area from RT5. Therefore, RT5 must be Level
2-capable to form adjacencies with RT1. However, it has been
made a Level-1 router with the command is-type level-1.
Therefore, no IS-IS adjacency will be formed between RT1 and
RT5. The solution here would be to change the area on RT5 to
the proper area of 49.0001. Step 5: Checking for
misconfigured subnets
In recent releases of Cisco IOS
Software, particularly in 12.0S, 12.0T, and 12.0T release
trains, adjacencies will not be formed between two neighbors if
the directly connected interfaces are not in the same IP
subnet. In Figure , the IP address of RT1 is changed to that of
another subnet. In Figure , the output of debug isis
adj-packet shows RT1 is rejecting the hello received from
RT5 because the interface address 10.1.1.5 advertised by the
latter is not on subnet 10.1.8.0/24. In earlier Cisco IOS
Software releases, it did not matter whether the routers
belonged to the different IP subnets because IS-IS adjacency
formation occurs primarily within the CLNP framework, where IP
addresses are irrelevant. However, in IP applications, directly
connected routers must be on the same subnet, except when IP
unnumbered is used. Therefore, the recent behavior provides an
extra check for the IP configuration while introducing sanity
into IS-IS data structures for tracking IP information. In
summary, it is important to make sure that directly connected
routers that need to form IS-IS adjacencies for IP routing are
on the same IP subnet. Step 6: Check for duplicate systems
IDs
If the previous steps checked out okay, but a
specific neighbor is not in the show clns neighbor
output, it is possible that adjacency is not being formed
because that neighbor has a duplicate system ID with the local
router. An IS-IS router will not form an adjacency with a
router in the same area that has a duplicate system ID. It also
logs duplicate system ID errors. Use the show logging
command to display entries in the log. If duplicate system ID
errors are found, the source of the conflict can be determined
from the output of debug adj-packets. This points to the
interface where the hellos with the duplicate system ID are
coming from.
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.
Content 5.8
Troubleshooting IS-IS 5.8.4 ES-IS adjacency
instead of IS-IS adjacency formed Cisco routers running
IS-IS in IP environments still listen to ISHs,
intermediate-system hellos, generated by ES-IS protocol, in
conformance with ISO 10589 requirements. When the physical and
data-link layers are operational, an ES-IS adjacency can be
formed even if appropriate conditions do not exist for
establishing an IS-IS adjacency. Figure shows what the output
for the show clns neighbors command looks like when an
ES-IS adjacency is formed instead of an IS-IS adjacency. This
is usually because IS-IS hellos are not being processed, as a
result of interface MTU mismatch or misconfigured
authentication.
Content 5.8
Troubleshooting IS-IS 5.8.5 Route advertisement
problems Most route advertisement problems can be narrowed
down to configuration problems at the source or LSP propagation
issues. Because IS-IS is a link-state protocol, IS-IS routers
depend on LSP flooding to obtain topology and routing
information. During stable conditions, each IS-IS router in an
area will have the same Level 1 link-state database, which
contains the LSPs generated by every router in the area.
Dijkstra’s algorithm is run over the LS database to obtain the
best path to every advertised route. If a route is missing in a
section of the area, it is because the routers in that section
did not receive the original LSP, or the LSP was received
corrupted, therefore, was purged. An even simpler reason could
be that the route was not even put into the LSP at the source.
The outputs of debug isis update-packets and debug
isis snp-packets could help decipher this sort of problem
as it is related to LSP flooding or issues with link-state
database synchronization. The highlighted portion of the
debug isis update-packets command shows RT1 flooding its
LSP and also receiving an LSP from RT2. Because the adjacency
was brought up, the output also shows the one-time exchange of
CSNPs on point-to-point links between RT1 and RT2. The
highlighted portion of the debug isis snp-packets
command indicates receipt of CSNP by RT5 from the DIS (RT1). By
comparing the contents of the CSNP with the local Level 1
database, RT5 determines that no changes occurred in all known
LSPs. There can be many potential causes for problems in which
routes are not reaching remote locations in the network
including adjacency problems, Layer 1/2 problems, IS-IS
misconfiguration, and other issues.
Content
5.8 Troubleshooting IS-IS
5.8.6 Route flapping problem Route flaps normally
are caused by unstable links between the source of the route
and the location where the flap is being observed. Typically,
multiple routes are impacted at the same time because of an
adjacency change affecting many LSPs, all of which might carry
numerous IP prefixes. Also, route flaps could induce consistent
running of SPF process, causing dangerously high CPU
utilization on route processors that might crash affected
routers. If the advertised LSP changes affect only IP prefixes,
only partial route calculation (PRC) is run instead of full SPF
calculations. PRC is less costly in terms of CPU cycles than
full SPF runs. Apart from certain destinations not being
reachable, obviously implying routing problems, high CPU
utilization by the SPF process (show process cpu
command) certainly should flag instabilities in the network.
High CPU utilization can be observed through the IOS command
line interface, network management applications, or special
network-performance analysis tools, such as CiscoWorks. The
show process cpu command can obtain CPU utilization