On 08/07/2020 14:07, Nikolay Aleksandrov wrote: > 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
Actually drop the whole /workaround/ comment altogether. It can be implemented fairly straight-forward even with the struct we got now. You don't need any new attributes. I just had forgotten the details and spoke too quickly. :) > 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 > > >
