EIGRP Summarization in DMVPN Phase 2 Networks

Imagine the following scenario: you’ve configured a Phase 2 DMVPN network with a hub and a few spokes. DMVPN is configured properly, IPSec and NHRP are working, you can ping all around the DMVPN cloud.

Next step: configuring EIGRP. You know you have to disable EIGRP split horizon and EIGRP next-hop processing. You even remember to configure interface bandwidth.

Someone told you to minimize the EIGRP routing traffic, so you use EIGRP stub routers on the spokes and route summarization on the hub router. The final EIGRP configuration is shown in the following diagram:

Note: Your network is using 10.0.0.0/8 addresses for LAN links and loopbacks and 192.168.0.0/16 for WAN links.

Would your Phase 2 DMVPN network perform as expected? If not, what’s wrong with it? If you think it has a problem, what would you change?

Don’t cheat, answer the questions before reading the solution.

Recent posts in the same categories

3 comments:

  1. Anonymous 23 October 2010 00:44
    Oh yes, now for the comment! Firstly to answer your question - summarization will hide the next-hop address and prevent phase 2 from creating spoke-to-spoke tunnels, as this functionality requires CEF adjacency to have the next-hop IP of the other spoke. Phase 2 was merely a crude hack to get NHRP working with CEF :)

    Next, for the thoughts I have. Summarizing routes with EIGRP in Phase 2 deployments does not significantly improve scalability if the spokes support EIGRP stub feature. Indeed, the main problem with EIGRP scalability is query scoping, which is effectively implemented using the stub feature. Being distance-vector, EIGRP is not very sensitive to topology change events in hub & spoke networks - incremental updates handle this smoothly. Unlike link-state protocols, EIGRP routing for Phase 2 may handle large hub and spoke topologies better. Of course, for large deployments, BGP could be a better option anyways.

    To finish with, I would like to recall my favorite RFC 1925, truth #11. Back in 2003 DMVPN was proclaimed as uniquely new solution that, however, was built upon the technology used for CLIP optimization back in 90s! And it took Cisco forever to finally stabilize and come with Phase 3. Seriously, shame on them :)
  2. Anonymous 11 March 2013 21:56
    Hello. What would be the problem with having the spokes summarize their networks in phase 2? Won't the hubs re-advertise this summary to the rest of the spokes?
    Replies
    1. Ivan Pepelnjak 12 March 2013 09:17
      Auto-summarization could generate all sorts of interesting side effects, so I disable it by default. Other than that, using summarization on spokes is fine - you shall not use it on the hub router (Phase 2 DMVPN only).
Add comment
Home
Sidebar