Skip to content

bridge: reliably pin the MAC on a bridge that lost its ports#1265

Open
twz123 wants to merge 2 commits into
containernetworking:mainfrom
twz123:bridge-mac-pinning
Open

bridge: reliably pin the MAC on a bridge that lost its ports#1265
twz123 wants to merge 2 commits into
containernetworking:mainfrom
twz123:bridge-mac-pinning

Conversation

@twz123

@twz123 twz123 commented Jun 17, 2026

Copy link
Copy Markdown
Contributor

The ensureAddr function pins the bridge's MAC address so it doesn't change as ports come and go. The pinning happens after the gateway address is set, so if a run set the address but then failed before pinning, subsequent runs never reattempted to pin the MAC, leaving behind a bridge with a floating MAC. The kernel zeroes a bridge's MAC address when its last port is removed, and ensureAddr pins the MAC using the address read when the bridge was looked up, which is before the veth is attached. So for an existing bridge that had previously lost all its ports, the address it tried to pin is all zeros, and pinning an all-zero address fails with EINVAL.

In fact, this can happen in practice: an ADD that fails has its veth cleaned up, which, if it was the first ADD, leaves the bridge portless and hence its MAC zeroed, so the next ADD fails to pin it.

Always pin the MAC, even if the gateway address is already present, regardless of the outcomes of previous attempts. Detect zero MACs and regenerate a random MAC address the same way the kernel does. This is fine as it only happens if the bridge has no ports, so no peer can hold stale state about the old address.

@twz123 twz123 force-pushed the bridge-mac-pinning branch from 4d7a078 to 8be5425 Compare June 17, 2026 16:29
twz123 added 2 commits June 17, 2026 18:36
The ensureAddr function pins the bridge's MAC address so it doesn't
change as ports come and go. The pinning happens after the gateway
address is set, so if a run set the address but then failed before
pinning, subsequent runs never reattempted to pin the MAC, leaving
behind a bridge with a floating MAC.

Always pin the MAC, even if the gateway address is already present,
regardless of the outcomes of previous attempts.

Signed-off-by: Tom Wieczorek <twieczorek@mirantis.com>
The kernel zeroes a bridge's MAC address when its last port is removed.
The ensureAddr function pins the bridge's MAC address using the
address read when the bridge was looked up, which is before the veth
is attached. So for an existing bridge that had previously lost all its
ports, the address it tried to pin is all zeros, and pinning an all-zero
address fails with EINVAL.

In fact, this can happen in practice: an ADD that fails has its veth
cleaned up, which, if it was the first ADD, leaves the bridge portless
and hence its MAC zeroed, so the next ADD fails to pin it.

Detect that case and regenerate a random MAC address the same way the
kernel does. This is fine as it only happens if the bridge has no ports,
so no peer can hold stale state about the old address.

Signed-off-by: Tom Wieczorek <twieczorek@mirantis.com>
@twz123 twz123 force-pushed the bridge-mac-pinning branch from 8be5425 to d06315e Compare June 17, 2026 16:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant