DMVPN EIGRP Scalability: Summary Routes vs Split Horizon

The DMVPN and EIGRP Scaling Constraint

The core challenge in this scenario is managing routing table size and convergence time in a growing DMVPN topology using EIGRP. In a standard Multipoint GRE (mGRE) setup, the hub router (R1) acts as a central point for all spoke-to-spoke traffic. By default, EIGRP enforces split horizon, which prevents a route learned on one interface from being advertised back out the same interface. However, on a multipoint interface like an mGRE tunnel, split horizon behavior can be tricky; typically, routes learned from one spoke are not sent to another spoke on the same multipoint interface if split horizon is enabled, but the primary issue here is the volume of specific subnets.

If the network expands with dozens of branches, each branch advertising multiple specific internal subnets, R1 would receive hundreds of distinct EIGRP updates. Without summarization, R1 would attempt to propagate these specific routes. Even with split horizon considerations, the sheer number of entries in the spokes' routing tables leads to scalability issues, increased memory usage, and slower convergence times during topology changes.

Why Summarization is the Correct Solution

Configuring a summary route (Option A) on R1's tunnel interface aggregates multiple specific subnets into a single, broader prefix. This drastically reduces the number of entries that R1 advertises to the spokes. Instead of receiving 50 specific /24 routes, a spoke might receive just one /16 summary route. This directly addresses the "network is expanding" concern by improving scalability and stability. It aligns with best practices for large-scale routing designs where stable, scalable routing is required.

Addressing Common Misconceptions

Many candidates might consider disabling split horizon (Option C). While disabling split horizon on a multipoint interface allows routes learned from one spoke to be advertised to others (enabling spoke-to-spoke communication via the hub), it does not solve the scaling problem. In fact, disabling it without summarization can lead to routing loops or excessive flooding of specific routes if not carefully managed. The question emphasizes the expansion and the need for a stable, scalable design, pointing toward summarization rather than just enabling basic connectivity features.

Other Options Analysis

• Disable stuck-in-active timer (Option B): This is a troubleshooting measure for EIGRP queries, not a design feature for scalability. It masks symptoms of poor design but doesn't fix the underlying routing table bloat.
• Configure a multipoint interface (Option D): DMVPN relies on mGRE interfaces by definition. Configuring it is a prerequisite, not a solution to the routing table expansion problem described. The interface type is already implied by the DMVPN solution choice.

Therefore, the critical implementation step on R1 to handle the growth and maintain scalability is to configure manual summary routes.