| Copyright |
© Ericsson AB 2010–2011. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner. | |||
| Disclaimer |
The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document. | |||
| Trademark List |
|
1 Verifying IS-IS
1.1 Sample IS-IS Topology
Use the following simple Intermediate System-to-Intermediate System (IS-IS) topology and configuration as a guide to troubleshooting general IS-IS issues on the SmartEdge® router. The sample output in this section matches the topology. For specific issues, see Section 2.
Figure 1 IS-IS Topology
1.2 Sample Configuration for Router jazz
The following is sample IS-IS configuration for router jazz.
[local]jazz#show configuration isis Building configuration... Current configuration: context local ! router isis jazz net 49.0001.0100.1001.0001.00 address-family ipv4 unicast ! interface to_rock1200 ! bind to ethernet 6/1 address-family ipv4 unicast ! interface loop100 passive-interface address-family ipv4 unicast ! ! ** End Context ** ! end
1.3 Sample Configuration for Router rock1200
The following is the IS-IS configuration for router rock1200.
[local]rock1200#show configuration isis Building configuration... Current configuration: context local ! router isis jazz address-family ipv4 unicast ! router isis rock1200 net 49.0001.0100.1001.1002.00 address-family ipv4 unicast ! interface to_jazz ! bind to ethernet 9/1 address-family ipv4 unicast ! interface second-isis-intf ! not bound to any circuit address-family ipv4 unicast ! ! ** End Context ** ! end
1.4 Tasks to Troubleshooting IS-IS
Use the following table as a guide to troubleshooting IS-IS. More information about each step is provided in subsequent sections.
|
Task |
Command |
Notes |
Checked? |
|---|---|---|---|
|
show log | grep ADJ show log | grep "Adj UP" |
|
||
|
show configuration isis |
|
||
|
show port show port counters |
Make sure your ports are enabled and circuit configuration matches. |
||
|
show ip interface brief show isis interfaces detail |
Make sure your interfaces are up. |
||
|
show isis adjacency |
If you find an issue, run the show isis adj log command. Run the following commands if you cannot isolate the fault.
Risk of performance loss. Enabling the generation of debug messages can severely affect system performance. To reduce the risk, exercise caution when enabling the generation of debug messages on a production system. Note: The configuration on both end points (interface type: point-to-point or broadcast) must match each other; otherwise, you will not be able to form an adjacency. This is a common issue. For information about interface types, see Section 2. For more information about how to troubleshoot IS-IS adjacency issues, see Section 2. |
||
|
show isis adj-log is system-id show isis adj-log interface if-name |
|
||
|
show isis protocol-summary |
Provides a good overview of the IS-IS router. |
||
|
show isis topology |
Displays which routers are participating in the IS-IS network beyond the connected neighbors. |
||
|
show ip route
|
|
||
|
show isis routes
|
|
||
|
show isis database |
This database includes information about the network topology for this area. All the routers in this area should have the same database. Does SPF have the needed LSPs? You also use this command along with the show isis topology command to verify that you are receiving the expected LSPs. For information about this command, see Section 1.12.
|
||
|
show isis statistics |
Verify the IS-IS traffic information. |
||
|
show isis spf-log |
Display a history of the IS-IS SPF calculation results. |
||
|
monitor isis adjacency monitor isis interfaces montior isis statistics |
|||
|
debug isis adjacency interface if-name |
For information about the debug isis adjacency command, see Section 2. |
1.5 Step 1: Check Logs
Run the following commands and check the logs for IS-IS adjacency issues:
- show log | grep ADJ
- show log | grep "Adj UP"
The following example shows you how to check your log for adjacency messages with a state that is Up.
[local]rock1200#show log | grep "Adj UP" Jul 27 11:00:59: [0011]: %ISIS-6-ADJ: L1 Adj UP with ID (0100.1001.1002) on intf to_jazz nsap 49.0001.0100
The following example shows you how to check your log for adjacency messages.
[local]rock1200#show log | grep ADJ Dec 8 01:04:00: [0001]: %ISIS-6-ADJ: P2P Adj UP with ID (1720.2200.5217) on intf to_jazz nsap 49.0001.0100
1.6 Step 2: Verify IS-IS Configuration
Run the show configuration isis command to verify the IS-IS configuration.
The following section describes the NSAP address syntax.
Figure 2 NSAP Address Syntax
Make sure both end points must have the same interface type: point-to-point or broadcast. Make sure the net is configured. ISI-S will not be enabled if no system ID is configured. For information about interface types, see Section 2.
[local]rock1200#show configuration isis Building configuration... Current configuration: context local ! router isis jazz address-family ipv4 unicast ! router isis rock1200 net 49.0001.0100.1001.0001.00 address-family ipv4 unicast ! interface to_jazz ! bind to ethernet 9/1 address-family ipv4 unicast ! interface second-isis-intf ! not bound to any circuit address-family ipv4 unicast ! ! ** End Context ** ! end
1.7 Step 3: Verify Port Status
Run the show port command to verify that the ports are up.
Before you check the status of a port, you first need to understand the differences between the Admin state” and the Line state:
- Admin state—Refers whether the port has been brought
up (by using the no shutdown command) or is down (by
using the shutdown command). If the Admin state is shut down, the port is down.
Recommended Action: Issue the no shutdown command on the port to bring up the port.
- Line state—Refers to the physical state of the port.
Recommended Action: When the Line state is down, use the checklist in Table 2.
|
# |
Line State Troubleshooting Checklist |
Checked? |
|---|---|---|
|
1 |
Is the cable correctly connecting the two ports or two nodes? |
|
|
2 |
Is there a fault in the cable? |
|
|
3 |
Are you using the right type of cable; for example, with Ethernet, are you using a cross-over cable instead of a straight cable? |
|
|
4 |
When the cable is connected to two nodes, is there a fault in one of the nodes? |
|
|
5 |
Is the card with a fiber port receiving light? Is the LOS LED in the port on? |
|
|
6 |
If you are using fiber optics, are you using the appropriate fiber type (for example, multimode or single mode) ? |
|
|
7 |
Is the other end port shut down? |
|
|
8 |
Is there an auto-negotiation mismatch? |
|
|
9 |
Is the SmartEdge router Gigabit Ethernet traffic GE port connected to an FE port? The SmartEdge router Gigabit Ethernet traffic cards do not support FE speeds). |
|
|
10 |
Are the fibers correctly connected? |
|
|
11 |
Does the circuit configuration match? |
If the Admin state is down, the Line state is always down. For the port to be up, the Admin state and Line state must both be up. To check the status of a port, issue the show port detail command. You must use the keyword detail or live to receive results in real time. For detailed information about each field displayed, see the Command List.
Use the following table to determine whether a port is up or down.
|
Admin State (Configuration) |
Line State (Physical) |
Result |
|---|---|---|
|
Up |
Down |
Down |
|
Up |
Up |
Up |
|
Down |
Up |
Down |
|
Down |
Down |
Down |
In the following example, the status of the Ethernet ports are up.
[local]rock1200(config-ctx)#show port Slot/Port:Ch:SubCh Type State 8/1 ethernet Up 9/1 ethernet Up
In the following example, the status of the Ethernet port is down. Although the Ethernet port is in a no shutdown state and the Admin state is up, the cable has been unplugged from the Ethernet port 8/1 and as a result, the Line state (the physical state) is down:
[local]rock1200#show port 8/1 detail ethernet 8/1 state is Up Description : Line state : Down Admin state : Up Encapsulation : ethernet MTU size : 1500 Bytes MAC address : 00:30:88:04:17:29 Media type : 10/100/1000Base-Tx Speed : 100 Mbps Duplex mode : half
Each traffic card collects Layer 1, 2, and 3 statistics. To check port counters, generate traffic on the port, run the show port counters command, and then see if traffic is increasing on the port. For detailed information about each field displayed, see the Command List.
[local]rock1200#show port counters Port Type 8/1 ethernet packets sent : 165488 bytes sent : 14105189 packets recvd : 18802 bytes recvd : 1790955 9/1 ethernet packets sent : 603463 bytes sent : 50526096 packets recvd : 791523 bytes recvd : 62009966 send packet rate : 0.42 send bit rate : 298.07 recv packet rate : 0.18 recv bit rate : 114.38 rate refresh interval : 60 seconds
1.8 Step 4: Verify Interfaces
This section includes the following sections
1.8.1 Verify All Interfaces
Use the show ip interface brief command to check if the interfaces are up. This command displays information about all interfaces, associated addresses, states, and bindings, including the interface bound to the Ethernet management port on the controller card.
An interface can be in any of the following states:
- Unbound—The interface is not currently bound to
any port or circuit. The binding is not valid.
- Note:
- In some cases, an interface can have an Unbound state and still be valid; for example, multibind interfaces where no active PPPoE or CLIPS sessions are active.
- Bound—The interface is bound to at least one port or circuit; however, none of the bound circuits are up. Therefore, the interface is not up. The binding is valid. The state Bound is expected behavior for multibind interfaces where there are no active subscribers.
- Up—At least one of the bound circuits is in the up state; therefore, the interface is also up and traffic can be sent over the interface. The binding is valid.
For detailed information about each field displayed, see the Command List.
[local]rock1200#show ip interface brief Tue May 11 06:04:07 2010 Name Address MTU State Bindings show isis mgmt 10.18.17.103/24 1500 Up ethernet 8/1 second-isis-intf 5.5.5.5/24 0 UnBound to_jazz 192.168.1.1/24 1500 Up ethernet 9/1
1.8.2 Verify IS-IS Interfaces
Run the show isis interface command to verify that the IS-IS interfaces are Up, and also check that the metric for each link is correct. If the IS-IS is down, make sure the interface is enabled.
|
if-name |
Optional. Interface name. Displays information only for the specified interface. |
|
intercontext |
Optional. Displays IS-IS intercontext interfaces. |
|
all |
Optional. Displays IS-IS interface information for all contexts. |
|
detail |
Optional. Displays detailed IS-IS interface information. |
|
extensive |
Optional. Displays information about Label Distribution Protocol (LDP)-Interior Gateway Protocol (IGP) synchronization states. |
The show isis interface output shows the to_jazz interface, which isUp state with a level 3 area performing unicast toplogy based-routing.
Use the if-nam option to specify the IS-IS interface.
[local]rock1200#show isis interface IS-IS interface(s) for tag rock1200: Interface L MT Stat Level-1-DR Level-2-DR Metric to_jazz 3 U Up rock1200.01 rock1200.01 10 Total IS-IS Interface(s): 1 [local]rock1200#show isis interfaces to_jazz IS-IS interface(s) for tag rock1200: Interface L MT Stat Level-1-DR Level-2-DR Metric to_jazz 3 U Up rock1200.01 rock1200.01 10
1.9 Step 5: Verify Which Routers are Adjacent to the System
Before IS-IS routers can exchange routing information, they must establish an adjacency by using IS-IS Hello PDUs. Adjacencies are formed by exchanging PDUs called Hello. Once routers become adjacent, they exchange topology information using link state PDUs (LSPs). Routers can establish adjacency only on the same level. A router can be of type level-1-2 , and such a router can form an adjacency with a level-1 router or a level-2-only router. Furthermore, a level-1-2 router can have level-1 adjacencies or level-2-only adjacencies. The topology databases for L1 and L2 remain separate, and the L2 and L1 routing remains separate when the router is an L1-L2 IS-IS router.
Run the show isis adjacency command to verify that every router builds an adjacency with its neighbors.
The output of the show isis adjacency command displays the following:
- System ID of the neighbor
- Interface of the neighbor that is connected on
- State of the adjacency (up, down, init)
If the expected adjacencies do not appear in the output, the problem is most likely with the IS-IS configuration on one of the devices. Correcting configuration mismatches between nodes usually solves adjacency problems. When examining adjacencies, check for the following common configuration issues.
|
Issue |
Checked |
|---|---|
|
1. Mismatched Level 1 and Level 2 interfaces. Are the routers configured for a common routing area? When both sides do not agree that they are members of a common area, there will be no IS-IS adjacency. See Section 2.2.1. |
|
|
2. Misconfigured NSAPs . See Section 2.2.2. |
|
|
Are you logging duplicate address errors? Use the show log command to detect this problem. See Section 2.2.3. |
|
|
4. Misconfigured IP addresses and Subnets. Are the corresponding interfaces in the same IP subnet? See Section 2.2.4. |
|
|
The adjacency will be stuck in the INIT state when only one side is enabled for authentication, or the authentication type is not the same: (simple or HMAC-MD5). When authentication is enabled, make sure the authentication configuration matches both endpoints. See Section 2.2.5. |
|
|
6. Is the interface added to the router IS-IS configuration on each node? |
|
|
7. Are the corresponding interfaces configured for the same routing level: L1, L2 or both? |
|
|
8. Is the basic configuration correct? Make sure the MTU setting matches both endpoints. |
For more detailed information about how to troubleshoot IS-IS adjacency issues, see Check for IS-IS Adjacency Formation Problems in Section 2.
This section contains the following sections:
1.9.1 Verify IS-IS Adjacency
Run the show isis adjacency command to verify that you have established adjacency with your neighbors. The configuration on both end points (interface type is point-to-point or broadcast) must match each other; otherwise, you will not be able to form an adjacency. This is a common issue. For information about interface types, see Section 2.
The following output for the show isis adjacency command shows an adjacency that is Up from rock1200 to jazz. You can also use the following syntax to display IS-IS adjacency information for a specific interface: show isis adjacency interface if-name.
[local]rock1200# show isis adjacency IS-IS Adjacenc(ies) for tag rock1200: SystemId Interface L MT Stat Hold SNPA Uptime jazz to_jazz 2 U Up 23 0030.8803.a7f8 01:15:25 jazz to_jazz 1 U Up 22 0030.8803.a7f8 01:15:25
The outputs of the show isis adjacency command from router rock1200 indicates it has formed only 1 and 2 adjacencies with the router to_jazz as expected. If no adjacency is formed, the CLI will display no output.
If you find an issue, run the following debug commands to isolate the fault.
Before you issue these commands, make sure you first check you logs. We highly recommend that you issue these commands during a maintenance window.
- debug isis adjacency interface if-name
- debug isis hello-packets
| Caution! | ||
|
Risk of performance loss. Enabling the generation of debug messages
can severely affect system performance. To reduce the risk, exercise
caution when enabling the generation of debug messages on a production
system.
| ||
1.9.2 Display Detailed IS-IS Adjacency Information
Run the show isis adjacency detail command to display detailed IS-IS adjacency information. In the following output the to_jazz interface is Up and is working correctly.
The most common issues to look for in the output of this command are mismatched IP Subnents. It sometimes has to be; for example, /30 on all routers. It cannot be /24 and /30.
For more information about this topic, see Misconfigured IP addresses and Subnets in Section 2.2.4.
[local]rock1200#show isis adjacency detail IS-IS Adjacenc(ies) for tag rock1200: SystemId Interface L MT Stat Hold SNPA Uptime jazz to_jazz 2 U Up 28 0030.8803.a7f8 01:15:58 Area Address(es): 49.0001 IP Address(es): 192.168.1.2 BFD state N/A neighbor IIH current seq 459, total iih pkt miss 0 adj nh-id 8 GR enabled state fresh jazz to_jazz 1 U Up 22 0030.8803.a7f8 01:15:58 Area Address(es): 49.0001 IP Address(es): 192.168.1.2 BFD state N/A neighbor IIH current seq 460, total iih pkt miss 0 adj nh-id 7 GR enabled state fresh Total IS-IS Adjacenc(ies): 2
1.9.3 Verify Connectivity
Run the ping and traceroute commands to verify interface connectivity to the adjacent router.
The following example pings and traceroutes the jazz router.
[local]rock1200#ping 10.18.17.102 PING 10.18.17.102 (10.18.17.102): source 10.18.17.103, 36 data bytes, timeout is 1 second !!!!! <<-- Indicates a successful ping. ----10.18.17.102 PING Statistics---- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.427/0.746/1.895/0.643 ms [local]rock1200#traceroute 10.18.17.102 se_traceroute to 10.18.17.102 (10.18.17.102), 30 hops max, 40 byte packets 1 10.18.17.102 (10.18.17.102) 2.635 ms 1.303 ms 1.204 ms
1.10 Step 6: Log Adjacency Changes
Run the show isis adj-log command to view adjacency logs. For more information about how to troubleshoot IS-IS adjacency issues, see Check for IS-IS Adjacency Formation Problems in Section 2.
This section contains the following sections
1.10.1 Display Adjacency Logs
The following example shows you how to display IS-IS adjacency logs.
[local]rock1200#show isis adj-log IS-IS tag rock1200 Adjacency log on last event of each interface: Interface Type State Adjs NeighborID L Time MT Last-Action to_jazz lan Up 3 jazz 2 01:19:16 U adj is up
1.10.2 Display Adjacency Log on the Interface
The following example shows you how to display an IS-IS adjacency log for a specific interface: rock1200.
[local]jazz#show isis adj-log is rock1200
IS-IS tag jazz Adjacency log on interfaces of neighbor rock1200:
Interface Type State Adjs NeighborID L Time MT Action
to_rock1200 lan Up 3 rock1200 2 02:49:46 U adj is up
Up 2 rock1200 1 02:49:46 U adj is up
1.11 Step 7: Verify Routing Instance
Run the show isis protocol-summary [ l1 | l2 | level-1 | level-2 ] command to display IS-IS protocol summary information. Verify that the IS-IS topology is correctly reflecting your network. If it does not, check your IS-IS configuration and use the commands after this section to investigate IS-IS.
The output of this command displays the following:
- Adj
- Area
- Counts
- SPF
- Graceful restart. When enabled, look at the output and see if the IS-IS instance is ready for a graceful restart.
- Fast convergence
- Interface
- The SPF delay interval and maximum SPF counts. Compare this information with the configuration by running the show configuration isis command.
- Note:
- Make sure you there is no configuration mismatch at the router isis and interface level. The default value for these levels is L1-L2. The follow example shows the correct level match.
context Rb-1 ! router isis 1 net 49.0001.0000.1111.1111.00 net 47.0001.0000.1111.1111.00 net 43.0002.0000.1111.1111.00 net 43.0001.0000.1111.1111.00 is type level-1-2 . . . ! interface Rb-1 circuit type level-1-2
The following example shows that the router rock1200 runs level 1 and level 2 with a wide metric style.
[local]rock1200#show isis protocol-summary
--- ISIS Instance: jazz / systemID: 0000.0000.0000 ---
Area , level-1-2,
metric wide-only, distance 115, topo ucast
Lsp Route isis total 0. level-1 0, level-2 0, interface route 0
SPF L1 holddown 5, interval 10
L2 holddown 5, interval 10
fast-convergence: enabled spf-delay-interval: 100ms max-spf-count: 3
Adj total 0, L1-LAN 0, L2-LAN 0, p2p 0
Intf total 0, LAN 0, p2p 0
GR Enabled
Time router uptime 02w05d01, instance uptime 01:19:06
--- ISIS Instance: rock1200 / systemID: cafe.3088.0417(rock1200) ---
Area 49.0001, level-1-2, metric wide-only, distance 115, topo ucast
Lsp L1 total 3, pnode 1. local lsp total 2, pnode 1
L2 total 3, pnode 1. local lsp total 2, pnode 1
Route isis total 2. level-1 2, level-2 0, interface route 1
SPF L1 holddown 5, interval 10
last time 00:03:32.327(periodic), duration 1, nodes 3, routes 2
L2 holddown 5, interval 10
last time 00:01:26.432(periodic), duration 0, nodes 3, routes 0
fast-convergence: enabled spf-delay-interval: 100ms max-spf-count: 3
Adj total 2, L1-LAN 1, L2-LAN 1, p2p 0
last uptime 01:21:48, on intf to_jazz,
neighbor cafe.3088.0015(jazz)
Intf total 1, LAN 1, p2p 0
GR Enabled
Time instance uptime 04d03h09
1.12 Step 8: Verify IS-IS Routers in the IS-IS Network
Run the show isis topology command to display which routers are participating in the IS-IS network. Verify that the expected topology appears in the output. This command is very useful for troubleshooting routing problems. This command displays the following information:
|
Field |
Description |
|
System |
The distance metric to reach the system. |
|
Distance |
The number of IP prefixes advertised by the system. |
|
Route |
The number of IP prefixes advertised by the system. |
|
IS |
The neighbors advertised by system. |
|
Next-Hop |
Next-hop router to reach the system. |
|
Interface |
The interface used to reach the system. |
|
IP Gateway |
The next hop IP address to reach the system. |
The show isis topology command has the following options:
|
Keyword |
Description |
|
l1 |
Optional. Displays only IS-IS level 1 protocol summary information. |
|
l2 |
Optional. Displays only IS-IS level 2 protocol summary information. |
|
level-1 |
Optional. Displays only IS-IS level 1 protocol summary information. |
|
level-2 |
Optional. Displays only IS-IS level 2 protocol summary information. |
[local]rock1200#show isis topology IS-IS ipv4 unicast topology for tag rock1200: System Distance Route IS Next-Hop Interface IP-Gateway jazz 10 2 0 jazz to_jazz 192.168.1.2 rock1200 0 2 1 Total level-1 IS-IS systems: 2 IS-IS ipv4 unicast topology for tag rock1200: System Distance Route IS Next-Hop Interface IP-Gateway jazz 10 2 0 jazz to_jazz 192.168.1.2 rock1200 0 2 1 Total level-2 IS-IS systems: 2
1.13 Step 9: Verify IP Routes
This section describes the various commands to verify the route tables and IS-IS route information in them. These commands are context-specific.
This section contains the following sections:
1.13.1 Step A: Verify the Active Routes in the RIB Table
Run the show ip route command to view the active (best) routes in the RIB table. To view a specific address, specify the network prefix by using the ip-addr/prefix-length construct.
The following output shows an IS-IS entry identified by the type value "i". The network 5.5.5.2/30, level 1 (L1) , is reachable by the next hop 192.168.1.2, using the to_jazz interface.
[local]rock1200#show ip route
Codes: C - connected, S - static, S dv - dvsr, R - RIP, e B - EBGP, i B - IBGP
O - OSPF, O3 - OSPFv3, IA - OSPF(v3) inter-area,
N1 - OSPF(v3) NSSA external type 1, N2 - OSPF(v3) NSSA external type 2
E1 - OSPF(v3) external type 1, E2 - OSPF(v3) external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, N - NAT
IPH - IP Host, SUB A - Subscriber address, SUB S - Subscriber static
SUB N - Subscriber ND, SUB D - Subscriber DHCP-PD
M F - Mobile Sub Foreign Agent, M H - Mobile Sub Home Agent
M G - Mobile Sub GTP
A - Derived Default, MeH - Media Nexthop
> - Active Route, * - LSP
Type Network Next Hop Dist Metric UpTime Interface
> i L1 5.5.5.2/30 192.168.1.2 115 11 01:21:24 to_jazz
> C 10.18.17.0/24 0 0 2w5d mgmt
> S 155.53.0.0/16 10.18.17.254 1 0 3d23h mgmt
> C 192.168.1.0/24
1.13.2 Step B: Verify All Routes Stored in the RIB Table
Run the show ip route all command to view all the routes stored in the RIB table from all the routing protocols.
The following example displays the routes stored in the RIB on router rock1200.
local]rock1200#show ip route all
Codes: C - connected, S - static, S dv - dvsr, R - RIP, e B - EBGP, i B - IBGP
A,H - derived hidden
O - OSPF, O3 - OSPFv3, IA - OSPF(v3) inter-area,
N1 - OSPF(v3) NSSA external type 1, N2 - OSPF(v3) NSSA external type 2
E1 - OSPF(v3) external type 1, E2 - OSPF(v3) external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, N - NAT
IPH - IP Host, SUB A - Subscriber address, SUB S - Subscriber static
SUB N - Subscriber ND, SUB D - Subscriber DHCP-PD
M F - Mobile Sub Foreign Agent, M H - Mobile Sub Home Agent
M G - Mobile Sub GTP
A - Derived Default, MeH - Media Nexthop
> - Active Route, * - LSP
Type Network Next Hop Dist Metric UpTime Interface
> i L1 5.5.5.2/30 192.168.1.2 115 11 01:23:53 to_jazz
> C 10.18.17.0/24 0 0 2w5d mgmt
> C H 10.18.17.0/32 0 0 2w5d mgmt
> C H 10.18.17.103/32 0 0 2w5d mgmt
> A H 10.18.17.254/32 10.18.17.254 254 0 3d23h mgmt
> C H 10.18.17.255/32 0 0 2w5d mgmt
> S 155.53.0.0/16 10.18.17.254 1 0 3d23h mgmt
> C 192.168.1.0/24 0 0 01:26:47 to_jazz
> C H 192.168.1.0/32 0 0 01:26:47 to_jazz
> C H 192.168.1.1/32 0 0 01:26:47 to_jazz
> A H 192.168.1.2/32 192.168.1.2 254 0 01:26:44 to_jazz
> C H 192.168.1.255/32 0 0 01:26:47 to_jazz1.14 Step 10: Check IS-IS Routes
This section contains the following sections:
- Step A: View IS-IS Routes
- Step B: View a Specific IS-IS Route Entry
- Step C: View IS-IS Route Entries In the RIB
1.14.1 Step A: Verify IS-IS Routes
Run the show isis routes command to verify active IS-IS routes.
Table 5 describes the output fields for the show isis routes command by using the ip-addr/prefix-length construct.
|
Field |
Description |
|---|---|
|
Prefix |
IP prefix. |
|
L |
IS-IS level. |
|
Metric |
Cost to reach this prefix. |
|
Interface |
Interface used to reach this prefix. |
|
Nexthop |
IP nexthop used to reach this prefix. |
|
Context |
Name of context |
Table 6 describes the output fields for the show isis routes summary command.
|
Field |
Description |
|---|---|
|
Route Type |
Route type. The route type can be
|
|
Level-1 |
Number of routes, per route type, in level 1 area. |
|
Level-2 |
Number of routes, per route type, in level 2 domain. |
|
Summarize (L1/L2) |
Number of routes, per route type, that are summarized in each level. The x/y output (for example, 0/1) indicates number of routes summarized in Level 1/ number of routes summarized in Level 2. |
|
L2-to-L1 Leak |
Number of IS-IS routes distributed from level 2 to level 1. These routes are not leaded on this system, but are leaked from level 2 into level 1 from other systems. |
[local]rock1200#show isis routes IS-IS IP route(s) for tag rock1200 Prefix Nexthop L Metric Interface Context 5.5.5.2/30 192.168.1.2 1 11 to_jazz 192.168.1.0/24 0.0.0.0 1 10 to_jazz Total IS-IS Route(s) for tag rock1200: 2 [local]rock1200#show isis routes summary IS-IS route(s) summary for tag jazz: Route Type Level-1 Level-2 Summarize(L1/L2) L2-to-L1 Leak IS-IS Route 0 0 - 0 Redistribute 0 0 0/0 Inter-area 0 0 0/0 Summary Address 0 0 0/0 IS-IS route(s) summary for tag rock1200: Route Type Level-1 Level-2 Summarize(L1/L2) L2-to-L1 Leak IS-IS Route 2 0 - 0 Redistribute 0 0 0/0 Inter-area 0 2 0/0 Summary Address 0 0 0/0 IS-IS interface routes: 1
1.14.2 Step B: Verify IS-IS Route Entries In the RIB
Run the show ip route isis command to view all IS-IS route entries in the RIB table (both active and standby paths).
[local]rock1200#show ip route isis
Codes: C - connected, S - static, S dv - dvsr, R - RIP, e B - EBGP, i B - IBGP
A,H - derived hidden
O - OSPF, O3 - OSPFv3, IA - OSPF(v3) inter-area,
N1 - OSPF(v3) NSSA external type 1, N2 - OSPF(v3) NSSA external type 2
E1 - OSPF(v3) external type 1, E2 - OSPF(v3) external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, N - NAT
IPH - IP Host, SUB A - Subscriber address, SUB S - Subscriber static
SUB N - Subscriber ND, SUB D - Subscriber DHCP-PD
M F - Mobile Sub Foreign Agent, M H - Mobile Sub Home Agent
M G - Mobile Sub GTP
A - Derived Default, MeH - Media Nexthop
> - Active Route, * - LSP
Type Network Next Hop Dist Metric UpTime Interface
> i L1 5.5.5.2/30 192.168.1.2 115 11 00:21:18 to_jazz
1.14.3 Step C: View a Specific IS-IS Route Entry
Run the show isis route address command to view a specific IS-IS route path and hops taken in the IS-IS route table.
[local]rock1200#show isis route 192.168.1.2 IS-IS prefix for tag rock1200: Prefix Nexthop Level Metric Interface 192.168.1.0/24 0.0.0.0 1 10 Is sourced from LSP(s): LSP ID Seq # System Name Arrive(ago) Interface(from) cafe.3088.0417.00-00 0x1ad rock1200
1.15 Step 11: Verify LSPs in IS-IS Database
Each IS-IS router builds and maintains a network topology database called a link state database. Each IS-IS router in the LAN calculates optimum routes to all destinations by using its link state database combined with the Shortest Path First (SPF) algorithm. SmartEdge® routers running the IS-IS protocol learn network topology by using the IS-IS database.
Since IS-IS is a link state protocol, the link state database must be the same for any router in the same area. Exactly the same database content is critical for the routing decision process. Incomplete database results in an incomplete network view and as a result, routing problems.
If you have routing problems, make sure your interfaces are correctly configured and make sure the SPF have the required LSPs.
Link State PDUs (LSPs) provide the following information:
- Knowledge of other routers present in the area
- Knowledge of networks connected to the above routers
IS-IS uses a designated router (DIS), a “virtual router called a pseudonode representing a LAN network, which sends LSPs on behalf of the LAN. All LAN routers (including DIS) report connectivity to only the pseudonode instead of each node in an a LAN (instead of an area).
An asterisk (*) in the show isis database output following the LSP ID indicates that the LSP is originated by the router on which the database is being observed.
In the AT/OL (Attached /Overload bit) column, verify that the value of each LSP is correct. AT means that the router has at least one interface to an L2 area. OL means the router is overloaded and has requested to be removed from the routes from other routers; for example, restarting.
- Attached Bit–Routers in an IS-IS L1 area exchange information within the L1 area. For IP destinations not found in the prefixes in the L1 database, the L1 router must forward packets to the nearest router that is in both IS-IS L1 and L2 with the attached bit set in its L1 LSP. A zero value (0) indicates the attachment is not set. 1 indicates the attachment is set (that router is attached to the backbone).
- Overload bit–The overload bit is used to exclude Level 1-2 router from transit Level 2 routing. The Level 1-2 router will only route traffic from or into a Level 1 area. Other Level 2 routers will exclude its from shortest path calculations – Temporarily exclude router from Level 2 routing when it boots up while waiting for BGP to synchronize (when IS-IS is used as IGP for iBGP network). A zero value (0) indicates the overload bit is not set. 1 indicates the overload bit is set.
A sequence number that is significantly higher than the sequence numbers of other LSPs might indicate instability either within the area or on the level 2 backbone. Another indication of instability is an LSP hold timer that never becomes too small.
The LSP ID identifies the originating router. It contains the following components:
- System ID–Represents the originating router NSAP address.
- Pseudonode ID–A zero (0) ID indicates a router LSP, non-zero ID indicates a pseudonode, representing a LAN.
- LSP number–LSP fragment number. If the LSPs are greater than 1492 bytes (if the default is used), the IS-IS protocol fragments them to the configured MTU sizes.
|
Field |
Description |
|---|---|
|
LSP ID |
Link state protocol data unit (LSP) ID that advertised this prefix. |
|
Seq # |
Sequence number of the LSP. |
|
System Name |
Router that advertised the LSP and prefix. |
|
Arrive |
Last time the system received this LSP. |
|
Interface |
Interface from which the last LSP arrived. |
If the neighbor has LSP-00 in the output), the neighbor is not reachable. To view routes, run the show isis database detail command.
The following example does not match the sample IS-IS topology.
Figure 3 LSP ID
Run the show isis database command to display a summary of the link-state database and verify that the pseduonodes are present (knowledge of other routers present in the area). Inspecting the LSP contents can help you diagnose routing advertising problems. To view detailed information, use the detailed keyword. For information about how to troubleshoot route advertisement problems, see Section 2.3.1.
|
instance-name |
Optional. IS-IS instance name. Displays database information only for the specified instance. |
|
detail |
Optional. Displays the content of each link-state protocol data unit (LSP). |
|
extensive |
Optional. Displays the context of each LSP and traffic engineering (TE) sub type-length-value (TLV) object for extended IS reachability TLVs. |
|
level-1 |
Optional. Displays the link-state database for level 1 only. |
|
level-2 |
Optional. Displays the link-state database for level 2 only. |
|
lsp-id |
LSP ID in the format nnnn.nnnn.nnnn.xx-yy. Displays only information pertaining to the specified LSP. Use this keyword to the LSPs of the border routers to verify external reachablity information reaches the LSPs correctly. |
|
sys-id |
IS-IS system ID in the format nnnn.nnnn.nnnn. Displays only information pertaining to all LSP IDs for the specified IS-IS system. |
For more information about verifying LSPs in the IS-IS database, see Check for Route Flaps or Unstable IS-IS Routes in Section 2.3.3.
The show isis database command output in the following example shows that router rock1200 has both a level 1 and level 2 link-state database, indicating that the router is an L1 and L2 router. To determine if you have the latest version of the LSPs, check the sequence number associated with the LSP in the show isis database output. On each node, verify that each node IS-IS database has synchronized this information to ensure that each router has the same view of your network.
[local]rock1200#show isis database detail IS-IS level 1 link-state database for tag rock1200: LSPID Sequence Checksum Holdtime AT/OL Len jazz.00-00 0x1c1 0xb1f 438 0/0 92 Area Address: 49.0001 NLPID: IP Hostname: jazz IP Address: 5.5.5.2 M-Topology: Metric: 10 IS-Extended rock1200.01 <<-- Make sure the metric has the expected value. Metric: 10 IP 192.168.1.0/24 Metric: 1 IP 5.5.5.2/30 <<--Make sure the router (in this example, the jazz router) is correctly advertising its route. If not, validate your configuration (by using the show configuration isis command) and check if there is network outage. rock1200.00-00* 0x1ad 0xb730 807 0/0 85 Area Address: 49.0001 NLPID: IP Hostname: rock1200 IP Address: 192.168.1.1 M-Topology: Metric: 10 IS-Extended rock1200.01 Metric: 10 IP 192.168.1.0/24 rock1200.01-00* 0x62 0x6222 807 0/0 53 Metric: 0 IS-Extended rock1200.00 Metric: 0 IS-Extended jazz.00 Total IS-IS LSP(s) for tag rock1200 in Level-1: 3 IS-IS level 2 link-state database for tag rock1200: LSPID Sequence Checksum Holdtime AT/OL Len jazz.00-00 0x1c0 0xd1e 749 0/0 92 Area Address: 49.0001 NLPID: IP Hostname: jazz IP Address: 5.5.5.2 M-Topology: Metric: 10 IS-Extended rock1200.01 Metric: 10 IP 192.168.1.0/24 Metric: 1 IP 5.5.5.2/30 rock1200.00-00* 0x1ae 0x318 949 0/0 96 Area Address: 49.00de NLPID: IP Hostname: rock1200 IP Address: 192.168.1.1 M-Topology: Metric: 10 IS-Extended rock1200.01 Metric: 10 IP 192.168.1.0/24 Metric: 11 IP 5.5.5.2/30 rock1200.01-00* 0x63 0x6023 949 0/0 53 Metric: 0 IS-Extended rock1200.00 Metric: 0 IS-Extended jazz.00 Total IS-IS LSP(s) for tag rock1200 in Level-2: 3
1.16 Step 12: Check IS-IS Statistics
Run the show isis [instance-name] statistics [detail] command to verify IS-IS traffic.
When the number of processed PDUs is less than the number of received PDUs, the result might indicate that the router has a problem processing PDUs. Run the show process command to verify this and try to isolate the process that is using the CPU. In the Drop column, check for drop packets.
Run the show port counters detail command to check the interface counters. For more information about this command, see the General Troubleshooting Guide.
The following example displays output from the show isis statistics command:
[local]rock1200#show isis statistics
IS-IS Router tag rock1200:
System Id: rock1200 Type: L1 SPF runs: 426
PDU Type Received Processed Drops Sent
LSP 104 104 0 201
IIH 35305 8452 26853 36022
CSNP 0 0 0 8838
PSNP 0 0 0 0
Type: L2 SPF runs: 430
PDU Type Received Processed Drops Sent
LSP 105 105 0 204
IIH 34437 8445 25992 35995
CSNP 0 0 0 8838
PSNP 0 0 0 0
Total 69951 17106 52845 90098
Total Received: 69951; Total Sent: 90098
1.17 Step 13: Examine the IS-IS SPF Log
Run the show isis spf-log command to verify that the SPF ran and investigate network instabilities. The SPF log includes a description of what triggered SPF recalculations. For example, when a new LSP has arrived and a new area has come up. This command provides an information on which LSPs are changing the most frequently and what is triggering the SPF calculations.
- Note:
- If the SPF log is not running as expected, check the following
SPF scheduling configuration parameters:
- fast-convergence
- holddown
- interval
To further investigate the SPF recalculation, run the following commands:
- debug isis spf-triggers—Displays events that trigger an SPF calculation
- debug isis spf-event—Displays detailed information of SPF calculations caused by the triggering event.
Before you issue the debug commands, make sure you first check your logs. We highly recommend that you issue these commands during a maintenance window.
| Caution! | ||
|
Risk of performance loss. Enabling the generation of debug messages
can severely affect system performance. To reduce the risk, exercise
caution when enabling the generation of debug messages on a production
system.
| ||
Table 8 describes the output fields for the show isis spf-log command.
|
Field |
Description |
|---|---|
|
When |
Time elapsed since the last SPF calculation took place. |
|
Duration |
Duration, in milliseconds, of an SPF calculation. |
|
Nodes |
Number of nodes involved in an SPF calculation. |
|
Count |
Number of times an SPF calculation was initiated. |
|
Routes |
Number of routes involved in an SPF calculation. |
|
Last Trigger LSP |
LSP ID that initiated the last SPF calculation. |
|
Reasons |
Reason for the last SPF calculation; see Table 9 for a list of explanations. |
Table 9 describes the reasons and explanations for the show isis spf-log SPF recalculation. Use this table with the results of the output to isolate the fault.
|
Reason ID |
Explanation |
|---|---|
|
ADMINDIST |
The administrative distance was reconfigured. |
|
AREASET |
A set of areas was changed. |
|
ATTACHFLAG |
A Level 2 attachment has changed. |
|
DISELECT |
Designated IS (DIS) election was rerun. |
|
IPRTLEAK |
Routes were leaked between levels. |
|
LOSTADJ |
Adjacency has been lost. For information about how to troubleshooting adjacencies, see Section 1.9 and Section 2.2. |
|
LSPHEADER |
An LSP header has changed. |
|
NEWADJ |
A new neighbor has come up. |
|
NEWAREA |
A new area has come up. |
|
NEWLSP |
A new LSP has arrived. |
|
NEWMETRIC |
A metric has changed. |
|
OVLD |
Overload. |
|
PERIODIC REDIST |
An internal LSP has been regenerated. |
|
PREFIX |
An SPF prefix has changed. |
|
PURGELSP |
An LSP was purged. |
|
REDIST |
A route was redistributed. |
|
RTCLEARED |
Routes were manually cleared. |
|
TLVCONTENT |
The content of an LSP changed. |
|
TLVROUTES |
An LSP route changed. |
|
ADJNEXTHOP |
A new next hop was added. |
|
USERTRIG |
The SPD recalculation was triggered by the user. |
|
TOPOCHG |
The network topology changed. |
|
SYSCHG |
The system ID changed. |
The following example shows the results of the show isis spf-log command.
[local]rock1200#show isis spf-log
IS-IS tag rock1200 level 1 SPF ipv4(unicast)log:
When Duration Nodes Count Routes Last Trigger LSP Reasons
00:13:33.237 0 3 2 2 rock1200.01-00 PERIODIC (12)
02:58:14.016 0 3 1 2 jazz.00-00 TLVROUTES
02:58:24.021 1 3 1 1 jazz.00-00 TLVROUTES
02:59:15.132 1 3 2 1 jazz.00-00 TLVCONTENT
02:59:25.144 0 2 2 1 jazz.00-00 NEWLSP
02:59:35.074 1 2 2 1 rock1200.00-00 DISELECT
LOSTADJ
NEWADJ
PREFIX
REDIST
03:01:07.412 1 1 1 1 rock1200.00-00 PREFIX
03:09:37.461 0 1 1 1 rock1200.00-00 PERIODIC
(298)
03d03h47 1 1 1 1 jazz.00-00 PURGELSP
03d03h51 0 1 1 1 rock1200.00-00 PERIODIC
03d03h53 1 1 2 1 rock1200.01-00 LOSTADJ
NEWLSP
03d03h54 1 3 1 1 rock1200.00-00 PREFIX
03d04h05 0 3 2 1 rock1200.01-00 PERIODIC (88)
04d01h27 0 3 2 1 jazz.00-00 TLVCONTENT
04d01h27 1 2 2 1 jazz.00-00 NEWLSP
04d01h27 0 2 2 1 rock1200.00-00 DISELECT
LOSTADJ
NEWADJ
PREFIX
REDIST
04d01h37 1 1 1 1 rock1200.00-00 PERIODIC (12)
04d04h25 1 1 1 1 jazz.00-00 PURGELSP
04d04h31 0 1 1 1 rock1200.00-00 PERIODIC
04d04h40 0 1 2 1 rock1200.01-00 LOSTADJ
NEWLSP
- Note:
- When you see "lost adjacency messages" LOSTADJ in the SPF log, see Section 1.9 and Section 2.2.
IS-IS tag rock1200 level 2 SPF ipv4(unicast)log:
When Duration Nodes Count Routes Last Trigger LSP Reasons
00:11:41.420 0 3 2 0 rock1200.01-00 PERIODIC (12)
02:58:06.953 0 3 1 0 rock1200.00-00 REDIST
02:58:14.053 0 3 1 0 jazz.00-00 TLVROUTES
02:58:24.059 0 3 1 0 jazz.00-00 TLVROUTES
02:59:15.170 0 3 2 0 jazz.00-00 TLVCONTENT
02:59:25.181 0 2 2 0 jazz.00-00 NEWLSP
02:59:29.252 1 2 1 0 rock1200.01-00 DISELECT
LOSTADJ
NEWADJ
02:59:35.112 0 1 1 0 rock1200.00-00 NEWADJ
PREFIX
REDIST
03:01:07.449 0 1 1 0 rock1200.00-00 PREFIX
03:06:42.632 0 1 1 0 rock1200.00-00 PERIODIC
(298)
03d03h34 1 1 1 0 jazz.00-00 PURGELSP
03d03h42 0 1 1 0 rock1200.00-00 PERIODIC
03d03h53 0 1 3 0 rock1200.01-00 LOSTADJ
NEWLSP
PURGELSP
03d03h54 0 3 1 0 rock1200.00-00 AREASET
PREFIX
03d03h57 0 3 2 0 rock1200.01-00 PERIODIC (89)
04d01h27 1 3 2 0 jazz.00-00 TLVCONTENT
04d01h27 0 2 2 0 jazz.00-00 NEWLSP
04d01h27 0 2 1 0 rock1200.01-00 DISELECT
LOSTADJ
NEWADJ
04d01h27 0 1 1 0 rock1200.00-00 NEWADJ
PREFIX
098
1.18 Step 14: Monitor IS-IS Events
Run the monitor isis commands to monitor IS-IS events in real-time. These commands are useful for troubleshooting intermittent issues.
|
Command |
Description |
|---|---|
|
monitor isis adjacency [detail] |
Displays continuously updated information about IS-IS neighbors. |
|
monitor isis interfaces [if-name][detail] |
Displays continuously updated information about IS-IS interfaces. |
|
monitor isis statistics [detail] |
Displays continuously updated information about IS-IS traffic statistics. |
1.18.1 Monitor IS-IS Adjacency
Run the monitor isis adjacency to display continuously updated information about IS-IS neighbors.
Table 11 describes the output fields for the monitor isis adjacency command.
|
Field |
Description |
|---|---|
|
SystemId |
ID of an IS-IS in an area. |
|
Interface |
Interface advertising the IS-IS. |
|
L |
Level 1 routing only (1), level 2 routing only (2), or levels 1 and 2 (3) routing. |
|
MT |
Multi-topology. Indicates whether each IS-IS instance performs unicast (U), multicast (M), or unicast and multicast (UM) topology-based routing. Displays no value when the default routing topology, unicast, is used. |
|
State |
IS-IS adjacency state. |
|
Holdtime |
Amount of time, in seconds, before an adjacency timeout occurs. |
|
SNPA |
Subnetwork Point of Attachment (SNPA) or the data-link address of the remote system. |
|
Uptime |
Amount of time that the adjacency has been up. |
[local]rock1200#monitor isis adjacency IS-IS Adjacenc(ies) for tag rock1200: SystemId Interface L MT Stat Hold SNPA Uptime jazz to_jazz 2 U Up 29 0030.8803.a7f8 01:45:26 jazz to_jazz 1 U Up 29 0030.8803.a7f8 01:45:26 Total IS-IS Adjacenc(ies): 2
1.18.2 Monitor IS-IS Interfaces
Run the monitor isis interface command to display continuously updated information about IS-IS interfaces.
Table 12 describes the output fields for the monitor isis interface command.
|
Field |
Description |
|---|---|
|
Interface |
Interface advertising the IS-IS. |
|
L |
Level 1 routing only (1), level 2 routing only (2), or levels 1 and 2 (3) routing. |
|
MT |
Multi-topology. Indicates whether each IS-IS instance performs unicast (U), multicast (M), or unicast and multicast (UM) topology-based routing. Displays no value when the default routing topology, unicast, is used. |
|
State |
IS-IS adjacency state. |
|
Level-1-DR |
IS-IS level 1 designated router (DR) for the interface. |
|
Level-2-DR |
IS-IS level 1 designated router (DR) for the interface. |
|
Metric |
Routing metric. A value inside the brackets is a multicast metric, and a value without brackets, or outside the brackets, is a unicast metric. |
[local]rock1200#monitor isis interfaces monitor isis interfaces: IS-IS interface(s) for tag rock1200: Interface L MT Stat Level-1-DR Level-2-DR Metric to_jazz 3 U Up rock1200.01 rock1200.01 10 Total IS-IS Interface(s): 1 % enter ctrl-C to exit monitor mode, monitor duration(sec): 600 (00:00:21)
1.18.3 Monitor IS-IS Statistics
Run the monitor isis statistics to display display continuously updated information about IS-IS traffic statistics.
Make sure the Sent and Received columns are incrementing. In the Drop column, check for drop packets.
[local]rock1200#monitor isis statistics
monitor isis statistics:
IS-IS Router tag rock1200:
System Id: rock1200 Type: L1 SPF runs: 427
PDU Type Received Processed Drops Sent
LSP 104 104 0 203
IIH 35346 8493 26853 36065
CSNP 0 0 0 8883
PSNP 0 0 0 0
Type: L2 SPF runs: 430
PDU Type Received Processed Drops Sent
LSP 106 106 0 204
IIH 34480 8488 25992 36038
CSNP 0 0 0 8882
PSNP 0 0 0 0
Total 70036 17191 52845 90275
Total Received: 70036; Total Sent: 90275
% enter ctrl-C to exit monitor mode, monitor duration(sec): 600 (00:00:05)
1.19 Step 15: Debug IS-IS
1.19.1 Debug IS-IS Adjacency
Use the following commands to debug IS-IS.
Before you issue these commands, make sure you first check your logs. We highly recommend that you issue these commands during a maintenance window.
| Caution! | ||
|
Risk of performance loss. Enabling the generation of debug messages
can severely affect system performance. To reduce the risk, exercise
caution when enabling the generation of debug messages on a production
system.
| ||
|
Command |
Notes |
|---|---|
|
debug isis adjacency detail |
Debug IS-IS adjacency. |
|
debug isis hello-packets |
Debug IS-IS Hello packets. |
|
debug isis lsp packets [send | receive] |
Debug IS-IS LSP packets. Make sure the system is sending to the correct interface or circuit. If the packet is received and then rejected, verify that the packet was rejected for a legitimate reason. Was it a valid packet? |
|
debug isis bfd |
Debug IS-IS Bidirectional Forwarding Detection (BFD). |
|
debug isis graceful-restart |
Debug IS-IS graceful restart event messages. |
|
debug isis spf-events |
Debug to see the course of SPF calculation. |
1.19.1.1 Example: Debug IS-IS Adjacency
[local]rock1200#terminal monitor [local]rock1200#debug isis adjacency detail [local]rock1200#May 11 06:41:42: [0001]: %ISIS-7-ADJ: send L1 LAN IIH on intf to_jazz May 11 06:41:42: [0001]: %ISIS-7-ADJ_DET: send IIH pkt len 61, seq 27064, w/o auth May 11 06:41:46: [0001]: %ISIS-7-ADJ: rcvd L2 LAN IIH from 0030.8803.a7f8 seq 676 on intf to_jazz May 11 06:41:46: [0001]: %ISIS-7-ADJ_DET: find my mac in this LAN IIH, state is UP now May 11 06:41:48: [0001]: %ISIS-7-ADJ: send L2 LAN IIH on intf to_jazz <<--Interface to the jazz router May 11 06:41:48: [0001]: %ISIS-7-ADJ_DET: send IIH pkt len 61, seq 27052, w th May 11 06:41:48: [0001]: %ISIS-7-ADJ: rcvd L1 LAN IIH from 0030.8803.a7f8 seq 679 on intf to_jazz May 11 06:41:48: [0001]: %ISIS-7-ADJ_DET: find my mac in this LAN IIH, state is UP now May 11 06:41:50: [0001]: %ISIS-7-ADJ: send L1 LAN IIH on intf to_jazz May 11 06:41:50: [0001]: %ISIS-7-ADJ_DET: send IIH pkt len 61, seq 27065, w/o auth May 11 06:41:54: [0001]: %ISIS-7-ADJ: rcvd L2 LAN IIH from 0030.8803.a7f8 seq 677 on intf to_jazz May 11 06:41:54: [0001]: %ISIS-7-ADJ_DET: find my mac in this LAN IIH, state is UP now
1.19.1.2 Debug IS-IS Hello Packets
Check whether hello packets (IIH) are exchanged among your neighbors.
[local]rock1200#terminal monitor [local]rock1200#debug isis hello-packets [local]rock1200#May 11 06:46:27: [0001]: %ISIS-7-ADJPKT_SD: send L2 IIH Len: 61 HT: 30, IF:to_jazz IS:cafe.3088.0417 May 11 06:46:31: [0001]: %ISIS-7-ADJPKT_RV: recv L1 IIH Len: 61, HT: 30, IF:to_jazz IS:cafe.3088.0015 <<-IIH indicates IS-IS hello packet. May 11 06:46:32: [0001]: %ISIS-7-ADJPKT_SD: send L1 IIH Len: 61, HT: 30, IF:to_jazz IS:cafe.3088.0417 May 11 06:46:32: [0001]: %ISIS-7-ADJPKT_RV: recv L2 IIH Len: 61, HT: 30, IF:to_jazz IS:cafe.3088.0015 May 11 06:46:37: [0001]: %ISIS-7-ADJPKT_SD: send L2 IIH Len: 61, HT: 30, IF:to_jazz IS:cafe.3088.0417 May 11 06:46:40: [0001]: %ISIS-7-ADJPKT_SD: send L1 IIH Len: 61, HT: 30, IF:to_jazz IS:cafe.3088.0417 May 11 06:46:41: [0001]: %ISIS-7-ADJPKT_RV: recv L1 IIH Len: 61, HT: 30, IF:to_jazz IS:cafe.3088.0015 May 11 06:46:44: [0001]: %ISIS-7-ADJPKT_RV: recv L2 IIH Len: 61, HT: 30, IF:to_jazz IS:cafe.3088.0015 May 11 06:46:45: [0001]: %ISIS-7-ADJPKT_SD: send L2 IIH Len: 61, HT: 30, IF:to_jazz IS:cafe.3088.0417 May 11 06:46:48: [0001]: %ISIS-7-ADJPKT_SD: send L1 IIH Len: 61, HT: 30, IF:to_jazz IS:cafe.3088.0417 May 11 06:46:49: [0001]: %ISIS-7-ADJPKT_RV: recv L1 IIH Len: 61, HT: 30, IF:to_jazz IS:cafe.3088.0015
1.19.1.3 Debug IS-IS LSP Packets
[local]rock1200#debug isis lsp-packets send May 12 09:25:30: [0001]: %ISIS-7-LSPPKT_SD: send L1 LSP Len: 85, LSPID cafe.3088.0417.0000, LT: 1199, Seq 0x21c May 12 09:25:30: [0001]: %ISIS-7-LSPPKT_SD: sent L1 LSP cafe.3088.0417.0100 on lan intf to_jazz May 12 09:25:30: [0001]: %ISIS-7-LSPPKT_SD: send L1 LSP Len: 53, LSPID cafe.3088. 0417.0100, LT: 1199, Seq 0xd1 [local]rock1200#debug isis lsp-packets receive May 12 09:23:18: [0001]: %ISIS-7-LSPPKT_RV: rcvd L1 LSP on intf to_jazz len 92 May 12 09:23:18: [0001]: %ISIS-7-LSPPKT_RV: recv L1 LSP Len: 92, LSPID cafe.30 88.0015.0000, LT: 1199, Seq 0x230
2 Troubleshooting Specific Routing IS-IS Issues
This section describes how to troubleshoot common IS-IS routing problems in the following areas:
In the IS-IS protocol, there are two types of networks:
- point-to-point
- broadcast
Unlike Open Shortest Path First (OSPF) Protocol, the IS-IS protocol does not have other network types such as non-broadcast and point-to-multipoint. For each type of network, a different type of IS-IS Hello (IIH) packet is exchanged to establish adjacency. On point-to-point networks, point-to-point IIHs are exchanged; and on broadcast networks (such as LAN), Level 1 or Level 2 LAN IIHs are exchanged.
During normal operation, IS-IS routers form and maintain adjacencies with each other by using hello packets. Routing information is then exchanged by flooding LSPs, which are stored in appropriate link-state databases (Level 1 or Level 2). Sequence numbers describe the contents of the database (CSNP) and to request and acknowledge receipt of specific LSPs from your neighbors. Sequence number packets (CSNPs and PSNPs) provide control for the flooding process and ensure database synchronization. All these processes need to occur successfully to ensure accurate dissemination of routing information in the IS-IS domain. Any failures result in inconsistencies, which cause routing problems.
Use the following IS-IS flowchart as a guide to troubleshooting IS-IS problems.
Figure 4 IS-IS Troubleshooting Flowchart
- Note:
- IS-IS summarization and redistribution and suboptimal routing problems are beyond the scope of this document.
2.1 IS-IS Topology
Use the following IS-IS topology as a guide to troubleshooting specific IS-IS issues that follow in subsequent sections.
Figure 5 IS-IS Topology
2.2 Check for IS-IS Adjacency Formation Problems
Adjacency formation problems are common IS-IS failures. They mainly occur as a result of router misconfiguration, hardware and software failures, and interoperability problems between routers from different vendors.
This section describes how to troubleshoot the following adjacency problems:
- Mismatched Level 1 and Level 2 interfaces
- Misconfigured NSAPs
- Duplicate System IDs
- Misconfigured IP addresses and Subnets
- Mismatch Authentication
For more information about troubleshooting adjacencies, see Section 1.9.
2.2.1 Check for Mismatched Level 1 and Level 2 Interfaces
By default, SmartEdge routers run IS-IS Level 1-2. In this mode, a router can form both Level 1 and Level 2 adjacencies with neighbors in the same area and form only Level 2 adjacencies with neighbors in different areas.
To check for mismatched level 1 and level 2 interfaces, run the show configuration isis command or show isis interfaces detail command.
The following topology shows that R2 forms only a L2 adjacency with R3, which is in area 49.0002. The default Level 1-2 mode can be modified for all interfaces on the router by using the router isis command IS-type or for a specific interface with the interface-level configuration command circuit-type level [level-1 | level-2].
If R2 is misconfigured as a Level 1 only on 9/2 , R2 will not form an adjacency with R3. As a result, the domain is partitioned and there is no communication between area 49.0001 and area 49.0002.
Figure 6 Mismatched Level 1 and Level 2 Interface
2.2.1.1 Step 1: Check for IS-IS Configuration Issues
The following example shows where to check for mismatch interface levels.
[local]R2.17.145#show configuration isis Building configuration... Current configuration: context local ! router isis csc net 49.0001.0000.0000.0001.00 <<-by default, the SmartEdge router uses L1-L2 address-family ipv4 unicast ! interface 9/2 ! bind to ethernet 9/2 circuit type level-1 <<--Non default value. address-family ipv4 unicast ! [local]R3.16.121#show configuration isis Building configuration... Current configuration: context local ! router isis csc net 49.0002.0000.0000.0002.00<<- by default,the SmartEdge router uses L1-L2 address-family ipv4 unicast ! interface 10/10 ! bind to ethernet 10/10 <<-- by default, the SmartEdge router uses L1-L2 address-family ipv4 unicast ! interface loBB address-family ipv4 unicast ! end
2.2.1.2 Step 2: Check Adjacency
To verify adjacency formation, run the show isis adjacency command.
The following output indicates an adjacency has formed.
[local]R2.17.145#show isis adjacency IS-IS Adjacenc(ies) for tag csc: SystemId Interface L MT Stat Hold SNPA Uptime R3.16.121 9/2 2 U Init 20 0030.8802.1f44 00:00:00
The following output indicates no adjacency has formed. No output is displayed when there is no adjacency.
[local]R2.17.145#show isis adjacency <<--No output indicates that am adjacency has not been formed.
2.2.1.3 Step 3: Correct Mismatch Level Configuration
When two routers are within different areas, they must establish an L2 adjacency. Either both routers use L2, or one router uses L2 while the other router uses L1-L2.
When the two routers are within the same area, the routers can establish an L1-L2 or an L1|L2 adjacency, depending on the configured circuit type of the two connected interfaces. They could be one of the following area settings:
- L1 to L1
- L2 to L2
- L1 to L1|L2
- L2 to L1|L2
- L1|L2 to L1|L2
In the following example, the configuration has a mismatch circuit type. To resolve this issue, change router R2 interface 9/2 circuit type configuration to Level 2. The IS-IS L2 adjacency shows up when you run the show isis adjacency command.
[local]R2.17.145(config)#context local [local]R2.17.145(config-ctx)#router isis csc [local]R2.17.145(config-isis)#interface 9/2 [local]R2.17.145(config-isis-if)#circuit type level-2-only [local]R2.17.145(config-isis-if)#end [local]R2.17.145#show isis adjacency IS-IS Adjacenc(ies) for tag csc: SystemId Interface L MT Stat Hold SNPA Uptime R3.16.121 9/2 2 U Init 20 0030.8802.1f44 00:00:00 Total IS-IS Adjacenc(ies): 1 [local]R2.17.145#show isis adjacency IS-IS Adjacenc(ies) for tag csc: SystemId Interface L MT Stat Hold SNPA Uptime R3.16.121 9/2 2 U Up 26 0030.8802.1f44 00:00:03 Total IS-IS Adjacenc(ies): 1 [local]R2.17.145#show isis adjacency detail IS-IS Adjacenc(ies) for tag csc: SystemId Interface L MT Stat Hold SNPA Uptime R3.16.121 9/2 2 U Up 20 0030.8802.1f44 00:00:09 Area Address(es): 49.0002 IP Address(es): 200.1.1.2 BFD state N/A neighbor IIH current seq 69, total iih pkt miss 0 adj nh-id 9, neighbor sent re-start tlv Total IS-IS Adjacenc(ies): 1 [local]R2.17.145#
2.2.1.4 Example: Debug Adjacency
When you run the debug isis adjacency interface if-name command, area mismatch messages indicate that the area configured on your local host and remote node does not match.
To resolve this issue, check the configuration on both systems and make the appropriate configuration changes. See Section 2.2.1.3 for an example about how to fix the configuration.
Before you issue these commands, make sure you first check you logs. We highly recommend that you issue these commands during a maintenance window.
| Caution! | ||
|
Risk of performance loss. Enabling the generation of debug messages
can severely affect system performance. To reduce the risk, exercise
caution when enabling the generation of debug messages on a production
system.
| ||
[local]R2.17.145#terminal monitor [local]R2.17.145#debug isis adjacency interface 9/2 [local]R2.17.145# Jan 29 16:28:25: [0001]: %ISIS-7-ADJ: rcvd L1 LAN IIH from 0030.8802.1f44 seq 201 on intf 9/2 Jan 29 16:28:25: [0001]: %ISIS-7-ADJ: rcvd L1 LAN IIH with area mismatch from 0030.8802.1f44 on intf 9/2 Jan 29 16:28:27: [0001]: %ISIS-7-ADJ: rcvd L2 LAN IIH from 0030.8802.1f44 seq 38on intf 9/2 Jan 29 16:28:29: [0001]: %ISIS-7-ADJ: send L1 LAN IIH on intf 9/2 Jan 29 16:28:34: [0001]: %ISIS-7-ADJ: rcvd L1 LAN IIH from 0030.8802.1f44 seq 202 on intf 9/2 Jan 29 16:28:34: [0001]: %ISIS-7-ADJ: rcvd L1 LAN IIH with area mismatch from 0030.8802.1f44 on intf 9/2 Jan 29 16:28:37: [0001]: %ISIS-7-ADJ: rcvd L2 LAN IIH from 0030.8802.1f44 seq 39 on intf 9/2 Jan 29 16:28:40: [0001]: %ISIS-7-ADJ: send L1 LAN IIH on intf 9/2 Jan 29 16:28:44: [0001]: %ISIS-7-ADJ: rcvd L1 LAN IIH from 0030.8802.1f44 seq 203 on intf 9/2 Jan 29 16:28:44: [0001]: %ISIS-7-ADJ: rcvd L1 LAN IIH with area mismatch from 0030.8802.1f44 on intf 9/2 Jan 29 16:28:47: [0001]: %ISIS-7-ADJ: rcvd L2 LAN IIH from 0030.8802.1f44 seq 40 on intf 9/2 Jan 29 16:28:50: [0001]: %ISIS-7-ADJ: send L1 LAN IIH on intf 9/2 Jan 29 16:28:52: [0001]: %ISIS-7-ADJ: rcvd L1 LAN IIH from 0030.8802.1f44 seq 204 on intf 9/2 Jan 29 16:28:52: [0001]: %ISIS-7-ADJ: rcvd L1 LAN IIH with area mismatch from 0030.8802.1f44 on intf 9/2 Jan 29 16:28:55: [0001]: %ISIS-7-ADJ: rcvd L2 LAN IIH from 0030.8802.1f44 seq 41 on intf 9/2 Jan 29 16:28:59: [0001]: %ISIS-7-ADJ: send L1 LAN IIH on intf 9/2 Jan 29 16:29:00: [0001]: %ISIS-7-ADJ: rcvd L1 LAN IIH from 0030.8802.1f44 seq 205 on intf 9/2 Jan 29 16:29:00: [0001]: %ISIS-7-ADJ: rcvd L1 LAN IIH with area mismatch from 0030.8802.1f44 on intf 9/2 Jan 29 16:29:07: [0001]: %ISIS-7-ADJ: rcvd L2 LAN IIH from 0030.8802.1f44 seq 42 on intf 9/2 Jan 29 16:29:09: [0001]: %ISIS-7-ADJ: rcvd L1 LAN IIH from 0030.8802.1f44 seq 206 on intf 9/2 Jan 29 16:29:09: [0001]: %ISIS-7-ADJ: rcvd L1 LAN IIH with area mismatch from 0030.8802.1f44 on intf 9/2 Jan 29 16:29:11: [0001]: %ISIS-7-ADJ: send L1 LAN IIH on intf 9/2
2.2.2 Check for Misconfigured NSAPs (NETs)
Each IS-IS node must have at least one NSAP address (NET) to identify it as a network node. This NET consists of the area as show in the following figure:
Figure 7 NSAP Address Syntax
For nodes with multiple NETs, the system ID must be the same in all of the nodes, and at least one of the area prefixes must be shared with another node in the same area.
The result of misconfiguring a NET is shown In this example, R2, R3, and R4 are suppose to be together in area 49.0001 and form both Level 1 and Level 2 adjacencies. R4 is misconfigured. The configurations for R2, R3, and R4 are not show in this section.
- Note:
- Before you begin check for the misconfigured NSAPs, make sure you ping your neighbors by using the ping command.
Figure 8 Misconfigured NSAPs (NETs)
The outputs of the show isis adjacency command from R2, R3, and R4 indicate R4 formed only Level 2 adjacencies with R2 and R3. However, R2 and R3 formed Level 1-2 adjacencies with each other as expected. This indicates that you need to verify the configuration and operation of R4.
[local2]R2.17.145#show isis adjacency <<-- Check the adjacency on R2. IS-IS Adjacenc(ies) for tag csc2: SystemId Interface L MT Stat Hold SNPA Uptime R3.16.121 12/5 2 U Up 18 0030.8800.2b40 00:24:54 R3.16.121 12/5 1 U Up 28 0030.8800.2b40 00:24:54 R4 12/5 2 U Up 24 0030.8800.3345 00:10:08 <<-Router R4 did not formed level 1 adjacency. Investigate router R4. Total IS-IS Adjacenc(ies): 3 [local2]R2.17.145# [local2]R3.16.121#show isis adjacency <<-- Check the adjacency on R3. IS-IS Adjacenc(ies) for tag csc2: SystemId Interface L MT Stat Hold SNPA Uptime R2.17.145 2/5 2 U Up 25 0030.8810.49a0 00:25:09 R2.17.145 2/5 1 U Up 21 0030.8810.49a0 00:25:09 R4 2/5 2 U Up 25 0030.8800.3345 00:10:19 <<-Router R4 did not formed level 1 adjacency. Investigate router R4. Total IS-IS Adjacenc(ies): 3 [local2]R3.16.121# [local2]R4#show isis adjacency <<-- Check adjacency on R4. IS-IS Adjacenc(ies) for tag csc2: SystemId Interface L MT Stat Hold SNPA Uptime R2.17.145 14/5 2 U Up 25 0030.8810.49a0 00:10:33 R3.16.121 14/5 2 U Up 28 0030.8800.2b40 00:10:30 <<-- Verify the configuration and operation of R4. Total IS-IS Adjacenc(ies): 2 [local2]R4#
R3 points correctly to R2 as the Level 2 DIS but incorrectly points to itself as the Level 1 DIS. This indicates that there is a problem with Level 1 communication. Because this is a new setup and all the defaults have not been changed, the only cause that might indicate the type of adjacency formed is the area prefix.
Further inspection of the NET configured on R4 shows that it was misconfigured with 47.0001.0000.0000.0003.00 rather than 49.0001.0000.0000.0003.00. This area ID mismatch resulted in R2 and R3 forming only Level 2 adjacencies with R4.
[local2]R2.17.145#show port 12/5 detail ethernet 12/5 state is Up Description : Line state : Up Admin state : Up Link Dampening : disabled Undampened line state : Up Dampening Count : 0 Encapsulation : ethernet MTU size : 1500 Bytes NAS Port Type : MAC address : 00:30:88:10:49:a0 Media type : 100Base-TX Speed : 100 Mbps Duplex mode : full Loopback : off Active Alarms : NONE [local2]R2.17.145# [local2]R2.17.145#show isis interfaces IS-IS interface(s) for tag csc2: Interface L MT Stat Level-1-DR Level-2-DR Metric 12/5 3 U Up R2.17.145.01 R2.17.145.01 10 Total IS-IS Interface(s): 1 [local2]R2.17.145# [local2]R3.16.121#show port 2/5 detailethernet 2/5 state is Up Description : Line state : Up Admin state : Up Link Dampening : disabled Undampened line state : Up Dampening Count : 0 Encapsulation : ethernet MTU size : 1500 Bytes NAS Port Type : MAC address : 00:30:88:00:2b:40 Media type : 100Base-TX Speed : 100 Mbps Duplex mode : full Loopback : off Active Alarms : NONE [local2]R3.16.121#show isis interfaces IS-IS interface(s) for tag csc2: Interface L MT Stat Level-1-DR Level-2-DR Metric 2/5 3 U Up R2.17.145.01 R2.17.145.01 10 Total IS-IS Interface(s): 1 [local2]R3.16.121# [local2]R4#show port 14/5 detail ethernet 14/5 state is Up Description : Line state : Up Admin state : Up Link Dampening : disabled Undampened line state : Up Dampening Count : 0 Encapsulation : ethernet MTU size : 1500 Bytes NAS Port Type : MAC address : 00:30:88:00:33:45 Media type : 100Base-TX Speed : 100 Mbps Duplex mode : full Loopback : off Active Alarms : NONE [local2]R3#show isis interfaces IS-IS interface(s) for tag csc2: Interface L MT Stat Level-1-DR Level-2-DR Metric 14/5 3 U Up ser-1.01 R2.17.145.01 10 <<--R3 points correctly to R2 as the Level 2 DIS but incorrectly points to itself as the Level 1 DIS. <<--This indicates that there is a problem with Level 1 communication. Total IS-IS Interface(s): 1 [local2]ser-1#
[local2]R2.17.145#terminal monitor [local2]R2.17.145#debug isis adjacency interface 12/5 [local2]R2.17.145#Feb 3 16:03:22: [0004]: %ISIS-7-ADJ: send L2 LAN IIH on intf 12/5 Feb 3 16:03:26: [0004]: %ISIS-7-ADJ: rcvd L1 LAN IIH from 0030.8800.2b40 seq 321 on intf 12/5 Feb 3 16:03:27: [0004]: %ISIS-7-ADJ: rcvd L2 LAN IIH from 0030.8800.2b40 seq 316 on intf 12/5 Feb 3 16:03:27: [0004]: %ISIS-7-ADJ: rcvd L2 LAN IIH from 0030.8800.3345 seq 213 on intf 12/5 Feb 3 16:03:30: [0004]: %ISIS-7-ADJ: send L1 LAN IIH on intf 12/5 Feb 3 16:03:31: [0004]: %ISIS-7-ADJ: send L2 LAN IIH on intf 12/5 Feb 3 16:03:31: [0004]: %ISIS-7-ADJ: rcvd L1 LAN IIH from 0030.8800.3345 seq 211 on intf 12/5 Feb 3 16:03:31: [0004]: %ISIS-7-ADJ: rcvd L1 LAN IIH with area mismatch from 0030.8800.3345 on intf 12/5 <<--When you have a area mismatch message, check the configuration. Feb 3 16:03:35: [0004]: %ISIS-7-ADJ: rcvd L1 LAN IIH from 0030.8800.2b40 seq 322 on intf 12/5 Feb 3 16:03:35: [0004]: %ISIS-7-ADJ: rcvd L2 LAN IIH from 0030.8800.3345 seq 214 on intf 12/5 Feb 3 16:03:37: [0004]: %ISIS-7-ADJ: rcvd L2 LAN IIH from 0030.8800.2b40 seq 317 on intf 12/5 Feb 3 16:03:39: [0004]: %ISIS-7-ADJ: rcvd L1 LAN IIH from 0030.8800.3345 seq 212 on intf 12/5 Feb 3 16:03:39: [0004]: %ISIS-7-ADJ: rcvd L1 LAN IIH with area mismatch from 0030.8800.3345 on intf 12/5 Feb 3 16:03:41: [0004]: %ISIS-7-ADJ: send L2 LAN IIH on intf 12/5 Feb 3 16:03:42: [0004]: %ISIS-7-ADJ: send L1 LAN IIH on intf 12/5
Before you issue a debug command, make sure you first check you logs. We highly recommend that you issue debug commands during a maintenance window.
| Caution! | ||
|
Risk of performance loss. Enabling the generation of debug messages
can severely affect system performance. To reduce the risk, exercise
caution when enabling the generation of debug messages on a production
system.
| ||
2.2.3 Check for Duplicate System IDs
All IS-IS nodes in an area must have the same area prefix and a unique system ID. If a node has multiple NETs configured, each address must have the same system ID. This is a critical protocol requirement, especially because the system ID is part of the LSPID, and its uniqueness is used to identify the owners of LSPs flooded within the area.
The adjacency between the remote and local nodes does not form when the neighbor has a duplicate system ID with the local router.
When different nodes in the area are incorrectly configured with the same system ID, the routers detect this and each node logs duplicate ID error messages: duplicate system ID.
To check for duplicate system ID error messages, run the show log command. If they are found, run the debug isis adjacency command to determine the source of the conflict in the output, which points to the interface where the hello messages with the duplicate ID are coming from.
If the nodes are directly connected, each router immediately detects the problem as it exchanges hellos to establish adjacency and as a result, the adjacency fails. If they are not directly connected, however, they overwrite each other's LSP for some time until the IS-IS process determines, based on the frequency of occurrence, that the problem is because of duplicate system IDs and logs appropriate error messages.
In the following example, the debug isis adjacency command shows a duplicate system ID between directly connected neighbors within same broadcast domain that was incorrectly configured as a duplicate system IDs in same area.
[local2]R2.17.145#terminal monitor [local2]R2.17.145#debug isis adjacency [local2]R2.17.145#Feb 3 16:10:06: [0004]: %ISIS-7-ADJ: rcvd L2 LAN IIH from 0030.8800.3345 seq 23 on intf 12/5 Feb 3 16:10:06: [0004]: %ISIS-7-ADJ: rcvd LAN L2 IIH duplicate system ID <<--Duplicate ID error messages from 0030.8800.3345 on intf 12/5 Feb 3 16:10:07: [0004]: %ISIS-7-ADJ: send L1 LAN IIH on intf 12/5 Feb 3 16:10:07: [0004]: %ISIS-7-ADJ: rcvd L2 LAN IIH from 0030.8800.2b40 seq 355 on intf 12/5 Feb 3 16:10:07: [0004]: %ISIS-7-ADJ: send L2 LAN IIH on intf 12/5 Feb 3 16:10:09: [0004]: %ISIS-7-ADJ: rcvd L1 LAN IIH from 0030.8800.3345 seq 23 on intf 12/5 Feb 3 16:10:09: [0004]: %ISIS-7-ADJ: rcvd LAN L1 IIH duplicate system ID from 0030.8800.3345 on intf 12/5 Feb 3 16:10:11: [0004]: %ISIS-7-ADJ: rcvd L1 LAN IIH from 0030.8800.2b40 seq 362 on intf 12/5 Feb 3 16:10:15: [0004]: %ISIS-7-ADJ: rcvd L2 LAN IIH from 0030.8800.3345 seq 24 on intf 12/5 Feb 3 16:10:15: [0004]: %ISIS-7-ADJ: rcvd LAN L2 IIH duplicate system ID from 0030.8800.3345 on intf 12/5 Feb 3 16:10:17: [0004]: %ISIS-7-ADJ: send L2 LAN IIH on intf 12/5 Feb 3 16:10:17: [0004]: %ISIS-7-ADJ: send L1 LAN IIH on intf 12/5 Feb 3 16:10:17: [0004]: %ISIS-7-ADJ: rcvd L1 LAN IIH from 0030.8800.3345 seq 24 on intf 12/5 Feb 3 16:10:17: [0004]: %ISIS-7-ADJ: rcvd LAN L1 IIH duplicate system ID from 0030.8800.3345 on intf 12/5 [local2]R4 terminal monitor [local2]R4 debug isis adjacency #Feb 3 16:01:53: [0008]: %ISIS-7-ADJ: rcvd L1 LAN IIH from 0030.8810.49a0 seq 356 on intf 14/5 Feb 3 16:01:53: [0008]: %ISIS-7-ADJ: rcvd LAN L1 IIH duplicate system ID from 0030.8810.49a0 on intf 14/5 Feb 3 16:01:55: [0008]: %ISIS-7-ADJ: send L2 LAN IIH on intf 14/5 Feb 3 16:01:55: [0008]: %ISIS-7-ADJ: rcvd L2 LAN IIH from 0030.8810.49a0 seq 351 on intf 14/5 Feb 3 16:01:55: [0008]: %ISIS-7-ADJ: rcvd LAN L2 IIH duplicate system ID from 0030.8810.49a0 on intf 14/5 Feb 3 16:02:00: [0008]: %ISIS-7-ADJ: rcvd L1 LAN IIH from 0030.8800.2b40 seq 354 on intf 14/5 Feb 3 16:02:01: [0008]: %ISIS-7-ADJ: rcvd L2 LAN IIH from 0030.8800.2b40 seq 348 on intf 14/5 Feb 3 16:02:01: [0008]: %ISIS-7-ADJ: send L1 LAN IIH on intf 14/5 Feb 3 16:02:03: [0008]: %ISIS-7-ADJ: rcvd L2 LAN IIH from 0030.8810.49a0 seq 352 on intf 14/5 Feb 3 16:02:03: [0008]: %ISIS-7-ADJ: rcvd LAN L2 IIH duplicate system ID from 0030.8810.49a0 on intf 14/5 Feb 3 16:02:03: [0008]: %ISIS-7-ADJ: rcvd L1 LAN IIH from 0030.8810.49a0 seq 357 on intf 14/5 Feb 3 16:02:03: [0008]: %ISIS-7-ADJ: rcvd LAN L1 IIH duplicate system ID from 0030.8810.49a0 on intf 14/5 Feb 3 16:02:05: [0008]: %ISIS-7-ADJ: send L2 LAN IIH on intf 14/5
Before you issue debug commands, make sure you first check you logs. We highly recommend that you issue these commands during a maintenance window.
| Caution! | ||
|
Risk of performance loss. Enabling the generation of debug messages
can severely affect system performance. To reduce the risk, exercise
caution when enabling the generation of debug messages on a production
system.
| ||
To solve this issue:
- Check the local and remote nodes configuration by using the show configuration isis command.
- Make the appropriate configuration changes so that the system IDs are unique.
2.2.4 Check for Misconfigured IP Addresses and Subnets
Incorrectly configured IP addresses prevent adjacency formation. The result of a misconfigured IP address is shown in the following debug and show command output. In this example, the IP address of R3 interface 10/10 is changed to 201.1.1.2/24. This erroneous entry causes the adjacency to be invalid with R3.
Figure 9 Misconfigured IP Addresses and Subnets
[local]R3.16.121#configuration Enter configuration commands, one per line, 'end' to exit [local]R3.16.121(config)#context local [local]R3.16.121(config-ctx)#int 10/10 [local]R3.16.121(config-if)#no ip address [local]R3.16.121(config-if)# ip address 201.1.1.2/24 [local]R3.16.121(config-if)#commit Transaction committed.
To determine if you have a misconfigured IP address, check your logs for messages similar to the following: “... no common IP subnets from ... ”.
The following example shows you the result of the misconfigured IP address when you run the debug isis adjacency interface if-name command. The "no common IP subnets" messages indicates that interface 10/10 has a misconfigured IP address. When this message appears, validate your configuration by running the show configuration isis command and make the appropriate configuration changes.
[local]R3.16.121#terminal monitor [local]R3.16.121#debug isis adjacency interface 10/10[local]R3.16.121#Jan 30 11:53:39.062: [0001]: %ISIS-7-ADJ: send L2 LAN IIH on intf 10/1 0 Jan 30 11:53:41.069: [0001]: %ISIS-7-ADJ: rcvd L2 LAN IIH from 0030.8810.10fd seq 21 on intf 10/10 Jan 30 11:53:41.071: [0001]: %ISIS-7-ADJ: rcvd L2 LAN IIH with no common IP subnets from 0030.8810.10fd on intf 10/10 <<--The message "no common IP subnets" indicates misconfigured incorrect IP address. <<-- Check your configuration. Jan 30 11:53:45.389: [0001]: %ISIS-7-ADJ: rcvd L1 LAN IIH from 0030.8810.10fd seq 22 on intf 10/10 Jan 30 11:53:45.390: [0001]: %ISIS-7-ADJ: rcvd L1 LAN IIH with no common IP subnets from 0030.8810.10fd on intf 10/10 Jan 30 11:53:45.472: [0001]: %ISIS-7-ADJ: send L1 LAN IIH on intf 10/10 Jan 30 11:53:49.962: [0001]: %ISIS-7-ADJ: send L2 LAN IIH on intf 10/10 Jan 30 11:53:50.679: [0001]: %ISIS-7-ADJ: rcvd L2 LAN IIH from 0030.8810.10fd seq 22 on intf 10/10 Jan 30 11:53:50.680: [0001]: %ISIS-7-ADJ: rcvd L2 LAN IIH with no common IP subnets from 0030.8810.10fd on intf 10/10 Jan 30 11:53:53.169: [0001]: %ISIS-7-ADJ: rcvd L1 LAN IIH from 0030.8810.10fd seq 23 on intf 10/10 Jan 30 11:53:53.171: [0001]: %ISIS-7-ADJ: rcvd L1 LAN IIH with no common IP subnets from 0030.8810.10fd on intf 10/10 Jan 30 11:53:53.872: [0001]: %ISIS-7-ADJ: send L1 LAN IIH on intf 10/10 Jan 30 11:54:00.980: [0001]: %ISIS-7-ADJ: rcvd L1 LAN IIH from 0030.8810.10fd seq 24 on intf 10/10 Jan 30 11:54:00.981: [0001]: %ISIS-7-ADJ: rcvd L1 LAN IIH with no common IP subnets from 0030.8810.10fd on intf 10/10 Jan 30 11:54:01.182: [0001]: %ISIS-7-ADJ: send L2 LAN IIH on intf 10/10 Jan 30 11:54:02.194: [0001]: %ISIS-7-ADJ: rcvd L2 LAN IIH from 0030.8810.10fd seq 23 on intf 10/10 Jan 30 11:54:02.195: [0001]: %ISIS-7-ADJ: rcvd L2 LAN IIH with no common IP subnets from 0030.8810.10fd on intf 10/10 Jan 30 11:54:04.463: [0001]: %ISIS-7-ADJ: send L1 LAN IIH on intf 10/10
| Caution! | ||
|
Risk of performance loss. Enabling the generation of debug messages
can severely affect system performance. To reduce the risk, exercise
caution when enabling the generation of debug messages on a production
system.
| ||
2.2.5 Check for Authentication Issues
Adjacencies will not form (become stuck in the INIT state):
- When only one side is correctly enabled for authentication
- Is receiving corrupt hello messages
- Has a mismatch MTU setting
Interface level authentication information is used only for IIH packets. Instance level authentication information is used for LSPs, PSNPs, and CSNPs.
The following can cause authentication failures:
- Authentication is not enabled on both endpoints.
- The authentication passwords on both endpoints do not
match.
A password mismatch between the source of the packet and the recipient creates both adjacency and routing update problems, depending on the type of authentication enabled.
- Even though authentication is enabled, the authentication type (simple or HMAC-MD5) can be mismatched.
Use the authentication configuration command to configure IS-IS routing packet authentication by using the simple or HMAC-MD5 authentication option for an IS-IS instance. To use a different key for a specific interface, use the authentication command in IS-IS interface configuration mode.
This section shows that an adjacency cannot be established between R2 and R3. R2 is configured with IS-IS authentication and R3 without authentication. It also shows you the result when you run the debug isis adjacency and have an authentication problem.
- Step 1: Check Local IS-IS Configuration
- Step 2: Check IS-IS Adjacency Formation
- Step 3: Check IS-IS Peer Configuration
- Example: Authentication Errors
2.2.6 Step 1: Check Local IS-IS Configuration
Check your local IS-IS configuration. Note your configuration and compare it with your peer IS-IS configuration to make sure they are correct.
[local]R2.17.145#show configuration isis
Building configuration...
Current configuration:
context local
!
router isis csc
net 49.0001.0000.0000.0001.00
authentication key-chain jyu type simple <<-- Authentication enabled
<<--The authentication type must match at both endpoints (simple/HMAC-MD5)
address-family ipv4 unicast
!
interface 9/2
! bind to ethernet 9/2
hello padding never
address-family ipv4 unicast
!
interface loBB
passive-interface
address-family ipv4 unicast
!
End
2.2.7 Step 2: Check IS-IS Adjacency Formation
Run the show isis adjacency command on your local system to gather more information about the state of the IS-IS adjacency. R3 keeps an Init state indefinitely because R2 fails to authenticate.
[local]R3.16.121#show isis adjacency IS-IS Adjacenc(ies) for tag csc: SystemId Interface L MT Stat Hold SNPA Uptime R2.17.145 10/10 2 U Init 23 0030.8810.10fd 00:00:00 <<--R3 keeps an “Init” state indefinitely because R2 fails to authenticate. .ser-1 2/11 2 U Up 28 0030.8800.334b 02d19h05
2.2.8 Step 3: Check IS-IS Peer Configuration
Check the IS-IS peer for a configuration mismatch with your local system. This configuration shows that authentication has not been enabled and the authentication type is not set on the remote node. To solve this issue, enable authentication on router R3 and make sure the authentication passwords and authentication type match at both endpoints.
[local]R3.16.121#show configuration isis Building configuration... Current configuration: context local ! router isis csc net 49.0002.0000.0000.0002.00 <<--Authentication is not enabled. address-family ipv4 unicast <<--Authentication type not set. redistribute connected ! interface 10/10 ! bind to ethernet 10/10 hello padding never address-family ipv4 unicast ! interface loBB address-family ipv4 unicast ! interface 2/11 ! bind to ethernet 2/11 circuit mtu 500 address-family ipv4 unicast ! end [local]R3.16.121#
2.2.9 Example: Authentication Errors
The following example shows you the result when you run the debug isis adjacency and have a authentication problem.
Before you issue a debug command, make sure you first check you logs. We highly recommend that you issue debug commands during a maintenance window.
| Caution! | ||
|
Risk of performance loss. Enabling the generation of debug messages
can severely affect system performance. To reduce the risk, exercise
caution when enabling the generation of debug messages on a production
system.
| ||
[local]R2.17.145#terminal monitor [local]R2.17.145#debug isis adjacency [local]R2.17.145#Feb 2 12:23:10: [0001]: %ISIS-7-ADJ: send L2 LAN IIH on intf 9/2 Feb 2 12:23:11: [0001]: %ISIS-7-ADJ: rcvd L2 LAN IIH from 0030.8802.1f44 seq 25878 on intf 9/2 Feb 2 12:23:11: [0001]: %ISIS-7-ADJ: authentication failed on rcvd L2 LAN IIH from 0030.8802.1f44 on interface 9/2 <<--The output shows a link authentication failure. Check the configuration on both endpoints. Feb 2 12:23:15: [0001]: %ISIS-7-ADJ: rcvd L1 LAN IIH from 0030.8802.1f44 seq 25877 on intf 9/2 Feb 2 12:23:15: [0001]: %ISIS-7-ADJ: authentication failed on rcvd L1 LAN IIH from 0030.8802.1f44 on interface 9/2 Feb 2 12:23:16: [0001]: %ISIS-7-ADJ: send L1 LAN IIH on intf 9/2 Feb 2 12:23:19: [0001]: %ISIS-7-ADJ: send L2 LAN IIH on intf 9/2 Feb 2 12:23:22: [0001]: %ISIS-7-ADJ: rcvd L2 LAN IIH from 0030.8802.1f44 seq 25879 on intf 9/2 Feb 2 12:23:22: [0001]: %ISIS-7-ADJ: authentication failed on rcvd L2 LAN IIH from 0030.8802.1f44 on interface 9/2 Feb 2 12:23:23: [0001]: %ISIS-7-ADJ: rcvd L1 LAN IIH from 0030.8802.1f44 seq 25878 on intf 9/2 Feb 2 12:23:23: [0001]: %ISIS-7-ADJ: authentication failed on rcvd -L1 LAN IIH from 0030.8802.1f44 on interface 9/2 Feb 2 12:23:24: [0001]: %ISIS-7-ADJ: send L1 LAN IIH on intf 9/2
2.3 Check for Route Update Problems
Most IS-IS problems are caused by adjacency (reachability) problems . When no adjacency issues exist, check for route update problems. Route update problems are challenging to isolate because the routing table can be populated with routing information from multiple sources.
The following are the most common causes of routing update problems for IS-IS:
If a route is not being learned in the rest of the area or domain, verify that the route in the IS-IS process has been correctly configured.
2.3.1 Check Route Advertisements
Most route advertisement problems are configuration issues or LSP propagation issues. To enable IS-IS formation, use IP subnet information, and LSP flooding by applying the ip router isis configuration command on the appropriate interface. IS-IS does not use a network statement for advertising an IP route as is commonly done for other protocols. Enabling IS-IS on an interface triggers the formation of adjacencies on that interface and also advertises the attached IP subnet in an LSP to all neighbors.
If the interface is correctly configured, check the IP reachability information fields of the router's LSP by running the show isis database level detail LSPID command. The output of database detail information of any LSP could useful for debugging. This command provides information about the LSP that is advertised to other neighbors. We assumed that there are no adjacency problems with any of the neighbors in the direction of the network where the route is missing. For more information about this command, see Section 1.15.
[local]R2.17.145#show isis interfaces detail IS-IS interface(s) for tag csc: 9/2 Up, level: 3, Ckt Id: 1, lan, Ucast IP address: 200.1.1.1/24 mtu: 9000, speed 1000000, Grid: 0x10000000, nh-id: 2, ckt 9/2 metrics[L1/L2]: v4 ucast[10/10] Level Adjs Priority Hello Hold Auth Blocked Metric 1 1 64 0 30 10 2 1 64 5 30 10 loBB Up, level: 3, Ckt Id: 2, p2p, Ucast IP address: 110.1.1.1/32 mtu: 1500, speed 0, Grid: 0x10000001, nh-id: 3, ckt Loopback metrics[L1/L2]: v4 ucast[10/10] Level Adjs Priority Hello Hold Auth Blocked Metric 3 0 64 7 30 10 Total IS-IS Interface(s): 2 [local]R2.17.145#
Use the level-1 keyword when the route is missing in only the local area. Use the level-2 keyword when the route is not present in other areas within the same domain.
If no adjacency problems exist, IS-IS routing is enabled correctly on the interface where the route should be taken from, and the prefix is seen in the LSP of the local router, run the show isis database level detail LSPID command on the remote routers to check the presence of the LSP that your are investigating. To obtain information about the topology of your network, run the show isis topology command. For information about this command, see Section 1.12.
The following examples shows the results for level 1 and level 2 IS-IS database.
[local]R2.17.145#show isis database l1 IS-IS level 1 link-state database for tag csc: LSPID Sequence Checksum Holdtime AT/OL Len R2.17.145.00-00* 0x3db 0x511a 521 0/0 97 R2.17.145.01-00* 0x6e 0x95b1 521 0/0 53 R3.16.121.00-00 0x1dc 0x7539 1126 0/0 124 ser-1.00-00 0xf 0xee4f 599 0/0 82 ser-1.01-00 0x4 0x6c41 599 0/0 53 e Total IS-IS LSP(s) for tag csc in Level-1: 5 [local]R2.17.145#show isis database l2 IS-IS level 2 link-state database for tag csc: LSPID Sequence Checksum Holdtime AT/OL Len R2.17.145.00-00* 0x3e4 0xfdf0 453 0/0 133 R2.17.145.01-00* 0x397 0x3ae0 377 0/0 53 R3.16.121.00-00 0x3df 0xd56a 1181 0/0 160 ser-1.00-00 0x10 0xf5bf 612 0/0 118 ser-1.01-00 0x4 0x6c41 612 0/0 53 Total IS-IS LSP(s) for tag csc in Level-2: 5 [local]R2.17.145#
At this level, the most common problem is having the wrong version of an LSP, indicated by a lower sequence number than a neighboring router.
You can diagnose the problem by running the show isis database command with the detail and extensive keywords. To determine if you have the latest version of the LSPs, check the sequence number associated with the LSP in the show isis database output. On each node, verify that each node IS-IS database has synchronized this information to ensure that each router has the same view of your network.
The passive-interface command is typically used when the subnet on an interface must be advertised without forming adjacency or sending redundant hello messages over that interface. For example, a loopback interface is normally defined as a passive interface so that its address is advertised without wasting CPU cycles to generate unnecessary hellos to nonexistent neighbors. If a loopback address is not advertised, check the configuration to make sure it is specified as a passive interface.
The following show configuration isis example shows that a passive interface has been enabled on interface LoBB. The show isis interface command indicates that interface LoBB is Up.
[local]R2.17.145#show configuration isis Building configuration... Current configuration: context local ! router isis csc net 49.0001.0000.0000.0001.00 address-family ipv4 unicast ! interface 9/2 ! bind to ethernet 9/2 hello padding never address-family ipv4 unicast ! interface loBB passive-interface <<--Passive interface is enabled address-family ipv4 unicast ! end [local]R2.17.145#show isis interfaces IS-IS interface(s) for tag csc: Interface L MT Stat Level-1-DR Level-2-DR Metric 9/2 3 U Up R2.17.145.01 R2.17.145.01 10 loBB 3 U Up 1 Total IS-IS Interface(s): 2 [local]R2.17.145#show isis interfaces detail IS-IS interface(s) for tag csc: 9/2 Up, level: 3, Ckt Id: 1, lan, Ucast IP address: 200.1.1.1/24 mtu: 9000, speed 1000000, Grid: 0x10000000, nh-id: 2, ckt 9/2 metrics[L1/L2]: v4 ucast[10/10] Level Adjs Priority Hello Hold Auth Blocked Metric 1 1 64 4 30 10 2 1 64 3 30 10 loBB Up, level: 3, Ckt Id: 2, p2p(Passive), Ucast IP address: 110.1.1.1/32 mtu: 1500, speed 0, Grid: 0x10000001, nh-id: 3, ckt Loopback metrics[L1/L2]: v4 ucast[1/1] Level Adjs Priority Hello Hold Auth Blocked Metric 3 0 64 7 30 1 Total IS-IS Interface(s): 2 [local]R2.17.145#
2.3.2 Check for IS-IS Route Updates
Route update problems involve situations where an LSP from a remote router is correctly received, but a route in the LSP is not installed in the routing table as expected. The most likely reason for this is because there is a similar route from another routing source with a better administrative distance than IS-IS. Route update problems are rare in IS-IS, and when they do occur, the reason is likely a software failure or an interoperability issue.
Run the following commands to isolate route update problems:
- show ip route isis
- show isis database level detail LSPID
If a route is not in the routing table as expected, run the show isis database command specifying the routing level, the LSPID of the source LSP. Use the detail keyword to further investigate the LSP.
The following example shows the link-state database for level 2 only. Verify that all expected pseduonodes are present. On each node, verify that each node has synchronized this information to ensure that each router has the same view of your network. The detail keyword lists reachable addresses and their cost.
[local]R2.17.145#show isis database level-2 IS-IS level 2 link-state database for tag csc: LSPID Sequence Checksum Holdtime AT/OL Len R2.17.145.00-00* 0x4fd 0xb97f 953 0/0 116 R2.17.145.01-00* 0x4ab 0xff6 953 0/0 53 R3.16.121.00-00 0x4fb 0xf1fb 1119 0/0 197 ser-1.00-00 0x129 0x34c4 447 0/0 92 ser-1.01-00 0x118 0x4157 447 0/0 53 Total IS-IS LSP(s) for tag csc in Level-2: 5 [local]R2.17.145# [local]R2.17.145#show isis database level-2 detail IS-IS level 2 link-state database for tag csc: LSPID Sequence Checksum Holdtime AT/OL Len R2.17.145.00-00* 0x4fc 0xbb7e 421 0/0 116 Area Address: 49.0001 NLPID: IP Hostname: R2.17.145 IP Address: 110.1.1.1 M-Topology: Metric: 10 IS-Extended R2.17.145.01 Metric: 10 IP 200.1.1.0/24 Metric: 1 IP 110.1.1.1/32 Metric: 10 IP 200.1.1.0/24 Metric: 1 IP 110.1.1.1/32 R2.17.145.01-00* 0x4aa 0x11f5 421 0/0 53 Metric: 0 IS-Extended R2.17.145.00 Metric: 0 IS-Extended R3.16.121.00 R3.16.121.00-00 0x4fa 0xf3fa 566 0/0 197 Area Address: 49.0002 NLPID: IP Hostname: R3.16.121 IP Address: 100.1.1.2 M-Topology: Metric: 10 IS-Extended R2.17.145.01 Metric: 10 IS-Extended ser-1.01 <<--Lists reachable addresses and their cost Metric: 10 IP 200.1.1.0/24 <<--Make sure expected addresses are reachable Metric: 10 IP 100.1.1.2/32 <<--in your network. Metric: 10 IP 118.1.1.0/24 Metric: 0 IP 10.16.50.4/32 Metric: 0 IP 10.16.50.20/30 Metric: 0 IP 10.16.50.52/30 Metric: 0 IP 10.16.83.34/32 Metric: 0 IP 10.192.16.0/23 Metric: 10 IP 100.1.1.2/32 Metric: 10 IP 200.1.1.0/24 Metric: 10 IP 118.1.1.0/24ser-1.00-00 0x129 0x34c4 788 0/0 92 Area Address: 49.0001 NLPID: IP Hostname: ser-1 IP Address: 118.1.1.1 M-Topology: Metric: 10 IS-Extended ser-1.01 Metric: 10 IP 118.1.1.0/24 Metric: 10 IP 118.1.1.0/24 ser-1.01-00 0x118 0x4157 788 0/0 53 Metric: 0 IS-Extended ser-1.00 Metric: 0 IS-Extended R3.16.121.00 Total IS-IS LSP(s) for tag csc in Level-2: 5 [local]R2.17.145#
2.3.3 Check for Route Flaps or Unstable IS-IS Routes
Route flaps are caused by
- An unstable link
- A complex condition, such as an intermittent routing loop
Typically, at the point where the flap is seen, the LSP that contains the route is periodically advertised and withdrawn, or newer versions are continuously being received. Route flaps can also have a negative impact on the routing environment when a large number of LSPs and routers are affected. This might cause the SPF process to run for long periods, resulting in potentially high levels of CPU utilization on the affected routers.
The most common causes of route flaps are unstable links. Run the show ip route isis detail command to determine the LSP associated with the unstable route. You can then focus on isolating the problem on a specific LSP.
|
Issue |
Checked |
|---|---|
|
1.Are there any links in the path flapping? Recommended action: Check your IS-IS adjacency logs and check for a physical layer issue. Check for LSP corruption. |
|
|
2. Is the CPU high? Route flaps could cause high CPU utilization? Recommended action: A. Check CPU utilization by running the show process command. B. Verify that the SPF ran and investigate network instabilities by running the show isis spf-log command. For information about this command, see Section 1.17. |
|
|
3. Is the LSP being continuously updated? Recommended Action: Inspect SPF logs by using the show isis spf-log command. |
|
|
4. Fix physical layer issues. |
The show interface or show isis interface command can provide link status information, and some information about the issue might be available in the logs. At the source of the LSP, the debug isis spf-events command provides information regarding events affecting the locally sourced LSP and, therefore, some clues to the problem.
In most cases, you can check for route flaps by looking at the sequence numbers of LSPs in the link state database. The show isis database output displays a far higher sequence number for the LSP with ID R2 than for the other known LSPs, indicates a route flap. A large discrepancy indicates either problems at the source or somewhere in between the source and the point of observation. If the source and the router at which the problem is being observed are directly connected, you can use standard procedures to troubleshoot the physical and data link layers. For information about how to check these layers, see the General Troubleshooting Guide.
[local]R2.17.145#show isis database level-2 IS-IS level 2 link-state database for tag csc: LSPID Sequence Checksum Holdtime AT/OL Len R2.17.145.00-00* 0x4fd 0xb97f 953 0/0 116 R2.17.145.01-00* 0x4ab 0xff6 953 0/0 53 R3.16.121.00-00 0x4fb 0xf1fb 1119 0/0 197 R4.00-00 0x129 0x34c4 447 0/0 92 R4.01-00 0x118 0x4157 447 0/0 53 Total IS-IS LSP(s) for tag csc in Level-2: 5 [local]R2.17.145#
2.3.4 Check for Discontinuous Level 2 Subdomains
Routers in different areas exchange routing information through Level 2 routing and are referred as Level 2 or back bone routers. Level 2 allows routers to exchange information to different areas. IS-IS requires the Level 2 backbone that interconnects the various areas to be contiguous. This condition can easily be violated by bad network design or router misconfiguration, as shown in below.
SmartEdge routers function as Level 1-2 by default and you exercise caution when turning off Level 2 routing until the impact is well understood.
In the following example, Level 1-only router in area 49.0002 disrupts the continuity of the Level 2 path, preventing areas 49.0001 and 49.0003 from reaching each other.
Figure 10 Discontinuous Level 2 Subdomains
Reference List
| [1] Configuring IS-IS. |
| [2] General Troubleshooting Guide. |
| [3] Data Collection Guideline for the SmartEdge Router. |