[B.A.T.M.A.N.] Add VLAN tag size to MTU recommendation?

[B.A.T.M.A.N.] Add VLAN tag size to MTU recommendation?

[Linus Lüssing]

Hi,

First of all, just wanted to forward this awesome diagram
regarding MTUs in Gluon-Setups which Freifunk Hamburg created
:D :

https://twitter.com/ohrensesselnet/status/789176399655350272

Which might be helpful for anyone new to understand how the
encapsulation in batman-adv works and how the MTU recommendations
of the underlying hard interfaces are calculated.

(I need to ask Leo for the sources, maybe a version without the
fastd overhead might be interesting for an MTU-explained page in
the open-mesh.org wiki :)?)


While checking the calculations Freifunk Hamburg did, I was
wondering whether the batadv_hardif_min_mtu() function should add
an extra 4 bytes for VLAN tagged, encapsulated payload to the MTU
calculations and the kmesg recommendations, especially since
Antonio's great work made TT fully VLAN-aware?

Open-Mesh.com/Cloudtrax routers are using the VLAN awareness, right?
Is the wifi interface MTU there just set to +4 bytes over the kmesg
recommedation?

Regards, Linus

Re: [B.A.T.M.A.N.] Add VLAN tag size to MTU recommendation?

[Linus Lüssing]

On Fri, Oct 21, 2016 at 11:53:44AM +0800, Marek Lindner wrote:
> 
> Hi,
> 
> On Thursday, October 20, 2016 11:56:14 PM HKT Linus Lüssing wrote:
> > First of all, just wanted to forward this awesome diagram
> > regarding MTUs in Gluon-Setups which Freifunk Hamburg created
> > 
> > :D :
> > https://twitter.com/ohrensesselnet/status/789176399655350272
> 
> this link leads to a router pic ?
> Found the diagram you were (probably) referring to by searching in his/her 
> tweetface history. 

Urgh, I'm very, very sorry, yes, I ment this one instead :( :

https://twitter.com/ffhhnoc/status/787771192853798915

> > While checking the calculations Freifunk Hamburg did, I was
> > wondering whether the batadv_hardif_min_mtu() function should add
> > an extra 4 bytes for VLAN tagged, encapsulated payload to the MTU
> > calculations and the kmesg recommendations
> I am wondering whether we are trying to solve a problem that isn't a batman 
> problem. You could have any number of encapsulation interfaces on top of bat0 
> (QinQ, GRE, etc) adding overhead. Do we reserve space for all these headers 
> too ?

Hm, not quite sure whether it is 100% the same. While the problem
is the same, for VLANs and GRE etc., in practice they behave a
little different: When you have a network card with an MTU of
1500 bytes, then it usually works both with or without VLANs. And
without fragmentation.

GRE or other tunneling protocols don't have that property. And
I'm wondering whether we should try to preserve such VLAN
properties.