What Happens After Failure is Recovered By FRR?
If failure occurs at a router other than the Head-End, the PLR:
Switches the traffic to the protection tunnel
Sends a PATH ERR message back to Head-End with:
— Error Code: RSVP Notify Error
— Error Value: Tunnel Locally Repaired
The Head-End, notified of the failure, is also aware that the traffic
is protected by FRR.
The Primary LSP-Path remains up, with the FRR protection active
on the PLR.
This is independent of the protection method and type.
Establishing Fast Reroute protection tunnels and forwarding traffic over the protection tunnels after a failure has
occurred in the network has been discussed in this section so far.
The rest of the section focuses on the events that take place after Fast Reroute protection has been activated by a PLR
router, and the actions that are taken by the Head-End after being informed of this fact.
After detecting the failure and immediately recovering the traffic on the protection tunnel, the next priority of the PLR
router is to inform the Head-End of the new situation. It sends a PATH Error message in the form of an “RSVP Notify
Error”. The “Error Value” field indicates that the tunnel is locally repaired at the PLR router issuing the Error message.
This tells the Head-End router that traffic forwarding still continues on the primary LSP-Path; the sole difference is that
it is on an FRR protection tunnel, and not on the original path. As a result, the Head-End does not set the primary LSPPath
status to down, and keeps it operationally up and active. This is applicable to all the one-to-one/facility and
router/link protection cases.
If a standby secondary path exists, the Head-End, upon learning that a PLR has recovered the traffic, will move traffic
to the standby LSP, using MBB. If only a secondary exists, the traffic stays on the FRR path, unless the detour or bypass
tunnel fails.
There might be further actions that are taken by the LSP Head-End upon being informed of the FRR status. The
conditions and details of these actions are covered later in the section.
A Primary LSP-Path has been established on the shortest IGP path.
A link-protect FRR detour path is also available on router R2.
Traffic is running on the Primary path.
The case study above is used to illustrate the concepts related to the events and actions taken after an FRR protection
tunnel activation.
A primary LSP-Path is configured with no specific hops and CSPF enabled. No additional constraints are specified for the
LSP-Path. CSPF calculates the entire LSP-Path based on the link costs. The path R1-R2-R4-R6 is chosen and signaled.
Fast Reroute one-to-one is also requested for the LSP. Router R2 signals a link protection detour that goes over routers
R7 and R8. Note that routers R1 and R4 can also establish detours going over the lower plane of the topology, but only
the detour of router R2 is shown for the sake of simplicity.
No link failures exist at present, and traffic forwarding takes place on the original LSP-Path.
No comments:
Post a Comment