On 08/07/2020 12:42, Vladimir Oltean wrote: > On Wed, Jul 08, 2020 at 12:16:27PM +0300, Nikolay Aleksandrov wrote: >> On 08/07/2020 12:04, Vladimir Oltean wrote: >>> Hi, >>> >>> I am confused after reading man/man8/bridge.8. I have a bridge br0 with >>> 4 interfaces (eth0 -> eth3), and I would like to install a rule such >>> that the non-IP multicast address of 09:00:70:00:00:00 is only forwarded >>> towards 3 of those ports, instead of being flooded. >>> The manual says that 'bridge mdb' is only for IP multicast, and implies >>> that 'bridge fdb append' (NLM_F_APPEND) is only used by vxlan. So, what >>> is the correct user interface for what I am trying to do? >>> >>> Thank you, >>> -Vladimir >>> >> >> Hi Vladimir, >> The bridge currently doesn't support L2 multicast routes. The MDB interface >> needs to be extended >> for such support. Soon I'll post patches that move it to a new, entirely >> netlink attribute- >> based, structure so it can be extended easily for that, too. My change is >> motivated mainly by SSM >> but it will help with implementing this feature as well. >> In case you need it sooner, patches are always welcome! :) >> >> Current MDB fixed-size structure can also be used for implementing L2 mcast >> routes, but it would >> require some workarounds. >> >> Cheers, >> Nik >> >> > > Thanks, Nikolay. > Isn't mdb_modify() already netlink-based? I think you're talking about > some changes to 'struct br_mdb_entry' which would be necessary. What > changes would be needed, do you know (both in the 'workaround' case as > well as in 'fully netlink')? > > -Vladimir >
That is netlink-based, but the uAPI (used also for add/del/dump) uses a fixed-size struct which is very inconvenient and hard to extend. I plan to add MDBv2 which uses separate netlink attributes and can be easily extended as we plan to add some new features and will need that flexibility. It will use a new container attribute for the notifications as well. In the workaround case IIRC you'd have to add a new protocol type to denote the L2 routes, and re-work the lookup logic to include L2 in non-IP case. You'd have to edit the multicast fast-path, and everything else that assumes the frame has to be IP/IPv6. I'm sure I'm missing some details as last I did this was over an year ago where I made a quick and dirty hack that implemented it with proto = 0 to denote an L2 entry just as a proof of concept. Also you would have to make sure all of that is compatible with current user-space code. For example iproute2/bridge/mdb.c considers that proto can be only IPv4 or IPv6 if it's not v4, i.e. it will print the new L2 entries as :: IPv6 entries until it's fixed. Obviously some of the items for the workaround case are valid in all cases for L2 routes (e.g. fast-path/lookup edit). But I think it's not that hard to implement without affecting the fast path much or even at all. Cheers, Nik
