If a bond interface is deleted and recreated, the gratuitous ARPs are sent with the wrong MAC address
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
keepalived |
Fix Released
|
Unknown
|
|||
keepalived (Ubuntu) |
Triaged
|
Undecided
|
Unassigned | ||
Xenial |
Triaged
|
Undecided
|
Unassigned | ||
Bionic |
Triaged
|
Undecided
|
Unassigned | ||
Disco |
Won't Fix
|
Undecided
|
Unassigned | ||
Eoan |
Triaged
|
Undecided
|
Unassigned |
Bug Description
When an interface is added to a bond interface, if it is the first
interface added, the MAC address of the bond interface is changed
to the MAC address of the added interface. When subsequent interfaces
are added, their MAC addresses are changed to that of the bond
interface.
Uptream issue [0] identified that if a bond interface is deleted and
recreated, the gratuitous ARPs were sent with the wrong source MAC
address.
Upstream commit [1] updates interface MAC addresses from the
netlink RTM_NEWLINK messages, so that the correct MAC address
is always used.
[0] https:/
[1] https:/
===== Original description =====
As explained in the upstream bug report:
https:/
please include the fix of the commit to ubuntu LTS:
https:/
description: | updated |
description: | updated |
Changed in keepalived (Ubuntu Xenial): | |
status: | New → Triaged |
Changed in keepalived (Ubuntu Bionic): | |
status: | New → Triaged |
Changed in keepalived (Ubuntu Disco): | |
status: | New → Triaged |
Changed in keepalived (Ubuntu Eoan): | |
status: | New → Triaged |
summary: |
- Include Upstream commit fixing mac address change issue in bond (and - bridged) interfaces + If a bond interface is deleted and recreated, the gratuitous ARPs are + sent with the wrong MAC address |
tags: | added: server-triage-discuss |
tags: | removed: server-triage-discuss |
Changed in keepalived: | |
status: | Unknown → Fix Released |
Changed in keepalived (Ubuntu Disco): | |
status: | Triaged → Won't Fix |
Thank you for taking the time to report this bug and helping to make Ubuntu better. What you need is a Stable Release Upgrade (SRU), which is subject to the procedure and policy documented here:
https:/ /wiki.ubuntu. com/StableRelea seUpdates
SRUs always come with some regression risk, so a compelling use case currently broken by the bug is normally needed to counterweight this risk. This is what we may be missing in this case. If you want to help the process please comment with a justification against https:/ /wiki.ubuntu. com/StableRelea seUpdates# When and complete steps 1 through 4 in https:/ /wiki.ubuntu. com/StableRelea seUpdates# Procedure - and go ahead with all the steps if you can. Note that that SRU team would need to make a final decision.