Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Configuring and Verifying Node-Link Protection

 

The following section describes the steps you must take to configure and verify many-to-one backup.



Configuring node-link protection is a two-part process. The first part involves configuring node-link protection for any LSPs traversing the protected node that require use of the bypass path, and the second part sets link protection on the outgoing RSVP interface on routers in the LSP.

Action

To configure node-link protection, follow these steps:

  1. In configuration mode, go to the following hierarchy level:

    For example:

  2. Configure node-link protection for the LSP:

  3. Verify the node-link protection configuration for the LSP:

  4. Configure link protection for the interface:

    For example:

  5. Configure link protection:

  6. Verify the link protection configuration for the interface, and commit both configurations:

  7. Repeat Step 1 through Step 3 on any other ingress routers that have LSPs requiring use of the bypass path.

  8. Repeat Step 4 and Step 5 on routers with outgoing interfaces in the LSP.

Sample Output

The following sample output shows the configuration of node-link protection on ingress router R1 in the network shown in Many-to-One or Link Protection:

Meaning

The sample output shows the configuration of node-link protection for an LSP. After node-link protection is configured, bypass paths are signaled to avoid the protected link or node in case of failure. Having bypass paths available does not in itself provide protection for LSPs that traverse the protected node. You must include the node-link-protection statement on the ingress router for each LSP that will benefit from the bypass path.



Purpose

After you configure node-link protection, you must check that bypass paths are up. You can also check the number of LSPs protected by the bypass paths. In the network shown in Node-Link Protection, two bypass paths should be up: one next-hop bypass path protecting the link between R1 and R2 (or next-hop 10.0.12.14), and a next-next-hop bypass path avoiding R2.

Action

To verify node-link protection (many-to-one backup), enter the following Junos OS CLI operational mode commands on the ingress router. You can also issue the commands on transit routers and other routers used in the bypass path for slightly different information.

Sample Output

Meaning

Sample output from R1 for the show mpls lsp command shows a brief description of the state of configured and active LSPs for which R1 is the ingress, transit, and egress router. All LSPs are up. R1 is the ingress router for lsp2-r1-to-r5, and the egress router for return LSP r5-to-r1. Two LSPs transit R1, lsp1-r6-to-r0 and the return LSP r0-to-t6. For more detailed information about the LSP, include the extensive option when you issue the show mpls lsp command.

Sample Output

Meaning

Sample output from R1 for the show mpls lsp extensive command shows detailed information about all LSPs for which R1 is the ingress, egress, or transit router, including all past state history and the reason why an LSP failed. All LSPs are up. The main two LSPs lsp2-r1-to-r5 and lsp1-r6-to-r0 have node-link protection as indicated by the Node/Link protection desired field in the ingress and transit sections of the output. In the ingress section of the output, the Link-protection Up field shows that lsp2-r1-to-r5 has link protection up. In the transit section of the output, the Type: Node/Link protected LSP field shows that lsp1-r6-to-r0 has node-link protection up, and in case of failure will use the bypass LSP Bypass->10.0.12.14->10.0.24.2.

Sample Output

Meaning

Sample output from R1 for the show rsvp interface command shows four interfaces enabled with RSVP (Up). Interface fe-0/1/0.0 has two active RSVP reservations (Active resv) that might indicate sessions for the two main LSPs, lsp1-r6-to-r0 and lsp2-r1-to-r5. Interface fe-0/1/0.0 is the connecting interface between R1 and R2, and both LSPs are configured with a strict path through fe-0/1/0.0. For more detailed information about what is happening on interface fe-0/1/0.0, issue the show rsvp interface extensive command.

Sample Output

Meaning

Sample output from R1 for the show rsvp interface extensive command shows more detailed information about the activity on all RSVP interfaces (3). However, only output for fe-0/1/0.0 is shown. Protection is enabled (Protection: On), with two bypass paths (Bypass: 2) protecting two LSPs (Protected LSP: 2). All LSPs are protected, as indicated by the Unprotected LSP: 0 field. The first bypass Bypass->10.0.12.14is a link protection bypass path (Type: LP), protecting the link between R1 and R2 fe-0/1/0.0. The second bypass path 10.0.12.14->10.0.24.2 is a node-link protected LSP, avoiding R2 in case of node failure.

Sample Output

Meaning

Sample output from R1 shows detailed information about the RSVP sessions active on R1. All sessions are up, with two ingress sessions, one egress session, and two transit sessions.

Within the ingress section, the first session is a bypass path, as indicated by the Type: Bypass LSP field; and the second session is a protected LSP (lsp2-r1-to-r5) originating on R1, as indicated by the Type: Node/Link protected LSP field.

Conclusion

Multiprotocol Label Switching (MPLS) label-switched path (LSP) link protection and node-link protection are facility-based methods used to reduce the amount of time needed to reroute LSP traffic. These protection methods are often compared to fast reroute—the other Junos OS LSP protection method.

While fast reroute protects LSPs on a one-to-one basis, link protection and node-link protection protect multiple LSPs by using a single, logical bypass LSP. Link protection provides robust backup support for a link, node-link protection bypasses a node or a link, and both types of protection are designed to interoperate with other vendor equipment. Such functionality makes link protection and node-link protection excellent choices for scalability, redundancy, and performance in MPLS-enabled networks.

Related Information

For additional information about MPLS fast reroute and MPLS protection methods, see the following:

  • Junos User Guide

  • Junos MPLS Applications Configuration Guide

  • Semeria, Chuck. RSVP Signaling Extensions for MPLS Traffic Engineering. White paper. 2002

  • Semeria, Chuck. IP Dependability: Network Link and Node Protection. White paper. 2002

  • RFC 4090, Fast Reroute Extensions to RSVP-TE for LSP Tunnels