Troubleshooting IS-IS Adjacency Problems

‚  < ‚  Free Open Study ‚  > ‚  

Troubleshooting IS-IS Adjacency Problems

IS-IS adjacency- related problems normally are caused by link failures and configuration errors. On Cisco routers, link failures easily can be identified by inspection of a show interface command output. 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. Chapter 10 provides a preview of this command in the coverage of basic configuration and verification of IS-IS operation. 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; the previous command lists all types of adjacencies, both for IS-IS and for ES-IS.

Before proceeding with the troubleshooting scenarios, take a look at this command again. The output in Example 11-1 was obtained from RT1, which is connected, as shown in Figure 11-1. Also shown in Example 11-1 is a variation of this command with an additional keyword, detail.

Figure 11-1. Network Diagram for Example 11-1

graphics/11fig01.gif

Example 11-1 show clns neighbors Command Output
 RT1#  show clns neighbors   System Id      Interface   SNPA             State  Holdtime  Type Protocol  RT2            Se0/0       *HDLC*           Up     27        L2   IS-IS RT5            Et0/0       00d0.58eb.ff01   Up     25        L1   IS-IS RT1#  show clns neighbors detail   System Id      Interface   SNPA             State  Holdtime  Type Protocol  RT2            Se0/0       *HDLC*           Up     24        L2   IS-IS   Area Address(es): 49.0002   IP Address(es):  192.168.1.2*   Uptime: 02:15:11 RT5            Et0/0       00d0.58eb.ff01   Up     23        L1   IS-IS   Area Address(es): 49.0001   IP Address(es):  10.1.1.5*   Uptime: 02:15:11 

The show clns neighbors command provides a summary of known neighbors, the connecting interface, and the state of the adjacency. The show clns neighbors detail command provides more information about each neighbor, such as the area that it belongs to and how long it has been known (uptime). Explanation of the fields in this output is as follows :

  • System ID ‚ System identifier of the neighbor.

  • Interface ‚ Physical interface where the neighbor is connected.

  • SNPA ‚ Subnetwork point of attachment. This is the data link type or address (HDLC or PPP for serial, and MAC address for LANs).

  • State ‚ State of the adjacency ‚ up, down, or init.

  • Holdtime ‚ The time interval until expiration of the adjacency. The holdtime is reset to the product of the hello interval and hello multiplier for corresponding neighbors every time that a hello is received from them. The default values of the hello interval and the hello multiplier are 10 seconds and 3, respectively; hence, the holdtime is reset to 30 seconds on receipt of a hello packet under default conditions of operation.

  • Type ‚ Type of adjacency ‚ Level 1, Level 2, or both.

  • Protocol ‚ The type of adjacency ‚ IS-IS, ISO IGRP, or ES-IS.

Problems with IS-IS adjacency formation can be registered by the presence of fewer neigh-bors than are 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 the ES-IS protocol instead of IS-IS.

You might recall from Chapter 10 that the ES-IS protocol is one of three protocols that supports the ISO CLNS environment. 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.

In the output of show clns displayed in Example 11-1, RT1 has properly formed adjacencies with its directly connected neighbors, RT2 (over Serial 0/0) and RT5 (over Ethernet 0/0). By using a three-way handshake to complete the adjacency process, RT1 can be certain that both RT2 and RT5 also have normally established corresponding adjacencies in the reverse direction. Example 11-2 shows similar output from RT1 featuring problems with the adjacencies formed with RT2 and RT5.

Example 11-2 show clns neighbors Command Output
 RT1#  show clns neighbors  System Id      Interface   SNPA            State  Holdtime  Type Protocol RT2            Se0/0       *HDLC*  Init  27        L2  IS-IS  RT5            Et0/0       00d0.58eb.ff01  Up  25        L1  ES-IS  

In this example, the IS-IS adjacency with RT2 is in INIT state instead of UP. The protocol is correctly shown as IS-IS. However, the adjacency with RT5 is in UP state; 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. When you determine that an IS-IS adjacency problem is not the result of link problems, you can use the show clns interface command to display anomalies, such as contention over the role of designated intermediate system (DIS). 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 many neighbors because the display shows all the hellos transmitted and received by the local routers. Consecutive hellos sent and received between two stations are spaced at approximately 10 seconds, in the default setting, so information fills the screen quickly.

The objective of the sections that follow is to assist you in understanding the nature of adjacency problems, uncover the causes, and correct them. Networks are critical in today's business environment, and the ability to troubleshoot problems quickly is a virtue that helps save businesses from the high costs associated with network outages and earns the network operator years of employability and accompanying benefits.

The following sections discuss adjacency problems and suggest possible causes.

Table 11-1 summarizes the adjacency problems and possible causes covered in this section. This abbreviated representation is designed to facilitate reference to the material. Each problem listed is subsequently elaborated, and pointers are provided on how to identify the symptoms and the necessary actions required to correct a specific problem.

