Hello Folks,
Welcome to my blog, in this blog, I am going to discuss the method which I always apply to check if the ISIS protocol is working perfectly on the router or not. The same process will also give some tips to troubleshoot the protocol. So let’s get started.
In case you want to read some more articles on ISIS please use the below links.
For this blog, I am going to use below network. Here ISIS-L1 is configured between all the routers.
Simple verification commands.
Let’s take an example of R1, what are the commands that you will run to know if ISIS is working fine on the router.
1- First you need to know if ISIS is enabled properly on the router or not.
2- You need to know if ISIS is learning anything from the learned adjacency.
3- You need to check if the convergence is happening properly. This means if I bring up any interface in the ISIS on some other router in the domain, is the prefix associated with this interface is propagated in the network properly or not.
4- I would check if SPF is working fine.
So let’s hit these points one by one.
In order to check if ISIS is enabled on the router properly or not we have the following commands.
These commands give us enough information to be sure that ISIS is enabled on the router and we don’t need to worry about the ISIS process on the router, quickly you need to verify all the configuration parameters here and try to match them with the configurations you have done.
R1#show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "application"
Sending updates every 0 seconds
Invalid after 0 seconds, hold down 0, flushed after 0
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Maximum path: 32
Routing for Networks:
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 4)
Routing Protocol is "isis CORE"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Redistributing: isis
Address Summarization:
None
Maximum path: 4
Routing for Networks:
Loopback1
GigabitEthernet1
GigabitEthernet2
Routing Information Sources:
Gateway Distance Last Update
6.6.6.6 115 00:09:19
7.7.7.7 115 00:09:19
5.5.5.5 115 00:09:19
3.3.3.3 115 00:09:19
4.4.4.4 115 00:09:19
2.2.2.2 115 00:09:19
10.10.10.17 115 01:13:38
Distance: (default is 115)
R1#show isis protocol
Tag CORE:
IS-IS Router: CORE (0x10000)
System Id: 0000.0000.0001.00 IS-Type: level-1
Manual area address(es):
49
Routing for area address(es):
49
49.0000
Interfaces supported by IS-IS:
GigabitEthernet2 - IP - IPv6
GigabitEthernet1 - IP - IPv6
Loopback1 - IP - IPv6
Redistribute:
static (on by default)
Distance for L2 CLNS routes: 110
RRR level: none
Generate narrow metrics: level-1-2
Accept narrow metrics: level-1-2
Generate wide metrics: none
Accept wide metrics: none
R1#
Now once we know if ISIS process is enabled on the router we need to move ahead to the adjacency. Adjacency has two things associated with it. First, if the adj is formed or not. Second, if the router is learning any prefixes from the adjacencies. For that, we will run the following commands.
In summary here we are checking if the ADJ with R2 is up and what are the prefixes we have learned from R2. This information can be found in isis database, please check the details below.
R1#show clns neighbors
Tag CORE:
System Id Interface SNPA State Holdtime Type Protocol
R2 Gi1 0c83.95a7.2e00 Up 25 L1 IS-IS
ios Gi2 0c83.9505.b101 Up 29 L1 IS-IS
R1#show isis neighbors
Tag CORE:
System Id Type Interface IP Address State Holdtime Circuit Id
R2 L1 Gi1 10.10.10.2 UP 24 01
ios L1 Gi2 10.10.10.6 UP 28 00
R1#
R1#show isis database detail
Tag CORE:
IS-IS Level-1 Link State Database:
LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL
R1.00-00 * 0x00000011 0x7DB7 1092/* 0/0/0
Area Address: 49
NLPID: 0xCC 0x8E
Hostname: R1
Metric: 10 IS R2.00
Metric: 10 IS ios.00
IP Address: 1.1.1.1
Metric: 10 IP 1.1.1.1 255.255.255.255
Metric: 10 IP 10.10.10.0 255.255.255.252
Metric: 10 IP 10.10.10.4 255.255.255.252
IPv6 Address: 2222::1
Metric: 10 IPv6 2001::/126
Metric: 10 IPv6 2002::/126
Metric: 10 IPv6 2222::1/128
R2.00-00 0x0000000F 0x34F3 781/1199 0/0/0
Area Address: 49
NLPID: 0xCC 0x8E
Hostname: R2
Metric: 10 IS R4.00
Metric: 10 IS R1.00
IP Address: 2.2.2.2
Metric: 10 IP 2.2.2.2 255.255.255.255
Metric: 10 IP 10.10.10.0 255.255.255.252
Metric: 10 IP 10.10.10.8 255.255.255.252
IPv6 Address: 2222::2
Metric: 10 IPv6 2222::2/128
Metric: 10 IPv6 2001::/126
Metric: 10 IPv6 2003::/126
<OUTPUT SNIP>
R1#show ip route 2.2.2.2
Routing entry for 2.2.2.2/32
Known via "isis", distance 115, metric 20, type level-1
Redistributing via isis CORE
Last update from 10.10.10.2 on GigabitEthernet1, 01:44:46 ago
Routing Descriptor Blocks:
* 10.10.10.2, from 2.2.2.2, 01:44:46 ago, via GigabitEthernet1
Route metric is 20, traffic share count is 1
Repair Path: 7.7.7.7, via MPLS-Remote-Lfa1
Now let’s check some more commands which can help us in the troubleshooting.
One is my favourite which tells about the changes that happened in ISIS in the past few hrs. The command will record the changes that triggered SPF full calculations. Generally, full SPF calculations will happen once we will happen if any event has made a change in the SPF topology like link up down event, router up down event etc. In every 15 seconds, there will be a default full spf calculation. We need to watch for any other event which has triggered full spf calculation.
R1#sh isis spf-log
Tag CORE:
TID 0 level 1 SPF log
When Duration Nodes Count First trigger LSP Triggers
02:32:20 0 7 1 PERIODIC SPFTYPE
02:17:20 0 7 1 PERIODIC SPFTYPE
02:02:20 0 7 1 PERIODIC SPFTYPE
01:56:08 0 1 3 R1.00-00 DELADJ DBCHANGED NEWLSP
01:56:07 0 2 3 R2.00-00 ADJMTIDCHG NEWLSP TLVCODE
01:56:06 0 4 2 R3.00-00 TLVCONTENT
01:56:05 1 7 3 ios.00-00 LSPHEADER TLVCONTENT
01:56:02 0 7 3 R1.00-00 NEWADJ TLVCONTENT
01:53:53 1 7 1 R3.00-00 TLVCONTENT
01:53:23 0 7 1 R4.00-00 TLVCONTENT
01:52:46 0 7 2 R3.00-00 TLVCONTENT
01:47:20 0 7 1 PERIODIC SPFTYPE
01:32:20 0 7 1 PERIODIC SPFTYPE
01:17:20 0 7 1 PERIODIC SPFTYPE
01:02:20 1 7 1 PERIODIC SPFTYPE
00:47:20 1 7 1 PERIODIC SPFTYPE
00:32:20 0 7 1 PERIODIC SPFTYPE
00:17:20 0 7 1 PERIODIC SPFTYPE
00:02:20 0 7 1 PERIODIC SPFTYPE
In below table you can see the definition of each column in the above command output. Here you can see that the second column tells us about the reason for the SPF calculation. In order to check the details for the trigger string you can check the table 2 below.
| Field | Description |
|---|---|
| When | How long ago (in hours: minutes: seconds) a full SPF calculation occurred. The last 20 occurrences are logged. |
| Duration | Number of milliseconds required to complete this SPF run. Elapsed time is wall clock time, not CPU time. |
| Nodes | Number of routers and pseudonodes (LANs) that make up the topology calculated in this SPF run. |
| Count | Number of events that triggered this SPF run. When there is a topology change, often multiple link-state packets (LSPs) are received in a short time. A router waits 5 seconds before running a full SPF run, so it can include all new information. This count denotes the number of events (such as receiving new LSPs) that occurred while the router was waiting its 5 seconds before running full SPF. |
| Last trigger LSP | Whenever a full SPF calculation is triggered by the arrival of a new LSP, the router stores the LSP ID. The LSP ID can provide a clue as to the source of routing instability in an area. If multiple LSPs are causing an SPF run, only the LSP ID of the last received LSP is remembered. |
| Triggers | A list of all reasons that triggered a full SPF calculation. For a list of possible triggers, see the table below. |
| Trigger | Description |
|---|---|
| ADMINDIST | Another administrative distance was configured for the IS-IS process on this router. |
| AREASET | Set of learned area addresses in this area changed. |
| ATTACHFLAG | This router is now attached to the Level 2 backbone or it has just lost contact to the Level 2 backbone. |
| BACKUPOVFL | An IP prefix disappeared. The router knows there is another way to reach that prefix but has not stored that backup route. The only way to find the alternative route is through a full SPF run. |
| DBCHANGED | A clear isis * command was issued on this router. |
| IPBACKUP | An IP route disappeared, which was not learned via IS-IS, but via another protocol with better administrative distance. IS-IS will run a full SPF to install an IS-IS route for the disappeared IP prefix. |
| IPQUERY | A clear ip route command was issued on this router. |
| LSPEXPIRED | Some LSP in the link-state database (LSDB) has expired. |
| LSPHEADER | ATT/P/OL bits or is-type in an LSP header changed. |
| NEWADJ | This router has created a new adjacency to another router. |
| NEWAREA | A new area (via network entity title [NET]) was configured on this router. |
| NEWLEVEL | A new level (via is-type) was configured on this router. |
| NEWLSP | A new router or pseudonode appeared in the topology. |
| NEWMETRIC | A new metric was configured on an interface of this router. |
| NEWSYSID | A new system ID (via NET) was configured on this router. |
| PERIODIC | Typically, every 15 minutes a router runs a periodic full SPF calculation. |
| RTCLEARED | A clear clns route command was issued on this router. |
| TLVCODE | TLV code mismatch, indicating that different type length values (TLVs) are included in the newest version of an LSP. |
| TLVCONTENT | TLV contents changed. This normally indicates that an adjacency somewhere in the area has come up or gone down. The “Last trigger LSP” column indicates where the instability may have occurred. |
Reference for the above tables : https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_isis/command/irs-cr-book/irs-l1.html#wp7305177930
Let’s explore a little more on triggers which can force router to run full SPF calculations. For this I will do following tests.
1- Shutdown link between R3 and R4, can you guess if this will trigger full SPF on R1 or not ?Let’s see …
On shutting down the link between R3 and R4 I see below logs in SPF.
Before shut down :
R1#show isis spf-log Tag CORE: TID 0 level 1 SPF log When Duration Nodes Count First trigger LSP Triggers 02:32:20 0 7 1 PERIODIC SPFTYPE 02:17:20 0 7 1 PERIODIC SPFTYPE 02:02:20 0 7 1 PERIODIC SPFTYPE 01:56:08 0 1 3 R1.00-00 DELADJ DBCHANGED NEWLSP 01:56:07 0 2 3 R2.00-00 ADJMTIDCHG NEWLSP TLVCODE 01:56:06 0 4 2 R3.00-00 TLVCONTENT 01:56:05 1 7 3 ios.00-00 LSPHEADER TLVCONTENT 01:56:02 0 7 3 R1.00-00 NEWADJ TLVCONTENT 01:53:53 1 7 1 R3.00-00 TLVCONTENT 01:53:23 0 7 1 R4.00-00 TLVCONTENT 01:52:46 0 7 2 R3.00-00 TLVCONTENT 01:47:20 0 7 1 PERIODIC SPFTYPE 01:32:20 0 7 1 PERIODIC SPFTYPE 01:17:20 0 7 1 PERIODIC SPFTYPE 01:02:20 1 7 1 PERIODIC SPFTYPE 00:47:20 1 7 1 PERIODIC SPFTYPE 00:32:20 0 7 1 PERIODIC SPFTYPE 00:17:20 0 7 1 PERIODIC SPFTYPE 00:02:20 0 7 1 PERIODIC SPFTYPE
After Shutdown:
R1#show isis SPF-log Tag CORE: TID 0 level 1 SPF log When Duration Nodes Count First trigger LSP Triggers 02:13:38 0 1 3 R1.00-00 DELADJ DBCHANGED NEWLSP 02:13:37 0 2 3 R2.00-00 ADJMTIDCHG NEWLSP TLVCODE 02:13:35 0 4 2 R3.00-00 TLVCONTENT 02:13:35 1 7 3 ios.00-00 LSPHEADER TLVCONTENT 02:13:32 0 7 3 R1.00-00 NEWADJ TLVCONTENT 02:11:23 1 7 1 R3.00-00 TLVCONTENT 02:10:53 0 7 1 R4.00-00 TLVCONTENT 02:10:16 0 7 2 R3.00-00 TLVCONTENT 02:04:50 0 7 1 PERIODIC SPFTYPE 01:49:50 0 7 1 PERIODIC SPFTYPE 01:34:50 0 7 1 PERIODIC SPFTYPE 01:19:50 1 7 1 PERIODIC SPFTYPE 01:04:50 1 7 1 PERIODIC SPFTYPE 00:49:50 0 7 1 PERIODIC SPFTYPE 00:34:50 0 7 1 PERIODIC SPFTYPE 00:19:50 0 7 1 PERIODIC SPFTYPE 00:04:50 0 7 1 PERIODIC SPFTYPE 00:01:39 0 7 1 R3.00-00 TLVCONTENT 00:01:17 0 7 1 R4.00-00 TLVCONTENT -------------> Lets verify from the TABLE-2
“TLV contents changed. This normally indicates that an adjacency somewhere in the area has come up or gone down. The “First trigger LSP” column indicates where the instability may have occurred.”
Alright , so we know with this SPF log that some adjacency change occurred between R3 and R4. Isn’t it neat !!!
2- Do you think if I shutdown a loopback on the ISIS neighbor , for example shut down a loopback on R3 . Will it force R1 router to run full SPF calculations ? Lets see …
Before loopback shutdown :
R1#show isis SPF-log Tag CORE: TID 0 level 1 SPF log When Duration Nodes Count First trigger LSP Triggers 02:22:39 0 2 3 R2.00-00 ADJMTIDCHG NEWLSP TLVCODE 02:22:38 0 4 2 R3.00-00 TLVCONTENT 02:22:37 1 7 3 ios.00-00 LSPHEADER TLVCONTENT 02:22:34 0 7 3 R1.00-00 NEWADJ TLVCONTENT 02:20:25 1 7 1 R3.00-00 TLVCONTENT 02:19:55 0 7 1 R4.00-00 TLVCONTENT 02:19:18 0 7 2 R3.00-00 TLVCONTENT 02:13:52 0 7 1 PERIODIC SPFTYPE 01:58:52 0 7 1 PERIODIC SPFTYPE 01:43:52 0 7 1 PERIODIC SPFTYPE 01:28:52 1 7 1 PERIODIC SPFTYPE 01:13:52 1 7 1 PERIODIC SPFTYPE 00:58:52 0 7 1 PERIODIC SPFTYPE 00:43:52 0 7 1 PERIODIC SPFTYPE 00:28:52 0 7 1 PERIODIC SPFTYPE 00:13:52 0 7 1 PERIODIC SPFTYPE 00:10:41 0 7 1 R3.00-00 TLVCONTENT 00:10:19 0 7 1 R4.00-00 TLVCONTENT 00:02:20 0 7 2 R4.00-00 TLVCONTENT
After we shutdown the loopback on R3 :
R3(config-if)#do sh ip int br
Interface IP-Address OK? Method Status Protocol
GigabitEthernet1 10.10.10.13 YES NVRAM up up
GigabitEthernet2 10.10.10.17 YES NVRAM up up
GigabitEthernet3 unassigned YES NVRAM administratively down down
GigabitEthernet4 unassigned YES NVRAM administratively down down
Loopback1 3.3.3.3 YES NVRAM administratively down down
MPLS-Remote-Lfa1 10.10.10.17 YES unset up up
MPLS-Remote-Lfa2 10.10.10.13 YES unset up up
R3(config-if)#
On router R1
------------
R1#sh ip route 3.3.3.3
% Network not in table
R1#
R1#show isis SPF-log
Tag CORE:
TID 0 level 1 SPF log
When Duration Nodes Count First trigger LSP Triggers
02:24:57 0 4 2 R3.00-00 TLVCONTENT
02:24:56 1 7 3 ios.00-00 LSPHEADER TLVCONTENT
02:24:54 0 7 3 R1.00-00 NEWADJ TLVCONTENT
02:22:44 1 7 1 R3.00-00 TLVCONTENT
02:22:15 0 7 1 R4.00-00 TLVCONTENT
02:21:38 0 7 2 R3.00-00 TLVCONTENT
02:16:12 0 7 1 PERIODIC SPFTYPE
02:01:12 0 7 1 PERIODIC SPFTYPE
01:46:12 0 7 1 PERIODIC SPFTYPE
01:31:12 1 7 1 PERIODIC SPFTYPE
01:16:12 1 7 1 PERIODIC SPFTYPE
01:01:12 0 7 1 PERIODIC SPFTYPE
00:46:12 0 7 1 PERIODIC SPFTYPE
00:31:12 0 7 1 PERIODIC SPFTYPE
00:16:12 0 7 1 PERIODIC SPFTYPE
00:13:01 0 7 1 R3.00-00 TLVCONTENT
00:12:39 0 7 1 R4.00-00 TLVCONTENT
00:04:39 0 7 2 R4.00-00 TLVCONTENT
00:01:12 0 7 1 PERIODIC SPFTYPE
There is no new SPF full recalculations apart from the periodic calculation at the end . So the conclusion here is that if we flap links which are not directly attached to the SPF topology the event will not cause the SPF calculations . So here I have a question..
Question , we have OSPF routes getting redistributed to ISIS . If I flap any link in the OSPF domain, will it cause SPF recalculations in the ISIS domain ?
You may be knowing the answer, please test and tell me in the comment section.
Summary :
We have seen commands with which we can check ISIS process on the router. We have also checked how to verify if the adj is proper and we are learning something over a particular adj. Lastly we did a small experiment to see what kind of triggers can run the SPF calculations and which are the one’s doesn’t affect it. Stay tuned and happy learning.