-
Notifications
You must be signed in to change notification settings - Fork 12
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
Initial multicast filtering support for bridge #309
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
9 tasks
troglobit
force-pushed
the
multicast-snooping
branch
2 times, most recently
from
February 29, 2024 09:38
857baf8
to
8d34c23
Compare
troglobit
force-pushed
the
multicast-snooping
branch
3 times, most recently
from
March 5, 2024 08:52
28e3e23
to
9642d51
Compare
troglobit
requested review from
mattiaswal,
rical and
wkz
and removed request for
rical
March 6, 2024 05:52
wkz
reviewed
Mar 6, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome job guys!
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
With VLAN filtering on a bridge we cannot use the mcast_query_use_ifaddr mechanism. This because even if the bridge may have an address it is likely not on the same subnet as that of the VLAN, and the multicast code in the kernel does not look at VLAN interfaecs on top of bridge for a relevant adddress. For these cases we have to use querierd, or a multicast router. Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This patch adds BUM flooding control per port. Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Note, no VLAN id, or other VLAN specific information is contained in the MDB entries, only forwarding information and per-port state. Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Depends on having mtools v3+ on test PC, so add it to the docker.
With 3 data connections between host and DUT.
Simple test that tests (without VLAN): * Multicast flooding works * Join works as expected
A bridge port cannot communicate on layer-3 while acting as a bridge port. Removing the port from the bridge re-enables the link-local addresses, if any, from the configuration. Fix #327 Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This is a forward-port of one of my bridge patches to handle RFC4541 style flooding of unknown multicast. https://lore.kernel.org/netdev/20220411133837.318876-9-troglobit@gmail.com/ Changes since this thread: use inferred mctx (VLAN multicast context) from br_handle_frame_finish() and br_dev_xmit(), which should fix the per-VLAN multicast handling issue pointed out by Nikolay. Todo before next patch series, add new option instead of breaking the existing functionality for the current mcast_flood flag. E.g., add a mcast_flood_always, since the current flag stops flooding when there is a known querier on the LAN. See the above thread for details. Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
An RFC conforming multicast snooping bridge should forward all unknown multicast (IP & MAC) on ports where the mcast_flood flag is set. The upstream kernel does not (yet) support this, but the KernelKit branch of the kernel and iproute2 now support it. Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
And cleanup ASCII picture
Since Infix supports per-VLAN querier parameters, like query interval, we currently need to run a separate querierd per VLAN interface. The replacement, mcd, will handle this automatically in its .conf file. Also, ensure we install the daemon configuration file as an example, and thus creating the /etc/querierd/ directory for where .conf files for each interface will be generated. Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
In a VLAN filtering bridge setup we want to be able to support an external IGMP/MLD querier running from userspace, because the bridge multicast code can only generate proxy/NULL querys per VLAN. This patch is a refactor to allow just that. If a VLAN on the bridge has an upper interface, matching the bridge name and VID, we generate a profile for querierd and enable the service. For all other cases we try to disable any running querierd. It is up to the daemon to figure out if it has a usable IP address to use as the query source IP or use 0.0.0.0. Since the logic for selecting a proper IP address must be handled by the daemon in the per-VLAN setup, we revert back to also use it for the stand-alone unfiltered bridge case as well. Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Remove a lot of extra sleeps.
troglobit
force-pushed
the
multicast-snooping
branch
from
March 7, 2024 09:51
7bfc358
to
1df8a86
Compare
wkz
approved these changes
Mar 7, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🥇
mattiaswal
approved these changes
Mar 7, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
troglobit
force-pushed
the
multicast-snooping
branch
from
March 7, 2024 10:23
1df8a86
to
be59473
Compare
Rename to more distinct names for netns and hostports
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
mattiaswal
force-pushed
the
multicast-snooping
branch
from
March 7, 2024 10:32
be59473
to
bcba9d1
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Initial IGMP/MLD filtering support for the Linux bridge model. This PR brings per-bridge and per-VLAN settings to control basic multicast snooping1 settings:
We have verified that the built-in querier function of the kernel works, in particular in a non-VLAN filtering setup. However, since it only supports proxy/NULL queries in a per-VLAN setup we've decided against using it at all. So all querier functionality is handled by a userspace daemon instead.
The upstream kernel support for multicast filtering is still a bit limited. For example:
To that end a couple of kernel patches are added to fix the last two issues. These patches are also published on our open kernel repo for the currently used kernel, along with any iproute2 patches needed to control these features. The idea is to upstream them at a later date. (After the next big customer release.)
The next PR in this series will focus on:
Footnotes
Unfortunately there is currently no way in the Linux bridge to enable filtering but not snooping. So when we use the term snooping it may also refer to filtering. We have discussed submitting kernel patches to address this issue but are time limited atm. ↩