Using Fast Reroute to Reduce Packet Loss Following a Link Failure
Problem
You want to reduce packet loss when a link along an LSP fails.
Solution
Fast reroute reduces packet loss when a link in the LSP fails. You configure fast reroute on the ingress router only:
[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 fast-reroute
Discussion
A basic function of IP routing protocols is to reroute traffic changes that occur in the network, such as a link or router node failure. Because the IP routing protocols are distributed across the network devices and because all routers must have a consistent view of the network, it can take some time for the routes to converge after a topology change. In a large network, convergence times can be on the order of several seconds, which may be unacceptable for your service-level agreements (SLAs).
MPLS fast reroute provides a solution to the convergence problem by rerouting traffic around a point of failure in an LSP. Fast reroute sets up a protection LSP around a point of failure in advance to protect an individual link between two routers. Each router in the LSP sets up protection LSPs when the ingress router signals the initial setup of the LSP. When a link along an LSP fails, the router upstream of the failure switches to the protection LSP as soon as it detects the failure. No route calculations need to be done because the protection LSP is signaled and set up in advance, and the routing protocols don need to converge, so the move to a path that circumvents the point of failure can happen quickly. Following a failure, the ingress router is notified and can compute a new path at its leisure. Traffic is protected in the meantime.
Fast reroute does not eliminate packet loss; it merely minimizes it. When a path fails and MPLS switches to the protection LSP, the MPLS routers still need some small amount of time to detect the failure and switch to the alternate path. The ingress router can then recalculate the LSP if necessary. During the switchover, the LSP will continue forwarding traffic while a new LSP is established.
You configure fast reroute only on the ingress router. You do not need to configure it on the LSPs transit and egress routers. As this recipe shows, the configuration is straightforward: just include the fast-reroute statement in the LSPs configuration. Once the LPS is running fast reroute, the ingress router signals all downstream routers that fast reroute has been requested and indicate which link requires protection, and each downstream router does its best to set up detours for the LSP. If a downstream router does not support fast reroute, it ignores the request to set up detours but continues to support the LSP. A router that does not support fast reroute will cause some of the detours to fail but otherwise has no impact on the LSP.
To check that fast reroute is configured and working properly, first verify that the ingress router has created an operational 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) FastReroute desired LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary primary-path-R1-to-R5 State: Up SmartOptimizeTimer: 180 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30) 10.1.13.2 S 10.1.36.2 S 10.1.56.1 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt): 10.1.13.2(flag=9) 10.1.36.2(flag=1) 10.1.56.1 8 Oct 12 15:15:31 Fast-reroute Detour Up 7 Oct 12 15:15:22 Record Route: 10.1.13.2(flag=9) 10.1.36.2(flag=1) 10.1.56.1 6 Oct 12 15:15:22 Record Route: 10.1.13.2(flag=9) 10.1.36.2 10.1.56.1 5 Oct 12 15:15:19 Selected as active path 4 Oct 12 15:15:19 Record Route: 10.1.13.2 10.1.36.2 10.1.56.1 3 Oct 12 15:15:18 Up 2 Oct 12 15:15:18 Originate Call 1 Oct 12 15:15:18 CSPF: computation result accepted Created: Wed Oct 12 15:15:18 2005 Total 1 displayed, Up 1, Down 0
This output shows the details of the LSP on the ingress router, R1. The LSP goes to 10.0.0.5 from 10.0.0.1, which is correct, and the state is Up, so the LSP is operational. The line FastReroute desired tells you that the ingress router has signaled the routers that might participate in the LSP to use fast reroute. This indicates that the fast reroute configuration has taken effect. Line 8 in the LSP log for the LSP indicates that a fast reroute detour has been set up. The Record Route for the LSP shows that the LSP is routed through R3 (10.1.13.2) and R6 (10.1.36.2).
Looking at the RSVP session shows more information about the detour:
aviva@R1> show rsvp session ingress detail
Ingress RSVP: 1 sessions
10.0.0.5
From: 10.0.0.1, LSPstate: Up, ActiveRoute: 0
LSPname: R1-to-R5, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 100480
Resv style: 1 FF, Label in: -, Label out: 100480
Time left: -, Since: Mon Oct 10 13:15:17 2005
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 39233 protocol 0
FastReroute desired
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: 10.1.13.2 (so-0/0/2.0) 12 pkts
RESV rcvfrom: 10.1.13.2 (so-0/0/2.0) 9 pkts
Explct route: 10.1.13.2 10.1.36.2 10.1.56.1
Record route:
The record route shows the primary path of the LSP, from R1 out interface so-0/0/2, to R3, then to R5 and ending at R6 (10.1.56.1). The Detour Record route shows the detour path, from R1 out a different interface, so-0/0/0, to R2 (10.1.12.1), then to R4 (10.1.26.2), and finally to R6. This detour goes around R3, providing protection if the link between R1 and R3 fails or if R3 itself fails.
Next, look on the transit routers to make sure they are aware of the detour. First, look at Router R3, which is the first router in the primary path:
aviva@R3> show rsvp session transit detail
Transit RSVP: 1 sessions
10.0.0.5
From: 10.0.0.1, LSPstate: Up, ActiveRoute: 1
LSPname: R1-to-R5, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 100112
Resv style: 1 FF, Label in: 100480, Label out: 100112
Time left: 119, Since: Mon Oct 10 13:09:14 2005
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 39233 protocol 0
FastReroute desired
PATH rcvfrom: 10.1.13.1 (so-0/0/2.0) 18 pkts
Adspec: received MTU 1500 sent MTU 1500
PATH sentto: 10.1.36.2 (so-0/0/3.0) 15 pkts
RESV rcvfrom: 10.1.36.2 (so-0/0/3.0) 15 pkts
Explct route: 10.1.36.2 10.1.56.1
Record route: 10.1.13.1
Router R3s record route for the primary R1-to-R5 LSP shows:
Record route: 10.1.13.1
This matches the record route on the ingress router:
Record route:
The only difference here is that for R3,
Detour Record route: 10.1.13.1 This detour protects the downstream
link from R3, which is the connection to R5. If this link fails, the detour goes to R4 (10.1.34.2), then to R5, the egress router. The next transit router to check is R2, which is not in the primary LSP but is part of the protection LSP that R1 has set up if its link to R3 goes down:
aviva@R2> show rsvp session transit detail
Transit RSVP: 1 sessions
10.0.0.5
From: 10.0.0.1, LSPstate: Up, ActiveRoute: 1
LSPname: R1-to-R5, LSPpath: Primary
Suggested label received: -, Suggested label sent:
Recovery label received: -, Recovery label sent: 100464
Resv style: 1 FF, Label in: 100432, Label out: 100464
Time left: 158, Since: Wed Oct 12 15:24:45 2005
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 5 receiver 39275 protocol 0
Detour branch from 10.1.12.1, to skip 10.0.0.3, Up
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Adspec: received MTU 1500
Path MTU: received 0
PATH rcvfrom: 10.1.12.1 (so-0/0/0.0) 8 pkts
Adspec: received MTU 1500 sent MTU 1500
PATH sentto: 10.1.24.2 (so-0/0/3.0) 4 pkts
RESV rcvfrom: 10.1.24.2 (so-0/0/3.0) 4 pkts
Explct route: 10.1.24.2 10.1.45.2
Record route: 10.1.12.1
The first few lines of the output confirm that this is LSP R1-to-R5, from 10.0.0.1 to 10.0.0.5. The Detour branch line indicates that this router is a
fast-reroute detour that will be used if R3 (10.0.0.3) fails. What happens when the link on one of the transit routers goes down? When R3 goes down, R1 can no longer direct the primary LSP out the so-0/0/2 interface to R3:
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 2 100% 155.52Mbps 155.52Mbps 0bps 50Mbps
so-0/0/2.0 Down 0 100% 155.52Mbps 155.52Mbps 0bps 100Mbps
The RSVP interface status shows that the so-0/0/2
link is down and has no active RSVP sessions, and all RSVP sessions have been moved to so-0/0/0. Next, look at the LSP on the ingress router:
aviva@R1show 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)
FastReroute desired
LoadBalance: Random
Encoding type:
Packet, Switching type: Packet, GPID: IPv4
*Primary primary-path-R1-to-R5 State: Up
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30)
10.1.12.2 S 10.1.26.2 S 10.1.56.1 S
Received RRO (
ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
10.1.12.2(flag=9) 10.1.26.2(flag=1) 10.1.56.1
21 Oct 12 15:23:03 Record Route: 10.1.12.2(flag=9) 10.1.26.2(flag=1) 10.1.56.1
20 Oct 12 15:23:03 Record Route: 10.1.12.2(flag=9) 10.1.26.2 10.1.56.1
19 Oct 12 15:23:00 Record Route: 10.1.12.2 10.1.26.2 10.1.56.1
18 Oct 12 15:23:00 Up
17 Oct 12 15:23:00 Originate make-before-break call
16 Oct 12 15:23:00 CSPF: computation result accepted
15 Oct 12 15:23:00 CSPF: link down/deleted: 10.1.13.1(R1.00/10.0.0.1)->10.1.13.
2(R3.00/10.0.0.3)
14 Oct 12 15:23:00 Originate make-before-break call
13 Oct 12 15:23:00 CSPF: computation result accepted
12 Oct 12 15:23:00 Tunnel local repaired
11 Oct 12 15:23:00 Record Route: 10.1.12.2 10.1.26.2 10.1.56.1
10 Oct 12 15:23:00 Tunnel local repaired
9 Oct 12 15:23:00 Down
…
Total 1 displayed, Up 1, Down 0
Line 9 of the LSP log shows when the link broke and the primary LSP went down. Line 10 shows R1 repairing the LSP, and line 11 shows that R1 has switched to the
protection LSP, redirecting traffic out so-0/0/0 (10.1.12.2) to R2. In lines 13 and 14, CSPF verifies that the protection LSP is up before tearing down the primary LSP (shown in line 15). By line 18, the new LSP is fully up, and line 19 shows its path (record route) through R2 and then R4, and then to R5. Line 12 indicates that the ingress router received a
PathErr message with an indication that the LSP was locally repaired by the
fast reroute backup LSP. This message triggers a recomputation for the primary LSP itself, and line 13 reports that the computation succeeded. Line 14 shows that signaling has been initiated for the make-before-break path. (This path is not up yet.) Line 15 indicates that the IGP deleted the listed link shown in the TE database, which triggers another path recomputation (line 16) and the initiation of another make-before-break operation (line 17), which overrides the previous one that is not yet up. The LSP finally comes up in line 18, with the path (record route) through R2 and then R4, and then to R5, as shown in lines 19, 20, and 21. Lines 10 through 17 log the reoptimization of the LSP after
fast reroute kicks in. The times shown are when the operation was recorded by the ingress router. They are not indicative of how long it took to switch over from the primary LSP to the protection path. When the
link between R3 and R1 breaks, R3 is no longer participating in the LSP:
aviva@R3> show mpls lsp transit extensive
Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0
This output shows that R3 has no knowledge of being the transit router for any LSPs. Finally, check the transit router R2:
aviva@R2> show mpls lsp transit extensive
Transit LSP: 1 sessions
10.0.0.5
From: 10.0.0.1, LSPstate: Up, ActiveRoute: 1
LSPname: R1-to-R5, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 100320
Resv style: 1 FF, Label in: 100416, Label out: 100320
Time left: 158, Since: Wed Oct 12 15:12:01 2005
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 3 receiver 39275 protocol 0
FastReroute desired
PATH rcvfrom: 10.1.12.1 (so-0/0/0.0) 109 pkts
Adspec: received MTU 1500 sent MTU 1500
PATH sentto: 10.1.26.2 (so-0/0/2.0) 11 pkts
RESV rcvfrom: 10.1.26.2 (so-0/0/2.0) 10 pkts
Explct route: 10.1.26.2 10.1.56.1
Record route: 10.1.12.1
The Record route line confirms that the LSP has been detoured to R2 and that R2 is now the second hop in the R1-to-R5 LSP.
RFC 4090,
Fast Reroute Extensions to RSVP-TE for LSP TunnelsSee Also
Категории