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 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 now-gone Cisco’s presentations, the number of spoke sites in an OSPF-based DMVPN can be pushed to low hundreds, while you can go above 500 with EIGRP and above 1000 with passive RIP or BGP
Summary
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). Keep the DMVPN subnet in a separate area and make that area a stub or totally stubby area. If you have more spoke sites, it makes more sense to go with a distance vector protocol and redistribution.
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.
Also, if you have redundant DMVPN links, your OSPF topology database becomes way more complex.
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 :)