Re: [Xen-devel] ARP problems with xen 4.0 with pvops kernel

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Hi Luis,

I think i'm using a setup similar to yours:
I'm using debian on my dom0 and domU's, xen4, pvops xen-next kernel for domU.

in /etc/network/interfaces I create a xen_bridge on boot

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp

# The primary network interface
allow-hotplug eth1
iface eth1 inet static
        address 172.16.1.1
        netmask 255.255.0.0

auto xen_bridge
iface xen_bridge inet static
        address 192.168.1.1
        netmask 255.255.255.0
        network 192.168.1.0
        broadcast 192.168.1.255
#       #gateway <your_default_gateway>
#       #pre-up ifconfig eth0 down
        pre-up brctl addbr xen_bridge
#       #pre-up brctl addif xen-bridge eth0
#       #pre-up ifconfig eth0 up
#       #post-down ifconfig eth0 down
#       #post-down brctl delif xen-bridge eth0







On which all the domU's will connect.

in xend-config.sxp, I use:

(network-script network-dummy)
(vif-script     vif-bridge)





In domU config files I specify IP, MAC and the bridge to connect to:

vif         = [ 'bridge=xen_bridge,ip=192.168.1.6,mac=00:16:3E:49:0E:FA' ]



Traffic between bridge and eth0 and eth1 is routed with iptables/ipmasq.


This works fine for me.

--
Sander






> Hello,

> Finally I managed to get a xen 4.0 working on ubuntu 10.04 with pvops
> kernel and libvirt. However I am having some problems with networking...
> after initial installation with netinstall image in hvm mode, when I
> transform the vm in xen pv (via pygrub with the current ubuntu kernel),
> networking startEd to act weird...

> Basically I'm not using a network script from xen. I define a bridge
> (manually or via libvirt, the result is the same) and I use vif-bridge
> to connect the vif to it. But now the weird part comes: I can
> communicate from domU to dom0, but not the other way around, unless I
> keep a ping running from domU to dom0... That's right, weird... while
> trying the ping from dom0 to domU, I used tcpdump both on the bridge, on
> the vif and on the eth0 in the domU. The arp packets never get to domU,
> but they appear both in the bridge and the vif sniff's...

> Here is the bridge:


> ifconfig virbr0
> virbr0    Link encap:Ethernet  HWaddr fe:ff:ff:ff:ff:ff  
>           inet addr:192.168.120.254  Bcast:192.168.120.255  Mask:255.255.255.0
>           inet6 addr: fe80::7cee:4bff:fe82:e63f/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:16 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:226 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0 
>           RX bytes:952 (952.0 B)  TX bytes:13953 (13.9 KB)


> brctl show
> bridge name     bridge id               STP enabled     interfaces
> virbr0          8000.feffffffffff       no              vif5.0


> tcpdump -i virbr0 -vv -n
> tcpdump: listening on virbr0, link-type EN10MB (Ethernet), capture size 96 
> bytes
> 01:31:25.945151 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP 
> (1), length 84)
>     192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 1, 
> length 64
> 01:31:26.945361 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP 
> (1), length 84)
>     192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 2, 
> length 64
> 01:31:27.945420 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP 
> (1), length 84)
>     192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 3, 
> length 64
> 01:31:28.945362 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP 
> (1), length 84)
>     192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 4, 
> length 64
> 01:31:29.945364 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP 
> (1), length 84)
>     192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 5, 
> length 64
> 01:31:30.944300 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
> 192.168.120.1 tell 192.168.120.254, length 28
> 01:31:30.945359 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP 
> (1), length 84)
>     192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 6, 
> length 64
> 01:31:31.944297 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
> 192.168.120.1 tell 192.168.120.254, length 28
> 01:31:31.945444 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP 
> (1), length 84)
>     192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 7, 
> length 64
> 01:31:32.944294 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
> 192.168.120.1 tell 192.168.120.254, length 28
> 01:31:32.945401 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP 
> (1), length 84)
>     192.168.120.254 > 192.168.120.1: ICMP echo request, id 10317, seq 8, 
> length 64
> 01:31:33.947293 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
> 192.168.120.1 tell 192.168.120.254, length 28
> 01:31:34.947373 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
> 192.168.120.1 tell 192.168.120.254, length 28
> 01:31:35.947353 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
> 192.168.120.1 tell 192.168.120.254, length 28
> 01:31:37.948352 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
> 192.168.120.1 tell 192.168.120.254, length 28
> 01:31:38.948399 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
> 192.168.120.1 tell 192.168.120.254, length 28
> 01:31:39.948376 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
> 192.168.120.1 tell 192.168.120.254, length 28
> 01:31:40.949356 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
> 192.168.120.1 tell 192.168.120.254, length 28


> tcpdump -i vif5.0 -vv -n
> tcpdump: WARNING: vif5.0: no IPv4 address assigned
> tcpdump: listening on vif5.0, link-type EN10MB (Ethernet), capture size 96 
> bytes
> 01:32:19.956358 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
> 192.168.120.1 tell 192.168.120.254, length 28
> 01:32:20.956358 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
> 192.168.120.1 tell 192.168.120.254, length 28
> 01:32:21.956359 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
> 192.168.120.1 tell 192.168.120.254, length 28
> 01:32:23.957311 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
> 192.168.120.1 tell 192.168.120.254, length 28
> 01:32:24.957312 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
> 192.168.120.1 tell 192.168.120.254, length 28
> 01:32:25.957359 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
> 192.168.120.1 tell 192.168.120.254, length 28
> 01:32:27.958360 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
> 192.168.120.1 tell 192.168.120.254, length 28
> 01:32:28.958310 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
> 192.168.120.1 tell 192.168.120.254, length 28
> 01:32:29.958362 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
> 192.168.120.1 tell 192.168.120.254, length 28



> Forwarding and iptables don't seem to be the problem, because if I
> initiate a ping from domU (at the same time as the failing one from
> dom0), the ping in dom0 starts to work. As soon as I stop the ping in
> domU, the one in dom0 starts failing again...

> Is anyone having the same problem? Is this a bug in the kernel? In dom0
> or domU? 

> Thanks in advance,
> LuÃs



-- 
Best regards,
 Sander                            mailto:linux@xxxxxxxxxxxxxx


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel