SD-WAN – Glorified DMVPN?

I had an interesting discussion with Jon Cooper in the Network Collective Slack. The discussion was around SD-WAN. We were discussing if SD-WAN is just a “glorified DMVPN” or if it’s something more than that. Note that this was a bit tongue in cheek comment from Jon but it’s interesting for the sake of discussion.

To compare the two, let’s look at some of the design and operational challenges of running a DMVPN.

Physical design – How many Hub routers do you need? In a DMVPN, the Hub router is a special type of device that is responsible for mapping the underlay IP address to the overlay IP address. If a Hub needs to be added, this Next Hop Server (NHS) needs to be added to the spokes. With Cisco SD-WAN, this is handled by the vBond which is a virtual machine running in a public cloud. Adding a device is simple as the WAN edge routers use a hostname (DNS) to ask for the IP of the vBond. This means that the physical design is less rigid.

Logical design – In a DMVPN, you need to decide on the number of DMVPN clouds. Do you do a single cloud or dual cloud? Dual cloud means deploying two tunnels while single cloud requires more from the routing protocol in order to do traffic engineering. The logical design is also fairly rigid for most commonly it will be either fully meshed or Hub and Spoke. With Cisco SD-WAN, it’s a single overlay. You don’t need to think about the number of clouds. It’s also more flexible because you can have different topologies for different VPNs.

Number of Overlays – With a DMVPN, if you need several VPNs, either you need to run several overlays or run something like MPLS on top of it. This adds complexity and it also means you can’t run PfR over the tunnels. With Cisco SD-WAN, a single overlay is used but still several VPNs can be used.

IPsec – Almost all DMVPNs use IPsec for encryption. Especially if internet is used as a transport. What are the challenges with IPsec? The first is that it requires some knowledge of IKE and IPsec in order to be able to set it up. The main challenge though is around crypto keys. How do you rotate your keys? With Cisco SD-WAN, the crypto key is rotated automatically for you. One solution for DMVPN is of course to use certificates, which is the next point.

Certificates – The use of certificates is challenging. It requires a working PKI environment and it’s challenging to get the certificate deployed to the router. Do you prestage? Or how do you get the cert on the device once it’s deployed? You need to reach the router to deploy the cert but you don’t want to have the router join the WAN until it has a cert. It becomes a chicken and egg problem and usually requires either prestaging or to have some kind of “out of band tunnel” to deploy the cert. With Cisco SD-WAN, the devices have certs that are embedded to the device and generating the CSR, getting it signed and deploying the cert is automated. This removes almost all of the headaches of maintaining certs.

ZTP – With Cisco SD-WAN there is support for Zero Touch Provisioning (ZTP). This means that a router can boot up, acquire an IP via DHCP, join the overlay and get a template deployed to it. This was more complex to do in a DMVPN network where the router must first get its configuration from somewhere. This was not automated and required the use of custom tools or relying on DHCP options to for example pull the configuration from a TFTP server. However, if certificates were used this could become quite complex.

Routing – Running a DMVPN means running a routing protocol. Most commonly EIGRP or BGP. This requires some knowledge to set up and tweak and to make sure routing are following the expected paths. This can be fairly simple or quite complex depending on the requirements. With Cisco SD-WAN, OMP is responsible for building the overlay and the administrator doesn’t really need to understand much to get routes flowing in the network. For troubleshooting, it’s always good to understand what runs under the hood though.

Policies – Most of the points above can in some way be automated in a “traditional” WAN but requires some more knowledge. However, traffic engineering in a DMVPN network can be complex, especially if you want use different paths based on the geography or site type. There’s not an easy way to get all your European sites to use a certain path. You have to configure all of the European spokes to do so. Even if you use something like BGP communities, that still requires that the local router understands to do with the community.

Configuration and rollback – Using automation, a lot of the pain of managing configurations can be managed or removed. However, there are still things that need to be addressed. How do you know that a router is using the configuration it should? What happens if someone configures something that is not in line with the configuration standard? How do you avoid deploying a bad configuration? How can you roll back to a known good state? Much of this is handled in a solution like Cisco SD-WAN where you can enforce the configuration of a device. In the backend, ConfD is used to make sure that you are trying to apply a valid configuration and that can keep track of the state of the configuration. The device will also roll back the configuration if it loses its connection to the vManage NMS.

Management – In a DMVPN WAN, there is not a single management tool to handle the WAN. You need some form of NMS, some form of automation tool, somewhere to store configurations, somewhere to store device images. It’s more complex to manage a WAN where there are many different management interfaces and many organizations have gone from having several people managing the WAN to one or fewer than before when they moved to SD-WAN. With a centralized management it becomes easy to deploy policies to the WAN and to check what the operational status is.

Compliance – I’ve already touched on it but in today’s networks where there are many devices and with complex configurations, how do you check that your network is compliant? What software are you running? Is the configuration compliant? You’d be surprised, or maybe not, that in customer networks it’s quite common to see 10-15 different software versions used for the same type of network device. This means that the network is not in a compliant state and that it’s opening up to more security holes than it should. With Cisco SD-WAN you can enforce both configurations and software versions.

Service chaining – How do you force certain traffic to traverse a firewall but not other traffic? How do you do this for some sites or a specific site? Doing this without some policy framework is complex and prone to error and probably requires PBR or a lot of nerd knobs to be configured. Using Cisco SD-WAN it’s possible to do service chaining by advertising special service routes.

DIA – Setting up Direct Internet Access (DIA) in a DMVPN network can be challenging. How can you deploy this to all or a range of sites? How do you send only some routes out the DIA? How do you send only cloud traffic such as O365 out the DIA? This can result in a quite complex configuration. Using Cisco SD-WAN, a template can be used to set up the DIA which makes it a lot easier to configure the DIA.

So… Is SD-WAN just a “glorified DMVPN”? Yes and a lot more. As always, one size does not fit all and always let your business requirements drive your network design. That said, SD-WAN is here and it’s real, and it’s a lot easier to manage than a DMVPN.