LDP Session Protection
LDP session protection is a feature which automatically creates targeted LDP neighborships for all directly connected neighbors. When this feature is turned on, each directly connected neighbor has two discovery methods - one through the dynamic discovery on the interface, and one through the targeted LDP session.
What is the benefit of this? If the interface used to reach the LDP neighbor goes down, by default the LDP session goes down and all label bindings are lost. When the interface comes back up, both IGP and LDP have to reconverge. However, LDP neighbors can be multiple hops away by using a targeted session. (Remember that LDP uses a TCP session which is multihop-capable). When you turn on session protection and the interface used to reach the directly connected neighbor goes down, the targeted session to that same neighbor stays up as long as there is an alternative path to reach that neighbor.
While this interface is down, you won’t actually use the label bindings for traffic, because that neighbor is no longer directly connected and no longer a nexthop for prefixes in the RIB. The IGP takes care of that part (reconvergence). But when the directly connected interface comes back up, you don’t have to rebuild the label bindings database for the neighbor and reconverge on LDP, because the session stayed up the entire time.
The benefit of session protection is mostly seen when links are flapping up and down. You have to continuously reconverge on the IGP, but when using LDP session protection, LDP does not have to continually rebuild the session and LIB as long as there is an alternative route to the neighbor.
In this article, we’ll first lab targeted sessions only. You might be used to using targeted sessions with Martini circuits (which forms targeted LDP sessions automatically based on neighbor statements in L2VPNs). We can also form targeted sessions manually. After we explore manual targeted sessions, we’ll enable session protection, which is essentially just automatic target session for all dynamically discovered neighbors.
Lab - Targeted LDP Sessions (Manual)
We’ll re-use the lab from the LDP/IGP Sync article, but with no LDP authentication.
Let’s first configure a targeted LDP session between PE1 and P4.
PE1 begins sending UDP/646 Hellos directly to 4.4.4.4. This is the same Hello message that would be multicast on a link to discover neighbors. But instead it is unicast to the specifed neighbor IP since this is a targeted session.
Notice that P4 is rejecting the UDP connection. This is because P4 is not accepting targeted sessions. We have two options to get the targeted session up. We can configure P4 to accept all targeted LDP sessions (unconditionally or based on an ACL of permitted LDP peers) or configure P4 for a targeted session specifically to PE1. Let’s first allow incoming targeted LDP sessions on P4.
PE1 and P4 now form a neighborship session and exchange label bindings:
We can see that the neighbor is discovered via a targeted Hello as opposed to discovered on an interface. PE1 lists itself as active and P4 lists itself as passive indicating their roles in initiating the targeted session.
Let’s remove the unconditional targeted-hello acceptance on P4 (which brings the session down), then configure 1.1.1.1 as an explicit peer on P4.
PE1 now lists itself as active, passive. I’m assuming this refers to the fact that it is configured to explicity form a session with 1.1.1.1, but it is currently the passive endpoint in the TCP connection. Notice the connection uses a random port on P4 (since P4 initiated the connection) and port 646 on PE1.
Lab - LDP Session Protection
LDP session protection is essentially just automatic targeted sessions to your directly connected neighbors. Let’s enable session protection on all PE/P routers.
Optionally you can configure a duration, which limits how long the session stays up after the directly connected neighbor is lost. By default the duration is infinite. If it is up for longer than say, 30 mins, you may want to just let LDP bring the session down and let LDP fully reconverge once the interface is back up.
You can also use the for keyword to specify an ACL to limit which LDP peers you enable session protection for.
Configuring LDP session protection automatically enables the acceptance of targeted Hellos. It also automatically creates a targeted session to every automatically discovered neighbor. (Neighbors are discoverged automatically on an interface by multicasting Hellos to 224.0.0.2 on UDP/646 and receiving replies to the same multicast IP from neighbors).
Let’s look at the LDP neighbor table on PE1:
Notice that the session to P3 has two discovery sources now. 1) The interface and 2) the targeted Hello. The targeted session we manually created to P4 still only has a single discovery source. Nothing has changed with that LDP neighbor. In fact, you could say that any regular targeted session already has session protection. In this sense, if you were to manually configure targeted sessions between all directly connected neighbors, you would have accomplished the same thing as turning on session protection.
If we take a pcap on the link between PE1 and P3, we see three Hellos. Two are to P3. One is the targeted session using the loopbacks as the src/dst, and one is sourced from Gi2 to 224.0.0.2. The third Hello is the targeted manual session between PE1 and P4.
Let’s shut down the link between P3 and P5 and see what happens. First we examine the remote label bindings for P5, and the existing neighbor session.
We shutdown Gi3 of P3, and see that the neighbor is still up, and we still have the remote label bindings for the peer.
The label bindings are retained because the targeted session to P5 is still up. However, none of these label bindings are actually in use in the LFIB, since P5 is not a nexthop for any prefixes in the RIB. We see this above with P5’s own loopback. The nexthop is P4 via Gi2 with the label that P4 advertised for this prefix.
So the only benefit to session protection is that when we bring the link back up, we will re-discover the neighbor on the interface, but not have to exchange label binding information. Let’s enable Gi3 again and take a pcap on the link.
LDP only needs to rediscover the neighbor and maintain it using the multicasted Hello. ISIS has to completely reconverge.
P3 has allocated a new label for the 10.3.5.0/24 prefix, since that link flapped. This is the only label information exchanged by LDP during this process. The targeted session now uses the connected interface again. The targeted session simply follows the IGP path.
Pop quiz! What happens if one router configures session protection, and the other router simply accepts targeted hellos (without configuring session protection)? Does the feature fully work on both routers? Only one? None? Think this through on your own, and then we will test it out.
We’ll test this scenario between P3 and P4. Let’s turn session protection off on P4, verify that the targeted session is down on P3, and then accept targeted hellos on P4.
When using session protection, an LDP neighborship uses a single TCP connection but two discovery methods for maintaining the neighbor’s aliveness. Above we can see that the existing TCP session between 3.3.3.3 and 4.4.4.4 stays up. P4 just stops responding to the targeted hellos from 3.3.3.3. It only responds to the multicasted Hellos it sees on the interface connecting to P3. Therefore the only discovery source is now the interface (Gi2).
Let’s accept targeted hellos on P4 now.
The target session is seen as a discovery source on P3 again.
The output above on P4 looks identical to when ldp session protection was enabled. Let’s bounce Gi2 on P3, which connects to P4, and take a pcap.
This works just as if P4 was configured for mpls ldp session protection. Notice that P3 did not actually send its own ISIS Hello until 60 seconds after the interface came up. Why is this? We left the sync delay set to 60 on this interface from the previous article!
Conclusion
The LDP Session Protection feature retains label bindings when a directly connected interface to an LDP neighbor goes down. It does this by forming a target LDP session to evey dynamically discovered neighbor. If the link to a neighbor goes down, the IGP routes around the failure, and the targeted session (being multihop in nature) remains up. When the directly connected interface goes up, the neighbors do not need to exchange label bindings again.
Whether you should actually implement this in your environment is up for debate. There is some overhead added with this feature, as every dynamically discovered neighbor needs to be maintained twice. Once using the interface multicast Hello (as normal), and once using a targeted Hello. This doubles the amount of LDP Hello traffic in your network. The benefit is quite minor too. The IGP has to converge anyways, so exchanging label bindings is not too big of a deal in my eyes.
The real benefit, I believe, comes when you do not have LDP/IGP sync enabled. When a link flaps, without either LDP sync or Session Protection enabled, you risk the IGP converging slightly faster, and IP routing VPN traffic before LDP comes up. Using Session Protection to retain label bindings prevents the need for LDP/IGP sync in this scenario. The LDP session is by default already converged before the IGP does.
However, I would argue that using only LDP/IGP sync is better than using only Session Protection. This is because if a link flaps on a stub router which only has one link to the MPLS network, then you have to reconverge on LDP anyways when the link comes back up. So if the targeted LDP session is lost, Session Protection does nothing, and you need LDP/IGP sync to prevent blackholing VPN traffic. Therefore I would personally recommend to only use LDP/IGP sync and not worry about enabling Session Protection.
Last updated
