thr3ads.net - Xen users - [Xen-devel] ARP problems with xen 4.0 with pvops kernel [Jun 2010]

If this information is useful, please help other people find it:
Share via:

Luís Silva

2010-Jun-02 00:38 UTC

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

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



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

Jeremy Fitzhardinge

2010-Jun-02 01:20 UTC

head link

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

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@lists.xensource.com
> http://lists.xensource.com/xen-devel
>   

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

Boris Derzhavets

2010-Jun-02 07:09 UTC

head link

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

Could you provide an exact version of pvops kernel you have built up.

Boris.

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

From: Luís Silva <luis.silva@axiomasoft.pt>
Subject: [Xen-users] ARP problems with xen 4.0 with pvops kernel
To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
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@lists.xensource.com
http://lists.xensource.com/xen-users


      

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

Sander Eikelenboom

2010-Jun-02 07:10 UTC

head link

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

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@eikelenboom.it


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

Boris Derzhavets

2010-Jun-02 08:00 UTC

head link

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

Via my experience under Xen 4.0 ( 2.6.32.14 pvops) on top of Ubuntu 10.04 Server
Command :-

# virt-install --connect xen:/// --name VF13P  -p --ram 2048 -f /dev/sda8 \
--vnc --location http://192.168.1.33/f13 --debug

Causes installer to crash Dom0 ( box just get frozen )  at the point of
requesting IP for F13 DomU via either eth0(xen bridge)  or virbr0.

About month ago same install worked OK with 2.6.32.12 pvops kernel.

Boris.
P.S. Some new message came up at virt-install :
libvirt : Xen Inotify error  - ......
libvirt : Xen Inotify error  - ......
libvirt : Xen Inotify error  - ......

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

From: Luís Silva <luis.silva@axiomasoft.pt>
Subject: [Xen-users] ARP problems with xen 4.0 with pvops kernel
To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
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@lists.xensource.com
http://lists.xensource.com/xen-users


      

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

Luís Silva

2010-Jun-02 08:47 UTC

head link

[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@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >   
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 




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

Jeremy Fitzhardinge

2010-Jun-02 16:06 UTC

head link

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

On 06/02/2010 01:47 AM, Luís Silva wrote:> 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...
Yes, ARP is a new twist on network problems.  I''m guessing
you''re using
hvm without stubdoms, which means that its networking originates from
qemu within dom0, whereas PV and HVM+stubdom comes via netback.

But aside from that, I''m stumped.  Are you running any firewalls on
either side?   Can you try disabling all the offloads (tx, rx, gso, tso)
on all the relevent interfaces (bridge, netback, within the guest) and
see if that changes anything?

    J
>
> 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@lists.xensource.com
<mailto:Xen-devel@lists.xensource.com>
>> > http://lists.xensource.com/xen-devel
>> >   
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
<mailto:Xen-devel@lists.xensource.com>
>> http://lists.xensource.com/xen-devel
>>
>>     
>

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

Luís Silva

2010-Jun-02 18:53 UTC

head link

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

Hello,

On Wed, 2010-06-02 at 09:06 -0700, Jeremy Fitzhardinge wrote:
> On 06/02/2010 01:47 AM, Luís Silva wrote:
> > 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...
> 
> Yes, ARP is a new twist on network problems.  I''m guessing
you''re using
> hvm without stubdoms, which means that its networking originates from
> qemu within dom0, whereas PV and HVM+stubdom comes via netback.
> 
Yes, when I mentioned hvm I was talking about hvm without stubdoms. I
haven''t tried those yet.
> But aside from that, I''m stumped.  Are you running any firewalls
on
> either side?   Can you try disabling all the offloads (tx, rx, gso, tso)
> on all the relevent interfaces (bridge, netback, within the guest) and
> see if that changes anything?
> 
>     J
> 

Ok, this is the bridge interface:


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

ifconfig virbr0
virbr0    Link encap:Ethernet  HWaddr c2:ef:67:2b:a4:23  
          inet addr:192.168.120.254  Bcast:192.168.120.255  Mask:255.255.255.0
          inet6 addr: fe80::c0ef:67ff:fe2b:a423/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:4662 (4.6 KB)


I''m not using firewall other than the rules defined by libvirt. DomU
has
no firewall and the rules in dom0 are only these (virbr0 is natted to
the outside, virbr1 is routed. The result is the same in either one of
them):

sudo iptables -L -n -v
Chain INPUT (policy ACCEPT 241K packets, 53M bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     udp  --  virbr1 *       0.0.0.0/0            0.0.0.0/0   
udp dpt:53
    0     0 ACCEPT     tcp  --  virbr1 *       0.0.0.0/0            0.0.0.0/0   
tcp dpt:53
    0     0 ACCEPT     udp  --  virbr1 *       0.0.0.0/0            0.0.0.0/0   
udp dpt:67
    0     0 ACCEPT     tcp  --  virbr1 *       0.0.0.0/0            0.0.0.0/0   
tcp dpt:67
    8   515 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0   
udp dpt:53
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0   
tcp dpt:53
    0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0   
udp dpt:67
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0   
tcp dpt:67

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      virbr1  0.0.0.0/0           
192.168.121.0/24
    0     0 ACCEPT     all  --  virbr1 *       192.168.121.0/24     0.0.0.0/0
    0     0 ACCEPT     all  --  virbr1 virbr1  0.0.0.0/0            0.0.0.0/0
    0     0 REJECT     all  --  *      virbr1  0.0.0.0/0            0.0.0.0/0   
reject-with icmp-port-unreachable
    0     0 REJECT     all  --  virbr1 *       0.0.0.0/0            0.0.0.0/0   
reject-with icmp-port-unreachable
   13  3448 ACCEPT     all  --  *      virbr0  0.0.0.0/0           
192.168.120.0/24    state RELATED,ESTABLISHED
   16  1374 ACCEPT     all  --  virbr0 *       192.168.120.0/24     0.0.0.0/0
    0     0 ACCEPT     all  --  virbr0 virbr0  0.0.0.0/0            0.0.0.0/0
    0     0 REJECT     all  --  *      virbr0  0.0.0.0/0            0.0.0.0/0   
reject-with icmp-port-unreachable
    0     0 REJECT     all  --  virbr0 *       0.0.0.0/0            0.0.0.0/0   
reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT 233K packets, 27M bytes)
 pkts bytes target     prot opt in     out     source               destination



And these are the various offload parameters as set at boot:


Offload parameters for virbr0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off

Offload parameters for vif1.0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off

Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: off
large-receive-offload: off


To disable all checksuming I run the following commands:
dom0:

sudo ethtool -K virbr0 tx off sg off tso off gso off gro off
sudo ethtool -K vif1.0 tx off sg off tso off gso off gro off

domU

sudo ethtool -K eth0 tx off sg off tso off gso off gro off


This managed to get all parameter to off in the mentioned interfaces,
but unfortunately the result is the same. The arp requests get to
vif1.0, but not to eth0 on the domU.


sudo tcpdump -i vif1.0 -n -vv arp
tcpdump: WARNING: vif1.0: no IPv4 address assigned
tcpdump: listening on vif1.0, link-type EN10MB (Ethernet), capture size 96 bytes
19:43:51.233378 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.1 tell 192.168.120.254, length 28
19:43:52.233164 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.1 tell 192.168.120.254, length 28
19:43:53.233166 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.1 tell 192.168.120.254, length 28
19:43:54.684214 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.1 tell 192.168.120.254, length 28
19:43:55.684218 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.1 tell 192.168.120.254, length 28
19:43:56.684232 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.1 tell 192.168.120.254, length 28


I hope this information is enough. If I can provide anything else to
help debug or test, please just ask! ;)

Thanks in advance,
Luís

> >
> > 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@lists.xensource.com
<mailto:Xen-devel@lists.xensource.com>
> >> > http://lists.xensource.com/xen-devel
> >> >   
> >>
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
<mailto:Xen-devel@lists.xensource.com>
> >> http://lists.xensource.com/xen-devel
> >>
> >>     
> >
> 
> 




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

Boris Derzhavets

2010-Jun-02 19:26 UTC

head link

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

Could you,please, build and try 2.6.32.10 ( xen/stable) ?

Boris.

--- On Wed, 6/2/10, Luís Silva <luis.silva@axiomasoft.pt> wrote:

From: Luís Silva <luis.silva@axiomasoft.pt>
Subject: [Xen-users] Re: [Xen-devel] ARP problems with xen 4.0 with pvops kernel
To: "Jeremy Fitzhardinge" <jeremy@goop.org>
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Date: Wednesday, June 2, 2010, 2:53 PM




  
  