Table 11-1. IS-IS Adjacency Problems/Causes
Problem Possible Causes
Problem 1: The IS-IS process is enabled, but some or all of the expected adja-cencies are not being formed, that is, some or all expected adjacencies are not in the output of the show clns neighbors command at all.

Links might be down, or the interfaces might be administratively shut down.

Also, the IS-IS configuration might be incomplete. Make sure that IS-IS is enabled on all interfaces of interest.

Check that the interface is defined as passive under the IS-IS router configuration.

Other possibilities are as follows:

  • Mismatched Level 1 and Level 2 interfaces or mismatched area addresses

  • Incorrect IP subnet configuration

  • Duplicate system ID in IS-IS area or backbone

Problem 2: Some or all of the neighbors displayed in the show clns neighbor output are in the INIT state.

A possible maximum transmission unit (MTU) mismatch has occurred.

Check for authentication problems.

Transmitted hellos are being corrupted before reaching the neighbor(s). Check for IS-IS packet errors in the log.

Problem 3: Some or all of the neighbors on an interface are in an UP state, but the protocol type is ES-IS instead of IS-IS.

A possible maximum transmission unit (MTU) mismatch has occurred.

Check for authentication problems.

IS-IS hellos are not being received or are coming in corrupted from the neighbor(s).

Problem 1: 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 11-2 shows a simple network in which four daisy-chained routers are grouped in twos and placed in separate areas.

Figure 11-2. Simple Network Diagram for Illustrating Adjacency Problems

graphics/11fig02.gif

The output of the show clns neighbors command captured on RT1 and shown in Example 11-3 displays only one neighbor instead of the expected two. RT2 is listed, but RT5 is missing. Because RT5 also is expected to be adjacent, this signals an adjacency problem that needs to be further investigated.

Example 11-3 show clns neighbors Command Output Reveals a Missing Neighbor
 RT1#  show clns neighbors  System Id      Interface   SNPA            State  Holdtime  Type Protocol RT2            Se0/0       *HDLC*          UP     27        L2   IS-IS 

The flowchart in Figure 11-3 illustrates the logical steps for troubleshooting the problem. These steps also are elaborated in the text that follows.

Figure 11-3. Flowchart for Resolving Missing IS-IS Adjacencies

graphics/11fig03.gif

Step 1: Checking for Link Failures

The first step toward addressing this problem is to make sure that all the interfaces on which adjacencies should be formed are in the up/up state. On Cisco routers, this can be done quickly with the show ip interfaces brief command, which displays a summary of all the interfaces, as shown in Example 11-4. The example is based on Figure 11-2.

Example 11-4 show ip interfaces brief Command Output Displays Physical State of Interfaces
 RT1#  show ip interface brief  Interface       IP-Address   OK? Method  Status                  Protocol  Ethernet0/0     10.1.1.1     YES NVRAM  administratively down   down  Serial0/0       192.168.1.1  YES NVRAM  up                      up  FastEthernet1/0 unassigned   YES unset  administratively down   down  Loopback0       11.1.1.1     YES NVRAM  up                      up  

The Status column of the show ip interfaces brief command tells whether an interface is up, down, or administratively down at the physical level. The Protocol column also needs to be up in order to confirm normal operation at the data link. Verify that the interface is working by pinging across to the other end, as demonstrated on Example 11-5. From Figure 11-2, you know that RT2 is on the other end of serial0/0 and has an IP address of 192.168.1.2 on the corresponding interface. Therefore, a ping to this interface will verify whether packets can go over the link. A successful ping test is confirmed by exclamations, as shown in Example 11-5. When the ping test fails, dots instead of exclamations are displayed. If the ping fails, the physical connectivity prob-lem first must be resolved before IS-IS operation is checked any further.

Example 11-5 Using ping to verify connectivity
 RT1#  ping 192.168.1.2  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms 
Step 2: Verifying Basic Configuration

If the link is fine, the next step involves verifying the IS-IS configuration. In general, IS-IS is enabled in two steps. First, the IS-IS process is configured, as shown in Example 11-6. Make sure that the IS-IS process is defined and that an NSAP or NET is configured.

Example 11-6 IS-IS Process Configuration
 router isis  net 49.0001.0000.0000.0001.00 

Unlike other IP routing protocols, such as RIP and OSPF, the IS-IS configuration doesn't use network statements to enable IS-IS routing on the router's interfaces. For example, in OSPF, if the IP subnet configured on an interface falls in the range of a network statement, OSPF will send Hellos over that interface to form adjacencies and therefore exchange IP routing inform -ation over that interface.

To enable IS-IS routing for IP on a Cisco router, you must configure the ip router isis command on the appropriate interfaces. The IP subnets on interfaces enabled for IS-IS routing in this manner automatically are put into the locally generated LSP. The only network statement required in IS-IS is the ISO NSAP, which also commonly is referred to as the network entity title (NET). However, it should be noted that misconfigured NETs are a common cause of IS-IS adjacency problems. This is further described later in Step 4, "Checking for Area Misconfiguration."

For interfaces on which the ip router isis command is missing, make sure that the router-level passive-interface command is not being used to disable IS-IS routing on them. When an inter-face is made passive, the ip router isis command automatically is removed from the interface. An interface is made passive if it is desirable to advertise its associated IP subnet without form-ing any adjacencies over it. Loopback interfaces normally are configured this way.

Step 3: Checking 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 is 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 facil-itate interarea communication.

In the default mode of operation, Cisco routers have Level 1 ‚ 2 capability. Two directly con-nected 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. You can use the router-level is-type command to change this behavior.

Using Figure 11-2 as an example, it might be 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 the command is-type level-2-only, it will not be capable of forming a Level 1 adjacency with RT5. As shown in Figure 11-2, the proper setup is to make RT5 a Level 1 router only if it has limited resources (memory and CPU capacity); 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

In the CLNP addressing overview provided in Chapter 10, the three main components of an NSAP address are discussed. With 1 byte at the farthest right end of the NSAP reserved for the NSEL and the following 6 bytes for the system ID, the rest of the address defines the area ID (see Figure 10-8 in Chapter 10).

Just as in the case of Step 3, two routers in different areas with different area IDs conse-quently are assigned to different areas and, therefore, form only a Level 2 adjacency. Using Figure 11-2 as an example, if RT5 is configured as Level 1 only but its area ID is miscon-figured to be different from the area ID of RT1, these two routers will not form any adjacency. The configuration in Example 11-7, even though RT1 is expected to be in area 49.0001, has been configured with an area ID of 49.0005 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 ‚ only router with the command is-type level-1. Therefore, no IS-IS adjacency will be formed between RT1 and RT5.

Example 11-7 RT1 and RT5 Configurations Show Area IDs and Adjacency Capabilities
 hostname RT1 ! interface Ethernet 0/0  ip address 10.1.1.1 255.255.255.0  ip router isis ! router isis net  49.0001  .0000.0000.0001.00 hostname RT5 ! interface Ethernet0/0  ip address 10.1.1.5 255.255.255.0  ip router isis ! router isis  net  49.0005  .0000.0000.0005.00  is-type level-1  
Step 5: Checking for Misconfigured IP Subnets

In recent releases of Cisco IOS Software, particularly in 12.0S, 12.0ST, and 12.0T release trains, adjacencies will not be formed between two neighbors if their directly connected interfaces are not in the same IP subnet. In Example 11-8, the address of RT1 is changed to that of another subnet. Again using Figure 11-2 for illustration, Example 11-9 shows RT1 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.

Example 11-8 Verifying the Effect of an IP Subnet Mismatch on IS-IS Adjacencies
 RT1#  show interface Ethernet 0/0  Ethernet0/0 is up, line protocol is up   Hardware is AmdP2, address is 00d0.58f7.8941 (bia 00d0.58f7.8941)   Internet address is 10.1.1.1/24 RT1#  conf t  Enter configuration commands, one per line.  End with CNTL/Z. RT1(config)#  int e 0/0  RT1(config-if)#  ip address 10.1.8.1 255.255.255.0  RT1(config-if)#  ^Z  
Example 11-9 Debugging Adjacency Problems Caused by an IP Subnet Mismatch
 RT1#  debug isis adj-packet  IS-IS Adjacency related packets debugging is on Apr 21 21:55:39: ISIS-Adj: Rec L1 IIH from 00d0.58eb.ff01 (Ethernet0/0), cir ty7  Apr 21 21:55:39: ISIS-Adj: No usable IP interface addresses in LAN IIH from Eth0  Apr 21 21:55:40: ISIS-Adj: Sending L1 IIH on Ethernet0/0, length 1497 Apr 21 21:55:41: ISIS-Adj: Sending serial IIH on Serial0/0, length 1499 Apr 21 21:55:42: ISIS-Adj: Rec L1 IIH from 00d0.58eb.ff01 (Ethernet0/0), cir ty7 Apr 21 21:55:42: ISIS-Adj: No usable IP interface addresses in LAN IIH from Eth0 Apr 21 21:55:43: %CLNS-5-ADJCHANGE: ISIS: Adjacency to RT5 (Ethernet0/0) Down, Apr 21 21:55:43: ISIS-Adj: L1 adj count 0 

In earlier Cisco IOS Software releases, it did not matter whether the routers belonged to 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 System 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 a duplicate system ID error, as shown in Example 11-10. 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, which points to the interface where the hellos with the duplicate system ID are coming from. See Example 11-11.

Example 11-10 Duplicate System ID Error Logs
 RT1#  show logging  Apr 21 16:30:59: %CLNS-3-BADPACKET: ISIS:  LAN L1 hello, Duplicate system ID  det) Apr 21 16:31:59: %CLNS-3-BADPACKET: ISIS:  LAN L1 hello, Duplicate system ID  det) Apr 21 16:33:00: %CLNS-3-BADPACKET: ISIS:  LAN L1 hello, Duplicate system ID  det) 
