Jean-Grégoire Foulon wrote:
Hello,
I am currently working with multiple Vlan stacking and the behaviour of
QinQ in the kernel is not always consistent. On some hardware I have to
use set the reorder flag to 0 for the QinQ to be working, while on
other, it just work whether this flag is 1 or 0.
I tested with the Fedora core 7 (kernel 2.6.21) on the following machines
Dell PC with Intel Corporation 82540EM Gigabit Ethernet Controller (rev 02)
Compaq laptop with Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
(rev 10)
As I understand it the only reason you would set the reorder flag to 0 is
if you have two vlan devices, using the same VID, connected to a bridge.
E.g.
br0
|- eth0.10
|- eth1.10
In this situation there's no need to strip the tags going up, or add tags going
down because all the interfaces are tagged and have the same VID. (However, if
you wanted to connect br0 to the IP stack you would have to create br0.10 and
leave reordering enabled on *that* vlan device.)
In other situations, e.g.
br0
|- eth0.10
|- eth1
or
br0
|- eth0.10
|- eth1.11
you would need to leave reordering on for both vlan devices.
So disabling reordering saves a few clocks, but is only valid in a few circumstances.
Someone please correct me if I've misunderstood this!
On the Dell, I don't need to set the reorder flag to 0 but on the Compaq
I need to do it.
Another even stranger thing is that on kernel 2.6.9 I need to set the
reorder flag to 0 if I want to stack 3 VLAN but I don't need to do it
when I stack only 2 VLAN...
What is the default behaviour ? Is there a bug for the support of one of
those network adapter ?
is QinQ officially supported by the Linux kernel ? Someone posted a
patch for 2.6.11, is it needed for 2.6.21 ?
A patch is still needed, but I've got no idea if the one I sent will still apply
cleanly to 2.6.21. Try it out!
The other problem I have is the fragmentation and MTU behaviour: the MTU
of a vlan device is the same as the MTU of its ethernet device (1500 in
my case), I think it should be less to reflect the size use by the vlan
header, no ?
When I use the command "ping -t 2000 <ip address>":
-on a network interface : it works
-on a level 1 vlan: it works
-on a level 2 or higher vlan: it fails
When I use the command "ping -t 1468 <ip address>":
-on a network interface : it works
-on a level 1 vlan: it works
-on a level 2 vlan: it works
-on a level 3 vlan: it fails
When I use the command "ping -t 1464 <ip address>":
-on a network interface : it works
-on a level 1 vlan: it works
-on a level 2 vlan: it works
-on a level 3 vlan: it works
A level 3 vlan has a maximum packet size 4 bytes smaller than a level 2
vlan.
When I change the MTU manually the "ping -t 2000 <ip address>" command
works on level 3 vlan, so it should make sense to reduce it when a VLAN
device is created, no ?
I am trying to modify a 2.4 kernel to do so, and it seems to work, may I
by breaking something else ?
Some ethernet drivers implement a change_mtu() method, and use the MTU size passed
in (from ifconfig <dev> mtu <size>) to set the maximum rx frame size. Others
just have a fixed maximum rx frame size and leave it to the IP stack to police the
MTU sizes.
If a driver is not vlan aware it may set a fixed maximum rx frame size of 1518, or
- if it implements change_mtu() - a maximum rx frame size of mtu + 18.
If a driver *is* vlan aware it will add 4 to the above, as it knows that the frames
may have an extra 4 byte shim that gets stripped by the vlan layer before the frame
enters the IP stack.
For a driver to be q-in-q aware it will need to add 4*(max q-in-q levels). I doubt
any drivers are q-in-q aware as q-in-q support isn't in the current kernel. You'll
probably have to hack'em.
Regards,
Jean-Gregoire
HTH,
Alex
_______________________________________________
Vlan mailing list
Vlan@xxxxxxxxxxxxxxx
http://www.candelatech.com/mailman/listinfo/vlan
