OSPF nonbroadcast one-sided neighborships

While writing my post about OSPF over DMVPN, I noticed something funny. When you set an OSPF network to non-broadcast, you need to set a manual neighbor. A fun trick with this is, that only one side needs the neighbor command, and the neighborship will come up. I thought this would be a nice way to keep configuration simple: Just put the same neighbor command at each spoke, and be done with it.

I noted a problem with this configuration, however, that turned out not to be a problem with my patience. Please follow me through this rabbit-hole, and see what it seemed my configuration didn’t work.

The problem

What actually happens when you set this up? Surprisingly little. You set the neighborship, you wait a bit, and then you get the message that the neighborship is down.

What happened? Shouldn’t OSPF start setting up the neighborship when one side attempts this?
The secret is in the OSPF priority. Apparently, if the side with the neighbor command has priority 0, the neighborship will not come up. Apparently, a nonbroadcast neighborship will first elect itself as DR, before setting up the neighborship. If it cannot elect an interim DR, it will not set up the tunnel:

Fix attemp #1: Interface priority

A fix is to set the priority to 1, so it will become BDR, then set up the neighborship. The problem is that, when the hub reloads, one of the spokes will take over as DR and remain there.

Fix attempt #2: Neighbor priority

I thought there might be another fix: if you set the priority on the neighbor statement, you let OSPF know you want that neighbor to become DR.

And see it doesn’t seem to work at first:

But exactly two minutes after the dead timer expired, this happens:

It worked, but it took TWO minutes plus dead timer? What happened? I shut down both tunnel interfaces to simulate a freshly starting network. I unshut the spoke before the tunnel, resulting in the ATTEMPT state failing before the wait timer on the hub interface expired.1 You can see here that the Hub elects itself as BDR almost 4 seconds after the neighborship attempt failed. The spoke apparently waits 2 minutes before reattempting. This seems like a logical explanation:

Back to the original problem

So , was I just too impatient the first time around? Let’s me reset everything. I shut both tunnels, and I first unshut the hub. I wait until it is back up and considers itself DR:

Everything is ready, so now I unshut the tunnel on the hub, and I get the following:

I thought this was maybe an order of operations thing, where the OSPF packet gets sent before NHRP is registered correctly. However, adding the command ip ospf transmit delay 2 to the interface doesn’t change it’s behaviour on this interface. The interface will still start right away:


I cannot find a good explanation for this problem, except that sometimes I am just too impatient.

  1. Remember: The wait timer and dead timer are the same value. 

Leave a Reply

Your email address will not be published. Required fields are marked *