May 2026 - Estimated read time: 14 min
Why operators choose IS-IS for simple, efficient, and extensible IGP control planes—from service provider cores to enterprise data centers and campus backbones.
When you spend time around large networks-service provider backbones and well-run enterprise cores-you notice a pattern: many of the most stable IP transport domains run IS-IS. That choice often surprises engineers who grow up in corporate environments where OSPF dominates. IS-IS can look obscure until you operate it at scale-then it starts to feel like a deliberately engineered tool: compact, extensible, and predictable.
This article explains why IS-IS earns its reputation as the “hidden jewel” of IP transport. It focuses on the benefits that matter in real networks-simplicity, efficiency, and extensibility-in a way that stays practical and grounded. It also stays honest: OSPF is a strong IGP. The goal is not to dunk on OSPF; the goal is to show why IS-IS often becomes the preferred backbone IGP when the network is large, multi-vendor, and relentlessly operational-whether that network belongs to a carrier, a cloud provider, a global enterprise, or a campus/data-centre operator.
Throughout the post, “simplicity” means fewer special cases and fewer hidden interactions. “Efficiency” means lower operational overhead and smoother scaling as topology and attributes grow. “Accuracy” means the claims stay grounded in how the protocols actually behave and how engineers actually run them in production.
1) The mental model: IS-IS and OSPF solve the same problem differently
Both IS-IS and OSPF are link-state routing protocols. They flood topology information, build a link-state database (LSDB), and run SPF to compute best paths. At a high level, they look similar. The differences that matter appear in three places: how the protocol encodes information, how it scopes the topology, and how it deals with growth (new attributes, new address families, and bigger networks).
- Encoding: IS-IS uses a TLV (Type-Length-Value) structure almost everywhere, which makes extensions natural. OSPF uses structured LSAs with type-specific formats; extensions exist (including opaque LSAs), but they can feel more constrained and more version-specific.
- Scoping: IS-IS uses Level-1 and Level-2 to create hierarchy (like “local area” and “backbone”), while OSPF uses areas with a designated backbone area (area 0) and ABRs to connect them.
- Transport: IS-IS runs directly over Layer 2 using CLNS (not inside IP), while OSPF runs over IP. This sounds academic, but it can simplify bring-up and reduce “IP depends on IGP depends on IP” confusion in some designs, especially when you treat loopbacks as stable identities and want the IGP to form adjacencies without relying on IP transport.
2) Why service providers care: backbone routing is a control-plane product
In SP transport, the IGP is not a feature; it is a control-plane product. It must stay stable while the network grows, while new services appear, while TE and SR attributes expand, and while maintenance happens every week. The best backbone IGP is the one that stays boring under stress: predictable convergence, predictable flooding, predictable extension behavior, and predictable troubleshooting.
This is where IS-IS shines. It is not “better at SPF.” It often stays more predictable as you keep adding requirements, especially in transport-heavy designs with TE/SR attributes and strict operational constraints.
2b) Corporate and enterprise context: where IS-IS fits outside service providers
IS-IS is not “only for carriers.” It shows up in corporate environments whenever the IGP becomes a transport foundation that must carry more than basic reachability: data center fabrics, multi-campus cores, SD-WAN underlays, and hybrid designs that use TE or Segment Routing attributes.
Data centre underlays and EVPN/VXLAN fabrics
Many enterprises build modern data centres with leaf-spine topologies and EVPN/VXLAN overlays. Even when the overlay uses BGP EVPN, the underlay still needs a stable IGP for loopback reachability, fast convergence, and clean extensibility. IS-IS works well here because the configuration surface stays small and the protocol tolerates growth in attributes (TE/SR, new TLVs) without the design turning into “OSPF plus extensions plus exceptions.”
Campus and large-site cores
In large campuses, the core often behaves like a service provider core in miniature: many VLANs, many routed access blocks, and constant churn at the edge. Teams often choose OSPF because it is familiar, but IS-IS can be a strong fit when the goal is a simple, consistent core IGP that is less sensitive to area boundary edge cases. A common enterprise pattern keeps IS-IS in the core and uses redistribution or controlled boundaries to integrate with OSPF at the access edge if required by tooling or legacy constraints.
SD-WAN and multi-transport WAN underlays
SD-WAN overlays depend on a stable transport and predictable failure behavior. In designs that keep a routed WAN core (MPLS, private backbone, or a routed hub-and-spoke), IS-IS often becomes attractive because it stays boring as you add sites and attributes. When the WAN evolves to include traffic engineering or SR policies, IS-IS’s extensibility becomes a practical advantage rather than a theoretical one.
Why enterprises still pick OSPF (and why that can be the right decision)
OSPF often wins in corporate environments for good reasons: deep team familiarity, abundant training material, common tooling assumptions, and integration with existing area designs. In smaller networks, OSPF’s area model can be perfectly clean, especially with point-to-point links and disciplined summarization. If your organization already runs OSPF well, switching IGPs is rarely justified without a clear operational payoff.
The takeaway is simple: IS-IS becomes compelling in enterprises when the IGP starts behaving like a transport product-large topologies, high change rates, multi-vendor needs, and an increasing appetite for TE/SR attributes. In that world, the “simplicity and extensibility” arguments that make sense for carriers apply to corporate networks too.
2c) What IS-IS gives you when you run it as a backbone protocol
IS-IS earns its reputation when you treat it as a backbone control plane rather than as a classroom topic. In that role, it consistently delivers three operator-facing benefits:
- Compact intent: a small configuration surface that stays consistent across vendors and across years of growth.
- Extensible mechanics: a TLV-based encoding model that absorbs new attributes (IPv6, TE, SR, flex-algo) without turning into a patchwork of special cases.
- Predictable operations: stable hierarchy options (L1/L2), pragmatic database synchronization (CSNP/PSNP), and troubleshooting that starts from a few clear questions.
If you already run OSPF successfully, you can keep doing so. This article’s point is narrower: when the network starts behaving like a transport fabric with continuous change, IS-IS tends to stay “quiet” in the best way-boring, consistent, and easy to extend.
3) Simplicity advantage #1: fewer network-type edge cases
OSPF brings a set of interface network types and behaviors (broadcast, point-to-point, NBMA, etc.) that can matter in enterprise and legacy designs. In modern SP cores, most links are point-to-point, and you configure OSPF to match. Even then, network-type mismatches and DR/BDR assumptions can create avoidable pain when someone makes a subtle change or when a topology deviates from the template.
IS-IS also elects a designated role (DIS) on broadcast segments and creates a pseudonode to reduce flooding. However, SP cores typically avoid shared multi-access in the core and run point-to-point everywhere. In that environment, IS-IS feels simpler because the configuration surface is smaller: set levels, set metrics, set authentication, and you are largely done.
This is not a claim that OSPF is hard. It is a claim that IS-IS gives you fewer knobs that can quietly diverge across vendors.
4) Simplicity advantage #2: hierarchy without ABR gymnastics
OSPF hierarchy centers on areas and the special role of area 0. Area design is powerful, but it can become operationally heavy as the network grows. You must keep area 0 contiguous or use virtual links (which most operators avoid). ABRs summarize, translate LSA types, and can create edge cases when policies drift. When area boundaries multiply, troubleshooting often requires thinking about which LSA type exists where and why.
IS-IS hierarchy is Level-1 and Level-2. Level-2 behaves like the backbone. Level-1 behaves like an area. L1/L2 routers sit at the boundary. Many SPs run L2-only in the core to keep it even simpler: one level, one topology, one set of rules. When they use hierarchy, it usually aligns with real failure domains or administrative boundaries.
The practical simplification is that IS-IS area design rarely turns into complex LSA-type reasoning. You still must design it well, but the mental model stays compact.
5) Efficiency advantage #1: TLV extensibility keeps growth tidy
IS-IS encodes most information in TLVs. That matters because real networks evolve. You add IPv6. You add TE attributes. You add SR SIDs. You add flex-algo, multi-topology, or new adjacency attributes. In a TLV world, you add a TLV and keep the rest intact. You do not need to redesign the entire message format.
OSPF has extension mechanisms, including opaque LSAs, and the ecosystem supports many OSPF extensions. The difference is the “feel” of evolution: IS-IS grows by adding TLVs to LSPs; OSPF grows by adding new LSA types or new uses of existing types. Both work, but TLVs often produce a smoother upgrade story because unknown TLVs can be ignored safely by devices that do not support them, while supported devices use them.
This is one reason IS-IS appears frequently in networks that adopt TE and Segment Routing early and at scale. The protocol’s encoding structure makes it comfortable to carry extra attributes without turning into a fragile patchwork.
6) Efficiency advantage #2: database synchronization is pragmatic and visible
IS-IS uses Complete Sequence Number PDUs (CSNPs) and Partial Sequence Number PDUs (PSNPs) to synchronize LSPs and request missing pieces. This model makes it straightforward to reason about database health. When something is missing, the protocol has a clear request/response rhythm.
OSPF uses LSA flooding with acknowledgements and uses database description packets (DD) during adjacency formation. That also works well. The operational difference is subtle: IS-IS’s CSNP/PSNP model is easy to inspect and aligns naturally with the idea of “here is my database summary; request what you need.” In large operational environments, that simplicity helps when you debug partial database issues.
Operational intuition (conceptual) IS-IS: - LSPs carry TLVs (topology + attributes) - CSNP advertises "these are the LSPs I have" - PSNP requests "send me LSP X/Y that I'm missing" OSPF: - LSAs carry topology + attributes by LSA type - DD exchanges summaries during adjacency bring-up - LSReq/LSUpd/LSAck finalize synchronization
7) Efficiency advantage #3: IP independence reduces bootstrapping weirdness
IS-IS runs directly over Layer 2 and does not require IP adjacency to form. This can simplify bootstrapping in environments where IP addressing or reachability is still being established. It also means IS-IS does not depend on IP in the same way when you bring up a new core link or when you rebuild a router from scratch.
This does not mean OSPF cannot bootstrap cleanly-it often does. It means IS-IS can feel more forgiving during bring-up when addressing changes, especially in designs where you treat loopbacks as identity and you want the IGP to establish reachability quickly without depending on higher-layer behavior.
8) Where IS-IS really wins: TE, SR, and transport attributes
Modern SP transport is not only shortest-path routing. It is traffic engineering, fast reroute, constraint-based path selection, and sometimes multiple algorithmic topologies. IS-IS is widely deployed in these environments because it carries TE and SR attributes naturally and because operator tooling and vendor support in SP contexts often assume IS-IS.
8.1 Traffic Engineering and SR in practice
When you deploy RSVP-TE or SR-TE, the IGP becomes the source of truth for topology and constraints: link bandwidth, affinities, SRLG hints, latency metrics (where supported), and SR SIDs. IS-IS carries these attributes through TLVs in a way that stays consistent as you evolve the network. That reduces the chance that “core routing” and “TE policy” become separate, drifting datasets.
8.2 Multiple topologies without multiple protocols
IS-IS supports multi-topology concepts that can help when you want different logical topologies for different service sets. Not every network needs this. But when you do need it, having it integrated into the IGP model reinforces the theme: one protocol, one database philosophy, multiple controlled outcomes.
9) Operational simplicity: troubleshooting tends to be more direct
Operators often describe IS-IS troubleshooting as clean. In typical SP deployments you see point-to-point links, L2-only core, stable metrics, and TLV-based attributes. When a problem occurs, you usually ask a small set of questions:
- Are adjacencies up at the expected level(s)?
- Do I see the expected LSPs and sequence numbers?
- Do CSNPs/PSNPs indicate missing or stale LSPs?
- Does SPF compute the expected next-hop given metrics and constraints?
- Do TE/SR attributes (if used) match the intended design?
OSPF troubleshooting can be equally systematic, but it often requires more context about area boundaries, LSA types, and interface network types-especially in mixed or legacy designs. In a pure point-to-point OSPF core, OSPF can be very clean too. The point is that IS-IS tends to stay clean even as you add attributes and features because the TLV model absorbs growth gracefully.
10) When OSPF is a natural fit (and why that doesn’t change the IS-IS case)
OSPF remains a strong choice in many networks and is often the default in corporate environments due to familiarity, training depth, and broad support. In enterprise networks, OSPF’s area model and its integration with IP addressing can be very natural. Many tooling ecosystems assume OSPF. Many teams have deep OSPF muscle memory, and that is a real operational asset.
The question is not “can OSPF scale?” It can. The question is “which IGP stays simplest as the network evolves into a transport fabric with SR, TE, multi-domain constraints, and continuous maintenance?” That is where IS-IS earns its reputation.
11) Design patterns that keep IS-IS simple and efficient
IS-IS becomes a jewel when you deploy it with discipline. Here are patterns that consistently work in SP transport:
- L2-only core where possible: one level reduces cognitive load and boundary complexity.
- Strict loopback discipline: treat loopbacks as identity; keep them stable and reachable; avoid ad-hoc addressing changes.
- Consistent metrics: define a metric philosophy that reflects capacity/latency tiers and avoid constant tuning; use TE policies for premium intent.
- Authentication everywhere: use consistent authentication policies to reduce accidental adjacency formation.
- Bounded flooding domains: align levels with real failure domains if you use hierarchy.
The same discipline applies to OSPF. The difference is that IS-IS often requires fewer design exceptions to remain stable at SP scale.
12) Common pitfalls and how to avoid them
IS-IS is not immune to mistakes. The most common operational issues are avoidable when you know what to look for.
- Level mismatches: adjacencies form only when both sides share a level. Standardize interface level settings and validate during turn-up.
- MTU mismatches: both IS-IS and OSPF can suffer MTU-related adjacency issues. Treat MTU as baseline and validate in templates.
- Overloaded LSPs: as you add TLVs (TE/SR), LSPs can fragment. That is normal, but you must monitor LSP counts and ensure platforms handle the scale.
- Metric chaos: frequent metric tweaks cause traffic churn. Use a stable metric strategy and move premium intent into TE/SR policy where possible.
- Unplanned flooding domains: avoid large broadcast segments in the core; prefer point-to-point links to keep protocol behavior predictable.
None of these pitfalls are unique to IS-IS. The point is that IS-IS gives you a clean baseline when you avoid avoidable complexity.
13) Migration thinking: moving from OSPF to IS-IS without drama
Many operators consider IS-IS after running OSPF for years. A safe migration respects two truths: routing changes are operationally risky, and you do not migrate for novelty. You migrate because you want a simpler transport control plane that scales with TE/SR and multi-domain growth.
A typical approach runs IS-IS in parallel in a controlled domain, validates stability and tooling, then expands gradually. Avoid coupling the migration to unrelated changes unless you have strong change discipline and lab validation. The goal is to keep user experience stable while the control plane evolves.
14) The practical takeaway: why IS-IS feels like a transport engineer’s protocol
IS-IS is not mysterious when you see it as a transport tool. Its strengths align with SP core realities: point-to-point links, a need for clean hierarchy, a steady stream of new attributes (TE/SR), and a requirement for predictable operations under continuous maintenance.
OSPF remains excellent in many contexts. But when you optimize for simplicity and efficiency at scale-especially in modern IP transport fabrics-IS-IS often ends up as the quieter, more adaptable choice. That is why operators call it the hidden jewel.