1

For one of our customers we have 1 NOC router with ~10 L2L VPNS running OSPF. We are slowly trying to migrate these L2L tunnels to a DMVPN solution. We decided to implement a second router as the DMVPN Hub (DMVPN was mysteriously breaking L2L tunnels when both on the same router as soon as ISAKMP SAs expired).

The original router is the DR and our newly implemented router is the BDR.

All of the documentation I have come across stress that the hub needs to be the DR. Can we implement phase 2 DMVPN with our hub as a BDR? What are any possible implications for running with this configuration?

Thanks!

3

So before the explanation you could configure a separate OSPF area (or possibly the second ospf process) that is purely for the DMVPN, that way the hub is the DR for that OSPF instance, you can initially make the cost higher to go over the DMVPN than adjust the cost when you're ready to cutover.

Another solution could be to run EIGRP over the DMVPN instead since it's all Cisco equipment you don't really have to worry about interoperability, but seeing how you already run OSPF in your LAN you're probably much more comfortable and experienced with it.

The only other option (I'm aware of at least) would be to a dual hub topology which may break some things since you you already have L2L tunnels to each site on one of the hubs, I've never had to attempt to configure this in tandem though so I'm unsure what the result would be. You may want to do this after the fact though anyways in order to have some redundancy should the DR go down.

The reason that this needs to be configured this way is because the hub is what creates the NHRP mappings in between all the sites, with the nhrp multicast map each site sends it's updates to the hub and the hub then forwards it onto all the other spokes. The spokes learn of the routes in the NHRP 'cloud' but since the DR isn't part of that topology it has no way of sending updates through NHRP since the BDR doesn't send out updates until it becomes the DR, with no way to forward the updates there is no way to propagate the information needed for the spoke-to-spoke tunnels. Furthermore the spoke routers cannot form an adjacency with the DR making it since as defined in the RFC 2328 'On broadcast and NBMA networks, all routers become adjacent to both the designated router and the backup designated router' Reference Sec. 10.4

Let me know if this helps or if you have any more questions!

| improve this answer | |
0

Thank you for the input, Fallacy!

We ended up (which now seems obvious in hindsight) creating a separate area for the DMVPN network. All spokes are properly seeing our newly implemented router as the DR and NHRP is working as intended.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.