Symptom/Cause | Solution |
|---|---|
Expected adjacencies not formed or not seen in the output of show clns neighbors The interfaces might have been administratively shut down The IS-IS configurations are incorrect. The levels configured on the interfaces might be mismatching The IP subnet configured is incorrect. Duplicate system ID is configured in IS-IS area. | Check for link failures. We can verify whether all the interfaces on which IS-IS adjacency is enabled are in UP state. This can be confirmed by checking the output of sh ip interface brief command. Once the state of the interface is verified to be in UP state, do a ping to the other end and check the connectivity is proper. If the ping fails, that means the physical connectivity problem exits, which should be resolved before going further. If the link is fine, check the IS-IS configurations. IS-IS is enabled in two steps, first is creating isis process as shown below: router isis net 49.0010.0000.0001.00 A misconfigured NET command could also lead to IS-IS adjacency problem. Next step is to attach this process to the appropriate interfaces with command ip router isis. By default, IS-IS router processes have Level 1-2 capability. We can configure IS-IS routers to be level-1 only or level-2 only by using the is-type command. If the levels are mismatching between two directly connected routers adjacency is not formed. By correcting the levels the adjacency issue can be resolved. If the directly connected routers are not present in the same IP subnet, adjacencies are not formed. In this case, the hellos received will be rejected as the interface addresses are not in same subnet. Hence make sure that the interfaces are configured in the same IP subnet. The system ID configured is unique throughout the network. If same system ID is configured for any two IS-IS routers adjacency will not be established. By enabling debug logs we can find the interface which is sending hellos with duplicate system ID. Hence make sure that system IDs are different across the network. |
The adjacency state of some or all neighbors is struck in INIT state in show clns neighbors Authentication problems. The MTU (Maximum Transmission Unit) mismatch has occurred. | If IS-IS authentication is enabled, first resolve this issue. If IS-IS authentication is not enabled, the problem might be with mismatched MTUs. First verify the authentication configurations on the routers. Make sure that proper authentication method is configured and the passwords are consistent. Sometimes, authentication may be enabled on only one side in which case the other side will not be able to process the hellos and hence the neighbor state will be stuck in INIT state. If the authentication problem is resolved and still the neighbor state is stuck in INIT, the possible cause will be because of mismatched MTU. The show isis interface command displays the MTU size of the link. You can also enable debug logs and check the MTU of the packets being sent on the interfaces. |
Symptom/Cause | Solution |
|---|---|
Route advertisement | Most route advertisement problems are caused because of incorrect configurations. If some routes are missing, use the show commands mentioned above to find more information about topology and LSPs. Using the knowledge about topology you can narrow down the problem to a single router. As IS-IS is a link-state protocol, the routers depend on LSPs to learn the topology and routing information. If a route is missing, it might be because the routers did not receive the original LSP or the LSP was received corrupted and hence was purged. In such cases, enabling debug logs for LSPs will help to determine the problem. |
Route flaps | Route flaps occur because of unstable links between the routers. As the links flap between UP and DOWN state, they induce SPF calculation resulting in high CPU utilization which might lead to crashes show clns neighbors detail Route flaps can be identified by checking the Uptime for the neighbor: In these cases physical connectivity should be stabilized to resolve the problem. In more complicated cases, the flapping might happen because of corrupted LSP storms or a routing loop. In such cases enabling debug logs for spf calculation helps to know which LSPs are changing more frequently and triggering SPF calculations. Care should be taken while enabling logs for these cases as CPU will be already overloaded. |
Route redistribution | IS-IS allows external routes like static, connected, or routes from other protocols to be distributed into IS-IS levels. The main reasons for external routes missing in routing table could be because of the wrong configuration. The source of the route may not be active in which case the external route will not be installed in the routing table. show ip route Verify that the source of the route is active. In case of static routes, the nexthop might not be reachable as the interface is down and hence it is not present in the routing table. show ip interface brief Check the interface state. External routes might be filtered in the route-map or distribute-list at the source, in which case it is the correct behavior to not install the route in the routing table. |