Second generation SD-WAN: how to migrate
By Tomas Hedqvist
By Tomas Hedqvist
Do you already have an SD-WAN solution deployed in your network? Then it's probably a first generation SD-WAN, built as a black box or grey box solution.
A second generation SD-WAN for deployment on uCPE is now gaining ground. It is based on white box hardware with open virtualization platforms. Unlike the first generation that has a strong dependency on the SD-WAN vendor, the second generation SD-WAN is built on a flexible and open foundation with best-of-breed VNFs from multiple vendors.
Whether you have a first generation SD-WAN installed in your branch offices or one or more stand-alone networking appliances filling the same functions, the principles of migrating to a second generation SD-WAN are more or less the same: start with what you have, virtualize existing legacy applications on a uCPE, then expand and evolve the solution. This is just as relevant for communication service providers: offer your customers a platform that allows them to keep their applications as VNFs, then expand and evolve your service offering.
Since there is often quite a lot of dependencies with legacy SD-WAN solutions through configuration and integration with automation, orchestration and other systems, they are not always the easiest components to change in the network without completely disrupting operations.
Fortunately, if you want to migrate to a virtualized network, almost all first generation SD-WAN appliances are also available as VNFs that you can run on a uCPE. It's the same application but packaged as a virtual machine, meaning you can keep your legacy security and communication solutions and focus on virtualizing the infrastructure.
The most important step when migrating to a second generation SD-WAN is that you build a virtualized base for your network functions by replacing old black box and grey box appliances with white box hardware and an open virtualization environment.
To select hardware you first need to establish what kind of connectivity you want and how much resources you need to run the VNFs and the virtualization. Virtualization platforms originating from the datacenter like OpenStack are often quite resource hungry and a poor choice for uCPE. An edge native virtualization platform like Enea NFV Access on the other hand is designed especially for uCPE, with minimized resource footprint and high networking performance. This makes it possible for you to save hardware costs. Platforms designed for uCPE are also often less complex and easier to provision and manage compared to data center solutions.
It is important that you make sure the procedure to deploy the uCPE and make the actual shift from the old equipment is simple enough to be handled by non-IT skilled staff. You will probably not be there yourself, so the staff at hand should be able to fix it with only a simple instruction. You probably don't want much network downtime while carrying out the move, so it needs to be well prepared. If it is, it should be possible to do it less than half an hour.
There is one feature above all others that makes this possible: zero touch provisioning (ZTP). Ideally, you should power on the device and plug in the network cable to automatically retrieve its Day 0 configuration. Depending on whether the virtualization is already installed with a call home address or not, you may need to install it from a USB stick or similar first.
Now that the NFV infrastructure is in place you can keep extending and evolving the functionality on the uCPE. If you have run a monolithic SD-WAN with integrated security or a separate hardware based security appliance, your solution can now be extended with best-of-breed components including separate VNFs for security, routing and so on.
The bottom line is that after migrating to a virtualized platform, you have an open and flexible platform that makes it simple to evolve and adapt your enterprise network for current and future needs.