Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Achieving a Make-Before-Break, Hitless Switchover for LSPs

 

Adaptive label-switched paths (LSPs) might need to establish a new LSP instance and transfer traffic from an old LSP instance onto the new LSP instance before tearing down the old one. This type of configuration is referred to as a make before break (MBB).

RSVP-TE is a protocol used to establish LSPs in MPLS networks. The Junos OS implementation of RSVP-TE to achieve a hitless (no traffic loss) MBB switchover has relied on configuring the timer values in the following configuration statements:

  • optimize-switchover-delay—Amount of time to wait before switching to the new LSP instance.

  • optimize-hold-dead-delay—Amount of time to wait after switchover and before deletion of the old LSP instance.

Both the optimize-switchover-delay and optimize-hold-dead-delay statements apply to all LSPs that use the make-before-break behavior for LSP setup and teardown, not just for LSPs for which the optimize-timer statement has also been configured. The following MPLS features cause LSPs to be set up and torn down using make-before-break behavior:

  • Adaptive LSPs

  • Automatic bandwidth allocation

  • BFD for LSPs

  • Graceful Routing Engine switchover

  • Link and node protection

  • Nonstop active routing

  • Optimized LSPs

  • Point-to-multipoint (P2MP) LSPs

  • Soft preemption

  • Standby secondary paths

Both the optimize-switchover-delay and optimize-hold-dead-delay statements when configured add an artificial delay to the MBB process. The value of the optimize-switchover-delay statement varies with the size of the Explicit Route Objects (EROs). An ERO is an extension to RSVP that allows an RSVP PATH message to traverse an explicit sequence of routers that is independent of conventional shortest-path IP routing. The value of the optimize-switchover-delay statement also depends on the CPU load on each of the routers on the path. Customers set the optimize-switchover-delay statement by trial and error.

The value of the optimize-hold-dead-delay statement depends on how fast the ingress router moves all application prefixes to point to the new LSP. This is determined by the Packet Forwarding Engine load, which can vary from platform to platform. Customers have to set the optimize-hold-dead-delay statement by trial and error.

However, as of Release 15.1, Junos OS is able to achieve a hitless MBB switchover without configuring the artificial delays that such timer values introduce.

This topic summarizes the three methods of achieving a MBB switchover from an old LSP to a new LSP using Junos OS:

Specifying the Amount of Time the Router Waits to Switch Over to New Paths

To specify the amount of time the router waits to switch over LSP instances to newly optimized paths, use the optimize-switchover-delay statement. You only need to configure this statement on routers acting as the ingress for the affected LSPs (you do not need to configure this statement on transit or egress routers). The timer in this statement helps to ensure that the new optimized paths have been established before traffic is switched over from the old paths. This timer can only by enabled or disabled for all of the LSPs configured on the router.

To configure the amount of time the router waits to switch over LSP instances to newly optimized paths, specify the time in seconds by using the optimize-switchover-delay statement:

You can include this statement at the following hierarchy levels:

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

Specifying the Amount of Time to Delay the Tear Down of Old Paths

To specify the amount of time to delay the tear down of old paths after the router has switched traffic to new optimized paths, use the optimize-hold-dead-delay statement. You only need to configure this statement on routers acting as the ingress for the affected LSPs (you do not need to configure this statement on transit or egress routers). The timer in this statement helps to ensure that old paths are not torn down before all routes have been switched over to the new optimized paths. This timer can be enabled for specific LSPs or for all of the LSPs configured on the router.

To configure the amount of time in seconds to delay the tear down of old paths after the router has switched traffic to new optimized paths, use the optimize-hold-dead-delay statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

Achieving a Hitless, MBB Switchover Without Artificial Delays

As of Junos OS Release 15.1, there is another way to relinquish the old LSP instances after MBB switchover without relying on the arbitrary time intervals set up by the optimize-switchover-delay or optimize-hold-dead-delay statement. For example, if you use the optimize-hold-dead-delay statement, you configure a time you think it is safe to wait before tearing down the old LSP instance after MBB. However, some routes might still be in the process of shifting to the new instance. Tearing down the old LSP instance prematurely results in one of the transit nodes dropping the traffic for those routes that have not shifted to the new LSP instance.

To avoid traffic loss, instead of using the optimize-switchover-delay statement, you can use MPLS-OAM (lsp ping), which confirms that the LSP data plane is established end-to-end. Instead of using the optimize-hold-dead-delay statement, you can use a feedback mechanism from the rpd infrastructure that confirms that all prefixes referring to the old LSP have been switched over. The feedback mechanism is sourced from the Tag library and relies on the routing protocol process (rpd) infrastructure to determine when all the routes using the old LSP instance have fully shifted to the new LSP instance after MBB switchover.

The feedback mechanism is always in place, and it is optional. Configure the optimize-adaptive-teardown statement to have the feedback mechanism used during MBB switchover. This feature is not supported for RSVP point-to-multipoint (P2MP) LSP instances. Global configuration of the optimize-adaptive-teardown statement only affects the point-to-point LSPs that are configured in the system.

You only need to configure the optimize-adaptive-teardown statement on routers acting as the ingress for the affected LSPs (you do not need to configure this statement on transit or egress routers). This feedback mechanism ensures that old paths are not torn down before all routes have been switched over to the new optimized paths. The global configuration of this configuration statement affects only the point-to-point LSPs that are configured in the system.

You can include this statement at the [edit protocols mpls] hierarchy level.