OSPFv3 Missing /128 Routes in 5.1

SethM · Fri Apr 22, 2011 5:10 am

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.)

SethM · Fri Apr 22, 2011 5:21 am

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.

Sat Apr 23, 2011 12:01 am

OSPFv3 in v5.1 can advertise /128. Did you set mac address on the bridge on which loopback address is set?

SethM · Sat Apr 23, 2011 12:47 am

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.

falz · Sat May 28, 2011 2:58 am

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.

SethM · Sat May 28, 2011 3:30 am

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:Cr ... ck_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.

falz · Sat May 28, 2011 3:36 am

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.

SethM · Sat May 28, 2011 3:47 am

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.

falz · Sat May 28, 2011 3:54 am

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.

fewi · Sat May 28, 2011 4:28 am

Have you opened up an official support ticket?

falz · Sat May 28, 2011 7:57 pm

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.

cupis · Wed Jun 08, 2011 2:23 pm

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.

Have you heard anything from Mikrotik on this? I am seeing the same issue with a mixed Mikrotik/Cisco network.

falz · Thu Jun 09, 2011 3:36 am

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.

Prolixium · Tue Jul 05, 2011 3:03 am

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.

- Mark

cupis · Thu Sep 08, 2011 8:25 pm

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.

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)?

fewi · Thu Sep 08, 2011 8:52 pm

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.

falz · Fri Dec 30, 2011 7:53 pm

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

SethM · Mon Jan 16, 2012 9:04 pm

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.

janisk · Thu Jan 19, 2012 1:10 pm

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.

falz · Thu Jan 19, 2012 2:45 pm

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.

janisk · Thu Jan 19, 2012 3:55 pm

ok, 5.12 (for some kind of mysterious reason, but previously it worked just fine) here, i have my /64 prefix for routers and i use prefix::1/128; prefix::2/128 etc.

falz · Thu Jan 19, 2012 4:07 pm

The important part IS the prefix length. '1234

:1' doesn't work, '1234

1::1' and longer does work. At this point my testing is simply adding address like above to interfaces and pinging it locally to see if it works or not. #1 above doesn't, #2 above does.

FIPTech · Sun Jan 29, 2012 2:50 am

It is not only a prefix lenght problem :

Try that :

1234

:100 is working

1234::100 is working

1::100 is working

1234::FF is working

1::FF is working

BUT,

1234

:FF is not working !!

Then,

1234:1::FF is working....

