Link-protection and node-link-protection on Juniper MX

Protecting LSPs in an MPLS enabled network can save quite some downtime whenever a link or a node in your network fails. In this article, we’ll go through the configuration of both link-protection and node-link-protection. We’ll configure it for the following scenario:



The routers in the network above are running IS-IS and they have MPLS and RSVP enabled for the interfaces that connect them together. The configuration is still largely like it was during this post.

Link-protection:

Before enabling link-protection (or node-link-protection), we have to enable the network to be able to support it. This is done in the [protocols rsvp] stanza under the RSVP-enabled interfaces;



Configuring ‘link-protection’ has to be done for all RSVP-enabled interfaces in the network. With this configuration statement, we’re telling the router to signal a bypass LSP as soon as an LSP that wants protection traverses this link. This protection can be either link-protection or node-link-protection.

After this, we can move on to enable link-protection on an LSP. The router already has an LSP configured:

Tiberius> show configuration protocols mpls
revert-timer 0;
label-switched-path to_Commodus {
    to 1.1.1.4;
    ldp-tunneling;
    primary via_Hadrian;
    secondary via_Romulus {
        standby;
    }
}
path via_Romulus {
    1.1.1.6 strict;
}
path via_Hadrian {
    1.1.1.10 strict;
}
interface xe-0/2/0.9;
interface xe-0/2/0.3;                    
                

To protect both the primary and the secondary LSP from individual link-failures across the network, we only need to add 1 configuration statement on the ingress LSR:



As soon as this configuration command is added, the Tiberius router will signal to the other routers that the LSP is one that wants link-protection. The other routers, with their RSVP-interfaces enabled for link-protection, will start signaling bypass LSPs where possible.

To verify link-protection is enabled, we can check the following on the Tiberius router:

play@MX480-TEST:Tiberius> show rsvp session ingress name to_Commodus detail
Ingress RSVP: 4 sessions

1.1.1.4
  From: 1.1.1.9, LSPstate: Up, ActiveRoute: 0
  LSPname: to_Commodus, LSPpath: Primary
  LSPtype: Static Configured
  Suggested label received: -, Suggested label sent: -
  Recovery label received: -, Recovery label sent: 300560
  Resv style: 1 SE, Label in: -, Label out: 300560
  Time left:    -, Since: Fri May 15 08:29:28 2015
  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
  Port number: sender 1 receiver 12472 protocol 0
  Link protection desired
  Type: Link protected LSP
  PATH rcvfrom: localclient
  Adspec: sent MTU 1500
  Path MTU: received 1500
  PATH sentto: 2.0.0.33 (xe-0/2/0.9) 1 pkts
  RESV rcvfrom: 2.0.0.33 (xe-0/2/0.9) 3 pkts
  Explct route: 2.0.0.33 2.0.0.42 2.0.0.66 2.0.0.21
  Record route: <self> 1.1.1.10 (node-id) 2.0.0.33 1.1.1.11 (node-id) 2.0.0.42 1.1.1.12 (node-id) 2.0.0.66 1.1.1.4 (node-id) 2.0.0.21

1.1.1.4
  From: 1.1.1.9, LSPstate: Up, ActiveRoute: 0
  LSPname: to_Commodus, LSPpath: Secondary
  LSPtype: Static Configured
  Suggested label received: -, Suggested label sent: -
  Recovery label received: -, Recovery label sent: 300800
  Resv style: 1 SE, Label in: -, Label out: 300800
  Time left:    -, Since: Fri May 15 08:29:58 2015
  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
  Port number: sender 2 receiver 12473 protocol 0
  Link protection desired
  Type: Link protected LSP
  PATH rcvfrom: localclient
  Adspec: sent MTU 1500
  Path MTU: received 1500
  PATH sentto: 2.0.0.9 (xe-0/2/0.3) 1 pkts
  RESV rcvfrom: 2.0.0.9 (xe-0/2/0.3) 4 pkts
  Explct route: 2.0.0.9 2.0.0.49 2.0.0.57 2.0.0.54
  Record route: <self> 1.1.1.6 (node-id) 2.0.0.9 1.1.1.7 (node-id) 2.0.0.49 1.1.1.8 (node-id) 2.0.0.57 1.1.1.4 (node-id) 2.0.0.54
Total 2 displayed, Up 2, Down 0                    
                

Or alternatively;

