Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

9 module online course

Start now!
back to overview

Lock-In and SD-WAN: a Match Made in Heaven

This blog post was initially sent to subscribers of my SDN and Network Automation mailing list. Subscribe here.

I made a statement along these lines in an SD-WAN blog post and related email sent to our SDN and Network Automation mailing list:

The architecture of most SD-WAN products is thus much cleaner and easier to configure than traditional hybrid networks. However, do keep in mind that most of them use proprietary protocols, resulting in a perfect lock-in.

While reading that one of my readers sent me a nice email with an interesting question:

Do you think that a lock-in regarding a specific company is only based on technology? Do you think that a suboptimal technology solution would trigger an introduction of a new vendor? My feeling is that the lock-in is not forced by technology solutions but more relationship oriented.

Obviously, there are all sorts of lock-ins, from contractual, relationship, CYA (nobody was ever fired for buying $vendor), religious (in $vendor we trust), philosophical (I buy from $vendor, therefore I am :D)…

However, being primarily an engineer, I prefer to focus on the technology lock-in (while keeping in mind that technology is nothing more than means to an end). Let’s compare a more traditional hybrid WAN architecture implemented with routers or firewalls to the wonderful new world of SD-WAN.

Traditional hybrid WANs are implemented on multi-purpose devices and use standardized protocols. You can troubleshoot them with off-the-shelf tools (Wireshark…) and even connect third party devices to the same network although with reduced functionality (example: P2P IPsec instead of DMVPN).

All SD-WAN solutions I’ve seen so far (apart from Cisco’s IWAN… but let’s not start the discussion whether that one counts or not) use undocumented proprietary protocols, making it impossible to use standard troubleshooting tools, or establish WAN/VPN-side connectivity with third-party devices.

If you decide to migrate from Cisco to Fortinet (as an example), you could start deploying Fortinet at remote sites and use P2P IPsec tunnels with your central Cisco router until the traffic increases to the point where it makes sense to deploy a hub device from the same vendor. If you want to change your SD-WAN vendor, the only choice you have today is to build a parallel network.

Please read our Blog Commenting Policy before writing a comment.

1 comment:

  1. I dont understand why it such a bad thing, networking is all about connectivity, who cares which vendor you choose to get the packet from A to B, as long as you make use of proven protocols and read about the best practices with those protocols; BGP, MPLS, IPSEC, STATIC, you can troubleshoot it and make use of different vendors. Just dont overcomplicated your network with application based loadbalancing and all those shenanigans. Keep it simple!! I like Juniper, Fortinet, Cisco, (insert vendor) and havent had any real problems with any of them, because i think you should keep networks clean and simple. If you want to use Route Reflectors and confederations inside a network of 10 backbone routers and also believe that you should run nuage or viptela at the edges of your network because you believe this is the right way to segment and automate your network... go ahead, but i think your missing some wires.


Constructive courteous comments are most welcome. Anonymous trolling will be removed with prejudice.