MAC address of bonding interface is randomly picked
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ifenslave (Ubuntu) |
Triaged
|
High
|
Unassigned |
Bug Description
The new style of bonding configuration (using "iface bond0 [...] \ bond_slaves none" for the master interface plus "iface ethX inet manual \ bond_master bond0" for each slave interface) results in the MAC address of the bond0 interface being randomly picked from one of the slaves.
This causes problems for auto-configuration methods such as IPv4 DHCP and IPv6 SLAAC, as DHCPv4 leases and IPv6 Interface Identifiers are directly based on the interface's MAC address. This means that if the MAC address changes unexpectedly, so may the IP address(es) as well, which might be big problem if the machine in question is some sort of server or similar that have just rebooted.
Unexpected MAC address changes may also cause problems for statically configured addresses, as the upstream router will likely have cached the IPv4 ARP and/or the IPv6 Neighbour entry pointing to the old MAC address. This results in the server not having any network connectivity until the upstream router have timed out its cache entry and probes anew. These timeouts may well be up to 20 minutes.
The old configuration style ("iface bond0 [...] \ bond_slaves eth0 eth1 [...]") did not have this problem, as the MAC address used for bond0 would always be the first listed interface (eth0). While I have no particular objection to the syntax change in itself, the choice of MAC address should be deterministic. It is probably possible to manually set the MAC address with the "hwaddr" option, but this is not ideal because it by necessity means every node must have a unique configuration file, which is problematic for large automated server deployments for example.
Tore
affects: | ifenslave-2.6 (Ubuntu) → ifenslave (Ubuntu) |
Changed in ifenslave (Ubuntu): | |
importance: | Medium → High |
Changed in ifenslave (Ubuntu): | |
assignee: | Stéphane Graber (stgraber) → nobody |
Changed in ifenslave (Ubuntu): | |
status: | Fix Released → Triaged |
Changed in ifenslave (Ubuntu): | |
status: | Triaged → Fix Released |
Changed in ifenslave (Ubuntu): | |
status: | Fix Released → Triaged |
Yeah, this is one of the unfortunate side effects of having event based network bring up in Ubuntu. As devices are added to the bond in the order in which they're initialized by the kernel and as that initialization happens in parallel, the final order tends to be pretty random...
Setting hwaddr is the obvious workaround, however as you said, that's problematic on deployments where you'd like to have an identical interfaces file on all machines...
I'm really not sure of what to do about this... I've been thinking about a few possibilities but they each come with serious problems:
- Add a new field which lets you specify what interface to pick the mac address from. The problem is that this won't work until the interface actually exists. If we only switch the MAC once the interface exists, then that won't solve your IPv6 case as the link-local and eui64 addresses don't update on mac address change.
- Reuse the bond-master field and have all bond actions held until the bond-master appears (with a 5min timeout), thereby guaranteeing it'll always be joined first. The obvious problem there is that if the bond-master doesn't appear, your boot will hang for 5 minutes and you'll still get the wrong MAC (and therefore the wrong IP).
I think the bond-master idea is the least wrong of the two but I'd need to get back into the code quite a bit to figure out how that'd work exactly and decide if we should reuse the name or find a new one for this.