bonding: Renaming multiple interfaces not working properly #66
Comments
|
Seems to be related to bonding since the renaming works properly during combustion-prepare: |
atanasdinov
changed the title
|
Hey, @jmmckenz. Thanks for the hint. Did that resolve the renaming issue or is it not enough? I'll try to reproduce it as well soon, as well as try to figure out the main culprit behind the bonding failures and how to best tackle those. |
At this time I don't think it is enough. There are two issues at play here, especially with multinic configurations. The first has to do with EIB and the enumeration of NICs not being predictable across multiple reboots. This should be remedied by setting the kernel arg "net.ifnames=1" to produce predictable nic names, BUT with the current release of EIB, it does not take effect until after the first reboot, so you have ethX.nmconnection names that may be invalid once net.ifnames=1 applies on reboot. This effects both bonded and non-bonded nics. There is a current PR that addresses this issue and will have the kexec shell apply the kernel parameter so that it is consistent through the build and reboot process. The second issue is with nmconfigurator itself. During combustion, nmc runs twice, once at preboot, and then again when the preboot phase is over and kexec has chrooted/mounted us into our "build". The first run correctly identifies host by mac, sets up nics, sets up bonds and slaves as expected. The second run fails to identify the host by mac if a bond is present, thus leaving us with the localhost.localdomain hostname instead of the name that should be generated from network/myhost.mycompany.com.yaml. Because it fails, it does not copy the interface.nmconnection files during combustion, and upon reboot, we are left with no network config for NetworkManager to apply. My assumption here, and take this with a grain of salt because it could be a reach, is that once the bond is established, the slave nics masquerade the MAC address of the bond, and move their own MAC to permaddr. This causes nmc to not recognize our host anymore because the effective MAC address of our interfaces is now cloned from the bond. But, that is just a theory. Refer to: #122 for more information and my UGLY workaround. I can tell you that we have made some good progress on the EIB "net.ifnames=1" handling, so hopefully it will get pushed out to a future release once it is fully tested and vetted. The nmc issue was identified last week, and may take time to identify root cause, effective remediation, or to see if there are existing ways through the eib-definition yaml that we can avoid the problem. |
|
A couple of notes explaining the reason behind all issues related to bonding. We have to run nmc during both the When bonding is configured, the We use a third-party crate to list the interfaces on the node since there's no native way in Rust to achieve the same. The linked crate will run getifaddrs under the hood to capture the interfaces and return them. Unfortunately, this C function will not return a result that we can rely on. Example (edited for visibility): We can clearly see that all interfaces share the MAC address of the bond and the actual MAC addresses of the interfaces are dropped. Other ways of extracting the MAC addresses resulting in "misleading" values include:
I'd like to have to do some more investigation as soon as I have the time but we need to migrate the current implementation away from
|
|
Different work around for static bonded nics (with caveats)... |
Input:
Applying the generated configuration on a host with two Ethernet interfaces (
eth0andeth1respectively) only results in properly renaming one of the interfaces:The text was updated successfully, but these errors were encountered: