JUNOS: IS-IS STUDY NOTES, PART 4 – FOR JUNIPER’S JNCIS-SP and JNCIS-ENT EXAMS

Oh my, you’ve come so far on this IS-IS journey! To think that an hour ago you barely knew what IS-IS stands for. And yet now, you’re a master!

You’ve already read Part 1 where I introduced you to the basic mechanics and configuration, and where you learned about IS-IS levels. Then you read Part 2 where we took a deeper dive into IS-IS messages, including the all-important Hello and LSP message types. We also learned about the elections that take place on broadcast networks. And then you read Part 3, where you learned about IS-IS areas, default routes, and using policies to leak from L2 to L1. You’re so smart now!

It’s finally time to really learn how to verify your work, and how to troubleshoot when things go wrong.

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 or face. Also, never forget to take a backup of the entire internet before you begin, just in case you delete the 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!

 

THE TOPOLOGY FOR THESE TESTS

Here’s the topology you’ve seen plenty of times before, this time with everything set to be in the same area of 49.0001. We have a “core” Level 2 network, with two Level 1 networks connecting to it.

Note that on the left, the vMX_2 to vMX_7 interface is entirely in Level 1. However, on the right, the vMX_4 to vMX_9 link is actually in both Level 1 and Level 2 at the same time. This is nice: we have a bit of overlap between the Level 1 and Level 2 networks on the right, which will let us see some cool stuff.

 

SHOW ISIS ADJACENCY

In Part 1 you saw how to configure IS-IS: you just add the interfaces you want to run it on. You can (and should) additionally turn off Level 1 and Level 2 either on a per-interface basis, or globally.

Let’s remind ourselves of the configuration on vMX_9, in set format. I’ve gone ahead and added some of the enhancements you learned about in Part 2:

root@vMX_9> show configuration protocols isis | display set
set protocols isis reference-bandwidth 100g
set protocols isis level 2 wide-metrics-only
set protocols isis level 1 wide-metrics-only
set protocols isis interface ge-0/0/0.0 point-to-point
set protocols isis interface ge-0/0/0.0 level 1 disable
set protocols isis interface ge-0/0/1.0 point-to-point
set protocols isis interface ge-0/0/2.0 point-to-point
set protocols isis interface ge-0/0/2.0 level 2 disable
set protocols isis interface lo0.0

There’s nothing new here to you, but notice that one interface explicitly turns off Level 1, another interface explicitly turns off Level 2, and a third interface doesn’t turn off either, which means that it runs both levels at once. That’s the interface facing vMX_4.

All interfaces are also configured to be point-to-point, which means there won’t be a DIS election any more. It’s a very good practice to configure this when it’s appropriate, because why bother creating a pseudonode when you don’t need one?

You also saw the command below in Part 1, which checks that adjacencies are up:

root@vMX_9> show isis adjacency
Interface             System         L State        Hold (secs) SNPA
ge-0/0/0.0            vMX_8          2  Up                   20
ge-0/0/1.0            vMX_4          3  Up                   23
ge-0/0/2.0            vMX_10         1  Up                   24

Interface ge-0/0/0.0 is Level 2, while ge-0/0/2.0 is Level 1. You’ll remember that we left ge-0/0/1.0 as the default behaviour, which is to try to take part in both levels. Interestingly, that interface is showing as “Level 3”. This immediately tells me that it’s a point to point interface.

How do I know that? Check this out: on broadcast L1/L2 interfaces, IS-IS will form two adjacencies – one for Level 1, and one for Level 2. However, on point-to-point interfaces, both levels are done in a single Hello message, which uses “Level 3” to really mean both levels.

To be clear, there isn’t a special secret Level 3; the number just represents both levels.

To show you what I mean, let’s delete the point-to-point configuration on either end of this interface on vMX_4 and vMX_9:

delete protocols isis interface ge-0/0/1.0 point-to-point

The result: is that two separate adjacencies are formed. We also now see the “SNPA” of the neighbor, the Sub-Network Point of Attachment (ie the MAC address).