1234:123::ff is not working... :=(

1::1 is working

1:1111::1 is working

11:1111::1 is working

111:1111::1 is not working...

I can't even see the packet flowing through the input ICMP rule when not working. NDP problem ?

Very strange isn't it.

Tested on version 5.12

Prolixium · Sun Feb 26, 2012 1:40 am

Still seeing this in 5.14... unfortunate

- Mark

Wed Mar 28, 2012 10:39 am

You can't ping those addresses only from terminal, because it parses it as MAC address. We will fix it in the future.
If you ping from winbox then there shouldn't be any problems.

FIPTech · Wed Mar 28, 2012 11:36 am

I just tested it again, and yes it is a terminal parsing problem. Does work from winbox.

falz · Sat Mar 31, 2012 8:37 pm

I can confirm this as well. Unfortunately the original bug in this thread is still a problem- /128 in OSPF doesn't work. This bug just makes it that much more difficult to troubleshoot.

Mon Apr 02, 2012 3:21 pm

We have set up Cisco router with /128 address on loopback interface and distribute connected routes.
RouterOS received that address.

c7200#show ipv6 route connected 
IPv6 Routing Table - default - 7 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
       B - BGP, M - MIPv6, R - RIP, I1 - ISIS L1
       I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
       EX - EIGRP external, ND - Neighbor Discovery
       O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
LC  111:1111::1/128 [0/0]
     via Loopback0, receive
LC  2001:DB8:1::1/128 [0/0]
     via Loopback0, receive

[admin@Test_GW] /ipv6 route> print where ospf
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable 
 #      DST-ADDRESS              GATEWAY                  DISTANCE
 1 ADo  111:1111::1/128          fe80::217:5aff:fe90:6...      110
 3 ADo  2001:db8:1::1/128        fe80::217:5aff:fe90:6...      110

You do not receive specific /128 addresses or any /128 address?

falz · Mon Apr 02, 2012 3:39 pm

Correct. Here's a Mikrotik running 5.14:

/ipv6 route print where ospf
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable 
 #      DST-ADDRESS              GATEWAY                  DISTANCE
 0 ADo  2001:d4e0::11:0:0:0:1... fe80::20d:66ff:febb:5...      110
 1 ADo  2001:d4e0::11:0:0:0:1... fe80::20d:66ff:febb:5...      110
 2 ADo  2001:d4e0::12:0:0:0:8... fe80::20a:8aff:fec4:b...      110
 3 ADo  2001:d4e0::12:0:0:0:9... fe80::20a:8aff:fec4:b...      110
 4 ADo  2001:d4e0::13:0:0:0:0... fe80::20a:8aff:fec4:b...      110
 5 ADo  2001:d4e0:100:101::/64   fe80::20a:8aff:fec4:b...      110
                                 fe80::20d:66ff:febb:5...
 6 ADo  2001:d4e0:100:102::/64   fe80::20a:8aff:fec4:b...      110
                                 fe80::20d:66ff:febb:5...
 7 ADo  2001:d4e0:100:103::/64   fe80::20d:66ff:febb:5...      110
 8 ADo  2001:d4e0:100:104::/64   fe80::20d:66ff:febb:5...      110
 9 ADo  2001:d4e0:100:105::/64   fe80::20d:66ff:febb:5...      110
10 ADo  2001:d4e0:100:106::/64   fe80::20d:66ff:febb:5...      110
11 ADo  2001:d4e0:100:107::/64   fe80::20d:66ff:febb:5...      110
12 ADo  2001:d4e0:100:109::/64   fe80::20d:66ff:febb:5...      110
13 ADo  2001:d4e0:100:121::/64   fe80::20d:66ff:febb:5...      110
14 ADo  2001:d4e0:100:122::/64   fe80::20a:8aff:fec4:b...      110
15 ADo  2001:d4e0:300:101::/64   fe80::20d:66ff:febb:5...      110

Here's its OSPF neighbor, which is a Cisco:

#sh ipv6 route ospf
IPv6 Routing Table - 8156 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route, M - MIPv6
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
       D - EIGRP, EX - EIGRP external
O   2001:D4E0::3/128 [110/110]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0::4/128 [110/110]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0::5/128 [110/110]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0::7/128 [110/120]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0::9/128 [110/110]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0::10/128 [110/110]
     via FE80::20C:42FF:FE95:9749, FastEthernet0/0.101
O   2001:D4E0::11/128 [110/110]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0::12/128 [110/100]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0::13/128 [110/110]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0::16/128 [110/110]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0::17/128 [110/110]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0::28/128 [110/220]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0::31/128 [110/110]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0::32/128 [110/110]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0:0:11::124/127 [110/120]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0:0:11::126/127 [110/120]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0:0:12::88/127 [110/110]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0:0:12::90/127 [110/110]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0:0:14::/126 [110/300]
     via FE80::20C:42FF:FE95:9749, FastEthernet0/0.101
O   2001:D4E0:100:101::/64 [110/110]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0:100:102::/64 [110/110]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0:100:103::/64 [110/120]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0:100:104::/64 [110/130]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0:100:105::/64 [110/130]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0:100:106::/64 [110/121]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0:100:107::/64 [110/121]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0:100:109::/64 [110/130]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0:100:121::/64 [110/120]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0:100:122::/64 [110/110]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13
O   2001:D4E0:300:101::/64 [110/220]
     via FE80::211:BCFF:FEE8:8800, FastEthernet0/0.13

Unsure if related- these are logged constantly on the Mikrotik:

07:29:56 route,ospf,error     src address=fe80::20c:42ff:fe95:9744 
07:29:56 route,ospf,error Discarding packet: locally originated 
07:29:56 route,ospf,error     src address=fe80::20c:42ff:fe95:9749 
07:30:00 route,ospf,error Discarding packet: locally originated 
07:30:00 route,ospf,error     src address=fe80::20c:42ff:fe95:9749 
07:30:01 route,ospf,error Discarding packet: locally originated 
07:30:01 route,ospf,error     src address=fe80::20c:42ff:fe95:9744 
07:30:06 route,ospf,error Discarding packet: locally originated 
07:30:06 route,ospf,error     src address=fe80::20c:42ff:fe95:9744 
07:30:06 route,ospf,error Discarding packet: locally originated 
07:30:06 route,ospf,error     src address=fe80::20c:42ff:fe95:9749

Indeed, fe80::20c:42ff:fe95:974* are local:

/ipv6 address print 
Flags: X - disabled, I - invalid, D - dynamic, G - global, L - link-local 
 #    ADDRESS             FROM-POOL INTERFACE          ADVERTISE
 0  G 2001:d4e0:200:101::3/64       ether10            no       
 1  G 2001:d4e0::10/128             loopback0          no       
 2  G 2001:d4e0::14:0:0:0:2/126     vlan3332           no       
 3 DL fe80::20c:42ff:fe95:9740/64   ether1             no       
 4 DL fe80::20c:42ff:fe95:9744/64   vlan3332           no       
 5 DL fe80::20c:42ff:fe95:9749/64   ether10            no       
 6 DL fe80::20c:42ff:fe95:9744/64   vlan3331           no       
 7 DL fe80::20c:42ff:fe95:9744/64   vlan3330           no       
 8 DL fe80::20c:42ff:fe95:9744/64   ether5             no       
 9 DL fe80::300:ff:fe00:100/64      loopback0          no       
10 DL fe80::20c:42ff:fe95:9745/64   bridge-vlan195     no       
11 DL fe80::20c:42ff:fe95:9747/64   vlan195

Perhaps try with the same prefix length I'm using- 1234:5678::1/128 instead of 123:4567::1/128.

ambo · Wed Apr 25, 2012 1:55 pm

Has any more progress been made with this issue?

One other thing that I have noticed is that directly connected /128 route for the loopback IP appears 'unreachable' in the winbox route list while it appears as 'ADC' via the terminal.

I also have some static routes pointing at the loopback (for BGP tie down) and they appear as unreachable on both winbox and the terminal.

Then on OSPFv3 - the loopback interface appears as 'inactive' even though the interface is up and working fine for the v4 loopback. (and before anyone asks... I've done the MAC address hack

)

The major problem with all of this is that iBGP between my routers is not coming up since the loopback IP addresses being used are not reachable.

When can we expect a fix for this? This problem was reported over a year ago.

SethM · Fri Jun 01, 2012 5:00 am

The changelogs for 6.0 betas don't say anything about this issue but I guess it's worth a look.

Fri Jun 01, 2012 11:22 am

RouterOS ignores LSAs with LA bit set which is set on loopback /128 routes advertised from cisco.
Temorary workaround until problem is fixed, is to advertise /128 routes as external (not intra-area)

interface Loopback0
no ipv6 ospf 1 area 0
!
ipv6 router ospf 1
redistribute connected
!

SethM · Fri Jun 01, 2012 8:32 pm

Thanks for the update.

LennonNZ · Wed Jun 06, 2012 1:53 am

I also have come across this problem (RB1100AHx2 running 5.17) I think. Please can this be fixed in the next version

Also the "work around" for cisco.. I don't really like advertising connected routes into OSPF3 (and I don't use cisco anyway)

