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