root@vMX_9> show isis adjacency
Interface             System         L State        Hold (secs) SNPA
ge-0/0/0.0            vMX_8          2  Up                   24
ge-0/0/1.0            vMX_4          1  Up                    8  50:0:0:50:0:3
ge-0/0/1.0            vMX_4          2  Up                    7  50:0:0:50:0:3
ge-0/0/2.0            vMX_10         1  Up                   20

 

SHOW ISIS ADJACENCY DETAIL/EXTENSIVE

There are also detailed and extensive versions of that command. Let’s take a look at the detailed version:

root@vMX_9> show isis adjacency detail vMX_8
vMX_8
  Interface: ge-0/0/0.0, Level: 2, State: Up, Expires in 23 secs
  Priority: 0, Up/Down transitions: 1, Last transition: 00:16:35 ago
  Circuit type: 2, Speaks: IP, IPv6
  Topologies: Unicast
  Restart capable: Yes, Adjacency advertisement: Advertise
  IP addresses: 10.8.9.8
  IPv6 addresses: fe80::5200:ff:fe4b:2

Notice that I was able to refer to the neighboring router by its hostname. It’s so helpful I could almost cry!

The first line shows you what you already knew: the interface, the level, and the state. After that you see the “Last transition”, which is very helpful for troubleshooting, along with the “Up/Down transitions”, which is also clearly useful. If it’s flapped recently, or if the up/down count is quickly going up, you might have a problem! You can also see the address families it speaks, and its local addresses.

The extensive version of this command is the same, but it shows you the up/down transitions in more detail, with timestamps.

That output was from a point-to-point interface. A broadcast interface shows the same information, but additionally tells you who has been elected to generate the DIS for the broadcast network:

root@vMX_9> show isis adjacency detail vMX_4
vMX_4
  Interface: ge-0/0/1.0, Level: 1, State: Up, Expires in 8 secs
  Priority: 64, Up/Down transitions: 1, Last transition: 00:09:00 ago
  Circuit type: 3, Speaks: IP, IPv6, MAC address: 50:0:0:50:0:3
  Topologies: Unicast
  Restart capable: Yes, Adjacency advertisement: Advertise
  LAN id: vMX_4.02, IP addresses: 10.4.9.4
  IP6 addresses: fe80::5200:ff:fe50:3

vMX_4
  Interface: ge-0/0/1.0, Level: 2, State: Up, Expires in 7 secs
  Priority: 64, Up/Down transitions: 1, Last transition: 00:09:00 ago
  Circuit type: 3, Speaks: IP, IPv6, MAC address: 50:0:0:50:0:3
  Topologies: Unicast
  Restart capable: Yes, Adjacency advertisement: Advertise
  LAN id: vMX_4.02, IP addresses: 10.4.9.4
  IPv6 addresses: fe80::5200:ff:fe50:3

 

CLEAR ISIS ADJACENCY

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

 

SHOW ISIS INTERFACE

Here’s another useful one: “show isis interface” will show you whether an interface is point-to-point, what levels are enabled on the interface, and what the metric is for each level.

root@vMX_9> show isis interface
IS-IS interface database:
Interface             L CirID Level 1 DR        Level 2 DR        L1/L2 Metric
ge-0/0/0.0            2   0x1 Disabled          Point to Point        100/100
ge-0/0/1.0            3   0x1 vMX_4.02          vMX_4.02              100/100
ge-0/0/2.0            1   0x1 Point to Point    Disabled              100/100
lo0.0                 3   0x1 Passive           Passive                 0/0

In this output, every interface has a metric of 100, because they’re 1Gb interfaces, and we configured a reference-bandwidth of 100Gb. We also set “wide-metrics-only”. Remember that without this, the biggest metric that any one interface can advertise is 63.

You can see that Level 1 is explicitly disabled on ge-0/0/0, and Level 2 is explicitly configured on ge-0/0/2. You can also see that both of them are “Point to Point”.

Interface ge-0/0/1 doesn’t explicitly say that it’s a broadcast interface, but it does tell you the name of the DIS on the interface, which implies that it’s broadcast. The fact that there’s a separate DIS for Level 1 and Level 2 tells you that this is an L1/L2 interface.

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; I’m just telling you for the sake of completion.

