On Thu Nov 14, 2024 at 7:06 PM CET, Linus Lüssing wrote:
Hi Nicolas,
Many thanks for your feedback!
[...]
I am not in favour of changing the behavior of batman-adv. Now everyone can increase the number of managed VLANs without any control by the node admin.
Valid concern. Especially as each added VLAN is quite costly for an OGM at the moment. A VLAN with one MAC address adds 12 bytes to a 24 bytes base OGM IV length (excluding ethernet header and other TVLVs).
However in a way for non-VLAN TT entries this is also partially a concern, right? Someone could also flood source MAC addresses in an uncontrolled way, too. (Though would likely have to actively keep roaming to create a constant extra overhead.)
Maybe it would make sense to check how the Linux bridge approaches this?
It seems there is an admin configurable limit of BR_MULTICAST_DEFAULT_HASH_MAX = 4096 entries for the MDB (multicast MAC addresses). And a configurable fdb_max_learned (disabled by default, for backwards compatibility reasons according to bdb4dfda3b) for the FDB (unicast MAC addresse). Thirdly, it seems 4096 VLANs are allowed (VLAN_N_VID), the maximum amount. Though this one does not seem configurable.
Would it maybe make sense to have a knob and by default set the limit to 8 or 16 VLANs? A default which could maybe be increased if the OGM size was decoupled from the amount of VLANs in the future?
I really like this idea. This either could be a compile time knob or a dynamic one to ensure we don't easilly have a too big OGM
The two reasons I would like to have a dynamic VLAN feature, especially for wireless community mesh networks:
Allow a group of people to setup and use their own address space when the centrally managed, default one does not match their needs. -> decentralization
Allow to get rid of the unused VID=0 and VID=1 entries by default, only dynamically learn them, to typically reduce the OGM overhead by at least 2*12 bytes. To partially mitigate the overhead regression we introduced by adding TT in compat 15.
Just my overall, conceptual thoughts on this feature. Will look into the refcount issue later, thanks for reporting!
Regards, Linus
Thanks