Hello,


On Wed, 2010-06-02 at 09:06 -0700, Jeremy Fitzhardinge wrote:

On 06/02/2010 01:47 AM, Luís Silva wrote:> 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...
Yes, ARP is a new twist on network problems.  I''m guessing
you''re using
hvm without stubdoms, which means that its networking originates from
qemu within dom0, whereas PV and HVM+stubdom comes via netback.



Yes, when I mentioned hvm I was talking about hvm without stubdoms. I
haven''t tried those yet.

But aside from that, I''m stumped.  Are you running any firewalls on
either side?   Can you try disabling all the offloads (tx, rx, gso, tso)
on all the relevent interfaces (bridge, netback, within the guest) and
see if that changes anything?

    J




Ok, this is the bridge interface:


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

ifconfig virbr0
virbr0    Link encap:Ethernet  HWaddr c2:ef:67:2b:a4:23  
          inet addr:192.168.120.254  Bcast:192.168.120.255  Mask:255.255.255.0
          inet6 addr: fe80::c0ef:67ff:fe2b:a423/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:4662 (4.6 KB)


I''m not using firewall other than the rules defined by libvirt. DomU
has no firewall and the rules in dom0 are only these (virbr0 is natted to the
outside, virbr1 is routed. The result is the same in either one of them):
sudo iptables -L -n -v
Chain INPUT (policy ACCEPT 241K packets, 53M bytes)
 pkts bytes target     prot opt in     out     source              
destination        
    0     0 ACCEPT     udp  --  virbr1 *       0.0.0.0/0           
0.0.0.0/0           udp dpt:53
    0     0 ACCEPT     tcp  --  virbr1 *       0.0.0.0/0           
0.0.0.0/0           tcp dpt:53
    0     0 ACCEPT     udp  --  virbr1 *       0.0.0.0/0           
0.0.0.0/0           udp dpt:67
    0     0 ACCEPT     tcp  --  virbr1 *       0.0.0.0/0           
0.0.0.0/0           tcp dpt:67
    8   515 ACCEPT     udp  --  virbr0 *       0.0.0.0/0           
0.0.0.0/0           udp dpt:53
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0           
0.0.0.0/0           tcp dpt:53
    0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0           
0.0.0.0/0           udp dpt:67
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0           
0.0.0.0/0           tcp dpt:67

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source              
destination        
    0     0 ACCEPT     all  --  *      virbr1  0.0.0.0/0           
192.168.121.0/24   
    0     0 ACCEPT     all  --  virbr1 *       192.168.121.0/24    
0.0.0.0/0          
    0     0 ACCEPT     all  --  virbr1 virbr1  0.0.0.0/0           
0.0.0.0/0          
    0     0 REJECT     all  --  *      virbr1  0.0.0.0/0           
0.0.0.0/0           reject-with icmp-port-unreachable
    0     0 REJECT     all  --  virbr1 *       0.0.0.0/0           
0.0.0.0/0           reject-with icmp-port-unreachable
   13  3448 ACCEPT     all  --  *      virbr0  0.0.0.0/0           
192.168.120.0/24    state RELATED,ESTABLISHED
   16  1374 ACCEPT     all  --  virbr0 *       192.168.120.0/24    
0.0.0.0/0          
    0     0 ACCEPT     all  --  virbr0 virbr0  0.0.0.0/0           
0.0.0.0/0          
    0     0 REJECT     all  --  *      virbr0  0.0.0.0/0           
0.0.0.0/0           reject-with icmp-port-unreachable
    0     0 REJECT     all  --  virbr0 *       0.0.0.0/0           
0.0.0.0/0           reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT 233K packets, 27M bytes)
 pkts bytes target     prot opt in     out     source               destination



And these are the various offload parameters as set at boot:


Offload parameters for virbr0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off

Offload parameters for vif1.0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off

Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: off
large-receive-offload: off


To disable all checksuming I run the following commands:

dom0:
sudo ethtool -K virbr0 tx off sg off tso off gso off gro off
sudo ethtool -K vif1.0 tx off sg off tso off gso off gro off

domU
sudo ethtool -K eth0 tx off sg off tso off gso off gro off


This managed to get all parameter to off in the mentioned interfaces, but
unfortunately the result is the same. The arp requests get to vif1.0, but not to
eth0 on the domU.


sudo tcpdump -i vif1.0 -n -vv arp
tcpdump: WARNING: vif1.0: no IPv4 address assigned
tcpdump: listening on vif1.0, link-type EN10MB (Ethernet), capture size 96 bytes
19:43:51.233378 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.1 tell 192.168.120.254, length 28
19:43:52.233164 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.1 tell 192.168.120.254, length 28
19:43:53.233166 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.1 tell 192.168.120.254, length 28
19:43:54.684214 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.1 tell 192.168.120.254, length 28
19:43:55.684218 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.1 tell 192.168.120.254, length 28
19:43:56.684232 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.1 tell 192.168.120.254, length 28


I hope this information is enough. If I can provide anything else to help debug
or test, please just ask! ;)


Thanks in advance,

Luís


>
> 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@lists.xensource.com
<mailto:Xen-devel@lists.xensource.com>
>> > http://lists.xensource.com/xen-devel
>> >   
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
<mailto:Xen-devel@lists.xensource.com>
>> http://lists.xensource.com/xen-devel
>>
>>     
>




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

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


      

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

Boris Derzhavets

2010-Jun-03 09:35 UTC

head link

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

> 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@axiomasoft.pt> wrote:

From: Luís Silva <luis.silva@axiomasoft.pt>
Subject: [Xen-users] ARP problems with xen 4.0 with pvops kernel
To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
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@lists.xensource.com
http://lists.xensource.com/xen-users


      

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

Luís Silva

2010-Jun-03 10:20 UTC

head link

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

Hello,

Thanks for the suggestion, xen/stable works ok for me. Only problem is
that I have to disable offload do get dhcp to work on domU, but the
problem I described before doesn''t exist in this kernel. Later today
I''m
going to try a previous build I have based on stable-2.6.32.x
(2.6.32.13) to check if it already had this problem or not and I''ll
post
the results.

Luís