Cool cool cool! Let’s look at the extensive version. You can see below that it tells you pretty much everything you’d ever want to know: MTU (“IIH max size”), the CSNP interval (how often the Complete Sequence Number PDU is sent out), the DIS election priority, the metric, the Hello interval, and who has won the DIS election (which is actually listed as the Designated Router, although that’s not strictly it’s name). I’m doing this on the broadcast interface:

root@vMX_9> show isis interface extensive ge-0/0/1.0
IS-IS interface database:
ge-0/0/1.0
  Index: 334, State: 0x6, Circuit id: 0x1, Circuit type: 3
  LSP interval: 100 ms, CSNP interval: 10 s, Loose Hello padding, IIH max size: 1492
  Adjacency advertisement: Advertise, Layer2-map: Disabled
  Interface Group Holddown Delay: 20 s, remaining: 0 s
  Level 1
    Adjacencies: 1, Priority: 64, Metric: 100
    Hello Interval: 9.000 s, Hold Time: 27 s
    Designated Router: vMX_4.02 (not us)
  Level 2
    Adjacencies: 1, Priority: 64, Metric: 100
    Hello Interval: 9.000 s, Hold Time: 27 s
    Designated Router: vMX_4.02 (not us)

 

SHOW ISIS DATABASE

This is where the fun stuff happens!

It’s in the database that you get to see the LSPs themselves, just like in the screenshots you saw in Part 2.

If you just do “show isis database” then you’ll see a list of every router in each level that your router is taking part in. You can then add “detail” or “extensive” to see the exact IPs and adjacencies that the router is advertising in its LSPs.

Let’s take a look at vMX_9 again, which has a presence in both the Level 2 backbone and in the Level 1 network on the right of the topology:

root@vMX_9> show isis database
IS-IS level 1 link-state database:
LSP ID                      Sequence Checksum Lifetime Attributes
vMX_4.00-00                      0x3   0x1e16      383 L1 L2
vMX_4.02-00                      0x1   0x1aa2      383 L1 L2
vMX_5.00-00                      0x4   0xc2d2     1137 L1 L2
vMX_9.00-00                      0x3   0xaf29      389 L1 L2
vMX_10.00-00                     0x4   0xf724     1175 L1 L2
  5 LSPs

IS-IS level 2 link-state database:
LSP ID                      Sequence Checksum Lifetime Attributes
vMX_2.00-00                      0x5   0x1226     1073 L1 L2
vMX_3.00-00                      0x5   0xe2e8     1156 L1 L2
vMX_4.00-00                      0x6   0x66ab     1077 L1 L2
vMX_4.02-00                      0x2   0x18a3     1169 L1 L2
vMX_7.00-00                      0x5   0x539e     1131 L1 L2
vMX_8.00-00                      0x6   0xa3ae     1158 L1 L2
vMX_9.00-00                      0x6   0xf8cd      389 L1 L2
  7 LSPs

You can easily see that Routers 2, 3, 4, 7, 8 and 9 are all in the backbone (Level 2), while routers 4, 5, 9 and 10 are in the Level 1 network. Another way of saying it is that vMX_4, 5, 9 and 10 have each generated a Level 1 LSP.

In addition, vMX_4 is responsible for generating the pseudonode for the broadcast interface between itself and vMX_9, because we removed the “point-to-point” configuration on those interfaces. This happens separately for Level 1 and for Level 2, which makes sense when you remember that they’re separate topologies. This is what the “vMX_4.02-00” LSP is for: it’s the pseudonode for that broadcast segment.

Remember that the point of this special pseudonode LSP is so that all interfaces on the shared broadcast network can just advertise a single connection to this pseudonode, rather than advertising every connection to every other interface on the shared broadcast network. On a network with a dozen or so interfaces on a shared network, this is really helpful. However, when only two router connect to each other, it actually makes things a bit more complicated, which is exactly the reason why it’s best to set interfaces to point-to-point where appropriate.

Let’s compare that output with a router that is only in Level 1. What does its database look like?

