[Xen-devel] Problem with 802.1Q tagging in Xen domain 0. (May be HW vlan acceleration related?)

[Igor Chubin <igor@xxxxxxx>]

Hello, list!



I have Xen dom 0 with several network interfaces.
I want to use 802.1Q VLAN's on one of the interfaces.



If I don't use xenbr0 (fig.1)
all works fine.



                     eth0    .---- eth0   VLAN1 [10.0.1.20]
============================<----- eth0.2 VLAN2 [10.0.2.20]
(tagged)                     .____ eth0.3 VLAN3 [10.0.3.20]

Figure 1.



      peth0 +------+ eth0    .---- eth0   VLAN1 [10.0.1.20]
============|xenbr0|========<----- eth0.2 VLAN2 [10.0.2.20]
(tagged)    +------+         .____ eth0.3 VLAN3 [10.0.3.20]

Figure 2.




But when I add the bridge xenbr0 (using network-bridge script)
only untagged interface (VLAN1, 10.0.1.20) works properly.



In instance,  I try to ping outside host 10.0.3.5 from 10.0.3.20 (VLAN3).
I have no responses.

During the pinging process I look into the peth0 (or xenbr0)
interface using tcpdump:


$ sudo tcpdump -i peth0 -e -n  arp
tcpdump: WARNING: peth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on peth0, link-type EN10MB (Ethernet), capture size 96 bytes
11:09:17.755752 00:16:3e:00:04:10 > 00:30:48:85:df:64, ethertype ARP (0x0806), 
length 56: arp reply 10.0.3.5 is-at 00:16:3e:00:04:10
11:09:18.763945 00:16:3e:00:04:10 > 00:30:48:85:df:64, ethertype ARP (0x0806), 
length 56: arp reply 10.0.3.5 is-at 00:16:3e:00:04:10
11:09:19.763942 00:16:3e:00:04:10 > 00:30:48:85:df:64, ethertype ARP (0x0806), 
length 56: arp reply 10.0.3.5 is-at 00:16:3e:00:04:10
11:09:20.764029 00:16:3e:00:04:10 > 00:30:48:85:df:64, ethertype ARP (0x0806), 
length 56: arp reply 10.0.3.5 is-at 00:16:3e:00:04:10


As you can see there are ARP-replyes, but there are no 802.Q tags in it!


The tags present in ARP-queries
(I have used tcpdump filter "vlan 3". 
You may notice also that tcpdump doesn't show replyes 
-- as you know for this moment -- replyes are not tagged):

$ sudo tcpdump -i xenbr0 -e -n vlan 3 
tcpdump: WARNING: xenbr0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tagged0, link-type EN10MB (Ethernet), capture size 96 bytes
10:59:32.790896 00:30:48:85:df:64 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q 
(0x8100), length 46: ethertype ARP, arp who-has 10.0.3.5 tell 10.0.3.20
10:59:34.791017 00:30:48:85:df:64 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q 
(0x8100), length 46: ethertype ARP, arp who-has 10.0.3.5 tell 10.0.3.20
10:59:35.791081 00:30:48:85:df:64 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q 
(0x8100), length 46: ethertype ARP, arp who-has 10.0.3.5 tell 10.0.3.20
10:59:36.791144 00:30:48:85:df:64 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q 
(0x8100), length 46: ethertype ARP, arp who-has 10.0.3.5 tell 10.0.3.20



I think that my problem is related to hardware VLAN acceleration
of Broadcom card.


The card model:
%# lspci | grep -i broadcom
04:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5721 Gigabit 
Ethernet PCI Express (rev 11)
05:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5721 Gigabit 
Ethernet PCI Express (rev 11)


$ sudo modinfo tg3
filename:       /lib/modules/2.6.18-4-xen-686/kernel/drivers/net/tg3.ko
author:         David S. Miller (davem@xxxxxxxxxx) and Jeff Garzik 
(jgarzik@xxxxxxxxx)
description:    Broadcom Tigon3 ethernet driver
license:        GPL
version:        3.65
vermagic:       2.6.18-4-xen-686 SMP mod_unload 686 REGPARM gcc-4.1


Is there any way to switch HW acceleration off (at least for debug purposes)?


May be the issue is not related to VLAN acceleration, 
but I'm sure that it is related to Broadcom card and tg3 at least.


I've noticed that my problem (or problem that is very close to mine) 
was discussed in this lists two months ago. 
"[Xen-devel] Problem with VLANs on tg3 NICs"
http://lists.xensource.com/archives/html/xen-devel/2007-01/msg00804.html


As far as I can judge the problem is not solved for the present.


Please tell me, 
is there are any ways to solve or bypass the problem?

Is this possible to fix tg3 driver? 
Or fix tg3 driver in this case is silly idea.


Thank you for any ideas!


-- 
WBR, i.m.chubin


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