[VLAN] Patch for vlan stacking/q-in-q support

Alex Zeffertt ajz at cambridgebroadband.com
Mon Aug 20 08:51:56 PDT 2007


Dylan Hall wrote:
> I've been trying to get vlan stacking (q in q) going and have produced a 
> small patch that seems to make it work for me:
> 
> diff -Naur linux-2.6.20.4/net/8021q/vlan_dev.c 
> linux-2.6.20.4-qinq/net/8021q/vlan_dev.c
> --- linux-2.6.20.4/net/8021q/vlan_dev.c 2007-03-24 07:52:51.000000000 +1200
> +++ linux-2.6.20.4-qinq/net/8021q/vlan_dev.c    2007-07-30 
> 11:50:49.000000000 +1200
> @@ -445,7 +445,6 @@
>          * OTHER THINGS LIKE FDDI/TokenRing/802.3 SNAPs...
>          */
> 
> -       if (veth->h_vlan_proto != __constant_htons(ETH_P_8021Q)) {
>                 int orig_headroom = skb_headroom(skb);
>                 unsigned short veth_TCI;
> 
> @@ -474,7 +473,6 @@
>                 if (orig_headroom < VLAN_HLEN) {
>                         VLAN_DEV_INFO(dev)->cnt_inc_headroom_on_tx++;
>                 }
> -       }
> 
> #ifdef VLAN_DEBUG
>         printk(VLAN_DBG "%s: about to send skb: %p to dev: %s\n",
> 
> 
> The patch is against 2.6.20.4.
> 
> My test setup looked something like:
> 
> vconfig set_name_type DEV_PLUS_VID_NO_PAD
> ip link set eth1 up
> vconfig add eth1 100
> ip link set eth1.100 up
> vconfig add eth1.100 50
> ip link set eth1.100.50 up
> ip a add 10.100.50.1/24 dev eth1.100.50
> ip link set eth1.100.50 mtu 1500
> 
> followed by pinging an imaginary device on the same subnet and using 
> tcpdump to observe what is sent.
> 
> What I was seeing is the above would produce packets with vlan id 50 
> (inner vlan) but the outer tag wasn't being inserted. These tests were 
> carried out using an e100 and a natsemi interface.
> 
> I repeated the tests with an e1000 which has hardware accelerated vlan 
> support. This second test did work, with the caveat that tcpdump on the 
> sender doesn't show the second tag, but tcpdump on a remote machine does.
> 
> This struck me as a little odd, so I had a poke around at the kernel 
> source. It would appear that the routine vlan_dev_hard_start_xmit, which 
> does the actual tag insertion for non-hardware accelerated interfaces 
> only inserts the tag if one is not already present. Removing this check 
> (e.g. always insert the tag) seems to work nicely for me :)
> 
> 
> So my questions are:
> 
> What might I break be removing this test?

Bridges with multiple vlan interfaces (same VID) where the REORDER flag
has be unset (default is set).

> Is there a smarter/better way of doing this?
> Can this, or a similar fix be made part of the code for future kernel 
> releases?
> 

We've discussed this before.  Try following this thread:

	http://osdir.com/ml/linux.drivers.vlan/2005-07/msg00046.html

BTW, this works for us!

Alex

> 
> Thanks,
> 
> Dylan
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Vlan mailing list
> Vlan at candelatech.com
> http://www.candelatech.com/mailman/listinfo/vlan



More information about the Vlan mailing list