On Friday, 26 April 2019 19:12:31 CEST Linus Lüssing wrote:
With DAT DHCP snooping, the gateway feature and multicast optimizations in place in some scenarios broadcast flooding might not be strictly necessary anymore to be able to establish IPv4/IPv6 communication. Therefore this patch adds an option to disable broadcast flooding.
Larger mesh networks typically filter a variety of multicast packets via ebtables/netfilter to clamp on overhead. With this option such firewall rules can be relaxed so that such multicast packets are only dropped if they cannot be handled by multicast-to-unicast, for instance.
"noflood" comes in two flavours: If set to 1 then flood prevention is enabled for all multicast/broadcast packets except ICMPv6 and IGMP (cautious mode). Or, if set to 2 then flood prevention is enabled for all multicast/broadcast packets (aggressive mode). If set to 0 then flood prevention is disabled.
"noflood" is disabled by default as there are still some things to take care of to avoid breaking things (especially for the "aggressive mode").
Signed-off-by: Linus Lüssing linus.luessing@c0d3.blue
The initial approach was a "noflood"-mark which worked similar to the isolation mark. Which allowed more flexibility so that the user could mark specific packets to be excluded from broadcast flooding via ebtables/netfilter. However, in practice skb-marking is not that easy to configure and if misconfigured will break a network horribly. Which was also a downside noted and discussed at BattleMesh v11.
This version now is a less flexible but therefore also simpler to use variant.
It looks like this is an option which can break the mesh rather easily. Here some quotes from 2019-04-30/2019-05-01:
<marec> even the 'cautious' option drops everything except for IGMP and ICMPv6 <marec> nobody has a clear picture what that $everything is <marec> how does it help you if IGMP and ICMPv6 go through if all other multicast / broadcast is dropped ? <marec> (because of too many mesh participants with multicast optimizations disabled) <T_X> with IGMP/ICMPv6 to always go through I hope we have the most basic things for IP-IP communication covered and unsucceptible to DoS cases you have already outlined <marec> T_X: how so ? <marec> T_X: even considering your gluon case - how many nodes would you need to update and have to enable mcast optimization to safely turn on noflood ? <marec> as I recall, your meshes are all bridged together over vpns <marec> with only 16 nodes not upgraded or mcast optimization disabled noflood will be permanently active <marec> (or whatever your fanout value is)
<T_X> so even if no node were having the multicast optimizations enabled, then communication both on the intranet and to the internet would still work <marec> that was not my point <marec> I want to allow people to experiment with and use multicast in a variety of undefined applications. <<< how do you want to get there ? <marec> while noflood drops everything <marec> (except for maybe IGMP and ICMPv6) <T_X> ah. yes. in that case, such applications would not / would stop working. but that's our current default case with basically filtering all/most multicast traffic except ICMPv6 via ebtables in Gluon
<marec> even standard DAT falls back to flooding, isn't it ? <T_X> marec: yep <marec> so, ARP does not work with noflood ? <T_X> if no ARP response in x milliseconds (250ms I think?) then it will flood the ARP request <T_X> marec: right
<marec> sounds to me the noflood will be pretty difficult to understand and debug <marec> how does a normal user understand when ARP works sometimes .. or even normal mcast apps work sometimes ? <marec> how will that seeming randomness be distinguishable from normal packet loss ? <T_X> yes. would at least need some thorough wiki page, I guess. *cough* :) <marec> I am talking about user outside the gluon garden <marec> sorry for pointing it out again but this noflood feature still feels like a gluon tailored solution - assuming auto-updaters, mcast enabled, no IPv4 or other things other than IPv6 with router advertisements
<ordex> my opinion is that I agree with T_X when he says "just add this patch to the Gluon repository for now" <ordex> honestly, skb-marking is much better imho. way less prone to mesh-explosions and people (that have a thorough understanding of ARP, ICMPv6, IGMP, MLD and understand what batman-adv would do or not) can decide how to treat such packets *externally* to batman-adv <ordex> this is what how we use the client-isolation with skb-marking - the dropping logic is implemented outside <ordex> with a match on the skb-mark <T_X> ok. and both the client-isolation and noflood skb->markings would fullfil a kind of similar purpose - that is preventing specific packets from reaching $destination, which could not be fullfilled with netfilter alone, right? [...] <ordex> the reason for the skb-marking is to have something to match packets against. In the client isolation case the knowledge about what to drop was inside batman-adv, thus we needed a way to "export" this knowledge
I would guess that you can also do something like this using ebtables + tc filter. Even with (tc) eBPF... since eBPF seems to be the miracle solution for everything these days.
Kind regards, Sven