Routing

 View Only

IMPORTANT MODERATION NOTICE

This community is currently under full moderation, meaning  all posts will be reviewed before appearing in the community. Please expect a brief delay—there is no need to post multiple times. If your post is rejected, you'll receive an email outlining the reason(s). We've implemented full moderation to control spam. Thank you for your patience and participation.



  • 1.  Is link-protection available when the label-switched path is down?

    Posted 09-14-2012 10:44

    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



  • 2.  RE: Is link-protection available when the label-switched path is down?

    Posted 09-19-2012 09:24

    Hi,

    Any experts please help explain this.

     

    Thanks.

    Ernest Lin



  • 3.  RE: Is link-protection available when the label-switched path is down?
    Best Answer

    Posted 09-19-2012 19:43

    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



  • 4.  RE: Is link-protection available when the label-switched path is down?

    Posted 07-19-2019 05:42

    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



  • 5.  RE: Is link-protection available when the label-switched path is down?

    Posted 07-19-2019 17:02

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

     

    kindly ignore the above comment 



  • 6.  RE: Is link-protection available when the label-switched path is down?

    Posted 01-18-2022 12:54
    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
    ------------------------------