IPv4 OSPF works 100%
IPv6 OSPF3 the bridge interface (as a loopback) is always down it is set with a /128 address loopback

and no routes are installed into routing table (but it sees the LSA's ok) (x.x.x.x = loopback of other router its connected to (juniper)

10:23:11 route,ospf,warning header=Summary Network LSA id=0.0.0.2 originator=x.x.x.x seqnum=0x800002d6
10:23:11 route,ospf,warning LSA installation failed
10:23:11 route,ospf,warning header=Summary Network LSA id=0.0.0.3 originator=x.x.x.x seqnum=0x8000029e
10:23:11 route,ospf,warning LSA installation failed
10:23:11 route,ospf,warning header=Summary Network LSA id=0.0.0.4 originator=x.x.x.x seqnum=0x800002d5

Work around.. static routes for loopbacks

falz · Tue Dec 11, 2012 9:36 pm

Has anyone tried out the RC's of 6.x to see if this is fixed?

Prolixium · Tue Dec 11, 2012 9:59 pm

Has anyone tried out the RC's of 6.x to see if this is fixed?

It's not fixed in 6.0rc3. In fact, all none of my OSPFv3 adjacencies come up in 6.0rc3 whereas they did in 5.x (I haven't bothered submitting a bug report, though). So, things are /worse/, now. It seems Mikrotik doesn't really care about IPv6..

