This post is a continuation of my previous DMVPN posts and I make comparisons to my OSPF post. Main DMVPN post
Main configuration of the devices used in the lab https://gist.github.com/KasperJak?page=1
EIGRP is much more flexible and it should be apparent quite fast why.
It's basically still proprietary to Cisco equipment, even though they did put it up for the IETF. Something about features not being available to other vendors, which basically means there isn't any reason for them to implement EIGRP. Good thing Denmark is basically Cisco fanatics. Time to dig in.
An NHRP feature we get to see for real in action now, is the routing information via NHRP. So when does NHRP start to route? With EIGRP default routing and spoke to spoke tunnels, NHRP will put information into RIB, marked by "H".
The only thing I have to do initially is removing my OSPF and adding EIGRP. It's pretty straightforward.This configuration wont work, though. A look at spoke3's information: !(/content/images/2016/07/eigrp-trace-no-sum.PNG) Routing information about the 172.16.x.x networks is missing and we don't have a default route either. Spoke3 has no idea how to reach those networks. Two solutions. Either disable split horizon in the hub tunnel interface or create a summary route.
The spokes won't see the 172.16 routes because split horizon prevents EIGRP from advertising a route out the same interface it was received. All routes will be known through the hub, but NHRP will override the information and install the direct route in CEF. Exactly like the ospf P2MP. no ip split-horizon eigrp 1
The better solution, in terms of scalability, is using a summary route. On the tunnel interface apply ip summary-adddress eigrp 1 0.0.0.0 0.0.0.0. Why this is a better solution, is because the spoke routers don't have to process or even look at any specific routes received. The only eigrp route they'll have, is a default to the hub. NHRP will add the precise routes for just the networks the spoke router wants to communicate with, but that is no different than removing split horizon. In the picture below, NHRP routes are added as "H".
At this point hub2 is shut down. Opening the hub2 interface and advertising another default route the same way, creates a path control issue. It's a 2 part issue, first part being how EIGRP applies metric and second part being the single DMVPN tunnel interface.
Part 1: If bandwidth or delay is changed on an interface, it will only be applied as metric on inbound routes.
Part 2: Because the metric is affected inbound, it's not possible from the spoke perspective/interface to manually choose one path. The connection is through one interface, so the metric manipulation will affect all routes anyway. If this was a dual cloud setup, I'd have two tunnel interfaces and then I could apply different metrics inbound.
It is possible to affect the metric of the default route, though. Simply just redistribute a static default route and use the metric parameters when redistributing. Remember, by default, EIGRP only uses delay and bandwidth in the metric calculation, so while you still have to put in a value for the other k-values, they won't have any effect. The downside, spokes will know all routes again and we will have to move to other means of route filtering.
So now I have an active default route pointing towards DC1 and a backup to DC2. What if I have networks on DC2 that the spokes have to communicate with? Those networks, if they "spawn" into EIGRP on the hubs, will be advertised to the spokes, regardless of the default summary. It means the spokes will know the correct way to these networks through EIGRP and won't have to use NHO to get there. These networks can, of course, be summarized as well. The point is, the traffic won't go through the wrong hub in this scenario.
Note1: Everytime you change a summary-address on an interface, EIGRP will perform a graceful restart on that interface, which happens to be connecting every peer in the whole network.
Note 2: There has to actually exist a network that is part of the summary-address for it to advertise. Unlikely to be a real problem, but it's nice to know how EIGRP works.
I think this is a decent place to end the first part. Keep it a bit episodic. At this point I have some options for how to advertise routes in EIGRP and I can't really conclude which way is the best, yet. I need to think about a case study kinda goal for my EIGRP network. Next part will be distribute list filtering, stub routers and multiple DMVPN clouds.
I also have to go through the posts and the github configurations to reformat it. I'm going to use GIST for the "base" configuration and then have the specific configurations for the posts in the scroll-box format. So there'll be a bit of practical website stuff before/inbetween the next post.