It was a real honour to have recently passed my JNCIS-SP. In fact, one thing I will say is that Juniper really go to town to reward your victory: when I left the exam centre, Barry Juniper-Networks (the CEO of Juniper Networks) personally phoned me to congratulate me, and to thank me for boosting the name of Juniper by aligning myself with them. “The synergy of your personal brand with our corporate brand will create something truly magical”, he said to me through tears of overwhelming joy. “The future of the information superhighway is safe today, thanks to your courage and bravery.” I told him that I was humbled and flattered. I then did three sick wheelies in a row on my BMX, and purhased £70,000,000 worth of bitcoin.

Anyway, forget I said any of that. Let’s dive back in to IS-IS! Remember, read part one first before reading this!

PDUs, LSPs, AND OTHER PACKET TYPES

There’s four major types of message that IS-IS routers will send to each other, each with its own sub-types depending on whether the router is Level 1 or Level 2. Together these messages are known not as packets, but as PDUs – Protocol Data Units.

Let’s take a quick look at these PDUs. These captures were done by the truly magnificent Jeremy Stretch at PacketLife, a blog that you should go and read every single word of.

HELLO MESSAGES

These are sent out to a multicast address every 9 seconds by default. Each level has its own address, and a L1/L2 router will send them out on both. Fun fact: these messages are also called IIH, or IS-IS Hellos.

In an IIH header you’ll see the System ID of the sender, and also the Holding Time (what OSPF calls the dead interval), which is how long to wait before declaring the neighborship dead.

There’s three kinds of Hello: Level 1 LAN, Level 2 LAN, and point-to-point. Can you work out which one this is?

Notice that the router tells us the address of the Designated IS on the LAN, and also this router’s priority. The DIS is the IS-IS equivalent of OSPF’s Designated Router, and we’ll talk about it later on.

Next you’ve got some sweet TLVs, like the “Protocols Supported” TLV which shows that the router supports IP. You also see the Area Address TLV, the IP Interface Address TLV, and a whole lot of padding.

LINK-STATE PDUs (LSP)

This is the equivalent of an OSPF LSA. Every router generates an LSP, which contains all the information about the prefixes on the router, the connections it has to other routers, and of course, the metrics.

Each LSP has two essential pieces of information. First, notice the LSP-ID, which uniquely identifies this LSP. The last number in an LSP-ID is usually 00. If it’s anything else then it means the LSP was fragmented, because it was too big for one packet.

Secondly, notice the Sequence Number, which goes up every time something changes, for example if a prefix is added or removed on the router. Remember the LSP-ID and the Sequence Number, because we’ll mention them again in a moment.

The LSP also contains the router’s Hostname, its Area Addresses, and the prefixes on that router, which you can see in the IP Internal Reachability TLV. We’ll look at this TLV in more detail later on, when we talk about how metrics work in IS-IS.

COMPLETE SEQUENCE NUMBER PDU (CSNP)

When two routers – sorry, Intermediate Systems! – become neighbors, they swap their knowledge of the network. Of course, sending each other the full routing table would be a bit inefficient, so instead they give each other their CSNPs, or Complete Sequence Number PDU.

As you can see, a CSNP contains a list of all the LSP IDs and Sequence Numbers that a router knows about. Notice that the router 4444.4444.4444 appears twice. That’s because there’s one LSP for the router itself, and one for the router acting as the Designated Intermediate System. Again, we’ll come to that later on.

Note that a CSNP is just a list of LSP IDs, and doesn’t contain and prefix information itself. Think of a CSNP like an index, or the contents page in a book. If you don’t know what a book is: a book is a bit like a movie, except that some trees had to die for it to be made. And if you don’t know what a tree is, think of a tree as like a kind of haunted granddad that sucks moisture from the ground.

PARTIAL SEQUENCE NUMBER PDU (PSNP)