On Wed, 2010-06-02 at 12:26 -0700, Boris Derzhavets wrote:
> Could you,please, build and try 2.6.32.10 ( xen/stable) ?
> 
> Boris.
> 
> --- On Wed, 6/2/10, Luís Silva <luis.silva@axiomasoft.pt> wrote:
> 
>         
>         From: Luís Silva <luis.silva@axiomasoft.pt>
>         Subject: [Xen-users] Re: [Xen-devel] ARP problems with xen 4.0
>         with pvops kernel
>         To: "Jeremy Fitzhardinge" <jeremy@goop.org>
>         Cc: xen-devel@lists.xensource.com,
>         xen-users@lists.xensource.com
>         Date: Wednesday, June 2, 2010, 2:53 PM
>         
>         
>         Hello,
>         
>         On Wed, 2010-06-02 at 09:06 -0700, Jeremy Fitzhardinge wrote: 
>         
>         > On 06/02/2010 01:47 AM, Luís Silva wrote:
>         > > 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...
>         > 
>         > Yes, ARP is a new twist on network problems.  I''m
guessing you''re using
>         > hvm without stubdoms, which means that its networking
originates from
>         > qemu within dom0, whereas PV and HVM+stubdom comes via
netback.
>         > 
>         
>         Yes, when I mentioned hvm I was talking about hvm without
>         stubdoms. I haven''t tried those yet. 
>         
>         > But aside from that, I''m stumped.  Are you running
any firewalls on
>         > either side?   Can you try disabling all the offloads (tx, rx,
gso, tso)
>         > on all the relevent interfaces (bridge, netback, within the
guest) and
>         > see if that changes anything?
>         > 
>         >     J
>         > 
>         
>         
>         Ok, this is the bridge interface:
>         
>         
>         brctl show
>         bridge name	bridge id		STP enabled	interfaces
>         virbr0		8000.feffffffffff	no		vif1.0
>         
>         ifconfig virbr0
>         virbr0    Link encap:Ethernet  HWaddr c2:ef:67:2b:a4:23  
>                   inet addr:192.168.120.254  Bcast:192.168.120.255 
Mask:255.255.255.0
>                   inet6 addr: fe80::c0ef:67ff:fe2b:a423/64 Scope:Link
>                   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>                   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>                   TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
>                   collisions:0 txqueuelen:0 
>                   RX bytes:0 (0.0 B) 
>          TX bytes:4662 (4.6 KB)
>         
>         
>         I''m not using firewall other than the rules defined by
>         libvirt. DomU has no firewall and the rules in dom0 are only
>         these (virbr0 is natted to the outside, virbr1 is routed. The
>         result is the same in either one of them): 
>         
>         sudo iptables -L -n -v
>         Chain INPUT (policy ACCEPT 241K packets, 53M bytes)
>          pkts bytes target     prot opt in     out     source              
destination
>             0     0 ACCEPT     udp  --  virbr1 *       0.0.0.0/0           
0.0.0.0/0           udp dpt:53
>             0     0 ACCEPT     tcp  --  virbr1 *       0.0.0.0/0           
0.0.0.0/0           tcp dpt:53
>          
>             0     0 ACCEPT     udp  --  virbr1 *       0.0.0.0/0           
0.0.0.0/0           udp dpt:67
>             0     0 ACCEPT     tcp  --  virbr1 *       0.0.0.0/0           
0.0.0.0/0           tcp dpt:67
>             8   515 ACCEPT     udp  --  virbr0 *       0.0.0.0/0           
0.0.0.0/0           udp dpt:53
>             0     0
>          ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0 
tcp dpt:53
>             0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0           
0.0.0.0/0           udp dpt:67
>             0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0           
0.0.0.0/0           tcp dpt:67
>         
>         Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>          pkts bytes target     prot
>          opt in     out     source               destination         
>             0     0 ACCEPT     all  --  *      virbr1  0.0.0.0/0           
192.168.121.0/24
>             0     0 ACCEPT     all  --  virbr1 *       192.168.121.0/24    
0.0.0.0/0
>             0     0 ACCEPT     all  --  virbr1 virbr1  0.0.0.0/0           
>          0.0.0.0/0           
>             0     0 REJECT     all  --  *      virbr1  0.0.0.0/0           
0.0.0.0/0           reject-with icmp-port-unreachable
>             0     0 REJECT     all  --  virbr1 *       0.0.0.0/0           
0.0.0.0/0           reject-with icmp-port-unreachable
>            13  3448 ACCEPT     all  --  *      virbr0  0.0.0.0/0           
192.168.120.0/24    state
>          RELATED,ESTABLISHED 
>            16  1374 ACCEPT     all  --  virbr0 *       192.168.120.0/24    
0.0.0.0/0
>             0     0 ACCEPT     all  --  virbr0 virbr0  0.0.0.0/0           
0.0.0.0/0
>             0     0 REJECT     all  --  *      virbr0  0.0.0.0/0           
0.0.0.0/0           reject-with icmp-port-unreachable
>             0     0 REJECT     all  --  virbr0
>          *       0.0.0.0/0            0.0.0.0/0           reject-with
icmp-port-unreachable
>         
>         Chain OUTPUT (policy ACCEPT 233K packets, 27M bytes)
>          pkts bytes target     prot opt in     out     source              
destination
>         
>         
>         
>         And these are the various offload parameters as set at boot:
>         
>         
>         Offload parameters for virbr0:
>         rx-checksumming: on
>         tx-checksumming: on
>         scatter-gather: on
>         tcp-segmentation-offload: on
>         udp-fragmentation-offload: on
>         generic-segmentation-offload: on
>         generic-receive-offload: off
>         large-receive-offload: off
>         
>         Offload parameters for vif1.0:
>         rx-checksumming: on
>         tx-checksumming: on
>         scatter-gather: on
>         tcp-segmentation-offload: on
>         udp-fragmentation-offload: off
>         generic-segmentation-offload: on
>         generic-receive-offload: off
>         large-receive-offload: off
>         
>         Offload parameters for eth0:
>         rx-checksumming: on
>         tx-checksumming: on
>         scatter-gather: on
>         tcp-segmentation-offload: on
>         udp-fragmentation-offload: off
>         generic-segmentation-offload: off
>         generic-receive-offload: off
>         large-receive-offload: off
>         
>         
>         To disable all checksuming I run the following commands:
>         dom0: 
>         
>         sudo ethtool -K virbr0 tx off sg off tso off gso off gro off
>         sudo ethtool -K vif1.0 tx off sg off tso off gso off gro off
>         
>         domU 
>         
>         sudo ethtool -K eth0 tx off sg off tso off gso off gro off
>         
>         
>         This managed to get all parameter to off in the mentioned
>         interfaces, but unfortunately the result is the same. The arp
>         requests get to vif1.0, but not to eth0 on the domU.
>         
>         
>         sudo tcpdump -i vif1.0 -n -vv arp
>         tcpdump: WARNING: vif1.0: no IPv4 address assigned
>         tcpdump: listening on vif1.0, link-type EN10MB (Ethernet), capture
size 96 bytes
>         19:43:51.233378 ARP, Ethernet (len 6), IPv4 (len 4), Request
who-has 192.168.120.1 tell 192.168.120.254, length 28
>         19:43:52.233164 ARP, Ethernet (len 6), IPv4 (len 4), Request
who-has 192.168.120.1 tell 192.168.120.254, length 28
>         19:43:53.233166 ARP, Ethernet (len 6), IPv4 (len 4), Request
who-has 192.168.120.1 tell 192.168.120.254, length 28
>         19:43:54.684214 ARP, Ethernet (len 6), IPv4 (len 4), Request
who-has 192.168.120.1 tell 192.168.120.254, length 28
>         19:43:55.684218 ARP, Ethernet (len 6), IPv4 (len 4), Request
who-has 192.168.120.1 tell 192.168.120.254, length 28
>         19:43:56.684232 ARP, Ethernet (len 6), IPv4 (len 4), Request
who-has 192.168.120.1 tell 192.168.120.254, length 28
>         
>         
>         I hope this information is enough. If I can provide anything
>         else to help debug or test, please just ask! ;)
>         
>         Thanks in advance,
>         Luís
>         
>         
>         > >
>         > > 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@lists.xensource.com
<mailto:Xen-devel@lists.xensource.com>
>         > >> > http://lists.xensource.com/xen-devel
>         > >> >   
>         > >>
>         > >>
>         > >> _______________________________________________
>         > >> Xen-devel mailing list
>         > >> Xen-devel@lists.xensource.com
<mailto:Xen-devel@lists.xensource.com>
>         > >> http://lists.xensource.com/xen-devel
>         > >>
>         > >>     
>         > >
>         > 
>         > 
>         
>         
>         
>         
>         
>         -----Inline Attachment Follows-----
>         
>         
>         _______________________________________________
>         Xen-users mailing list
>         Xen-users@lists.xensource.com
>         http://lists.xensource.com/xen-users
> 




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

Boris Derzhavets

2010-Jun-03 10:59 UTC

head link

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

> stable-2.6.32.x (2.6.32.13) to check if it already had this problem.
I would guess it''s OK now ;)

# git branch -D xen/stable-2.6.32.x
# git checkout -b xen/stable-2.6.32.x  origin/xen/stable-2.6.32.x
# git pull
# make menuconfig ( will show 2.6.32.14 at the moment)
# make
>have to disable offload do get dhcp to work on domU
 Run tcpdump on any other box on the LAN different from Dom0 hosting.
 DHCPDISCOVER is a broadcast request, so you should be able to capture
 wrong UDP checksums. Otherwise it''s gonna be a miracle.

Boris.


--- On Thu, 6/3/10, Luís Silva <luis.silva@axiomasoft.pt> wrote:

From: Luís Silva <luis.silva@axiomasoft.pt>
Subject: Re: [Xen-users] Re: [Xen-devel] ARP problems with xen 4.0 with pvops
kernel
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "Jeremy Fitzhardinge" <jeremy@goop.org>,
xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Date: Thursday, June 3, 2010, 6:20 AM




  
  
Hello,


Thanks for the suggestion, xen/stable works ok for me. Only problem is that I
have to disable offload do get dhcp to work on domU, but the problem I described
before doesn''t exist in this kernel. Later today I''m going to
try a previous build I have based on stable-2.6.32.x (2.6.32.13) to check if it
already had this problem or not and I''ll post the results.


Luís


On Wed, 2010-06-02 at 12:26 -0700, Boris Derzhavets wrote:


    


Could you,please, build and try 2.6.32.10 ( xen/stable) ?


Boris.


--- On Wed, 6/2/10, Luís Silva <luis.silva@axiomasoft.pt> wrote:


    

    From: Luís Silva <luis.silva@axiomasoft.pt>

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

    To: "Jeremy Fitzhardinge" <jeremy@goop.org>

    Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com

    Date: Wednesday, June 2, 2010, 2:53 PM

    



    Hello,

    

    On Wed, 2010-06-02 at 09:06 -0700, Jeremy Fitzhardinge wrote: 
    
