While working on the design for a 20+ site DMVPN migration, I realized something often overlooked in the documentation for an internet-based DMVPN deployment. To maintain a zero (or minimal) touch deployment model in an internet-based DMVPN, default routing is a must for dynamic tunnel establishment between hubs and spokes. The public addressing of spoke routers is typically at the mercy of one or more service providers and even if you have been allocated a static address per the service contract, these still have a tendency to change due to reasons out of the customer’s control. This is especially true in teleworker-type deployments with a broadband service provider. To deal with this issue, an engineer has two options: maintain a list of static routes on every hub/spoke router comprised of every public and next-hop address in the DMVPN environment or use a static default route pointing out the public interface.

Tough decision, huh? Not so fast.

What happens when you have a transparent proxy deployed in your network at the hub site? No problem, just have the spoke routers carry a default route advertised into the IGP from the hub site. Wait…we are already using a default route to handle DMVPN tunnel establishment between spoke routers. To resolve this issue, we need two default routes: one for clients within the VPN and one for establishing spoke-to-spoke tunnels. We could add two defaults to the same routing table with the same administrative distance but load balancing is not the behavior we want and our tunnels would throw a fuss due to route recursion. How about policy-based routing with the local policy command configured for router-initiated traffic? Pretty ugly. Enter FVRF or Front-door VRF.

Front-door VRF takes advantage of the VRF-aware features of IPSec. While touted as a security feature in the scant Cisco documentation by separating your private routing table into an isolated construct from your public address space, this feature also provides an ideal solution for maintaining separate routing topologies for DMVPN control-plane traffic and user data-plane traffic.

So how does all this work? Pretty simply if you are familiar with the VRF concept. First, on your spoke routers, create a VRF to be used for resolving tunnel endpoints:

Note the only VRF-specific configuration is the crypto keyring statement. Both the ISAKMP policy and IPSec transform-set configuration is no different than a typical deployment. GET VPN could be used instead, if your security posture calls for it.

Configuring the tunnel interface is standard fare except for the “tunnel vrf” argument. This command forces the far-side tunnel endpoint to be resolved in the VRF specified. By default, tunnel endpoint resolution takes place in the global table which is obviously not the behavior we want. Also, notice the “ip nhrp shortcut” and “ip nhrp redirect” arguments. These two commands mean we are using DMVPN Phase 3 and it’s fancy CEF rewrite capable for spoke-to-spoke tunnel creation.

Last, lets add our default route within the VRF:

ip route vrf FVRF 0.0.0.0 0.0.0.0 10.1.1.2 name DEFAULT_FOR_FVRF

And we’re done! At this point, assuming your hub site configuration is correct, you should have a working DMVPN tunnel.

In the output below, notice the “fvrf” and “ivrf” sections under tunnel interface 1. The concept of IVRF is the exact opposite of FVRF: tunnel control-plane traffic operates in the global routing table, and your private side operates in a VRF. IVRF can be tricky in that, if your spoke routers are managed over the tunnel, all management functionality (SNMP, SSH, etc.) must be VRF-aware. Recent IOS releases have been much better with VRF-aware features but YMMV:

You can now configure your favorite flavor of IGP as would normally would (globally, that is) without impacting DMVPN control-plane traffic. In this scenario, OSPF is used with the tunnel interfaces configured as a point-to-multipoint network type. The static default route in the FVRF table handles tunnel establishment while the dynamically-learned default via OSPF handles the user data plane within the VPN:

Front-door VRF works best when used on both hub and spoke routers. Why? Well, anytime a new spoke is to be provisioned, you have to do zero configuration on the hub site. Configure the spoke router, ship it out the door, and have the field plug it in at their convenience.