IS-IS: the routing protocol hiding under the internet

Intermediate System to Intermediate System (IS-IS) is the link-state routing protocol ISO wrote for OSI and RFC 1195 extended to IP: it floods link state as OSPF does, but its packets travel on the link layer, not inside IP. After reading, you can build a NET from a loopback address, tell Level 1 from Level 2 routing, predict which router becomes the DIS on a LAN, read show isis neighbor and show isis database in FRRouting, and say what its authentication protects and what it leaves open.

View as Markdown

Intermediate System to Intermediate System () is a link-state interior routing protocol: each router floods a description of its links and computes shortest paths over the shared map. It was written for the Open Systems Interconnection (OSI) protocols of the International Organization for Standardization (ISO), and (RFC) 1195 extended it to IP. After reading, you can say why its packets are not IP, build a network entity title (), tell Level 1 from Level 2, predict the Designated Intermediate System (DIS) on a local area network (), read FRRouting (FRR) output, and say what its authentication leaves open.

A link-state protocol from the OSI world

RFC 1195 names the family: "The integrated IS-IS is a dynamic routing protocol, based on the (Dijkstra) routing algorithm" (RFC 1195, section 1.1). Shortest path first (SPF) is Dijkstra's computation; dynamic routing compared sets IS-IS beside . An intermediate system is OSI's term for a router (section 2).

In February 1990 RFC 1142 republished ISO's draft, DP 10589 (a Draft Proposal), stating "This is not an Internet standard" (RFC 1142). RFC 1195 followed in December 1990: "This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments" (RFC 1195, Abstract). ISO/IEC 10589 (IEC: International Electrotechnical Commission) appeared in 1992 and 2002; the draft "differed in a considerable number of significant respects" from it, and RFC 1142 is now historic (RFC 7142, sections 1 and 3.1). Values below come from RFCs that restate the standard, or are marked as the 1990 draft's.

Not an IP packet

IS-IS rides on the link layer, not in IP: "all IS-IS routers, including IP-only routers, must be able to receive IS-IS packets using the normal encapsulation for OSI packets" (RFC 1195, section 4.1). On that is an Institute of Electrical and Electronics Engineers () 802.3 frame with a Logical Link Control (LLC) header, not an (the Ethernet frame, field by field). Every IS-IS frame in a three-router FRR 8.4.4 lab begins so:

12:03:37.110430 2e:0f:c2:dd:72:da > 01:80:c2:00:00:14, 802.3, length 1500: LLC, dsap OSI (0xfe) Individual, ssap OSI (0xfe) Command, ctrl 0x03: OSI NLPID IS-IS (0x83): length 1497

LLC 0xFE means OSI; 0x83, the first octet of the protocol data unit (PDU), is the draft's IS-IS discriminator, and the draft sends to 01-80--00-00-14 for Level 1 and 01-80-C2-00-00-15 for Level 2 (RFC 1142, constants). With no IP header, an IP capture filter never matches; pcap-filter has isis (pcap-filter(7)). The PDUs are hellos, which form adjacencies; link state packets (LSPs), each router's self-description; and sequence number packets (SNPs), complete (CSNP) or partial (PSNP), which keep databases in step (RFC 1195, section 5.1).

The NET and the system ID

Even an IP-only router needs an OSI address, used only by IS-IS (RFC 1195, section 3.3). IS-IS reads that Network Service Access Point (NSAP) as an area address, a system identifier (system ID) and a one-octet NSAP selector (NSEL) (RFC 1629, section 3); a NET is an NSAP whose selector is 00 (Juniper Networks, IS-IS Overview). "An implementation MUST use an ID Length of 6, and MUST check the ID Length defined in the IS-IS PDUs it receives" (RFC 3719, section 3.1).

For loopback 192.0.2.1 in area 49.0001, Juniper's method pads each octet to three digits, 192.000.002.001, and regroups them in fours:

Field	Octets	Value
Area address	3	49.0001
System ID	6	1920.0000.2001
NSEL	1	00
NET	10	49.0001.1920.0000.2001.00

The 49 follows the convention of Juniper's own examples. The often-copied 1921.6800.1001 decodes to the private 192.168.1.1.

