Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nl_bridge: flush our fdb entries on vlan removal #446

Merged
merged 1 commit into from
Aug 21, 2024
Merged

Conversation

KanjiMonster
Copy link
Contributor

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
Copy link
Contributor Author

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.

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)

Signed-off-by: Jonas Gorski <[email protected]>
@rubensfig rubensfig merged commit 1d4c971 into main Aug 21, 2024
5 checks passed
@rubensfig rubensfig deleted the jogo_fdb_flush branch August 21, 2024 12:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants