LDP Reliability

Background

As shown in Figure 2-7, an LSR periodically sends Hello messages to its neighboring LSRs to advertise its existence on the network and maintain adjacencies. An LSR creates a Hello timer for each neighbor to maintain an adjacency. Each time the LSR receives a Hello message, the LSR resets the Hello timer. If the Hello timer expires before the LSR receives a new Hello message, the LSR considers that the adjacency is terminated. This mechanism cannot detect link faults quickly, especially when a Layer 2 device is deployed between LSRs.

Figure 2-7 BFD for LDP LSPs

BFD can quickly detect faults on an LDP LSP and trigger a traffic switchover upon an LDP LSP failure, minimizing packet loss and improving network reliability.

Implementation

BFD for LDP LSP is implemented by establishing a BFD session between two nodes on both ends of an LSP and binding the session to the LSP. BFD rapidly detects LSP faults and triggers a traffic switchover. When BFD monitors a unidirectional LDP LSP, the reverse path of the LDP LSP can be an IP link, an LDP LSP, or a traffic engineering (TE) tunnel.

A BFD session that monitors LDP LSPs is negotiated in static mode: The negotiation of a BFD session is performed using the local and remote discriminators that are manually configured for the BFD session to be established. On a local LSR, you can bind an LSP with a specified next-hop IP address to a BFD session with a specified peer IP address.

BFD uses the asynchronous mode to check LSP continuity. That is, the ingress and egress periodically send BFD packets to each other. If one end does not receive BFD packets from the other end within a detection period, BFD considers the LSP Down and sends an LSP Down message to the LSP management (LSPM) module.

Figure 2-8 BFD for LDP LSPs

Background

LDP-IGP synchronization is used to synchronize the status between LDP and an IGP to minimize the traffic loss time if a network fault triggers the LDP and IGP switching.

On a network with active and standby links, if the active link fails, IGP routes and an LSP are switched to the standby link. After the active link recovers, IGP routes are switched back to the active link before LDP convergence is complete. In this case, the LSP along the active link takes time to make preparations, such as adjacency restoration, before being established. As a result, LSP traffic is discarded. If an LDP session or adjacency between nodes fails on the active link, the LSP along the active link is deleted. However, the IGP still uses the active link, and as a result, LSP traffic cannot be switched to the standby link, and is continuously discarded.

LDP-IGP synchronization supports only OSPFv2 and IS-IS for IPv4.

According to the fundamentals of LDP-IGP synchronization, an IGP cost value is set to delay a route switchback until LDP convergence is complete. Before the LSP along the active link is established, the LSP along the standby link is retained, so that the traffic continues to be forwarded through the standby link. The backup LSP is torn down only after the primary LSP is established successfully.

LDP-IGP synchronization timers are as follows:

• Hold-max-cost timer

• Delay timer

Implementation

Figure 2-9 Switchback problem to be solved in LDP-IGP synchronization

• In Figure 2-9, on a network with active and standby links, after the active link recovers, an attempt is made to switch traffic back from the standby link to the active link. Revertive traffic is discarded because the backup LSP becomes unavailable after the IGP convergence is complete but the primary LSP is not established. In this situation, you can configure LDP-IGP synchronization to delay the IGP route switchback until LDP convergence is complete. Before the primary LSP is converged, the backup LSP is retained, so that the traffic continues to be forwarded through the backup LSP until the primary LSP is successfully established. Then the backup LSP is torn down. The process is as follows:

  1. A link fault is rectified.

  2. An IGP advertises the maximum cost of the active link, delaying the IGP route switchback.

  3. Traffic is still forwarded along the backup LSP.

  4. After the LDP session and adjacency are successfully established, Label Mapping messages are exchanged to instruct the IGP to start synchronization.

  5. The IGP advertises the normal cost of the active link and converges to the original path. The LSP is reestablished and the forwarding entries are delivered within milliseconds.

• If the LDP session or adjacency between nodes on the active link fails, the primary LSP is deleted, but the IGP still uses the active link. As a result, LSP traffic cannot be switched to the standby link, and traffic is continuously discarded. In this situation, you can configure LDP-IGP synchronization. If an LDP session or adjacency fails, LDP informs the IGP that the LDP session or adjacency is faulty. In this case, the IGP advertises the maximum cost of the faulty link. The route is switched to the standby link, and the LSP is also switched to the standby link. The process is as follows:

  1. The LDP session or adjacency between nodes on the active link is faulty.

  2. LDP informs the IGP that the LDP session or adjacency along the active link is faulty. The IGP then advertises the maximum cost of the active link.

  3. IGP routes are switched to the standby link.

  4. The LSP is reestablished along the standby link, and forwarding entries are delivered.

  To prevent a continuous failure to reestablish the LDP session or adjacency, you can configure the Hold-max-cost timer to enable the node to permanently advertise the maximum cost so that traffic is transmitted over the standby link until the LDP session and LDP adjacency are reestablished along the active link.

• LDP-IGP synchronization state transition mechanism

  After LDP-IGP synchronization is enabled on an interface, an IGP queries the status of related interfaces, LDP sessions, and LDP adjacencies based on the process shown in Figure 2-10. Then, the interface enters a state based on the query result. Then, the state transition is performed, as shown in Figure 2-10.

  Figure 2-10 Query process of and status transition diagram for LDP-IGP synchronization
  
  When different IGP protocols are used, the preceding states are different.

  • When OSPF is used, the status transits based on the flowchart shown in Figure 2-10.
  • When IS-IS is used, no Hold-normal-cost state is involved. After the Hold-Max-Cost timer expires, IS-IS advertises the normal cost value of the interface link, but the Hold-max-cost state is still displayed.

Usage Scenario

On the network shown in Figure 2-11, an active link and a standby link are established. LDP-IGP synchronization and LDP FRR can be deployed together.

Figure 2-11 LDP-IGP synchronization deployment

Benefits

LDP-IGP synchronization reduces the packet loss rate during an active/standby link switchover and improves the reliability of an entire network.

Background

On an MPLS network, when the primary link fails, IP FRR ensures fast IGP route convergence and switches traffic to the backup link. However, a new LSP needs to be established, which causes traffic loss. If the LSP fails (for some reason other than a primary link failure), traffic is restored until a new LSP is established, causing traffic interruption for a long time. Auto LDP FRR is used on an MPLS network to address these issues.

Auto LDP FRR, using the liberal label retention mode of LDP, obtains a liberal label, assigns a forwarding entry to the label, and then delivers the forwarding entry to the forwarding plane as the backup forwarding entry for the primary LSP. When the interface goes Down (as detected by the interface itself or by BFD) or the primary LSP fails (as detected by BFD), traffic is quickly switched to the backup LSP.

Concepts

Auto LDP FRR: This automatic approach depends on IP FRR. A backup LSP can be established and its forwarding entries can be delivered only when the source of the liberal label matches the backup route. That is, the liberal label is obtained from the outbound interface and next hop of the backup route, and the backup LSP triggering conditions are met. By default, LDP LSP setup is triggered by a 32-bit backup route.

Implementation

In liberal label retention mode, an LSR can receive a Label Mapping message of an FEC from any neighboring LSR. However, only the Label Mapping message sent by the next hop of the FEC can be used to generate a label forwarding table for LSP setup. In contrast, Auto LDP FRR can generate an LSP as the backup of the primary LSP based on Label Mapping messages that are not from the next hop of the FEC. Auto LDP FRR establishes forwarding entries for the backup LSP and adds the forwarding entries to the forwarding table. If the primary LSP fails, traffic is switched to the backup LSP quickly to minimize traffic loss.

Figure 2-12 Auto LDP FRR - triangle topology