- Mark

falz · Tue Dec 11, 2012 10:30 pm

Ouch.

tomaskir · Wed Dec 12, 2012 2:18 am

I wouldnt put it as "they dont care", there is simply a lot to do for v6. Submit the support ticked and bug them with emails about it, they should fix it then. v6 and CCR are major products, so OSPFv2 and v3 are high on the priority list.

Posting on forums is one thing, but getting an actual Ticket ID with history in their ticket tracker is considerably different when trying to fix something, and from Mikrotiks point of view when telling programmers to fix something.

falz · Wed Dec 12, 2012 3:04 am

I opened a ticket (#2011052866000205) in May 2011 (it's mentioned above) as well as a response from June 2011. Is there any web frontend to their ticket system to see if there's any type of status updates or silently resolved?

tomaskir · Wed Dec 12, 2012 10:27 am

Didnt notice that sorry.

And no, will just have to email support asking for a status update.

Wed Dec 12, 2012 11:21 am

There is no update for this problem.

You will need to use workaround as suggested above.

Wed Dec 12, 2012 11:35 am

There is no update for this problem.

You will need to use workaround as suggested above.

Kadafi · Wed Feb 06, 2013 12:48 pm

This will be fixed in v6.0rc9
Developers just upgraded my router. Problem solved.

cupis · Fri Feb 08, 2013 3:19 pm

What's new in 6.0rc9 (2013-Feb-08 08:15):

*) ospf - fixed Summary-LSA prefix length check for OSPFv3, was not
accepting valid LSAs;

Does anyone know if this fix will be implemented in a 5.x version?

falz · Sun Feb 10, 2013 6:47 pm

I don't seem to recall many bugfixes being ported back to previous versions, so I'm guessing "no".

Prolixium · Tue Feb 12, 2013 3:01 am

This will be fixed in v6.0rc9
Developers just upgraded my router. Problem solved.

Erm... I just upgraded to 6.0rc9. However, the problem is not solved. Can anyone else confirm? Maybe something else is wrong on my side.

- Mark

Tue Feb 12, 2013 1:30 pm

Fix is not for the problem mentioned in this topic. It fixes only summary-LSA also called inter-area-prefix-LSA.

SwissWISP · Tue Feb 26, 2013 3:53 pm

I've got the same problem on a RB1100AH which is connected to a Brocade CER. I get the /128 from the CER but not from the Ciscos behind the CER. The Ciscos all get the /128 of my RB however. At the moment it's not a big problem because I can get the /128 via BGP but hopefully it will be fixed soon.

- Mat

Ozelo · Thu Aug 08, 2013 2:34 pm

Hello there!

We are starting to implement Juniper on our backbone and it seems we jumped in kinda the same issue reported here. So let me share my experience so it may help you too.

The task was quite simple: Switch a 1100AHx2 for a MX5. Just in case, there was /128s configured on ROS 5.25 so we just copied the same configuration on Junos (at least, expecting the same results).

