Skip to content

docs: add known issue for management bridge MAC change after NetworkManager migration - #1049

Open
tillo wants to merge 2 commits into
harvester:mainfrom
tillo:known-issue-mgmt-br-mac-float
Open

tillo wants to merge 2 commits into
harvester:mainfrom
tillo:known-issue-mgmt-br-mac-float

Conversation

@tillo

@tillo tillo commented May 22, 2026

Copy link
Copy Markdown

Problem

After the wicked → NetworkManager migration (Harvester v1.6.x → v1.7.x), the management bridge mgmt-br is no longer protected against MAC address changes.

Under wicked, /etc/wicked/scripts/setup_bond.sh ran a bond post-up hook that pinned mgmt-br's MAC address to the bond MAC. That script still ships in /oem/90_custom.yaml, but it is dead code now that NetworkManager is the active network stack — wicked is inactive, so the hook never runs.

mgmt-br then behaves as a plain Linux bridge and adopts the lowest MAC address among its enslaved ports. Bridge-mode VM networks enslave VM veth interfaces into mgmt-br, so the bridge MAC can change on any VM start/stop/migrate.

This breaks Layer 2 load balancers: MetalLB's L2 ARP responder caches the announce-interface MAC at creation and keeps advertising the stale value. Once the originating veth is removed, that MAC exists on no interface and every affected LoadBalancer IP becomes unreachable — an intermittent, hard-to-diagnose outage where the backing pods are healthy, the IPs are reported as assigned, and ARP still resolves, but to a MAC that black-holes traffic.

Change

Adds Known Issue #6 to the v1.6.x → v1.7.x upgrade page: the failure mode plus a remediation — a NetworkManager dispatcher script that re-pins mgmt-br to the bond MAC on every network event, persisted via an /oem config file so it survives reboots and upgrades. This restores, under NetworkManager, the behaviour the old wicked setup_bond.sh hook provided.

Applied to docs/ and the version-v1.7 / version-v1.8 copies.

Notes

  • Observed and remediation verified on Harvester v1.7.1.
  • This may also warrant a product-side fix — Harvester could carry the NetworkManager-era equivalent of setup_bond.sh so no manual step is needed. Happy to file a separate harvester/harvester issue for that if maintainers prefer.

@tillo
tillo force-pushed the known-issue-mgmt-br-mac-float branch from ef3215d to 58c828d Compare May 28, 2026 07:59
@tserong
tserong self-requested a review May 29, 2026 10:11
…anager migration

The wicked-to-NetworkManager migration drops the bond post-up hook that
pinned the management bridge (mgmt-br) MAC address to the bond MAC. Without
it, mgmt-br behaves as an ordinary Linux bridge and floats its MAC to the
lowest-MAC enslaved port; bridge-mode VM veths can therefore change the
bridge MAC on VM lifecycle events. MetalLB's L2 ARP responder caches the
announce-interface MAC and then advertises a stale value, black-holing
LoadBalancer IPs.

Document the failure mode and a NetworkManager dispatcher-script remediation
persisted via an /oem config file, under Known Issues on the v1.6.x-to-v1.7.x
upgrade page (docs/ and the v1.7 and v1.8 versioned copies).

Signed-off-by: Martino Dell'Ambrogio <tillo@tillo.ch>
@tillo
tillo force-pushed the known-issue-mgmt-br-mac-float branch from 8447343 to f96efbf Compare September 14, 2026 21:13
@tillo
tillo requested review from a team and jillian-maroket as code owners September 14, 2026 21:13
@jillian-maroket

Copy link
Copy Markdown
Contributor

@tserong Please review the wicked → NetworkManager details in this PR. Thanks!

@tillo

tillo commented Nov 10, 2026

Copy link
Copy Markdown
Author

@tserong — gentle nudge on this one: the review was requested on 2026-09-15 and the PR has been open since May.

One note on CI, in case the build is a gate here: the Pull Request Build run for this PR (34897613641) reports failure but never started a single job — there is no failing step to inspect. The only checks that actually executed are DCO (success) and Mergify (neutral). I don't have write access on this repo so I can't re-trigger it; someone with maintainer rights may need to re-run that workflow.

Happy to adjust anything in the wording or detail.

No content change. The Pull Request Build run for this branch never
executed a job and expired after 30 days waiting for approval; a new
commit gives the run a fresh attempt to be approved and started.

Signed-off-by: Martino Dell'Ambrogio <tillo@tillo.ch>

This branch has not been deployed

No deployments
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.

2 participants