DMVPN scalability

Alexander sent me a very valid question: “Do you cover scalability problems in your DMVPN webinar” (register here). Of course I do, more than half of the webinar is devoted to them.

As you know, DMVPN is a combination of multiple technologies, including ISAKMP (key exchange), IPsec (encryption), GRE (tunneling), NHRP (tunnel endpoint resolution) and a routing protocol. Any one of these can be a limiting factor:

  • • ISAKMP is CPU-consuming, more so if you use certificates. Large number of concurrent key exchanges can overload a low-end spoke router in Phase 2/3 DMVPN networks. Use ISAKMP call admission control;
  • The limiting factor of IPsec encryption is usually the throughput. Use hardware encryption modules;
  • Multicast/broadcast packets sent over an mGRE tunnel (for example, routing protocol hello messages or updates) are transformed into numerous unicast GRE packets, potentially overloading the output interface on the hub router. Change the routing protocol;
  • Low NHRP registration timeout on the spoke routers can overload the hub router in networks with very high hub-to-spoke ratios. Increase the NHRP registration timeout;

Most common limiting factor is the routing protocol. OSPF is the worst possible choice, as the weakest spoke router limits the scalability (unless you use flooding filters). EIGRP with stub routers is pretty good (although it’s hard to push it above 350 peers on a 7200) as is RIP and ODR, but they all suffer from the multicast replication issues. For larger networks you should use unidirectional RIP, BGP or static routes.

Do I have to mention that all these choices are explained in details (including sample configurations in the slideware and numerous sets of router configurations covering each and every scenario) in the DMVPN: From Basics to Scalable Networks webinar (and here’s the registration link)?

1 comment:

  1. It is probably worth mentioning the use of GETVPN for DMVPN traffic encryption - this allows for scaling IPsec control/data plane and significantly reducing spoke-to-spoke tunnel latency.

    ReplyDelete

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.