Overload Bit
Load isis.cfg
Set the overload bit on routers R2, R3, and XR1:
On R2, set overload bit on startup, wait for BGP, and supress all external routes
On R3, set overload bit right now, and advertise all prefixes
On XR1, set overload bit on startup, wait for BGP, and suppress both inter-area and external routes
Answer
Explanation
The overload bit in ISIS is set in a router’s LSP. It can be displayed using show isis database. For example, verify that R3 is currently setting the OL bit in its LSP:
ATT/P/OL means Attached bit/Partition repair/Overload bit. Parition repair is not implemented in any modern ISIS implementation. The attached bit is used in a L1 LSP to signal that the router is attached to the L2 backbone.
The original purpose of the OL bit was for an ISIS router to indicate that it has run out of memory, and that its LSDB might be out of sync. Therefore, other routers should not use this router as transit in their paths. Note that when the OL bit is set, the router is never used for transit, even if no other paths exist. The node can still be used to reach leaf prefixes advertised directly from the node itself, such as its own loopback.
The OL bit has been re-purposed to be used as a sort of BGP sync mechanism. You can have the router set the OL bit upon startup and clear it when BGP has come up. This allows you to ensure that the router won’t blackhole traffic that is forwarded in the global table via iBGP.
You can also set the OL bit at any time as a way to take a router out of service. When other routers see the OL bit set, they know not to use that router as transit.
The OSPF equivalent of this feature is the max-metric command. The router can set its interfaces in the Router LSA to maximum metric to discourage use of itself as transit. This is essentially how LDP sync works. The big difference is that with ISIS, when using the OL bit, the metric of links within the LSP is not actually manipulated. Additionally, in OSPF, the router can still be used for transit if no other paths exist, while this is not the case for the ISIS node with OL bit set.
On IOS-XE, you can control what to advertise when the OL bit is set using suppress [external|interlevel|prefixes]. The prefixes keyword means to not advertise any prefixes. On IOS-XR, the logic is reversed. By default, interlevel and external prefixes are suppressed, and you can advertise them using the advertise keyword.
Verification
R2 should no longer have ECMP routes to XR1. It should only be using R4 for transit. It will only use R3 for traffic R3 itself is advertising - its loopback and connected routes.
Note that the OL bit does not set R3’s metrics to max, as it works in OSPF. Instead, the OL means “don’t use me for transit.” The OL bit does not impact the actual link metrics. Also note that even if no other paths exist, a node with the OL bit set will never be used for transit.
Neither R2 or XR1 have set the OL bit yet. They will on startup, and they will clear the bit once BGP sessions come up.
I tried to verify that XRv1 will wait for BGP, but it doesn’t seem to work. Instead, simply doing on-startup seconds does work. The XRv will set OL=1 upon bootup, and will wait the specified amount of time before clearing the OL bit.
Last updated