Example 11-11 Detecting Duplicate System IDs with debug isis adj-packet
 RT1#  debug isis adj-packet  IS-IS Adjacency related packets debugging is on RT1# Apr 21 21:43:08: ISIS-Adj: Sending L2 IIH on Ethernet0/0, length 1497 Apr 21 21:43:09: ISIS-Adj: Sending L1 IIH on Ethernet0/0, length 1497 Apr 21 21:43:09: ISIS-Adj: Rec L1 IIH from 00d0.58eb.ff01 (Ethernet0/0), cir ty7  Apr 21 21:43:09: ISIS-Adj: Duplicate system id  Apr 21 21:43:12: ISIS-Adj: Sending L1 IIH on Ethernet0/0, length 1497 Apr 21 21:43:12: ISIS-Adj: Sending L2 IIH on Ethernet0/0, length 1497 Apr 21 21:43:12: ISIS-Adj: Rec L1 IIH from 00d0.58eb.ff01 (Ethernet0/0), cir ty7  Apr 21 21:43:12: ISIS-Adj: Duplicate system id  

Problem 2: Adjacency in INIT State

The most common causes for an adjacency getting stuck in INIT state are mismatched interface MTU and misconfigured authentication parameters. The output in Example 11-12 shows what an adjacency would look like when stuck in INIT.

Example 11-12 IS-IS Adjacency Stuck in an INIT State
 RT2#  show clns neighbors  System Id      Interface   SNPA          State  Holdtime  Type Protocol RT1            Se0/0       *HDLC*  Init  29        L2   IS-IS 

To guarantee that adjacent IS-IS routers can receive and process LSPs of manageable sizes from each other, ISO 10589 specifies that hellos, which are used to form and maintain adjacencies, should be padded up to maxsize ‚ 1, where maxsize is the maximum LSP buffer size or the MTU of the outgoing interface of the source node. The objective of this requirement is to ensure that an adjacency will be formed only between routers capable of handling all IS-IS packets sent to each other. The maximum LSP buffer size is specified as 1492 bytes; however, Cisco IOS Software defaults to the MTU, meaning that hellos are padded to MTU ‚ 1 bytes. Therefore for Cisco routers, every-thing being equal, adjacencies are formed only when MTUs of directly connected interfaces match.

Figure 11-4 illustrates a situation for normal adjacency formation.

Figure 11-4. Investigating IS-IS Adjacencies ‚ A Simple Network

graphics/11fig04.gif

In Example 11-13, the output of show clns neighbors from RT1 shows that the adjacency state is up and that the protocol type is IS-IS. Example 11-13 also shows excerpts of the show clns interface command from the two routers involved, RT1 and RT2. The MTU is 1500 bytes on either side.

Example 11-13 Correctly Formed IS-IS Adjacency
 RT1#  show clns neighbors  System Id    Interface   SNPA            State  Holdtime  Type Protocol RT2          Se0/0        *HDL C*  Up  250      IS  IS-IS  RT1#  show clns interface s 0/0  Serial0/0 is up, line protocol is up   Checksums enabled,  MTU 1500  , Encapsulation HDLC _____________________________________________________________________________________ RT2#  show clns int s 0/0  Serial0/0 is up, line protocol is up   Checksums enabled,  MTU 1500  , Encapsulation HDLC 

Often, an adjacency will be stuck in INIT because only one side is enabled for authentication. For example, when basic IS-IS authentication is enabled, a simple clear-text password is carried in a Type Length Value (TLV) field (Type 10) in the hello packets. If the hello received by a peer does not contain the authentication TLV or the password in the TLV is not as expected, the peer ignores the hello. On the other hand, if a router is not enabled for authentication, it doesn't care about the existence of the authentication TLV in a neighbor's hello. This latter situation leads to a router processing a neighbor's hellos, registering that neighbor, advancing the status of the adjacency to INIT, and not going further. This is because the other router ignores any received hellos from the first and, therefore, never lists the first router as a detected IS neighbor. Therefore, the two routers are unable to complete the three-way adjacency process to form a complete adjacency. This is further elaborated later in this chapter, in the "Misconfigured Authentication" section. Another reason why an adjacency might be stuck in INIT is that the local routers' hello might not be getting corrupted before reaching the other end.

Figure 11-5 is a flowchart representing troubleshooting steps for problems in which an IS-IS adjacency is stuck in INIT.

Figure 11-5. Flowchart to Resolve IS-IS Adjacencies Stuck in INIT

graphics/11fig05.gif

Step 1. If IS-IS authentication is configured, the first step in tackling this problem is to address any potential issues in this area. If no authentication is in use, the potential cause of the problem could be mismatched MTUs.

Step 2. In this step, the configuration for authentication is verified . The Cisco implementation allows authentication to be configured in three ways: at the domain, area, or interface levels. Make sure that the appropriate method is properly configured and that the passwords used are consistent. Authentication is further elaborated in a subsequent section, "Misconfigured Authentication."

