OSPF and IS-IS: Interior Routing Protocols for ISPs

BGP gets the attention because it is what connects you to the rest of the internet, but it is not how the routers inside your own network find each other. For that you run an Interior Gateway Protocol, and for ISPs that almost always means one of two link-state protocols: OSPF or IS-IS. The IGP is the quiet foundation everything else sits on — your BGP sessions, your MPLS paths, your management reachability all depend on the IGP knowing how to get from one of your routers to another.

Choosing and operating an IGP well is less about which protocol is theoretically superior and more about understanding what an IGP is for, what it must never be asked to do, and which of the two fits your team and your scale. The protocols are more similar than their partisans admit; the design discipline around them matters far more than the choice between them.

What an IGP is actually for

An IGP has one job: give every router inside your network an automatically maintained map of the internal topology, so each can compute the best path to every internal destination. The destinations that matter are your own infrastructure — primarily the loopback addresses your routers use to source BGP sessions and other control-plane traffic, plus your point-to-point links. This is a small, slow-changing set. A mid-sized ISP might have a few hundred internal prefixes in its IGP, and they change only when you add or remove network equipment.

The defining property of an IGP is fast, automatic reconvergence. When a link or router fails, the IGP detects it, floods that information to every router, and each router recomputes its shortest paths — typically within a second or two on a well-tuned network. Traffic that was using the failed path shifts to the next best one without human intervention. That speed and automation is the whole point, and it is achievable precisely because the IGP carries a small, stable table.

How link-state routing works

Both OSPF and IS-IS are link-state protocols, and they share the same core mechanics. Each router describes its own local connectivity — which neighbours it sees and the cost of each link — in a small advertisement. These advertisements are flooded reliably to every other router in the area, so that eventually every router holds an identical copy of the complete topology database. This is fundamentally different from older distance-vector protocols, where each router only knew what its neighbours told it about reachability and trusted those summaries blindly.

Once every router has the same map, each one independently runs a shortest-path-first calculation — the Dijkstra algorithm — rooted at itself, to determine the lowest-cost path to every destination. Because every router computes from an identical database, they all agree on the topology and produce consistent, loop-free paths. Link costs are usually set inversely to bandwidth or by hand, so traffic naturally prefers faster links. When the topology changes, only the affected advertisements are reflooded and the calculation reruns; the protocol does not start from scratch.

OSPF: the widely understood default

OSPF is the most widely deployed IGP in the world, and that ubiquity is its greatest practical strength. The pool of engineers who know it well is enormous, the documentation and training material is exhaustive, and almost every vendor's implementation is mature and interoperable. OSPF scales by dividing the network into areas, with a backbone area that all other areas attach to, which limits how far topology changes propagate and keeps the per-router database manageable.

For most enterprises and a large share of ISPs, OSPF is the safe default. If your priority is easy hiring, abundant learning resources, and a protocol your team already understands, OSPF answers the question without drama. Its main historical limitation was that it ran as separate protocol instances for IPv4 and IPv6, meaning a dual-stack network effectively ran two parallel OSPF topologies to maintain.

IS-IS: the carrier-core favourite

IS-IS is favoured in many of the largest service-provider cores. It organises hierarchy through levels rather than areas, and it has a reputation for scaling cleanly and remaining robust in very large topologies. Its most distinctive trait is that it was not originally designed around IP at all — it runs directly on the data link layer and carries IP reachability as additional information, which means a single IS-IS instance handles IPv4 and IPv6 together without running parallel topologies. For operators building large dual-stack backbones, that integration is a genuine operational simplification.

The trade-off is people. The pool of engineers with deep IS-IS expertise is smaller than for OSPF, and learning resources, while good, are less abundant. IS-IS rewards networks large enough and stable enough in their staffing to invest in that expertise; it is less obviously the right call for a smaller team that already lives and breathes OSPF.

OSPF versus IS-IS at a glance

The rule that matters most: keep BGP out of your IGP

Whichever protocol you choose, the single most important design rule is to keep the boundary between your IGP and BGP absolutely clean. Your IGP carries internal infrastructure routes — a small, stable set. BGP carries customer routes and the full internet table — a large, constantly churning set. These two route populations have opposite characteristics, and the IGP is engineered for the first and actively hostile to the second.

Pour customer prefixes or full-internet routes into your IGP and you destroy the very property that makes it useful. Every BGP update would trigger an IGP reflood and a shortest-path recalculation across your entire network. The database would balloon, convergence would slow to a crawl or stall, and a single flapping customer link could destabilise routing for every router you operate. The correct pattern is to let the IGP carry only loopbacks and links, run BGP between routers on top of that stable foundation (typically anchoring BGP sessions to the loopbacks the IGP makes reachable), and let BGP do the heavy lifting of customer and internet reachability. Tools like route summarisation and stub areas exist specifically to keep the IGP lean.

How to choose and what people get wrong

For most teams the honest answer is: run whatever your engineers already know well, and run it consistently everywhere. If your staff knows OSPF, OSPF is almost certainly the right choice — operational familiarity prevents more outages than any protocol feature delivers. Reach for IS-IS when you are building a large core, you value its integrated dual-stack handling, and you have or can hire the expertise to operate it confidently.

The common mistakes are predictable. Mixing multiple IGPs internally adds complexity for no benefit — pick one and standardise. Designing a single flat area and letting it grow until convergence degrades is another; introduce hierarchy before you need it, not after it hurts. And by far the most damaging mistake is the one above: leaking BGP scale into the IGP, usually through a careless redistribution statement, and then wondering why the network has become slow and fragile. Audit your redistribution boundaries deliberately.

The takeaway

OSPF and IS-IS are both excellent link-state IGPs, and for the overwhelming majority of networks the choice between them matters far less than the discipline of keeping the IGP small, stable, and strictly separate from BGP. Pick the one your team can operate confidently, design in hierarchy early, and guard the boundary with BGP so customer and internet routes never contaminate your interior. A lean IGP underneath well-controlled BGP filtering and policy is what keeps a growing ISP network both fast to converge and easy to reason about.