diff options
| author | Kibaek Yoo <psykibaek@gmail.com> | 2026-02-28 16:16:12 +0900 |
|---|---|---|
| committer | Jakub Kicinski <kuba@kernel.org> | 2026-03-03 18:08:13 -0800 |
| commit | b52363f706e53101d9f8c5ba5e3854d6be8f122c (patch) | |
| tree | 40f248fe6f4bec6ae8bd9ed776db8a57de859372 /include/uapi/linux | |
| parent | d6ca199568c53ece99aeeae1022d04f2fd8cde7f (diff) | |
| download | lwn-b52363f706e53101d9f8c5ba5e3854d6be8f122c.tar.gz lwn-b52363f706e53101d9f8c5ba5e3854d6be8f122c.zip | |
net: macvlan: support multicast rx for bridge ports with shared source MAC
Macvlan bridge mode currently does not handle the case where an
external source shares its MAC address with a local macvlan interface.
When such a frame arrives, macvlan_hash_lookup() matches the source
MAC to the local macvlan, and macvlan_multicast_rx() assumes bridge
ports already received the frame during local transmission. Since the
frame actually originated externally, bridge ports never saw it.
This situation arises with protocols like VRRP, where multiple hosts
use the same virtual MAC address.
Support this by passing NULL as the source device and including
MACVLAN_MODE_BRIDGE in the mode mask for the else branch of
macvlan_multicast_rx(). This ensures all VEPA and bridge mode macvlan
interfaces receive incoming multicast regardless of source MAC
matching. The trade-off is that looped-back locally-originated
multicasts may be delivered to bridge ports a second time, but
multicast consumers already handle duplicate frames.
Signed-off-by: Kibaek Yoo <psykibaek@gmail.com>
Link: https://patch.msgid.link/20260228071613.4360-1-psykibaek@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'include/uapi/linux')
0 files changed, 0 insertions, 0 deletions
