This is the third and final part of my whistle-stop tour of IS-IS, for people studying for their Juniper JNCIS-SP and JNCIS-ENT exams. If you’ve not read part 1 and part 2 yet, you might want to give them a go first. Click here to read part one! And then, click here for part two!

Or, perhaps you’re feeling dangerous? Well then read on!

Before we begin though, a quick word about safe troubleshooting. Please remember to wear gloves and goggles whenever you attempt to troubleshoot a routing protocol, just in case prefixes fly out of the screen and scold your hands or eyes. Also, never forget to take a backup of the entire internet before you begin, just in case you delete the entire world wide web by mistake. It’s happened before, and it’ll happen again. Finally, always – I repeat, ALWAYS – phone your friends and family to tell them that you love them. That’s not specific to troubleshooting – that’s just general life advice. You’re welcome!



You and me have come a long way over these past three posts. We’ve learned a lot together, been through so much. I dare say that in the process we’ve becomes best friends, brothers, sisters, perhaps even lovers. But not in a weird way, because this is a beautiful literary metaphor. It’s like something Byron would say.

Anyway, my point is this: we’ve learned tons about how IS-IS works, and how to configure it. Now, in this final post, let’s look at how to verify that everything’s “hunky dory” – and troubleshoot when it isn’t.



An essential command that shows your neighbors. This output is courtesy of the Junos Cookbook:

aviva@RouterG> show isis adjacency
Interface             System       L  State    Hold (Secs)  SNPA
fe-0/0/1.0            RouterH      2  Up                21  0:5:85:c1:d1:d1
fe-1/0/0.0            RouterA      1  Up                 6  0:5:85:ca:ca:70

Most of these columns in the output are self-explanatory. Sometimes you’ll see a 3 in the L column, which means the router is a L1/L2 router. The SNPA is the Sub-Network Point of Attachment, which is the neighbor’s MAC address.

It’s pretty annoying that it shows the MAC address instead of the IP address – remember, IS-IS is based on ISO. There’s two ways to get the neighbor IP: either search the ARP cache, or add the word detail to the end of the command. To quote the Juniper webiste:

user@host> show isis adjacency detail
  Interface: at-2/3/0.0, Level: 3, State: Up, Expires in 21 secs
  Priority: 0, Up/Down transitions: 1, Last transition: 00:01:09 ago
  Circuit type: 3, Speaks: IP, IPv6
  Topologies: Unicast, IPV6-Unicast Restart capable: Yes, Adjacency advertisement: Advertise
  LAN id: pro-bng3-c-F.02, IP addresses:
  IPv6 addresses: fe80::2a0:a514:0:4745
  Level 1 IPv4 Adj-SID: 299808, IPv6 Adj-SID: 29982



This one does what it says! Add the hostname at the end of the command, or alternatively add the word “all” if you’re bloodthirsty.



Again, from the marvellous Cookbook:

aviva@RouterG> show isis interface
IS-IS interface database:
Interface             L CirID Level 1 DR    Level 2 DR     L1/L2 Metric
fe-0/0/1.0            3 0x2   RouterG.02    RouterG.02     10/10
fe-1/0/0.0            1 0x3   RouterG.03    Disabled       10/10
lo0.0                 0 0x1   Passive       Passive        0/0

Again, a L of 3 means it’s a L1/2 router.

The CirID is the Circuit ID. Each interface on the router gets given one, to make it unique in the link-state database. 0x01 is shared between the point-to-point interfaces. Broadcast interfaces start at 0x02 and go up from there. It’s not too important in most situations.

You can also see the level 1 DIS, the level 2 DIS, and the level 1 and 2 metrics.



Here’s just the first few lines of output, taken from an example on Juniper’s website:

user@host> show isis route
IS-IS routing table                Current version: L1: 4 L2: 13
IPv4/IPv6 Routes
Prefix                  L    Version   Metric Type  Interface    NH Via         2       13       10    int   ae0.0        IPV4 camaro        2       13       20    int   so-6/0/0.0   IPV4 olympic
                                                     as0.0        IPV4 glacier        2       13       20    int   so-6/0/0.0   IPV4 olympic
                                                     ae0.0        IPV4 camaro        2       13       10    int   as0.0        IPV4 glacier        2       13       10    int   so-6/0/0.0   IPV4 olympic            2       13       20    int   so-6/0/0.0   IPV4 olympic            2       13       20    int   so-6/0/0.0   IPV4 olympic

The version isn’t too important – basically it’s the version of SPF that generated the route. Of more interest is whether the route is internal or external.

Notice in the output below that the next-hop (NH Via) mentions the router by name, not by IP address. Urgh! To be honest it’s probably better to use show route protocol isis in most situations.



