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.
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.
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.
Questions on how our expertise can assist your company?
Feel free to contact us for more information.