On 06/02/2010 01:47 AM, Luís Silva wrote:> 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...
Yes, ARP is a new twist on network problems.  I''m guessing
you''re using
hvm without stubdoms, which means that its networking originates from
qemu within dom0, whereas PV and HVM+stubdom comes via netback.


    
    Yes, when I mentioned hvm I was talking about hvm without stubdoms. I
haven''t tried those yet.
    
But aside from that, I''m stumped.  Are you running any firewalls on
either side?   Can you try disabling all the offloads (tx, rx, gso, tso)
on all the relevent interfaces (bridge, netback, within the guest) and
see if that changes anything?

    J


    
    

    Ok, this is the bridge interface:

    

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

ifconfig virbr0
virbr0    Link encap:Ethernet  HWaddr c2:ef:67:2b:a4:23  
          inet addr:192.168.120.254  Bcast:192.168.120.255  Mask:255.255.255.0
          inet6 addr: fe80::c0ef:67ff:fe2b:a423/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B) 
 TX bytes:4662 (4.6 KB)

    

    I''m not using firewall other than the rules defined by libvirt.
DomU has no firewall and the rules in dom0 are only these (virbr0 is natted to
the outside, virbr1 is routed. The result is the same in either one of them):
sudo iptables -L -n -v
Chain INPUT (policy ACCEPT 241K packets, 53M bytes)
 pkts bytes target     prot opt in     out     source              
destination        
    0     0 ACCEPT     udp  --  virbr1 *       0.0.0.0/0           
0.0.0.0/0           udp dpt:53
    0     0 ACCEPT     tcp  --  virbr1 *       0.0.0.0/0           
0.0.0.0/0           tcp dpt:53
 
    0     0 ACCEPT     udp  --  virbr1 *       0.0.0.0/0           
0.0.0.0/0           udp dpt:67
    0     0 ACCEPT     tcp  --  virbr1 *       0.0.0.0/0           
0.0.0.0/0           tcp dpt:67
    8   515 ACCEPT     udp  --  virbr0 *       0.0.0.0/0           
0.0.0.0/0           udp dpt:53
    0     0
 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0           tcp
dpt:53
    0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0           
0.0.0.0/0           udp dpt:67
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0           
0.0.0.0/0           tcp dpt:67

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot
 opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      virbr1  0.0.0.0/0           
192.168.121.0/24   
    0     0 ACCEPT     all  --  virbr1 *       192.168.121.0/24    
0.0.0.0/0          
    0     0 ACCEPT     all  --  virbr1 virbr1  0.0.0.0/0           
 0.0.0.0/0           
    0     0 REJECT     all  --  *      virbr1  0.0.0.0/0           
0.0.0.0/0           reject-with icmp-port-unreachable
    0     0 REJECT     all  --  virbr1 *       0.0.0.0/0           
0.0.0.0/0           reject-with icmp-port-unreachable
   13  3448 ACCEPT     all  --  *      virbr0  0.0.0.0/0           
192.168.120.0/24    state
 RELATED,ESTABLISHED 
   16  1374 ACCEPT     all  --  virbr0 *       192.168.120.0/24    
0.0.0.0/0          
    0     0 ACCEPT     all  --  virbr0 virbr0  0.0.0.0/0           
0.0.0.0/0          
    0     0 REJECT     all  --  *      virbr0  0.0.0.0/0           
0.0.0.0/0           reject-with icmp-port-unreachable
    0     0 REJECT     all  --  virbr0
 *       0.0.0.0/0            0.0.0.0/0           reject-with
icmp-port-unreachable

Chain OUTPUT (policy ACCEPT 233K packets, 27M bytes)
 pkts bytes target     prot opt in     out     source               destination

    

    

    And these are the various offload parameters as set at boot:

    

Offload parameters for virbr0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off

Offload parameters for vif1.0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off

Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: off
large-receive-offload: off

    

    To disable all checksuming I run the following commands:

    dom0: 
sudo ethtool -K virbr0 tx off sg off tso off gso off gro off
sudo ethtool -K vif1.0 tx off sg off tso off gso off gro off

    domU 
sudo ethtool -K eth0 tx off sg off tso off gso off gro off

    

    This managed to get all parameter to off in the mentioned interfaces, but
unfortunately the result is the same. The arp requests get to vif1.0, but not to
eth0 on the domU.

    

sudo tcpdump -i vif1.0 -n -vv arp
tcpdump: WARNING: vif1.0: no IPv4 address assigned
tcpdump: listening on vif1.0, link-type EN10MB (Ethernet), capture size 96 bytes
19:43:51.233378 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.1 tell 192.168.120.254, length 28
19:43:52.233164 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.1 tell 192.168.120.254, length 28
19:43:53.233166 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.1 tell 192.168.120.254, length 28
19:43:54.684214 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.1 tell 192.168.120.254, length 28
19:43:55.684218 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.1 tell 192.168.120.254, length 28
19:43:56.684232 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.1 tell 192.168.120.254, length 28

    

    I hope this information is enough. If I can provide anything else to help
debug or test, please just ask! ;)

    

    Thanks in advance,

    Luís

    

    >
> 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@lists.xensource.com
<mailto:Xen-devel@lists.xensource.com>
>> > http://lists.xensource.com/xen-devel
>> >   
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
<mailto:Xen-devel@lists.xensource.com>
>> http://lists.xensource.com/xen-devel
>>
>>     
>


    
    

    



    

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

    



    _______________________________________________

    Xen-users mailing list

    Xen-users@lists.xensource.com

    http://lists.xensource.com/xen-users




    



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

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


      

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

Luís Silva

2010-Jun-03 23:18 UTC

head link

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

Hello again,

So, As I said, I had a build of 2.6.32.13 built from xen/stable-2.6.32.x
hanging around (last commit in git log is
"4dd582f35f28707a039111be9fdb8101fecb07de") and I tested it for the
particular problem I reported. The tests didn''t show the problem I had,
so it should have been introduced somewhere in between...

