Jump to chapter (9)
IS-IS for the SP core: what you will learn and the big picture
What you will learn in this module. You will build, read and troubleshoot IS-IS (Intermediate System to Intermediate System) the way SPCOR 350-501 expects: how a router is named by a NET, what the PDUs and TLVs carry, how level-1, level-2 and level-1-2 routers form adjacencies, how a DIS works on a LAN, how the attached bit gives an area a default route, how route leaking and the overload bit work, and how to troubleshoot a silent adjacency. Everything runs on IOS XE-style routers in the simulator, with real command output.
Prerequisites. The free spcor-start module (what an IGP does in a provider core) and the OSPF ideas from CCNA or ENARSI: link-state database, SPF, adjacency, metric. No IS-IS knowledge is assumed.
Analogy: districts and a ring road
Imagine a large city. Each district publishes a detailed street map that only district officers need: that is level 1. The city also publishes a ring-road map connecting the districts: that is level 2. A district officer who also sits on the ring-road committee holds both maps: that is a level-1-2 router. When a district resident needs to go to another district, the local map says nothing, so the officer answers "take the exit to the ring road", which is the default route that the attached bit creates. The whole IS-IS design is this idea: small local maps, one backbone map, and level-1-2 routers in between.
Why IS-IS in a provider
- It runs directly on layer 2. IS-IS packets ride in the data link frame (CLNS), not in IP. An IP misconfiguration cannot break the adjacency, and a remote host cannot send IS-IS packets to your router across the internet.
- TLVs make it extensible. Features such as IPv6, wide metrics, traffic engineering and segment routing arrive as new TLVs in the same LSPs.
- One backbone, simple hierarchy. Two levels are enough for networks with hundreds of routers, and many providers run a single level-2 domain.
- Stable under change. An IS-IS router belongs to one area as a whole, so area borders are links, not routers.
The module lab: four routers, two areas, one level-2 link between the border routers.
Your first IS-IS in six lines
The first lab (spcor-isis-two-areas) asks you to start IS-IS on four routers. On R2, a level-1-2 border router, the whole job is this reference configuration (taken from the lab solution):
! R2 - IOS XE style
router isis
net 49.0001.0000.0000.0002.00
interface Loopback0
ip router isis
interface GigabitEthernet0/0
ip router isis
isis network point-to-point
interface GigabitEthernet0/1
ip router isis
isis network point-to-point
The same lab, a few seconds later, on R2:
R2# show isis neighbors Tag null: System Id Type Interface IP Address State Holdtime Circuit Id R1 L1 Gi0/0 10.1.12.1 UP 27 00 R3 L2 Gi0/1 10.1.23.3 UP 27 00
Notice the Type column: R1 is a level-1 neighbour, R3 a level-2 neighbour. R2 holds both because it is level-1-2. Each of the next chapters explains one part of this picture.
Worked example. Metro Fibre wants Pune and Nashik in separate areas so that a flap in a Nashik access link does not trigger SPF in Pune. The engineer gives Pune routers the area 49.0001 and Nashik routers 49.0002, makes the two border routers level-1-2, and leaves the access routers level-1. Access routers hold only their own area; the border routers hold both and join the areas to each other.
Common mistake. Forgetting ip router isis on the loopback. The router forms adjacencies on its links but nobody can reach its loopback, so BGP and LDP sessions to it never come up.
Exam trap. On IOS the default router type is level-1-2, and the default metric style is narrow. Expect questions where a router behaves strangely because nobody set is-type or metric-style.
Silent core after a new router
A provider added router R9 to its IS-IS core and everything worked, except nobody could ping R9's loopback. The loopback interface was up but had no ip router isis line. Adding it advertised the prefix in R9's LSP and the ping worked immediately.
Lesson: in IS-IS you enable the protocol per interface, and the loopback is an interface like any other.
"Why does IS-IS not depend on IP?"
IS-IS was designed for the OSI protocol suite and its PDUs are carried directly in layer 2 frames (CLNS). It carries IP prefixes as data inside TLVs. So IS-IS adjacencies do not need IP connectivity, and the protocol is naturally limited to directly connected neighbours, which is good for security.
Key takeaways
- IS-IS is a link-state IGP that runs directly on layer 2 and carries data in TLVs.
- Level 1 is inside an area, level 2 is the backbone, level-1-2 routers do both.
- Area borders are links, because a router belongs to one area as a whole.
- On IOS you enable it with a NET under router isis and ip router isis per interface.
- IOS defaults: level-1-2, narrow metrics, distance 115, metric 10 per link.
The NET: how IS-IS names a router and its area
OSPF names a router with an IPv4-looking router ID and puts the area on each interface. IS-IS does it differently: one address per router, called the NET (Network Entity Title), which holds both the area and the router's unique name. Think of a postal address: the pin code is the area, the house number is the system ID, and the final "00" is a fixed suffix saying "deliver to the router itself".
Anatomy of a NET
A NET read from the right.
- AFI 49
- The first byte "49" is the Authority and Format Identifier for private addressing, the equivalent of RFC 1918 space. Providers use it almost always.
- Area ID
- Everything in front of the system ID. "49.0001" and "49.0001.0001" are different areas. The area can be 1 to 13 bytes.
- System ID
- Exactly 6 bytes on Cisco and Juniper, unique in the domain. It identifies the router in LSPs and in
showcommands. - NSEL
- Network service access point selector. It is always 00 on a router.
Choosing a system ID the SP way
Providers do not invent random IDs. They encode the loopback so the ID can be read at a glance. Take the loopback 10.0.255.4 and pad every octet to three digits: 010.000.255.004, then regroup the 12 digits into three blocks of four: 0100.0025.5004. The NET becomes 49.0001.0100.0025.5004.00. A second convention, used in the labs, simply numbers routers: 0000.0000.0001 for R1, 0000.0000.0002 for R2. Both are fine. What matters is that every router in the domain has a unique system ID, even in different areas, because level-2 LSPs travel between areas.
Configuring it
router isis
net 49.0001.0000.0000.0002.00
is-type level-1-2 ! the IOS default; shown for clarity
log-adjacency-changes
interface Loopback0
ip router isis
A router can have more than one NET (for example when migrating areas), but all NETs must share the same system ID. The net command is configured once under router isis, not per interface.
Names instead of numbers
Reading 0000.0000.0003 in outputs is hard. IS-IS therefore advertises the router's hostname inside its LSP (TLV 137, "dynamic hostname"), and IOS shows the name instead of the system ID wherever it can. You saw it already in show isis neighbors. The mapping table is:
R2# show isis hostname
Level System ID Dynamic Hostname (null)
* 0000.0000.0002 R2
2 0000.0000.0003 R3
1 0000.0000.0001 R1
The asterisk marks the local router. The first column shows the level at which the name was learned. The same neighbours seen through the CLNS commands, with the data-link address (SNPA), are:
R2# show clns neighbors Tag null: System Id Interface SNPA State Holdtime Type Protocol R1 Gi0/0 5254.0c04.4b01 Up 27 L1 IS-IS R3 Gi0/1 5254.0e04.4e02 Up 27 L2 IS-IS
show clns neighbors is useful because it lists the MAC address (SNPA) of each neighbour: proof that the two routers really see each other on layer 2.
Worked example. Router PUNE-PE1 has loopback 10.0.255.1 and sits in area 49.0001. Pad the octets: 010.000.255.001, regroup: 0100.0025.5001. NET: 49.0001.0100.0025.5001.00. The neighbour in Nashik, loopback 10.0.255.2, in area 49.0002: 49.0002.0100.0025.5002.00. The system IDs differ in the last block, as required, even though the areas also differ.
Common mistakes. (1) Duplicate system IDs: two routers claim the same name, LSPs overwrite each other and routes flap. Check the logs for a duplicate system ID warning. (2) Writing the NET with the wrong length, so that the "area" swallows part of the system ID. Always count six bytes before the final 00. (3) Changing the area on a level-1 router and losing the adjacency, because level-1 neighbours must share the area.
Exam trap. "What is the area in NET 49.0010.0000.0000.0007.00?" The answer is 49.0010: remove the last byte (NSEL) and the six bytes before it (system ID). Also, NSEL 00 means the NET identifies a router; any other NSEL would identify a transport entity.
Two routers, one name
During a rollout two engineers cloned the same configuration template for routers in different cities and forgot to change the system ID. The two routers shared 0000.0000.0009. The database showed one LSP whose content kept changing, SPF ran continuously and routes to both cities flapped. Giving one router a new NET and clearing the IS-IS process fixed it.
Lesson: system IDs must be unique across the whole domain, not only within an area.
"Decode this NET: 49.0002.0100.0025.5001.00."
The final 00 is the NSEL, the six bytes before it (0100.0025.5001) are the system ID and 49.0002 is the area. Add that the system ID here encodes loopback 10.0.255.1, which is a common provider habit, and that the area must match for level-1 adjacencies but the system ID must be unique everywhere.
Key takeaways
- One NET per router names both its area and its system ID.
- Read a NET from the right: NSEL 00, six-byte system ID, then the area.
- System IDs must be unique in the whole domain; many providers encode the loopback.
- AFI 49 is the private address format used almost everywhere.
- show isis hostname and show clns neighbors map names, system IDs and MACs.
PDUs, TLVs and the link-state database
IS-IS talks with four kinds of messages, called PDUs (Protocol Data Units). Think of a newsroom. Reporters (routers) write articles (LSPs) about their own links. Editors check that everybody has the same set of articles by sending contents lists (CSNPs) and, when something is missing, ask for it with a request slip (PSNP). Before any of that, neighbours must first say hello (IIH). Every PDU contains TLVs: Type, Length, Value blocks, like labelled boxes. Because the box has a type and a length, a router simply skips a box it does not understand. That is why IS-IS extends so easily.
The PDU types
| PDU | Name | Purpose |
|---|---|---|
| IIH | IS-IS Hello | Finds neighbours and keeps adjacencies alive. Three forms: LAN level-1, LAN level-2, point-to-point |
| LSP | Link State PDU | Describes a router's links and prefixes. Flooded to the whole level |
| CSNP | Complete Sequence Number PDU | A summary of every LSP in the database, used to synchronise |
| PSNP | Partial Sequence Number PDU | Acknowledges an LSP on point-to-point links, or requests a missing LSP |
The hello carries the system ID, the area address, the supported protocols, the hold time and, on LANs, the priority and the DIS. Two routers form an adjacency only if the parameters in the hello are compatible (chapter 4). The default hello interval is 10 seconds and the hold time is three hellos, 30 seconds. The Holdtime column in show isis neighbors counts down from that value and is refreshed by every hello; in the lab output it is around 27.
The LSP and its name
Each router originates one LSP per level, named like R2.00-00: system ID (shown as hostname), a pseudonode ID (00 for the router itself, 01, 02 and so on for LAN pseudonodes, chapter 5) and an LSP fragment number (00 for the first; larger LSPs are split into -01, -02). An LSP also has a sequence number that grows with each new version (a higher number wins), a checksum and a remaining lifetime that counts down from 1200 seconds. The originator refreshes the LSP every 900 seconds. If an LSP expires it is purged from the database.
An LSP is flooded hop by hop; sequence numbers decide which copy is newest.
Reading the database
The real database of R2 in the two-area lab, level-1 part first:
R2# show isis database detail
IS-IS Level-1 Link State Database:
LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL
R1.00-00 0x00000004 0x0AD2 1172/1200 0/0/0
Area Address: 49.0001
NLPID: 0xCC
Hostname: R1
IP Address: 1.1.1.1
Metric: 10 IS R2
Metric: 10 IP 10.1.12.0 255.255.255.0
Metric: 0 IP 1.1.1.1 255.255.255.255
R2.00-00 * 0x00000009 0x2F1C 1177/* 1/0/0
Area Address: 49.0001
Hostname: R2
Metric: 10 IS R1
Metric: 10 IP 10.1.12.0 255.255.255.0
Metric: 10 IP 10.1.23.0 255.255.255.0
Metric: 0 IP 2.2.2.2 255.255.255.255
How to read this: each block is one LSP. Area Address is TLV 1, NLPID 0xCC (TLV 129, supported protocols) says "IPv4 is routed here", Hostname is TLV 137, IP Address is TLV 132 (an IPv4 interface address of the router). Metric: 10 IS R2 is an adjacency (TLV 2, narrow), and IP ... lines are prefixes (TLV 128). The asterisk marks the local router's own LSP. In the LSP Holdtime/Rcvd column "1172/1200" means 1172 seconds of lifetime left and a received lifetime of 1200. The last column is ATT/P/OL: the attached bit, the partition-repair bit and the overload bit. Here R2's level-1 LSP has ATT = 1 (chapter 6).
Why two databases
A level-1-2 router such as R2 keeps two separate link-state databases, one for level 1 and one for level 2, runs SPF on each, and installs the best result. This is why show isis database prints two sections, each with its own LSPs.
R2# show isis database IS-IS Level-1 Link State Database: R1.00-00 0x00000004 0x0AD2 1172/1200 0/0/0 R2.00-00 * 0x00000009 0x2F1C 1177/* 1/0/0 IS-IS Level-2 Link State Database: R2.00-00 * 0x00000008 0xB5A5 1172/* 0/0/0 R3.00-00 0x00000008 0xB964 1172/1200 0/0/0
R2 originates two LSPs of its own (one per level) but R1 appears only in level 1 and R3 only in level 2.
Worked example. R1's LSP has sequence 0x4. A new link comes up, R1 regenerates the LSP with sequence 0x5 and floods it. R2 compares: 0x5 is higher than 0x4, so it replaces its copy, floods it onward and runs a partial or full SPF. Meanwhile an old copy with 0x4 arriving late is simply ignored, because its sequence number is lower.
Common mistake. Reading show isis database to prove a route exists. The database proves the router knows about the LSP; it does not prove SPF installed a route. If an LSP is present but the route is not, suspect a metric-style mismatch (see the spcor-isis-design module) or an SPF/ATT rule.
Exam trap. Remember the numbers: max LSP lifetime 1200 s, refresh 900 s, hello 10 s with hold 30 s (3.33 s hello and 10 s hold for a DIS). Remember also that IS-IS LSPs are not acknowledged on LANs; the DIS sends CSNPs instead, while point-to-point links use PSNPs as acknowledgements.
Stale LSP after a router was replaced
An engineer replaced a failed router and gave the new box the same NET. The database kept an old LSP of that router with a higher sequence number than the new box was generating, so the network briefly used outdated information. The new router noticed the higher sequence number, jumped above it and re-flooded its LSP within seconds, and everything converged. The engineer learned to expect a short period of confusion in the database when a router is swapped.
Lesson: sequence numbers rule. The newest LSP wins, and a router can overtake its own old LSP.
"What are CSNP and PSNP used for?"
A CSNP lists all LSPs in the database with their sequence numbers and checksums, so neighbours can compare and find missing or old LSPs. It is sent periodically by the DIS on a LAN and once at the start on a point-to-point link. A PSNP lists some LSPs: on point-to-point links it acknowledges received LSPs, and on any link it requests LSPs that the router found missing in a CSNP.
Key takeaways
- Four PDUs: IIH, LSP, CSNP, PSNP; all carry TLVs.
- LSP ID = system ID + pseudonode ID + fragment; sequence number picks the newest.
- LSP lifetime is 1200 s and the originator refreshes it every 900 s.
- A level-1-2 router keeps two databases, one per level.
- ATT/P/OL column shows attached, partition and overload bits.
Levels, router types and adjacency rules
In the analogy of chapter 1 each district has its own street map (level 1) and the districts share a ring-road map (level 2). Now we turn the analogy into rules. Every IS-IS router has a router type and every interface has a circuit type. Together they decide which adjacencies come up.
The three router types
| Type | IOS command | What it does |
|---|---|---|
| Level-1 | is-type level-1 | Forms L1 adjacencies only. Knows its own area. Uses a default route toward the nearest attached router to leave the area. |
| Level-2 | is-type level-2-only | Forms L2 adjacencies only. Part of the backbone. The area ID does not have to match its neighbours'. |
| Level-1-2 | is-type level-1-2 (default) | Keeps both databases. Connects an area to the backbone. Sets the ATT bit when it can reach other areas. |
The circuit type narrows things further per interface: isis circuit-type level-1, level-2-only or level-1-2 (the default follows the router type). Use it to stop level-1 hellos on a core link, for instance.
Who forms an adjacency with whom
| Neighbour A | Neighbour B | Result |
|---|---|---|
| L1 | L1, same area | L1 adjacency |
| L1 | L1, different area | None |
| L2 | L2, any area | L2 adjacency |
| L1-2 | L1-2, same area | L1 and L2 adjacencies (two) |
| L1-2 | L1-2, different area | L2 only |
| L1 | L2-only | None |
| L1-2 | L1 (same area) | L1 adjacency |
An L1 router cannot form an adjacency with an L2-only router; L1-2 routers in different areas form L2 only.
What else must match
Matching levels and areas are not enough. The two ends must also agree on:
- Network type. Both ends broadcast, or both ends point-to-point (
isis network point-to-point). Mismatch: hellos fly in both directions of different formats and no adjacency forms (chapter 5). - MTU. IS-IS pads hellos to the full interface MTU by default. A neighbour that cannot receive a hello of that size never sees it. IOS shows the MTU in
show clns interface(the lab shows 1497). - Authentication on the hello (chapter 7) and the same system-ID uniqueness (chapter 2).
- Layer 3 on LANs. Neighbours on a LAN need IP addresses in the same subnet; point-to-point links do not strictly, but the same subnet is good practice for IPv4 next hops on Ethernet.
On point-to-point links IS-IS uses a three-way handshake (RFC 5303) so each side knows the other sees its hello, a feature that avoids one-way adjacencies.
Seeing the levels in the lab
R2 holds both levels. The Type column of show isis neighbors shows what was negotiated on each link:
R2# show isis neighbors System Id Type Interface IP Address State Holdtime Circuit Id R1 L1 Gi0/0 10.1.12.1 UP 27 00 R3 L2 Gi0/1 10.1.23.3 UP 27 00
R2 and R3 are in different areas, so only level 2 forms, even though both are level-1-2. Now look at what the circuit type does. On R3 the interface towards R4 had been set to isis circuit-type level-2-only in the troubleshooting lab, while R4 is a level-1 router:
R3# show clns interface g0/0
GigabitEthernet0/0 is up, line protocol is up
Checksums enabled, MTU 1497, Encapsulation SAP
Routing Protocol: IS-IS
Circuit Type: level-2
Level-2 Metric: 10, Priority: 64, Circuit ID: R3.01
Number of active level-2 adjacencies: 0
Only level-2 hellos leave this interface, R4 wants level 1, so no adjacency. After no isis circuit-type the same command prints Circuit Type: level-1-2 and "Number of active level-1 adjacencies: 1".
Worked example. You have R5 in area 49.0003 configured as default (level-1-2) connected to R2 (49.0001, level-1-2). What forms? Different areas, so L1 cannot form; both are level-1-2 so L2 forms. If R5 were is-type level-1, nothing would form (different areas), and if R5 were level-2-only an L2 adjacency would form regardless of area.
Common mistake. Leaving every router at level-1-2 in a design that wants a single level-2 core. Each router then keeps two identical databases and runs SPF twice. If you only need level 2, set is-type level-2-only everywhere.
Exam trap. "Two level-1 routers in different areas are connected. What forms?" Nothing. And "two level-1-2 routers in different areas": only level 2. Level-1 adjacency needs a matching area; level-2 does not.
The access router that never saw its upstream
A new access router R4 in area 49.0002 was configured level-1 and cabled to R3. It showed no neighbour. The engineer found isis circuit-type level-2-only on R3's interface, copied from a core-link template. Removing it brought up the level-1 adjacency, the attached bit made R4 install a default route and traffic flowed.
Lesson: compare router type and circuit type on both ends of a silent link.
"What adjacencies form between two level-1-2 routers in the same area?"
Two adjacencies: one level-1 and one level-2, because they share an area and both run both levels. Show you also know that on a LAN each level elects its own DIS and that you can limit levels per interface with circuit-type.
Key takeaways
- Router types: level-1, level-2-only, level-1-2 (IOS default).
- L1 adjacencies need the same area; L2 adjacencies do not.
- L1-2 routers in different areas form L2 only.
- Circuit-type per interface can restrict levels and can silently stop an adjacency.
- Network type, MTU, authentication and unique system IDs must also be consistent.
LANs and links: DIS, pseudonode and point-to-point circuits
Picture a meeting room with ten people (a LAN with ten routers). If each person had to brief every other person separately that would be 45 conversations. Instead, the group elects one chairperson who keeps the minutes and reads out a short summary every few seconds. Everybody else just compares the summary with their own notes. In IS-IS the chairperson is the DIS, the Designated Intermediate System, and the "minutes" are a made-up router called the pseudonode.
What happens on a broadcast link
By default IOS treats an Ethernet interface as a broadcast circuit. The routers on it:
- Exchange LAN hellos (separately for level 1 and level 2) to multicast MAC addresses.
- Elect a DIS per level. The highest priority wins (default 64, range 0 to 127,
isis priority N [level-1|level-2]). A tie is broken by the highest MAC address (SNPA). - The DIS creates a pseudonode LSP that represents the LAN. Every router on the LAN lists the pseudonode as a neighbour, and the pseudonode lists all the routers. The pseudonode LSP ID ends with a non-zero number, such as R3.01-00. The number is the local circuit ID on the DIS.
- The DIS multicasts a CSNP every 10 seconds so that all routers can detect and repair missing LSPs, and it sends hellos three times as fast (every 3.33 s, hold 10 s) so a DIS failure is noticed quickly.
A star-shaped description replaces the full mesh: the LSDB holds n links to one pseudonode instead of n(n-1)/2 links between routers. That is why the pseudonode exists.
The DIS represents a LAN as one pseudonode in the database.
How IS-IS differs from OSPF's DR
| Feature | OSPF DR | IS-IS DIS |
|---|---|---|
| Backup | BDR exists | No backup DIS |
| Preemption | No: first elected stays | Yes: a better priority takes over at once |
| Adjacencies | Only to DR/BDR | Routers are adjacent to everyone |
| Priority 0 | Never elected | Still eligible (lowest preference) |
| Per level | n/a | One DIS for L1 and one for L2, possibly different routers |
Point-to-point circuits
A core link joins exactly two routers, so a DIS and pseudonode are pure overhead. On Ethernet core links provider engineers configure isis network point-to-point. Then: no election, no pseudonode LSP, no periodic CSNP, one hello type for both levels, a three-way handshake, and PSNP acknowledgements. Adjacencies come up faster and the database is smaller. Both ends must be configured the same way.
! Point-to-point link (two-area lab, after the p2p step) R2# show isis neighbors R1 L1 Gi0/0 10.1.12.1 UP 27 00 R3 L2 Gi0/1 10.1.23.3 UP 27 00
Circuit Id 00 marks a point-to-point circuit. On a LAN the Circuit Id is the DIS name and a pseudonode number. From the troubleshooting lab, once its four tasks are solved, the LAN links show:
R1# show isis neighbors R2 L1 Gi0/0 10.1.12.2 UP 22 R2.01 R3# show isis neighbors R4 L1 Gi0/0 10.1.34.4 UP 22 R3.01 R2 L2 Gi0/1 10.1.23.2 UP 22 00
R2.01 says "on this LAN the DIS is R2 and the pseudonode is number 01". The R3-R4 LAN uses R3.01, because the last task of the lab gives R3 a higher level-1 priority:
R3# show clns interface g0/0
Level-1 Metric: 10, Priority: 100, Circuit ID: R3.01
DR ID: R3.01
Number of active level-1 adjacencies: 1
Level-2 Metric: 10, Priority: 64, Circuit ID: R3.01
On R4 you can also see the pseudonode LSP itself in the database, with its own LSP ID:
R4# show isis database
IS-IS Level-1 Link State Database:
LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL
R3.00-00 0x00000004 0x8867 1175/1200 1/0/0
R3.01-00 0x00000001 0x5490 1175/1200 0/0/0
R4.00-00 * 0x00000002 0x493B 1175/* 0/0/0
Worked example. Three routers on one VLAN, all default priority 64. R1 has MAC 5254.0001, R2 5254.0002, R3 5254.0003. Tie on priority, so the highest MAC wins: R3 is DIS for both levels. An engineer sets isis priority 100 level-1 on R1. Because the DIS is preemptive, R1 becomes the level-1 DIS at once and a new pseudonode LSP is generated, while R3 stays the level-2 DIS. Two DIS on the same LAN, one per level, is perfectly normal.
Common mistakes. (1) Configuring point-to-point on one end only: one side sends p2p hellos and the other LAN hellos, so the adjacency stays down. (2) Setting priority 0 and assuming that router can never be DIS: in IS-IS it still can be, if nobody else is eligible. (3) Using a switch in the middle of a "point-to-point" link: it is a LAN, so keep the broadcast type or use a real p2p.
Exam trap. The exam may ask which router is the DIS from a table of priorities and MACs. Highest priority wins, then highest MAC, per level, with preemption and no backup. Pseudonode LSP IDs end in a non-zero number.
The router that kept winning the election
Whenever a lab router rebooted on a shared LAN, routing paused briefly: a replacement with a higher MAC took over as DIS, flooded a new pseudonode LSP, and every router re-ran SPF. The team moved all core links to point-to-point, so there was no DIS and no election, and reboots no longer disturbed neighbours.
Lesson: on two-router links, point-to-point removes a source of instability.
"Why does an SP engineer configure isis network point-to-point on Ethernet links?"
An Ethernet interface defaults to a broadcast circuit, which runs a DIS election and creates a pseudonode LSP and CSNP traffic even if only two routers are present. Point-to-point avoids all of this, brings the adjacency up faster, uses a three-way handshake and reduces the database size. It must be set at both ends.
Key takeaways
- On a LAN the DIS (per level) creates a pseudonode LSP and sends CSNPs every 10 seconds.
- Highest priority then highest MAC wins; DIS is preemptive and has no backup.
- Circuit Id such as R3.01 shows the DIS and pseudonode; 00 means point-to-point.
- Core links use isis network point-to-point on both ends.
- Priority 0 is still eligible in IS-IS, unlike OSPF.
Leaving an area: the attached bit, default routes and route leaking
A level-1 router knows only its own area. When it needs a destination in another area, it has no route. In the district analogy, the local map says nothing about other districts, so the officer sends the resident "to the ring road". IS-IS builds that signpost automatically with the attached (ATT) bit. And if the signpost is too crude, you can leak specific routes from the ring road down into the district.
Step 1: what flows up and what flows down
- Level 1 to level 2 (up): automatic. A level-1-2 router puts all the prefixes of its level-1 area into its level-2 LSP. So backbone routers know every area's prefixes. You saw this: R3 learned R1's loopback 1.1.1.1 as
i L2. - Level 2 to level 1 (down): nothing by default. Level-1 routers do not receive level-2 routes. This keeps level-1 databases small.
Step 2: the attached bit gives a default route
A level-1-2 router that can reach another area through level 2 sets the ATT bit in its level-1 LSP. Every level-1 router that sees an LSP with ATT = 1 installs a default route (0.0.0.0/0) toward the nearest such router, by lowest metric. R2's LSP in the lab shows it:
R2# show isis database
IS-IS Level-1 Link State Database:
LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL
R1.00-00 0x00000004 0x0AD2 1172/1200 0/0/0
R2.00-00 * 0x00000009 0x2F1C 1177/* 1/0/0
And on R1 the result, taken before any leaking was configured:
R1# show ip route isis
Gateway of last resort is 10.1.12.2 to network 0.0.0.0
i*L1 0.0.0.0/0 [115/10] via 10.1.12.2, 00:00:05, GigabitEthernet0/0
2.0.0.0/32 is subnetted, 1 subnets
i L1 2.2.2.2 [115/10] via 10.1.12.2, 00:00:05, GigabitEthernet0/0
10.0.0.0/24 is subnetted, 1 subnets
i L1 10.1.23.0 [115/20] via 10.1.12.2, 00:00:05, GigabitEthernet0/0
The route has code i*L1: IS-IS, candidate default, level 1. R1 pings R4's loopback 4.4.4.4 without having a specific route, because the packet follows the default route to R2, and R2 knows the way. The first ping character in the lab is a dot (the ARP/first packet), then four successes: normal.
The attached bit in R2's level-1 LSP turns into a default route on R1.
Step 3: leak specific routes down
A default route is cheap but crude. If an area has two exits, level-1 routers choose the nearest by metric to the exit, not by the best path to the destination: sub-optimal routing. Fix it by leaking selected level-2 prefixes into level 1 on the level-1-2 router. In the lab, R2 leaks only R4's loopback with a prefix list and route-map:
! Reference configuration from the lab solution (R2)
ip prefix-list LEAK seq 5 permit 4.4.4.4/32
route-map L2-TO-L1 permit 10
match ip address prefix-list LEAK
router isis
redistribute isis ip level-2 into level-1 route-map L2-TO-L1
R1# show ip route isis
i*L1 0.0.0.0/0 [115/10] via 10.1.12.2, 00:00:28, GigabitEthernet0/0
4.0.0.0/32 is subnetted, 1 subnets
i ia 4.4.4.4 [115/30] via 10.1.12.2, 00:00:23, GigabitEthernet0/0
R1 now holds a specific route to 4.4.4.4 with code i ia (IS-IS inter-area), metric 30 (10 + 10 + 10). 3.3.3.3 is not leaked, so it does not appear: only what the prefix list permits goes down. In the database, R2's level-1 LSP now carries the leaked prefix with the up/down bit set.
The up/down bit is a loop guard. A prefix leaked from level 2 into level 1 is marked "down". If a level-1-2 router sees a prefix with this mark in a level-1 LSP, it will not advertise it back up into level 2. Without it, leaked routes could ping-pong between levels.
Step 4: summarise to keep tables small
The other tool is summarisation: an area border router advertises one summary instead of many prefixes. On IOS it is configured under router isis as summary-address <prefix> <mask> level-2 (reference command; not part of the lab). The summary exists as long as at least one more-specific route exists inside it.
Worked example. An area has two exits, R2 (to the east) and R9 (to the west). With only the default route a level-1 access router picks the closer exit, even for destinations that are far cheaper through the other exit. The engineer leaks the prefixes of the eastern and western regions from R2 and R9 respectively. Each access router now has specific routes and picks the exit that is truly best for each prefix.
Common mistakes. (1) Leaking everything with no filter: level-1 routers then carry the whole backbone table and the benefit of areas is lost. (2) Expecting level-1-only routers to learn anything without ATT: if no level-1-2 router has ATT = 1, no default route appears, and inter-area traffic fails. (3) Forgetting that a router in level 2 only never sets ATT because it has no level-1 LSP.
Exam trap. The ATT bit is set only in level-1 LSPs and only by a level-1-2 router that has a level-2 adjacency to another area. L1-only routers install the default route; L2 routers do not look at ATT at all. Leaking goes from level 2 to level 1 with the up/down bit; level 1 to level 2 is automatic.
Half the traffic took the long way
An area with two border routers used only default routes. Access routers sent all traffic to whichever border router was nearest, and half of it then had to cross the backbone again to reach a destination close to the other border router. The engineer leaked the 20 busiest prefixes into level 1 on both border routers with a prefix list. Latency for those destinations dropped and the extra backbone load disappeared.
Lesson: default routes are simple and sub-optimal; leak the prefixes that matter.
"How does a level-1 router reach a destination in another area?"
A level-1-2 router with a level-2 path to other areas sets the ATT bit in its level-1 LSP. Level-1 routers then install a default route to the nearest ATT router. If that is not good enough, level-2 prefixes can be leaked into level 1 with a policy, using the up/down bit to prevent loops, and the border router can summarise level-1 prefixes towards level 2.
Key takeaways
- Level 1 to level 2 flows automatically; level 2 to level 1 does not.
- The ATT bit in a level-1 LSP makes level-1 routers install a default route (i*L1).
- Route leaking (redistribute isis ip level-2 into level-1) gives specific routes, shown as i ia.
- The up/down bit stops leaked routes from re-entering level 2.
- Filter leaking and use summaries to keep level-1 tables small.
Operating IS-IS: overload bit, timers, metrics, passive interfaces and authentication
A working IS-IS network still needs care: you must take routers out of service without dropping traffic, tune how fast the network reacts, advertise loopbacks without opening adjacencies on customer links, and make sure that nobody can inject false routing information. This chapter collects those day-two tools. Where the simulator does not implement a command, it is shown as reference configuration and says so.
1. The overload bit: draining a router for maintenance
Setting the overload (OL) bit in a router's LSP tells all other routers: "I am still here, but do not send transit traffic through me." Routes to the router's own prefixes remain, but SPF no longer uses it as a path to anything else. Traffic shifts to other paths. When the router is back, clear the bit. Cisco also offers the bit at startup, so a rebooted router does not attract traffic until it has converged.
! Lab command (works in the simulator) router isis set-overload-bit ! Reference configuration, not simulated: wait 300 s after boot router isis set-overload-bit on-startup 300
The effect on the lab's database, seen from R1 (the third number of ATT/P/OL is the OL bit):
R1# show isis database
IS-IS Level-1 Link State Database:
LSPID LSP Seq Num LSP Checksum LSP Holdtime/Rcvd ATT/P/OL
R1.00-00 * 0x00000004 0x0AD2 1172/* 0/0/0
R2.00-00 0x0000000A 0x5B5F 1200/1200 1/0/1
R2's LSP has a new sequence number (0xA instead of 0x9) and OL = 1. R2 is now drained. Other routers keep the adjacency and the database entry, so there is no hold-time expiry or reconvergence storm when it returns.
2. Interface metrics and timers
Every IS-IS interface on IOS starts with metric 10, whatever the speed. To prefer one path, raise the metric on the others (chapter 4 of spcor-isis-design explores design choices). Hello timing can also be tuned per interface. In the lab:
R2# show running-config interface g0/0 interface GigabitEthernet0/0 ip address 10.1.12.2 255.255.255.0 ip router isis isis network point-to-point isis metric 30 isis hello-interval 3 isis hello-multiplier 4 R2# show clns interface g0/0 Level-1 Metric: 30, Priority: 64, Circuit ID: R2.00 Level-2 Metric: 30, Priority: 64, Circuit ID: R2.00 Next IS-IS Hello in 3 seconds
Hello interval 3 s times multiplier 4 gives a hold time of 12 s instead of the default 30 s, so a dead neighbour is noticed faster. The metric is advertised at 30 on both levels. For sub-second detection, providers do not push hello timers to the limit; they use BFD instead (spcor-ha module). Reference commands: bfd all-interfaces under router isis and bfd interval 300 min_rx 300 multiplier 3 on the interface; not simulated here.
Other timers worth knowing as reference: spf-interval, prc-interval and lsp-gen-interval throttle how often SPF, partial route calculation and LSP regeneration run, each with a maximum wait, an initial wait and a second wait (exponential backoff). They protect the CPU in a flapping network. Defaults are fine for most designs; change them only after measuring.
3. Passive interfaces and advertising loopbacks
A passive interface is advertised in the LSP but sends no hellos, so no adjacency can form on it. Use it on loopbacks (which have nothing to talk to) and on customer-facing links. In the lab form:
router isis
passive-interface Loopback0
passive-interface GigabitEthernet0/2 ! customer link: advertised, no hellos
On large networks, reference command advertise passive-only under router isis advertises only the prefixes of passive interfaces and leaves out the transit link prefixes; it shrinks the table and the attack surface. It needs BGP or LDP to use loopbacks everywhere, which is the provider design anyway.
4. Authentication: only trusted routers may join
Without authentication anyone who plugs a router into a core link can send IS-IS hellos or LSPs. Defence uses three scopes: hello authentication (interface level, protects adjacencies), area authentication (level-1 LSPs and SNPs) and domain authentication (level-2 LSPs and SNPs). Cisco IOS XE builds them on a key chain. This is reference configuration, not simulated in the lab, and syntax can vary with the release; verify it on your platform:
! Reference configuration (secrets are placeholders)
key chain ISIS-KEYS
key 1
key-string <secret>
interface GigabitEthernet0/1
isis authentication mode md5 level-2
isis authentication key-chain ISIS-KEYS level-2
router isis
authentication mode md5 level-2
authentication key-chain ISIS-KEYS level-2
Both ends must match, or no adjacency (hello authentication) or no LSP acceptance (area and domain authentication) results. MD5 is old; where the platform and release support it, prefer the HMAC-SHA algorithms of RFC 5310 through the key chain, and rotate keys with overlapping lifetimes. Authentication is one layer: also filter IS-IS from customer ports and use passive interfaces. The spcor-sp-security module covers more.
Worked example. R2 must be upgraded tonight. The engineer sets set-overload-bit at 22:00, waits until show ip route on neighbours no longer uses R2 as a next hop, reboots at 22:15, and after the reboot leaves set-overload-bit on-startup 300 in place so that R2 only takes transit traffic after five minutes. Customers never notice.
Common mistakes. (1) Setting aggressive hello timers on both ends but not matching them: IS-IS does not require equal intervals because the hold time comes from the sender's hello, but a mismatch with a slow neighbour can cause flaps. (2) Enabling authentication on one end first: the adjacency drops. Plan it as a coordinated change (use commit confirmed logic or an out-of-band path). (3) Forgetting to clear overload after maintenance: the router stays drained and silently carries no transit traffic.
Exam trap. The OL bit does not make the router unreachable: its own loopback and connected prefixes are still reachable; only transit is avoided. And hello authentication, area authentication and domain authentication are different things with different scopes.
The router that stayed quiet
After a weekend maintenance, traffic through one core router stayed at zero for days. The engineer checked the interfaces (up) and the neighbours (up). Then show isis database showed OL = 1 on that router's LSP: the overload bit from the maintenance was never cleared. Removing set-overload-bit brought traffic back within a minute.
Lesson: neighbours up and routes present does not mean the router is a transit candidate. Read the OL column.
"How would you take a core router out of service without dropping traffic?"
Set the overload bit so that other routers stop using it for transit, wait until traffic moves away, do the work, then clear the bit. Mention set-overload-bit on-startup to avoid blackholing while the router converges after a reboot, and that BFD and fast reroute reduce the loss on unplanned failures.
Key takeaways
- The OL bit drains a router: neighbours stay, transit stops.
- Interface metric (default 10) and hello timers are per-interface; use BFD for fast detection.
- Passive interfaces are advertised without forming adjacencies.
- Authentication has three scopes: hello, area and domain, built on key chains.
- SPF, PRC and LSP throttles protect the CPU; tune only after measuring.
Troubleshooting IS-IS: a workflow for silent adjacencies
When an IS-IS adjacency does not come up, there is no error message on the screen. The two routers simply do not talk. That silence is why a fixed order of checks matters. A doctor does not guess: temperature, pulse, then specific tests. Here is the order for IS-IS, moving from the cheapest check to the most specific one.
The workflow
- Layer 1 and 2. Interface up/up, right cable, same VLAN or point-to-point circuit?
show ip interface brief. Without this, nothing else matters. - Is IS-IS running on the interface?
show clns interface <int>prints the circuit type, metrics, priority and the number of active adjacencies. If the interface is not listed,ip router isisis missing. - Router and circuit types.
show running-config | section router isisforis-typeand the NET, and the interface forisis circuit-type. Level-1 needs the same area, level 1 cannot meet level-2-only. - Network type. Both ends point-to-point or both broadcast. Compare
show clns interfaceon both ends: a DIS line ("DR ID") appears only on broadcast circuits. - MTU, authentication, duplicate system ID. Hello padding to the full MTU, a key mismatch, or two routers with the same system ID.
- Adjacency up but routes missing? Go to the database (
show isis database detail): is the LSP there? If yes and the route is not installed, suspect a metric-style mismatch (see spcor-isis-design), the ATT/leaking rules, or a route-map filter.
Check the cheap things first, then the specific ones.
Walk-through: three silent adjacencies (lab spcor-isis-adjacency-ts)
The scenario: a change window went wrong at Metro Fibre. R1 (level-1) and R2 are in area 49.0001; R3 and R4 (level-1) in area 49.0002. Nobody can reach anybody. Start at R1.
Fault 1: R1 and R2.
R1# show isis neighbors
Tag null:
System Id Type Interface IP Address State Holdtime Circuit Id
R1# show running-config | section router isis
router isis
net 49.0003.0000.0000.0001.00
is-type level-1
log-adjacency-changes
No neighbour. R1 is level-1 only and R2 is in 49.0001, but R1's NET says 49.0003. Fix without changing the system ID: no net 49.0003.0000.0000.0001.00 then net 49.0001.0000.0000.0001.00.
Fault 2: R2 and R3. Compare the two ends of the link:
R2# show clns interface g0/1
Level-2 Metric: 10, Priority: 64, Circuit ID: R2.00
Number of active level-2 adjacencies: 0
R3# show clns interface g0/1
Level-1 Metric: 10, Priority: 64, Circuit ID: R3.02
DR ID: R3.02
Level-2 Metric: 10, Priority: 64, Circuit ID: R3.02
DR ID: R3.02
Number of active level-2 adjacencies: 0
R3 shows a "DR ID" (a DIS), so R3 runs a broadcast circuit; R2 has no DR line because it is point-to-point (the lab configured it so). One end is p2p, the other LAN. Fix on R3: isis network point-to-point under Gi0/1.
Fault 3: R3 and R4.
R3# show clns interface g0/0
Circuit Type: level-2
Level-2 Metric: 10, Priority: 64, Circuit ID: R3.01
Number of active level-2 adjacencies: 0
R4 is level-1 only; R3 runs only level 2 on this interface because of isis circuit-type level-2-only. Fix on R3: no isis circuit-type. Then set the DIS priority: isis priority 100 level-1 on the same interface. After all three fixes:
R1# show isis neighbors
R2 L1 Gi0/0 10.1.12.2 UP 22 R2.01
R3# show isis neighbors
R4 L1 Gi0/0 10.1.34.4 UP 22 R3.01
R2 L2 Gi0/1 10.1.23.2 UP 22 00
R3 is now the level-1 DIS on its LAN with R4 (circuit R3.01) and R2-R3 is a level-2 point-to-point adjacency (circuit 00). The lab checks that R1 and R4 can reach each other's loopbacks.
Symptom-to-cause table
| Symptom | Likely cause | Check |
|---|---|---|
| No neighbour at all | No ip router isis, area mismatch on L1, circuit-type, network type | show clns interface, running-config |
| Neighbour flapping | MTU, duplex or physical errors, aggressive timers, auth keys | logs, interface counters |
| Adjacency up, no routes | Metric-style mismatch, ATT bit absent, route-map filter | show isis database detail |
| Loopback unreachable | No ip router isis on Loopback0, passive misuse | show ip route isis |
| Traffic avoids a router | Overload bit set | OL column in show isis database |
debug isis adj-packets is the next tool (reference command; not simulated): use it briefly and carefully on a live router because it prints every hello.
Worked example. A new router R6 shows no neighbour on a core link. Your steps: link up (yes); show clns interface lists the interface (yes, so IS-IS is on); is-type level-1-2, NET area same as the neighbour's (yes); the neighbour prints "DR ID" lines and R6 does not, so one end is p2p. You configure isis network point-to-point on the neighbour, the adjacency comes up in seconds. Four commands, four layers, no guessing.
Common mistakes. (1) Rebooting the router. It never fixes a configuration mismatch. (2) Fixing only one end and declaring victory: always re-check both neighbours. (3) Changing the system ID to "fix" an adjacency: this renumbers the router in the whole domain and breaks other things.
Exam trap. The exam shows two partial configurations and asks why no adjacency forms. Look for: different areas with level-1, p2p on one end only, circuit-type mismatch, different authentication. Do the checks in the order above.
Change window, three faults, one hour
The team that led the change window above found all three faults in under an hour using this order: first area mismatch (visible in the running config), then the p2p mismatch (visible by comparing DR lines), then the circuit type. The first engineer who tried had changed three things at once and then could not tell which one mattered.
Lesson: one fix at a time, re-verify after each, and write the cause in the ticket.
"An IS-IS adjacency does not come up. What do you check?"
Interface state and IP, then whether IS-IS is enabled on the circuit, then router type and area against the neighbour's, then circuit type and network type on both ends, then MTU, authentication and system ID duplication. If the adjacency is up but routes are missing, I read the database and look at metric style and leaking.
Key takeaways
- A silent adjacency has no error message; use a fixed order of checks.
- show clns interface shows circuit type, priority, DR ID and active adjacencies.
- Typical causes: area mismatch on L1, p2p on one end, circuit-type, MTU, authentication.
- Adjacency up with routes missing: read the database and think of metric style, ATT and filters.
- Change one thing at a time and verify both ends.
Summary and exam checklist
You can now build a two-level IS-IS network, read its databases, predict which adjacencies form, find the cause of a silent link and operate the network safely. This chapter is your revision sheet.
IS-IS on one page.
Can-do checklist
- I can write a NET and split it into area, system ID and NSEL, and I can encode a loopback in the system ID.
- I can name the four PDUs and say what each does.
- I can read
show isis database detailand explain LSP ID, sequence number, lifetime, ATT/P/OL and the TLVs shown. - I can predict the adjacency (L1, L2, none) for any pair of router types and areas.
- I can explain DIS election, the pseudonode and why core links use point-to-point.
- I can explain the attached bit, default route, route leaking, the up/down bit and summarisation.
- I can drain a router with the overload bit and know the three authentication scopes.
- I can troubleshoot a silent adjacency using the six-step workflow.
Mini glossary
- NET
- Network Entity Title: area + system ID + NSEL 00.
- System ID
- Six-byte unique router identifier.
- IIH / LSP / CSNP / PSNP
- Hello, link-state PDU, complete and partial sequence number PDUs.
- TLV
- Type-Length-Value block inside a PDU.
- DIS / pseudonode
- LAN chairperson and the virtual router that represents the LAN.
- ATT bit
- Attached bit in a level-1 LSP: this router reaches other areas.
- OL bit
- Overload bit: do not use this router for transit.
- Route leaking
- Selectively advertising level-2 routes into level 1.
Most tested facts
| Fact | Value |
|---|---|
| NSEL of a router | 00 |
| System ID length | 6 bytes |
| Default IOS router type / metric style | level-1-2 / narrow |
| Default interface metric on IOS | 10; distance 115 |
| Hello interval and hold (LAN, router) | 10 s and 30 s; DIS 3.33 s and 10 s |
| LSP max lifetime / refresh | 1200 s / 900 s |
| CSNP interval from the DIS | 10 s |
| DIS election | Highest priority (default 64), then highest MAC; preemptive; no backup |
| Adjacency L1-2 to L1-2, different areas | Level 2 only |
| Circuit Id 00 / R3.01 | Point-to-point / LAN with DIS R3 and pseudonode 01 |
| Leaked route code on IOS | i ia |
Command cheat-sheet (IOS XE style)
! Configure router isis net 49.0001.0000.0000.0002.00 is-type level-1-2 redistribute isis ip level-2 into level-1 route-map <NAME> set-overload-bit interface GigabitEthernet0/1 ip router isis isis network point-to-point isis circuit-type level-2-only isis priority 100 level-1 isis metric 30 ! Verify show isis neighbors show clns neighbors show clns interface <int> show isis database [detail] show isis hostname show ip route isis show running-config | section router isis
Worked example. Self-test with the lab. Predict before you type: R2 (L1-2, 49.0001) connects to R3 (L1-2, 49.0002) and to R1 (L1, 49.0001). Which neighbours and which types does R2 show? Answer: R1 as L1 and R3 as L2. Which router sets ATT and where? R2 sets it in its level-1 LSP. Does R1 know 4.4.4.4 before leaking? No: only a default route. After leaking 4.4.4.4/32: yes, as i ia.
Common mistake. Memorising commands without predicting the output. In the exam you rarely see the output; you must know what it would say. Predict first, then run the command, and learn from every difference.
Exam trap. Re-read: ATT is set by L1-2 routers in level-1 LSPs; L1 adjacency needs the same area; L2 needs none; DIS is per level and preemptive; narrow metric is the IOS default (next module).
From lab to production
A candidate who had completed both IS-IS labs was asked, in his first week on a real network, why one access router had no route to another area. He checked R-access: level-1 only, ATT not seen in the neighbour's LSP because the neighbour had no level-2 adjacency after a failed uplink. The uplink repair restored ATT and the default route returned. He had practised exactly this chain in the lab.
Lesson: lab practice with predicted outputs transfers directly to production.
"Explain IS-IS to me in two minutes."
Link-state IGP on layer 2 with TLVs; routers named by a NET; two levels, L1 inside an area, L2 as the backbone, L1-2 joining them; DIS and pseudonode on LANs, point-to-point on core links; ATT bit gives level-1 routers a default route, leaking gives specifics, overload bit drains a router; authentication protects adjacencies. Finish with one troubleshooting example.
Key takeaways
- NET names router and area; read it from the right.
- L1 needs the same area; L2 does not; L1-2 in different areas form L2.
- DIS per level, preemptive, no backup; use p2p on core links.
- ATT bit gives a default route; leaking gives specific routes; OL bit drains.
- Next: spcor-isis-design for wide metrics, multivendor cores and redistribution.