RouterOS 5.1 talking OSPFv3 with a an existing Cisco network seems to ignore /128 routes which are used as loopback addresses for things like BGP peers and nexthops. Can this be fixed?
(Before someone jumps in about using a /64 for loopbacks, see RFC 5375 section B.2.3.)
A side effect of this problem is that it all IPv6 BGP routes are invalid because it thinks all of the nexthops (the loopbacks) are invalid.
OSPFv3 in v5.1 can advertise /128. Did you set mac address on the bridge on which loopback address is set?
It’s advertising a /128 from a loopback bridge OK, but it’s not seeing any received /128 from any other routers (all Cisco) on the network. I checked to see if there is an LSA received for the missing routes (there is) but they don’t appear in the IPv6 route table. I can provide a copy of “lsa print detail” and “ipv6 route print” by email for comparison if needed; I don’t want to post it in a public forum.
I seem to have the opposite problem. I can see /128s from its OSPFv3 neighbor but I’m unable to find a way to advertise my loopback (bridge) interface’s /128. This bridge has no ports associated with it. The same bridge is used for OSPFv2 for IPv4 and works fine when I add a network statement. There’s no such equivilant in OSPFv3.
I’ve tried manually adding an OSPFv3 interface for loopback, set passive or non passive and it does not appear- the state just says ‘down’. I’ve also tried to add ‘all’ which seems to attempt to add information about physical ethernet interfaces but not the bridge. I’ve tested on RouterOS 5.1, 5.2, and now 5.4.
You have to give the bridge a manual MAC address. See: http://wiki.mikrotik.com/wiki/Manual:Creating_IPv6_loopback_address
This isn’t related to my problem though, RouterOS seems to ignore the LSA type from Cisco routers that carry /128s from the Cisco loopback interfaces.
Thanks, you’re right. And indeed, I see no /128s from the rest of my network which is primarily Cisco. I do see some /127s and /126s however. Without /128 it appears that I cannot use loopbacks for ipv6 bgp.
I saw exactly the same thing: RouterOS will pick up everything except the /128s, and I too use those for BGP. Good to know someone else can confirm it. Hopefully Mikrotik will fix it eventually.
Indeed. as a workaround I’m peering with an interface IP. However most of my routes have /128 loopbacks as their nexthops so the routes are invalid. Basically this makes ipv6 bgp unusable on any Mikrotik on my network.
Have you opened up an official support ticket?
I’ve just done so. Interestingly /system sup-output also crashes saying “Console has crashed; please log in again.” so I was unable to send this file with the support. Also I believe it’s more than just OSPFv3- I can’t even ping my local /128 IP, although it IS pingable from other OSPFv3 hosts on my network.
Have you heard anything from Mikrotik on this? I am seeing the same issue with a mixed Mikrotik/Cisco network.
I hadn’t heard from Mikrotik support for a while but recieved this email this morning:
Thank you for the report, we will try to fix this issue in one of the nextversions.
RouterOS 5.1 talking OSPFv3 with a an existing Cisco network seems to ignore /128 routes which are used as loopback addresses for things like BGP peers and nexthops. Can this be fixed?
I didn’t see this mentioned, but it’s not just /128s from Cisco IOS that are being ignored. I’m seeing the same thing when peering with two Juniper routers. For example, OSPFv3 routes seen by Junos:
prox@zat> show ospf3 route |match /
2001:48c8:1:100::c/126 Intra Network IP 20
2001:48c8:1:104::2a/128 Intra Network IP 0
2001:48c8:1:104::2b/128 Intra Network IP 10
2001:48c8:1:104::2c/128 Intra Network IP 20
2001:48c8:1:104::2f/128 Intra Network IP 20
2001:48c8:1:131::8/126 Intra Network IP 10
2001:48c8:1:131::c/126 Intra Network IP 20
2001:48c8:1:131::10/126 Intra Network IP 10
2001:48c8:1:131::14/126 Intra Network IP 10
2001:48c8:1:131::18/126 Intra Network IP 20
Routes seen by RouterOS:
[admin@cicada] > routing ospf-v3 route print
# DST-ADDRESS STATE COST
0 2001:48c8:1:100::c/126 intra-area 20
1 2001:48c8:1:104::2f/128 intra-area 10
2 2001:48c8:1:131::8/126 intra-area 20
3 2001:48c8:1:131::c/126 intra-area 20
4 2001:48c8:1:131::10/126 intra-area 20
5 2001:48c8:1:131::14/126 intra-area 10
6 2001:48c8:1:131::18/126 intra-area 10
The only /128 RouterOS is seeing in OSPFv3 is its own loopback. I first noticed this on RouterOS 5.2 and am seeing it as well on 5.5. Not good.
Has anyone heard anything further on this issue? The changelogs do not suggest this is fixed yet in 5.6 (still running 5.4 atm)?
I’m receiving /128s just fine from Vyatta as well as other ROS routers via both OSPFv3 and BGP itself. Not use about Junos or IOS, though.
resurrecting this as it’s still not fixed. One of my more recent posts in this thread indicated that when I have a /128 assigned to a local interface (bridge as a loopback) it’s not even pingable locally. This is still the case with 5.11. I can ping the ipv4 /32 that’s on the same interface.
fewi, does this work for you? All of the hardware I’m testing on is Routerboard stuff, no x86.
edit: just discovered something interesting. If it’s xxxx:yyyy::z/128 it does NOT work. if it’s xxxx:yyyy::z:a/128 it DOES work:
[falz@rb751] /ipv6 address> set 2 address=2617:f5e1::F/64
[falz@rb751] /ipv6 address> /ping 2617:f5e1::F
HOST SIZE TTL TIME STATUS
sent=1 received=0 packet-loss=100%
[falz@rb751] /ipv6 address> set 2 address=2617:f5e1::0:F/64
[falz@rb751] /ipv6 address> /ping 2617:f5e1::0:F
2617:f5e1::f 56 64 2ms echo reply
another example:
/ipv6 address> set 1 address=1234:1234::1/128
/ipv6 address> /ping 1234:1234::1
HOST SIZE TTL TIME STATUS
timeout
sent=1 received=0 packet-loss=100%
/ipv6 address> set 1 address=1234:123::1/128
/ipv6 address> /ping 1234:123::1
HOST SIZE TTL TIME STATUS
timeout
sent=1 received=0 packet-loss=100%
/ipv6 address> set 1 address=1234:12::1/128
/ipv6 address> /ping 1234:12::1
HOST SIZE TTL TIME STATUS
1234:12::1 56 64 0ms echo reply
sent=1 received=1 packet-loss=0% min-rtt=0ms avg-rtt=0ms max-rtt=0ms
I’ve been meaning to revisit this issue using an RB751 I have on my test bench but I’ve been busy.
I don’t have any Juniper devices, but I have tested OSPFv3 with Cisco, Vyatta (quagga-based) and OpenBSD. Everything but RouterOS carries the /128s properly.
i have no such expensive gear in my test network, but my ipv6 router management ip addresses with /128 are normally redistributed over the network. That is between OSPFv3 in RouterOS.
See my examples above of ipv6 addresses that do work vs those that don’t. The ones that don’t work aren’t even pingable locally so this more than just an OSPF issue.