On Fri, Nov 04, 2022 at 12:23:07PM +0100, netdev@xxxxxxxxxxxxxxxxxxxx wrote: > On 2022-11-04 00:18, Vladimir Oltean wrote: > > > 3. Forwarding: Locked FDB entries forward traffic like regular entries. > > > If user space detects an unauthorized MAC behind a locked port and > > > wishes to prevent traffic with this MAC DA from reaching the host, it > > > can do so using tc or a different mechanism. > > > > In other words, a user space MAB daemon has a lot of extra work to do. > > I'm willing to bet it's going to cut 90% of those corners ;) anyway... > > I would like to know your (Vladimir) take on the approach of the > implementation for the mv88e6xxx that I have made and which will also be > the basis for how the WesterMo hostapd fork will be afaik... > > Is it in general a good idea to use TC filters for specific MACs instead > of having the driver installing blocking entries, which I know the Marvell > XCat switchcore will also have (switchcore installed blockig entries)? Well, the mv88e6xxx driver does not offload tc filters in general, so let's keep that in mind. Achieving the behavior of not forwarding traffic to a BR_FDB_LOCKED entry can be done in a variety of ways using tc. Simplest would be to put an "action drop" filter on the egress chain of the port where the BR_FDB_LOCKED entry is located. Although that's probably least amenable to offloading. I think "action drop" is more popular as an offload action on ingress chains, which means you'd either have to (a) put an "action drop" on the ingress chain of every other bridge port, or (b) create a shared tc block and put all bridge ports in that. The problem with (b) is that it doesn't play all that well with bridge ports belonging to different hardware blocks. All in all, I think the yet-to-be-introduced 'blackhole' FDB flag makes the most sense for this behavior. Its scope is the entire bridge forwarding domain by definition (no need to attach it as filter to the egress or ingress block of one/multiple bridge ports), and it's also easily offloadable. I think it could make a lot of sense for the MAB daemon to do one of 2 things: replace the BR_FDB_LOCKED entry with a static/dynamic FDB entry if it's going to authorize it, or with a blackhole entry on br0 if it's going to deny it. So you wouldn't have to manually add the blackhole entry from the mv88e6xxx driver; user space would do it.