Surprisingly, /128s at loopback interface from Juniper was NOT being exported to other router Mikrotik. Ive opened a case at Juniper networks and we concluded that Juniper was indeed exporting the /128s without really solving the problem. So they said "different vendors may not work smoothly"... I got that, closed the case and was going to change all those /128s to /127s which was working well between Junos and ROS.

Today I was going to do that and in the middle of the proccess Ive commited a Junos config which successfully exported all the /128s. O.o Wooot??

So thats it, it allowed Mikrotik to receive the routes /128 and all I did was to remove the flag "passive" from interface ospf3 at Junos side.

"lo0.0" was set "passive" on both ospf and ospf3 protocols. As you can see, even with "passive", all the /32s for IPv4 loopback addresses are being exported but you just CANT let it the same way for IPv6 loopback addresses, will simply not work. I wonder why Junos and ROS are so different in this matter....

For those curious about it, the "policy-statements" are simply identical. Heres my ospf config on Junos:

admin@MYJUNIPER# show protocols ospf
export OSPF-OUT;
area 0.0.0.0 {
    interface lo0.0 {
        passive;
    }
    interface ge-1/1/9.0;
    interface ge-1/1/1.0;
    interface ge-1/1/2.0;
    interface ge-1/1/3.0;
    interface ge-1/1/4.0;
    interface ge-1/0/2.0;
}

admin@MYJUNIPER# show protocols ospf3
export OSPF-OUT-V6;
area 0.0.0.0 {
    interface ge-1/0/2.0;
    interface ge-1/1/1.0;
    interface ge-1/1/2.0;
    interface ge-1/1/3.0;
    interface ge-1/1/4.0;
    interface ge-1/1/9.0;
    interface lo0.0;
}

Prolixium · Thu Aug 08, 2013 5:21 pm

Hi Ozelo -

Today I was going to do that and in the middle of the proccess Ive commited a Junos config which successfully exported all the /128s. O.o Wooot??

So thats it, it allowed Mikrotik to receive the routes /128 and all I did was to remove the flag "passive" from interface ospf3 at Junos side.

"lo0.0" was set "passive" on both ospf and ospf3 protocols. As you can see, even with "passive", all the /32s for IPv4 loopback addresses are being exported but you just CANT let it the same way for IPv6 loopback addresses, will simply not work. I wonder why Junos and ROS are so different in this matter....

Interesting..

I just tried this with RouterOS 6.2 on x86 and Junos 12.1X44-D10.4 on an SRX210.. no dice. RouterOS still did not learn the /128 from the SRX210. I even cleared the OSPFv3 neighbors for good measure. To be honest, if this had worked I would have opened up a case with Juniper because it shouldn't make any difference whatsoever

(I'm curious why it's working for you)

- Mark

Ozelo · Thu Aug 08, 2013 7:43 pm

Yes, Ive found something else. Ive upgraded the ROS to 6.2 to see if anything changes and now Im willing to upgrade Junos. Im using version 11.4X27.44

I found that it is not really working as expected. To follow up what Im facing, consider the following: At Mikrotik side, nothing special. I just put up a router id and added the interface facing Junos unde routing/ospfv3/interfaces. At Junos side, please have a look at this policy below (the IPv6 one come from Juniper support).

The thing Im facing is:
1-Restart Junos, ROS IPv6 route list show only the /127;
2-Issue "delete protocols ospf3 area 0.0.0.0 interface lo0.0" then commit, ROS IPv6 route list show the /128s but NOT the /127;
3-Issue "set protocols ospf3 area 0.0.0.0 interface lo0.0" then commit, ROS IPv6 route list show both the /128s and the /127;
4-Restart Junos, ROS IPv6 route list show only the /127; (repeat step 2 and 3 to get all things working till next Junos restart)

Very ODD.

