Re: vlan with higher MTU (jumbo frame) than underlying Ethernet interface

[Erik Fair <fair%NetBSD.org@localhost>]

On Sep 7, 2012, at 12:53, Manuel Bouyer wrote:

> On Fri, Sep 07, 2012 at 11:21:11AM -0700, Erik Fair wrote:
>> NetBSD's documentation doesn't say explicitly: can one have a vlan interface 
>> with a jumbo frame MTU (e.g. 9000), on top of an Ethernet interface which 
>> supports jumbo frames, but whose MTU (1500) has not be adjusted up?
> 
> No, I think the underlying interface needs to have the hightest MTU of all
> vlans.

> But you can have another vlan(4) interface with 1500 MTU

Unfortunately, that's backwards: for network booting (SFAIK, no system firmware 
supports or uses jumbo frames - it's an unsafe assumption), and for systems 
that don't support jumbo frames to be on the same LAN, you need those to be on 
the non-vlan'd network (no VIDs) and everything configured so that no one sends 
or broadcasts any packets to them bigger than the standard MTU.

The configuration I have in mind is that the vlan have jumbo frames (vlans need 
larger than standard MTU anyway, even if only a few bytes for the VID), and 
only those hosts that can support it will configure it. That way, those 
(consenting) hosts could jumbo away at each other, but would be sending 
standard MTU packets to "everyone else" on the same LAN, with no VID and a 
different IP network address.

Of course, the NetBSD Ethernet drivers that support jumbo frames need to be 
written to be able to receive them always, or a vlan configuration directive as 
I discuss passed through in a nominally invisible way), for this to work. In 
this sort of scenario, interface MTU becomes more of an API notification to 
userland on what can be sent (or to the IP stack for fragmentation, or TCP MSS) 
than an actual constraint on the operation of the driver on packet reception.

Or, if one wants to quote ancient (RFC) scripture, NetBSD's Ethernet drivers 
need to be coded to be "liberal in what they accept, and conservative in what 
they send."

        Erik <fair%netbsd.org@localhost>