RFC 1195 says to "use the value hex '02 00' prepended to an IP address of the router", giving 0200.c000.0201, which cannot collide with a media access control (MAC) address: 0x02 sets the global/local bit that assigned IEEE 802 addresses leave clear (section 3.3; see how MAC addresses are assigned).

Levels instead of areas

"Level 1 routers forward all traffic for destinations outside of their area to a level 2 router in their area" (RFC 1195, section 1.2); Level 2 routers know the Level 2 topology, and a router can be both (FRR's is-type level-1-2). A Level 1 router refuses a neighbour from another area; a Level 2 router accepts any Level 2 neighbour (section 1.2).

The backbone is not an area but the set of Level 2 routers, and "IS-IS requires that the set of level 2 routers be connected": Level 1 links cannot repair a partition (RFC 1195, section 1.2).

A Level 1-2 router that reaches another area sets the attached (ATT) bit in its Level 1 LSP, and Level 1 routers install a default route to the nearest such router (Juniper Networks, IS-IS Overview). In the lab, r2's LSP shows 1/0/0 under ATT/P/OL and r1 installs 0.0.0.0/0 10 e12 198.51.100.2 (see routing tables and the default gateway). Prefixes leaked down into Level 1 carry the up/down bit and never go back up (RFC 5305, section 4.1), the loop route redistribution guards against.

The LAN and its DIS

On a LAN, IS-IS replaces n-squared links between routers with n links to a pseudonode, whose LSP one elected router originates (RFC 1195, section 1.2): the DIS, one per level. Cisco states the rules: "On a LAN, one of the routers elects itself the DIS, based on interface priority (the default is 64)"; "If all interface priorities are the same, the router with the highest subnetwork point of attachment (SNPA) is selected"; "There is no backup DIS elected"; and "The DIS election is preemptive (unlike OSPF)" (Cisco, Understanding IS-IS Pseudonode LSP); OSPF's election is in the OSPF primer.

In the lab, at equal priority, r1 was DIS: its SNPA, the MAC 8272.129b.cdac, is higher than r2's 2e0f.c2dd.72da. Eight seconds after isis priority 100 level-1 on r2, r1 reported LAN Priority: 64, is not DIS and r2 LAN Priority: 100, is DIS; r1's old pseudonode LSP stayed purged beside r2's new one, as the rule allows: "The pseudonode LSPs generated by the previous DIS are no longer required and may be purged by the new DIS" (RFC 7987, section 2). The DIS also multicasts CSNPs in place of acknowledgements (Juniper Networks, IS-IS Overview), every 10 seconds in the lab.

Hellos and the three-way handshake

A hello carries a holding time, the hello interval times a multiplier, after which a silent neighbour is dropped. ISO sets the multiplier at 10, most implementations used 3 by 2004, and "Values lower than 3 are unstable, and may cause adjacencies to flap" (RFC 3719, section 2.2). FRR 8.4.4 used 3 seconds times 10: 30 seconds in every lab hello, the DIS's included. Faster detection is the job of Bidirectional Forwarding Detection (BFD).

Point-to-point links first lacked a three-way handshake, so "if the link fails in only one direction, the failure will only be detected by one of the systems" (RFC 5303, section 1). RFC 5303's type 240 carries the states Down, Initializing and Up (section 2.1), and the lab's r2 to r3 hellos step through Down (2), Initializing (1) and Up (0).

LSPs and the clock

An LSP ID is system ID, pseudonode and fragment: r1.00-00 is r1's own, r1.02-00 its pseudonode. A higher sequence number is newer; at equal numbers a purged copy wins (RFC 7987, section 2). ISO fixes MaxAge at 1200 seconds, with a recommended refresh every 900, and RFC 3719 notes: "These times have proven to be too short in some networks, as they result in a steady flow of LSP updates even when nothing is changing" (RFC 3719, section 2.1). The 16-bit field allows 65535 seconds, 18.2 hours, the "up to 18 hours" of RFC 5303, section 1; the lab's lifetimes counted down from about 1200.

Metrics, narrow and wide

The original metric had 6 bits, 0 to 63 (RFC 5305, section 3), and the draft capped a path at 1023 (RFC 1142, constants): 17 links at 63 make 1071. RFC 5305 added type 22 for neighbours, with 24 bits, and type 135 for prefixes, with 32; a link at 16,777,215 is left out of SPF, and paths stop at 4,261,412,864 (RFC 5305, sections 3 and 4). "If not all devices in the IS-IS domain support wide metrics, narrow metrics MUST continue to be used" (RFC 3787, section 5). FRR defaults to metric-style wide.

TLVs: how it learned IPv6 without a new version

A PDU body is a run of type-length-value (TLV) elements, one octet each for type and length (RFC 1195, section 3.1), and RFC 1195 made them extensible: "Any codes in a received PDU that are not recognised are ignored and passed through unchanged" (section 3.1). RFC 8918 gives the reason: "In order to allow protocol extensions to be deployed in a backwards compatible way, an implementation is required to ignore TLVs that it does not understand" (RFC 8918, section 1). r1's LSP, decoded by tcpdump:

L1 LSP, hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0)
  lsp-id: 1920.0000.2001.00-00, seq: 0x00000003, lifetime:  1186s
  chksum: 0x520a (correct), PDU length: 92, Flags: [ L1 IS ]
    Protocols supported TLV #129, length: 2
      NLPID(s): IPv4 (0xcc), IPv6 (0x8e)
    Area address(es) TLV #1, length: 4
      Area address (length: 3): 49.0001
    Hostname TLV #137, length: 2
      Hostname: r1
    IS-IS Router Capability TLV #242, length: 5
      Router-ID 192.0.2.1, Flags [none]
    Traffic Engineering Router ID TLV #134, length: 4
      Traffic Engineering Router ID: 192.0.2.1
    Extended IS Reachability TLV #22, length: 11
      IS Neighbor: 1920.0000.2001.02, Metric: 10, no sub-TLVs present
    IPv4 Interface address(es) TLV #132, length: 4
      IPv4 interface address: 192.0.2.1
    Extended IPv4 Reachability TLV #135, length: 17
      IPv4 prefix:    198.51.100.0/24, Distribution: up, Metric: 10
      IPv4 prefix:       192.0.2.1/32, Distribution: up, Metric: 10

