SD-WAN is all the rage these days (at least according to software-defined pundits), but networking engineers still build DMVPN networks, even though they are supposedly impossibly-hard-to-configure Rube Goldberg machinery.
To be honest, DMVPN is not the easiest technology Cisco ever developed, and there are plenty of gotchas, including the problem of default routing in Phase 2/3 DMVPN networks.
In DMVPN Phase 2 or Phase 3 designs a spoke site exchanges encrypted traffic directly with another spoke site. As we usually don’t know the IP addresses of other remote sites in advance, we solve the remote spoke site reachability problem with a default route on the spoke routers pointing to the Internet uplink.
On the other hand, we might want to use a default route throughout the corporate WAN network, be it to simplify routing or to attract all user-generated Internet traffic to the central site for inspection.
The above picture clearly illustrates the problem we’re dealing with – different types of traffic (user traffic versus DMVPN-encapsulated WAN traffic) use different default routes. While you could use PBR to meet this requirement, I’d strongly discourage that – who knows how PBR applied to GRE/IPsec traffic works on platforms that implement IPsec encryption and/or DMVPN encapsulation in hardware.
There’s a much cleaner solution: create a transport VRF with its own routing table and its own default route, and assign the Internet uplink to the transport VRF. The default route used in the transport (Internet) VRF is totally independent from the default route used by the user (or other router-generated) traffic. Problem solved.
Well, there are (as always) a few other bits-and-pieces you have to configure. You have to associate the new VRF with the transport functionality of the DMVPN tunnel, and move the IKE/IPsec functionality to the VRF (Cisco’s IPsec documentation calls this front door VRF – FVRF). You’ll find the necessary details in Cisco’s online documentation or in my DMVPN webinars (which include fully-tested router configurations).
One of the attendees of my recent SDN workshop claimed that the NetBrain network mapping tool gets totally confused when faced with a VRF. There might be other non-VRF-aware network management tools out there – check them out before buying them.
2015-10-23: As an anonymous commenter pointed out, NetBrain 5.2a is fully VRF aware. In any case, make sure you test most complex scenarios that you might encounter in your network when evaluating any network management tool.