In Figure 2-12, the optimal route from LSR_1 to LSR_2 is LSR_1-LSR_2. A suboptimal route is LSR_1-LSR_3-LSR_2. After receiving a label from LSR_3, LSR_1 compares the label with the route from LSR_1 to LSR_2. Because LSR_3 is not the next hop of the route from LSR_1 to LSR_2, LSR_1 stores the label as a liberal label. If a route is available for the source of the liberal label, LSR_1 assigns a forwarding entry to the liberal label as the backup forwarding entry, and then delivers this forwarding entry to the forwarding plane with the primary LSP. In this way, the primary LSP is associated with the backup LSP.

Auto LDP FRR is triggered when an interface failure is detected by the interface itself or BFD, or a primary LSP failure is detected by BFD. After Auto LDP FRR is complete, traffic is switched to the backup LSP using the backup forwarding entry. Then the route is converged from LSR_1-LSR_2 to LSR_1-LSR_3-LSR_2. An LSP is established on the new path (the original backup LSP) and the original primary LSP is deleted. Traffic is forwarded along the new LSP of LSR_1-LSR_3-LSR_2.

Usage Scenario

Figure 2-12 shows a typical application environment of Auto LDP FRR. Auto LDP FRR functions well in a triangle topology but may not take effect in some situations in a rectangle topology.

Figure 2-13 Auto LDP FRR - rectangle topology

As shown in Figure 2-13, if the optimal route from LSR_1 to LSR_4 is LSR_1-LSR_2-LSR_4 (with no other route for load balancing), LSR_3 receives a liberal label from LSR_1 and is bound to Auto LDP FRR. If the link between LSR_3 and LSR_4 fails, traffic is switched to the route of LSR_3-LSR_1-LSR_2-LSR_4. No loop occurs in this situation.

However, if optional routes from LSR_1 to LSR_4 are available for load balancing (LSR_1-LSR_2-LSR_4 and LSR_1-LSR_3-LSR_4), LSR_3 may not receive a liberal label from LSR_1 because LSR_3 is a downstream node of LSR_1. Although LSR_3 receives a liberal label and is configured with Auto LDP FRR, traffic may still be forwarded to LSR_3 after the traffic switching, leading to a loop. The loop exists until the route from LSR_1 to LSR_4 is converged to LSR_1-LSR_2-LSR_4.

Background

On an MPLS network, when the GR Restarter restarts a protocol or performs an active/standby switchover, label forwarding entries on the forwarding plane are deleted, interrupting data forwarding.

LDP GR can address this issue and therefore improve network reliability. During a protocol restart or active/standby switchover, LDP GR retains label forwarding entries because the forwarding plane is separated from the control plane. The device still forwards packets based on the label forwarding entries, ensuring data transmission. After the protocol restart or active/standby switchover is complete, the GR Restarter can restore to the original state with the help of the GR Helper.

Concepts

The device can function only as the GR Helper.

Implementation

Figure 2-14 shows LDP GR implementation.

Figure 2-14 LDP GR implementation

LDP GR works as follows:

1. An LDP session is set up between the GR Restarter and GR Helper. The GR Restarter and GR Helper negotiate GR capabilities during LDP session setup.
2. When restarting a protocol or performing an active/standby switchover, the GR Restarter starts the Forwarding State Holding timer, retains label forwarding entries, and sends an LDP Initialization messages to the GR Helper. When the GR Helper detects that the LDP session with the GR Restarter is Down, the GR Helper retains label forwarding entries of the GR Restarter and starts the Reconnect timer.
3. After the protocol restart or active/standby switchover, the GR Restarter reestablishes an LDP session with the GR Helper. If an LDP session is not reestablished before the Reconnect timer expires, the GR Helper deletes label forwarding entries of the GR Restarter.
4. After the GR Restarter reestablishes an LDP session with the GR Helper, the GR Helper starts the Recovery timer. Before the Recovery timer expires, the GR Restarter and GR Helper exchange Label Mapping messages over the LDP session. The GR Restarter restores forwarding entries with the help of the GR Helper, and the GR Helper restores forwarding entries with the help of the GR Restarter. After the Recovery timer expires, the GR Helper deletes all forwarding entries that have not been restored.
5. After the Forwarding State Holding timer expires, the GR Restarter deletes label forwarding entries and the GR is complete.