templates: generate unique deterministic MACs for mesh interfaces #1322
Conversation
|
I know there was a lot of discussions about this yesterday in the chats, but could you write a small overview why we need this? It was a bit to much for me to read everything afterwards |
|
Let me summarize what I understood: We're observing that on sama-sued-60ghz, the route to Zwingli is taking different paths. The reason is that incorrectly configured switches/dumb switches are causing more than one path through which the MAC address can be learned (e.g. via zwingli->sama or via zwingli->scharni/wilgu/...->sama. Currently, all VLANs have the same MAC address. By giving each VLAN its own MAC address, we solve the problem because the MAC address is then unique for each path. Therefore, we don't have to solve the original problem, although this should of course still happen. Solving the problem with unique MAC addresses per VLAN is desirable because misconfigurations can occur again (human error). |
|
Please put that into the commit message, so we can still understand the reasoning behind this change later on. |
|
@PolynomialDivision done |
We're observing that on sama-sued-60ghz, the route to Zwingli is taking different paths. The reason is that incorrectly configured switches/dumb switches are causing more than one path through which the MAC address can be learned (e.g. via zwingli->sama or via zwingli->scharni/wilgu/...->sama. Currently, all VLANs have the same MAC address. By giving each VLAN its own MAC address, we solve the problem because the MAC address is then unique for each path. Therefore, we don't have to solve the original problem, although this should of course still happen. Solving the problem with unique MAC addresses per VLAN is desirable because misconfigurations can occur again (human error).
pktpls
force-pushed
the
mesh-random-mac
branch
from
ac9a4d1 to
dc588db
Compare
No description provided.