Lessons (6, study in order)

Lesson 1 · Where exactly IS-IS and OSPF differ

Beginner · about 10 min

Goal: First build the right frame of reference: how similar they are, and what each of the five differences costs.

First, the similarities (you can carry your OSPF intuition straight over)

IS-IS and OSPF are both link-state protocols, and their skeletons work in exactly the same way:

① Form an adjacency with a neighbor, kept alive with Hello packets
② Package "who I'm connected to, at what cost, and which prefixes I can reach" and flood it across the whole network
③ Every device independently assembles a complete topology map (the database)
④ Run Dijkstra over that map to compute shortest paths

So the core intuition you built in the OSPF tab — "every device has a full topology map, so loops are mathematically impossible" — applies here without any change.
That's also the fundamental reason both of them beat RIP / EIGRP.

★ Then the five differences (the only thing you need to memorize in this lesson)

OSPF                       IS-IS
Runs over      IP (protocol 89)           directly on the link layer
Layer boundary inside a router (ABR)      on a link
Backbone       area 0, one area number    the contiguous set of all L2 routers
Broadcast net  DR / BDR, non-preemptive   DIS, preemptible, no BDR
election
How it extends adds a new LSA type       adds a TLV

★ Rows 1 and 5 are two sides of the same coin:
IS-IS doesn't depend on IP — everything is carried in TLVs — so supporting IPv6 just means adding one more TLV;
OSPF itself runs on top of IPv4, so it had to spin up an entirely separate OSPFv3.

That's exactly why carrier backbones favor IS-IS: extending it costs far less — MPLS-TE, Segment Routing, and everything else that came later were all bolted on as new TLVs.

Hands-on: see clearly that "the layer boundary is on a link"

Go to the Topology & Adjacency page and load the default "Two-level basics" scenario, and look only at R2:

· R2's adjacency to R1 is L1 (same area, 49.0001)
· R2's adjacency to R3 is L2 (across areas)

★ The same device, two neighbors, two different levels — the level is a property of the link.

Compare OSPF: an ABR is one device with "one foot in area 0, the other in a non-backbone area" — the area is a property of the interface, but "who is the ABR" is an identity of the device.
IS-IS has no such thing as an "ABR" identity — there's only "which level I speak on this particular link."

Key takeaways

• IS-IS and OSPF share the exact same skeleton: adjacency → flooding → topology map → Dijkstra
• The five differences: what it runs over / where the layer boundary is / how the backbone is defined / broadcast-network election / how it extends
• IS-IS doesn't run over IP, and everything is carried in TLVs → extending it costs little, which is why it's popular in carrier networks
• The layer boundary sits on a link, not on a router

