Routing

Hi,

The Juniper Day One book, Deploying MPLS, the book describes that Link protection provides protection against a link failure along an RSVP label-switched path. When link protection is configured.

I followed the book's topology diagram to do a lab test. I don't see bypass-lsp up when a link failure along an RSVP label-switched path.

I am not able to understand,

1. The label-switched path is set by ERO strict path, if there is a link failure along an RSVP label-switched path, the LSP should be torn down. How does the link-protection protect the LSP?

2. If the label-switched path has a ERO strict secondary path. There is a link failure along an RSVP label-switched primary path, the path will be switched to secondary path. How does the link-protection do its function to protect primary path?

Thanks.

Ernest Lin

Hi,

Any experts please help explain this.

Thanks.

Ernest Lin

Hi ernestlin,

During a link failure in the primary LSP ,

Point-of-Local-Repair (PLR) will detetct the failure and it will immediately reroute the data traffic onto the bypass tunnel and also start to send the control traffic for the protected LSP onto the bypass tunnel.

Therefore, the protected LSP will stay in UP state, eventhough the strict ERO is not statisfied during a link failure.

In general, the path used via the bypass will not be an optimum path.

The purpose of local repair is to keep high priority  and loss-sensitive traffic flowing while a more optimal re-routing of  the tunnel can be effected by the head-end of the tunnel.  Thus, the  head-end has to know of the failure so that it may re-signal an optimal LSP. Therefore PLR will signal the headend via RSVP Path Error message about the failure.  Also, the headend will detect the failure via IGP as well.

So, Headend will start to recalculate a possible alternate path or signal the secondary LSP. Once this LSP is setup, the headend will switch-over the traffic to the secondary LSP and signal other LSRs to tear down the protected LSP.

These RSVP signalling mechanisms are explained in the RFC 4090 (Fast Reroute Extensions to RSVP-TE for LSP Tunnels).

The following document calrifies the Link/Node protection configured with Secondary path.

http://www.juniper.net/techpubs/en_US/junos9.5/information-products/topic-collections/config-guide-mpls-applications/id-23830.html

When standby secondary path, and fast reroute or link protection are configured on an LSP, full traffic protection is enabled. When a failure occurs in an LSP, the router upstream from the failure routes traffic around the failure and notifies the ingress router of the failure. This rerouting keeps the traffic flowing while waiting for the notification to be processed at the ingress router. After receiving the failure notification, the ingress router immediately reroutes the traffic from the patched primary path to the more optimal standby path.

So, Link/Node protection is an immediate patch work for the failure and the traffic will be handed-over to secondary path once it is available. ( If the Headend router unabale to calculate the secondary path, the traffic will flow through the bypass tunnel )

 Hope this helps.

Regards

Moses N

-------------------------------------------------------

If this post answers your question, please mark it as "Accepted Solution".
Kudos are a nice way of expressing your gratitude

The purpose of local repair is to keep high priority  and loss-sensitive traffic flowing while a more optimal re-routing of  the tunnel can be effected by the head-end of the tunnel.  Thus, the  head-end has to know of the failure so that it may re-signal an optimal LSP. Therefore PLR will signal the headend via RSVP Path Error message about the failure.  Also, the headend will detect the failure via IGP as well.

================================================================================================

i think should re-signal to the ingress router with path tier not path error

i think should re-signal to the ingress router with reservation tier not path error

kindly ignore the above comment