From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: mdlabriola@yahoo.com, zary@cvtisr.sk
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: [mdlabriola@yahoo.com: Re: Re: [Xen-users] DomU routed traffic disappearing in vif.]
Date: Mon, 10 May 2010 11:18:35 -0400 [thread overview]
Message-ID: <20100510151835.GG29517@phenom.dumpdata.com> (raw)
> On Sat, 2010-05-08 at 02:53 +0200, Matej Zary wrote:
> > Hello,
> >
> >
> > XEN 4.0 with pvops 2.6.32.11 Dom0 kernel. Configured PV DomU with the same pvops Xen kernel on top of it.
> >
> > Physical computers has 3 NICs - every NIC in own bridge (first one created by Xen).
> >
> > eth0 8000.00138fe78f1b no peth0
> > mst1 8000.0040f4b5286e no eth1
> > vif5.0
> > mst2 8000.000e2e68db10 no eth2
> > vif5.1
> >
> > Attached 2 virtual NICs to the PV DomU and bridges - I want to use that DomU as router between that two bridges (enabled ip_forwarding in DomU) - mst1 and mst2.
> >
> > I can ping from netwok on eth1 the vif5.0 interface.
> > I can ping from network on eth2 the vif5.1 interface.
> > I can see with tcpdump, that the DomU routes the traffic between its eth0 and eth1 interfaces (tcpdump inside the domu).
> > I can see with tcpdump the incoming traffic in mst1 and vif5.0.
> > But there's nothing on the vif5.1and mst2 bridge - even when tcpdump on the eth1 in that PV DomU shows the routed traffic ("works" the same in opposite direction too).
> >
> > Looks like all traffic routed by that PV DomU cant't get from DomU eth interface to the vif interface. Ping from the DomU works (non routed traffic), but no routed traffic can get thu this Dom0.
> >
> > IPltables flushed with -F
> >
> > Thanks for every idea, i'm clueless right now. :(
> >
> > Regars
> >
> > Matej
>
> Well, it's the dreaded cksum incorrect error (and Real(BAD)tek PCI
> NICs). Tried to set off the tx check-summing on all interfaces (eth
> interfaces in DomU, eth and bridge interfaces in Dom0) with ethtool -K
> iface tx off, and it changed the situation a little bit - now are these
> packets with incorrect checksum visible on the outgoing eth2 physical
> NIC in the mst2 bridge and also on physical host in the physical network
> connected to mst2 bridge via the eth2 NIC. Final result ist still the
> same, physical hosts routed via the DomU can't communicate (now they are
> getting packets with wrong checksum at least :D).
>
> Any chances that newer pv_ops kernel that the 2.6.32.11 (git stable)
> version will solve this issue? Or I have to switch to the 2.6.18 and the
> forwardported oldstyle kernels?
Ian had a patch that he backported from XCP that might fix this, not
sure thought. Jeremy is trying it out but he ran in some other issues
(pvgrub messing up UDP checksums). Stay tuned.
next reply other threads:[~2010-05-10 15:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-10 15:18 Konrad Rzeszutek Wilk [this message]
2010-05-10 15:32 ` [mdlabriola@yahoo.com: Re: Re: [Xen-users] DomU routed traffic disappearing in vif.] Ian Campbell
2010-05-10 17:17 ` Michael D Labriola
2010-05-10 19:21 ` Michael D Labriola
2010-05-11 0:43 ` Re: [mdlabriola@yahoo.com: [Xen-devel] Re: " Matej Zary
2010-05-11 8:39 ` Re: [mdlabriola@yahoo.com: Re: Re: [Xen-users] " Ian Campbell
2010-05-11 13:33 ` Re: [mdlabriola@yahoo.com: [Xen-devel] Re: " Konrad Rzeszutek Wilk
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=20100510151835.GG29517@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=mdlabriola@yahoo.com \
--cc=xen-devel@lists.xensource.com \
--cc=xen-users@lists.xensource.com \
--cc=zary@cvtisr.sk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.