particular LSA is flapping is to turn on debug
ip ospf monitor. This debug command in Figure shows
that a router LSA is flapping in area 0. The next step is to
determine which router LSA is flapping and check the log for
any interface flap. The show log command in Figure shows
the log of the router with router ID 192.168.1.129, the ID
displayed in the output of the debug ip ospf monitor
command. The log shows that a serial link keeps going up and
down. Whenever there is an interface flap, it causes SPF to
run. Solution
There are two solution to this
problem: - Fix the link that is flapping.
- Redefine the area boundaries.
Sometimes, the
first solution might not be manageable because the link is
flapping as the result of a telco outage that is outside the
network boundary. One way to fix this temporarily is to
manually shut down the interface. The second solution requires
some redesigning. If the link flap is happening too often, it
might be possible to redefine the area, exclude this router
from the area, and make it a member of a totally stubby area.
Sometimes, this is also difficult to implement, depending upon
the physical location of this link. In short, link flaps are
realities; if there are too many link flaps, the number of
routers in an area should be decreased so that fewer routers
are affected.
Content 5.8
Troubleshooting IS-IS 5.8.1 IS-IS adjacency
problems IS-IS adjacency-related problems normally are
caused by link failures and configuration errors. On Cisco
routers, inspecting the output of the show interface
command can easily identify link failures. Also, because IS-IS
routing is not required to establish IP connectivity to
directly attached routers, it is easy to discern whether the
problem is media-related or specific to the IS-IS
configuration. The show clns neighbors command is
usually the starting point for troubleshooting IS-IS adjacency
problems. The output of this command should list all neighbors
expected to be adjacent to the router being investigated. The
command show clns is-neighbors provides similar output,
but it is intended to list only neighbor routers or IS-IS
adjacencies; whereas show clns neighbors lists all types
of adjacencies, both for IS-IS and ES-IS. Using the output from
the show clns neighbor and show clns neighbor
detail commands, IS-IS adjacencies can be examined.
Problems with IS-IS adjacency formation can be registered by
the presence of fewer neighbors than expected or a situation in
which the status of an expected adjacency is not up. Another
symptom could be that the neighbor is known through ES-IS
protocol instead of IS-IS. The router RT1 has properly formed
adjacencies with its directly connected neighbors, RT2 and RT5.
All ISO devices run the ES-IS protocol to facilitate mutual
discovery and communication between end systems and routers in
the CLNS environment. End systems and routers exchange
end-system hellos (ESHs) and intermediate-system hellos (ISHs)
within the ES-IS framework. Connected routers also receive each
other’s ISHs and form ES-IS adjacencies. Therefore, it is
possible that ES-IS adjacencies might still be formed between
two routers even if there are problems with the IS-IS
adjacency. Figure also shows output from show clns
neighbors, but shows problems with the adjacencies formed
with RT2 and RT5. In this example, the IS-IS adjacency with RT2
is in INIT state instead of UP. The protocol is correctly shown
as IS-IS. The adjacency with RT5 shows UP, however the protocol
is ES-IS instead of IS-IS. As explained previously, the ES-IS
protocol runs independently of IS-IS; therefore, the ES-IS
adjacency formed between RT1 and RT5 has nothing to do with
IS-IS. These routers cannot form an IS-IS adjacency with each
other, apparently because of a problem in the configuration or
the IS-IS environment. Most adjacency problems related to the
IS-IS environment can be debugged with the debug isis
adj-packets command. The output of this command can be
daunting if the router under inspection has a lot of neighbors
because the display shows all the hellos transmitted and
received by the local routers.
Content
5.8 Troubleshooting IS-IS
5.8.2 Some or all of the adjacencies are not coming
up The absence of some expected IS-IS adjacencies means
that the affected routers will not be capable of exchanging
routing information, effectively creating reachability problems
to certain destinations in the network. Figure shows a simple
network in which four daisy-chained routers are grouped in twos
and placed in separate areas. Figure and display different
outputs of the show clns neighbors command captured on
RT1. Figure displays two neighbors, while Figure displays only
one neighbor instead of the expected two. RT2 is listed, but
RT5 is missing. Steps and Possible Causes Step 1:
Checking for link failures
The first step is to check
for link failures. On Cisco routers this can be done using the
show ip interface brief command. If there is a problem,
the appropriate interfaces will display something other than
the up/up state. Shown is an example if there is a link failure
problem. The solution here would be to correct the Layer 1/2
problem. Step 2: Checking for configuration errors
If the link is fine, the next step would be to verify the
IS-IS configuration. Make sure the IS-IS process is defined and
that an NSAP and NET is configured. Unlike other IP routing
protocols, the IS-IS configuration does not use network
statements to enable IS-IS routing on the router interfaces. To
enable IS-IS routing for IP on a Cisco router, the ip
router isis command must be configured on the appropriate
interfaces. Make sure the router-level
passive-interface command is not being used to disable
IS-IS routing on these interfaces. When an interface is made
passive, the ip router isis command is automatically
removed from the interface. Step 3: Checking for mismatched
Level 1 and Level 2 interfaces
If the configuration
looks correct, the next step is to check for mismatched Level 1
and Level 2 interfaces. IS-IS supports a two-level routing
hierarchy in which routing within an area is designated as
Level 1 and routing between areas in designated as Level 2. An
IS-IS router can be configured to participate in Level 1
routing only (Level 1 router), Level 2 routing only (Level 2
router) or both (Level 1-2 router). Level 1-2 routers act as
border routers between IS-IS areas and facilitate interarea
communication. In the default mode of operation, Cisco routers
have Level 1-2 capability. Two directly connected routers with
a common area ID will form a Level 1-2 adjacency by default,
even though only a Level 1 adjacency is necessary for them to
communicate. Use the router-level is-type command to
change this behavior. In Figure , it is desirable to make RT5 a
Level 1-only router while RT1 remains capable of Level 1-2.
This requires RT5 to be configured with the is-type
level-1 command, but nothing needs to be done on RT1. If
RT1 is made a Level 2-only router with is-type
level-2-only command, it will not be capable of forming a
Level 1 adjacency with RT5. The proper setup is to make RT5 a
Level 1 router only if it has limited resources (memory and
CPU); RT1 should be a Level 1-2 router for it to communicate
with RT5 at Level 1 and with RT2 at Level 2 because RT2 is in
another area. Just as with RT5, RT6 can be a Level 1-only
router, if necessary. Step 4: Checking for area
misconfiguration
Two routers in different areas with
different area IDs consequently are assigned to different
areas, therefore, form only a Level 2 adjacency. RT5 is
configured as Level 1 only but its area ID is misconfigured to
be different from the area ID of RT1. These two routers will
not form any adjacency. The configuration in Figure , even
though RT1 is expected to be in area 49.001, has been
configured with an area ID of 49.005 placing it in a different