Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Configuring Hot Standby of Secondary Paths for LSPs

 

By default, secondary paths are set up only as needed. To have the system maintain a secondary path in a hot-standby state indefinitely, include the standby statement:

You can include this statement at the following hierarchy levels:

The hot-standby state is meaningful only on secondary paths. Maintaining a path in a hot-standby state enables swift cutover to the secondary path when downstream routers on the current active path indicate connectivity problems. Although it is possible to configure the standby statement at the [edit protocols mpls label-switched-path lsp-name primary path-name] hierarchy level, it has no effect on router behavior.

If you configure the standby statement at the following hierarchy levels, the hot-standby state is activated on all secondary paths configured beneath that hierarchy level:

  • [edit protocols mpls]

  • [edit protocols mpls label-switched-path lsp-name]

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

  • [edit logical-systems logical-system-name protocols mpls label-switched-path lsp-name]

The hot-standby state has two advantages:

  • It eliminates the call-setup delay during network topology changes. Call setup can suffer from significant delays when network failures trigger large numbers of LSP reroutes at the same time.

  • A cutover to the secondary path can be made before RSVP learns that an LSP is down. There can be significant delays between the time the first failure is detected by protocol machinery (which can be an interface down, a neighbor becoming unreachable, a route becoming unreachable, or a transient routing loop being detected) and the time an LSP actually fails (which requires a timeout of soft state information between adjacent RSVP routers). When topology failures occur, hot-standby secondary paths can usually achieve the smallest cutover delays with minimal disruptions to user traffic.

When the primary path is considered to be stable again, traffic is automatically switched from the standby secondary path back to the primary path. The switch is performed no faster than twice the retry-timer interval and only if the primary path exhibits stability throughout the entire switch interval.

The drawback of the hot-standby state is that more state information must be maintained by all the routers along the path, which requires overhead from each of the routers.

Note

When viewed with inet.3, the same LSP may appear to be shown twice as the active route (both primary and secondary), even though traffic actually is being forwarded over the primary path LSP only. This is normal output, and reflects only that the secondary standby path is available.