Label Switched Paths Fast-Reroute

Introduction

In the last few posts we have created a primary and secondary label switched path (LSP) through our Multiprotocol Label Switching (MPLS) core with traffic switching over to the secondary in the event of a primary failure.  However, this takes time and this will not work for traffic that is considered critical and if there are Service Level Agreements (SLA) in place, customers may be entitled to monetary compenstation for the downtime.  This is where resiliency technologies come into play.

When you use Resource Reservation Protocol w/ Traffic Engineering extensions (RSVP-TE), you have the ability to use a few MPLS resiliency technologies.  These technologies include Fast-Reroute, Node Protection, and Link Protection.  The first one we will talk about is Fast-Reroute.

Fast-Reroute Protection

The whole purpose of LSP resiliency is to protect the traffic traversing an LSP from dropping traffic in the event of a failure within the path of the LSP.  If a failure is detected, there should be a mechanism to automatically switch the traffic over to another LSP without dropping traffic so packets can flow until the primary LSP comes back up and is considered stable.   When we start talking about these technologies, you have the three different protections mentioned prior but they are different in how/what they protect.

There are a few things to understand about Fast-Reroute before we get into configuring it inside our core.  Fast Reroute uses detours along the path of the LSP that are pre-computed and pre-established and a detour path is created for each LSP and cannot be shared.  For a more detailed overview, please check out the Fast Reroute Overview on Juniper’s website.  Next, Fast Reroute configuration is only needed on the ingress Provider Edge (PE) routers.  This is because the ingress router will signal all downstream routers that Fast Reroute is enabled for the LSP and each router in the path of the LSP will calculate a detour in the event of a failed link.

That last part is key as it the router in the path of the LSP that detects a link failure will route traffic for that LSP over it’s detour link.  While this is happening, the ingress router will recalculate an optimal path to the egress router and then switch traffic from the LSP flowing via the detour over to the new LSP.  Let’s take a look.

Fast-Reroute Configuration

Below is the normal MPLS topology that we have been using with our scenarios and a single LSP from PE-R1 (100.1.1.1) to PE-R3 (100.1.1.5).  I have removed the secondary path for the LSP and have a single entry in the primary path that says 100.1.1.5 loose so that we allow OSPF to determine the route that is taken from PE-R1 to PE-R2.  So the topology and configuration on PE-R1 looks like this (with our LSP in green):

Fast Reroute with Primary LSP
Fast Reroute with Primary LSP
root@PE-R1> show configuration protocols mpls label-switched-path CUSTOMER-A
to 100.1.1.5;
fast-reroute;
primary PRIMARY;

As you can see from the diagram, RSVP has determined that the LSP should take the path from PE-R1 through P-R1 to get to PE-R3.  Take a look at the following outputs using the command show mpls lsp ingress detail and show route 100.1.1.5/32:

root@PE-R1> show mpls lsp ingress detail
Ingress LSP: 1 sessions

100.1.1.5
  From: 100.1.1.1, State: Up, ActiveRoute: 0, LSPname: CUSTOMER-A
  ActivePath: PRIMARY (primary)
  FastReroute desired
  LSPtype: Static Configured
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
 *Primary   PRIMARY          State: Up
    Priorities: 7 0
    SmartOptimizeTimer: 180
    Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 2)
 10.0.0.2 S 10.0.0.26 S
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          10.0.0.2 10.0.0.26
Total 1 displayed, Up 1, Down 0

root@PE-R1> show route 100.1.1.5/32

