LDP NSF allows an RP to recover from disruption in service without losing its MPLS forwarding state. LDP NSF works under the following circumstances:

• LDP restart--An LDP Restart occurs after an SSO event interrupts LDP communication with all LDP neighbors. If the RPs are configured with LDP NSF, the backup RP retains the MPLS forwarding state and reestablishes communication with the LDP neighbors. Then the RP ensures that the MPLS forwarding state is recovered.

• LDP session reset--An LDP session reset occurs after an individual LDP session has been interrupted, but the interruption is not due to an SSO event. The LDP session might have been interrupted due to a TCP or UDP communication problem. If the RP is configured with MPLS LDP NSF support and graceful restart, the RP associates a new session with the previously interrupted session. The LDP bindings and MPLS forwarding states are recovered when the new session is established.

If an SSO event occurs on an LSR, that LSR performs an LDP restart. The adjacent LSRs perform an LDP session reset.

See the following section for more information about LDP restart and reset.

In the topology shown in the figure below, the following elements have been configured:

• LDP sessions are established between Router 1 and Router 2, as well as between Router 2 and Router 3.

• A label switched path (LSP) has been established between Router 1 and Router 3.

• The routers have been configured with LDP NSF.

Figure 1. Example of a Network Using LDP Graceful Restart

The following process shows how LDP recovers when one of the routers fails:

1. When an RP fails on Router 2, communications between the routers is interrupted.

2. Router 1 and Router 3 mark all the label bindings from Router 2 as stale, but they continue to use the bindings for MPLS forwarding.

3. Router 1 and Router 3 attempt to reestablish an LDP session with Router 2.

4. Router 2 restarts and marks all of its forwarding entries as stale. If you enter a showmplsldpgraceful-restart command, the command output includes the following line:

LDP is restarting gracefully. 

1. Router 1 and Router 3 reestablish LDP sessions with Router 2, but they keep their stale label bindings. If you enter a showmplsldpneighborcommand with the graceful-restart keyword, the command output displays the recovering LDP sessions.

2. All three routers readvertise their label binding information. If a label has been relearned after the session has been established, the stale flags are removed. The showmplsforwarding-tablecommand displays the information in the MPLS forwarding table, including the local label, outgoing label or VC, prefix, label-switched bytes, outgoing interface, and next hop.

You can set various timers to limit how long the routers wait for an LDP session to be reestablished before restarting the router. See the following commands for more information:

• mpls ldp graceful-restart timers forwarding-holding

• mpls ldp graceful-restart timers max-recovery

• mpls ldp graceful-restart timers neighbor-liveness

An RP that is configured to perform LDP NSF includes the Fault Tolerant (FT) Type Length Value (TLV) in the LDP initialization message. The RP sends the LDP initialization message to a neighbor to establish 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 RP is configured to perform 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. This field is set to 120 seconds and cannot be configured.

• The Recovery Time field shows the time (in milliseconds) that the neighbor should retain the MPLS forwarding state during a recovery. If a neighbor did not preserve the MPLS forwarding state before the restart of the control plane, the neighbor sets the recovery time to 0.

If an RP is not configured for MPLS LDP Graceful Restart and it attempts to establish an LDP session with an RP that is configured with LDP Graceful Restart, the following events occur:

1. The RP that is configured with MPLS LDP Graceful Restart sends an initialization message that includes the FT session TLV value to the RP that is not configured with MPLS LDP Graceful Restart.

2. The RP that is not configured for MPLS LDP Graceful Restart receives the LDP initialization message and discards the FT session TLV.

3. The two RPs create a normal LDP session but do not have the ability to perform MPLS LDP Graceful Restart.

You must enable all RPs with MPLS LDP Graceful Restart for an LDP session to be preserved during an interruption in service.

Checkpointing is a function that copies state information from the active RP to the backup RP, thereby ensuring that the backup RP has the latest information. If the active RP fails, the backup RP can take over.

For the LDP NSF feature, the checkpointing function copies the active RP’s LDP local label bindings to the backup RP. The active RP sends updates to the backup RP when local label bindings are modified as a result of routing changes.

Note	Local label bindings that are allocated by BGP and null local label bindings are not included in the checkpointing operation.

The checkpointing function is enabled by default.

To display checkpointing data, issue the show mpls ldp graceful-restartcommand on the active RP.

To check that the active and backup RPs have identical copies of the local label bindings, you can issue the show mpls ldp bindingscommand with the detail keyword on the active and backup RPs. This command displays the local label bindings that have been saved. The active RP and the backup RP should have the same local label bindings.