MPLS LDP IGP Synchronization

A common problem with MPLS networks that are running LDP is that when the LDP session is broken on a link, the IGP still has that link as outgoing; thus, packets are still forwarded out of that link. This happens because the IGP installs the best path in the routing table for any prefix. Therefore, traffic for prefixes with a next hop out of a link where LDP is broken becomes unlabeled. Consecutively, MPLS VPN data packets can be discarded and VPN traffic is black-holed.

RFC5443 introduce a great solution for this problem which is know “LDP IGP Synchronization”. Before we dig into how LDP IGP synchronization is working, let us go through an example explain to us when and how the traffic can be blackholed which will need to call “LDP IGP synchronization” to fix.

In the topology below, will see that the traffic from CE1 to CE2 takes the path PE1-P3-P4-PE2 which is the normal behavior of LDP to follow the IGP. The next traceroute output can explain this.


let us now fail the LDP session between R3 and R4 and examine the effect on the traffic forwarding on both IP and VPN traffic.

In case of pure IPv4 traffic, R3 will un-tag the traffic and forward the packets unlabeled to R4. R4 will tag the traffic again and continue forwarding the traffic as normal MPLS traffic.

The next trace output from PE1 to PE2 loopback0, explain what happened.

So, there is not a big problem for networks that are running IPv4-over-MPLS only. At the point where LDP is broken, the packets become unlabeled and are forwarded as IPv4 packets until they become labeled again on the next LSR.

Now, let us examine the case of VPN traffic. The below traceroute output shows that the traffic is blackholed in the MPLS cloud !!

Here is the explanation for what had happened..  In the case of MPLS VPN, the packets are IPv4 packets, but they are encapsulated with two labels which are a VPN label and LDP label. Normally the P routers (P3, P4) are not aware about the VPN routes and they forward the VPN traffic based on the outer LDP label. Therefore, when the MPLS VPN packets become unlabeled on the P routers—they are dropped. The following diagram explain this.




The solution is MPLS LDP-IGP Synchronization [RFC5443]. This feature ensures that the link is not used to forward traffic when the LDP session across the link is down. Rather, the traffic is forwarded out another link where the LDP session is still established.

When the MPLS LDP-IGP synchronization is active for an interface, the IGP announces that link with maximum metric until the synchronization is achieved, or until the LDP session is running across that interface. The maximum link metric for OSPF is 65536 (hex 0xFFFF). No path through the interface where LDP is down is used unless it is the only path.

Will run the LDP IGP Synchronization now, and see how it fix out issue…

 

 

Let us have a look to P3 OSPF Database, and see what have been changed… ya! now P3 as shown below is advertising P3-P4 link with metric of 65535 which is the maximum metric

This will cause IGP to prefer the path through P5 to forward the traffic and avoid the P3-P4 link where LDP is broken. Now let us come back to CE1 and run a trace to CE2 and see how it will work


That is really great … I am happy 🙂 I hope that you happy too. thanks to [RFC5443]. Now let us have a look on the configuration of this feature in both IOS and JUNOS. (to be updated)

Thank you.


Ahmad Alhady


This entry was posted in MPLS, Uncategorized. Bookmark the permalink.

Leave a Reply