Add VLAN tag size to MTU recommendation?
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
A message that is not in the archive (sent off-list or not yet received): 123097163.ZmppEksrjh@voltaire
Quoted 7 lines · Marek Lindner
Hi,
Quoted 3 lines · HKT Linus Lüssing
First of all, just wanted to forward this awesome diagram regarding MTUs in Gluon-Setups which Freifunk Hamburg created
Quoted 6 lines
Quoted 2 lines
:D :
https://twitter.com/ohrensesselnet/status/789176399655350272this 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
Quoted 8 lines
Quoted 4 lines
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 recommendationsI 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.