admin@MYJUNIPER# show interfaces lo0
unit 0 {
    family inet {
        address x.x.x.2/32;
        address x.x.x.254/32;
        address x.x.x.20/32;
        address x.x.x.13/32;
    }
    family inet6 {
        address x:x::2/128;
        address x:x::13/128;
        address x:x::20/128;
        address x:x:0:3::254/128;
        address x:x:0:df::2/127;
    }
}

admin@MYJUNIPER# show protocols ospf
export OSPF-OUT;
area 0.0.0.0 {
    interface lo0.0 {
        passive;
    }
    interface ge-1/1/9.0;
    interface ge-1/1/1.0;
    interface ge-1/1/2.0;
    interface ge-1/1/3.0;
    interface ge-1/1/4.0;
    interface ge-1/0/2.0;
}

admin@MYJUNIPER# show protocols ospf3
export OSPF-OUT-V6;
area 0.0.0.0 {
    interface ge-1/0/2.0;
    interface ge-1/1/1.0;
    interface ge-1/1/2.0;
    interface ge-1/1/3.0;
    interface ge-1/1/4.0;
    interface ge-1/1/9.0;
    interface lo0.0;
}

admin@MYJUNIPER# show policy-options policy-statement OSPF-OUT
term 1 {
    from {
        protocol direct;
        route-filter 172.25.3.0/30 exact;
    }
    then reject;
}
term 2 {
    from protocol direct;
    then {
        external {
            type 1;
        }
        accept;
    }
}
term 3 {
    from {
        protocol static;
        route-filter 0.0.0.0/0 orlonger;
    }
    then {
        external {
            type 1;
        }
        accept;
    }
}

admin@MYJUNIPER# show policy-options policy-statement OSPF-OUT-V6
term 1 {
    from protocol direct;
    then {
        external {
            type 1;
        }
    }
}
term 2 {
    from {
        protocol direct;
        rib inet6.0;
        route-filter 0::0/0 prefix-length-range /128-/128;
    }
    then {
        external {
            type 1;
        }
        accept;
    }
}
term 3 {
    from {
        protocol static;
        route-filter 0::0/0 orlonger;
    }
    then {
        external {
            type 1;
        }
        accept;
    }
}

Sun Jan 19, 2014 11:49 pm

Can anyone confirm if this bug still exists in RouterOS 6.8 ?

bryantabb · Sat Feb 08, 2014 9:59 am

Can anyone confirm if this bug still exists in RouterOS 6.8 ?

just did a quick test between a x86 v6.9 vm and a cisco CSR1000v and yup problem still there

basic setup was /128 on loopback \ bridge (with MAC address assigned) and with a /64 on the physical interfaces

on the cisco side still had to use redistribute connected under ipv6 router ospf xx with no ipv6 ospf config on the loopback interface before mikrotik would install the cisco loopback address in the routing table

paoloaga · Sat Feb 08, 2014 8:09 pm

I am also waiting for this bug to be fixed. I manage a large network and I need to have loopbacks inside OSPF and not advertised as external.

chocbanana · Thu Apr 30, 2015 7:33 am

This issue is STILL present in latest release 6.28... mikrotik pls

Below is a .pcap of an ignored OSPFv3 LSA, from a Brocade CER, with a single /128 (LA bit set) -- encoded as base64 since it won't let me attach.

1MOyoQIABAAAAAAAAAAAAP//AAABAAAAJP0/VZnKDQC2AAAAtgAAADMzAAAABXSO+Kc5g4bdbAAA
AACAWQH+gAAAAAAAAHaO+P/+pzmD/wIAAAAAAAAAAAAAAAAABQMEAIBn40MCAAAAAEHgAAAAAAAC
AAEgAQAAAABn40MCgAAAFhkcADgAAAATAgAAAQAAAAIAAAADZ+NDAwIAAAEAAAADAAAABWfjQwQA
ASAJAAAAAGfjQwKAAAATaEwANAABIAEAAAAAZ+NDAoACAAAgAIAABmYAAAAAAAAAAAAB