Step 3. In this step, it is assumed that there are no authentication issues. Hence, the next possibility is mismatched MTUs. The show clns interface command can quickly verify the MTUs on either side of the link. The "Mismatched MTU" section provides further details on debugging and verification pro-cedures for troubleshooting MTU mismatched problems.

Step 4. Recent 12.0S and 12.0ST Cisco IOS Software releases allow hello padding to be disabled to reduce significant and unnecessary bandwidth consumption in some network environments. Hello padding is disabled with the assump-tion that the MTUs match. This step suggests making sure that hello padding is configured consistently on either side. If the MTUs match on either side, disabling hello padding on only one side will not have any operational con-sequences. Issues relating to the disabling of hello padding are explored further in the later section "IS-IS Hello Padding."

Step 5. If no issues are found with authentication and MTUs also match, debugging of the IS-IS adjacency-formation process should be enabled with the command debug isis adj-packets . The output should be scrutinized for clues that could provide more insight into the init state of the adjacency. Debugging should be enabled at both ends with timestamps to help correlate events at both sides.

Step 6. In this decision step, you determine whether you have enough information to diagnose the problem and implement a solution, or whether you need to ask for expert assistance.

Step 7. If nothing can be discerned about the problem at this time, it most likely is caused by a software malfunction and should be turned over for technical assistance.

Step 8. This step is the solution stage. The troubleshooting process ends at this step if the problem is figured out. If it is determined that the problem is with authentication, the necessary configuration changes can be made to enable the adjacency to complete. On the other hand, if there is an MTU mismatch, the MTU must be changed on one side to match the other. Disabling the hello padding does not remove MTU verification at either end; it just allows smaller hellos to be advertised to save bandwidth.

As mentioned previously, a possible cause of the adjacency getting stuck in INIT is when one side's hellos are reaching the other side but corrupted in transition. This situation is comparable to the misconfigured adjacency scenario. To determine if packet corruption might be the cause, you need to check for packet corruption errors in the logs of the remote router.

Mismatched MTU

Examples 11-14 and 11-15 demonstrate the effect of the default behavior of mismatched MTUs. The demonstration is based on Figure 11-4.

Example 11-14 Debugging MTU Mismatch on RT2
 RT2(config)#  interface s 0/0  RT2(config-if)#  mtu 2000  RT2#  debug isis adj-packets  IS-IS Adjacency related packets debugging is on RT2#  Apr 20 19:56:23: ISIS-Adj: Sending serial IIH on Serial0/0, length 1999  Apr 20 19:56:23: ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir type L1L2 Apr 20 19:56:23: ISIS-Adj: rcvd state UP, old state UP, new state UP Apr 20 19:56:23: ISIS-Adj: Action = ACCEPT  Apr 20 19:56:31: ISIS-Adj: Sending serial IIH on Serial0/0, length 1999  Apr 20 19:56:33: ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir type L1L2 Apr 20 19:56:33: ISIS-Adj: rcvd state UP, old state UP, new state UP Apr 20 19:56:33: ISIS-Adj: Action = ACCEPT Apr 20 19:56:39: ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir type L1L2  Apr 20 19:56:39: ISIS-Adj: rcvd state DOWN, old state UP, new state INIT  Apr 20 19:56:39: ISIS-Adj: Action = GOING DOWN  Apr 20 19:56:39: %CLNS-5-ADJCHANGE: ISIS: Adjacency to RT1 (Serial0/0) Down, nes  Apr 20 19:56:39: ISIS-Adj: L2 adj count 0 Apr 20 19:56:39: ISIS-Adj: Sending serial IIH on Serial0/0, length 1999 Apr 20 19:56:40: ISIS-Adj: Sending serial IIH on Serial0/0, length 1999 Apr 20 19:56:42: ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir type L1L2  Apr 20 19:56:42: ISIS-Adj: rcvd state DOWN, old state DOWN, new state INIT  Apr 20 19:56:42: ISIS-Adj: Action = GOING UP, new type = L2 Apr 20 19:56:42: ISIS-Adj: New serial adjacency Apr 20 19:56:42: ISIS-Adj: Sending serial IIH on Serial0/0, length 1999 Apr 20 19:56:50: ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir type L1L2 Apr 20 19:56:50: ISIS-Adj: rcvd state DOWN, old state INIT, new state INIT Apr 20 19:56:50: ISIS-Adj: Action = GOING UP, new type = L2 Apr 20 19:56:51: ISIS-Adj: Sending serial IIH on Serial0/0, length 1999 

As shown in Example 11-14, the MTU on RT2 is changed to 2000 bytes, and the debug isis adj-packet command is enabled to observe what goes on in the background. Notice that be-cause the MTU on the serial interface is now 2000 bytes, the hello packets are padded to 1999 bytes. The debug output shows RT2 sending out serial IIHs of 1999 bytes.