root@vMX_1> show isis database
IS-IS level 1 link-state database:
LSP ID                      Sequence Checksum Lifetime Attributes
vMX_1.00-00                      0x3   0xfafc      829 L1 L2
vMX_2.00-00                      0x3   0xe701      803 L1 L2
vMX_6.00-00                      0x3   0x4b61      827 L1 L2
vMX_7.00-00                      0x3   0x8d10      799 L1 L2
  4 LSPs

IS-IS level 2 link-state database:
LSP ID                      Sequence Checksum Lifetime Attributes
vMX_1.00-00                      0x4   0xf044      829 L1 L2
  1 LSPs

That’s interesting. It has a Level 1 database of four routers, which is correct – but it’s also generated an LSP for itself in Level 2, even though it doesn’t have any Level 2 adjacencies! This is because we didn’t turn off Level 2 globally on that router.

If a device is entirely in Level 1, it’s worth typing “set protocols isis level 2 disable” to turn the level off completely. This will also stop accidental Level 2 adjacencies forming, and is a lot easier than doing it on an interface-by-interface basis. The same goes for Level 2 routers, by turning off Level 1 globally.

 

SHOW ISIS DATABASE DETAIL

If you add the “detail” flag, you’ll see all the prefixes within that one LSP, and all of the routers that the router is connected to.

Staying on vMX_9, let’s look at vMX_8’s Level 2 LSP. You can do this on any router in the level, because each router should have exactly the same information about every other router that it knows about. Notice we don’t specify Level 2 in the CLI command, because vMX_8 is only in Level 2. But we could add it on if we wanted to be specific.

root@vMX_9> show isis database vMX_8 detail
IS-IS level 1 link-state database:

IS-IS level 2 link-state database:
vMX_8.00-00 Sequence: 0x6, Checksum: 0xa3ae, Lifetime: 907 secs
   IS neighbor: vMX_3.00                      Metric:      100
   IS neighbor: vMX_7.00                      Metric:      100
   IS neighbor: vMX_9.00                      Metric:      100
   IP prefix: 10.3.8.0/24                     Metric:      100 Internal Up
   IP prefix: 10.7.8.0/24                     Metric:      100 Internal Up
   IP prefix: 10.8.9.0/24                     Metric:      100 Internal Up
   IP prefix: 192.168.1.8/32                  Metric:        0 Internal Up
   V6 prefix: 2001:db8::8/128                 Metric:        0 Internal Up

If you’re only used to reading the OSPF database, then your jaw will be at the floor right now from how easy this is to read! You can immediately see the three routers that vMX_8 has a connection to, listed by name. You can also see the four IPv4 and the one IPv6 address connected to it.

There’s also an extensive version of this command, which I won’t show here because it’s massive! But in short, the extensive version of the command will show you everything in that router’s LSP, including what areas it takes part in, its ISO address, timers and lifetimes and checksums. Also, if you’re running MPLS traffic engineering then the extensive command will show you all the RSVP bandwidth reservations at each priority level.

By the way, you can also see that all five prefixes are “Up”. What does that mean? You might be tempted to think that it means they’re working and operational, but in fact it means something else – it’s used to stop routing loops that can occur when IPs are advertised between levels.

 

A QUICK NOTE ON THE DOWN BIT

Each advertisement comes with something called the Distribution bit, otherwise known as the Up/Down bit, or the Down bit for short.

If ever a prefix is advertised from Level 2 into Level 1, this bit is set as Down. 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.”

In Part 3 I added a default route on vMX_9, and advertised it into Level 1. Why didn’t vMX_4 redistribute it into Level 2? You may be tempted to think that it’s because the Down bit was set. Interestingly though, in my labbing I found that the down bit was NOT set!

I wanted to make sure I wasn’t going mad, so I made a second aggregate route for 192.0.0.0/8 on vMX_9, and also leaked this just into Level 1. I was surprised to see that the down bit WAS set for that route! So it seems like there’s some special rule that says “Don’t advertise a default route from Level 1 to Level 2.” I couldn’t find any documentation on it – but the labbing doesn’t lie!

