From: "Luís Silva" <luis.silva@axiomasoft.pt>
To: Boris Derzhavets <bderzhavets@yahoo.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-users] Re: ARP problems with xen 4.0 with pvops kernel
Date: Thu, 03 Jun 2010 11:20:24 +0100 [thread overview]
Message-ID: <1275560425.23424.4.camel@luis-port> (raw)
In-Reply-To: <83243.28786.qm@web56103.mail.re3.yahoo.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 18062 bytes --]
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
>
[-- Attachment #1.1.2: Type: text/html, Size: 21497 bytes --]
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2010-06-03 10:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-02 0:38 ARP problems with xen 4.0 with pvops kernel Luís Silva
2010-06-02 1:20 ` Jeremy Fitzhardinge
2010-06-02 8:47 ` [Xen-devel] " Luís Silva
2010-06-02 16:06 ` Jeremy Fitzhardinge
2010-06-02 18:53 ` Luís Silva
2010-06-02 19:26 ` Re: [Xen-devel] " Boris Derzhavets
2010-06-03 10:20 ` Luís Silva [this message]
2010-06-03 10:59 ` Boris Derzhavets
2010-06-03 23:18 ` [Xen-users] " Luís Silva
2010-06-06 10:19 ` Re: [Xen-devel] ARP problems with xen 4.0 with pvops kernel 2.6.32.15 Boris Derzhavets
2010-06-06 16:43 ` [Xen-users] " Jeremy Fitzhardinge
2010-06-02 7:09 ` ARP problems with xen 4.0 with pvops kernel Boris Derzhavets
2010-06-02 7:10 ` Sander Eikelenboom
2010-06-02 8:00 ` [Xen-users] " Boris Derzhavets
2010-06-03 9:35 ` Boris Derzhavets
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1275560425.23424.4.camel@luis-port \
--to=luis.silva@axiomasoft.pt \
--cc=bderzhavets@yahoo.com \
--cc=jeremy@goop.org \
--cc=xen-devel@lists.xensource.com \
--cc=xen-users@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).