Show 89 – OSPF vs IS-IS Smackdown – Where You Can Watch Their Eyes Reload

In this show we discuss the the differences between OSPF & IS-IS routing protocols and the differences between them.

    • protocol optimisations are both good and bad.
    • How both protocols have poor metric generation
    • OSPFv3 offers some hope for the future.
    • QoS Based metrics in their forms – MPLS TE isn’t getting good adoption.
    • Why do vendors put 10 cent CPUs in their equipment and make using SPF protocols so hard ?


Best Quotes:

Ivan – “There is the right thing to do, which is to choose IS-IS. Then there is the best thing to do which is to choose OSPF.”

Marko: “Then you can watch their Eyes reload”

On the “Unique versus Useful”

A comparison between two routing protocols: OSPF and IS-IS – Radia Perlman – Behind the IEEE Paywall so don’t bother following the link

Multi-topology routing in OSPFv3 (MT-OSPFv3)

IS-IS and OSPF Difference Discussions – IETF DRAFT

OSPF and IS-IS : Choosing an IGP for Large-Scale Networks – Jeff Doyle


Petr Lapukhov
Marko Milovejic @icemarkom and Blog – My Network Stories
Ivan Pepelnjak –@ioshints

Greg Ferro
Greg Ferro is a Network Engineer/Architect, mostly focussed on Data Centre, Security Infrastructure, and recently Virtualization. He has over 20 years in IT, in wide range of employers working as a freelance consultant including Finance, Service Providers and Online Companies. He is CCIE#6920 and has a few ideas about the world, but not enough to really count. He is a host on the Packet Pushers Podcast, blogger at and on Twitter @etherealmind and Google Plus.
Greg Ferro
Greg Ferro
Greg Ferro
Greg Ferro

