summaryrefslogtreecommitdiff
path: root/data/templates/frr/pimd.frr.tmpl
diff options
context:
space:
mode:
authorChristian Poessinger <christian@poessinger.com>2021-09-26 12:28:37 +0200
committerChristian Poessinger <christian@poessinger.com>2021-09-26 12:36:19 +0200
commite4812d266ea841f8baf5ad6c7cfae1c7eba664b6 (patch)
tree0e659ded033cf139f86be067874d6c2d47852e56 /data/templates/frr/pimd.frr.tmpl
parentbfe59076f8075083920143cfb4ae22617aa0c663 (diff)
downloadvyos-1x-e4812d266ea841f8baf5ad6c7cfae1c7eba664b6.tar.gz
vyos-1x-e4812d266ea841f8baf5ad6c7cfae1c7eba664b6.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. (cherry picked from commit 8d6861290f39298701b0a89bd358545763cee14b)
Diffstat (limited to 'data/templates/frr/pimd.frr.tmpl')
0 files changed, 0 insertions, 0 deletions