Juniper Static Label Switched Paths (Part 2)

Introduction

In the last post (Juniper Static Label Switched Paths (Part 1)), we took our MPLS core from the posts Simple Juniper MPLS Core w/ L3VPN (Part 1) and Simple Juniper MPLS Core w/ L3VPN (Part 2) and expanded it to add Label Switched Paths in the MPLS core to perform deterministic pathing for our L3VPN.  We created an LSP that took a path from PE-R1 to PE-R3 for the Customer-A L3VPN instead of relying on OSPF to determine the path.  In this post, we will take a look at adding a secondary path so that if/when the primary path fails, a secondary path will take it’s place.

While this will allow us to create a secondary path, the example is a basic one that does not take advanced topics (such as fast-reroute and link protection) and will perform a failover very quickly.  There will be subsequent posts regarding these topics but for now, let’s keep it simple!

Topology

Just like all my posts, lets start off with the topology diagram.  Just like all the others, its a simple MPLS topology with a single L3VPN for Customer-A (CE-A-R1 and CE-A-R2).

Juniper MPLS Diagram

Since last post, our pathing from PE-R1 to PE-R3 no longer relies on OSPF but instead, uses Resource Reservation Protocol (RSVP) as our signaling protocol with a label switched path (LSP) named CUSTOMER-A to take the path PE-R1 -> P-R1 -> PE-R3 to send packets from CE-A-R1 to CE-A-R2.  But what if there is a failure anywhere in that path?  This is where a secondary path comes in.

Label Switched Path Secondary Path

Before we proceed with creating our secondary path, let’s do some quick checks to make sure everything is still good with our current configuration and our traceroute from CE-A-R1 traverses the correct path:

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.742 ms 19.742 ms 19.672 ms
 2 10.0.0.2 (10.0.0.2) 35.266 ms 35.011 ms 30.038 ms
 MPLS Label=299904 CoS=0 TTL=1 S=0
 MPLS Label=299856 CoS=0 TTL=1 S=1
 3 10.0.0.26 (10.0.0.26) 29.531 ms 20.596 ms 29.676 ms
 MPLS Label=299856 CoS=0 TTL=1 S=1
 4 16.16.16.2 (16.16.16.2) 29.838 ms 30.053 ms 30.304 ms

Our traceroute still goes over the primary LSP via PE-R1 -> P-R1 -> PE-R3 and we can also check the ingress LSP to verify as well:

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

100.1.1.5
 From: 100.1.1.1, State: Up, ActiveRoute: 0, LSPname: CUSTOMER-A
 ActivePath: PRIMARY (primary)
 LSPtype: Static Configured
 LoadBalance: Random
 Encoding type: Packet, Switching type: Packet, GPID: IPv4
 *Primary PRIMARY State: Up
 Priorities: 7 0
 SmartOptimizeTimer: 180
 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
 19 Dec 21 07:11:15.014 Selected as active path: due to 'primary'
 18 Dec 21 07:10:14.981 Record Route: 10.0.0.2 10.0.0.26
 17 Dec 21 07:10:14.981 Up

So everything is good.  Traceroute works and we have verified that the primary path (only one that should be configured at this point) is being taken.  So let’s create our secondary!

The secondary path is just like the primary in that you define it in the protocols mpls hierarchy.  You do not have to name the path secondary but just know that this path will be used as a backup in the event of a primary failure.  For this scenario, we are simply going to label it as SECONDARY.  However, this time, instead of configuring explicit hops, we are going to define a single entry as loose.  This tells that the LSP that the path from PE-R1 to PE-R3 does not need to be a direct path.

It gets a bit confusing so let’s take a more detail explanation of strict vs loose (see Juniper’s Configuring and Verifying a Primary Path document):

  • Strict—The route taken from the previous router to this router is a direct path and cannot include any other routers. This is the default. If the address is an interface address, this router also ensures that the incoming interface is the one specified. Specifying the incoming interface is important when there are parallel links between the previous router and this router, and because it ensures that routing can be enforced on a per-link basis.  For strict addresses, you must ensure that the router immediately preceding the router you are configuring has a direct connection to that router. The address can be a loopback interface address, in which case the incoming interface is not checked.
  • Loose—The route taken from the previous router to this router need not be a direct path, can include other routers, and can be received on any interface. The address can be any interface address or the address of the loopback interface.

For our example, we are going to configure our secondary path to take the path PE-R2 initially but after that first hop, take whatever path OSPF says that it should take.  For example, the configuration looks like the following:

label-switched-path CUSTOMER-A {
 to 100.1.1.5;
 no-cspf;
 primary PRIMARY;
 secondary SECONDARY;
}
path PRIMARY {
 10.0.0.2 strict;
 10.0.0.26 strict;
}
path SECONDARY {
 10.0.0.10 strict;
 100.1.1.5 loose;
}