You’ll only need to know this one if something has seriously gone wrong – it gives you a breakdown of each PDU the router has sent and received, and whether it was processed or dropped. You’ll also see the number of times that SPF has been run. You’ll even see the number of times an LSP has been regenerated, due to nearing the end of its lifetime.

Again, from Juniper themselves:

user@host> show isis statistics
IS-IS statistics for merino:

PDU type     Received  Processed     Drops      Sent    Rexmit
LSP             12227      12227         0      8184       683
IIH            113808     113808         0    115817         0
CSNP           198868     198868         0    198934         0
PSNP             6985       6979         6      8274         0
Unknown             0          0         0         0         0
Totals         331888     331882         6    331209       683

Total packets received: 331888 Sent: 331892

SNP queue length:  0      Drops:  0
LSP queue length:  0      Drops:  0

SPF runs:               1014
Fragments rebuilt:      1038
LSP regenerations:       425
Purges initiated:          0


Aah, this is where the fun stuff happens! I hope that Joseph will allow me to quote from his brilliant JNCIA study guide, which you should read from cover to cover.

In this output, we see each of the individual LSPs that a router generates. You see it listed by the LSP ID and the Sequence Number – the very same information that’s sent out in the CSNP packes!

user@Cabernet> show isis database
IS-IS level 1 link-state database:
LSP ID                     Sequence Checksum Lifetime Attributes

Merlot.00-00                   0x31   0x781a     1049 L1 L2 Attached
Shiraz.00-00                   0x39    0xf8b      835 L1
Shiraz.02-00                   0x37   0x7611      941 L1
Cabernet.00-00                 0x2d   0xc362     1015 L1 L2 Attached
  4 LSPs

IS-IS level 2 link-state database:
LSP ID                     Sequence Checksum Lifetime Attributes
Riesling.00-00                 0x3c   0x6ca1     1120 L1 L2
Merlot.00-00                   0x37   0xc288     1047 L1 L2
Cabernet.00-00                 0x37   0x66d9     1015 L1 L2
  3 LSPs

You’ll see that the LSP-ID is made up of the System ID (translated into the Hostname), and then two numbers. The first is the Circuit ID, and the second is the LSP Number field. Usually this is 00, but if the advertisement was bigger than can fit into one PDU then it’ll be split into multiple PDUs.

Notice in the Level 1 database that Shiraz appears twice. The “00-00” is the router itself, while the “02-00” is the pseudonode of the DIS.

If you add in a hostname, and add the detail flag, you’ll see all the prefixes within that one LSP. Here’s some edited output from Juniper’s website:

user@host> show isis database sisira.00-00 detail
IS-IS level 1 link-state database:

sisira.00-00 Sequence: 0x11, Checksum: 0x10fc, Lifetime: 975 secs
   IS neighbor: hemantha-CE3.02               Metric:       10
   IP prefix:                      Metric:       10 External Down
   IP prefix:                      Metric:       10 External Down
   IP prefix:                      Metric:       10 External Down
   IP prefix:                      Metric:       10 Internal Up
   IP prefix:                  Metric:       10 External Down
   IP prefix:                  Metric:       10 External Down
   IP prefix:                  Metric:       10 External Down
   IP prefix:                  Metric:       10 External Down
   IP prefix:                  Metric:        0 Internal Up

You’re probably wondering about that Up and Down column. Does “down” mean that the prefix is unreachable? Not quite – it indicates that the prefix was advertised from the Level 2 backbone, down into a Level 1 network.

Let’s introduce one final concept in this tour of IS-IS: the Up/Down bit. This is a one-bit flag in the Extended IP Reachability TLV, and it’s used to prevent routing loops. When a prefix is introduced into IS-IS the bit is set to 0. Then, to quote the RFC: “If a prefix is advertised from a higher level to a lower level (e.g., level 2 to level 1), the bit MUST be set to 1, indicating that the prefix has traveled down the hierarchy.”

This screenshot taken from inetsix’s packet capture, which is well worth a look to see all the TLVs in action.



Well, not really. There’s so much stuff we haven’t covered. We’ve not touched Graceful Restart, or authentication, or overloading, or the unique properties of redistributing external prefixes into a Level 1 network. For all those things, I recommend the excellent JNCIS study guide. As I say, these three posts are not a complete guide to IS-IS. But I hope they’ve given you a good and fun introduction to this great protocol.

In the mean time, best of luck with your studies towards this awesome certification!

Do leave a comment if you found this post helpful, and feel free to also comment sharing any other knowledge you have, or interesting stories of running IS-IS in the real world! And of course, if you enjoyed it, I’d love it if you shared it around on social media, Twitter, LinkedIn, and all the rest. Hell, if you fancy printing it and giving it to a pigeon to take to the other side of the country, go ahead and do it! It’s legal, and no-one can stop you.


Leave a Reply

Your email address will not be published. Required fields are marked *