Discussion

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@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.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 makebefore-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.
Using Fast Reroute to Reduce Packet Loss Following a Link Failure | 533
This is the Title of the Book, eMatter Edition
Copyright © 2008 O’Reilly & Associates, Inc. All rights reserved.