Once the routers have swapped CSNPs, they can check to see if there are any missing in their databases: they compare their own list of known LSPs with the CSNP received from their neighbor. If it sees one missing, or if it sees that a neighbor has a newer version, it requests it with a PSNP – the P standing for Partial.

I didn’t do a screenshot of this, because I want to encourage you to go here and look at Jeremy’s P2P capture. It’s very simple though: it’s just a smaller version of the CSNP, with a list of LSP-IDs and LSP Sequence Numbers. The router can then reply by sending the full LSP that the LSP-ID represents.

— Adjacencies can’t form between a level-1 only and a level-2 only router, but can form between all other combinations (L1 to L1, L2 to L2, L1/2 to L1/2).

— Two L1/L2 routers will form two adjacencies!

— The rules for forming an adjacency are more forgiving than in OSPF. For example, if they have different hold timers, the adjacency still forms, and each router just honours the other’s request.

— Cisco uses Hello/Hold timers of 10/30 seconds for routers, and 3/10 seconds for the DIS. Juniper uses 9/27 seconds for routers, and 3/9 for the DIS.

— Unlike OSPF, ISIS transitions to a full adjacency as soon as hellos are exchanged – NOT when the LSPs are exchanged. This means that if both routers see each other in their Hello messages, the adjacency goes to up.

— The six adjacency stages: New > One-Way > Initialising > Up > Down (when there’s an area mismatch, hold time expired, authentication failure) > Reject (also for when authentication doesn’t match – it cycles between Down and Reject).

— The CSNP is re-sent periodically on broadcast networks, by the DIS. Wait, what’s a DIS? Good question:

DESIGNATED INTERMEDIATE SYSTEM (DIS)

Yep, it’s another thing that IS-IS does in a similar-but-different way to OSPF!

In case you don’t know, here’s the theory: on a LAN segment it’s inefficient to send the same updates multiple times to each of your neighbors out of the same interface. So instead, one router is “designated” to receive and pass on all the updates in the network.

OSPF calls this this Designated Router. In IS-IS the DR is called the Designated Intermediate System – which makes sense, because Intermediate System is the ISO name for a router!

There’s no backup DIS, like there is in OSPF. And also unlike OSPF, if a router with a better priority comes online, it actually takes over the role of the DIS!

The DIS appears as a “pseudonode” in the network. Think of this “virtual” router as logically sitting in between all the routers on the segment. To quote from the JNCIA guide, “The pseudonode will advertise the neighbor relationships of all routers in its database update; the actual routers advertise a relationship with only the pseudonode”. This takes the strain out of the SPF calculation, because there’s less adjacencies to compute. (Pic also taken from the JNCIA guide, which you can and should buy and read!)

You’ll see the router that acts as the DIS twice in the database – once for the actual physical router, and then once for the virtual DIS.

In the screengrab of the Hello message above you can see the Priority field. Junos defaults to 64, and the biggest number wins the election. MAC addresses are used as a tie-breaker. To be more specific, the SNPA (Sub-Network Point of Attachment) is the tie-breaker, which includes both MAC addresses and DLCIs on frame-relay circuits.

Setting the priority is nice and easy, thanks to the sweet Junos hierarchy:

set protocols isis interface ge-0/0/0.0 level 1 priority 200

The usual 27 second hold time is reduced to 9 seconds on a DIS, which means the Hello PDU is sent every 3 seconds.

METRICS & REFERENCE BANDWIDTH

Like OSPF, ISIS uses the Shortest Path First algorithm to work out the best route to a prefix.

OSPF’s “cost” is based on the bandwidth of the link. Weirdly, by default ISIS doesn’t care about that – it just gives every link a cost of 10, regardless of the speed!!! (The one exception is loopback interfaces, which get a metric of 0.) This is obviously stupid, and you’ve got two choices to get around this.

First, you can increase or decrease the cost on a per-interface basis. You can even have different metrics for each level:

A much better idea is to just scrap this nonsense altogether, and base the cost on the bandwidth of the link. Just set your reference bandwidth of choice, and you’re “good” to “go”:

