Introduction to MPLS LDP Graceful Restart
MPLS LDP graceful restart preserves data plane forwarding along LDP LSPs in the presence of temporary LDP control plane disruption. The disruption might be an LDP control plane restart caused by a supervisor switchover or process restart or a TCP or UDP event that disrupts control plane communication between two LDP control planes, even if neither restarts.
The following example describes how MPLS LDP graceful restart operates in the presence of an LDP control plane restart. Note that this interaction has two different roles: the router with the restarting LDP control plane and the neighbor router that detects a loss and recovery of its LDP session to the restarting router. Each carries out MPLS LDP graceful restart procedures appropriate to its role.
The topology shown in Figure 1-1 has the following elements:
All three routers are running MPLS LDP, all with graceful restart enabled.
An LDP session exists between R2 and R1, and another LDP session exists between R2 and R3.
LDP LSPs have been established, including LSPs that connect R1 and R3 and are carrying data traffic. In a network with more routers, multiple LSPs might traverse R1-R2-R3 in both directions.
Figure 1-1 Example of a Network Using LDP Graceful Restart
The following sequence shows how the three routers cooperate to provide NSF and avoid a disruption to data traffic:
1. At session establishment, each router reports to its neighbors that it supports graceful restart. Each session endpoint knows that both ends of the session support graceful restart.
2. R2 begins a supervisor switchover. R2’s LDP control plane and all of its LDP TCP connections and LDP UDP hello adjacencies stop operating. R2’s data plane marks all of its label entries as stale but continues to use those entries for forwarding MPLS data traffic.
3. R1 notices a loss of communication with R2. (In this sequence, R3 performs the same actions as R1.) R1 marks all of its label bindings from R2 as stale but continues to use those entries for forwarding data traffic.
4. R1 and R2 reestablish an LDP session. On R1, entering the
show mpls ldp neighbor graceful-restart
command displays information about the recovering session.
5. R2 reacquires its local label binding information. R2’s data plane typically provides R2’s control plane with the same local label for each prefix that was used prior to the restart.
6. Both routers readvertise their label binding information. If R1 relearns a label from R2, R1 marks the binding as no longer stale. If R2 learns a label from R1 and submits that label to its data plane, the data plane marks the entry as no longer stale.
7. After a certain amount of time has passed, R1’s LDP control plane cleans up all entries that are still marked as stale. Similarly, R2’s data plane removes all entries that are still marked as stale.
Typically, if no other network disruption occurs during this graceful restart operation, all bindings are relearned from the neighbor with the same label values as before the session restart. In this scenario, all saved bindings are marked as not stale during recovery, and no entries need to be cleaned up.
Another scenario of interest is a TCP or UDP communication failure without an LDP control plane restart. In this case, the two LDP control planes at either end of the session detect the communication failure. Each LDP control plane applies the same procedures as R1 used above, and NSF is achieved. R1 carries out the same MPLS LDP graceful restart procedures whether the communication failure with R2 was caused by a restart of R2’s control plane or by a networking issue without a restart of R2’s control plane.
You can set various timers to limit how long the routers wait for an LDP session to be reestablished before restarting the router.
What Happens if a Router Does Not Have MPLS LDP Graceful Restart Enabled
When a router that does not support MPLS LDP graceful restart undergoes a control plane restart, its data plane MPLS forwarding entries are freed.
A neighbor of such a router, detecting a loss of communication, frees all bindings from the restarting router. This behavior occurs whether the neighbor supports MPLS LDP graceful restart or not. A neighbor that supports MPLS LDP graceful restart learns at session establishment that the restarting router is not supporting MPLS LDP graceful restart. The neighbor does not run graceful restart procedures when detecting a loss of communication to the restarting router.
The cleanup actions of both the restarting router and its neighbor cause any data traffic on the old LSPs to be dropped until recovery activities have addressed the situation. Recovery activities include traffic reroute or the reestablishment of MPLS LDP LSPs or both.
How a Router Advertises that it Supports MPLS LDP Graceful Restart
A router that supports MPLS LDP graceful restart announces its capabilities to its neighbors in the fault tolerant (FT) type-length-value (TLV) in the LDP initialization message. The router sends the LDP initialization message to a neighbor as part of establishing an LDP session.
The FT session TLV includes the following information:
The Learn from Network (L) flag is set to 1, which indicates that the router is configured to perform MPLS LDP graceful restart.
The Reconnect Timeout field shows the time (in milliseconds) that the neighbor should wait for a reconnection if the LDP session is lost. If the timer is set to 0 and the local router fails, its peers do not wait for it to recover.
The Recovery Time field shows the time (in milliseconds) that the neighbor should retain the MPLS forwarding state during a recovery currently in progress. For example, if a neighbor restarted and did not preserve the MPLS forwarding state across the restart, the neighbor should set its recovery time to 0.
Note The reconnect time applies to the next communication loss while the recovery time applies to the recovery from the preceding communication loss.