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 suggests 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.