This output also shows that RT2 continues to receive and process IIHs from RT1. However, at this time, RT1 cannot accept and process the 1999-byte IIHs from RT2 and, therefore, deletes the adjacency, removing RT2 from the list of known IS neighbors advertised in its hello. Con-sequently, RT2 changes the state of the adjacency to INIT and logs an adjacency change error. From this time on, the adjacency gets stuck in INIT. RT2 receives 1499-byte hellos from RT1, which are not larger than the 1999 bytes expected. However, the IS-IS adjacency is stuck in INIT state because RT1 cannot complete the three-way adjacency process.

Example 11-15 features show clns neighbors command output from RT2, confirming the debugging output.

Example 11-15 Init State Confirmed on RT2
 RT2#  show clns neighbors  System Id      Interface   SNPA          State  Holdtime  Type Protocol RT1            Se0/0       *HDLC*  Init  29        L2   IS-IS 

Example 11-16 features the corresponding debugging output on RT1.

Example 11-16 Debugging MTU Mismatch on RT1
 RT1#  debug isis adj-packets  IS-IS Adjacency related packets debugging is on Apr 20 19:55:52: ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir type L1L2 Apr 20 19:55:52: ISIS-Adj: rcvd state UP, old state UP, new state UP Apr 20 19:55:52: ISIS-Adj: Action = ACCEPT Apr 20 19:55:52: ISIS-Adj: Sending serial IIH on Serial0/0, length 1499 Apr 20 19:56:00: ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir type L1L2 Apr 20 19:56:00: ISIS-Adj: rcvd state UP, old state UP, new state UP Apr 20 19:56:00: ISIS-Adj: Action = ACCEPT Apr 20 19:56:01: ISIS-Adj: Sending serial IIH on Serial0/0, length 1499  Apr 20 19:56:10: ISIS-Adj: Sending serial IIH on Serial0/0, length 1499   Apr 20 19:56:18: ISIS-Adj: Sending serial IIH on Serial0/0, length 1499   Apr 20 19:56:28: ISIS-Adj: Sending serial IIH on Serial0/0, length 1499   Apr 20 19:56:30: %CLNS-5-ADJCHANGE: ISIS: Adjacency to RT2 (Serial0/0) Down, hod  Apr 20 19:56:30: ISIS-Adj: L2 adj count 0 Apr 20 19:56:34: ISIS-Adj: Sending serial IIH on Serial0/0, length 1499 Apr 20 19:56:37: ISIS-Adj: Sending serial IIH on Serial0/0, length 1499 Apr 20 19:56:45: ISIS-Adj: Sending serial IIH on Serial0/0, length 1499 

The logging timestamps are almost synchronized to match related events as they occur on the separate routers. RT1 does not report receipt of any corresponding hellos from RT2 for the three highlighted consecutive hellos that it advertises; consequently, it drops the adjacency to RT2 and also logs an adjacency change error. RT1 silently discards the hellos from RT2 and doesn't log any corresponding errors until it drops the adjacency. Even though RT1 does not process any of the IIHs from RT2 because they are larger than expected, resulting in deletion of the IS-IS adjacency, it retains an ES-IS adjacency to RT2. The ES-IS adjacency is sustained independently by ISHs under the ES-IS protocol.

Example 11-17 shows the corresponding output of show clns neighbors on RT1 after the IS-IS adjacency is dropped.

Example 11-17 ES-IS Adjacency Retained on RT1 Without IS-IS Adjacency
 RT1#  show clns neighbors  System Id    Interface   SNPA          State  Holdtime  Type Protocol RT2          Se0/0       *HDLC*        Up     250       IS   ES-IS 

Example 11-18 demonstrates reinstatement of the adjacency after the MTU is corrected on RT2. As highlighted in the debugging output, RT2 begins to send 1499-byte IIHs to RT1. These obviously are accepted and processed by RT1, which then sends IIHs with RT2 listed as an IS nieghbor to complete the three-way handshake, thus restoring the adjacency.

Example 11-18 Correcting the MTU Mismatch Restores IS-IS Adjacency Between RT1 and RT2
 RT2(config-if)#  mtu 1500  RT2(config-if)#  ^Z  RT2# RT2#  debug isis adj-packets   Apr 20 20:09:15: ISIS-Adj: Sending serial IIH on Serial0/0, length 1499  Apr 20 20:09:15: ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir type L1L2 Apr 20 20:09:15: ISIS-Adj: rcvd state DOWN, old state INIT, new state INIT  Apr 20 20:09:15: ISIS-Adj: Action = GOING UP, new type = L2   Apr 20 20:09:18: ISIS-Adj: Sending serial IIH on Serial0/0, length 1499  Apr 20 20:09:18: ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir type L1L2  Apr 20 20:09:18: ISIS-Adj: rcvd state INIT, old state INIT, new state UP  Apr 20 20:09:18: ISIS-Adj: Action = GOING UP, new type = L2 Apr 20 20:09:18: %CLNS-5-ADJCHANGE: ISIS: Adjacency to RT1 (Serial0/0) Up, new y  Apr 20 20:09:18: ISIS-Adj: L2 adj count 1  Apr 20 20:09:19: ISIS-Adj: Sending serial IIH on Serial0/0, length 1499 Apr 20 20:09:19: ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir type L1L2 Apr 20 20:09:19: ISIS-Adj: rcvd state UP, old state UP, new state UP Apr 20 20:09:19: ISIS-Adj: Action = ACCEPT Apr 20 20:09:27: ISIS-Adj: Sending serial IIH on Serial0/0, length 1499 
