Path Computation for LSPs on an Overloaded Router
Setting the overload bit in a router running IS-IS causes it to appear overloaded and prevents it from being used for transit traffic. Any new MPLS LSPs, including RSVP-signaled or LDP-signaled LSPs, are re-reouted away from an overloaded router. In the case of RSVP, this behavior applies to both Constrained Shortest Path First (CSPF) and non-CSPF LSPs. However, this behavior does not apply to new or existing bypass LSPs. Bypass LSPs are recalculated only when a different event triggers a path recalculation. For example, if you set the smart optimize timer with the smart-optimize-timer statement, the bypass LSP is rerouted away from the overloaded router only after the specified time elapses. Otherwise, the bypass LSP continues to transit the overloaded router.
You cannot establish any new transit LSPs through an overloaded router. However, you can configure ingress and egress LSPs through an overloaded router.
When you set the overload bit on an IS-IS router, any new LSPs transiting through it are recomputed and re-routed away from it. However, existing CSPF LSPs remain active and are not torn down.
An example of when you might want to establish transit LSPs
through an overloaded router is illustrated in Figure 1, which shows an aggregation router
(Router A) dual-homed on two core routers (Router B and Router C). You want to include the aggregation router in the LSP mesh, but transit LSPs should not pass through it, because it is a less capable router with relatively low-bandwidth uplinks to the core. Certain failure and rerouting scenarios could make it impossible for the aggregation router to establish some of its LSPs. Consequently, you run the router in a steady state with the overload bit set, but you are still able to establish ingress and egress LSPs through it.