set protocols isis reference-bandwidth 10g

Fun fact that you’ll never need in the real world, but is interesting trivia: there’s actually four costs in an IS-IS TLV. As well as the “Default Metric”, IS-IS also allows you to calculate a path based on the Delay Metric, the Error Metric, and the Expense Metric, which is literally how much money the link costs! Having said that, even though these numbers are included in the advertisement (as you can see in this picture), these metrics are always set to 0, and no vendor that I know of actually uses them. Still, it tickles me that IS-IS has four costs, including one actual “cost” in the expense!

WIDE METRICS

By default the maximum cost a link can have is 63, because the three original prefix TLVs (IS reachability, IP Internal Reachability, and IP External Reachability) only gave 6 bits to the metric value – as you can see in the pic above.

Luckily, the gods of the internet made some extensions that support a 24-bit metric field. These two TLVs are called the Extended Reachability TLV, and the IP Extended Reachability TLV. When you use these, it’s called using the Wide Metric, and is configured like this:

set protocols isis level 2 wide-metrics-only

Interestingly, Junos advertises both by default, for backwards compatibility purposes! But even though it advertises both out of the box, it only uses the small metrics by default. So remember to configure the wide metrics if you want to use them!

A couple of other things to note when working out the best route:

— L1 paths are preferred over L2 paths

— Internal paths are preferred over external paths

— When you turn on Wide Metrics it removes the external flag – in other words, IS-IS doesn’t distinguish between internal and external prefixes when you’re using wide metrics.

THE ATTACHED BIT

Like OSPF, all traffic must go via the backbone, to prevent routing loops.

Unlike OSPF, a Level 1/2 router won’t automatically populate routes from its backbone into its level 1 area. Instead, the Level 1/2 router tells everyone in level 1 that it’s connected to the backbone, and that they should come to it for the route out.

That sounds a little like a default route, right? And in effect, it is. But interestingly, the Level 1/2 router doesn’t actually advertise a default route.

Instead, the level 1/2 router sets a bit known as the “attached bit” in its LSP. When a L1/L2 router sends its L1 LSP into the Level 1 network, this attached bit signals to the other routers that it can reach the backbone. The others L1 routers then generate a default route themselves, pointing to the L1/2 router. That’s pretty different to OSPF!

MESH GROUPS

When a network has a full mesh of routers, LSPs sent by one router will be received by all other routers – and then flooded back out again, which means that routers receive the same LSP multiple times. Not a big deal in a small network, but a real waste of resources in a big network.

You can stop this inefficiency by configuring a mesh group. It’s super simple: you just tell the router which interfaces are in the mesh group. Then, when an LSP comes in on an interface in the mesh group, it isn’t flooded out of any other interfaces in the mesh. Observe:

The number is a 32 bit value, with only local significance. Boom! Easy.

That’s it for part 2. How are you finding it? I hope these posts are useful to you. I’ve got to say, when I started studying IS-IS I thought I’d hate it, but as time goes on I’m finding I prefer it to OSPF! Go grab a cup of coffee, then come back for part 3, where we’ll go over the very best Junos verification and troubleshooting commands. Click here for part 3!

If this post was helpful to you, I’m always grateful if you share it on social media, Twitter, LinkedIn etc. I rarely use Twitter myself, but why not follow me anyway? And hey – why not leave a comment saying hi! Who knows – perhaps we’ll even end up getting married.

One thought on “JUNOS: IS-IS STUDY NOTES, PART 2 – FOR JUNIPER’S JNCIS-SP and JNCIS-ENT EXAMS”

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

Comment

Name *

Email *

Website

Hi!

I’m Chris, a network engineer from London. This is a blog of random knowledge I’ve acquired while studying for some sweet sexy network engineering certifications. Technically vendor neutral, but as you’ll soon find out, I love Junos very much.

As I learn cool new stuff, I try to write it up with plenty of jokes, and a generous dollop of silliness, so that you’ll have as much fun learning about networking as I do.