Again, for a basic configuration, there is not much to the secondary path.  We define the path with the hops that we want to take and then under then LSP, we define the secondary path.  As I mentioned prior, this does not tweak any convergence features so this will result in packet loss when the primary path goes down.

Testing and Verification

Before we simulate a path failure, let’s take a look at a few outputs.  First, let’s look at the ingress LSP on PE-R1 to verify that not only do we have a primary but also a secondary LSP:

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)
 LSPtype: Static Configured
 LoadBalance: Random
 Encoding type: Packet, Switching type: Packet, GPID: IPv4
 *Primary PRIMARY State: Up
 Priorities: 7 0
 SmartOptimizeTimer: 180
 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
 Secondary SECONDARY State: Dn
 Priorities: 7 0
 SmartOptimizeTimer: 180
 20 Dec 21 07:49:24.426 Clear Call
Total 1 displayed, Up 1, Down 0

As you can see, we now have a primary path in the up state and a secondary in the down state.  The reason for this is the secondary is not in use and hence has not been signaled by PE-R1 to go into the up state.  So with that out of the way, let’s disable the ge-0/0/0 interface on PE-R1 and take a look at the LSP:

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: SECONDARY (secondary)
 LSPtype: Static Configured
 LoadBalance: Random
 Encoding type: Packet, Switching type: Packet, GPID: IPv4
 Primary PRIMARY State: Dn
 Priorities: 7 0
 SmartOptimizeTimer: 180
 40 Dec 21 07:58:44.369 10.0.0.10: Explicit Route: wrong delivery[2 times]
 *Secondary SECONDARY State: Up
 Priorities: 7 0
 SmartOptimizeTimer: 180
 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
 10.0.0.10 10.0.0.18 10.0.0.34
Total 1 displayed, Up 1, Down 0

We can now see that PE-R1 has signaled the secondary path due to the link failure.  Since we only configured a single explicit path of 10.0.0.10, OSPF dictated where the link should go after that and it determine it to be P-R2 and then PE-R3.  We can verify that traffic from CE-A-R1 is now taking that path (note, to see the MPLS information in the traceroute, I also enabled icmp-tunneling on PE-R2 since it is acting as a transit router now):

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) 19.977 ms 14.846 ms 9.773 ms
 2 10.0.0.10 (10.0.0.10) 25.138 ms 25.805 ms 39.477 ms
 MPLS Label=299888 CoS=0 TTL=1 S=0
 MPLS Label=299856 CoS=0 TTL=1 S=1
 3 10.0.0.18 (10.0.0.18) 50.253 ms 50.017 ms 34.697 ms
 MPLS Label=299936 CoS=0 TTL=1 S=0
 MPLS Label=299856 CoS=0 TTL=2 S=1
 4 10.0.0.34 (10.0.0.34) 30.016 ms 29.873 ms 29.978 ms
 MPLS Label=299856 CoS=0 TTL=1 S=1
 5 16.16.16.2 (16.16.16.2) 34.963 ms 35.059 ms 40.162 ms

As you can see, the traceroute has confirmed that the path is now over the secondary LSP.  We can also go on a device that is a transit router to see that the LSP is traversing it.  For example, since PE-R2 is now in the path of the LSP, if you use the command show mpls lsp transit detail, you will see the information for the LSP:

root@PE-R2> show mpls lsp transit detail
Transit LSP: 1 sessions

100.1.1.5
 From: 100.1.1.1, LSPstate: Up, ActiveRoute: 0
 LSPname: CUSTOMER-A, LSPpath: Secondary
 Suggested label received: -, Suggested label sent: -
 Recovery label received: -, Recovery label sent: 299936
 Resv style: 1 FF, Label in: 299888, Label out: 299936
 Time left: 157, Since: Mon Dec 21 07:58:39 2015
 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
 Port number: sender 6 receiver 50017 protocol 0
 PATH rcvfrom: 10.0.0.9 (ge-0/0/0.0) 9 pkts
 Adspec: received MTU 1500 sent MTU 1500
 PATH sentto: 10.0.0.18 (ge-0/0/2.0) 8 pkts
 RESV rcvfrom: 10.0.0.18 (ge-0/0/2.0) 8 pkts
 Explct route: 10.0.0.18 100.1.1.5
 Record route: 10.0.0.9 <self> 10.0.0.18 10.0.0.34
Total 1 displayed, Up 1, Down 0

Conclusion

There you have it, a secondary path being used in the event of the primary going down.  Now, if you were to reactivate the ge-0/0/0 interface on PE-R1, PE-R1 will signal the primary path and both primary/secondary will be up.  However, until the router knows that the path is stable, it will still send packets over the secondary until it is confident that it can send it over the primary.  Once it starts doing that, it will tear down the secondary and move it back to the down state.

In an upcoming post, I will show how you can configure the LSP to automatically have the secondary path in an up state and have it transition immediately over the secondary path in the event of a primary path failure.  This is where things get really interesting and fun.  Stay tuned.

Troy Perkins

Leave a Reply

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