Building network automation solutions

9 module online course

Start now!

Can you run OSPF over DMVPN?

Ian sent me a really good OSPF-over-DMVPN question after watching my DMVPN webinar:

In the DMVPN webinar you discuss OSPF design and configuration. However, Cisco design guide says you should use a different routing protocol from what you use on your LAN but you seem to suggest it is okay to extend your OSPF network out to the DMVPN edge by continuing to use OSPF albeit in a different area.

The main issue you face when running OSPF over DMVPN is scalability: OSPF does not scale as well as other routing protocols when used over DMVPN.

Because OSPF is a link-state protocol, the topology database of every spoke router has to contain full topology of the DMVPN area (and LSAs for all IP prefixes inserted into the area by ABRs) and if you believe a low-end router cannot handle more than 50 routers in an OSPF area (that’s the “classic” OSPF design recipe), you see how limited we are. Furthermore, DMVPN cloud has to be a single subnet, so all the spoke routers attached to the same DMVPN cloud have to be in the same OSPF area.

You can implement OSPF flood reduction on the hub router in combination with reliable static default routing on the spokes to increase OSPF scalability.

You can make things a bit better by making the DMVPN area totally stubby (in which case you need Internet VRF for Phase 2 DMVPN), so at least the changes in the non-DMVPN part of the network are not causing SPFs (or partial SPFs).

According to Cisco’s presentations, the number of spoke sites in an OSPF-based DMVPN can be pushed to low hundreds (I would seriously doubt that the low-end spokes would survive that, but maybe they would), while you can go above 500 with EIGRP and above 1000 with passive RIP.


OSPF over DMVPN works just fine as long as the number of spoke sites is low (I would keep it below 100, but it obviously depends on the CPU capabilities of the platform you’re using for the spoke sites), you keep the DMVPN subnet in a separate area and make that area a stub or totally stubby area. If you have a larger number of spoke sites, it makes more sense to go with a distance vector protocol and redistribution.


  1. But it does look like there should be no big scaling issues when using LSDB filtering with NHRP Phase 3: spoke routers are no longer a problem (they only need one/two default route(s)), it's the hub router that becomes control-plane scalability bottleneck due to the number of OSPF adjacencies it has to maintain. One may also mention the impact of SPF runs in the hub due to topology events at the spokes.

    However, the mesh of adjacencies at the hub could be scaled adding more tiers to the tree structure (after all, this is why they recommend phase 3). Additionally, use of iSPF will make the impact of full SPF runs in the hub almost negligible, due to clean tree-like structure of hub-and-spoke topology.
  2. Even with LSDB filtering you still have to send hellos from the hub and the multicast replication is the next roadblock (that passive RIP just whizzes past).

    Also, if you have redundant DMVPN links, your OSPF topology database becomes way more complex.
  3. That's exactly the neighbor maintenance problem at the hub - one of the classic problem for scaling any protocol that maintains active adjacencies. As I mentioned, this could be alleviate by splitting the topology into tree, as opposed to plain "fat" star.

    Theoretically, if you would use P2MP+P2P network types over the DMVPN cloud, DC-extension could be enabled to suppress Hello packet exchange. The only problem here is that Cisco OSPF implementation does not support RFC 3883 for inactive peer detection, AFAIK :) Therefore, as an alternative, Hello timers could be tuned to properly pace the packet flow and match the hub capabilities.

    Furthermore, DMVPN redundancy is normally realized in form of multi-homed tree topologies that are perfectly OK for iSPF optimization, due to their clear hierarchical structure. Using OSPF flood reduction (DNA bit) would further allow eradicating periodic flooding completely and make LSA flooding more lightweight.

    Speaking generally, scaling almost any routing protocol in purely hierarchical structure is much easier compared to a more complex graph following say power-law structure. OSPF may seem a bit more resource consuming, but could be scaled just fine with the addition of extra bolts and knots. I just with they support all extension designed for OSPF out there :)
Add comment