When I first read about LDP-IGP synchronization, I couldn’t really understand what it was about until I tested it out. We will continue using the network diagram from our previous MPLS articles:

The configuration is the same as in the other articles except that I have used the BGP next-hop-self command between the BGP neighbors (PE1 and PE2) so that the next-hop of the customer networks on the PE routers is seen as the other PE router as shown below:

Now let me explain the problem: In our scenario, only PE1 and PE2 know about the customer routes via BGP; the core routers (P1 and P2) only forward customer routes using labels without any actual knowledge of these routes. You can refer to the previous article for more explanation on this.

CCNA Training – Resources (Intense)

When the network is operating normally, i.e., IGP is converged and LDP sessions have formed and labels distributed, the path through P1 is the preferred path for forwarding traffic between the customer networks, as highlighted below:

But what happens if the path through P1 goes down, maybe because of a link failure? The IGP will attempt to find an alternate path. Using PE1 as an example, OSPF will discover that it can still reach PE2 (4.4.4.4) through P2. Since PE1 already has the remote binding of 4.4.4.4/32 received from P2 in its LIB, that label is then installed in the LFIB and used for forwarding instead of the one from P1.

Therefore, there is just a little downtime to allow OSPF find the alternate path. But what happens when the link through P1 is restored? The IGP quickly converges but LDP does not converge as fast (because it relies on IGP). Therefore, PE1 will begin using the path through P1, sending the packets as unlabeled packets – normal IP packets. When P1 receives that packet and tries to process it, it discovers the route is not in its routing table and so the packet is dropped.

Let’s simulate this: CE1 will send a continuous ping to CE2 and, in between, I will shut down the P1 router and then bring it back up again.

Notice that we have two streams of packet loss. The first one occurs while OSPF tries to find an alternative path. Then the ping is successful again. Afterward, when I restart the P1 router and it comes back up, OSPF converges first; PE1 sends the packets through P1 unlabeled but, because P1 does not have a route to that network, the packets are dropped.

Afterwards, the LDP session forms between PE1 and P1; P1 distributes labels to PE1 and PE1 is able to encapsulate the traffic with MPLS headers so the ping is successful again.

In this case, we have just four packet losses but the problem may be escalated when a link is flapping, for example. This problem occurs because, even though LDP relies on the IGP, they are not synchronized. This brings us to the solution: LDP-IGP Synchronization. It works by “discouraging” a link from being used if the LDP session is not yet operational on that link. This “discouragement” is done by setting the cost of that link to the maximum value until the LDP session comes up. At the moment, only OSPF and IS-IS supports LDP-IGP Synchronization in Cisco IOS. In OSPF, the maximum cost link is 65535.

LDP-IGP synchronization is configured under the OSPF process using the mpls ldp sync command. In our scenario, I will be configuring it on both PE1 and PE2. The reason I also have to configure it on PE2 is because of the return traffic in our example.

We can use the show ip ospf mpls ldp interface command to confirm that LDP-IGP synchronization is turned on.

Now let’s test using the same repeating ping.

Notice now that we have only one stream of packet losses when OSPF is trying to find an alternate path. We can also view some commands to see LDP-IGP synchronization in operation. Below, we see that the interface was sending the maximum metric through that interface after the OSPF process came up but before the LDP session was formed.

Now when the LDP session came up, notice PE1 is now sending the correct metric for that link.

In this example, we have seen that LDP allowed the IGP adjacency to be formed between the LDP neighbors because there was no other link to reach 2.2.2.2 (the LDP router ID of P1). In cases where there is another link to reach that peer, the IGP will wait to form the adjacency indefinitely unless the LDP session is formed. For example, if I shut down the Fa0/0 interface of P1, the LDP session between P1 and PE1 will go down; however, PE1 still has a route to 2.2.2.2 via P2.

Therefore, the LDP will not allow the IGP form an adjacency over that link until the LDP session is formed. I will now bring up that interface; notice that the LDP session comes up first before the OSPF adjacency is formed.

If you don’t want the IGP to wait indefinitely, you can configure a hold time after which the IGP adjacency forms to enable the LDP session come up. We use the mpls ldp igp sync holddown global configuration command to achieve this.

Summary

This brings us to the end of this article where we have considered the problem between LDP and IGP that even though LDP relies on IGP, there is no synchronization between them. This can result in packet drops if a link fails or there is link flapping. We then looked at the solution to this, which is LDP-IGP synchronization where a link is discouraged from being used (by sending the maximum metric on that link) if the LDP session is not formed between the neighbors.

I hope you have found this article helpful and I wish you success in your further studies.

References and Further Reading

  1. MPLS Fundamentals by Luc De Ghein
  2. RFC 5443: LDP IGP Synchronization: http://tools.ietf.org/html/rfc5443