IS-IS
Intermediate System to Intermediate System (IS-IS) is a link-state routing protocol designed as an interior gateway protocol (IGP) for intradomain routing within autonomous systems, originally developed by the International Organization for Standardization (ISO) to support the Open Systems Interconnection (OSI) protocol suite and later extended by the Internet Engineering Task Force (IETF) to handle IP traffic efficiently in both pure IP and mixed OSI/IP environments.[1] It employs the shortest path first (SPF) algorithm, akin to Dijkstra's, to compute optimal routes based on a shared link-state database built from flooded link-state protocol data units (LSPs), enabling routers to maintain a complete topology view and support scalable, hierarchical routing across large networks.[2] IS-IS is particularly noted for its flexibility in addressing, using network entity titles (NETs) derived from OSI network service access point (NSAP) formats, and its ability to carry multiple protocol information via network layer protocol identifiers (NLPIDs), including support for IPv4 (NLPID 129) and IPv6 (per RFC 5308).[1][3] The protocol's development traces back to the late 1980s as part of ISO's efforts to enable routing for Connectionless Network Protocol (CLNP) in OSI networks, with the core specification outlined in ISO/IEC 10589:2002.[4] and RFC 1195 (1990) for integrated IP support, allowing a single routing instance to manage both protocol families without the overhead of separate mechanisms.[1] This adaptation addressed the need for a robust IGP in early Internet environments, where IS-IS competed with RIP and later OSPF, but gained prominence in service provider backbones due to its native support for large-scale topologies and minimal configuration complexity compared to area-based OSPF designs.[2] Over time, extensions have enhanced its capabilities, including traffic engineering (RFC 3784), cryptographic authentication (RFC 5304), and IPv6 routing (RFC 5308), ensuring its continued relevance in modern networks.[5][3] IS-IS operates through a two-level hierarchy: Level 1 routers handle intra-area routing within local areas using area addresses for reachability, while Level 2 routers interconnect areas to form a backbone for inter-area traffic, with Level 1/2 routers bridging the two for route summarization and leakage as needed.[2] Routers establish adjacencies via hello protocol data units (PDUs) on point-to-point or broadcast links, flood LSPs to advertise link states, metrics (default reference bandwidth-based, extendable to wide metrics of 1-16,777,215), and reachability information, and perform periodic database synchronization to detect changes and trigger partial or full SPF recalculations for fast convergence.[1][2] Key advantages include its protocol-independent design, which avoids IP-specific dependencies for greater stability; support for variable-length subnet masking (VLSM) and type-of-service (TOS) routing; and scalability in handling thousands of routers through area partitioning and optional features like multi-instance IS-IS (MI-IS-IS) for virtual routing and forwarding (VRF) environments.[1][2] In contemporary deployments, IS-IS powers large ISP and data center networks, often integrated with MPLS for traffic engineering and segment routing (SR), where it distributes labels and prefixes to enable source-based path control without per-flow state.[2] Its robustness is further bolstered by mechanisms like bidirectional forwarding detection (BFD) for sub-second failure detection, loop-free alternates (LFA) for local protection, and overload bit signaling to temporarily exclude unstable routers from path calculations, making it a preferred choice for high-availability environments requiring minimal downtime.[2] Despite competition from OSPF, IS-IS's simplicity in large, flat topologies and vendor-agnostic implementations continue to drive its adoption in core internet routing infrastructures.[1]Introduction
Description
IS-IS, or Intermediate System to Intermediate System, is an Interior Gateway Protocol (IGP) originally developed for routing in Open Systems Interconnection (OSI) networks but subsequently adapted to support IP routing in TCP/IP and dual environments.[1] It functions as a link-state protocol, enabling routers within an autonomous system to exchange topology information and compute optimal paths. Widely deployed in large-scale service provider backbones, IS-IS supports efficient routing across extensive IP infrastructures.[6] In its link-state mechanism, IS-IS routers flood Link State Protocol Data Units (LSPs) to all other routers in the routing domain, allowing each to construct a synchronized database representing the complete network topology.[1] Using this database, routers independently calculate shortest paths to destinations via Dijkstra's shortest path first (SPF) algorithm, ensuring consistent forwarding decisions across the network.[1] The protocol employs a two-level hierarchy—Level 1 for intra-area routing and Level 2 for inter-area connectivity—to manage complexity in sizable domains.[7] Key characteristics of IS-IS include its scalability for large topologies, native multi-protocol support for both IP and Connectionless Network Protocol (CLNP) traffic, and addressing flexibility that accommodates diverse network designs.[7] High-level operation proceeds through neighbor discovery to establish communication, database synchronization to maintain topology accuracy, and route computation to update forwarding tables as changes occur.[7] Compared to distance-vector protocols, which propagate routes incrementally and risk temporary loops or prolonged convergence during topology shifts, IS-IS achieves faster convergence and inherent loop prevention by leveraging comprehensive topology knowledge at each router.[7]History
The Intermediate System to Intermediate System (IS-IS) routing protocol emerged in the 1980s as a component of the International Organization for Standardization (ISO)'s Open Systems Interconnection (OSI) reference model, designed to support connectionless network layer routing within OSI environments.[8] Developed initially for routing Connectionless-mode Network Protocol (CLNP) packets, IS-IS was formalized in its initial specification through ISO/IEC 10589, published in 1992, which defined the protocol's core mechanisms for intra-domain routing in OSI networks.[9][10] In parallel with the rise of the Internet Protocol (IP), the Internet Engineering Task Force (IETF) adapted IS-IS for TCP/IP environments via RFC 1195, also released in 1990, which integrated IP routing capabilities into the OSI-based protocol while maintaining support for both IP and CLNP in dual-stack configurations.[1] This extension allowed IS-IS to function as an interior gateway protocol (IGP) for IP networks without requiring a complete redesign, leveraging its existing link-state architecture. Throughout the 1990s, IS-IS gained traction among large service providers, particularly due to its superior scalability in expansive topologies compared to early implementations of Open Shortest Path First (OSPF); for instance, Cisco's IS-IS implementation at the time was noted for greater stability and reliability in handling large-scale deployments.[11] Subsequent IETF efforts introduced key enhancements to address evolving network demands. In 2004, RFC 3784 extended IS-IS with traffic engineering capabilities, including the adoption of wide metrics (up to 24 bits) to support finer-grained path selection in bandwidth-intensive scenarios.[12] IPv6 routing support followed in 2008 with RFC 5308, which defined mechanisms for advertising IPv6 reachability using existing IS-IS type-length-value (TLV) structures, enabling seamless dual-stack IPv4/IPv6 operations.[3] More recently, in 2019, RFC 8667 specified extensions for Segment Routing over the MPLS data plane, allowing IS-IS to advertise segment identifiers for source-based path engineering without additional state in the network core.[13] From 2023 to 2025, IS-IS has maintained its relevance through adoption in modern data center fabrics, often serving as the underlay protocol for Ethernet VPN (EVPN) and Virtual Extensible LAN (VXLAN) overlays in multi-tier Clos topologies.[14] While the core protocol has seen no fundamental changes, vendor implementations have incorporated advancements such as YANG data models (defined in RFC 9130, 2022) to facilitate model-driven telemetry and automation, enabling programmatic configuration, real-time monitoring, and integration with orchestration tools for large-scale environments.[15]Core Concepts
Terminology
In the IS-IS protocol, an Intermediate System (IS) refers to a device, such as a router, capable of relaying network protocol data units (NPDUs) and performing routing functions to forward traffic between End Systems (ESs) or other ISs within a routing domain. Conversely, an End System (ES) is a non-routing device, such as a host, that originates or terminates NPDUs but does not relay them, relying instead on ISs for path determination to other destinations. The Network Service Access Point (NSAP) serves as the OSI model's equivalent to an IP address, representing a conceptual point where network services are accessed and identifying network entities through a structured format including area address, system ID, and selector fields. IS-IS routers are addressed using NSAPs, often in the form of a Network Entity Title (NET), which omits the selector for routing purposes.[1] Key protocol data units (PDUs) facilitate topology advertisement and synchronization. The Link State PDU (LSP) is the primary packet type used by ISs to broadcast link-state information about their connectivity and reachability, enabling the construction of a link-state database across the network. For database synchronization, the Complete Sequence Number PDU (CSNP) lists the sequence numbers of all LSPs in an IS's database, periodically multicast by the Designated IS (DIS) on broadcast networks to ensure all neighbors maintain consistent views. In contrast, the Partial Sequence Number PDU (PSNP) targets specific LSPs, serving as acknowledgments for received LSPs or requests for missing ones to resolve discrepancies during flooding. Adjacency formation relies on the Intermediate System Hello (IIH) PDU, which ISs exchange to discover neighbors, negotiate capabilities, and establish or maintain adjacencies on point-to-point or broadcast links. On multi-access broadcast segments, a Designated Intermediate System (DIS) is elected among ISs based on priority to represent the segment as a pseudonode, generating LSPs on its behalf and reducing flooding overhead. IS-IS employs a hierarchical routing structure with Level 1 routing, which handles intra-area forwarding using the system ID portion of NSAP addresses within a single area, and Level 2 routing, which manages inter-area paths across the domain backbone using full area addresses to connect multiple areas. This separation allows scalable routing by limiting detailed topology knowledge to local areas while maintaining global connectivity.[1]Addressing and NET
The Intermediate System to Intermediate System (IS-IS) protocol employs Network Entity Titles (NETs) as its primary addressing mechanism for identifying routers within a routing domain. A NET is a specific form of Network Service Access Point (NSAP) address, defined in ISO 8348/Add.2, where the N-selector field is set to zero to designate the entire network entity rather than a specific service.[16] This structure ensures unique identification of Intermediate Systems (routers) and supports the protocol's hierarchical routing model. NETs are manually configured on each router and remain static throughout the system's operation, providing a stable basis for adjacency formation and link-state advertisement. The format of a NET consists of three main components: the Area ID, the System ID, and the N-selector. The Area ID, which identifies the routing area within the domain, is variable in length, ranging from 1 to 13 bytes (octets), allowing flexibility in hierarchical addressing.[16] The System ID follows, fixed at 6 bytes for uniqueness within the area (and domain-wide for Level 2 routers), often derived from a MAC address or assigned administratively to ensure global distinction across the network.[16] The N-selector concludes the NET as a single byte, uniformly set to 00 for NETs, distinguishing them from NSAPs used for end-system services.[16] This variable-length design, encoded as binary octets with the most significant octet first, enables efficient packing in protocol data units (PDUs) while supporting the OSI addressing syntax defined in ISO 10589.[16] NETs function as router identifiers in IS-IS operations, uniquely labeling each router in Link State PDUs (LSPs) for database synchronization and path computation. The full NET or its System ID portion is embedded in LSP headers, allowing routers to advertise their identity and reachable prefixes without relying on IP-specific addressing.[16] For Level 1 routing, the Area ID confines advertisements to intra-area scope, while Level 2 routing uses the System ID for inter-area connectivity, promoting scalability in large domains.[16] The variable Area ID length facilitates administrative partitioning of the routing domain, enabling operators to balance load and containment without fixed boundaries.[16] To integrate IP routing within IS-IS, as specified in RFC 1195, IP prefixes are mapped to IS-IS reachability information through Type-Length-Value (TLV) extensions in LSPs. Routers advertise directly connected IP subnets using the IP Internal Reachability Information TLV (code 128), which includes the IP address, subnet mask, and metric, allowing IS-IS to compute paths to IPv4 destinations alongside OSI addresses.[1] For external or summarized routes, the IP External Reachability Information TLV (code 130) is employed in Level 2 LSPs, enabling hierarchical aggregation of IP prefixes (e.g., a /8 network) while preserving native IS-IS flooding efficiency.[1] This dual-stack capability supports mixed OSI/IP environments without separate protocols, with best-match selection prioritizing longer prefix masks for precise routing.[1] A representative NET example is 49.0001.1921.6800.1001.00, where 49 denotes the Authority and Format Identifier (AFI) for private data networks, 0001 is the 1-byte Area ID, 1921.6800.1001 forms the 6-byte System ID (often represented in dotted decimal for readability), and 00 is the N-selector.[7] This format illustrates how NETs encapsulate both area hierarchy and router specificity in a compact, OSI-compliant string.Hostname Resolution
In IS-IS networks, hostname resolution enables the mapping of human-readable symbolic names to router identifiers, facilitating easier network management. This feature is supported through a dynamic hostname Type-Length-Value (TLV) extension, defined as TLV type 137, which allows routers to advertise their hostnames within Link State Protocol Data Units (LSPs). The TLV carries a variable-length string (1 to 255 bytes) representing the hostname, such as a fully qualified domain name or a subset thereof, without null termination. This mechanism was introduced in RFC 2763 and updated in RFC 5301 to address the limitations of using opaque hexadecimal System IDs for identification in large-scale deployments.[17] The resolution process occurs as routers flood their LSPs containing the hostname TLV across the network; receiving routers parse these LSPs and extract the TLV to build or update a local mapping table that associates the advertised hostname with the originating router's System ID, derived directly from the LSP identifier. This mapping can extend to the full Network Entity Title (NET) by combining the System ID with area information. Routers implementing the extension store these mappings optionally, ignoring the TLV if not supported, ensuring backward compatibility with the core IS-IS protocol as specified in ISO/IEC 10589. The process relies on the standard LSP flooding mechanism but does not alter routing decisions.[17] Hostname resolution finds primary use in debugging, network monitoring, and command-line interface (CLI) outputs, where symbolic names replace hexadecimal identifiers for clarity—for instance, in Cisco IOS implementations, the "show isis hostname" command displays the dynamic mapping table to aid troubleshooting. It enhances operator efficiency in multi-vendor environments by providing consistent name-based references without relying on external systems like DNS. However, the feature is optional and not integral to core routing operations, meaning its absence does not impact protocol functionality. Additionally, hostnames are not required to be globally unique, potentially leading to ambiguities if duplicate names are used, though the underlying System IDs remain unique.[17][18]Protocol Mechanics
Packet Types
IS-IS employs four primary types of Protocol Data Units (PDUs) to facilitate neighbor discovery, link-state advertisement, and database synchronization within the routing domain. These PDUs share a common header structure that ensures interoperability and includes essential fields for identification and processing. The protocol's design, as specified in the OSI standard, supports both point-to-point and broadcast network types, with variants tailored to Level 1 (intra-area) and Level 2 (inter-area) routing operations.[16] The common PDU header, fixed at 8 octets in length, begins with an intradomain routing protocol discriminator (value 0x83) to identify IS-IS packets, followed by a length indicator specifying the total PDU length. It includes a version field (typically 1), a reserved octet, a protocol ID extension (value 1), and an ID length octet indicating the system identifier length (usually 6 octets). The header concludes with the source ID, a 6-octet field representing the originating Intermediate System's identifier. The PDU type field, a single octet, distinguishes the specific PDU category and variant, such as 15 for Level 1 LAN Hello or 18 for Level 1 LSP. Variable-length fields follow the header, encoded in Type-Length-Value (TLV) format to carry protocol-specific information.[16][16] Hello PDUs (IIHs) are used to discover and maintain adjacencies between neighboring Intermediate Systems. There are three main variants: Level 1 LAN IIH (PDU type 15), sent multicast to all Level 1 routers on broadcast networks for intra-area neighbor detection; Level 2 LAN IIH (PDU type 16), similarly multicast for inter-area neighbors; and Point-to-Point IIH (PDU type 17), exchanged unicast on non-broadcast links to establish bidirectional connectivity. These PDUs include fields such as holding time (to manage adjacency timers), priority (for Designated Intermediate System election on LANs), and local circuit ID, enabling routers to assess compatibility and form Level 1 or Level 2 adjacencies as needed.[16][16] Link State PDUs (LSPs) advertise a router's local topology, capabilities, and attached networks to the domain. Level 1 LSPs (PDU type 18) are generated by Level 1 and Level 2 routers for intra-area flooding, while Level 2 LSPs (PDU type 20) are produced by Level 2 routers for domain-wide distribution. Each LSP includes a 2-octet lifetime field, initialized to a maximum age (typically 1200 seconds) and decremented upon transmission to indicate validity; expired LSPs are purged after a zero-age lifetime (60 seconds). A 4-octet sequence number tracks updates, starting at 1 and incrementing modulo 2^32 to ensure the latest version is propagated during flooding. The LSP identifier combines the source ID, pseudonode number (0 for non-LAN routers), and fragment number.[16][16][16] To handle large topologies where an LSP exceeds the maximum transmission unit (MTU), fragmentation is supported by dividing content across multiple LSPs, each with a unique fragment number (0 to 255). The total number of fragments is determined by the originating LSP buffer size advertised in a TLV within the LSP. This allows up to 256 fragments per originating system, ensuring complete topology information is reliably flooded without packet loss due to size constraints.[16] Sequence Number PDUs (SNPs) ensure link-state database synchronization across the network. Complete SNPs (CSNPs), with Level 1 (PDU type 24) and Level 2 (PDU type 25) variants, provide a full summary of all LSPs in the database, listing ranges of LSP identifiers, sequence numbers, checksums, and lifetimes; they are periodically multicast by the Designated Intermediate System on broadcast networks to detect inconsistencies. Partial SNPs (PSNPs), Level 1 (PDU type 26) and Level 2 (PDU type 27), target specific LSPs for acknowledgment or query, unicast on point-to-point links or multicast on LANs to request missing or outdated entries, thereby resolving synchronization issues efficiently.[16][16][16]| PDU Type | Variant | Role | Key Fields | PDU Type Value |
|---|---|---|---|---|
| Hello (IIH) | Level 1 LAN | L1 adjacency on broadcast | Holding Time, Priority, LAN ID | 15 |
| Hello (IIH) | Level 2 LAN | L2 adjacency on broadcast | Holding Time, Priority, LAN ID | 16 |
| Hello (IIH) | Point-to-Point | Adjacency on point-to-point | Holding Time, Circuit ID | 17 |
| Link State (LSP) | Level 1 | Intra-area topology | Lifetime, Sequence Number, LSP ID | 18 |
| Link State (LSP) | Level 2 | Inter-area topology | Lifetime, Sequence Number, LSP ID | 20 |
| Sequence Number (SNP) | Level 1 CSNP | L1 database summary | LSP Ranges, Sequence Numbers | 24 |
| Sequence Number (SNP) | Level 2 CSNP | L2 database summary | LSP Ranges, Sequence Numbers | 25 |
| Sequence Number (SNP) | Level 1 PSNP | L1 LSP query/ACK | Specific LSP ID, Sequence Number | 26 |
| Sequence Number (SNP) | Level 2 PSNP | L2 LSP query/ACK | Specific LSP ID, Sequence Number | 27 |