-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IPv6 auto-conf for bridge interfaces gets random link identifier instead of MAC based (eui64) #357
Comments
Fixes #357 Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Issue #357 Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Cannot reproduce (on my Qemu system). Could you attach the startup-config you used to trigger this (censoring any customer specifics)? Also, did this trigger from power-on (using startup-config) or did it happen at runtime, i.e., reconfiguring the device to use bridge + ipv6? Because in the latter case we've seen issues with enabling settings post-boot that don't "take" until after a save and reboot. Addendum: I was a bit curious if we had missed something else, and I found another sysctl setting called |
J-O posted a follow-up in a side channel. What follows is my translation from Swedish, any errors are mine.
|
An example with qemu using infix latest as of April 16 (built April 15 as shown below)
Startup Config attached.
Configuration:
Show IP assignment
reboot and login again
reboot and login again
In later infix versions, IPv6 address gen mode is no longer shown (null rather than eui64)
Full output
|
Reproduced. Root cause is the initial random MAC address assigned to the bridge before we add any bridge ports. The fix is to ensure the bridge is always created with the system base mac. For Qemu/Qeneth:
|
Re: IPv6 addrgen mode no longer shown, apparently the iproute2 upgrade caused this. In v6.5 they added support for "filtering stats", a kernel feature that has been available since Linux 2015, behind which the IPv6 addrgen mode is hidden. From now on, use:
The |
To prevent the kernel from setting a random mac address on new bridges, before we have added any bridge ports, we create bridges using the: 1. Custom mac address from the configuration (phys-address) 2. System base mac from /run/system.json 3. None, if there is no base mac address in system.json, e.g. r2s Fixes #357 Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
To prevent the kernel from setting a random mac address on new bridges, before we have added any bridge ports, we create bridges using the: 1. Custom mac address from the configuration (phys-address) 2. System base mac from /run/system.json 3. None, if there is no base mac address in system.json, e.g. r2s Fixes #357 Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
To prevent the kernel from setting a random mac address on new bridges, before we have added any bridge ports, we create bridges using the: 1. Custom mac address from the configuration (phys-address) 2. System base mac from /run/system.json 3. None, if there is no base mac address in system.json, e.g. r2s Fixes #357 Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
To prevent the kernel from setting a random mac address on new bridges, before we have added any bridge ports, we create bridges using the: 1. Custom mac address from the configuration (phys-address) 2. System base mac from /run/system.json 3. None, if there is no base mac address in system.json, e.g. r2s Fixes #357 Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
To prevent the kernel from setting a random mac address on new bridges, before we have added any bridge ports, we create bridges using the: 1. Custom mac address from the configuration (phys-address) 2. System base mac from /run/system.json 3. None, if there is no base mac address in system.json, e.g. r2s Fixes #357 Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
The fix to this has been moved to a separate branch, https://github.com/kernelkit/infix/tree/stable-bridge-mac, because it for some reason break IGMP functionality. Pending investigation. |
I had a quick look at why the test-suite fails with the fix for this in https://github.com/kernelkit/infix/tree/stable-bridge-mac applied. The test I manually verified that bridge snooping still works and that traffic isn't flooded as the test failure suggests. This points to either a race condition in the test or some strange first-time behavior when joining a group in a pristine system. Investigation will continue. |
Discussed AFK with @wkz about your findings from yesterday, and I think the best way forward here is kernelkit/mcd#5. I.e., fix in userspace. |
To prevent the kernel from setting a random mac address on new bridges, before we have added any bridge ports, we create bridges using the: 1. Custom mac address from the configuration (phys-address) 2. System base mac from /run/system.json 3. None, if there is no base mac address in system.json, e.g. r2s Fixes kernelkit#357 Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Reproduced on latest infix (2024-03-25) but seems to have been like this all the time.
When using IPv6 autoconfiguration on a bridge interface, the fe80:: address will differ for each boot. The link identifier seems to be random rather than based on the bridge MAC (which is inherited from the first/lowest port attached)
Next boot
The text was updated successfully, but these errors were encountered: