IS-IS vs OSPF: Which One Should You Learn — and Run?

The short answer

Here is the whole comparison in a few sentences. OSPF and IS-IS are two systems that do one job: they keep every router in a network holding the same up-to-date map, so each router can work out the best road for your data. OSPF is the one most companies run, and the one almost every engineer learns first. IS-IS is its older cousin, and it is still the favourite inside the very large backbone networks that carry the internet itself. If you are choosing what to learn: OSPF first, IS-IS second if you aim at carriers, cloud giants or high-speed trading firms. If you are choosing what to run: OSPF for a normal company network, IS-IS for a huge backbone, and — in a modern data centre — possibly neither. Everything below is the why, in plain words.

Picture two delivery firms using the same road atlas. Both send drivers out to report every new road and every closure. Both pin those reports on the same wall map. And both plan routes with the same rule: take the cheapest total road. The difference is in the paperwork. One firm files everything in folders that belong to one numbering system. The other writes each fact on its own labelled slip, so a brand-new kind of fact is just a new slip in the same folder. That filing difference — not the map, and not the route maths — is most of what separates OSPF from IS-IS.

First, what is the same — and it is most of it

Start here, because most arguments about these two skip it. Both begin the same way: neighbouring routers introduce themselves with small "hello" messages and agree to work together — engineers call that agreement an adjacency (in plain words: a neighbour partnership). When anything changes — a link fails, a new one appears — the routers that saw it write a short update note and pass it to their neighbours, who pass it on, until every router has it. That passing-along is called flooding, and it is really just everyone making sure nobody is working from an old map. OSPF calls these notes LSAs; IS-IS calls them LSPs. Different names, same thing: map updates.

Every router keeps all the notes it has received in one pile — its copy of the map (engineers call it the link-state database). Because everyone floods every note to everyone, every pile ends up identical. Then each router runs the same shortest-path maths over its own copy, giving each road a price tag (the cost — fast, reliable roads get low prices) and picking the cheapest route to everywhere. When the map changes, everyone re-runs the maths and settles on the new routes; that settling is called convergence. An engineer who truly understands one of these protocols already understands about eighty percent of the other. Mostly the vocabulary changes, not the ideas.

That also settles the most common argument: neither protocol is magically "faster" in a normal design. How quickly a network settles after a failure depends on how fast the failure is noticed, how fast the notes flood, how the re-calculation timers are set, and how big the map is — all design and tuning choices, not a property printed on the box. If a network recovers slowly, the fix is almost never "swap the protocol".

Difference 1: how their messages travel

Think of it as two ways of sending the map updates. OSPF sends its messages through the normal postal system. Its notes ride inside IP — the same addressing system your data uses — on IP's own numbered channel 89 (engineers say "protocol 89"; IP has numbered channels the way a building has numbered doors, and OSPF has its own door). IS-IS uses its own private courier instead. Its messages travel directly over the cable itself, one hop at a time, without using IP at all. Its routers do not even introduce themselves with IP addresses: each one carries a name tag from an older addressing family, called a NET (Network Entity Title) — it looks like 49.0001.1921.6800.1001.00.

Why would anyone want the private courier? Because of the worst day of the year. If the IP addressing on a link is broken or mis-typed, OSPF's messages cannot travel that link — the very system that would fix the addressing problem is cut off by it. IS-IS messages do not care: the courier does not need street addresses to walk next door, so the neighbour partnership stays up and the network can still heal itself. The price of that independence is small but real: before anything else makes sense, you have to learn to read those name tags.

Difference 2: how they divide a big map

A map of ten routers fits on one page. A map of ten thousand does not — so both protocols let you cut the map into pieces, and each router only keeps the fine detail for its own piece. This is where their shapes genuinely differ, and the diagram shows it.

OSPF works like city districts around one central station. Each piece of the map is an area. One special area, Area 0, is the backbone, and the rule is strict: every other area must connect directly to Area 0, and traffic between areas crosses the backbone. Done well, areas keep each router's map small — a router only needs street-level detail for its own district. Done carelessly on day one, they add border crossings a small network never needed.

IS-IS works like local streets feeding one long ring road. It divides by level instead of area number. Level 1 routers know their own local area in detail. Level 2 routers know how to travel between areas. A Level 1/2 router does both jobs. The backbone is not one special area — it is simply the unbroken chain of Level 2 and Level 1/2 routers linked together, wherever they happen to be. And here is the part big networks love: you are allowed to skip the local level almost entirely and run one huge, flat Level 2 map. Doing the same in OSPF means one giant Area 0, which its design tolerates far less gracefully.

Difference 3: how they grow new features

Remember the two filing systems from the start. This is where the labelled slips pay off. Almost everything IS-IS carries is a TLV — a slip that says "here is what I am, here is how long I am, here is the fact". When the world invented new facts to carry — IPv6 addresses, traffic-engineering numbers, the labels used by segment routing — IS-IS just added new kinds of slip. The folder never changed; the slips multiplied. One IS-IS setup therefore carries IPv4 and IPv6 together, in a single map.

