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