Why do so many service providers run IS-IS instead of OSPF?
Show the answer
Say this first
Partly history: several large ISPs chose IS-IS in the 1990s when mature implementations were available, and vendors kept investing in it. Partly design: it is TLV based, so new features such as IPv6, MPLS traffic engineering and segment routing arrived as new TLVs in the same protocol. It runs outside IP, so its control plane cannot be attacked from a remote IP host. And a flat L2 backbone is simple, with fewer database object types and fewer area rules than OSPF. OSPF can do the job too.
Go deeper
Side by side
| IS-IS | OSPF | |
|---|---|---|
| Carried in | Layer 2 directly | IP protocol 89 |
| IPv6 | Same instance, new TLVs | OSPFv3, a separate protocol |
| Database objects | LSPs with TLVs, one per router per level (plus fragments) | Several LSA types with different flooding scopes |
| Area border | Between routers | Inside the ABR |
| Backbone | Any contiguous L2 routers | Area 0 |
| LAN election | DIS, preemptive, no backup | DR and BDR, not preemptive |
| Default interface metric on Cisco | 10 on every interface | Reference bandwidth divided by interface bandwidth |
| Default hello and hold on Cisco | 10 s and 30 s | 10 s and 40 s on broadcast links |
What an interviewer wants to hear
That the choice is about operations and extensibility, not that one protocol is "faster". Both are link state, both run SPF, both converge in well under a second when tuned. Providers value a stable, simple, extensible core, and IS-IS gives them that with less to tune.
They will ask next
Would you put IS-IS in an enterprise?
It works well, but most enterprise engineers and many firewalls and cloud routers know OSPF better. I would use IS-IS where the team already runs it or the enterprise has a provider-style MPLS core.
Traps
- Saying IS-IS converges faster because it is IS-IS. Convergence depends on timers and SPF tuning in both.