Troubleshooting IS-IS Adjacency Problems
| ‚ < ‚ Free Open Study ‚ > ‚ |
Troubleshooting IS-IS
|
| 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:
|
| 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
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 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
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
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
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
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
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
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
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
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 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
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
-
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 asubsequent 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
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
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
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
-
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
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
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 ‚ > ‚ |
Similar products
Similar products
- ActionScript Cookbook
Flash getuserlist() - ActionScript 3. 0 Cookbook
Actionscript splice insert - Programming C#
C# reflection ebook - Java All-In-One Desk Reference For Dummies
In singleton pattern how do we use clonenotsupported exception in java - Switching to VoIP
Pots as backup to voip - Troubleshooting IP Routing Protocols
How to trace isis duplicate system id in cisco