inet.0: 25 destinations, 25 routes (25 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

100.1.1.5/32       *[OSPF/10] 00:02:36, metric 2
                    > to 10.0.0.2 via ge-0/0/0.0

inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

100.1.1.5/32       *[RSVP/7/1] 00:02:31, metric 2
                    > to 10.0.0.2 via ge-0/0/0.0, label-switched-path CUSTOMER-A
                      to 10.0.0.6 via ge-0/0/1.0, label-switched-path CUSTOMER-A

We see that the primary LSP is up, Fast Reroute has been set to desired, and the LSP is traversing the path as described prior.  This is also confirmed by the traceroute on CE-A-R1 to CE-A-R2’s loopback address:

root@CE-A-R1> traceroute 16.16.16.2
traceroute to 16.16.16.2 (16.16.16.2), 30 hops max, 40 byte packets
 1  172.16.1.1 (172.16.1.1)  15.147 ms  9.976 ms  15.119 ms
 2  10.0.0.2 (10.0.0.2)  34.959 ms  30.675 ms  39.290 ms
     MPLS Label=301440 CoS=0 TTL=1 S=0
     MPLS Label=299904 CoS=0 TTL=1 S=1
 3  10.0.0.26 (10.0.0.26)  30.158 ms  30.021 ms  29.961 ms
     MPLS Label=299904 CoS=0 TTL=1 S=1
 4  16.16.16.2 (16.16.16.2)  39.971 ms  39.729 ms  45.212 ms

We can also confirm that the LSP is traversing P-R1 as a transit LSP and that a detour LSP has been signaled as well:

100.1.1.5
  From: 100.1.1.1, LSPstate: Up, ActiveRoute: 0
  LSPname: CUSTOMER-A, LSPpath: Primary
  Suggested label received: -, Suggested label sent: -
  Recovery label received: -, Recovery label sent: 3
  Resv style: 1 FF, Label in: 301440, Label out: 3
  Time left:  141, Since: Thu Dec 24 09:21:19 2015
  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
  Port number: sender 42 receiver 50024 protocol 0
  FastReroute desired
  PATH rcvfrom: 10.0.0.1 (ge-0/0/0.0) 13 pkts
  Adspec: received MTU 1500 sent MTU 1500
  PATH sentto: 10.0.0.26 (ge-0/0/4.0) 12 pkts
  RESV rcvfrom: 10.0.0.26 (ge-0/0/4.0) 9 pkts
  Explct route: 10.0.0.26
  Record route: 10.0.0.1 <self> 10.0.0.26
    Detour is Up
    Detour Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
    Detour adspec: received MTU 1500 sent MTU 1500
    Path MTU: received 1500
    Detour PATH sentto: 10.0.0.22 (ge-0/0/2.0) 10 pkts
    Detour RESV rcvfrom: 10.0.0.22 (ge-0/0/2.0) 7 pkts
    Detour Explct route: 10.0.0.22 10.0.0.38 10.0.0.41
    Detour Record route: 10.0.0.1 <self> 10.0.0.22 10.0.0.38 10.0.0.41
    Detour Label out: 301792
Total 2 displayed, Up 2, Down 0

Couple of things (highlighted in green) jump out on P-R1.  First, it knows that the LSP from PE-R1 to PE-R3 has Fast Reroute desired so it has set up a detour LSP and it is up.  Currently it is configured to traverse P-R2 (10.0.0.22) then go to PE-R3 (10.0.0.41) in the event of a path failure as show below (detour is shown as a dotted orange line):

Label Switched Fast Reroute w/ Detour
Label Switched Fast Reroute w/ Detour

Label Switched Path Failure

Now that we have our LSP configured for Fast Reroute and both the LSP and detour LSP have been signaled on P-R1, let’s simulate a failure of the link between P-R1 and PE-R3.  We are going to start a ping from CE-A-R1 to CE-A-R2’s loopback address, fail the link, and the perform some show commands to verify that we did not drop traffic and the LSP has detoured the failed link.  First, let’s check the ping from CE-A-R1 after the link failure:

root@CE-A-R1> ping 16.16.16.2
PING 16.16.16.2 (16.16.16.2): 56 data bytes
64 bytes from 16.16.16.2: icmp_seq=0 ttl=60 time=35.178 ms
64 bytes from 16.16.16.2: icmp_seq=1 ttl=60 time=35.822 ms
64 bytes from 16.16.16.2: icmp_seq=2 ttl=60 time=40.993 ms
64 bytes from 16.16.16.2: icmp_seq=3 ttl=60 time=36.101 ms
64 bytes from 16.16.16.2: icmp_seq=4 ttl=60 time=30.959 ms
64 bytes from 16.16.16.2: icmp_seq=5 ttl=60 time=30.659 ms
64 bytes from 16.16.16.2: icmp_seq=6 ttl=60 time=25.608 ms
64 bytes from 16.16.16.2: icmp_seq=7 ttl=60 time=30.448 ms
64 bytes from 16.16.16.2: icmp_seq=8 ttl=60 time=30.632 ms
64 bytes from 16.16.16.2: icmp_seq=9 ttl=60 time=30.776 ms
64 bytes from 16.16.16.2: icmp_seq=10 ttl=60 time=30.559 ms
64 bytes from 16.16.16.2: icmp_seq=11 ttl=60 time=30.490 ms
64 bytes from 16.16.16.2: icmp_seq=12 ttl=60 time=35.527 ms
64 bytes from 16.16.16.2: icmp_seq=13 ttl=60 time=40.204 ms
64 bytes from 16.16.16.2: icmp_seq=14 ttl=60 time=31.051 ms

The packets highlighted in yellow is roughly when the link was failed.  As you can tell by the sequence numbers, no packets were dropped.  Now, let’s check out the ingress LSP on PE-R1 to see what is going on:

root@PE-R1> show mpls lsp ingress detail
Ingress LSP: 1 sessions

100.1.1.5
  From: 100.1.1.1, State: Up, ActiveRoute: 0, LSPname: CUSTOMER-A
  ActivePath: PRIMARY (primary)
  FastReroute desired
  LSPtype: Static Configured
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
 *Primary   PRIMARY          State: Up
    Priorities: 7 0
    SmartOptimizeTimer: 180
    Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3)
 10.0.0.6 S 10.0.0.38 S 10.0.0.41 S
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          10.0.0.6 10.0.0.38 10.0.0.41
Total 1 displayed, Up 1, Down 0

