DR versus DIS: What’s the Diff?

OSPF and IS-IS, both link state protocols, use mechanisms that manage flooding on a broadcast link, as well as simplify the shortest path tree passing through the broadcast link. OSPF elects a Designated Router (or DR) to simplify broadcast links, and IS-IS elects a Designated Intermediate System (or DIS—a topic covered in depth in the IS-IS Livelesson I recently recorded). Beyond their being used in two different protocols, there are actually subtle differences in the operation of the two mechanisms. So what is the difference?

Before we dive into differences, let’s discuss the similarities. We’ll use the illustration below as a basis for discussion.

Broadcast network operation in link state protocols

Q1 and Q2 illustrate the operation of a link state protocol without any optimization on a broadcast network, with Q1 showing the network, and Q2 showing the resulting shortest path tree. Q3 and Q4 illustrate link state operation with optimization over a broadcast link. It’s important to differentiate between building a shortest path tree (SPT) across the broadcast link and flooding across the broadcast link—flooding is where the primary differences lie in the handling of broadcast links in the two protocols.

Let’s consider building the SPT first. Both protocols operate roughly the same in this area, so I’ll describe both at the same time. In Q1, there is no DIS (DR)—called a pseudonode from this point forward, so each pair of intermediate systems (routers) connected to the link will advertise connectivity to every other IS (router) connected to the broadcast link (so A will advertise B, C, and D as connected; B will advertise A, C, and D as connected, etc.). From E’s perspective, then, the broadcast link will appear to be a full mesh network, as shown in Q2. Full mesh connectivity adds a good bit of complexity to the tree, as you can see in the diagram.

To reduce this complexity, the intermediate systems (routers) connected to the broadcast link can elect an intermediate system (router) to generate a pseudonode, as shown in Q3. Regardless of their actual adjacency state, each intermediate system (router) reports it is only connected to the pseudonode, and the pseudonode reports what appears to be a set of point-to-point links to each of the intermediate systems (routers) connected to the broadcast link. The result is an SPT that looks like Q4; there is an extra hop in the SPT, but it is much simpler to calculate (even in reaction to topology changes).

For calculating the SPT, then, OSPF and IS-IS act much the same. The difference between the two actually lies in the way flooding is handled across the broadcast link.

Assume, for a moment, the illustrated network is running OSPF, and router A receives an updated LSA. Router A will flood this new LSA to a special multicast address that only the DR (and BDR) listens to. Once the DR has received (and acknowledged) the LSA, it will reflood the new LSA to the “all routers” multicast address on the broadcast segment.

Now let’s change the situation, and say the network is running IS-IS. Again, intermediate system A receives an updated LSP—but rather than sending this new information just to the DIS, it floods the LSP onto the entire link. So what does the DIS do in terms of flooding? The only thing a DIS does on the flooding side of things in IS-IS is to send out periodic packets describing its database (Complete Sequence Number Packets, or CSNPs). If an IS happens to fail to receive a particular LSP that was flooded by another IS connected to the same link, it will notice the missing LSP in its database, and request it from the DIS.

The flooding mechanisms, then, are completely different between the two protocols—differences that show up in the implementation details. For instance, IS-IS doesn’t elect a backup DIS, but OSPF does—why? Because if the OSPF DR fails, some router connected to the link must take over flooding changed LSPs, or the database can become desynchronized. On the other hand, if the DIS fails, there’s not much chance of anything bad happening. If one intermediate system drops an LSP, when a new DIS is elected and sends a CSNP, the loss will be noticed and taken care of. For much the same reason, the IS-IS can be preemptively replaced, while the OSPF DR cannot be.


  1. alan.wijntje on 11 May 2016 at 4:47 am

    He Russ,

    Thank you for the nugget of wisdom, I am actually busy reviewing routing protocols (need to recertify my CCDP) so this fit in nicely together with the flooding domains versus areas post (although I guess those won’t be on the exam hahaha).

    This post to some extend reminded me off your earlier post on the CAP theorem and more specifically how the protocols (try to) ensure consistency.

    It also made me wonder about availability as in the CAP theorem availability is denoted as the ability to read the database, so thinking about this I’m wondering why don’t the intermediate systems sync (read/pull) the DR/DIS database to ensure consistency instead of “assuming” some flooding will occur (waiting for the DR/DIS to push)?
    While I appreciate the distinction is minute (push or pull information) I’m just curious if this was ever considered and what reasons (the infamous why) there are for the push.



    • Mohammad Moghaddas on 14 May 2016 at 1:33 pm

      Hi Alan,

      Regarding a read/pull mechanism for Intermediate Systems, off the top of my head, I can imagine a scenario where one or more problematic (whether by misconfiguration or a software bug) Intermediate Systems keep the DIS busy with pulling/reading the database. Besides, though the traffic volume caused by this issue is presumably unseeable, but it’s abusing the network and could cause misbehavior in the broadcast domain.

      Please correct me if I’ve made a wrong assumption.



  2. khanwannabeccie on 11 May 2016 at 4:50 am

    I am currently reviewing the trial sessions on this and its an absolute delight to learn from you!
    do you have plans to do this for other topics too?


    • Russ on 12 May 2016 at 7:49 am

      I am working with Cisco Press on an OSPF LiveLesson, and a network design LiveLesson, as well as another book (if it’s approved).



      • khanwannabeccie on 13 May 2016 at 1:58 pm

        sounds like a deal!!
        after the other lessons are released, there should be like a bundle price for all of your courses!

  3. goie on 12 May 2016 at 5:06 pm

    Thank you for this very useful info. i saw few of your isis live lesson video on safari online books and all i can say is that these are the best videos lecture i have ever seen. it was a great privileged for me to learn from video lectures of one of the great guy in networking history.
    desperately waiting for your OSPF live lesson videos