# LDP Session Protection
Load **isis.cfg**
```
#IOS-XE
config replace flash:isis.cfg
#IOS-XR
configure
load bootflash:isis.cfg
commit replace
y
```
* Configure LDP using IGP autoconfig on routers R2-R6 and XR1.
* Configure session protection between R2 and R3, and between R6 and XR1. Use two different methods to protect each of the two sessions.
* Verify that the session stays up when the direct link between the neighbors flaps.
## Answer
```
#R2-R6
router isis
mpls ldp autoconfig
#XR1
router isis 1
add ipv4
mpls ldp auto-config
!
mpls ldp
```
```
#R2, R3
mpls ldp session protection
#R6
mpls ldp neighbor 19.19.19.19 targeted
! or
mpls ldp discovery targeted-hello accept
#XR1
mpls ldp
address-family ipv4
neighbor 6.6.6.6 targeted
! or
mpls ldp
address-family ipv4
discovery targeted-hello accept
```
## Explanation
Session protection keeps an LDP session up in the event that the local link to a router goes down. It only works if there is still an alternate route to the neighbor. Of course, while the link is down, the label bindings are no longer used. But when the link comes back up the routers don’t need to re-converge on LDP. The label bindings are still the same, and are retained.
This is *sort of* an alternative to LDP/IGP sync when a link flaps. When the IGP adjacency comes back up LDP is already established, so you don’t get any blackholing of labeled traffic. However, LDP/IGP sync protects more situations than session protection for the purpose of keeping LDP in sync with the IGP. It’s more proper to say that session protection is for improving re-convergence of LDP neighbors, while LDP/IGP sync is for preventing blackholing of labeled traffic.
Because session protection just uses a targeted session, you can achieve the same result by manually configuring targeted sessions between LDP neighbors. When using targeted sessions, you can configure one side only, and configure the other side to accept targeted Hellos.
The only difference between using session protection and using a targeted session, is that session protection has a built-in holddown timer. If the holddown timer expires, the LDP session is torn down anyways, even though loopback connectivity is still available. The idea is that you don’t want to hold onto the LDP bindings indefinitely if the routers’ direct link is permanently disconnected. At a certain point, holding onto unused label bindings is not worth it any more.
## Verification
LDP session protection takes advantage of the fact that a single LDP TCP session is always used no matter how many “links” the routers have between them. So essentially, we can have *n* discovery soruces, but always one single TCP session. Session protection simply uses a targeted hello as a second discovery source.
Notice above that the default LDP session protection duration is 86400 seconds (24 hours). We can control this using **mpls ldp session protection duration *****seconds|*****infinite**.
To demonstrate LDP session protection in action, we’ll change the duration, shut the direct link between R2-R3, and run **debug mpls ldp session protection**.
```
#R2
mpls ldp session protection duration 180
!
int Gi2.23
shut
#R3
mpls ldp session protection duration 180
```
The discovery sources now lists only the targeted Hello. The session protection state is now **protecting.** The holdup timer starts counting down.
Eventually, the holdup timer expires, and the LDP session is completely torn down.
If we bring the directly connected interface back up, the session protection will go back to **ready**.
```
#R2
int Gi2.23
no shut
```
XR1 only used a manual targeted session. Because we didn’t explicitly configure session protection, we don’t see any session protection output. However, the result is the same as if we used session protection with an infinite duration.
Note that on IOS-XR, session protection configuration is very similar to IOS-XE:
```
#IOS-XR
mpls ldp
session protection [duration seconds|infinite]
```
Also, we have the option of restricting session protection to particular LDP RIDs using an ACL on both IOS-XE and IOS-XR. We’ll configure session protection between R5 and XR1 to demonstrate this method:
```
#XR1
mpls ldp
session protection for R5
!
ipv4 access-list R5
10 permit ipv4 host 5.5.5.5 any
#R5
mpls ldp session protection for 1
!
ip access-list standard 1
10 permit 19.19.19.19
```
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://ccie-sp.gitbook.io/ccie-spv5.1-labs/labs/ldp/ldp-session-protection.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.