Lesson 2 · System ID and area numbers (don't apply IP intuition here)

Beginner · about 8 min

Goal: Understand how IS-IS identifies a device, and exactly when area numbers must match.

System ID: 6 bytes, completely unrelated to IP

OSPF's Router-ID looks like an IP address (and is usually just taken from a loopback address), which makes people assume "a router's identity = some IP."

IS-IS's System ID is a pure identifier: 6 bytes, written as three groups of hex digits xxxx.xxxx.xxxx, and has absolutely nothing to do with IP.
The only hard requirement is: it must be unique across the entire IS-IS domain.

In real networks, to guarantee uniqueness and make troubleshooting easier, it's usually mapped mechanically from a loopback address:
10.1.1.1 → zero-padded to 010.001.001.001 → 0100.0100.1001.
That's just a human convention — the protocol itself requires none of it.

The full NET address

What you actually type in the configuration is the NET (Network Entity Title):

49.0001  .  0000.0000.0001  .  00
  ↑              ↑              ↑
area number   System ID     NSEL (always 00)

· 49 is a private AFI, the equivalent of a private IP address range — fine for enterprise networks and labs
· NSEL is always 00, meaning "this is a router" — just remember to write 00 and you're done

★ When area numbers must match

There's only one rule here, but it's the root cause of many real-world failures:

An L1 adjacency requires both ends to have exactly the same area number; an L2 adjacency does not.

A corollary (a very common failure in real networks): two devices both default to level-1-2, but have different area numbers →
the L1 adjacency can never form, and it automatically falls back to an L2-only adjacency.

★ This is a confusing symptom: display isis peer shows the neighbor, but only the Level-2 row is there, and intra-area routes simply never come up.
If this was actually meant to be an inter-area link, this is the correct behavior; if you assumed they were in the same area, then it's a misconfiguration.

Key takeaways

• System ID is 6 bytes, unique within the domain, unrelated to IP
• NET = area number + System ID + 00
• ★ An L1 adjacency requires matching area numbers; L2 does not
• Both configured as level-1-2 but with different area numbers → automatically falls back to an L2-only adjacency

Lesson 3 · Why adjacencies won't come up (four ways to check)

Troubleshooting · about 14 min

Goal: IS-IS adjacency failures share a common signature: the interface is up, you can ping across it, and there's still no neighbor.

Three states are all you need (compare OSPF's eight)

IS-IS's adjacency state machine has only three states: Down / Initializing / Up.

Of OSPF's eight states, the two key steps IS-IS skips are:
· No 2-Way state — on a broadcast network, everyone forms an adjacency with everyone else; there's no OSPF-style design of "only fully synchronize with the DR"
· No ExStart master/slave negotiation — it compares sequence numbers directly via CSNP / PSNP; whoever is missing something asks for it

★ Stuck at Initializing = one-way visibility: I received its IIH, but that IIH doesn't list me → meaning it can't receive my packets.
This is the classic symptom of a one-way link (a fiber pair broken in one direction, or one end shut down).

★ Four reasons adjacencies fail, in the order you should check them

① Level mismatch — one end only speaks L1, the other only speaks L2
　L1 IIH and L2 IIH are two different kinds of packets; an end that only speaks the other level simply never replies.
　Check: display isis interface and compare the circuit-level on both ends.

② Different area numbers while trying to form L1 — see the previous lesson.
　Check: if display isis peer shows only a Level-2 row, this is the most likely cause.

③ Duplicate System ID — two devices claiming to be the same identity.
　A distinctive symptom: routes flap constantly, and LSP sequence numbers climb rapidly (the two devices keep overwriting each other's LSPs).

④ Authentication mismatch — the IIH gets dropped outright.
　IS-IS authentication can be applied separately at the interface level (protects adjacencies) and the area/domain level (protects LSPs).

★★ A fifth case: the neighbor is Up, but the LSDB never finishes syncing

This is IS-IS's hardest failure to diagnose, and worth remembering on its own: mismatched MTU on the two ends.

IS-IS does no MTU negotiation, and unlike OSPF it never checks MTU inside a DD packet. So:
· IIH packets are small → they get through fine → the neighbor shows Up, everything looks normal
· LSP packets are large → they get dropped → the LSDB can never finish syncing → routes come and go

★ What makes it hard to diagnose is that the symptom and the root cause are very far apart: what you observe is "routes are unstable," while the cause sits in the physical interface's MTU setting — and the neighbor state, interface state, and ping are all perfectly normal.

Remember this causal chain and it can save you hours.

Key takeaways

• Three states: Down / Initializing / Up
• Stuck at Initializing = one-way visibility = a one-way link
• Four reasons adjacencies fail: level mismatch / area number / duplicate System ID / authentication
• ★ The fifth and sneakiest case: mismatched MTU → the neighbor is Up but the LSDB never finishes syncing

Lesson 4 · ★ L1's suboptimal routing (the core of this module)

Advanced · about 18 min

Goal: This is a pitfall unique to IS-IS, and one real networks genuinely fall into. Understand it, and you understand the price of hierarchy.

First, look at what information an L1 router actually has

An L1 router only maintains the LSDB of its own area. It has no visibility at all into topology outside its area.

So how does it reach anything outside the area? Through a default route:
An L1/L2 router sets the ATT (Attached) bit in its own L1 LSP, meaning "I'm connected to the backbone."
An L1 router inside the area sees this bit and generates a default route pointing at it.

★ Here's the key: the ATT bit only says "I'm connected to the backbone" — it says nothing about "how far it is once you leave through me."
So when an area has multiple exit points, L1 can only pick using one criterion: whichever is closest to me.

★★ "Closest to me" does not mean "best route to the destination"

The default scenario exists precisely to demonstrate this:

Area 49.0001 (L1)                     Area 49.0002

  R1(L1) ──10── R2(L1/L2) ──50── R4(L2) ──10── R5 → 10.2.2.0/24
    │                             │
    └────30──── R3(L1/L2) ───5────┘

R1 wants to reach 10.2.2.0/24. The only information it can see is "how far to each of the two exits":
· To R2 = 10 → closest, picks it
· To R3 = 30 → loses out

But once you factor in the path outside the area, the conclusion is exactly the opposite:
· Total via R2 = 10 + 50 + 10 = 70
· Total via R3 = 30 + 5 + 10 = 45 ← the actual optimum

★★★ R1 picked a path that's 25 more expensive, and it has absolutely no way of knowing that.
This isn't a misconfiguration — it's an inherent cost of hierarchical design.

Hands-on: run it yourself

Go to the Route Computation page, select R1, target prefix 10.2.2.0/24, and click Compute.

Focus on the "exit candidates" table:
· R2's row: intra-area cost 10 (what L1 can see), full-path cost 70 (what L1 can't see)
· R3's row: intra-area cost 30, full-path cost 45
· The UI marks "L1 picked this one" and "this is actually optimal" on two different rows

Then switch to R2 and take a look: R2 is L1/L2, so it can see the detailed routes outside the area — compare the two and you'll see exactly what information R1 is missing.

★ The fix: route leaking (RFC 2966)

The standard fix is to have the L1/L2 router inject L2's detailed routes into L1 — this is called route leaking.

After leaking, R1 can see "the cost of reaching 10.2.2.0/24 through each exit," so it can pick the optimal one itself, and the suboptimal route disappears.

On the Route Computation page, turn on R3's "route leaking" switch and recompute — the cost will drop from 70 to 45.

The cost: the L1 LSDB gets bigger. How much detail to leak is a trade-off you have to make yourself —
leaking everything is basically giving up the scalability benefit hierarchy was supposed to buy you — at that point you might as well not have hierarchy at all.

Another approach is tuning cost so "the closest exit" happens to also be the optimal one — it works, but it's fragile: any topology change, or a newly added exit, breaks it again.

★ Compare: OSPF doesn't have this problem

OSPF's ABR injects inter-area detailed routes (Type-3 LSAs) into the area, so routers inside the area can see "the total cost of reaching this prefix via each ABR" and pick the optimal one themselves.

★ So this is a deliberate design trade-off:
· OSPF: injects detail by default → never suboptimal, at the cost of a larger intra-area LSDB
· IS-IS: only gives one ATT bit by default → a much smaller LSDB, at the cost of possible suboptimality

IS-IS chose "cheaper," then uses route leaking as an on-demand remedy.
At backbone scale, this trade-off makes sense — but you need to know exactly where its cost lands.

Key takeaways

• ★ L1 has only one default route out of the area, pointing at the nearest ATT router
• ★ "The exit closest to me" ≠ "the exit that's optimal for the destination" → suboptimal routing
• The ATT bit only says "I'm connected to the backbone," not "how far it is from me"
• The fix: route leaking (RFC 2966). The cost is a larger L1 LSDB
• OSPF doesn't have this problem (ABRs inject Type-3 LSAs) — this is a deliberate design trade-off

Lesson 5 · DIS and the pseudonode (compared with DR/BDR)

Advanced · about 12 min

Goal: Election on a broadcast network. Three differences from OSPF, each one for a reason.

Why you need to elect a representative at all

If N devices sit on one Ethernet segment and directly advertise adjacencies with each other, the LSDB ends up with N×(N−1) relationships.

The fix is to elect a representative that abstracts the entire segment into a virtual node; every device then only advertises "I'm connected to this virtual node" → the count drops to N.

· OSPF calls it the DR, and the virtual node shows up as a Network LSA
· IS-IS calls it the DIS, the virtual node is called the pseudonode, and the DIS generates a pseudonode LSP

The idea is identical either way. Note that the cost from the pseudonode to every member is 0 — the segment itself shouldn't add any overhead.

★ Three ways it differs from DR/BDR

① The DIS can be preempted
　A device with a higher priority coming online will kick the current DIS out.
　OSPF's DR, once elected, keeps the role (unless it goes down) — to avoid unnecessary churn.
　IS-IS chose "predictable outcome": whoever has the highest priority should be the DIS, regardless of who showed up first.

② There's no BDR
　IS-IS considers DIS failover fast enough that no standby is needed.
　Why it's fast: the DIS sends IIH at 1/3 the interval of a regular router (3.3 seconds vs. 10 seconds), so its failure is detected much sooner.

③ Priority 0 still participates
　In OSPF, priority 0 means "I opt out of the election"; in IS-IS, 0 is just a very low priority.
　To keep a specific device from becoming DIS, you have to raise everyone else's priority instead.

Election rule: higher priority wins; if tied, the higher System ID wins.

Hands-on: watch preemption happen

Go to the Topology & Adjacency page and load the "DIS election and preemption" scenario. Four devices sit on one broadcast network; R3's priority is 90 and everyone else's is 64 → R3 is the DIS.

Now change R4's priority to 100 and check again — the DIS becomes R4. This never happens in OSPF.

★ While you're there, take a look at that pseudonode LSP on the LSDB page: the pseudonode number in the LSP-ID is 01 instead of 00 — that's exactly how you tell it apart from a regular LSP.

Real-world practice: just avoid broadcast networks entirely

For an Ethernet link between exactly two devices, it's usually manually configured as point-to-point:

interface GigabitEthernet0/0/1
 isis circuit-type p2p

The benefit: no DIS election, no pseudonode generated → the adjacency forms faster, the LSDB stays smaller, and there's one fewer class of failure to worry about.

Only leave it as broadcast type when multiple devices genuinely share the same switched segment.

Key takeaways

• DIS follows the same idea as DR: abstract the segment into one virtual node, dropping the relationship count from N² to N
• ★ Three differences: the DIS can be preempted / there's no BDR / priority 0 still participates
• The DIS's Hello interval is 1/3 that of a regular router, so failover is fast
• A pseudonode LSP's pseudonode number is non-zero; cost to every member is 0
• Real-world practice: configure a two-device Ethernet link as p2p

Lesson 6 · The narrow-metric 63 pitfall + a discontinuous backbone

Troubleshooting · about 12 min

Goal: Two default-value traps you need to know about.

★ Narrow metric: interface cost is capped at 63

IS-IS uses narrow metrics by default, so the interface cost field is only 6 bits → maximum 63, and the cumulative cost of an entire path is capped at 1023.

The practical consequences:
· Cost can only take values 1–63, so you can't spread costs sensibly based on bandwidth
· Traffic engineering isn't supported — the sub-TLVs TE needs don't fit inside a narrow metric

★ This is the same class of problem as EIGRP's classic metric topping out at 10 Gbps: a field left too narrow when the protocol was designed, patched up later only through extension.

The fix is cost-style wide, which extends cost to 24 bits.
MPLS-TE, Segment Routing, and IPv6 all require wide metrics.

⚠️ There's a trap when switching to wide metrics

Routers running narrow metrics and routers running wide metrics can't see each other's metrics when computing routes.

So switching the whole network straight to wide will drop routes during the transition window. The correct sequence is:

① First change the whole network to cost-style compatible   # sends both, accepts both
② Confirm the whole network has converged
③ Then change the whole network to cost-style wide

This is a textbook case of "a protocol upgrade needs a compatibility window."

★ A discontinuous backbone: far more hidden than in OSPF

IS-IS's backbone is "the contiguous set formed by all L2 routers," and it has no number at all.

The upside is flexibility: the backbone's shape grows with the topology, and nobody has to plan out an area 0.
The cost is that a break produces no error whatsoever:

· OSPF: there's at least the explicit concept of "area 0" — you can spot at a glance whether something isn't connected to it, and there's an explicit remedy in the form of virtual links
· IS-IS: when the backbone splits into two halves, each half believes everything is fine on its own side; the only symptom is that inter-area routes stop working — you have to manually check the continuity of L2 adjacencies yourself

So critical L2 links must always be built with redundancy.

Key takeaways

• ★ Narrow metric caps interface cost at 63 and path cost at 1023, and doesn't support TE
• Switching to wide metrics needs a transition through compatible first — switching directly drops routes
• ★ The backbone = the contiguous set of all L2 routers, with no number, and a break produces no error
• Critical L2 links need redundancy