Re: Default QinQ behaviour for MTU and REORDER flag
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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 worksA 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.
HTH, Alex _______________________________________________ Vlan mailing list Vlan@xxxxxxxxxxxxxxx http://www.candelatech.com/mailman/listinfo/vlan
[Netdev] [Ethernet Bridging] [Linux Wireless] [Kernel Newbies] [Security] [Linux for Hams] [Netfilter] [Bugtraq] [Photo] [Yosemite] [Yosemite News] [MIPS Linux] [ARM Linux] [Linux RAID] [Linux Admin] [Samba] [Video 4 Linux] [Linux Resources]