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):
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 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:
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.