IS-IS Hello Padding

Recent releases of Cisco IOS Software from the 12.0S and 12.0ST trains allow padding of hellos to be disabled. Older releases follow ISO 10589, which requires hellos to be padded automatically, as described earlier. The motivation behind disabling hello padding is based on the notion that this process is effectively not an MTU discovery mechanism and designed to check only MTU consistency between adjacent neighbors. Because most media have default MTUs, this check is, therefore, redundant and costly. Network operators are also well aware of their networking environments, so padding hellos to the MTU size of outgoing interfaces results in unnecessary waste of network bandwidth.

A couple of commands exist for disabling and re-enabling IS-IS hello padding. Hellos are padded by default on Cisco routers.

The following is a router-level command and applies globally to all IS-IS ‚ enabled interfaces. The multipoint and point-to-point keywords restrict the effect of the command to only multipoint or point-to-point interfaces, respectively:

 [  no  ]  hello padding  [  multipoint   point-to-point  ] 

The following is an interface-level command that can be applied to disable padding on a specific interface:

 [  no  ]  isis hello padding  

The status of hello padding on an interface can be verified with the show clns interface command, as shown in Example 11-19. Examples 11-20 and 11-21 display debug isis adj-packet outputs for RT1 and RT2, respectively (see Figure 11-4). Example 11-20 shows RT1 sending hellos of only 38 bytes because padding has been disabled. On the other hand, RT2 is sending 1499 bytes, 1 byte short of the MTU on Serial 0/0, because hello padding is still enabled. Because the MTU on RT2 has not changed, its expected maximum hello size from RT1 remains 1499. The adjacency will fail if RT1 is configured with an MTU of 2000, for example, and starts sending hellos of 1999.

In general, suppressing hello padding only 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.

Example 11-19 Verifying Status of Hello Padding on an Interface
 RT1#  show clns interface Serial0/0  Serial0/0 is up, line protocol is up   Checksums enabled, MTU 1500, Encapsulation HDLC   ERPDUs enabled, min. interval 10 msec.   RDPDUs enabled, min. interval 100 msec., Addr Mask enabled   Congestion Experienced bit set at 4 packets   CLNS fast switching enabled   CLNS SSE switching disabled   DEC compatibility mode OFF for this interface   Next ESH/ISH in 40 seconds   Routing Protocol: IS-IS     Circuit Type: level-1-2     Interface number 0x1, local circuit ID 0x100     Level-1 Metric: 10, Priority: 64, Circuit ID: RT2.00     Number of active level-1 adjacencies: 0     Level-2 Metric: 10, Priority: 64, Circuit ID: 0000.0000.0000.00     Number of active level-2 adjacencies: 1     Next IS-IS Hello in 3 seconds  No hello padding  
Example 11-20 Debugging IS-IS Hello Packets on RT1
 RT1#  debug isis adj-packets  Apr 29 14:34:22: ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir type L1L2 Apr 29 14:34:22: ISIS-Adj: rcvd state UP, old state UP, new state UP Apr 29 14:34:22: ISIS-Adj: Action = ACCEPT  Apr 29 14:34:25: ISIS-Adj: Sending serial IIH on Serial0/0, length 38  Apr 29 14:34:32: ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir type L1L2 Apr 29 14:34:32: ISIS-Adj: rcvd state UP, old state UP, new state UP Apr 29 14:34:32: ISIS-Adj: Action = ACCEPT  Apr 29 14:34:38: ISIS-Adj: Sending serial IIH on Serial0/0, length 38  
Example 11-21 Debugging IS-IS Hello Packets on RT2
 RT2#  debug isis adj-packets   Apr 29 14:34:15: ISIS-Adj: Sending serial IIH on Serial0/0, length 1499  Apr 29 14:34:17: ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir type L1L2 Apr 29 14:34:17: ISIS-Adj: rcvd state UP, old state UP, new state UP Apr 29 14:34:17: ISIS-Adj: Action = ACCEPT  Apr 29 14:34:23: ISIS-Adj: Sending serial IIH on Serial0/0, length 1499  Apr 29 14:34:26: ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir type L1L2 Apr 29 14:34:26: ISIS-Adj: rcvd state UP, old state UP, new state UP Apr 29 14:34:26: ISIS-Adj: Action = ACCEPT 

