Category: IS-IS
Lab: Passive IS-IS Interfaces
The initial IS-IS labs covered the IS-IS basics. It’s time to move on to interesting IS-IS features (and why you might want to use them), starting with passive IS-IS interfaces.

Lab: Level-1 and Level-2 IS-IS Routing
One of the recipes for easy IS-IS deployments claims that you should use only level-2 routing (although most vendors enable level-1 and level-2 routing by default).
What does that mean, and why does it matter? You’ll find the answers in the Optimize Simple IS-IS Deployments lab exercise.

Weird Junos IS-IS Metrics
As part of the netlab development process, I run almost 200 integration tests on more than 20 platforms (over a dozen operating systems), and the amount of weirdness I discover is unbelievable.
Today’s special: Junos is failing the IS-IS metrics test.
The test is trivial:
- The device under test is connected to two IS-IS routers (X1 and X2)
- It has a low metric configured on the link with X1 and a high metric configured on the link with X2
The validation process is equally trivial:
Lab: Dual-Stack IS-IS Routing
Contrary to the OSPF world, where we have to use two completely different routing protocols to route IPv4 and IPv6 (unless you believe in the IPv4 address family in OSPFv3), IS-IS provided multi-protocol support from the very early days of its embracement by IETF. Adding IPv6 support was only a matter of a few extra TLVs, but even there, IETF gave us two incompatible ways of making IPv6 work with IS-IS.
Want to know more? You’ll find the details in the Dual-Stack (IPv4+IPv6) IS-IS Routing lab exercise.

Lab: Using IS-IS Metrics
It’s time for another “the vendor IS-IS defaults are all wrong” blog post. Wide IS-IS metrics were standardized in RFC 3784 in June 2004, yet most vendors still use the ancient narrow metrics as the default setting.
Want to know more? The Using IS-IS Metrics lab exercise provides all the gory details.

Lab: Configure IS-IS on Point-to-Point Links
From a very high-level perspective, OSPF and IS-IS are quite similar. Both were created in the Stone Age of networking, and both differentiate between multi-access LAN segments and point-to-point serial interfaces. Unfortunately, that approach no longer works in the Ethernet Everywhere world where most of the point-to-point links look like LAN segments, so we always have to change the default settings to make an IGP work better.
That’s what you’ll do in today’s lab exercise, which also explains the behind-the-scenes differences between point-to-point and multi-access links and the intricate world of three-way handshake.

IS-IS Labs: Explore IS-IS Data Structures
In the first exercise in the IS-IS labs series, you configured IS-IS routing for IPv4. Before moving on to more complex topics, let’s explore the data structures IS-IS created to represent your network.

IS-IS Labs: Configure IS-IS Routing for IPv4
In the first exercise in the IS-IS labs series, you’ll configure IS-IS routing for IPv4. The basic configuration is trivial, but you’ll also have to tweak the defaults that most vendors got wrong (we’ll discuss why those defaults are wrong in the next lab exercises).

I also tried to make the IS-IS labs more than just lab exercises. Each exercise includes a bit of background information or IS-IS theory; this one describes generic OSI addresses (NSAPs) and router addresses (NETs).
Running IS-IS over Unnumbered Ethernet Interfaces
Last time we figured out that we cannot run OSPF over unnumbered interfaces that are not point-to-point links because OSPF makes assumptions about interface IP addresses. IS-IS makes no such assumptions; IPv4 and IPv6 prefixes are just a bunch of TLVs exchanged between routers over a dedicated layer-3 protocol with ridiculously long network addresses.
Could we thus build a totally unnumbered IP network with IS-IS even when the network contains multi-access segments? It depends:
IS-IS Flooding Details
Last week I published an unrolled version of Peter Paluch’s explanation of flooding differences between OSPF and IS-IS. Here’s the second part of the saga: IS-IS flooding details (yet again, reposted in a more traditional format with Peter’s permission).
In IS-IS, DIS1 is best described as a “baseline benchmark” – a reference point that other routers compare themselves to, but it does not sit in the middle of the flow of updates (Link State PDUs, LSPs).
A quick and simplified refresher on packet types in IS-IS: A LSP carries topological information about its originating router – its System ID, its links to other routers and its attached prefixes. It is similar to an OSPF LSU containing one or more LSAs of different types.
LSA/LSP Flooding in OSPF and IS-IS
Peter Paluch loves blogging in microchunks on Twitter ;) This time, he described the differences between OSPF and IS-IS, and gracefully allowed me to repost the explanation in a more traditional format.
My friends, I happen to have a different opinion. It will take a while to explain it and I will have to seemingly go off on a tangent. Please have patience. As a teaser, though: The 2Way state between DRothers does not improve flooding efficiency – in fact, it worsens it.
Unequal-Cost Multipath in Link State Protocols
TL&DR: You get unequal-cost multipath for free with distance-vector routing protocols. Implementing it in link state routing protocols is an order of magnitude more CPU-consuming.
Continuing our exploration of the Unequal-Cost Multipath world, why was it implemented in EIGRP decades ago, but not in OSPF or IS-IS?
Ignoring for the moment the “does it make sense” dilemma: finding downstream paths (paths strictly shorter than the current best path) is a side effect of running distance vector algorithms.
Link-State Routing Protocols Are Eventually Consistent
One of my readers sent me this interesting question:
Assuming we are running a very large OSPF area with a few thousand nodes. If we follow the chain reaction of OSPF LSA flooding while the network is converging at the same time, how would all routers come to know that they all now have same view of area link states and there are no further updates or convergence?
I have bad news: the design requirements for link state protocols effectively prevent that idea from ever working well.
Reviving Old Content, Part 3
We had the usual gloomy December weather during the end-of-year holidays, and together with the partial lockdown (with confusing ever-changing rules only someone in Balkans could dream up) it managed to put me in OCD mood… and so I decided to remove broken links from the old blog posts.
While doing that I figured out how fragile our industry is – I encountered a graveyard of ideas and products that would make Google proud. Some of those blog posts were removed, I left others intact because they still have some technical merits, and I made sure to write sarcastic update notices on product-focused ones. Consider those comments Easter eggs… now go and find them ;))
Worth Reading: Redistributing Your Entire IS-IS Network By Mistake
Here’s an interesting factoid: when using default IS-IS configuration (running L1 + L2 on all routers in your network), every router inserts every IP prefix from anywhere in your network into L2 topology… at least on Junos.
For more details read this article by Chris Parker. I also wrote about that same problem in 2011.