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 

I have a question about LSP.

So, we are configured the Dynamic LSP, but, if we have a link fail in the middle path, this LSP down and fastly stay up. We use a FRR in all devices, but even though this LSP have a FLAP.

This one secod that stay down, my l2vpn also stay down.
Ex:
Jan 18 11:23:26 : RPD_MPLS_PATH_DOWN: MPLS path down on LSP PE1-TO-PE2
Jan 18 11:23:27 : RPD_MPLS_PATH_UP: MPLS path up on LSP PE1-TO-PE2 path

L2VPN:
Jan 18 11:23:26 : RPD_LAYER2_VC_DOWN: State of Layer 2 VC (VPN : L2VPN-22222, local-site : 1, remote-site : 2) changed from UP to DELETED
Jan 18 11:23:27 : RPD_LAYER2_VC_UP: State of Layer 2 VC (VPN : L2VPN-22222, local-site : 1, remote-site : 2) changed to UP

695238 Jan 18 11:23:27.214 Record Route
695237 Jan 18 11:23:26.763 Originate Call
695236 Jan 18 11:23:26.763 Clear Call
695235 Jan 18 11:23:26.763 CSPF: computation result accepted >>>> cspf changed the route
695234 Jan 18 11:23:26.758 CSPF: link down/deleted: >>>> deleted fault link
695233 Jan 18 11:23:26.703 Deselected as active
695232 Jan 18 11:23:26.687 ResvTear received

This time down is normal? i knwo that is very short but my client of vpn 2222 stay down for a one second.



------------------------------
Raphael Soares
------------------------------

Original Message:
Sent: 09-19-2012 19:43
From: Moses Nagarajah
Subject: Is link-protection available when the label-switched path is down?

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