On vMX_10 I am looking at vMX_9’s LSP. Notice that the 0/0 route is “Up”, while the 192/8 route is “Down”.

root@vMX_10> show isis database vMX_9 detail
IS-IS level 1 link-state database:

vMX_9.00-00 Sequence: 0x33, Checksum: 0x47a8, Lifetime: 1192 secs
   IS neighbor: vMX_4.02                      Metric:      100
   IS neighbor: vMX_10.00                     Metric:      100
   IP prefix: 0.0.0.0/0                       Metric:       10 Internal Up
   IP prefix: 10.4.9.0/24                     Metric:      100 Internal Up
   IP prefix: 10.9.10.0/24                    Metric:      100 Internal Up
   IP prefix: 192.0.0.0/8                     Metric:      210 Internal Down
   IP prefix: 192.168.1.9/32                  Metric:        0 Internal Up
   V6 prefix: 2001:db8::9/128                 Metric:        0 Internal Up

IS-IS level 2 link-state database:

Quirky bit of fun there! In any case, it’s the Down bit that makes sure that L2-to-L1 stuff doesn’t get re-advertised from L1-to-L2.

 

SHOW ISIS STATISTICS

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.

root@vMX_9> show isis statistics
IS-IS statistics for vMX_9:
PDU type       Received    Processed        Drops         Sent       Rexmit
LSP                  43           43            0           44            0
IIH                1941           38            0          986            0
CSNP                769          769            0          374            0
PSNP                 18           18            0           15            0
Unknown               0            0            0            0            0
Totals             2771          868            0         1419            0

Total packets received: 2771 Sent: 1419

SNP queue length: 0 Drops: 0
LSP queue length: 0 Drops: 0
SPF runs: 23
Fragments rebuilt: 13
LSP regenerations: 4
Purges initiated: 0

 

SHOW ISIS OVERVIEW

And one final chill command which does exactly what it says on the tin:

root@vMX_9> show isis overview
Instance: master
  Router ID: 192.168.1.9
  Hostname: vMX_9
  Sysid: 0000.0000.0009
  Areaid: 49.0001
  Adjacency holddown: enabled
  Maximum Areas: 3
  LSP life time: 1200
  Reference bandwidth: 100000000000
  Attached bit evaluation: enabled
  SPF delay: 200 msec, SPF holddown: 5000 msec, SPF rapid runs: 3
  IPv4 is enabled, IPv6 is enabled
  Traffic engineering: enabled
  Restart: Disabled
    Helper mode: Enabled
  Layer2-map: Disabled
  Source Packet Routing (SPRING): Disabled
  Post Convergence Backup: Disabled
  Level 1
    Internal route preference: 15
    External route preference: 160
    Prefix export count: 0
    Wide metrics are enabled
  Level 2
    Internal route preference: 18
    External route preference: 165
    Prefix export count: 0
    Wide metrics are enabled

 

THAT’S IT – FOR NOW!

You and me have come a LONG way over these past four 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. Well, sad news: our love is now over, because you’ve come to the end of the series!

There’s plenty more to cover in IS-IS. We’ve not touched Graceful Restart, or authentication, or overloading, or the unique properties of redistributing external prefixes into a Level 1 network. Hopefully though, these four posts have given you enough confidence to go Googling for more information, and to start adding IS-IS into your labs. I hope they’ve given you a fun introduction to this great protocol.

If you read these posts in order to go for the JNCIS-ENT or JNCIS-SP, the let me wish you the very best of luck with your studies towards this awesome certification!

Do leave a comment if you found this series helpful, and feel free to also comment sharing any other knowledge you have, or interesting stories of running IS-IS in the real world! Follow me on Twitter if you want to find out when I make new posts. 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.

 

PS: As it happens, I have written a few more posts on IS-IS, which you might like if you’re still hungry for more. Give this post a read where I explain how leaving everything to the L1/L2 default can lead to some seriously disastrous consequences! Then, how about this one where I show you how to use routing policy to remove point-to-point IP addresses from your routing table, to make things more scalable. I hope you enjoy them!

Leave a Reply

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