OSPF's paperwork is more bound to its numbering system, so growth historically meant printing new kinds of form — and for IPv6, printing a whole second manual. IPv6 in OSPF is a separate sibling protocol, OSPFv3, usually run as a second, parallel setup next to OSPFv2: two neighbour partnerships, two maps, two of everything. (OSPFv3 can carry IPv4 as well, on paper — but the two-setup pattern is still what most engineers meet in the field.) At backbone scale, IS-IS's one setup carrying both families is a genuine saving in daily work, not a footnote.

The smaller print

Who chairs the meeting. When several routers share one cable (a typical office LAN), having everyone exchange notes with everyone is noise. So one router is elected chair: in OSPF it is called the designated router, with a backup chair (the BDR) ready to take over. IS-IS elects a chair too (the DIS) but keeps no backup — and if a stronger router joins later, it can take the chair away, which OSPF's chair never suffers. Small difference, slightly different behaviour when a chair fails.

Price tags that can go high enough. Remember each road gets a price tag, and the maths picks the cheapest route — so the tags must be able to tell a fast road from a slow one. Old IS-IS price tags stopped at 63, like a price list that cannot tell a footpath from a motorway; every modern IS-IS network switches to "wide" tags, which reach 16,777,215. OSPF has the mirror-image trap: it works each tag out from the link's speed against a reference speed, and with the factory reference, every modern 10G, 25G and 100G link rounds down to the same price of 1 — the maths then cannot prefer the motorway. Raising that reference is a one-line fix that old networks often never got.

Side by side

Why the giant backbones picked IS-IS

Three reasons, in the order the people who run them usually give. First, size without border gymnastics: one flat Level 2 map with hundreds of routers is a normal IS-IS design, so the backbone grows by bolting on routers, not by re-drawing district borders and re-planning which area touches the centre. Second, new features arrived cheaply: because labelled slips made growth easy, IS-IS picked up IPv6, traffic engineering and later segment routing cleanly. Segment routing, in plain words, means writing a packet's route as a short list of stops stuck to the packet itself — and the giant provider cores that use it very often run IS-IS underneath to hand out those stops. Third, it does not depend on the thing it fixes: the system that heals the network can still form its neighbour partnerships on a link whose IP addressing is broken — one less circular problem on the worst day of the year.

None of that makes IS-IS "better" in a 40-router campus. It makes it better fitted to one particular shape of problem: huge, long-lived, hungry for new features, and run by a small expert team who chose it once and have kept it for decades.

Why companies picked OSPF — and were right to

A company network has a different shape: many sites, many hands, people changing jobs, and real value in the next engineer understanding the design at 2 a.m. OSPF wins there on people, not packets. It is taught first in almost every course, it appears in every vendor's company-network design guide, every tool supports it, and the pool of engineers who can run it is the widest there is. Its district model, whatever its rules, also matches how companies actually look: a head-office backbone with branch districts around it. And for a normal estate, running OSPF is a solved, boring problem — and in operations, boring is a compliment.

One honest third answer belongs in any modern comparison. Inside many of today's data centres, the switches are arranged like a ladder: a bottom row plugged into the servers, a top row connecting the bottom row together (engineers call this a leaf-spine fabric). In those buildings, the plumbing routes underneath everything — the underlay — are often run by neither protocol. They use eBGP instead: the between-organisations protocol, borrowed inside, giving each switch its own number and simple one-to-one partnerships with its neighbours — no shared map to flood at all. So "which of the two should the new fabric run?" is no longer always a two-way question.

So: which should you learn, and which should you run?

Learn OSPF first if you are heading for company roles. It is the interview and certification baseline, and its map-and-shortest-path ideas carry straight over to everything else. Learn IS-IS next if you are aiming at carriers, cloud giants, high-frequency trading or segment-routing work — job adverts in those worlds name it, and courses rarely teach it, which is exactly why our full IS-IS guide (linked below) exists. Knowing both, and knowing they are cousins rather than rivals, is the real senior-engineer signal.

Run OSPF for a small-to-large company network with a mixed team and standard equipment — one area until the map genuinely grows big enough to need districts. Run IS-IS for a carrier core, a very large backbone, or a segment-routing underlay looked after by one expert team — wide price tags, mostly Level 2. For a brand-new leaf-spine data centre, look at eBGP for the plumbing before defaulting to either. And in every case: the protocol your on-call team can troubleshoot half-asleep beats the prettier one they cannot.

Four mistakes this comparison prevents

1. Copying a carrier design into a campus. A flat, all-Level-2 IS-IS core is elegant at 500 routers and pointless ceremony at 15, where a single-area OSPF design would be understood by every new hire on day one. 2. Splitting OSPF into areas on day one. Areas are a scaling tool, not a rite of passage. Splitting early means border routers (the ABRs that sit between areas) and summary lines — writing "all of the north side" on the map instead of listing every street — long before the map is big enough to need either. 3. Leaving factory price tags in place. IS-IS's old tags cannot tell a 100G link from a 1G link, and OSPF's factory reference speed flattens every modern link to price 1 — both quietly produce nonsense routes on fast networks until the wide tags or the raised reference are set. 4. Arguing about the protocol instead of checking the design. Slow settling, partnerships that keep dropping, and odd route choices are almost always timer settings, a mismatched cable setting, area design, or a physical fault first. Check the design before blaming the acronym.