bisdn / basebox

A tiny OpenFlow controller for OF-DPA switches.
Mozilla Public License 2.0
45 stars 9 forks source link

nl_bridge: flush our fdb entries on vlan removal #446

Closed KanjiMonster closed 3 weeks ago

KanjiMonster commented 1 month ago

The kernel refuses to remove fdb entries for VLANs that are not configured, but at the same time won't remove permanent entries on VLAN deletion, including extern_learn entries.

Fortunately recent kernels gained the ability for bulk deletion, so add a new helper to send a flush of all extern_learn entries from a deleted vlan from a certain port.

Using this, we can make sure no entries are left behind in the removed vlan.

Any removed entry will trigger a DEL_NEIGH message from the kernel, but since we already removed the neigh from the cache and removed the flow, we do not need to handle it again here, so add a check before attempting to handle the deleted neigh.

This was tested via:

on switch:

$ ip link add swbridge type bridge vlan_filtering 1 vlan_default_pvid 0 $ ip link set dev port5 master swbridge
$ ip link set dev port5 up
$ bridge vlan add dev port5 vid 2 pvid untagged

(connect something to port5, let it generate packets)

$ bridge fdb show dev port5 | grep extern_learn
0c:c4:7a:9c:29:fc vlan 2 extern_learn master swbridge
$ bridge vlan del dev port5 vid 2

Before:

$ bridge fdb show dev port5 | grep extern_learn
0c:c4:7a:9c:29:fc vlan 2 extern_learn master swbridge

(entry still present)

After:

$ bridge fdb show dev port5 | grep extern_learn

(entry gone)

KanjiMonster commented 1 month ago

For us being able to handle the DEL_NEIGH messages, we would need to do reference counting for the vlan group for bridges as well - currently we (try to) delete it directly on vlan removal.