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 (click to enlarge).

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?

This is just one of the scenarios covered in the DMVPN: from Basics to Scalability webinar (register here). We’ll also discuss OSPF, BGP, RIP and ODR routing as well as highly-scalable solutions like unidirectional routing and hierarchical hubs in Phase 3 DMVPN.

Update: You might want to read the solution.

3 comments:

  1. 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 :)

    ReplyDelete
  2. 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?

    ReplyDelete
    Replies
    1. 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).

      Delete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.