In this post we discuss how SD WAN brings a number of benefits to the deployment of a WAN. We show how SD WAN can reduce the time (and thus cost) of deployment, how it can reduce mistakes, introduce consistency and reduce or remove the need for engineer installs.
Incidentally, if you are a large enterprise managing your own WAN then you should see these benefits directly. If you have bought a Managed WAN then it is likely that your service provider will see them. Nonetheless, it is to be hoped that you would enjoy a better service as a result.
SD WAN allows you to design a template up front, and then have each site deployed using the template (with adjustments for IP Addresses). Devices therefore don’t need to be physically staged, or at least require minimal staging.
With a traditional WAN templates can still be used but they are kept as text files, which can take longer to create and can be misused.
With a traditional WAN, different routers have different Command Line Interface (CLI) commands; making templates more difficult to create. Also, there are many ways to achieve the same result, meaning a lack of consistency to configuration templates.
We periodically hear from businesses who have experienced mistakes in network deployment. One of the reasons for these mistakes is the inconsistent production of router configurations.
SD WAN helps by creating standardisation. The configuration template is contained within the platform, removing the issue of an engineer designing a new configuration for a site. With SD WAN all elements of the configuration are issued centrally by the orchestrator. Thus, there is little for the Commissioning Engineer to configure on a deployment once the business intent overlays are set up.
SD WAN configuration is more intuitive than with a traditional WAN. This is because it uses a Graphical User Interface (GUI) rather than producing lines of code. Although many Cisco products can be configured by GUI, the GUI for traditional routers is less comprehensive and still requires using CLI to complete the config.
SD WAN can reduce the cost of deployment by separating the activities of a highly skilled Design Engineer followed by a less skilled Commissioning Engineer.
A senior engineer will be needed for the template designs and for applying individual site-specific information such as IP Addresses and subnets.
The router then downloads the configuration from the cloud, so there shouldn’t need to be a senior engineer on hand when the install is taking place. Installs should be plug and play.
With a traditional WAN, one would deliver the first couple of sites with a certain understanding of how the configuration will work. Then something might change with the requirements or perhaps something isn’t working as well as it should. Thus, the the config is tweaked for the next few sites. However, if time isn’t taken to go back and change the other sites then the estate will end up with a number of config styles. This can also be caused by a software level changing – what worked on one version of the IOS no longer works on the new.
With SD WAN, if the config needs to change, the template can be changed and then all devices that have that config will be updated remotely.
Sometimes mismatches can happen when different carriers are used. For instance:
SD WAN takes control of the CoS and prioritisation and doesn’t need to interact with the Carrier’s CoS so networks can be delivered consistently regardless of the Carrier.
With a traditional WAN there are a number of ways to configure a device for the same end goal, which can lead to different engineers having different preferences and styles. This can cause problems when engineers don’t understand each other’s styles, and cause a long-term knock-on effect for In-Life management.
With SD WAN you design Business Intent Overlays which effectively create the configuration. Since these Overlays are saved as templates, a change in Design Engineer won’t lead to a change in template designs.
Many SD WAN vendors claim that they provide zero touch deployments. This can be true but not in all cases.
When first deployed to site, the SD WAN device first needs to obtain an IP Address. With Internet Broadband this is likely to be DHCP, so the network will give the device this address. With private networks or Internet with Static IP, an engineer or your managed service provider will have applied this to the device before it is sent out.
The device, then calls home over the internet, using DNS, before being assigned to the SD WAN central orchestrator.
It’s perfectly feasible for the device to call home once plugged in, but some businesses are not happy for their own staff to do this. If you have relied on a managed engineer install in the past, then you may not be prepared (or resourced) to have a zero touch deployment at every site.
What we can say is that there is only a basic config required to get up and running. Once your IT team or Managed Service Provider has access, they can initiate the full configuration to be applied – in which case a technical courier would be sufficient.