IPv6 came as TLVs 232 and 236 and identifier 0x8E, seen above (RFC 5308, sections 1 to 4), whereas OSPF needed "incrementing the protocol version from version 2 to version 3" (RFC 5340, Abstract); IS-IS PDUs still say version 1 (RFC 3719, section 3.3). Traffic engineering added sub-TLVs inside TLVs (RFC 5305, section 2), and RFC 8667 defines Segment Routing on a Multiprotocol Label Switching () data plane (RFC 8667, Abstract) (see the MPLS primer).

The overload bit

A router that cannot store every LSP sets the overload bit, and the others stop using it for transit (RFC 3719, section 12), though it stays reachable as a destination (RFC 3787, section 4). After a reboot IS-IS converges before BGP, so "It is convenient to set the Overload Bit until has converged" (section 4); FRR has set-overload-bit on-startup (FRRouting documentation, ISIS). In the lab, set-overload-bit on r2 showed at r1 within 2 seconds as 1/0/1, r2's own prefixes still reachable; removed, it cleared in 30 seconds.

How it fails, and how it is attacked

Failures follow the rules: an area mismatch blocks Level 1, a split Level 2 stays split, and a link or buffer smaller than the largest LSP means "full propagation of all LSPs may not be possible, resulting in routing loops and black holes" (RFC 3719, section 5).

The first password was no defence: "The use of a simple password does not provide useful protection against intentional misbehavior" (RFC 1195, section 6). Type 10 now carries a cleartext password (1), a keyed-hash message authentication code with Message Digest 5, - (54) (RFC 5304, sections 1 and 2), or a generic HMAC with the -1 or SHA-2 Secure Hash Algorithms (3) (RFC 5310, section 1).

A digest proves possession of a key, not origin: the method "is not being used to authenticate the specific originator of a PDU" (RFC 5310, section 4). "IS-IS on a broadcast network shares the same key between all neighbors on that network", and with no sequence number a replayed hello can reset adjacencies and a replayed CSNP set off an LSP flood (RFC 6039, section 4.2). The Remaining Lifetime is zeroed before hashing, "thus this field is not authenticated" (RFC 5310, section 4).

