[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-users] Re: [Xen-devel] ARP problems with xen 4.0 with pvops kernel
Hello, I'm using the latest stable-2.6.32.x. I already tried "ethtool -K <bridge> tx off", but that didn't make any difference. Also, this only happen with pv, in hvm mode all works ok and the domU sees the arp messages... Thanks, Luís On Tue, 2010-06-01 at 18:20 -0700, Jeremy Fitzhardinge wrote: On 06/01/2010 05:38 PM, Luís Silva wrote: > 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... What version of kernel are you using in dom0 and domU? There was a netback bug which caused problems with dom0<->domU communication, but it has been fixed for a while in 2.6.32 (but only recently in .31). The workaround is to disable tx checksum offload on your bridge (ethtool -K <bridge> tx off). J > > 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 > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel Attachment:
signature.asc _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |