WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-users] Re: [Xen-devel] ARP problems with xen 4.0 with pvops kernel
From: Luís Silva <luis.silva@xxxxxxxxxxxxx>
Date: Wed, 02 Jun 2010 09:47:31 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 02 Jun 2010 01:49:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C05B1D8.4000104@xxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
Organization: Axiomasoft
References: <1275439138.2202.27.camel@luis-port> <4C05B1D8.4000104@xxxxxxxx>
Reply-to: luis.silva@xxxxxxxxxxxxx
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
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
Description: This is a digitally signed message part

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