EDIT: Just found another thread discussing the problem and a post from mrz saying it will be fixed in ROS 7.

lcm · Wed Nov 11, 2015 11:38 pm

Which Thread?

On my case, i can create a bridge for loopback, it is up and runnning, but when i ADD the loopback interface to ospfv3, it will not advertive my /128 address and the state of the interface on OSPFv3/interfaces is "Down"

is it the same problem?

Wed Nov 11, 2015 11:50 pm

Which Thread?

On my case, i can create a bridge for loopback, it is up and runnning, but when i ADD the loopback interface to ospfv3, it will not advertive my /128 address and the state of the interface on OSPFv3/interfaces is "Down"

is it the same problem?

Yes, the same problem.

Mikrotik confirmed a long time back that the issue will be fixed in RouterOS v7.

With any luck we will see a beta of this by the end of the year.

StubArea51 · Thu Nov 12, 2015 12:17 am

I hope you're right NZ_Monkey, would love to see this and a bunch of other stuff fixed in v7 and be able to test by the end of the year.

Thu Nov 12, 2015 12:53 am

I hope you're right NZ_Monkey, would love to see this and a bunch of other stuff fixed in v7 and be able to test by the end of the year.

I am optimistic!

We have been holding back rolling out a bunch of new services as we need fixes and features that will only be in v7.

e.g.
- This bug is holding us back from IPv6 rollout.
- Lack of "Add to address list" action in Route Filters is making it time consuming to meet BCP's
- Inability to view advertised/received prefixes on a BGP session within a VRF (PE-CE) is causing daily troubleshooting headaches.
- BFD bugs on v6 mean we cannot detect partial Layer2 path failures.

khemara · Sat Jan 16, 2016 10:32 am

Dear All,

A workaround for me is that: on the Cisco router, I set the Loopback interface to an area number other than 0 (backbone):

# conf t
(config)# int lo0
(config-if)# ipv6 ospf 123 area 10

After that, I could see the /128 IPv6 address that belongs to the Loopback interface on Cisco router in the route list on Mikrotik:

> ipv6 route print where ospf

And the page that gave me some hints was this:
https://cciethebeginning.wordpress.com/ ... work-type/

Hope this helps and there is a fix for next ROS release soon.

Thanks,
Khem

rganascim · Wed Jan 27, 2016 7:42 pm

This issue still exists in 6.33.5.

Router OS ignores intra-area-prefix with Prefix-options set to LA (0x02).

Workaround: export the loopback as external.

(2 years and not solved yet)

Thu Jan 28, 2016 2:05 pm

There will be no fix for this problem in ROS v6.

StubArea51 · Thu Jan 28, 2016 6:42 pm

There will be no fix for this problem in ROS v6.

Thanks MRZ, can you let us know why?

gius64 · Thu Jan 28, 2016 11:52 pm

There will be no fix for this problem in ROS v6.
Thanks MRZ, can you let us know why?

I think they'll fix it in ROS v7

Fri Jan 29, 2016 4:42 pm

Exactly, v7 will have the fix. Too much code need to be modified to fix those ospf bugs in ROS v6.

StubArea51 · Mon Feb 01, 2016 7:45 pm

Exactly, v7 will have the fix. Too much code need to be modified to fix those ospf bugs in ROS v6.

Will RouterOS V7 be announced as ready at MUM Europe

?

Mon Feb 01, 2016 8:05 pm

I hope that ROS v7 will also fix this OSPF bug:

R1 = static default GW with ping test, OSPF redistribute-default if-installed-as-typeX
R2 = floating static backup default GW, OSPF redistribute-default if-installed-as-typeX

If R1's default GW goes down, R2 takes over, but R2 will ignore OSPF-based default GW from R1 when R1's default GW comes back online. Manual intervention is currently necessary in order to restore routing to the desired original state.

Tue Feb 02, 2016 5:05 am

Exactly, v7 will have the fix. Too much code need to be modified to fix those ospf bugs in ROS v6.
Will RouterOS V7 be announced as ready at MUM Europe ?