As you can see in the highlighted green text, we are now traversing P-R2 to get to PE-R3 and it now looks like this:

Fast Reroute around failed link
Fast Reroute around failed link

As you can see, after P-R1 sent a notification to PE-R1 that it has detoured the LSP around the failed link, PE-R1 re-signaled the LSP to go through P-R2.  This can be further confirmed by looking at the transit LSP on P-R2 using the command show mpls lsp transit detail:

100.1.1.5
  From: 100.1.1.1, LSPstate: Up, ActiveRoute: 0
  LSPname: CUSTOMER-A, LSPpath: Primary
  Suggested label received: -, Suggested label sent: -
  Recovery label received: -, Recovery label sent: 300672
  Resv style: 1 FF, Label in: 301824, Label out: 300672
  Time left:  158, Since: Thu Dec 24 09:28:33 2015
  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
  Port number: sender 43 receiver 50024 protocol 0
  FastReroute desired
  PATH rcvfrom: 10.0.0.5 (ge-0/0/1.0) 11 pkts
  Adspec: received MTU 1500 sent MTU 1500
  PATH sentto: 10.0.0.38 (ge-0/0/4.0) 6 pkts
  RESV rcvfrom: 10.0.0.38 (ge-0/0/4.0) 5 pkts
  Explct route: 10.0.0.38 10.0.0.41
  Record route: 10.0.0.5 <self> 10.0.0.38 10.0.0.41
  Detour branch from 10.0.0.1, to skip 100.1.1.4, Up
    Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
    Adspec: received MTU 1500
    Path MTU: received 0
    PATH rcvfrom: 10.0.0.21 (ge-0/0/2.0) 4 pkts
    Adspec: received MTU 1500
    PATH sentto: 10.0.0.38 (ge-0/0/4.0) 0 pkts
    RESV rcvfrom: 10.0.0.38 (ge-0/0/4.0) 0 pkts
    Explct route: 10.0.0.38 10.0.0.41
    Record route: 10.0.0.1 10.0.0.21 <self> 10.0.0.38 10.0.0.41
    Label in: 301840, Label out: 300672
Total 2 displayed, Up 2, Down 0

As you can see there is still a detour on PE-R1 that traverses P-R1 in the event of another failure but for now, the LSP has been signaled and is in an up state.  Fruther confirmation from CE-A-R1 shows that packets are now traversing the path as shown:

root@CE-A-R1> traceroute 16.16.16.2
traceroute to 16.16.16.2 (16.16.16.2), 30 hops max, 40 byte packets
 1  172.16.1.1 (172.16.1.1)  15.504 ms  19.606 ms  20.068 ms
 2  10.0.0.6 (10.0.0.6)  45.133 ms  40.328 ms  34.024 ms
     MPLS Label=301824 CoS=0 TTL=1 S=0
     MPLS Label=299904 CoS=0 TTL=1 S=1
 3  10.0.0.38 (10.0.0.38)  45.868 ms  38.876 ms  29.673 ms
     MPLS Label=300672 CoS=0 TTL=1 S=0
     MPLS Label=299904 CoS=0 TTL=2 S=1
 4  10.0.0.41 (10.0.0.41)  35.009 ms  34.879 ms  29.961 ms
     MPLS Label=299904 CoS=0 TTL=1 S=1
 5  16.16.16.2 (16.16.16.2)  39.946 ms  39.641 ms  35.453 ms

Conclusion

As you can see, without a secondary LSP configured and PE-R1 signaling to the core that it wishes to use Fast Reroute, we are able to route around a failed link/node with no dropped packets from the customer.  Obviously this is a very basic example but there are notable issues with scale which are discussed in detail on several websites and documents which I recommend reading.  But for now, realize that Fast Reroute is an option for resiliency in a MPLS core.

In the next few posts, I will start showing you how to configure link- and node-protection which have several benefits including bypass LSPs and the ability to have LSPs share resources on the bypass LSP.

Troy Perkins

Leave a Reply

Your email address will not be published. Required fields are marked *