BGP peer could ping both IPv4 and IPv6 global loopback IPs from its and vise versa. The nexthop address was incorrectly set to the dynamic link local address belonging to a bridge called 'hosting', instead of the 'lo' loopback bridge.
The problematic site had been commissioned at the beginning of us receiving our first IPv4 address block. The allocation was relatively tiny (/22) so address preservation resulted in us allocating overlapping IPs to the 'lo' (41.0.0.1/32) loopback and 'hosting' (41.0.0.1/27) bridges. The hosting subnet was intended to provide easy service provisioning for customers simply wanting public internet access.
Router that establish multi-protocol (ip, ipv6, l2vpn) BGP sessions towards route reflectors configured with 'nexthop-choice=force-self update-source=lo' store the elected IPv4 source address used to establish the session. RouterOS, when advertising an IPv6 prefix, attempts to first use the interface's IPv6 global address ahead of the link local address by referencing the interface using the IPv4 address used for the peering session. I believe this process not to implement longest prefix match.
The result is that RouterOS attempts to retrieve a non-existent global IPv6 address from the 'hosting' bridge and therefor chooses its link local address. This may also manifest itself to appear that RouterOS selects a seemingly random IPv6 source address, should the 'hosting' bridge have had a global IPv6 address assigned to it, by miss interpreting the reference to random IPv6 source selection in the 'BGP nexthop selection and validation in RouterOS 3.x' documentation.
We were fortunate that this site exclusively contained customers where we manage each customer behind their own routers. We could subsequently simply drop the 41.0.0.1/27 IPv4 assignment on the unused hosting bridge.
Reference:
https://wiki.mikrotik.com/wiki/Manual:B ... uterOS_3.x
Snippets:
Code: Select all
As the last fallback, use the address used to establish the connection. (In case of IPv6 connection between the peers, use a random IPv4 address of the connection's interface. Same applies to IPv6 nexthop with IPv4 connection.)
This isn't normally a problem as loopbacks simply have single IPv4 and IPv6 addresses.
Code: Select all
Select global nexthop in the same way we would select IPv4 nexthop.
<snip>
take as nexthop the link-local address belonging to the interface used to establish the connection with remote peerInterface selection is most probably currently simply the first where IP is equal the one used to connect to the peer, instead of using a longest prefix match technique.