Hello everyone.

I currently have a full OSPF/MPLS network based on CCR2004 routers thats been operational for quite some time. I use a mixture of 25G and 10G uplinks. I've recently been working to add P routers into my network above the existing architecture and migrating to 100G full links.

For the new CCR2216 links, I've created new /30 IP spaces for the adjacencies. added OSPF/MPLS and all is well.
Over the past 2 days I've been working to migrate some existing connections from the CCR2004 network to uplink directly to the new CCR2216. When doing this, i first remove the /30 IP from the existing CCR2004 and all OSPF (/routing/ospf/interface-template) and mpls LDP interface (/mpls/ldp/interface). I then put the IP from the CCR2004 and establish the OSPF adjacencies. This is where the odd problem occurs.

The loopback IP will ping from the CCR2216 to the CCR2004 that I'm migrating, but the CCR2004 cannot ping the CCR2216 loopback. I checked the route table and the routes are pointing towards the correct interface and IP, it just returns a timeout. I thought this was specifically an issue with OSPF, but it does not appear to be the case. the MPLS (/mpls/ldp/neighbor/print) shows a DW flag on the CCR2004 for establishing the adjacency, and the CCR2216 shows a DT flag towards the CCR2004. I have no advertise-filters or accept-filters enabled on either router at this stage to rule out some odd behavior there. The only way I can get the MPLS adjacency to establish is by disabling all VPLS connections (/interface/vpls), waiting about 30 seconds for the MPLS adjaency to go trom DW/DT to DO, and then re-establing the VPLS sessions. Side note, the entire time on the CCR2004, it shows all VPLS sessions are running, but they are passing zero traffic, and the tunnel even shows a DOtv status.

I think this is a bug of sorts within MPLS but I'm hoping someone can share some insight into why this behavior may be occuring or if they have experienced anything similar.
I've tried changing the IP addresses on the L3 side instead of migrating the existing and the MPLS behavior seems to be the same. Why it affects the OSPF loopback address that should really have nothing to do with MPLS at this point is where I'm at a loss.

Thanks

Hi!
Can you try it with RouterOS v7.17.beta2? There are some changes in mpls code.
oreggin

@digitallystoned - If you think it might be a bug, it’s probably better to check with Mikrotik Support. Otherwise, I’d suggest coming back with a simple network diagram to make it easier to follow your thought process, plus a full export from both devices (minus anything that needs to be left out for privacy reasons).

Be sure that you have some thing like this in your config .

/routing filter rule
add chain=ospf-in disabled=no rule="if (dst in 10.29.0.0/24 && dst-len in 24-32) { set pref-src 10.29.0.1; accept }"

where 10.29.0.0/24 is a loopbacks range and 10.29.0.1 is loopback ip installed on RT.

Make your you have your transport address specified on your MPLS/LDP instance. I had a similar problem and realized I missed this on a few of my 7.x routers, drove me batshit for a bit.

All,

After some further troubleshooting and some more lab work, I was able to determine the cause of my issue. I run 3 separate Loopback subnets (10.5.0.0/24, 10.5.1.0/24, 10.5.2.0/24) for my MPLS LO addresses (see picture attachment). I was actually doing some upgrade work to 7.16.2 from 7.16.1 on a production router and one device dropped offline, so i began troubleshooting. The issue I had was that i wasn't using advertise filters anywhere and i actually had a label problem. When i checked my /mpls/forwarding-table/print I found that geting from the downstream device (10.5.1.6) back to the upstream device (10.5.2.2) i had a label=4xxx instead of a label=impl-null. I was connecting a VPLS from 10.5.1.6 to 10.5.0.1, and because I wasn't filtering, if the MPLS/VPLS session between those two routers came up before the MPLS negotation between 10.5.1.6 and 10.5.2.2, I would get the DT issue on 10.5.2.2 because it was sending traffic downstream (confirmed by pings) but 10.5.1.6 would timeout because it had a label it shouldn't have. This may be a bug in 7.16.x code since I don't recall having the issues under 7.15.x code.

And for those that need assistance with multi subnet MPLS advertise filters, depending on the routers purpose the advertise-filters need to be adjusted. For example, for 10.5.0.1 the advertise-filters were prefix=10.5.0.0/24 advertise=yes, followed by 0.0.0.0/0 advertise=no. The 10.5.1.6 router was similar with the prefix 10.5.1.0/24 instead. For the 10.5.2.x routers in the network, I had to actually filter on all 3 subnets with the default deny in order for the filtering to work as expected. the VPLS sessions would not initialize. Hope this helps someone else in the future.