Today I again chased a forwarding Problem in our Network integrating a new PTP Link. Behaviour is still flaky.

While integrating the link I started without doing OSPF/MPLS over the link itself. The IPs used by the link (gateway on both sides, Link addresses) where not reachable by parts of the network. Nailed it down to a MPLS router on the path. Route was there, Route was in the MPLS forwarding table. Ping from this router to the link does not work and does not show up with packet sniffer started on the same router. So ROS silently drops packets ignoring MPLS forwarding table.

Enabled OSPF/LDP on the new link does not repair the problem. Then disable/enable the IP address on one side of the link makes it work. So this seems to trigger the problematic router 2 hops away to sync its MPLS forwarding table to wherever it needs to be.

These strange effects are there for years now.

I use latest Long-Term ROS everywhere.

A few questions...

What hardware and long term version?

Are you running VPLS?

Are your OSPF and LDP timers matched?

A few questions...

What hardware and long term version?

Are you running VPLS?

Are your OSPF and LDP timers matched?

CCR-1036-8G-2S+ 6.46.8
OSPF/LDP Timers default: OSPF: 5/1/10/40 LDP: 5/15
VPLS: yes (This is our reason to use MPLS).

I have seen this kind of behaviour at differnet sites over the years. This is triggered by a network change or a reboot. With normal operation there is no problem. Most time LDP disable/enable resolves the problem. I guess the MPLS Table is not translated into an internal forwarding table/mechanism under certain conditions.

A few questions...

What hardware and long term version?

Are you running VPLS?

Are your OSPF and LDP timers matched?

CCR-1036-8G-2S+ 6.46.8
OSPF/LDP Timers default: OSPF: 5/1/10/40 LDP: 5/15
VPLS: yes (This is our reason to use MPLS).

I have seen this kind of behaviour at differnet sites over the years. This is triggered by a network change or a reboot. With normal operation there is no problem. Most time LDP disable/enable resolves the problem. I guess the MPLS Table is not translated into an internal forwarding table/mechanism under certain conditions.

Here's a few things to run through.

1. Move to 6.47.9 long term - it's got some fixes for OSPF and we've used it in quite a few client networks on CCR1036-8G-2S+ without issues. Be sure every MPLS router is running the same version - if there are different versions, it's not uncommon to have random issues

2. Verify the MAC address for a VPLS interface wasn't accidentally copied / pasted and duplicated inadvertently - this is one of the most common but hardest to detect mistakes we see because the failures are intermittent and clear after enable/disable or reboot.

3. Ensure there isn't a router-id overlap for OSPF or LDP between non-connected routers - this won't show up in a log as a "dup router id" and will cause instability in OSPF LSAs and the MPLS forwarding table.

4. RF backhauls sometimes interfere with multicast - have seen this more than once with Ubiquiti AirFiber - use a packet capture to ensure the multicast groups for OSPF and LDP are working.

Thanks for the infos. As routing/forwarding table is accurate on the problematic router update imho point 1 is the main point...

A few questions...

What hardware and long term version?

Are you running VPLS?

Are your OSPF and LDP timers matched?

CCR-1036-8G-2S+ 6.46.8
OSPF/LDP Timers default: OSPF: 5/1/10/40 LDP: 5/15
VPLS: yes (This is our reason to use MPLS).

I have seen this kind of behaviour at differnet sites over the years. This is triggered by a network change or a reboot. With normal operation there is no problem. Most time LDP disable/enable resolves the problem. I guess the MPLS Table is not translated into an internal forwarding table/mechanism under certain conditions.

As IPANetEngineer said above,

Set your hello timer in ospf to 5s to match your ldp timer settings. (Or set ldp to 10s for hello timer, but 5s ospf hello seems to work fine)

I have a somewhat large ospf/mpls/ldp/vpls network, and I used to have that problem on occasion. One of the steps was infact making the hello timers the same. Typically a down stream router would have a stuck routing table, and I would have to track down which one had it, and restart it. Its been quite some time. One of the other things I had done was mpls advertise filtering, but IIRC the timers was the root issue.

6.47.7 and 6.47.8 have been very good to me on my equipment, which is 90% ARM and 10% CCR. I have some on 6.47.7 and some on 6.47.8, and the two seem to play well together. I believe most of the changes in that series were ARM stability issues, which I experienced. The earlier versions of 6.47 had some snmp/ARM issues.

Question, Are you using BFD in OSPF?