Proof of Concept, 1st step into the SD-WAN journey

Proof of Concept

After selection of the preferred solution and prior to the roll-out of an SD-WAN solution, we strongly recommend taking some time to set-up a Proof of Concept (PoC) with your preferred supplier. Before going into details, it is important to understand the differences between demo, PoC and pilot.

A demo is a good starting point to get a first impression of the solution. In most cases it is available off-the shelf. You get an idea of the look-and-feel of the portal and the key concepts you can expect from the solution. However, you must work with some dummy data and cannot simulate specific use cases.

If you want to test customized use cases prior to implementing your network, then a PoC might be the right choice. PoCs are easy to set-up, as these are executed in a lab environment, so no impact on your production environment. Every service provider taking SD-WAN seriously should be able to provide you with a PoC.

A pilot is set-up on (part) of the live customer network and brings therefore most value as behaviour of applications in a pilot environment are most likely the ones you will discover in production as well. Besides testing features and end-user experience, this is also a good moment to finetune implementation procedures and collaboration with your chosen MSP.

Now we understand the differences and values of demo, PoC and pilot, let’s zoom in in the PoC phase. It’s important to think upfront what you want to achieve with the PoC and define which tests are relevant for you.

Below you find some typical use cases you should consider testing:

Basic traffic flows

%

One of the key benefits of SD-WAN is being able to split traffic over different paths. This allows to off-load less mission critical or latency sensitive traffic to less expensive internet VPN’s. This test sounds obvious and will be skipped by a lot of people in a PoC, but every vendor uses their proper algorithms for path selection, so it’s a good idea to get familiar with these algorithms and ensure they do what you expect.

Dynamic path selection

%

Once the default routes are defined, we need to test what happens when network conditions change. For example, by increasing latency or jitter at a certain value, we want traffic can be moved to a more stable circuit. And, when the network falls to normal conditions again, traffic should be re-swapped to their ‘default’ path.

User experience during link failure

%

An issue in your underlay connectivity can happen. It is important to know upfront what the impact will be on your end-users in that case. Will traffic be redirected without interruptions?

Edge device failure

%

Your critical sites need to be protected against single point of failures. If you use 2 devices in high-availability mode at a remote site, it’s good to know upfront that traffic is being rerouted to the secondary CPE in case of failure of the primary.

Orchestrator failure

%

In case the connection between the management layer and a branch site fails, there is no impact on the end-user service. It’s good to test this, to be assured there will be no surprises once in production.

Not part of the PoC as such, driving a PoC makes you also familiar with the look and feel of the portal, the different menus, ways to configure policies, reporting capabilities, etc.

In order to evaluate a PoC in an objective way, you need to define upfront the success criteria. For each use case and test you have to define the expected result, and this result should be measurable. Purpose at the end of the day is having all tests succeeded successfully. Only then, the PoC can be considered as successful and the journey towards a confident implementation can start.

Share this post