Re: [Xen-users] Re: [Xen-devel] Ethernet MTU

[Javier Guerra <javier@xxxxxxxxxxx>]

On Wednesday 16 August 2006 6:58 am, Molle Bestefich wrote:
> B) Use another type of switch/bridge, call it "intelligent switch" or
> "VLAN switch" or whatever, which can inspect into the IP layer of
> frames carrying IP packets and fragment them accordingly.
>
> Does that exist?

there are "layer 3" switches, that do some limited IP routing.

> > For 802.1q, Linux normally does some trickery where the MTU is bumped up
> > by 4 when a tag is involved, but as far as userspace is concerned the
> > MTU is always 1500 whether it's a native or tagged packet.
>
> So when configuring a VLAN on an interface, you say that Linux
> automatically adds 4 to the MTU of the underlying physical interface?

no, there's nothing automatic on this. in fact, the kernel, the available 
patches, and the usual workarounds have it all wrong (IMNSHO)

let me go at the beginning of the problem.

1) ethernet frames were usually limited to 1536 bytes (1.5k, weird number).

2) the ethernet frame header+checksum used to be 36 bytes

3) the MTU of ethernet available to the next layer (IP, usually) is usually 
1500 bytes

3) most ethernet cards have a frame buffer of at least 2k, and either have a 
settable parameter usually put at 1536 (but could go up to 2048), or some 
don't reject any frame and rely on the kernel to drop them.

4) almost all linux eth drivers (i've read 3com, intel, realtek, and a few 
more) reject all frames larger than MTU+36. that 36 is a hard-coded number. 
not even a #define, it's a '36' right on the code.

5) an 802.1q tag uses 4bytes more on the ethernet header. it's not an IP 
thing, it's at ethernet level, therefore, on a tagged interface the header 
isn't 36 bytes, it's now 40bytes

6) if you set the MTU to 1500 as usual, you want to accept 1540byte frames, no 
problem for almost any card out there.

7) when you set the MTU at 1500, the linux drivers will reject any 1540byte 
frames, long before going to the 802.1q code.

8) the suggested workaround is to set the 'physical' interface's MTU to 1504 
and the 'split' MTU to 1500.  note that you shouldn't do any IP on the 
physical interface, since you don't really have space to put a 1504byte IP 
packet

9) most of the non-jumboframe-capable drivers have a hard limit at MTU 1500 
(at least the 3com has this), there are some 'old' pages that suggest how to 
teak the code to allow MTU of 1504. last time i checked, (2.6.11, i think) 
the mainline kernel doesn't have this.

that's it, a whole mess.  in my case, i wanted to split the network on VLANs, 
and connect them with by a software bridge that lets me filter the traffic 
while using one single IP space.  using GigE i set eth0's MTU to 1504 (no 
problem for a jumbo-frame capable driver), and MTU1500 on eth0.1, eth0.2, etc  
works perfectly, but shouldn't be that way.

ideally, the drivers should put the maximum frame allowable at MTU+ETHHEADER, 
where ETHHEADER would be usually 36, but go to 40 if using 802.1q.


-- 
Javier

Attachment: pgpJlIdjB4_kQ.pgp
Description: PGP signature

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