The no hello padding command is effective only after the adjacency is activated (see Example 11-22). Therefore, before adjacency is formed, the size of hello packets transmitted to solicit adjacencies is MTU ‚ 1. This also implies that an adjacency stays up when the MTU size is changed to a larger value after the hello padding is disabled; the hello packets transmitted are deceptively small. However, if packets larger than the MTU on the receiving side are transmitted, they are dropped. In this situation, if the link flaps, the adjacency fails be-cause the MTU mismatch is detected during the initial exchange of hellos after the flap.

Example 11-22 shows that RT1 stops sending 38-byte unpadded hellos and starts sending 1499-byte hellos after the interface is shut down to deactivate the IS-IS adjacency.

Example 11-22 Debugging Hello Packets with Interface Shut Down
 RT1(config-if)#  interface serial0/0  RT1(config-if)#shutdown RT1(config-if)#  ^Z  RT1# RT1#  debug isis adj-packets  Apr 29 15:18:43: ISIS-Adj: Sending serial IIH on Serial0/0, length 38  Apr 29 15:18:46: %CLNS-5-ADJCHANGE: ISIS: Adjacency to RT1 (Serial0/0) Down, hod  Apr 29 15:18:46: ISIS-Adj: L2 adj count 0  Apr 29 15:18:49: ISIS-Adj: Sending serial IIH on Serial0/0, length 1499  Apr 29 15:18:52: ISIS-Adj: Sending serial IIH on Serial0/0, length 1499 Apr 29 15:19:02: ISIS-Adj: Sending serial IIH on Serial0/0, length 1499 Apr 29 15:19:11: ISIS-Adj: Sending serial IIH on Serial0/0, length 1499 
Misconfigured Authentication

Authentication can be misconfigured in two situations, resulting in incomplete adjacencies:

  • Authentication passwords on either side of the adjacency do not match.

  • One side of the adjacency is not enabled for authentication.

Recall from Chapter 10 that currently (at the time of writing) only simple passwords are supported on Cisco routers. Three methods exist for enabling IS-IS authentication:

  • The first method is at the interface level with the isis password command . This configuration can be for routing at Level 1 or Level 2 or both.

  • The second method uses the router-level area-password command and applies to only Level 1 routing on all active IS-IS interfaces on the router.

  • The third method is for Level 2 only and uses the domain-password command at the router level.

When there is a password mismatch, the IS-IS adjacency does not come up at all for the applicable level of routing on either side of the connection, and the show clns neighbors command displays only ES-IS adjacency, as shown in Example 11-17.

When only one side is enabled for authentication, that side does not process hellos from a neigh-bor that does not contain the appropriate passwords. The side without authentication does not check for passwords, so it receives and processes hellos as usual; however, the adjacency will not advance beyond INIT because the local side is never listed in the IS neighbor's TLV of the remote router. The output of show clns neighbors looks like the output in Example 11-15. The router configured for authentication does not process IS-IS hellos from the remote side, so IS-IS adjacency is not formed, even though ES-IS adjacencies are formed, as shown in Example 11-17.

Example 11-23 shows the debugging output from the debug isis adj-packets command, providing an indication of authentication problems. The authentication errors are high-lighted.

Example 11-23 Debugging Authentication Problems
 RT1#  debug isis adj-packets  Apr 29 17:09:46: ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir type L1L9  Apr 29 17:09:46: ISIS-Adj: Authentication failed  Apr 29 17:09:48: ISIS-Adj: Sending serial IIH on Serial0/0, length 1499 Apr 29 17:09:54: ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir type L1L9  Apr 29 17:09:54: ISIS-Adj: Authentication failed  Apr 29 17:09:56: ISIS-Adj: Sending serial IIH on Serial0/0, length 1499 Apr 29 17:10:03: ISIS-Adj: Rec serial IIH from *HDLC* (Serial0/0), cir type L1L9 Apr 29 17:10:03: ISIS-Adj: Authentication failed Apr 29 17:10:05: ISIS-Adj: Sending serial IIH on Serial0/0, length 1499 

Problem 3: Only ES-IS Adjacency Instead of IS-IS Adjacency Formed

Cisco routers running IS-IS in IP environments still listen to ISHs generated by ES-IS protocol, in conformance with ISO 10589 requirements. Hence, 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. Example 11-24 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 most likely because IS-IS hellos are not being processed, as a result of interface MTU mismatch or misconfigured authentication. Both of these causes are covered extensively in the previous section.

Example 11-24 Forming an ES-IS Adjacency
 RT1#  show clns neighbors  System Id    Interface   SNPA          State  Holdtime  Type Protocol RT2          Se0/0       *HDLC*        Up     250       IS   ES-IS 
‚  < ‚  Free Open Study ‚  > ‚  


Troubleshooting IP Routing Protocols
Troubleshooting IP Routing Protocols (CCIE Professional Development Series)
ISBN: 1587050196
EAN: 2147483647
Year: 2002
Pages: 260

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net