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-devel] Re: [Xen-users] ARP problems with xen 4.0 with pvops kernel

To: xen-devel@xxxxxxxxxxxxxxxxxxx, xen-users@xxxxxxxxxxxxxxxxxxx, luis.silva@xxxxxxxxxxxxx
Subject: [Xen-devel] Re: [Xen-users] ARP problems with xen 4.0 with pvops kernel
From: Boris Derzhavets <bderzhavets@xxxxxxxxx>
Date: Thu, 3 Jun 2010 02:35:32 -0700 (PDT)
Cc:
Delivery-date: Thu, 03 Jun 2010 02:37:36 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1275557732; bh=EAg0Id7bBqxr7YkPI2ifS1FRglhSEVloVoLiomJNfFM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=4uo/i0Hfne0CIw/Zi8+AL292nL8AWfJO9nPuNlBstUyYROjyHf5d+VvyFncdhXxyRFNMSV5sR5kURBN0W4mObM5SH8w4B9nknFYW7sLBOtyB/FCKS9cb48KkI0OnDZgp55Ifrqpwy/lqre6/gE/57pX+y6AiJKxWgenuh4vMNvs=
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=DXdIGYQ1DmiEhCPYOxayTDkans3keDbCu4urXBJMgcMsRAmEdgTxZfhQu2PfcEbVGDcDP0zrfJRGcEURlmK3y4xLoZ68qzYA4Az8cBAFwNQtCjfH3xidoycgWzFIk441r9OEMkAaVQZDHWxsbiihTLhT/Kx1uvLr3qsW7+9hQTo=;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1275439138.2202.27.camel@luis-port>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> 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 was unable to reproduce this issue. F13 PV DomU was created via virt-manager
( libvirt 0.8.0) at Xen 4.0 (2.6.32.14) Dom0 on top of Ubuntu 10.04 Server.
I am able open SSH connection from Dom0 to F13 DomU.

Boris.



--- On Tue, 6/1/10, Luís Silva <luis.silva@xxxxxxxxxxxxx> wrote:

From: Luís Silva <luis.silva@xxxxxxxxxxxxx>
Subject: [Xen-users] ARP problems with xen 4.0 with pvops kernel
To: xen-devel@xxxxxxxxxxxxxxxxxxx, xen-users@xxxxxxxxxxxxxxxxxxx
Date: Tuesday, June 1, 2010, 8:38 PM

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

-----Inline Attachment Follows-----

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

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