On 2022-09-28 08:59, Ido Schimmel wrote:
Sorry for the delay, was away.
Good to have you back. :-)
On Tue, Sep 27, 2022 at 10:33:10AM +0200, netdev@xxxxxxxxxxxxxxxxxxxx
wrote:
On 2022-09-21 09:15, Ido Schimmel wrote:
> bridge fdb add `mac_get $h2` dev br0 blackhole
To make this work, I think we need to change the concept, so that
blackhole
FDB entries are added to ports connected to the bridge, thus
bridge fdb add MAC dev $swpX master blackhole
This makes sense as the driver adds them based on the port where the
SMAC is
seen, even though the effect of the blackhole FDB entry is switch
wide.
Asking user space to associate a blackhole entry with a bridge port
does
not make sense to me because unlike regular entries, blackhole entries
do not forward packets out of this port. Blackhole routes and nexthops
are not associated with a device either.
Adding them to the bridge (e.g. f.ex. br0) will not work in the SW
bridge as
the entries then are not found.
Why not found? This works:
# bridge fdb add 00:11:22:33:44:55 dev br0 self local
$ bridge fdb get 00:11:22:33:44:55 br br0
00:11:22:33:44:55 dev br0 master br0 permanent
With blackhole support I expect:
# bridge fdb add 00:11:22:33:44:55 dev br0 self local blackhole
$ bridge fdb get 00:11:22:33:44:55 br br0
00:11:22:33:44:55 dev br0 master br0 permanent blackhole
In my previous replies, I have notified that fdb_find_rcu() does not
find the entry added with br0, and thus fdb_add_entry() that does the
replace does not replace but adds a new entry. I have been thinking that
it is because when added with br0 as dev it is added to dev br0's fdb,
which is not the same as 'dev <Dev> master' fdb...
I think bridge fdb get works in a different way, as I know the get
functionality gets all fdb entries from all devices and filters them (if
I am not mistaken)...
