Intermediate System to Intermediate System (IS-IS) is a link-state Interior Gateway Protocol (IGP) used for routing within an administrative domain or network. It operates by reliably flooding link-state information throughout a network of routers, allowing each router to independently build a database of the network's topology and calculate the best path to destinations using Dijkstra's algorithm.
Common issues with IS-IS protocol include:
Synchronization Problems: Disruptions in the exchange of routing information between Level 1 (L1) and Level 2 (L2) routers.
Routing Loops: Occurrences where packets circulate endlessly within the network
Adjacency Failures: Routers failing to form neighbor adjacencies, often due to mismatched IS-IS levels or configuration errors
Incorrect Routing Information: Routers having outdated or incorrect topology information, leading to suboptimal routing decisions
Triaging ISIS adjacency bringup issues:
Sometimes an adjacency bringup issue is seeen reported without making sure the follwoing minimum required configuration.
Please use the following commands to verify if the above minimum configuration are present or not.
Please refer to Minimum ISIS configuration for official documentation.
This is typically seen due to lack of proper data connectivity of between the routers on the adjacency forming link. Due to such forwarding problems ISIS IIH PDUs sent by one routers do not even reach the remote router. Please run ping from both the routers on either sides of the link to ensure proper data connectivity over the link. If basic ping does not work please investigate further the data connectivity issue with the platform-specific PFE(forwarding) team.
Sometimes even after normal ping reachability, adjacencies are not formed due to MTU mismatch. If the length of the IIH PDU received and the MTU configured on the interface does NOT match, IIH PDUs are dropped. In cases of tunneled/virtua interfaces where there is some encapsulation (e.g. GRE), there is a chance that the interface MTU and the real available MTU differs, or may even go below the minimum PDU size of 1492 for ISIS IIH PDUs. Please run ping with mtu size 1492 to rule out such MTU issues with underlying links. Refer to ISIS on GRE interfaces for more information.
An adjacency can be stuck in INIT state when a router finds a neighbor's IIH PDUs not including it in the set of IS-REACH TLVs. Most likely the neighbor would have found out some problem in current router's IIH PDUs but the neighbor's IIH PDUs are found to be valid on this router.
Another reason maybe a unidirectional forwarding issue in the underlying transport, because of which one router may see another's IIH, but the other is not able to receive this router's IIH PDUs. To check such issues collect the show isis statistics commands on regular basis on both routers.
root@MX-1# run show isis statistics IS-IS statistics for MX-1: PDU type Received Processed Drops Sent Rexmit LSP 419 419 0 298 153 IIH 24832 23 0 49597 0 CSNP 39098 39098 0 39098 0 PSNP 434 434 0 404 0 Unknown 0 0 0 0 0 Totals 64783 39974 0 89397 153 Total packets received: 64783 Sent: 89550 SNP queue length: 0 Drops: 0 LSP queue length: 0 Drops: 0 SPF runs: 600 Fragments rebuilt: 317 LSP regenerations: 245 Purges initiated: 0
Collecting the packet capture at both sides of the adjacency using "run monitor traffic interface <ifl>" will confirm if packets are received in RE or not. If it is confirmed a engineer from the underlying transport platform team should triage further.
This is the most filed case under this category. Investigation in past has revealed that such observation can be attributed to one of the following reason(s).
1. Graceful Restart is NOT configured on the DUT For zero traffic loss with GRES, chasis redundancy needs to be configured. Following configuration enables it. root@MX> show configuration chassis redundancy graceful-switchover; {master} root@MX> If not configured use 'set chassis redundancy graceful-switchover' to configure the same. The above configuration by itself is not enough. Graceful Restart(GR) mechanisms need to be enabled for routing protocols to prevent them from flapping the existing adjacencies on switchover. Following configuration enables it. root@MX> show configuration routing-options graceful-restart; ... {master} root@MX> If not configured use 'set routing-options graceful-restart' to configure the same. 2. ISIS configured on LAN adjancencies with default hello and hold-time intervals Sometimes, inspite of ensuring that chassis redundancy and protocol GR mechanisms are enabled, it has been seen that ISIS adjacencies on new master RE has flapped causing momentary deletion of routes and hence a brief duration of traffic drop. This happens only on LAN adjcencies, mostly due to scaling down of hello and holdtime intervals on LAN adjacencies. Please refer to the Known-Facts section for more details.
1. Graceful Restart is NOT configured on the DUT
For zero traffic loss with GRES, chasis redundancy needs to be configured. Following configuration enables it.
root@MX> show configuration chassis redundancy graceful-switchover; {master} root@MX>
If not configured use 'set chassis redundancy graceful-switchover' to configure the same.
The above configuration by itself is not enough. Graceful Restart(GR) mechanisms need to be enabled for routing protocols to prevent them from flapping the existing adjacencies on switchover. Following configuration enables it.
root@MX> show configuration routing-options graceful-restart; ... {master} root@MX>
If not configured use 'set routing-options graceful-restart' to configure the same.
2. ISIS configured on LAN adjancencies with default hello and hold-time intervals
Sometimes, inspite of ensuring that chassis redundancy and protocol GR mechanisms are enabled, it has been seen that ISIS adjacencies on new master RE has flapped causing momentary deletion of routes and hence a brief duration of traffic drop.
This happens only on LAN adjcencies, mostly due to scaling down of hello and holdtime intervals on LAN adjacencies. Please refer to the Known-Facts section for more details.
When elected as a DIS on any LAN adjacency, the hello and hold-timer intervals are scaled down by factor of 3. This means the default values of 9 and 27 seconds of ISIS hello and holdtime intervals are scaled down to 3 and 9 seconds for LAN adjacencies.
In cases of switchover with such default or even more agressive(lower) time interval values, there is a good chance that the first hello from the new master RE, post-switchover will reach well after the holdtime expiry on the peer router. ISIS on new master will be start sending out hellos soon after switchover. However the packet transmit-path for the same packets may take sometime to be ready and Hello packets initiated for transmitted will be &dropped in transit till then*. Since the peer will not get any hello within the next holdtime interval, it will bring down the ISIS adjacency with the DUT router, and cause traffic drops.
To take care of this issue and to ensure the zero traffic loss, one of the following approach can be taken.
Due to the 8-bit size of psuedonode-id field, ISIS protocol itself can support upto 254 LAN interfaces on any router. If there is a need for scaling beyond 254 interfaces, all the interfaces should be configured as point-to-point under ISIS config as follows.
protocols isis interface all {point-to-point;...}
4/25/2025: KB created.