play@MX480-TEST:Tiberius> show mpls lsp name to_Commodus extensive
Ingress LSP: 1 sessions

1.1.1.4
  From: 1.1.1.9, State: Up, ActiveRoute: 0, LSPname: to_Commodus
  ActivePath: via_Hadrian (primary)
  Link protection desired
  LSPtype: Static Configured, Penultimate hop popping
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
  Revert timer: 0
 *Primary   via_Hadrian      State: Up
    Priorities: 7 0
    SmartOptimizeTimer: 180
    Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 40)
 2.0.0.33 S 2.0.0.42 S 2.0.0.66 S 2.0.0.21 S
    ...
    <output omitted>
    ...
    8 May 15 08:30:22.911 Link-protection Up
    ...
    <output omitted>
    ...
    2 May 15 08:29:28.906 Originate Call
    1 May 15 08:29:28.906 CSPF: computation result accepted  2.0.0.33 2.0.0.42 2.0.0.66 2.0.0.21
  Standby   via_Romulus      State: Up
    Priorities: 7 0
    SmartOptimizeTimer: 180
    Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 40)
 2.0.0.9 S 2.0.0.49 S 2.0.0.57 S 2.0.0.54 S
    ...
    <output omitted>
    ...
    8 May 15 08:31:42.409 Link-protection Up
    ...
    <output omitted>
    ...
    2 May 15 08:29:58.835 Originate Call
    1 May 15 08:29:58.835 CSPF: computation result accepted  2.0.0.9 2.0.0.49 2.0.0.57 2.0.0.54
                  
                

We can also move over to the Nero router. Here we can verify that Nero has already pre-signaled a bypass LSP:



Traffic traversing the normal LSP runs through Hadrian, Nero and Septimus before ending up on Commodus. This can be obtained by examining the ‘Record Route’ listed in the output from the ‘show rsvp session ingress name to_Commodus detail’ command.

In that output, we previously saw the following in the Record Route:’ 1.1.1.12 (node-id) 2.0.0.66’ This node-id belongs to Septimus and ‘2.0.0.66’ is configured for one of Septimus’ interfaces.

Let’s check Nero for ingress Bypass LSPs:

play@MX480-TEST:Nero> show rsvp session ingress
Ingress RSVP: 2 sessions
To              From            State   Rt Style Labelin Labelout LSPname
1.1.1.9         1.1.1.11        Up       0  1 SE       -   300768 Bypass->2.0.0.41->2.0.0.34
1.1.1.12        1.1.1.11        Up       0  1 SE       -   300896 Bypass->2.0.0.66
                

The appropriately named bypass LSP ‘Bypass->2.0.0.66’ can be used to circumvent the link between Nero and Septimus when it fails. To see more details about this LSP, we can issue to following command:

play@MX480-TEST:Nero> show rsvp session name Bypass->2.0.0.66 detail
Ingress RSVP: 2 sessions

1.1.1.12
  From: 1.1.1.11, LSPstate: Up, ActiveRoute: 0
  LSPname: Bypass->2.0.0.66
  LSPtype: Static Configured
  Suggested label received: -, Suggested label sent: -
  Recovery label received: -, Recovery label sent: 300896
  Resv style: 1 SE, Label in: -, Label out: 300896
  Time left:    -, Since: Fri May 15 08:29:31 2015
  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
  Port number: sender 1 receiver 60214 protocol 0
  Type: Bypass LSP
    Number of data route tunnel through: 1
    Number of RSVP session tunnel through: 0
  PATH rcvfrom: localclient
  Adspec: sent MTU 1500
  Path MTU: received 1500
  PATH sentto: 2.0.0.45 (xe-0/2/0.12) 1 pkts
  RESV rcvfrom: 2.0.0.45 (xe-0/2/0.12) 1 pkts
  Explct route: 2.0.0.45 2.0.0.57 2.0.0.17
  Record route: <self> 2.0.0.45 2.0.0.57 2.0.0.17
Total 1 displayed, Up 1, Down 0                    
                

Simply by using the name Bypass->2.0.0.66, you can verify the LSP on the other routers as well. Either through ‘show rsvp session name Bypass->2.0.0.66 detail’ or through ‘show rsvp session name Bypass->2.0.0.66’.

Node-link-protection:

The last thing to look at is node-link-protection. Commodus has an LSP towards the Tiberius router:



The LSP is configured as follows:

