Page MenuHomeFreeBSD

bridge: Simplify mac address generation
ClosedPublic

Authored by kp on Apr 15 2020, 7:07 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Dec 10, 3:00 PM
Unknown Object (File)
Sun, Dec 8, 10:03 AM
Unknown Object (File)
Nov 22 2024, 6:46 AM
Unknown Object (File)
Nov 17 2024, 7:56 PM
Unknown Object (File)
Nov 14 2024, 4:32 PM
Unknown Object (File)
Oct 29 2024, 9:34 PM
Unknown Object (File)
Oct 23 2024, 11:18 AM
Unknown Object (File)
Oct 22 2024, 11:44 AM
Subscribers

Details

Summary

Unconditionally use ether_gen_addr() to generate bridge mac addresses.
This function is now less likely to generate duplicate mac addresses
across jails. The old hand rolled hostid based code adds no value.

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 30521
Build 28268: arc lint + arc unit

Event Timeline

bz added inline comments.
sys/net/if_bridge.c
746

I don't fully understand the logic but ether_gen_addr() will always give you the same result in the loop so the outcome of the retry is not going to change, right? Do we need the do { } while() loop still or is that an endless loop now and we should rather have proper error handling? I am not even sure this was sane before... But that's probably a different question to raise.

This revision is now accepted and ready to land.Apr 15 2020, 8:02 PM
sys/net/if_bridge.c
746

Agreed... I suspect the loop and check for a conflict should probably just go away or get fixed (and not loop unless randomness comes back). It's really not (and wasn't) enough to just check bridge interfaces because those aren't the only kind of interfaces that get generated/random/arbitrary MAC addresses.

It also seems like it would've been safer to assume that other vnets on the same machine /could/ be in the same broadcast domain and check bridges in all vnets.

sys/net/if_bridge.c
746

Or for that one of the bridges in one of the 20 machines next to it in the rack running all the same with some similarly broken non-unique setup.
There's things we can do and things we cannot do and if it is an issue for users despite us trying the reasonable things then they can set these "unique" identifiers hard and by hand from the management interface at creation time themselves using an administered namespace.

Remove (now actively harmful) retry loop

This revision now requires review to proceed.Apr 16 2020, 2:58 PM
sys/net/if_bridge.c
746

Yeah, that's a great point. We must get rid of the loop here.

This revision was not accepted when it landed; it landed in state Needs Review.Apr 18 2020, 8:01 AM
This revision was automatically updated to reflect the committed changes.