I sure hope so.

I am waiting on this fix for us to be able to do a full scale roll-out of IPv6 on our main network.

paoloaga · Wed Feb 17, 2016 12:22 pm

This, and also recursive nexthop lookup for IPv6 BGP routes. It is blocking our IPv6 deployment, and it is becoming a huge issue.

StubArea51 · Wed Feb 17, 2016 3:52 pm

This, and also recursive nexthop lookup for IPv6 BGP routes. It is blocking our IPv6 deployment, and it is becoming a huge issue.

+1000 !

Yes, can't wait for recursive routing to be available in IPv6

ecaps · Tue Dec 27, 2016 3:15 pm

Hi!

hmm - i guess there is no news about that issue?

did anyone find a workaround for that?

and i thought mikrotik is useable as a bgp border.

JimmyNyholm · Fri Dec 30, 2016 4:45 am

Hundred versions and five years later no fix.
This year ends with Mikrotik Promising to fix this issue that lasted over 2 major versions in the 3 major that they are eagerly denying has officially been presented as of yet. No internal Alfa exists hence no external Beta exist and no Product with version 7 is promised to ever come out officially but it is then we will get working ipv6.

Thanks for nothing.
PS. Thanks for the good jobb you are doing. but stuff like this takes the charm out of that to DS.
PS2. My bitterness comes from that now I am suffering too DS.

May 2017 be the year when Mikrotik Officially Announces the Arrival of RouterOS 7.0 and deliver on the long awaited "promise".

cheeze · Fri Dec 30, 2016 7:36 am

For what it's worth, Mikrotik is just not there on IPv6 yet. I hate to say it, but they just are not in the current routing stack. It's better to just do IPv4 and MPLS related networking which....lets be honest is most of what networking entails right now. So for more stability and operation I would say it's probably best to just stick with IPv4 only on Mikrotik.

The thing that they are focusing is making version 6 as good as they can without touching the routing stack. That's why they are focusing on everything except the routing stack. The routing stack is going to get forklifted in once they feel they are where they want to be for initial release on version 7. What will likely happen is that version 7 will have a couple of new features but mostly bug fixes on release. The easy features will likely be added first (like IPv6 recursive BGP resolution, OSPF3 fixes, and such). Then every 2-3 releases (assuming they do a release every 2 to 3 months) or so they will likely release larger features. Then that will go on for probably most of ROS 7.

Obviously it's all speculation but I'm GUESSING that that's what they are likely focusing on for this next year. In the meantime until ROS 7 actually gets the release it will be things they can fix with ROS that don't touch the stack. Which is frustrating for us but, I actually want to say is good as well. It's not what we all want but...well...they can't throw away the work they have put into ROS 7. They probably have put in a good amount of it now and they are likely at the 50% mark of where they want to be for "release" or at least for beta. I do honestly question if it's a good idea for Mikrotik at this point to do their own routing stack. It's a *lot* of work. An absurdly large amount of work. I almost want to say not business feasible amount of work. It probably would be better for them to go with IP Infusion and get ZebOS routing/switching stack for ROS. It would add a *lot* of features for both routing and switching. Integrating said stack would be a lot of work and it would take some control away from Mikrotik but....I think in the end it would be better for them if they went this route. Who knows, maybe they did go this route and the reason everything is taking so long is because they have to reconstruct the entire back end to use the new routing stack. I have no idea though. I wish we knew. I wish we knew if Mikrotik is writing literally everything from scratch or if they are using an outside routing stack.

I just wish so much that we were given an expected release beta feature list or at least a "this is what we would like to get done for ROS 7 on initial release." I know it will likely be in 2017, and likely around the late spring/early summer timeframe. That's my "gut feeling" at least. I have no proof of any of it.

yasu1976 · Mon May 14, 2018 5:11 am

Hi.

The patch attached worked for our case.

I understand, for MikroTik and its users, it may be a bigger problem
than just fixing a source code, but.

Hope this helps.

regards,
Yasu

Who is online