When Is Something SD-WAN?

A couple of days ago, I wrote on LinkedIn asking you what a SD-WAN solution should consist of.

https://www.linkedin.com/posts/danieldib_sdn-sdwan-wan-activity-6583614108971655168-BH8x

The post was meant to create a discussion and there were a lot of great answers. Some of the features are “must have” and some of them are “nice to have”. I’m not claiming to have all of the answers but here are some of my thoughts on the topic.

Automated VPN – There should be a mechanism to help you build the IPSec tunnels. You should not have to configure them manually. Traditionally, we often used something like DMVPN to build the tunnels for us. Consider the following:

• How are devices onboarded? Who can join the overlay?
• Are tunnels built using certificates or pre-shared key?
• How often are keys rotated? If at all
• How do you prevent a stolen router from joining the overlay?

Separation of control- and data plane – This one is debatable but there should a mechanism to influence topology of the overlay, and routing of the edge devices, using a central mechanism. With DMVPN, we had the ability to do Hub & Spoke or fully meshed, but there was no granular control. We could influence routing by using for example BGP communities. Consider these things:

• Can I influence the topology of my overlay from a central place?
• Can this be done per VPN?
• Can I modify forwarding behavior of my edge routers?
• How granularly can I do this?

Transport Independence – This one is basic but still important. Does the solution support using any form of transport such as MPLS, internet and supporting also LTE and not only Ethernet?

Separate Transport- and Service Side – Is the transport side truly separated from the service side? We used to do this by using front door VRFs so that the transport interfaces were separated from the LAN interfaces. This provided us a couple of things:

• Isolate reachability from outside to our LAN
• Minimize risk of route recursion loops
• Ability to use any addressing in the LAN without conflicting with transport side

This really does sound obvious but I’ve heard of SD-WAN solutions having issues where the addressing used by the SP conflicted with the customer’s addressing. Not a good place to be in.

Application-aware Routing – We’ve been using things like IP SLA and PfR to provide application-aware routing, that is, the ability to send traffic on different paths depending on how a transport is performing, in regards to the amount of packet loss, latency, and jitter. This provides the ability to protect against brownouts and not only blackouts. Also a DPI engine is needed to be able to identify applications. Consider these things:

• How is the performance of the transport being measured? Is it ICMP? BFD? Or measuring performance of the actual traffic?
• What type of conditions can it react to?
• Can it measure for different QoS classes? Based on DSCP?
• Can it react to varying amounts of bandwidth? Think a RF based WAN

API – Having a GUI is nice but there also needs to be a way of interacting with the solution using code. That way, you can have a software pipeline where a new site gets spun up and you could even do CI/CD to check that everything came up OK.

Segmentation – Segmentation is getting increasingly more important. You may want to separate guests from employees or different BUs from each other or having a way of on-boarding acquisitions. There should be segmentation and it preferably you should be able to leverage the same tunnels and not building new ones. Consider these things:

• Does my solution support segmentation?
• How many VPNs?
• Different topologies per VPN?
• Does the segmentation require new tunnels?

There are a lot of things I haven’t brought up. I haven’t talked about cloud managed, or security features, or FEC, or packet duplication and many other things. These are all considerations but I believe that to qualify as SD-WAN, you should fulfill the things I mentioned in this post. As I said before, I don’t claim to have all the answers, I’m just giving you some things to consider to get through the marketing hype. Good luck with your SD-WAN deployments!