[B.A.T.M.A.N.] [PATCH] batman-adv: introduce "noflood" broadcast flood prevention option
linus.luessing at c0d3.blue
Sat Apr 27 04:38:49 CEST 2019
On Sat, Apr 27, 2019 at 05:56:03AM +0800, Marek Lindner wrote:
> On Saturday, 27 April 2019 01:12:31 HKT 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.
> Could you outline the use-case for this specific noflood option in more detail ?
> The description above is not entirely clear to me. Especially, the 'might not
> be strictly necessary anymore' to 'firewall rules can be relaxed'. How are
> these things connected ? Is this option implemented only, so that some firewall
> rules don't need to be set anymore ?
The main use-case I currently have in mind is safely enabling multicast in
larger, public mesh networks:
Currently we have firewall rules in Gluon to drop most multicast.
With multicast-to-multi-unicast we could in theory use multicast
without creating broadcast overhead for the whole mesh. However
only until we hit the multicast_fanout threshold. Then things
would get flooded again.
The desired behaviour in this case would be to let multicast packets pass
unless they would be flooded. A firewall does not know which
mechanism batman-adv would choose. Hence this option within
batman-adv to create this desired behaviour.
With "might not be strictly necessary anymore" I ment that if
certain requirements are met that address assignments and address
resolution can now be achieved without needing broadcast flooding.
> What happens if a user enables 'noflood' but does not fall into the 'might not
> be strictly necessary anymore' category ?
Well, broken connectivity. Typing "ip link set dev eth0 multicast off"
in a setup which still needs multicast to function would be an
analogy then :).
More information about the B.A.T.M.A.N