Protecting an LSPs Path

Problem

You want to protect an LSPs traffic in the event of a link or router failure to ensure that it always arrives at the egress end of the LSP.

Solution

When you create an LSP, RSVP establishes a single path between the ingress and egress routers. One way to protect the LSPs path is to establish an end-to-end secondary path for the LSP. First, explicitly set up the primary LSP:

	[edit protocols mpls]
	aviva@R1# set label-switched-path R1-to-R5 to 10.0.0.5
	aviva@R1# set label-switched-path R1-to-R5 bandwidth 50m
	aviva@R1# set label-switched-path R1-to-R5 primary primary-path-R1-to-R5
	aviva@R1# set path primary-path-R1-to-R5	

Then, configure a secondary path to the same egress router:

	[edit protocols mpls]
	aviva@R1# set label-switched-path R1-to-R5 secondary secondary-path-R1-to-R5 standby
	aviva@R1# set path secondary-path-R1-to-R5

Discussion

When you create a basic LSP on the ingress router, one route is set up to reach the egress router and all the LSPs traffic is forwarded along this route. If a failure occurs along the pathfor instance, if a routers interface goes offline, if an entire router goes down, or if the physical link between two routers is cutthe ingress router recalculates the LSPs path and re-establishes the LSP if possible. However, until the ingress route learns of the LSP failure and recalculates a new LSP, all traffic going into the LSP is dropped and never reaches the egress. Depending on the length of the LSP, the speeds of the interfaces, and other factors, it can take some seconds for the new LSP to become operational. One way to provide a redundant path is to set up a secondary path in advance and have it always be on call in case the primary path fails so that it can immediately take over forwarding the LSPs traffic. An optimal secondary LSP takes a completely different path through the network so that there are no common links or routers shared by the two LSPs. For this recipe, the network topology is extended to six routers (see Figure 14-7).

The first part of this recipe sets up the primary path on the ingress router, R1. The first command names the LSP and specifies the address of the egress router, R5. The second command reserves bandwidth for the LSP, here requesting 50 Mbps. The third command creates the primary LSP and names it primary-path-R1-to-R5. The final command, the set path command, tells MPLS about the name of the path.

Figure 14-7. Six-router topology for RSVP-signaled LSPs

At this point in the configuration, you can verify that the primary path has been established:

	aviva@R1> show mpls lsp ingress extensive
	Ingress LSP: 1 sessions
	10.0.0.5
	 From: 10.0.0.1, State: Up, ActiveRoute: 0, LSPname: R1-to-R5
	 ActivePath: primary-path-R1-to-R5 (primary)
	 LoadBalance: Random
	 Encoding type: Packet, Switching type: Packet, GPID: IPv4
	 *Primary primary-path-R1-to-R5 State: Up
	 Bandwidth: 50Mbps
	 SmartOptimizeTimer: 180
	 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
	 10.1.13.2 10.1.34.2 10.1.45.2
	 5 Oct 7 09:15:34 Selected as active path
	 4 Oct 7 09:15:34 Record Route: 10.1.13.2 10.1.34.2 10.1.45.2
	 3 Oct 7 09:15:34 Up
	 2 Oct 7 09:15:34 Originate Call
	 1 Oct 7 09:15:05 Path name undefined or disabled[3 times]
	 Created: Fri Oct 7 09:14:36 2005
	 Total 1 displayed, Up 1, Down 0

This output shows that the LSP to 10.0.0.5, the egress router, is up (State: Up) and is the primary path to the egress router. The Bandwidth field indicates that the requested bandwidth reservation of 50 Mbps has been honored and allocated. The RSVP RRO in the path calculation log (line 4 in the log) contains the path being followed by the primary LSP. This LSP goes first to R3 (10.1.31.2) and then to R4 (10.1.34.2) before reaching the egress at R5 (10.1.45.2). The following command shows that RSVP has reserved the bandwidth:

	aviva@R1> show rsvp interface
	RSVP interface: 2 active
	 Active Subscr- Static Available Reserved Highwater
	Interface State resv iption BW BW BW mark
	so-0/0/0.0 Up 0 100% 155.52Mbps 155.52Mbps 0bps 0bps
	so-0/0/2.0 Up 1 100% 155.52Mbps 105.52Mbps 50Mbps 50Mbps

For interface so-0/0/2, which connects to R3, the first router in the LSP, the output shows that 50 Mbps have been reserved and 105.52 Mbps are still available.

Next in the configuration is to set up a secondary path. There are two commands for this. The first command creates the secondary path in the LSP, and the second defines the path for MPLS. This recipe uses the standby option in the secondary path so the path is established when the primary path is set up and remains up at all times. This means that the secondary path is always available to take over immediately if the primary path fails. The result is that no traffic is dropped during the time it takes for CSPF to calculate a new route and RSVP to signal a new path.

