Hi,
I’m trying to figure out what is happening in the following scenario:
The router has OSPF route to PE 10.0.0.189 loopback via correct gateway
The router has MPLS labels to PE 10.0.0.189 loopback via correct gateway
But… traceroute doesn’t find the gateway to send the packet labeled.
Is that a RouterOS MPLS bug?
Sometimes, OSPF converges to correct gateway, MPLS LDP stucks on wrong gateway (do not follow OSPF convergence):
Hey. Did you fix this? If yes, then how? If no, have you tried OSPF process reset?
The MIkroTik implementation of MPLS/LDP does not have fast reroute, so first OSPF timers must expire and then LDP timers have to also expire before a path is moved over. Sometimes this happens under a minute and sometimes it takes longer.
In, general though, we’ve deployed a large number of MPLS based MikroTik networks with multiple paths and not found this to be a widespread issue.
How long are you waiting for the path to change?
I presume there to have been a network interruption which resulted in OSPF reconverging but LDP not having timed out.
The following thread details the same problem, we have not had a subsequent problem since matching OSPF and MPLS LDP interface timers:
http://forum.mikrotik.com/t/mpls-incorrect-forwarding-table/103749/1
Hi,
This week we had another failure similar to this:
When there is a fault in L2 path, RB converges OSPF correctly to the new best path. But MPLS still tries the earlier interface, causing traffic loops.
The solution: disable MPLS LDP and re-enable it
When fault is corrected in L2 path, RB again converges OSPF correctly, but MPLS keeps freezed on the earlier interface, causing traffic in both interfaces.
The solution: disable MPLS LDP and re-enable it
When LDP is disabled and enabled again, MPLS “unfreezes”, refresh all LSP and agrees (sync) with OSPF decisions.
The example below shows OSPF route to 10.0.0.248 converged correctly via VLAN 195, but MPLS route still on earlier path (ether3):
