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

[Adrian Chadd <adrian@xxxxxxxxxxxxxxx>]

On Wed, Aug 16, 2006, Sylvain Coutant wrote:
> > So when configuring a VLAN on an interface, you say that Linux
> > automatically adds 4 to the MTU of the underlying physical interface?
> > 
> > Since Linux has no way of synchronizing the MTU with the interface at
> > the other end of the wire, that's really stupid.  It should just lower
> > the MTU of the virtual interface by 4 bytes instead.
> 
> No, that would also be stupid in some way. The goal is each interface have 
> the same mtu on each side.
> If you some have a 1500 bytes mtu interface without tagging at the other end 
> of the Ethernet segment (I mean the switch removes the tag before sending the 
> packet to the other computer), you would then have different mtu sizes (1496 
> on one side and 1500 on the other).
> 
> It is usual to manage oversized Ethernet frames when dealing with tags. So 
> you keep a basic mtu of 1500 and add a varying size Ethernet header to this. 
> Your Ethernet packet will then be something *starting at* 1518 (with a basic 
> header). In the case of 802.1q tagging, it will be larger. This is the way 
> you ensure each ethernet interface has the same mtu at each end.

Just in case people are unclear (and some people are):

The MTU in "ifconfig eth0" is the ethernet payload MTU. This is set to be 1500 
bytes.
The VLAN header in 802.1q isn't, IIRC, part of the definition of "payload".
This is why the underlying VLAN implementation will (should!) raise the ethernet
frame size by 4 bytes; so the 1500 byte payload (which can be IP, IPv6, IPX, 
etc)
will fit.

The goal of having matching MTUs at both ends is because PMTU discovery
and IP fragmentation happens at Layer 3, not ethernet (layer 2). If your
Layer 3 knows the MTU is smaller then yes, one end can send back an ICMP
Frag Required and PMTU can kick in. If the MTU on one end is different
to the other then the losses occur at the Layer 2, not Layer 3. IP doesn't
get told the packet dropped; a counter may or may not be incremented
on some interface and traffic mysteriously disappears.

The correct solution is allowing >1518 byte ethernet frames to accomodate
whatever extra fruit may pop up in the ethernet specification (such as 802.1q.)




Adrian


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