Content

| 5.8 |  | Troubleshooting IS-IS |
| 5.8.3 |  | Adjacency is stuck in INIT state |

The most common causes for an adjacency getting stuck in INIT state are mismatched interface MTU and authentication parameters. Figure shows two routers running IS-IS. The output from show clns neighbors shows what an adjacency would look like when stuck in INIT.

Steps and Possible Causes

Step 1: Checking authentication
If IS-IS authentication is configured, the first step in tackling this problem is to address potential issues in this area. The Cisco implementation allows authentication to be configured in three ways: at the domain, area, or interface levels. It is important to be sure that the appropriate method is properly configured and that the passwords used are consistent. The output of the debug isis adj-packets command indicates authentication problems.

Step 2: Checking for mismatched MTUs
If there are no authentication issues, the next possibility is mismatched MTUs. The show clns interface command can quickly verify the MTUs on the other side of the link. The output of debug isis adj-packets shows when the MTU is changed to produce a mismatch.

Step 3: Checking for Disabling of IS-IS Hello Padding
Cisco IOS Software releases starting with 12.0S and 12.0ST, allow hello padding to be disabled to reduce significant and unnecessary bandwidth consumption in some network environments. Hello padding is disabled with the assumption that the MTUs match.

This step suggest making sure that hello padding is configured consistently on either side. In general, only suppressing hello padding should not affect the adjacency, as long as the hellos sent out on the transmitting side are smaller than the MTU on the receiving side. Also, disabling hello padding does not disable verification of the maximum acceptable size of received hello packets. The debug isis adj-packets command can be used to troubleshoot these issues. The show clns interface command in Figure shows the status of hello padding on an interface.