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