To sumarize my findings:

      * xen/stable (2.6.32.10): OK: It still has the UDP checksum
        problem, but other than that, networking seems to work ok.
      * xen(stable-2.6.32.x (up to commit
        "4dd582f35f28707a039111be9fdb8101fecb07de"): OK: I
didn''t test
        the checksum problem, but it should have it also as the fix was
        commited after this date. My problem also doesn''t show up here.
      * xen/stable-2.6.32.x (2.6.32.14): NOT OK: No communication from
        dom0 to domU, unless domU is generating traffic. ARP requests
        from dom0 don''t reach domU. As to whether the UDP checksum is
        fixed or not... It should be fixed but my ubuntu 10.04 domU
        still can''t get a DHCP lease without disabling checksum offload
        on the vif interface. At least, the UDP checksum errors don''t
        get to dmesg, but it still seems to be something wrong with this
        kernel version. Bellow I post the tcpdump''s for a DHCP request
        from domU, first with default settings and the second with
        offload disabled (by sudo ethtool -K vif2.0 tx off sg off tso
        off gso off gro off)


This dump is *with* checksum:

sudo tcpdump -i vif2.0 -n -vv
tcpdump: WARNING: vif2.0: no IPv4 address assigned
tcpdump: listening on vif2.0, link-type EN10MB (Ethernet), capture size 96 bytes
00:04:39.314038 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP
(17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
00:16:36:47:57:87, length 300, xid 0x1882cf2d, Flags [none] (0x0000)
	  Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:04:39.413071 IP (tos 0x0, ttl 64, id 49739, offset 0, flags [none], proto UDP
(17), length 328)
    192.168.120.254.67 > 192.168.120.114.68: BOOTP/DHCP, Reply, length 300,
xid 0x1882cf2d, Flags [none] (0x0000)
	  Your-IP 192.168.120.114
	  Server-IP 192.168.120.254
	  Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:04:44.315876 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP
(17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
00:16:36:47:57:87, length 300, xid 0x1882cf2d, secs 5, Flags [none] (0x0000)
	  Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:04:44.316316 IP (tos 0x0, ttl 64, id 49740, offset 0, flags [none], proto UDP
(17), length 328)
    192.168.120.254.67 > 192.168.120.114.68: BOOTP/DHCP, Reply, length 300,
xid 0x1882cf2d, secs 5, Flags [none] (0x0000)
	  Your-IP 192.168.120.114
	  Server-IP 192.168.120.254
	  Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:04:49.315733 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.114 tell 192.168.120.254, length 28
00:04:50.315687 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.114 tell 192.168.120.254, length 28
00:04:51.315737 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.114 tell 192.168.120.254, length 28
00:04:57.324111 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP
(17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
00:16:36:47:57:87, length 300, xid 0x1882cf2d, secs 18, Flags [none] (0x0000)
	  Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:04:57.324498 IP (tos 0x0, ttl 64, id 49741, offset 0, flags [none], proto UDP
(17), length 328)
    192.168.120.254.67 > 192.168.120.114.68: BOOTP/DHCP, Reply, length 300,
xid 0x1882cf2d, secs 18, Flags [none] (0x0000)
	  Your-IP 192.168.120.114
	  Server-IP 192.168.120.254
	  Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:05:02.323734 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.114 tell 192.168.120.254, length 28
00:05:03.323731 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.114 tell 192.168.120.254, length 28
00:05:04.323732 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.114 tell 192.168.120.254, length 28



This dump is *without* checksum:

00:05:56.313304 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP
(17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
00:16:36:47:57:87, length 300, xid 0xfccb9d73, Flags [none] (0x0000)
	  Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:05:56.313902 IP (tos 0x0, ttl 64, id 49742, offset 0, flags [none], proto UDP
(17), length 328)
    192.168.120.254.67 > 192.168.120.114.68: BOOTP/DHCP, Reply, length 300,
xid 0xfccb9d73, Flags [none] (0x0000)
	  Your-IP 192.168.120.114
	  Server-IP 192.168.120.254
	  Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:06:01.313723 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.114 tell 192.168.120.254, length 28
00:06:02.313725 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.114 tell 192.168.120.254, length 28
00:06:03.313724 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.114 tell 192.168.120.254, length 28
00:06:04.320745 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP
(17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
00:16:36:47:57:87, length 300, xid 0xfccb9d73, secs 8, Flags [none] (0x0000)
	  Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:06:04.321119 IP (tos 0x0, ttl 64, id 49743, offset 0, flags [none], proto UDP
(17), length 328)
    192.168.120.254.67 > 192.168.120.114.68: BOOTP/DHCP, Reply, length 300,
xid 0xfccb9d73, secs 8, Flags [none] (0x0000)
	  Your-IP 192.168.120.114
	  Server-IP 192.168.120.254
	  Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:06:04.325804 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP
(17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
00:16:36:47:57:87, length 300, xid 0xfccb9d73, secs 8, Flags [none] (0x0000)
	  Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:06:04.422863 IP (tos 0x0, ttl 64, id 49744, offset 0, flags [none], proto UDP
(17), length 336)
    192.168.120.254.67 > 192.168.120.114.68: BOOTP/DHCP, Reply, length 308,
xid 0xfccb9d73, secs 8, Flags [none] (0x0000)
	  Your-IP 192.168.120.114
	  Server-IP 192.168.120.254
	  Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:06:07.315456 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP
(17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
00:16:36:47:57:87, length 300, xid 0xfccb9d73, secs 8, Flags [none] (0x0000)
	  Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:06:07.440054 IP (tos 0x0, ttl 64, id 49745, offset 0, flags [none], proto UDP
(17), length 336)
    192.168.120.254.67 > 192.168.120.114.68: BOOTP/DHCP, Reply, length 308,
xid 0xfccb9d73, secs 8, Flags [none] (0x0000)
	  Your-IP 192.168.120.114
	  Server-IP 192.168.120.254
	  Client-Ethernet-Address 00:16:36:47:57:87 [|bootp]
00:06:12.439828 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.114 tell 192.168.120.254, length 28
00:06:13.439746 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.114 tell 192.168.120.254, length 28
00:06:14.439674 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.114 tell 192.168.120.254, length 28


I hope this extra information can help to trace the problems.
Luís

On Thu, 2010-06-03 at 03:59 -0700, Boris Derzhavets wrote:
> > stable-2.6.32.x (2.6.32.13) to check if it already had this problem.
> 
> I would guess it''s OK now ;)
> 
> # git branch -D xen/stable-2.6.32.x
> # git checkout -b xen/stable-2.6.32.x  origin/xen/stable-2.6.32.x
> # git pull
> # make menuconfig ( will show 2.6.32.14 at the moment)
> # make
> 
> >have to disable offload do get dhcp to work on domU
> 
>  Run tcpdump on any other box on the LAN different from Dom0 hosting.
>  DHCPDISCOVER is a broadcast request, so you should be able to capture
>  wrong UDP checksums. Otherwise it''s gonna be a miracle.
> 
> Boris.
> 
> 
> --- On Thu, 6/3/10, Luís Silva <luis.silva@axiomasoft.pt> wrote:
> 
>         
>         From: Luís Silva <luis.silva@axiomasoft.pt>
>         Subject: Re: [Xen-users] Re: [Xen-devel] ARP problems with xen
>         4.0 with pvops kernel
>         To: "Boris Derzhavets" <bderzhavets@yahoo.com>
>         Cc: "Jeremy Fitzhardinge" <jeremy@goop.org>,
>         xen-devel@lists.xensource.com, xen-users@lists.xensource.com
>         Date: Thursday, June 3, 2010, 6:20 AM
>         
>         
>         Hello,
>         
>         Thanks for the suggestion, xen/stable works ok for me. Only
>         problem is that I have to disable offload do get dhcp to work
>         on domU, but the problem I described before doesn''t exist
in
>         this kernel. Later today I''m going to try a previous build
I
>         have based on stable-2.6.32.x (2.6.32.13) to check if it
>         already had this problem or not and I''ll post the results.
>         
>         Luís
>         
>         On Wed, 2010-06-02 at 12:26 -0700, Boris Derzhavets wrote:
>         
>         > Could you,please, build and try 2.6.32.10 ( xen/stable) ?
>         > 
>         > Boris.
>         > 
>         > --- On Wed, 6/2/10, Luís Silva
<luis.silva@axiomasoft.pt>
>         > wrote:
>         > 
>         >         
>         >         From: Luís Silva <luis.silva@axiomasoft.pt>
>         >         Subject: [Xen-users] Re: [Xen-devel] ARP problems
>         >         with xen 4.0 with pvops kernel
>         >         To: "Jeremy Fitzhardinge"
<jeremy@goop.org>
>         >         Cc: xen-devel@lists.xensource.com,
>         >         xen-users@lists.xensource.com
>         >         Date: Wednesday, June 2, 2010, 2:53 PM
>         >         
>         >         Hello,
>         >         
>         >         On Wed, 2010-06-02 at 09:06 -0700, Jeremy
>         >         Fitzhardinge wrote: 
>         >         
>         >         > On 06/02/2010 01:47 AM, Luís Silva wrote:
>         >         > > 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...
>         >         > 
>         >         > Yes, ARP is a new twist on network problems. 
I''m guessing you''re using
>         >         > hvm without stubdoms, which means that its
networking originates from
>         >         > qemu within dom0, whereas PV and HVM+stubdom
comes via netback.
>         >         > 
>         >         
>         >         Yes, when I mentioned hvm I was talking about hvm
>         >         without stubdoms. I haven''t tried those yet. 
>         >         
>         >         > But aside from that, I''m stumped.  Are
you running any firewalls on
>         >         > either side?   Can you try disabling all the
offloads (tx, rx, gso, tso)
>         >         > on all the relevent interfaces (bridge, netback,
within the guest) and
>         >         > see if that changes anything?
>         >         > 
>         >         >     J
>         >         > 
>         >         
>         >         
>         >         Ok, this is the bridge interface:
>         >         
>         >         
>         >         brctl show
>         >         bridge name	bridge id		STP enabled	interfaces
>         >         virbr0		8000.feffffffffff	no		vif1.0
>         >         
>         >         ifconfig virbr0
>         >         virbr0    Link encap:Ethernet  HWaddr
c2:ef:67:2b:a4:23
>         >                   inet addr:192.168.120.254 
Bcast:192.168.120.255  Mask:255.255.255.0
>         >                   inet6 addr: fe80::c0ef:67ff:fe2b:a423/64
Scope:Link
>         >                   UP BROADCAST RUNNING MULTICAST  MTU:1500 
Metric:1
>         >                   RX packets:0 errors:0 dropped:0 overruns:0
frame:0
>         >                   TX packets:25 errors:0 dropped:0 overruns:0
carrier:0
>         >                   collisions:0 txqueuelen:0 
>         >                   RX bytes:0 (0.0
>         >          B) 
>         >          TX bytes:4662 (4.6 KB)
>         >         
>         >         
>         >         I''m not using firewall other than the rules
defined
>         >         by libvirt. DomU has no firewall and the rules in
>         >         dom0 are only these (virbr0 is natted to the
>         >         outside, virbr1 is routed. The result is the same in
>         >         either one of them): 
>         >         
>         >         sudo iptables -L -n -v
>         >         Chain INPUT (policy ACCEPT 241K packets, 53M bytes)
>         >          pkts bytes target     prot opt in     out     source 
destination
>         >             0     0 ACCEPT     udp  --  virbr1 *      
0.0.0.0/0            0.0.0.0/0           udp dpt:53
>         >             0     0 ACCEPT     tcp  --  virbr1 *      
0.0.0.0/0            0.0.0.0/0           tcp dpt:53
>         >         
>         >          
>         >             0     0 ACCEPT     udp  --  virbr1 *      
0.0.0.0/0            0.0.0.0/0           udp dpt:67
>         >             0     0 ACCEPT     tcp  --  virbr1 *      
0.0.0.0/0            0.0.0.0/0           tcp dpt:67
>         >             8   515 ACCEPT     udp  --  virbr0 *      
0.0.0.0/0            0.0.0.0/0           udp dpt:53
>         >             0     0
>         >         
>         >          ACCEPT     tcp  --  virbr0 *       0.0.0.0/0         
0.0.0.0/0           tcp dpt:53
>         >             0     0 ACCEPT     udp  --  virbr0 *      
0.0.0.0/0            0.0.0.0/0           udp dpt:67
>         >             0     0 ACCEPT     tcp  --  virbr0 *      
0.0.0.0/0            0.0.0.0/0           tcp dpt:67
>         >         
>         >         Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>         >          pkts bytes target    
>         >          prot
>         >          opt in     out     source               destination
>         >             0     0 ACCEPT     all  --  *      virbr1 
0.0.0.0/0            192.168.121.0/24
>         >             0     0 ACCEPT     all  --  virbr1 *      
192.168.121.0/24     0.0.0.0/0
>         >             0     0 ACCEPT     all  --  virbr1 virbr1 
0.0.0.0/0
>         >         
>         >          0.0.0.0/0           
>         >             0     0 REJECT     all  --  *      virbr1 
0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
>         >             0     0 REJECT     all  --  virbr1 *      
0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
>         >            13  3448 ACCEPT     all  --  *      virbr0 
0.0.0.0/0            192.168.120.0/24
>         >          state
>         >          RELATED,ESTABLISHED 
>         >            16  1374 ACCEPT     all  --  virbr0 *      
192.168.120.0/24     0.0.0.0/0
>         >             0     0 ACCEPT     all  --  virbr0 virbr0 
0.0.0.0/0            0.0.0.0/0
>         >             0     0 REJECT     all  --  *      virbr0 
0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
>         >             0     0 REJECT     all  -- 
>         >          virbr0
>         >          *       0.0.0.0/0            0.0.0.0/0          
reject-with icmp-port-unreachable
>         >         
>         >         Chain OUTPUT (policy ACCEPT 233K packets, 27M bytes)
>         >          pkts bytes target     prot opt in     out     source 
destination
>         >         
>         >         
>         >         
>         >         And these are the various offload parameters as set
>         >         at boot:
>         >         
>         >         
>         >         Offload parameters for virbr0:
>         >         rx-checksumming: on
>         >         tx-checksumming: on
>         >         scatter-gather: on
>         >         tcp-segmentation-offload: on
>         >         udp-fragmentation-offload: on
>         >         generic-segmentation-offload: on
>         >         generic-receive-offload: off
>         >         large-receive-offload: off
>         >         
>         >         Offload parameters for vif1.0:
>         >         rx-checksumming: on
>         >         tx-checksumming: on
>         >         scatter-gather: on
>         >         tcp-segmentation-offload: on
>         >         udp-fragmentation-offload: off
>         >         generic-segmentation-offload: on
>         >         generic-receive-offload: off
>         >         large-receive-offload: off
>         >         
>         >         Offload parameters for eth0:
>         >         rx-checksumming: on
>         >         tx-checksumming: on
>         >         scatter-gather: on
>         >         tcp-segmentation-offload: on
>         >         udp-fragmentation-offload: off
>         >         generic-segmentation-offload: off
>         >         generic-receive-offload: off
>         >         large-receive-offload: off
>         >         
>         >         
>         >         To disable all checksuming I run the following
>         >         commands:
>         >         dom0: 
>         >         
>         >         sudo ethtool -K virbr0 tx off sg off tso off gso off
gro off
>         >         sudo ethtool -K vif1.0 tx off sg off tso off gso off
gro off
>         >         
>         >         domU 
>         >         
>         >         sudo ethtool -K eth0 tx off sg off tso off gso off gro
off
>         >         
>         >         
>         >         This managed to get all parameter to off in the
>         >         mentioned interfaces, but unfortunately the result
>         >         is the same. The arp requests get to vif1.0, but not
>         >         to eth0 on the domU.
>         >         
>         >         
>         >         sudo tcpdump -i vif1.0 -n -vv arp
>         >         tcpdump: WARNING: vif1.0: no IPv4 address assigned
>         >         tcpdump: listening on vif1.0, link-type EN10MB
(Ethernet), capture size 96 bytes
>         >         19:43:51.233378 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.120.1 tell 192.168.120.254, length 28
>         >         19:43:52.233164 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.120.1 tell 192.168.120.254, length 28
>         >         19:43:53.233166 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.120.1 tell 192.168.120.254, length 28
>         >         19:43:54.684214 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.120.1 tell 192.168.120.254, length 28
>         >         19:43:55.684218 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.120.1 tell 192.168.120.254, length 28
>         >         19:43:56.684232 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.120.1 tell 192.168.120.254, length 28
>         >         
>         >         
>         >         I hope this information is enough. If I can provide
>         >         anything else to help debug or test, please just
>         >         ask! ;)
>         >         
>         >         Thanks in advance,
>         >         Luís
>         >         
>         >         
>         >         > >
>         >         > > 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@lists.xensource.com
<mailto:Xen-devel@lists.xensource.com>
>         >         > >> >
http://lists.xensource.com/xen-devel
>         >         > >> >   
>         >         > >>
>         >         > >>
>         >         > >>
_______________________________________________
>         >         > >> Xen-devel mailing list
>         >         > >> Xen-devel@lists.xensource.com
<mailto:Xen-devel@lists.xensource.com>
>         >         > >> http://lists.xensource.com/xen-devel
>         >         > >>
>         >         > >>     
>         >         > >
>         >         > 
>         >         > 
>         >         
>         >         
>         >         
>         >         
>         >         -----Inline Attachment Follows-----
>         >         
>         >         _______________________________________________
>         >         Xen-users mailing list
>         >         Xen-users@lists.xensource.com
>         >         http://lists.xensource.com/xen-users
>         > 
>         
>         
>         
>         
>         
>         -----Inline Attachment Follows-----
>         
>         
>         _______________________________________________
>         Xen-users mailing list
>         Xen-users@lists.xensource.com
>         http://lists.xensource.com/xen-users
> 




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

Boris Derzhavets

2010-Jun-06 10:19 UTC

head link

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

Network issues when working with DomUs in 2.6.32.14 and finally been fixed,
seem to appear again in 2.6.32.15. Reverting to back to xen/stable - 2.6.32.10
works as a fix again.

Boris

--- On Thu, 6/3/10, Luís Silva <luis.silva@axiomasoft.pt> wrote:

From: Luís Silva <luis.silva@axiomasoft.pt>
Subject: Re: [Xen-users] Re: [Xen-devel] ARP problems with xen 4.0 with pvops
kernel
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "Jeremy Fitzhardinge" <jeremy@goop.org>,
xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Date: Thursday, June 3, 2010, 6:20 AM




  
  
Hello,


Thanks for the suggestion, xen/stable works ok for me. Only problem is that I
have to disable offload do get dhcp to work on domU, but the problem I described
before doesn''t exist in this kernel. Later today I''m going to
try a previous build I have based on stable-2.6.32.x (2.6.32.13) to check if it
already had this problem or not and I''ll post the results.


Luís


On Wed, 2010-06-02 at 12:26 -0700, Boris Derzhavets wrote:


    


Could you,please, build and try 2.6.32.10 ( xen/stable) ?


Boris.


--- On Wed, 6/2/10, Luís Silva <luis.silva@axiomasoft.pt> wrote:


    

    From: Luís Silva <luis.silva@axiomasoft.pt>

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

    To: "Jeremy Fitzhardinge" <jeremy@goop.org>

    Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com

    Date: Wednesday, June 2, 2010, 2:53 PM

    



    Hello,

    

    On Wed, 2010-06-02 at 09:06 -0700, Jeremy Fitzhardinge wrote: 
    
On 06/02/2010 01:47 AM, Luís Silva wrote:> 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...
Yes, ARP is a new twist on network problems.  I''m guessing
you''re using
hvm without stubdoms, which means that its networking originates from
qemu within dom0, whereas PV and HVM+stubdom comes via netback.


    
    Yes, when I mentioned hvm I was talking about hvm without stubdoms. I
haven''t tried those yet.
    
But aside from that, I''m stumped.  Are you running any firewalls on
either side?   Can you try disabling all the offloads (tx, rx, gso, tso)
on all the relevent interfaces (bridge, netback, within the guest) and
see if that changes anything?

    J


    
    

    Ok, this is the bridge interface:

    

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

ifconfig virbr0
virbr0    Link encap:Ethernet  HWaddr c2:ef:67:2b:a4:23  
          inet addr:192.168.120.254  Bcast:192.168.120.255  Mask:255.255.255.0
          inet6 addr: fe80::c0ef:67ff:fe2b:a423/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B) 
 TX bytes:4662 (4.6 KB)

    

    I''m not using firewall other than the rules defined by libvirt.
DomU has no firewall and the rules in dom0 are only these (virbr0 is natted to
the outside, virbr1 is routed. The result is the same in either one of them):
sudo iptables -L -n -v
Chain INPUT (policy ACCEPT 241K packets, 53M bytes)
 pkts bytes target     prot opt in     out     source              
destination        
    0     0 ACCEPT     udp  --  virbr1 *       0.0.0.0/0           
0.0.0.0/0           udp dpt:53
    0     0 ACCEPT     tcp  --  virbr1 *       0.0.0.0/0           
0.0.0.0/0           tcp dpt:53
 
    0     0 ACCEPT     udp  --  virbr1 *       0.0.0.0/0           
0.0.0.0/0           udp dpt:67
    0     0 ACCEPT     tcp  --  virbr1 *       0.0.0.0/0           
0.0.0.0/0           tcp dpt:67
    8   515 ACCEPT     udp  --  virbr0 *       0.0.0.0/0           
0.0.0.0/0           udp dpt:53
    0     0
 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0           tcp
dpt:53
    0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0           
0.0.0.0/0           udp dpt:67
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0           
0.0.0.0/0           tcp dpt:67

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot
 opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      virbr1  0.0.0.0/0           
192.168.121.0/24   
    0     0 ACCEPT     all  --  virbr1 *       192.168.121.0/24    
0.0.0.0/0          
    0     0 ACCEPT     all  --  virbr1 virbr1  0.0.0.0/0           
 0.0.0.0/0           
    0     0 REJECT     all  --  *      virbr1  0.0.0.0/0           
0.0.0.0/0           reject-with icmp-port-unreachable
    0     0 REJECT     all  --  virbr1 *       0.0.0.0/0           
0.0.0.0/0           reject-with icmp-port-unreachable
   13  3448 ACCEPT     all  --  *      virbr0  0.0.0.0/0           
192.168.120.0/24    state
 RELATED,ESTABLISHED 
   16  1374 ACCEPT     all  --  virbr0 *       192.168.120.0/24    
0.0.0.0/0          
    0     0 ACCEPT     all  --  virbr0 virbr0  0.0.0.0/0           
0.0.0.0/0          
    0     0 REJECT     all  --  *      virbr0  0.0.0.0/0           
0.0.0.0/0           reject-with icmp-port-unreachable
    0     0 REJECT     all  --  virbr0
 *       0.0.0.0/0            0.0.0.0/0           reject-with
icmp-port-unreachable

Chain OUTPUT (policy ACCEPT 233K packets, 27M bytes)
 pkts bytes target     prot opt in     out     source               destination

    

    

    And these are the various offload parameters as set at boot:

    

Offload parameters for virbr0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off

Offload parameters for vif1.0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off

Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: off
large-receive-offload: off

    

    To disable all checksuming I run the following commands:

    dom0: 
sudo ethtool -K virbr0 tx off sg off tso off gso off gro off
sudo ethtool -K vif1.0 tx off sg off tso off gso off gro off

    domU 
sudo ethtool -K eth0 tx off sg off tso off gso off gro off

    

    This managed to get all parameter to off in the mentioned interfaces, but
unfortunately the result is the same. The arp requests get to vif1.0, but not to
eth0 on the domU.

    

sudo tcpdump -i vif1.0 -n -vv arp
tcpdump: WARNING: vif1.0: no IPv4 address assigned
tcpdump: listening on vif1.0, link-type EN10MB (Ethernet), capture size 96 bytes
19:43:51.233378 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.1 tell 192.168.120.254, length 28
19:43:52.233164 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.1 tell 192.168.120.254, length 28
19:43:53.233166 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.1 tell 192.168.120.254, length 28
19:43:54.684214 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.1 tell 192.168.120.254, length 28
19:43:55.684218 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.1 tell 192.168.120.254, length 28
19:43:56.684232 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has
192.168.120.1 tell 192.168.120.254, length 28

    

    I hope this information is enough. If I can provide anything else to help
debug or test, please just ask! ;)

    

    Thanks in advance,

    Luís

    

    >
> 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@lists.xensource.com
<mailto:Xen-devel@lists.xensource.com>
>> > http://lists.xensource.com/xen-devel
>> >   
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
<mailto:Xen-devel@lists.xensource.com>
>> http://lists.xensource.com/xen-devel
>>
>>     
>


    
    

    



    

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

    



    _______________________________________________

    Xen-users mailing list

    Xen-users@lists.xensource.com

    http://lists.xensource.com/xen-users




    



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

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


      

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

Jeremy Fitzhardinge

2010-Jun-06 16:43 UTC

head link

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

On 06/06/2010 03:19 AM, Boris Derzhavets wrote:> Network issues when working with DomUs in 2.6.32.14 and finally been
> fixed,
> seem to appear again in 2.6.32.15. Reverting to back to xen/stable -
> 2.6.32.10
> works as a fix again.
>
There are no substantial differences between 2.6.32.14 and .15.  If
there are any differences in behaviour between them, then I''d suspect
some inconsistency from boot to boot, or in your kernel build process.

    J
>
> Boris
>
> --- On *Thu, 6/3/10, Luís Silva /<luis.silva@axiomasoft.pt>/* wrote:
>
>
>     From: Luís Silva <luis.silva@axiomasoft.pt>
>     Subject: Re: [Xen-users] Re: [Xen-devel] ARP problems with xen 4.0
>     with pvops kernel
>     To: "Boris Derzhavets" <bderzhavets@yahoo.com>
>     Cc: "Jeremy Fitzhardinge" <jeremy@goop.org>,
>     xen-devel@lists.xensource.com, xen-users@lists.xensource.com
>     Date: Thursday, June 3, 2010, 6:20 AM
>
>     Hello,
>
>     Thanks for the suggestion, xen/stable works ok for me. Only
>     problem is that I have to disable offload do get dhcp to work on
>     domU, but the problem I described before doesn''t exist in this
>     kernel. Later today I''m going to try a previous build I have
based
>     on stable-2.6.32.x (2.6.32.13) to check if it already had this
>     problem or not and I''ll post the results.
>
>     Luís
>
>     On Wed, 2010-06-02 at 12:26 -0700, Boris Derzhavets wrote:
>>     Could you,please, build and try 2.6.32.10 ( xen/stable) ?
>>
>>     Boris.
>>
>>     --- On *Wed, 6/2/10, Luís Silva
**/<luis.silva@axiomasoft.pt>/*
>>     wrote:
>>
>>
>>         From: Luís Silva <luis.silva@axiomasoft.pt>
>>         Subject: [Xen-users] Re: [Xen-devel] ARP problems with xen
>>         4.0 with pvops kernel
>>         To: "Jeremy Fitzhardinge" <jeremy@goop.org>
>>         Cc: xen-devel@lists.xensource.com,
xen-users@lists.xensource.com
>>         Date: Wednesday, June 2, 2010, 2:53 PM
>>
>>         Hello,
>>
>>         On Wed, 2010-06-02 at 09:06 -0700, Jeremy Fitzhardinge wrote:
>>>         On 06/02/2010 01:47 AM, Luís Silva wrote:
>>>         > 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...
>>>
>>>         Yes, ARP is a new twist on network problems.  I''m
guessing you''re using
>>>         hvm without stubdoms, which means that its networking
originates from
>>>         qemu within dom0, whereas PV and HVM+stubdom comes via
netback.
>>>
>>>                               
>>         Yes, when I mentioned hvm I was talking about hvm without
>>         stubdoms. I haven''t tried those yet.
>>>         But aside from that, I''m stumped.  Are you running
any firewalls on
>>>         either side?   Can you try disabling all the offloads (tx,
rx, gso, tso)
>>>         on all the relevent interfaces (bridge, netback, within the
guest) and
>>>         see if that changes anything?
>>>
>>>             J
>>>
>>>                               
>>
>>         Ok, this is the bridge interface:
>>
>>         brctl show
>>         bridge name	bridge id		STP enabled	interfaces
>>         virbr0		8000.feffffffffff	no		vif1.0
>>
>>         ifconfig virbr0
>>         virbr0    Link encap:Ethernet  HWaddr c2:ef:67:2b:a4:23  
>>                   inet addr:192.168.120.254  Bcast:192.168.120.255 
Mask:255.255.255.0
>>                   inet6 addr: fe80::c0ef:67ff:fe2b:a423/64 Scope:Link
>>                   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>                   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>                   TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
>>                   collisions:0 txqueuelen:0 
>>                   RX bytes:0 (0.0
>>          B) 
>>          TX bytes:4662 (4.6 KB)
>>                             
>>
>>
>>         I''m not using firewall other than the rules defined by
>>         libvirt. DomU has no firewall and the rules in dom0 are only
>>         these (virbr0 is natted to the outside, virbr1 is routed. The
>>         result is the same in either one of them):
>>
>>         sudo iptables -L -n -v
>>         Chain INPUT (policy ACCEPT 241K packets, 53M bytes)
>>          pkts bytes target     prot opt in     out     source          
destination
>>             0     0 ACCEPT     udp  --  virbr1 *       0.0.0.0/0       
0.0.0.0/0           udp dpt:53
>>             0     0 ACCEPT     tcp  --  virbr1 *       0.0.0.0/0       
0.0.0.0/0           tcp dpt:53
>>
>>          
>>             0     0 ACCEPT     udp  --  virbr1 *       0.0.0.0/0       
0.0.0.0/0           udp dpt:67
>>             0     0 ACCEPT     tcp  --  virbr1 *       0.0.0.0/0       
0.0.0.0/0           tcp dpt:67
>>             8   515 ACCEPT     udp  --  virbr0 *       0.0.0.0/0       
0.0.0.0/0           udp dpt:53
>>             0     0
>>
>>          ACCEPT     tcp  --  virbr0 *       0.0.0.0/0           
0.0.0.0/0           tcp dpt:53
>>             0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0       
0.0.0.0/0           udp dpt:67
>>             0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0       
0.0.0.0/0           tcp dpt:67
>>
>>         Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>>          pkts bytes target    
>>          prot
>>          opt in     out     source               destination         
>>             0     0 ACCEPT     all  --  *      virbr1  0.0.0.0/0       
192.168.121.0/24
>>             0     0 ACCEPT     all  --  virbr1 *       192.168.121.0/24
0.0.0.0/0
>>             0     0 ACCEPT     all  --  virbr1 virbr1  0.0.0.0/0
>>
>>          0.0.0.0/0           
>>             0     0 REJECT     all  --  *      virbr1  0.0.0.0/0       
0.0.0.0/0           reject-with icmp-port-unreachable
>>             0     0 REJECT     all  --  virbr1 *       0.0.0.0/0       
0.0.0.0/0           reject-with icmp-port-unreachable
>>            13  3448 ACCEPT     all  --  *      virbr0  0.0.0.0/0       
192.168.120.0/24
>>          state
>>          RELATED,ESTABLISHED 
>>            16  1374 ACCEPT     all  --  virbr0 *       192.168.120.0/24
0.0.0.0/0
>>             0     0 ACCEPT     all  --  virbr0 virbr0  0.0.0.0/0       
0.0.0.0/0
>>             0     0 REJECT     all  --  *      virbr0  0.0.0.0/0       
0.0.0.0/0           reject-with icmp-port-unreachable
>>             0     0 REJECT     all  -- 
>>          virbr0
>>          *       0.0.0.0/0            0.0.0.0/0           reject-with
icmp-port-unreachable
>>
>>         Chain OUTPUT (policy ACCEPT 233K packets, 27M bytes)
>>          pkts bytes target     prot opt in     out     source          
destination
>>                             
>>
>>
>>
>>         And these are the various offload parameters as set at boot:
>>
>>         Offload parameters for virbr0:
>>         rx-checksumming: on
>>         tx-checksumming: on
>>         scatter-gather: on
>>         tcp-segmentation-offload: on
>>         udp-fragmentation-offload: on
>>         generic-segmentation-offload: on
>>         generic-receive-offload: off
>>         large-receive-offload: off
>>
>>         Offload parameters for vif1.0:
>>         rx-checksumming: on
>>         tx-checksumming: on
>>         scatter-gather: on
>>         tcp-segmentation-offload: on
>>         udp-fragmentation-offload: off
>>         generic-segmentation-offload: on
>>         generic-receive-offload: off
>>         large-receive-offload: off
>>
>>         Offload parameters for eth0:
>>         rx-checksumming: on
>>         tx-checksumming: on
>>         scatter-gather: on
>>         tcp-segmentation-offload: on
>>         udp-fragmentation-offload: off
>>         generic-segmentation-offload: off
>>         generic-receive-offload: off
>>         large-receive-offload: off
>>                             
>>
>>
>>         To disable all checksuming I run the following commands:
>>         dom0:
>>
>>         sudo ethtool -K virbr0 tx off sg off tso off gso off gro off
>>         sudo ethtool -K vif1.0 tx off sg off tso off gso off gro off
>>                             
>>
>>         domU
>>
>>         sudo ethtool -K eth0 tx off sg off tso off gso off gro off
>>                             
>>
>>
>>         This managed to get all parameter to off in the mentioned
>>         interfaces, but unfortunately the result is the same. The arp
>>         requests get to vif1.0, but not to eth0 on the domU.
>>
>>         sudo tcpdump -i vif1.0 -n -vv arp
>>         tcpdump: WARNING: vif1.0: no IPv4 address assigned
>>         tcpdump: listening on vif1.0, link-type EN10MB (Ethernet),
capture size 96 bytes
>>         19:43:51.233378 ARP, Ethernet (len 6), IPv4 (len 4), Request
who-has 192.168.120.1 tell 192.168.120.254, length 28
>>         19:43:52.233164 ARP, Ethernet (len 6), IPv4 (len 4), Request
who-has 192.168.120.1 tell 192.168.120.254, length 28
>>         19:43:53.233166 ARP, Ethernet (len 6), IPv4 (len 4), Request
who-has 192.168.120.1 tell 192.168.120.254, length 28
>>         19:43:54.684214 ARP, Ethernet (len 6), IPv4 (len 4), Request
who-has 192.168.120.1 tell 192.168.120.254, length 28
>>         19:43:55.684218 ARP, Ethernet (len 6), IPv4 (len 4), Request
who-has 192.168.120.1 tell 192.168.120.254, length 28
>>         19:43:56.684232 ARP, Ethernet (len 6), IPv4 (len 4), Request
who-has 192.168.120.1 tell 192.168.120.254, length 28
>>                             
>>
>>
>>         I hope this information is enough. If I can provide anything
>>         else to help debug or test, please just ask! ;)
>>
>>         Thanks in advance,
>>         Luís
>>
>>>         >
>>>         > 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@lists.xensource.com
<mailto:Xen-devel@lists.xensource.com>
<mailto:Xen-devel@lists.xensource.com>
>>>         >> > http://lists.xensource.com/xen-devel
>>>         >> >   
>>>         >>
>>>         >>
>>>         >> _______________________________________________
>>>         >> Xen-devel mailing list
>>>         >> Xen-devel@lists.xensource.com
<mailto:Xen-devel@lists.xensource.com>
<mailto:Xen-devel@lists.xensource.com>
>>>         >> http://lists.xensource.com/xen-devel
>>>         >>
>>>         >>     
>>>         >
>>>
>>>
>>>                               
>>
>>
>>
>>         -----Inline Attachment Follows-----
>>
>>         _______________________________________________
>>         Xen-users mailing list
>>         Xen-users@lists.xensource.com
>>         http://lists.xensource.com/xen-users 
>>
>>
>
>
>     -----Inline Attachment Follows-----
>
>     _______________________________________________
>     Xen-users mailing list
>     Xen-users@lists.xensource.com
>     </mc/compose?to=Xen-users@lists.xensource.com>
>     http://lists.xensource.com/xen-users
>
>

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

Maybe Matching Threads

Search for more maybe matching threads

Xen users - Jun 2010 - ARP problems with xen 4.0 with pvops kernel

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Maybe Matching Threads