ISIS Overload timeout – Testing the timeout knob
1. Intro
First of all, lets quickly review the what the official documentation is saying about the ISIS overload timeout knob:
You configure or disable overload mode in IS-IS with or without a timeout. Without a timeout, overload mode is set until it is explicitly deleted from the configuration. With a timeout, overload mode is set if the time elapsed since the IS-IS instance started is less than the specified timeout.
A timer is started for the difference between the timeout and the time elapsed since the instance started. If the time elapsed after the IS-IS instance is enabled is less than the specified timeout, overload mode is set. When the timer expires, overload mode is cleared. In overload mode, the routing device IS-IS advertisements are originated with the overload bit set. This causes the transit traffic to take paths around the routing device. However, the overloaded routing device’s own links are still accessible.
To understand the scenario for setting the overload bit, consider that BGP converges slowly. It is not very good at detecting that a neighbor is down because it has slow-paced keepalive timers. Once the BGP neighbor is determined to be down, it can take up to 2 minutes for a BGP router to declare the neighbor down. IS-IS is much quicker. IS-IS only takes 10-30 seconds to detect absent peers. It is the slowness of BGP that necessitates the use of the overload bit. IS-IS and BGP routing are mutually dependent on each other. If both do not converge at the same time, traffic is dropped without notification (black holed).
So, you might want to configure the routing device so that it appears to be overloaded when you are restarting routing on the device. Setting the overload bit for a fixed amount of time right after a restart of the routing protocol process (rpd) ensures that the router does not receive transit traffic while the routing protocols (especially BGP) are still converging.
For our practical example, we will continue from our previous post ‘ISIS Overload – Learn with a practical example‘, so this is currently the state of the network:
R3 output:
### We can see that R2 and R3 have the overload bit set:
root@r3> show isis database
IS-IS level 1 link-state database:
0 LSPs
IS-IS level 2 link-state database:
LSP ID Sequence Checksum Lifetime Attributes
r1.00-00 0x25 0xce72 625 L1 L2
r3.00-00 0x26 0x8890 610 L1 L2 Overload
r4.00-00 0x25 0x42c0 665 L1 L2
r5.00-00 0x25 0x625d 682 L1 L2
r2.00-00 0x25 0xaf5f 632 L1 L2 Overload
5 LSPsR1 output:
### Because both R2 and R3 have overload configured, there is no route to R4:
root@r1> show route 17.0.0.0/24
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
17.0.0.1/32 *[Direct/0] 06:47:53
> via lo0.0
17.0.0.2/32 *[IS-IS/18] 06:47:38, metric 1000
> to 17.8.0.2 via ge-0/0/1.0
17.0.0.3/32 *[IS-IS/18] 00:12:12, metric 10
> to 17.8.1.2 via ge-0/0/2.02. Configure the ISIS Overload timeout
We will configure the timeout knob on the R3 router and we will see the impact.
R3 output:
[edit]
root@r3# set protocols isis overload timeout 300
[edit]
root@r3# show | compare
[edit protocols isis overload]
+ timeout 300;
[edit]
root@r3# commit
commit complete
### Now the overload bit is no longer set on R3 :
[edit]
root@r3# run show isis database
IS-IS level 1 link-state database:
0 LSPs
IS-IS level 2 link-state database:
LSP ID Sequence Checksum Lifetime Attributes
r1.00-00 0x28 0xc875 630 L1 L2
r3.00-00 0x2a 0xba5e 1194 L1 L2
r4.00-00 0x28 0x3cc3 504 L1 L2
r5.00-00 0x28 0x5c60 536 L1 L2
r2.00-00 0x28 0xa962 566 L1 L2 Overload
5 LSPsR1 output:
### Now we have routes to R4 and R5 :
root@r1> show route 17.0.0.0/24
inet.0: 24 destinations, 24 routes (24 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
17.0.0.1/32 *[Direct/0] 07:24:34
> via lo0.0
17.0.0.2/32 *[IS-IS/18] 07:24:19, metric 1000
> to 17.8.0.2 via ge-0/0/1.0
17.0.0.3/32 *[IS-IS/18] 00:48:53, metric 10
> to 17.8.1.2 via ge-0/0/2.0
17.0.0.4/32 *[IS-IS/18] 00:00:10, metric 20
> to 17.8.1.2 via ge-0/0/2.0
17.0.0.5/32 *[IS-IS/18] 00:00:10, metric 20
> to 17.8.1.2 via ge-0/0/2.0This is can be a little contra intuitive, but actually it makes sense if you think about it. Let’s read again the documentation:
“A timer is started for the difference between the timeout and the time elapsed since the instance started. If the time elapsed after the IS-IS instance is enabled is less than the specified timeout, overload mode is set.”
Because more than 300 seconds have passed since the ISIS instance has started, the overload bit is cleared as we already saw in the CLI output.
3. Restart the ISIS process
Lets now try restarting the ISIS process and see the impact.
R3 output
### Restart the entire rpd process to force an ISIS to restart:
root@r3> restart routing
Routing protocols process signalled but still running, waiting 28 seconds more
Routing protocols process started, pid 51156
### ISIS restarting and now is working to reestablish the all adjacencies:
root@r3> show isis adjacency
Interface System L State Hold (secs) SNPA
ge-0/0/1.0 r1 2 New 20
ge-0/0/2.0 0100.4923.9202 2 New 25
ge-0/0/3.0 r5 2 Up 24
### ISIS process now fully operational, all adjacencies are UP:
root@r3> show isis adjacency
Interface System L State Hold (secs) SNPA
ge-0/0/1.0 r1 2 Up 23
ge-0/0/2.0 r4 2 Up 20
ge-0/0/3.0 r5 2 Up 20
### Very important, now the Overload bit is set for R3:
root@r3> show isis database
IS-IS level 1 link-state database:
0 LSPs
IS-IS level 2 link-state database:
LSP ID Sequence Checksum Lifetime Attributes
r3.00-00 0x4 0xabcc 1028 L1 L2 Overload
r1.00-00 0x2b 0xc6b1 1026 L1 L2
0100.4923.9153.00-00 0x2b 0xb85f 903 L1 L2
r4.00-00 0x2b 0x3aff 1024 L1 L2
r5.00-00 0x2c 0xd91c 1000 L1 L2
r2.00-00 0x2a 0xa564 986 L1 L2 Overload
6 LSPs
### After 300 seconds, now the Overload bit is cleared for R3:
root@r3> show isis database
IS-IS level 1 link-state database:
0 LSPs
IS-IS level 2 link-state database:
LSP ID Sequence Checksum Lifetime Attributes
r3.00-00 0x5 0x84f6 1110 L1 L2
r1.00-00 0x2b 0xc6b1 848 L1 L2
0100.4923.9153.00-00 0x2b 0xb85f 725 L1 L2
r4.00-00 0x2b 0x3aff 846 L1 L2
r5.00-00 0x2c 0xd91c 822 L1 L2
r2.00-00 0x2a 0xa564 808 L1 L2 OverloadR1 output:
### Lets observe the network impact from the R1 perspective.
### While the ISIS process is restarting on R3, for a brief moment some prefixes are missing on R1.
### We are missing routes to R3, and as result, there is no more path to R4 or R5 either:
root@r1> show route 17.0.0.0/24
inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
17.0.0.1/32 *[Direct/0] 07:39:06
> via lo0.0
17.0.0.2/32 *[IS-IS/18] 07:38:51, metric 1000
> to 17.8.0.2 via ge-0/0/1.0
### Once ISIS process is running again on R3 (with all adjacencies UP), now R1 has a route to R3.
### Notice there is no path to R4 or R5 because the ISIS Overload timeout is set for 300 seconds:
root@r1> show route 17.0.0.0/24
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
17.0.0.1/32 *[Direct/0] 07:39:14
> via lo0.0
17.0.0.2/32 *[IS-IS/18] 07:38:59, metric 1000
> to 17.8.0.2 via ge-0/0/1.0
17.0.0.3/32 *[IS-IS/18] 00:00:07, metric 10
> to 17.8.1.2 via ge-0/0/2.0
### After 300 seconds (ISIS overload timeout on R3), now we have again routes to R4 and R5.
root@r1> show route 17.0.0.0/24
inet.0: 24 destinations, 24 routes (24 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
17.0.0.1/32 *[Direct/0] 07:45:38
> via lo0.0
17.0.0.2/32 *[IS-IS/18] 07:45:23, metric 1000
> to 17.8.0.2 via ge-0/0/1.0
17.0.0.3/32 *[IS-IS/18] 00:06:31, metric 10
> to 17.8.1.2 via ge-0/0/2.0
17.0.0.4/32 *[IS-IS/18] 00:02:11, metric 20
> to 17.8.1.2 via ge-0/0/2.0
17.0.0.5/32 *[IS-IS/18] 00:02:11, metric 20
> to 17.8.1.2 via ge-0/0/2.0
To conclude, the ISIS overload timeout is set after ISIS process is started, but not during normal operations.