Look at the LSP again to check that the secondary path has been set up. A quick glance shows two RSVP sessions for the R1-to-R5 LSP:

	aviva@R1>  
show rsvp session ingress
	Ingress RSVP: 2 sessions
	To From State Rt Style Labelin Labelout LSPname
	10.0.0.5 10.0.0.1 Up 0 1 FF - 100144 R1-to-R5
	10.0.0.5 10.0.0.1 Up 0 1 FF - 100160 R1-to-R5
	Total 2 displayed, Up 2, Down 0

A detailed look at the LSP shows more information about the two paths:

	aviva@R1> show mpls lsp ingress extensive
	Ingress LSP: 1 sessions
	10.0.0.5
	 From: 10.0.0.1, State: Up, ActiveRoute: 0, LSPname: R1-to-R5
	 ActivePath: primary-path-R1-to-R5 (primary)
	 LoadBalance: Random
	 Encoding type: Packet, Switching type: Packet, GPID: IPv4
	 *Primary primary-path-R1-to-R5 State: Up
	 Bandwidth: 50Mbps
	 SmartOptimizeTimer: 180
	 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
	 10.1.13.2 10.1.34.2 10.1.45.2
	 5 Oct 7 09:15:34 Selected as active path
	 4 Oct 7 09:15:34 Record Route: 10.1.13.2 10.1.34.2 10.1.45.2
	 3 Oct 7 09:15:34 Up
	 2 Oct 7 09:15:34 Originate Call
	 1 Oct 7 09:15:05 Path name undefined or disabled[3 times]
	 Standby secondary-path-R1-to-R5 State: Up
	 Bandwidth: 50Mbps
	 SmartOptimizeTimer: 180
	 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
	 10.1.13.2 10.1.36.2 10.1.56.1
	 3 Oct 7 09:26:07 Record Route: 10.1.12.2 10.1.24.2 10.1.45.2
	 2 Oct 7 09:26:07 Up
	 1 Oct 7 09:26:07 Originate Call
	 Created: Fri Oct 7 09:14:37 2005
	Total 1 displayed, Up 1, Down 0

In addition to the primary path, the LSP now has the secondary, standby path, which is up and for which 50 Mbps of bandwidth have been reserved. Check RSVP again to verify the bandwidth reservation:

	aviva@R1show rsvp interface
	RSVP interface: 2 active
	 Active Subscr- Static Available Reserved Highwater
	Interface State resv iption BW BW BW mark
	so-0/0/0.0 Up 1 100% 155.52Mbps 105.52Mbps 50Mbps 50Mbps
	so-0/0/2.0 Up 1 100% 155.52Mbps 105.52Mbps 50Mbps 100Mbps

The output shows that RSVP has reserved 50 Mbps for the secondary LSP on the routers other interface, so-0/0/0.

The difference between the primary and secondary paths is the path itself. The Record Route fields, which contain the information in the RSVP RRO, show the two paths. The primary path goes along 10.1.13.2 to R3, then along 10.1.34.2 to R4, and finally along 10.1.45.2 to reach the egress router, R5:

	4 Oct 7 09:15:34 Record Route: 10.1.13.2 10.1.34.2 10.1.45.2

The secondary path goes out 10.0.12.1 to R2, then along 10.1.24.2 to R4 to reach R5:

	3 Oct 7 09:26:07 Record Route: 10.1.12.2 10.1.24.2 10.1.45.2

The two paths from R1 to R5 are completely separate and nonoverlapping, so the secondary path provides nonredundant backup in case the primary LSP fails. Because the LSP is being signaled and set up automatically, the secondary path might share routers with the primary path. However, the JUNOS CSPF calculation tries to ensure that the primary and secondary paths do not overlap where possible; the calculation of the secondary path by CSPF takes the path of the primary into account. Lets look at an example where this happens. First, look at the interfaces on which RSVP has reserved bandwidth:

	aviva@R1> show rsvp interface
	RSVP interface: 2 active
	 Active Subscr- Static Available Reserved Highwater
	Interface State resv iption BW BW BW mark
	so-0/0/0.0 Up 0 100% 155.52Mbps 155.52Mbps 0bps 50Mbps
	so-0/0/2.0 Up 2 100% 155.52Mbps 55.52Mbps 100Mbps 100Mbps