The defences: "ISes implementing HMAC-MD5 authentication MUST NOT accept unauthenticated purges" (RFC 5304, section 2); RFC 7987 forbids purging another router's LSP before it has been held for MaxAge (RFC 7987, section 2); RFC 6232 records who sent a purge (RFC 6232, Abstract); and keys can roll, since implementations "MUST be able to store and use more than one key at the same time" (RFC 5310, section 4). None of it stops a compromised router (RFC 5304, section 3.1).

How to see it

The lab's r1, in FRR syntax (FRRouting documentation, ISIS):

interface e12
 ip router isis LAB
!
router isis LAB
 net 49.0001.1920.0000.2001.00
 is-type level-1
 metric-style wide
 hostname dynamic

r2# show isis neighbor
Area LAB:
  System Id           Interface   L  State        Holdtime SNPA
 r1                  e21         1  Up            29       8272.129b.cdac
 r3                  e23         2  Up            27       2020.2020.2020

Columns: neighbour (dynamic hostname), interface, level, state, seconds of holding time left, and SNPA; a point-to-point link has no MAC, so FRR prints 2020.2020.2020.

r2# show isis database
Area LAB:
IS-IS Level-1 link-state database:
LSP ID                  PduLen  SeqNumber   Chksum  Holdtime  ATT/P/OL
r1.00-00                   92   0x00000003  0x520a    1126    0/0/0
r1.02-00                   51   0x00000002  0x803e    1106    0/0/0
r2.00-00             *    101   0x00000002  0x0cd1    1104    1/0/0
    3 LSPs

Each row: LSP ID, PDU length, sequence number, checksum, remaining lifetime (in parentheses once purged), and the attached, partition-repair and overload bits; an asterisk marks the router's own. In tcpdump, -e prints the link-level header, -n keeps addresses numeric, -v adds detail and -w writes a file (tcpdump(8)):

tcpdump -i e12 -e -n -v isis
tcpdump -i e12 -w isis-lan.pcap isis

The first octets of the LAN hello above:

Octets	Value	Meaning
01 80 c2 00 00 14	destination	all Level 1 intermediate systems
05 dc	1500	802.3 length
fe fe 03	LLC	OSI service access points, control 3
83	131	IS-IS protocol discriminator
1b	27	header length
0f	15	Level 1 LAN hello, as tcpdump decodes it
03	3	circuit type, Level 1 and 2
19 20 00 00 20 02	1920.0000.2002	source system ID
00 1e	30	holding time, seconds
05 d9	1497	PDU length
40	64	priority
81 02 cc 8e	type 129	protocols supported: IPv4, IPv6

The Python playground redoes this arithmetic; the packet capture plan builder helps place a capture, which for IS-IS must sit on the segment; the MAC vendor lookup reads 01-80-C2-00-00-14 as multicast and the lab's virtual interfaces as locally administered.

Where it runs

No source read measures it. RFC 6232 says IS-IS "has been widely used in large-scale IP networks because of its strong scalability and fast convergence" (RFC 6232, section 1); FRR's documentation says "ISIS is widely used in large networks such as and backbone networks", ISP meaning internet service provider (FRRouting documentation, ISIS).

What to remember

IS-IS is ISO's link-state protocol, extended to IP by RFC 1195; its PDUs travel in 802.3 frames, never inside IP.
A NET is area address, six-octet system ID and NSEL 00: loopback 192.0.2.1 in area 49.0001 gives 49.0001.1920.0000.2001.00.
Level 1 knows its area; Level 2 routers must form one connected backbone; the attached bit gives Level 1 a default route.
A LAN elects one DIS per level by priority (64 by default), then highest SNPA, preemptively and with no backup.
LSPs live 1200 seconds and are refreshed every 900 by the standard's figures; implementations stretch this up to 65535.
Unknown TLVs are ignored and passed on, which brought IPv6 (232, 236) and wide metrics (22, 135) without a new version.
Authentication proves possession of a shared key, not origin, and leaves replays and the Remaining Lifetime open.