play@MX480-TEST:Commodus> show configuration protocols mpls
revert-timer 120;
label-switched-path to_Tiberius {
    to 1.1.1.9;
    ldp-tunneling;
    primary via_Caligula;
    secondary via_Septimus {
        standby;
    }
}
path via_Caligula {
    1.1.1.8 strict;
}
path via_Septimus {
    1.1.1.12 strict;
}
interface xe-0/2/0.14;
interface xe-0/3/0.6;                    
                

Enabling this LSP for node-link-protection is nothing more than adding the following command:

set protocols mpls label-switched-path to_Tiberius node-link-protection                    
                

Verifying node-link protection hardly differs from verifying link-protection:

play@MX480-TEST:Commodus> show rsvp session name to_Tiberius detail
Ingress RSVP: 4 sessions

1.1.1.9
  From: 1.1.1.4, LSPstate: Up, ActiveRoute: 0
  LSPname: to_Tiberius, LSPpath: Primary
  LSPtype: Static Configured
  Suggested label received: -, Suggested label sent: -
  Recovery label received: -, Recovery label sent: 301376
  Resv style: 1 SE, Label in: -, Label out: 301376
  Time left:    -, Since: Wed May 13 21:16:40 2015
  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
  Port number: sender 1 receiver 37581 protocol 0
  Node/Link protection desired <<-instead of the previous 'Link protection desired'
  Type: Node/Link protected LSP
    ...
    <output omitted>
    ...


play@MX480-TEST:Commodus> show mpls lsp name to_Tiberius detail
Ingress LSP: 1 sessions

1.1.1.9
  From: 1.1.1.4, State: Up, ActiveRoute: 0, LSPname: to_Tiberius
  ActivePath: via_Caligula (primary)
  Node/Link protection desired
  LSPtype: Static Configured, Penultimate hop popping
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
  Revert timer: 120
 *Primary   via_Caligula     State: Up
    ...
    <output omitted>
    ...
                

Link-node-protection will ask all the transit LSRs to try and establish bypass LSPs around links as well as nodes. A quick look at the Augusts router shows us two bypass LSPs are established:

play@MX480-TEST:Augustus> show mpls lsp
Ingress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Egress LSP: 2 sessions
To              From            State   Rt Style Labelin Labelout LSPname
1.1.1.7         1.1.1.6         Up       0  1 SE       3        - Bypass->2.0.0.49
1.1.1.7         1.1.1.4         Up       0  1 SE       3        - Bypass->2.0.0.53->2.0.0.58
Total 2 displayed, Up 2, Down 0                    
                

The first LSP only lists 1 IP address. This is the address of the link that is bypassed. The second LSP lists two IP addresses, indicating multiple links are used for this bypass LSP. This LSP can be used to circumvent an entire node in case a router goes down.

One last thing I forgot. Verifying that a link is protected can also be observed through the following command:

play@MX480-TEST:Nero> show rsvp interface xe-0/3/0.17 extensive
xe-0/3/0.17 Index 361, State Ena/Up
  Authentication, Aggregate, Reliable, LinkProtection
  HelloInterval 9(second)
  Address 2.0.0.65
  ActiveResv 2, PreemptionCnt 0, Update threshold 10%
  Subscription 100%,
  bc0 = ct0, StaticBW 10Gbps
  ct0: StaticBW 10Gbps, AvailableBW 10Gbps
    MaxAvailableBW 10Gbps = (bc0*subscription)
    ReservedBW [0] 0bps[1] 0bps[2] 0bps[3] 0bps[4] 0bps[5] 0bps[6] 0bps[7] 0bps
  Protection: On, Bypass: 1, LSP: 1, Protected LSP: 1, Unprotected LSP: 0
      3 May 15 08:29:29 New bypass Bypass->2.0.0.66
      2 May 13 12:21:37 Delete bypass Bypass->2.0.0.66->2.0.0.21, inactivity timeout
      1 May 13 09:27:15 New bypass Bypass->2.0.0.66->2.0.0.21
    Bypass: Bypass->2.0.0.66, State: Up, Type: LP, LSP: 1, Backup: 0
      3 May 15 08:29:32 Record Route:  2.0.0.45 2.0.0.57 2.0.0.17
      2 May 15 08:29:32 Up
      1 May 15 08:29:31 CSPF: computation result accepted                    
                

That’s all there is to it. A little recap picture to sum things up:



Complete configuration is here.

17-5-2015