diff options
| author | Christian Poessinger <christian@poessinger.com> | 2021-09-26 12:28:37 +0200 |
|---|---|---|
| committer | Christian Poessinger <christian@poessinger.com> | 2021-09-26 12:28:37 +0200 |
| commit | 8d6861290f39298701b0a89bd358545763cee14b (patch) | |
| tree | 710233d8df84b51f695fd6de36d3c364bde5649f /interface-definitions/include/bgp/neighbor-shutdown.xml.i | |
| parent | 289a495c8f45322d58bd849aa8aca48cf0210b03 (diff) | |
| download | vyos-1x-8d6861290f39298701b0a89bd358545763cee14b.tar.gz vyos-1x-8d6861290f39298701b0a89bd358545763cee14b.zip | |
vyos.ifconfig: T3860: bugfix in get_mac_synthetic()
Commit 081e23996f (vyos.ifconfig: get_mac_synthetic() must generate a stable
"MAC") calculated a "stable" synthetic MAC address per the interface based on
UUID and the interface name. The problem is that this calculation is too stable
when run on multiple instances of VyOS on different hosts/hypervisors.
Having R1 and R2 setup a connection both via "tun10" interface will become the
same "synthetic" MAC address manifesting in the same link-local IPv6 address.
This e.g. breaks OSPFv3 badly as both neighbors communicate using the same
link-local address.
As workaround one can:
set interfaces tunnel tun1337 address 'fe80::1:1337/64'
set interfaces tunnel tun1337 ipv6 address no-default-link-local
This commit changes the way in how the synthetic MAC address is generated. It's
based on the first 48 bits of a sha256 sum build from a CPU ID retrieved via
DMI, the MAC address of eth0 and the interface name as used before. This should
add enough entropy to get a stable pseudo MAC address.
Diffstat (limited to 'interface-definitions/include/bgp/neighbor-shutdown.xml.i')
0 files changed, 0 insertions, 0 deletions