The configuration allocates 50 Mbps for the primary path, and this output shows that RSVP has set aside 100 Mbps on a single interface, so-0/0/2, so you know that both the primary and secondary LSPs are being routed toward R3. To check this, look at the LSPs record route:

	aviva@R1> show mpls lsp ingress extensive
	Ingress LSP: 1 sessions
	10.0.0.5
	 From: 10.0.0.1, State: Up, ActiveRoute: 0, LSPname: R1-to-R5
	 ActivePath: primary-path-R1-to-R5 (primary)
	 LoadBalance: Random
	 Encoding type: Packet, Switching type: Packet, GPID: IPv4
	 *Primary primary-path-R1-to-R5 State: Up
	 Bandwidth: 50Mbps
	 SmartOptimizeTimer: 180
	 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
	 10.1.13.2 10.1.34.2 10.1.45.2
	 22 Oct 12 14:53:24 Selected as active path
	 21 Oct 12 14:53:24 Record Route: 10.1.13.2 10.1.34.2 10.1.45.2
	 20 Oct 12 14:53:24 Up
	 19 Oct 12 14:53:24 Originate Call
	…
	 Standby secondary-path-R1-to-R5 State: Up
	 Bandwidth: 50Mbps
	 SmartOptimizeTimer: 180
	 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
	 10.1.13.2 10.1.36.2 10.1.56.1
	 35 Oct 12 14:55:56 Record Route: 10.1.13.2 10.1.36.2 10.1.56.1
	 34 Oct 12 14:55:56 Up
	 33 Oct 12 14:55:55 Originate Call
	…
	Total 1 displayed, Up 1, Down 0

This output confirms that RSVP has routed both the primary and secondary LSPs through R3 (10.1.13.2). You can force one of the LSPs to go through R2 instead by manually configuring the LSPs next hop. The following command explicitly configures the first next hop for the secondary LSP:

	[edit protocols mpls]
	aviva@R1# set path secondary-path-R1-to-R5 10.1.12.2

Checking the RSVP bandwidth reservation confirms the change:

	aviva@R1> show rsvp interface
	RSVP interface: 2 active
	 Active Subscr- Static Available Reserved Highwater
	Interface State resv iption BW BW BW mark
	so-0/0/0.0 Up 1 100% 155.52Mbps 105.52Mbps 50Mbps 50Mbps
	so-0/0/2.0 Up 1 100% 155.52Mbps 105.52Mbps 50Mbps 100Mbps

RSVP has reserved 50 Mbps on each of the two outgoing interfaces. Looking at the LSP paths shows that the two paths are indeed different:

	aviva@R1> show mpls lsp ingress extensive
	Ingress LSP: 1 sessions
	10.0.0.5
	 From: 10.0.0.1, State: Up, ActiveRoute: 0, LSPname: R1-to-R5
	 ActivePath: primary-path-R1-to-R5 (primary)
	 LoadBalance: Random
	 Encoding type: Packet, Switching type: Packet, GPID: IPv4
	 *Primary primary-path-R1-to-R5 State: Up
	 Bandwidth: 50Mbps
	 SmartOptimizeTimer: 180
	 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
	 10.1.13.2 10.1.34.2 10.1.45.2
	 22 Oct 12 14:53:24 Selected as active path
	 21 Oct 12 14:53:24 Record Route: 10.1.13.2 10.1.34.2 10.1.45.2
	 20 Oct 12 14:53:24 Up
	 19 Oct 12 14:53:24 Originate Call
	…
	 Standby secondary-path-R1-to-R5 State: Up
	 Bandwidth: 50Mbps
	 SmartOptimizeTimer: 180
	 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
	 10.1.12.2 10.1.24.2 10.1.45.2
	 39 Oct 12 15:07:10 Record Route: 10.1.12.2 10.1.24.2 10.1.45.2
	 38 Oct 12 15:07:10 Up
	 37 Oct 12 15:07:10 Originate Call
	 36 Oct 12 15:07:10 Clear Call
	…
	Total 1 displayed, Up 1,

The show rsvp interface output illustrates an important point about secondary paths, which is that the secondary path inherits the same properties as the primary path. In the output, you see that RSVP has reserved the same amount of bandwidth (50 Mbps) for both the secondary and primary paths, so 100 Mbps total are reserved for the primary and secondary LSPs. This points out one of the drawbacks of having a secondary LSP that is on standby. Even though the secondary path is used only rarely, bandwidth resources must always be set aside for it so that the secondary path is always available. If your networks link resources are constrained in any way, you should consider different methods of protecting LSPs, such as fast reroute (see Recipe 14.12) and autobandwidth (see Recipe 14.13).

When setting up secondary paths, be careful not to overallocate resources accidentally. For the SONET link in this example, if you set aside 80 Mbps for the primary LSP, RSVP can establish the LSP just fine:

	[edit protocols mpls]
	aviva@R1# set label-switched-path R1-to-R5 bandwidth 80m
	aviva@R1# commit and-quit
	commit complete
	Exiting configuration mode
	aviva@R1> show rsvp interface
	RSVP interface: 2 active
	 Active Subscr- Static Available Reserved Highwater
	Interface State resv iption BW BW BW mark
	so-0/0/0.0 Up 0 100% 155.52Mbps 155.52Mbps 0bps 0bps
	so-0/0/2.0 Up 1 100% 155.52Mbps 75.52Mbps 80Mbps 100Mbps

