EIGRP Edge Routing w/ DMVPN

We have a ton of remote sites (payments centers, small offices, etc) with a single router on-site, typically an 871 series hanging off a cable modem with a static IP. These routers are terminated via point-to-point GRE tunnels back to a pair of central hub sites. Because we run OSPF, and are poorly summarized, these routers can carry up to 7500 prefixes depending on the area type of the market. All these routers really need is a default route back towards the two hubs in a active/standby model with return traffic to the spokes preferring the active hub site for symmetry. Secondly, provisioning new remotes requires touching both the hub and spoke routers for building tunnel interfaces. The configs on the hub sites can be fairly long and annoying to troubleshoot, especially with static IPs of the remote sites changing over time and lack of cleaning up old configs.

To address the size of the RIB on the spokes, we could use statics and redistribution on the hubs and floating statics on the spoke routers. It will reduce the RIB of the spokes but its fairly high maintenance on both of the hub sites. With a static for a loopback, voice and data vlans, your looking at least 90 statics on some of the hub routers. That’s not helping the config complexity problem. Distribute lists do not work with OSPF in the outbound direction and the interface-level “ip ospf database-filter all” won’t help us leak a default to the spokes. We need distance vector. EIGRP stub flags and an 0.0.0.0/0 summary towards the spokes would be perfect.

To cut down on the tunnel interfaces, the obvious choice is DMVPN. There’s is little to no spoke-to-spoke traffic so DMVPN will purely serve as a tool for configuration simplification.

Here’s the DMVPN configuration for the two hub sites. First, notice there are no static unicast maps, multicast maps or nhs configuration pointing to the opposite hub site. Basically, I don’t want a tunnel and ultimately a EIGRP neighbor relationship built from Hub site 1 to Hub site 2. There would be no reason to have this in place and will only cause issues since both hubs are only advertising a default route out their tunnel interfaces. Secondly, Hub site 1 has it’s tunnel interface delay set to 100 so all spokes will prefer the default route via Hub site 1 after calculating their feasible distance. Lastly, the default route being generated to the spokes is being set with an administrative distance of 254. The reason for this is because when you manually summarize, a summary-route is generated in the routing table pointing to Null0 with an administrative distance of 5. While this is not necessarily a problem for CIDR blocks where more specific prefixes exist in the RIB, this can cause traffic following a default route to be black-holed. We want to set this null route above any IGP-learned default route so it is not preferred. Oh, and notice split-horizon and next-hop-self for EIGRP are not being disabled on the tunnel interface. We are not interested in spoke to spoke tunnels nor are we interested in spokes having all routes within the DMVPN. Disabling split-horizon would allow the spoke prefixes to be advertised back out the tunnel interfaces to the other spokes. Disabling next-hop-self would allow these prefixes to be advertised with a next-hop of the advertising spoke router (which is where the NHRP query would come into play for a spoke-to-spoke tunnel).

Here’s the DMVPN configuration for the spoke sites. It’s pretty straightforward. I found the “ip nhrp registration timeout” command had to be added on the spokes. When testing failure of a hub site, there were issues with EIGRP adjacencies being reformed with the failed hub router when it came back online. Because we don’t want Hub site 1 and Hub site 2 to be NHRP peers, the hub site’s will not query one another for NHRP mappings. So instead, the spokes are periodically broadcasting their presence every 5 seconds. When the hub comes back online, it will receive the registration message from the spoke, rebuild its mGRE tunnel and reform its EIGRP adjacency. The spoke routers do not necessarily need to be configured as stubs as they should never be queried but it is good practice.

So that takes care of getting a dynamic default to the spokes, but now we need advertise the routes from the spokes back into the rest of the network. Remember, we set the delay of the tunnel interface of Hub site 1 so all spokes would prefer its default route. When we are redistributing EIGRP into OSPF, we will be injecting them as E2s with a metric of 100 from Hub site 1 and a metric of 200 from Hub site 2. This should give us traffic symmetry. Also, we are only permitting specific blocks for redistribution. We don’t want anyone routing any prefix they damn please.

Share this:

Like this:

5 Responses

I have run into a problem with this configuration. Although the dynamic spoke-to-spoke tunnels come up, the client traffic doesn’t use them. This is because the NHRP shortcut route is stuck in VRF land. Normally NHRP shortcut injects the new direct route into the RIB. I’m assuming that this NHRP process is in the VRF and thus cannot put the route into the global table.

I was able to verify this by configuring a static route in the global table pointing to the remote site via the DMVPN IP endpoint of the dynamic tunnel. Then the traffic used the new link without problem.

Any idea on how to get the NHRP shortcut route injection to “leak” from the VRF into the global table? Am I just missing something?

I just remembered from another one of your blog posts that your design doesn’t use spoke-to-spoke tunnels (you don’t need them). So there isn’t any NHRP shortcut in your configs. I guess this is a limitation of using front door VRF in this case. I guess the only solution is to go to IVRF and put the private side in the VRF instead of the public side.

I was just referring to the fact that the DMVPN setup in your earlier article did not require dynamic spoke communications. I assumed that you didn’t need that either for the FVRF setup.

Anyhow, it’s all good now. This configuration definitely works even with the addition of NHRP shortcut. It’s really great having a private default for the client traffic and a separate public default for the tunnel establishment. Works like a charm.