In this series on building a WAN using Cisco DMVPN, I explained how DMVPN works and factors that affect the scalability and design of a DMVPN. I’ll wrap up the series by looking at routing considerations for a DMVPN design. Choosing the right routing protocol is very important in building a scalable and stable DMVPN. Issues may be hidden until the DMVPN becomes large enough, but it’s always better to pick the right protocol from the start than to have to redesign at a later stage.
OSPF
Many organizations use Open Shortest Path First (OSPF) as their interior routing protocol. It may seem a natural choice to run it over DMVPN as well, but doing so comes with some serious limitations. OSPF is a link state protocol, thus all routers in an area must have the same view of the network. Any change in the area will trigger all routers in the area to run the shortest path first (SPF) algorithm. Depending on the size of the network, this may lead to a lot of SPF runs, which could affect the performance of branch routers with small CPUs.
DMVPN requires a single subnet, so all OSPF routers would have to be in the same area. Summarization is only available on area border routers (ABRs) and autonomous system boundary routers (ASBRs), which means that the hub must be an ABR for it to summarize routes. Misconfiguring the designated router (DR) or backup designated router (BDR) role would also break the connectivity. Any form of traffic engineering is very difficult in a link state protocol such as OSPF.
An OSPF DMVPN design may look like this:
Follow these guidelines if implementing OSPF over DMVPN:
For small scale DMVPN deployments, running OSPF may be acceptable. Large scale implementations will either run EIGRP or BGP.
EIGRP
Enhanced Interior Gateway Routing Protocol (EIGRP) is an advanced distance vector protocol. This makes it more suitable for DMVPN since it’s not restricted by the topology limitations of a link state protocol. EIGRP can summarize at any point, manipulate metrics at any point and does not have any concept of areas. This makes it much easier to deploy and scale EIGRP in a DMVPN topology.
Deploying EIGRP over DMVPN is fairly straightforward. In phase 1 and phase 3, the next hop of routes is the hub. In phase 2, the hub must not set itself as the next-hop for routes, which is the default for EIGRP. Split horizon must be disabled at the hubs so that routing updates can be sent out the same interface (tunnel) they came in on.
The main factor when deploying EIGRP is to turn all spoke routers into stub routers. EIGRP queries its neighbors when a route goes away and this affects the scalability and convergence of EIGRP.
Keep track of how many adjacencies the hubs have; generating hellos may become a significant task if there are a lot of neighbors, which could be somewhat alleviated by increasing the hello timers. A typical DMPVN EIGRP design may look like this:
The reason for running the DMVPN in a separate autonomous system (AS) to the core is that it makes the routes external, which simplifies traffic engineering if the WAN layer is also connected to a MPLS WAN or other WANs. Note that W1 and C1 in the topology are clustered routers. Make the spoke routers into stub routers and keep track of the number of peers on the hub routers.
BGP
Border Gateway Protocol (BGP) is also a viable solution for DMVPNs. It is well known for its proven capability to scale to a large number of peers/routes and with default timers, it puts less strain on the routers than other routing protocols.
What needs to be considered for BGP over DMVPN? Should iBGP or eBGP be used? Consider these factors when choosing iBGP or eBGP:
eBGP is the easy choice for DMVPN due to the next-hop being modified on outbound updates, but comes with some other challenges. Use the same AS at all sites or unique AS? 16-bit AS numbers allow for 1024 private AS numbers which means there could be no more than 1024 spokes. This works well except for really large deployments and keeps the BGP loop prevention mechanism in place. It requires a lot of configuration at the hub though with unique AS numbers at the spokes. 32-bit AS numbers allow for over 94 million private AS numbers, taking care of the lack of AS numbers.
There’s also the option of running the same AS at all site but it requires the command “allowas-in” at the spokes or “as-override” at the hubs, which modifies the loop prevention mechanism and could lead to loops in the control plane.
To help with the configuration of peers, there is a dynamic neighbor BGP feature which allows a router to listen for incoming BGP messages.
The limiting factor of iBGP used to be that the route reflector would not modify the next-hop of the routes that were reflected. Since the next-hop was not modified, running iBGP was not possible without also running an IGP to calculate the next-hops. This has been solved by a new feature with the command neighbor next-hop-self all, which will modify the next-hop also for reflected routes on the route reflector. This works well for phase 1 and phase 3 DMVPN deployments, making iBGP a very viable choice and the preferred choice unless other requirements warrant the use of eBGP.
For DMVPN design, EIGRP and BGP are the natural choices and BGP can scale to the highest number of spokes. Good luck in your deployment of DMVPN.
Discover the benefits of scalable backbone and network services for application and cloud providers.
Network automation is gaining momentum. Here's how you can drive this powerful technology to its full potential.
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.
