‚ < ‚ Free Open Study ‚ > ‚ |
Troubleshooting IS-IS Adjacency ProblemsIS-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 Example 11-1 show clns neighbors Command OutputRT1# 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 :
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 OutputRT1# 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 1: Some or All of the Adjacencies Are Not Coming UpThe 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 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 Step 1: Checking for Link FailuresThe 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 InterfacesRT1# 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 ConfigurationIf 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 Configurationrouter 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 InterfacesIS-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 MisconfigurationIn 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 Capabilitieshostname 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 SubnetsIn 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 AdjacenciesRT1# 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 MismatchRT1# 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 IDsIf 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 LogsRT1# 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-packetRT1# 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 StateThe 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 StateRT2# 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 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 AdjacencyRT1# 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
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 MTUExamples 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 RT2RT2(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 RT2RT2# 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 RT1RT1# 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 RT2RT2(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 PaddingRecent 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 InterfaceRT1# 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 RT1RT1# 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 RT2RT2# 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 DownRT1(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 AuthenticationAuthentication can be misconfigured in two situations, resulting in incomplete adjacencies:
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:
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 ProblemsRT1# 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 FormedCisco 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 ‚ > ‚ |