However, RSVP cannot establish the secondary LSP:

	aviva@R1> show mpls lsp ingress extensive
	Ingress LSP: 1 sessions
	10.0.0.5
	 From: 10.0.0.1, State: Up, ActiveRoute: 0, LSPname: R1-to-R5
	 ActivePath: primary-path-R1-to-R5 (primary)
	 LoadBalance: Random
	 Encoding type: Packet, Switching type: Packet, GPID: IPv4
	 *Primary primary-path-R1-to-R5 State: Up
	 Bandwidth: 80Mbps
	 SmartOptimizeTimer: 180
	 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
	 10.1.13.2 10.1.36.2 10.1.56.1
	 9 Oct 7 09:32:15 Record Route: 10.1.13.2 10.1.36.2 10.1.56.1
	 8 Oct 7 09:32:15 Up
	 7 Oct 7 09:32:15 Originate Call
	 6 Oct 7 09:32:15 Clear Call
	 5 Oct 7 09:15:34 Selected as active path
	 4 Oct 7 09:15:34 Record Route: 10.1.13.2 10.1.34.2 10.1.45.2
	 3 Oct 7 09:15:34 Up
	 2 Oct 7 09:15:34 Originate Call
	 1 Oct 7 09:15:05 Path name undefined or disabled[3 times]
	 Standby secondary-path-R1-to-R5 State: Dn
	 Bandwidth: 80Mbps
	 SmartOptimizeTimer: 180
	 6 Oct 7 09:33:18 Requested bandwidth unavailable[14 times]
	 5 Oct 7 09:32:15 Originate Call
	 4 Oct 7 09:32:15 Clear Call
	 3 Oct 7 09:26:07 Record Route: 10.1.13.2 10.1.36.2 10.1.56.1
	 2 Oct 7 09:26:07 Up
	 1 Oct 7 09:26:07 Originate Call
	 Created: Fri Oct 7 09:14:36 2005
	Total 1 displayed, Up 1, Down 0

This output shows that the secondary path is down because of insufficient bandwidth on the link. The interface has 155.52 Mbps total bandwidth, but the two LSPs need 160 Mbps. To not have RSVP double-count the bandwidth, you can make the secondary LSP adaptive:

	[edit protocols mpls]
	aviva@R1# set label-switched-path R1-to-R5 adaptive

In adaptive mode, the bandwidth reservation for the secondary path is shared with that for the primary path, so RSVP is now able to establish the secondary LSP. Checking the LSP again:

	aviva@R1> show mpls lsp ingress extensive
	Ingress LSP: 1 sessions
	10.0.0.5
	 From: 10.0.0.1, State: Up, ActiveRoute: 0, LSPname: R1-to-R5
	 ActivePath: primary-path-R1-to-R5 (primary)
	 LoadBalance: Random
	 Encoding type: Packet, Switching type: Packet, GPID: IPv4
	 *Primary primary-path-R1-to-R5 State: Up
	 Bandwidth: 80Mbps
	 SmartOptimizeTimer: 180
	 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
	 10.1.13.2 10.1.36.2 10.1.56.1
	 4 Oct 7 09:34:29 Selected as active path
	 3 Oct 7 09:34:29 Record Route: 10.1.13.2 10.1.36.2 10.1.56.1
	 2 Oct 7 09:34:29 Up
	 1 Oct 7 09:34:28 Originate Call
	 Standby secondary-path-R1-to-R5 State: Up
	 Bandwidth: 80Mbps
	 SmartOptimizeTimer: 180
	 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
	 10.1.13.2 10.1.36.2 10.1.56.1
	 3 Oct 7 09:34:57 Record Route: 10.1.13.2 10.1.36.2 10.1.56.1
	 2 Oct 7 09:34:57 Up
	 1 Oct 7 09:34:57 Originate Call
	 Created: Fri Oct 7 09:34:28 2005
	Total 1 displayed, Up 1, Down 0

The output verifies that the secondary LSP has been established.

Another option is not to reserve bandwidth at all for the secondary path, which gives protection but without any guarantees.

In addition to needing to reserve bandwidth for rarely used secondary paths, secondary LSPs have two other disadvantages that may cause you to consider using different protection methods. One is that this configuration creates a single secondary standby for each protected path. If both paths fail, the desired protection is not provided. Although you can create more than one secondary path, you are again faced with the problem of reserving bandwidth for several rarely used paths. A second disadvantage is that the secondary LSP takes effect only when the ingress router learns of the failure in the path, so some traffic in the LSP will be lost. Methods such as fast reroute kick in when routers along the LSP learn of a failure, resulting in less loss of traffic.

See Also

Recipes 14.12 and 14.13