Latest posts by Greg Ferro (see all)

  • athompso

    I think you all missed the point when arguing about IS-IS being “easier” to deploy in large, flat networks: it’s easier because it requires less manual configuration – particularly in IOS.  Two statements, I think, in IOS 12.x.  Turning on OSPF requires more planning, more work by an already-overloaded engineer.  Turning on IS-IS requires less planning, less work, assuming the network engineer understands IS-IS already.

    BTW: we’re still running 7206VXRs as core routers… not because they’re our “favourite” router, but because they were good enough to last this long!

    • Marko Milivojevic

      Oh, IS-IS is *by far* not easier to deploy. It’s easier ONLY if you use equal-cost links everywhere, otherwise you need to manually set the metrics.

      • athompso

        Thankfully, I don’t have to worry about links with grossly unequal cost in my network, so I hadn’t noticed that.

      • dbg

        Get yourself a real router, that can calculate IS-IS cost based on reference bandwidth, if this is what you’re after 😉

      • Alexandra Stanovska

         Sidenote, have you realized you already set metric manually for other purposes or protocols? It’s called “bandwidth” command that you put under interface 😉

        • Marko Milivojevic

          Well, “bandwidth” is mostly already set on the interface. 

          Then again, we can argue the bandwidth is not exactly a good metric to begin with in modern networks… We touched on that subject in the show… :-)

  • dbg

    I’ll try to expand what I was saying in twitter yesterday.

    You guys spent quite a lot of time discussing extensibility and separation of topology information from addressing and routing. While it is all true what have been said, but this is not what I expected from the podcast. These points are rather obvious and kinda beaten to death.

    There’re some subtle differences between the protocol though that are worth mentioning.

    1) Fragmentation. OSPF and IS-IS approach to fragmentation is completely different. OSPF relies on IP fragmentation, while IS-IS implements it’s own mechanism. As with any other cases of IP fragmentation, one lost fragment renders the whole PDU useless. With IS-IS fragmentation mechanisms the fragments are largely independent: they are flooded independently, they can be even used for SPF calculations independently (except for fragment 0 of course). They are so independent that the ISO/IEC 10589 doesn’t even call them fragments, it calls them multiple LSPs.

    2) MTU handling. This one is well known: explicit MTU in OSPF DBD, implicit MTU discovery with hello padding in IS-IS, etc. Just one point of interest here: to pad or not to pad when you’re running IS-IS over large MTU environment? Different vendors take different approaches here. Some vendors chose to pad to full MTU, while others pad only to maximum IS-IS PDU length.

    Both approaches have their own merits. Padding to full MTU tries to ensure that MTU on the both sides of the link matches (which is a good thing, mismatching MTU can lead to lots of hard-to-troubleshoot forwarding problems), but it is not fool-proof – IP MTU and CLNS MTU can be configured independently, and padding only checks the latter. So, those who pad just up to maximum IS-IS PDU length, say: “Why bother? You’re not verifying anything on IP layer anyway. What is really important is that the LSPs are able to come through. They cannot be refragmented in the middle of the network, so you really have to make sure that MTU is at least the size of the largest possible LSP fragment. It’s all that matters.”

    3) Hello/dead timers. Very small feature but operationally very important. OSPF timers have to match, and if you change anything the adjacency will flap. It’s not the case with IS-IS.

    4) Initial DB synchronization. OSPF initial LSDB synchronization is very different from ongoing LSDB synchronization which happens as something in the network changes. This procedure is quite complex and since it is not exercised as often as ongoing synchronization, this code path is always less tested than the rest of the protocol machinery. About 80% of OSPF bugs I ever hit with any vendor were about initial LSDB synchronization. OSPF is really overzealous in this initial sync up process – the process can even be started over on some events, which means that it might never complete if such events occur frequently enough.

    IS-IS on the other hand doesn’t do anything special to initially sync the LSDB. It uses exactly the same mechanisms to initially sync up as well as to ensure ongoing LSDB sync while the adjacency is up – all the same CSNP/PSNP procedures. One exception though: the spec says that CSNP goes out to a p2p link only initially, but some implementations chose to ignore that clause and send CSNP on p2p links periodically anyway to make sure the LSDBs are really in sync. The spec doesn’t prohibit it, and I believe it’s a good thing to recheck the state once in a while. You can’t do that with OSPF.

    5) Declaring the adjacency up. OSPF will declare the adjacency up only when it is done with LSDB synchronization. IS-IS on the other hand can do that once hello exchange is complete. In fact modern IS-IS implementations don’t declare the adjacency up immediately, they hold it off for some time to make sure that the things are stable, but this holding off is not really tied to LSDB sync.

    One may think that OSPF approach is more reliable. But it isn’t really. If the router was already part of the network, it already has the full LSDB, and what we need to do is just check that everything is ok. If the router was previously isolated, it’s LSDB is indeed out of sync, and this inconsistency will affect traffic. But it is only traffic to the previously isolated part of the network, which is affected anyway.

    6) Designated router/intermediate system. Everybody knows that OSPF employs DR and BDR, while IS-IS has just one DIS. This fact is connected to my two previous points. OSPF initial LSDB synchronization is complex, heavy, expensive and delays announcing the new adjacency. Nobody wants to go through all that when DR fails, hence the BDR with it’s additional complexity. With IS-IS, it is very simple – new DIS only has to generate a new pseudo-node LSP and this is it.

    7) Flooding dynamics. IS-IS flooding (and synching too!) is governed by very simple and elegant mechanism: two flags per LSP/link (SRM and SSN), and a handful of timers which are generally independent from the network conditions. This mechanism allows IS-IS to continue with it’s own pace even something is lost in transmission. OSPF builds retransmit lists, starts retransmissions, expects acknowledgments etc. In other words, OSPF becomes more aggressive when something bad happens on the link or on the neighboring router, and it can worsen those conditions. This point is mainly theoretical, I’ve yet to see a meltdown caused by this, but it can theoretically happen.
    8) Specification readability. Many people complain that they’re having hard time to read ISO/IEC 10589. I say, once you get used to slightly different terminology (routeing vs. routing, intermediate system vs. router, etc.) the spec is quite readable (the protocol simplicity plays important role here), while RFC2328 is one of the worst RFC I ever seen: it’s convoluted structure makes it excruciatingly painful to find anything – you have to look in four places each giving you a small piece of incomplete information.

    Hmm, it is already 6k of text, and I didn’t even get to areas and design. I can go on for another couple of hours, but there’s nothing really interesting there – I’m not a big fan of areas anyway. My approach here is “go flat if you can, do areas if you must” :)

    • MCL Nicolas

      Jesus, Thanks for these informations … do you actually publish somewhere ? 😉 I guess the PacketPusher’s team got another guest to invite 😉 

      • Daniel Ginsburg

        I don’t, except for an occasional post to my personal blog. Most of the time it is networking related, but not always, and it is mainly in Russian.

      • Markh1289

        Didn’t see the post from Jesus … are you confused with Daniel?

  • Big Evil

    Very nice guys – i learnt a ton of info.

  • Krunal Shah

    Nice discussion, One thing I missed is design difference between IS-IS and OSPF when it is used between PE-CE. 

  • Pingback: EIGRP vs OSPF vs RIP()

  • Brandon Mangold

    Wow, very nice podcast! Very glad to hear Petr Lapukhov on the podcast. I had the immense privilege of attending an CCIE bootcamp with him at INE. He is a really good guy, probably the smartest individual I have ever met.

  • Dan

    Best show ever! Thanks.

  • Toby Jason Davey

    I’ve been studying networking and feel exactly how you described. IS-IS has just been kind of there and we haven’t been taught about it. Which is a shame :/

  • Pingback: OSPF – Design, Packetpushers | Jonas väg till CCIE()

  • Pingback: Hour 74: The state of IS-IS | RoutingNull0 - The Network Engineer Path()