Xen devel - Sep 2011 - bug in vlan offload in dom0 3.0.0 kernel?

I''ve just upgraded some dom0''s to 3.0.0 (debian kernel) and
now my
vlan''s aren''t working properly. Traffic is transmitted and
other devices
on that vlan see that traffic, and the xen machine sees the tagged
response on eth0 but the packet never makes it onto eth0.2 (vlan2). My
setup is this:

br-wan
    eth0.2 - physical network interface
    vif1.0 - virtual backend interface for vm

Here''s an attempt to describe what I''m seeing for transmit:

vm eth0 - untagged packet
xen vif1.0 - untagged packet
xen br-wan - untagged packet
xen eth0.2 - untagged packet
xen eth0 - tagged packet
|
router eth0 - tagged packet
router eth0.2 - untagged packet

That all looks fine. The packets are tagged inside the vlan interface
and then tagged once they appear on the physical trunk. For receive:

router eth0.2 - untagged packet
router eth0 - tagged packet
| 
xen eth0 - tagged packet
xen eth0.2 - nothing

The nics are Intel dual port gigabit adapters - 82576. There is at least
one bug report describing similar behaviour to the above but that was
back in 2.6.x.

Has anyone else seen this problem? And more importantly, might vswitch
solve some of the above problems?

Thanks

James

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

On Thu, Sep 29, 2011 at 10:33:44AM +1000, James Harper
wrote:
> I''ve just upgraded some dom0''s to 3.0.0 (debian kernel)
and now my
From?
> vlan''s aren''t working properly. Traffic is transmitted
and other devices
> on that vlan see that traffic, and the xen machine sees the tagged
> response on eth0 but the packet never makes it onto eth0.2 (vlan2). My
> setup is this:
> 
> br-wan
>     eth0.2 - physical network interface
>     vif1.0 - virtual backend interface for vm
> 
> Here''s an attempt to describe what I''m seeing for
transmit:
> 
> vm eth0 - untagged packet
> xen vif1.0 - untagged packet
> xen br-wan - untagged packet
> xen eth0.2 - untagged packet
> xen eth0 - tagged packet
> |
> router eth0 - tagged packet
> router eth0.2 - untagged packet
> 
> That all looks fine. The packets are tagged inside the vlan interface
> and then tagged once they appear on the physical trunk. For receive:
> 
> router eth0.2 - untagged packet
> router eth0 - tagged packet
> | 
> xen eth0 - tagged packet
> xen eth0.2 - nothing
> 
> The nics are Intel dual port gigabit adapters - 82576. There is at least
> one bug report describing similar behaviour to the above but that was
> back in 2.6.x.
> 
> Has anyone else seen this problem? And more importantly, might vswitch
> solve some of the above problems?
So.. just since that is probably the first thing you should have checked for,
but did your turn checksumming off?

> 
> Thanks
> 
> James
> 
> _______________________________________________
> 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

> On Thu, Sep 29, 2011 at 10:33:44AM +1000, James Harper wrote:
> > I''ve just upgraded some dom0''s to 3.0.0 (debian
kernel) and now my
> 
> From?
>From 2.6.32 pvops
> > Has anyone else seen this problem? And more importantly, might
vswitch
> > solve some of the above problems?
> 
> So.. just since that is probably the first thing you should have
checked for,
> but did your turn checksumming off?
> 
Yes, even with all offloads turned off this is still broken. Google
tells me that I''m not the only one having this problem and it sounds
like it''s the igb driver that is broken wrt the new vlan offload code.
It was a known bug around 2.6.37 and just hasn''t been fixed yet.

I''ve worked around the problem by using openvswitch which works because
it doesn''t use vlan offload it handles the trunking internally. I had
to
increase the MTU on the eth0 interface to 1504 and had to write a brctl
compatibility script (the ''brctl compatibility layer'' in
openvswitch
doesn''t show internal bridges correctly in the output of show) but
other
than that it is now working mostly fine.

The only problem is that the tapN interfaces get added to the bridge on
DomU startup but don''t get removed from the database on shutdown. The
reason they don''t get removed is that because the PCI device is
unplugged when the PV drivers take over, the shutdown code isn''t fired
for that interface. Under brctl it didn''t matter because the kernel
handled removing an interface when it went away. That''s only cosmetic
though.

James

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