In the first post of this series, I discussed why organizations are moving to the Internet for their WAN needs, and a few of the available designs for building a WAN using Cisco DMVPN. This post will examine factors that need to be considered at the hub and at the spoke, and different designs to meet scalability requirements at the hub.
The hub is critical in a DMVPN deployment; spokes use it as a mapping server to find the public IP of other spokes. The behavior is similar to how any-source multicast (ASM) works where a shared tree is built first, and then the potentially more optimal source tree is built. Think of the hub as the rendezvous point (RP) of the network.
Factors affecting hub requirements
Number of tunnels -- The number of tunnels is important for several reasons. The more tunnels that terminate at the hub, the more routing protocol packets and control plane packets that need to be generated and sent towards the spokes. The combined effort of GRE, NHRP and routing protocol packets may be substantial depending on the number of tunnels and more importantly, the rate of change in the network.
IPsec performance -- The hub has to encrypt packets towards the spokes and decrypt incoming packets. The more traffic going through the hub, the more IPsec capacity is needed. This may lead to using a device with support for IPsec offloading.
Throughput -- The hub must be able to handle the traffic from all the spokes. This will vary depending on whether centralized Internet access is used and how much of the traffic from the spokes goes to central locations as opposed to spoke-to-spoke traffic.
Firewall capacity -- If there is a requirement for firewalling the traffic, this can either be done at the spoke, the hub, or in a central location beyond the hub. Routers will generally have less firewalling capacity than a dedicated firewall.
Design options
Allowing for spoke-to-spoke tunnels will put less stress on the hub than centralizing all the traffic. Scaling of hubs can be achieved through different designs. One design is to use the Server Load Balancing (SLB) feature. In this design, all hubs use the same IP from the viewpoint of the spokes and the SLB feature distributes incoming mGRE packets among the hubs.
The beauty of this design is that it’s easy to add hubs when scaling is required or remove hubs for maintenance and no need to update configuration of the spokes.
Hubs can also be scaled by layering them; this is especially relevant in networks that span a wide geographical area. Regional hubs can then connect to core layer hubs and tunnels are divided among the regional hubs to share the load.
Don’t neglect the spokes
I’ve covered some design factors for the hub, but what about the spokes? There are design considerations for them as well; neglecting the spokes may lead to a poorly performing DMVPN network.
One of the main scaling factors of the spokes is the number of routes. Branch routers can normally only hold a few hundred routes or a few thousand at the most. For this reason, summarization is desirable from the hub towards the spokes. That said, DMVPN phase 2 networks can’t easily be summarized because the next-hop on routes from the hub towards the spokes can’t be the hub for spoke-originated routes. This makes the scaling properties of phase 2 networks worse.
However, Phase 1 and phase 3 networks can use summarization or even send a default route from the hub to make the routing table as small as possible. This removes most of the scalability concerns from the spoke point of view.
There are also other factors that will affect the lower level design of the spokes. How many virtual routing and forwarding (VRF) instances do you need? VRFs are useful for separating the transport network from the DMVPN overlay. Do you need to do firewalling? How much bandwidth is necessary to meet the site requirements? What routing protocols does the router support?
Building a WAN using Cisco DMVPN focuses a lot on the hub, which is natural considering its importance. However, what if the hub performs perfectly, but the spoke can’t keep up with the rate of change or the number of routes? All these factors must be considered when building a WAN.
In the final post of this three-part series, I’ll look at different routing protocols in DMVPN designs and the factors that lead to one or another.
Subsea cable alternatives can provide a level of comfort for those concerned about disruptions. Realistically, they will continue to play a small, but critical role in the short term.
Maintaining existing network infrastructures often incurs huge technical debt before newer technologies are adopted over time.
Amid ongoing regional uncertainties, telecom infrastructure in the Middle East has expand to include terrestrial low-latency network infrastructure, which offers resilience and agility in navigating political complexities without relying solely on undersea networks.
