On Tue, 29 Mar 2011 21:47:09 +0200 Jiri Pirko wrote: > Tue, Mar 29, 2011 at 09:18:44PM CEST, andy@xxxxxxxxxxxxx wrote: > >On Tue, Mar 29, 2011 at 2:36 PM, Jiri Pirko <jpirko@xxxxxxxxxx> wrote: > >> Tue, Mar 29, 2011 at 06:54:58PM CEST, andy@xxxxxxxxxxxxx wrote: > >>>On Mon, Mar 28, 2011 at 1:54 PM, igor serebryany <igor47@xxxxxxxxxxx> wrote: > >>>> it appears that 802.1q tagging is broken in 2.6.38 when combined with bridging. > >>>> here is how to reproduce the problem: > >>>> > >>>> i set up an interface for the machine running 2.6.38 on my cisco router, and > >>>> assign a subnet to that interface. i am using ping from the router to do the > >>>> testing. i am getting all the data here with 'tcpdump -e -n' from the machine. > >>>> > >>>> i ping the machine from the router, and i see properly-tagged ARP requests > >>>> coming in on eth0: > >>>> > >>>> 12:12:05.052465 00:11:20:dd:81:00 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q > >>>> (0x8100), length 64: vlan 234, p 0, ethertype ARP, Request who-has 10.0.0.206 > >>>> tell 10.0.0.205, length 46 > >>>> > >>>> i then create a vlan interface on the machine: > >>>> > >>>> vconfig add eth0 234 > >>>> ifconfig eth0.234 up > >>>> > >>>> i tcpdump the newly-created interface, and i see the arp packets appearing on > >>>> it, now properly untagged > >>>> > >>>> 12:14:33.549939 00:11:20:dd:81:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), > >>>> length 60: Request who-has 10.0.0.206 tell 10.0.0.205, length 46 > >>>> > >>>> if i assign an ip to this interface, i can see pings being exchanged on eth0.234 > >>>> > >>>> 12:17:12.681079 00:11:20:dd:81:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), > >>>> length 60: Request who-has 10.0.0.206 tell 10.0.0.205, length 46 > >>>> 12:17:12.681090 00:30:48:fd:98:d8 > 00:11:20:dd:81:00, ethertype ARP (0x0806), > >>>> length 42: Reply 10.0.0.206 is-at 00:30:48:fd:98:d8, length 28 > >>>> 12:17:14.682076 00:11:20:dd:81:00 > 00:30:48:fd:98:d8, ethertype IPv4 (0x0800), > >>>> length 114: 10.0.0.205 > 10.0.0.206: ICMP echo request, id 24, seq 1, length 80 > >>>> 12:17:14.682088 00:30:48:fd:98:d8 > 00:11:20:dd:81:00, ethertype IPv4 (0x0800), > >>>> length 114: 10.0.0.206 > 10.0.0.205: ICMP echo reply, id 24, seq 1, length 80 > >>>> > >>>> now, i want to assign eth0 to a bridge > >>>> > >>>> brctl addbr xenbr0 > >>>> ifconfig xenbr0 up > >>>> brctl addif xenbr0 eth0 > >>>> > >>>> i now attempt to ping the machine again. watching tcpdump on eth0.234, i don't > >>>> see any of my packets anymore! > >>>> > >>>> instead, if i watch xenbr0 with tcpdump, i can see the tagged packets being > >>>> dumped straight into xenbr0, without the vlan tags stripped out! > >> > >> Yep, that seems expected. rx_handler for bridge is earlier in rx path > >> than vlan processing. This is was not changed in 2.6.38. This is with us > >> for a long time. I plan to refuse this topo in future (not sure yet > >> thought) > >> > > > >I have no idea what version Igor was using before. Even if Igor's > >upgrade as not from 2.6.37, this sounds like a regression. > > Well, one commit I'm thinking of which might cause this "regression" > (athought I do not see that as one) is this: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3701e51382a026cba10c60b03efabe534fba4ca4 > > cc'ing Jesse. > > Anyway. I think that on non-hw-accel vlans this is the same all the > time as it is now. It is possible to make this configuration work again by adding ebtables rules - an example is given in the bridge-nf FAQ (http://ebtables.sourceforge.net/misc/brnf-faq.html): ebtables -t broute -A BROUTING -i eth0 --vlan-id 15 -j DROP This sends traffic for VLAN 15 coming from eth0 to the VLAN code instead of bridge, so that it would be properly received on eth0.15. Or you can add a rule which handles any VLAN-tagged traffic: ebtables -t broute -A BROUTING -i eth0 -p 802_1Q -j DROP This was required even for kernels before 2.6.37, but only if the network card did not have VLAN RX acceleration support; VLAN hw-accel code in those kernels handled tagged packets before the bridge code. The commit mentioned above (present in mainline since 2.6.37-rc1) made the behavior for hw-accel and non-hw-accel cases identical - now ebtables rules are required for all kinds of cards.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/bridge
