In a recent Packet Pushers Heavy Networking episode, Ethan and Greg discussed how difficult SD-WAN is, and why you shouldn’t outsource your SD-WAN to a MSP. So, how difficult is really SD-WAN?

Now, this is of course going to depend on your organization’s level of skill, as well as what vendor you go with, but there are still some conclusions that we can come to.

Most of the SD-WAN solutions are operated by cloud-hosted SDN controllers, where the vendor has setup the virtual machines running the software for you. This greatly simplifies a lot of things that have been painful in the past. From a Cisco perspective, this is some of the pain that has been removed from you:

  • Controllers – Controllers are installed for you and backed up by Cisco
  • Software – Software is managed centrally, don’t need to login to each device to update it
  • Traffic engineering – Can modify routing behavior without being an expert in say BGP
  • Certificates – Only devices with a valid certificate can join the overlay, you don’t need your own Public Key Infrastructure (PKI)
  • Pre Shared Keys (PSK) – Keys used for IPSec are rotated automatically without manual intervention

This means that it’s fairly simple to get started with SD-WAN. That unfortunately means that many organizations might go “SD-WAN is simple, let’s just get started”. This can lead to a suboptimal design where a lot of the technical debt gets inherited into the new design. Not a place you want to be in. Being an expert in SD-WAN, and a Network Architect, let me explain why you should get someone with expertise involved in your project:

Business outcomes – A design should always be driven by delivering business outcomes. You may or may not have someone with the competence, and time, to front C-level people and stake holders to analyze where the business is going, and then translating that back to technology. Is the company going through a digital transformation? What are the cloud initiatives? Is the company growing organically or by acquisitions? Are there initiatives internally to improve user experience? Being an Architect is very different from being an Engineer. You may need some assistance in guiding your journey forward.

Design and guidance – How many routers should we have at each site? How many transports? Do we need MPLS or only internet? What are others doing? How do we connect to the cloud? Where do we put our security perimeter? How do we protect clients when every site has an internet transport? How do we do load sharing? How many VPNs do we need? How do we connect to the LAN? Using a routing protocol or a First Hop Routing Protocol (FHRP)? Even with SD-WAN, there are still a lot of design discussions to be had, and choices to be made. Unless you know the solution you are choosing, it’s likely you will neglect important factors or make choices based on the wrong information. Someone with experience should be involved in the design process to limit the amount of poor choices made in the design phase.

Real world experience – When reading the marketing, everything looks simple, just send a router to site, run ZTP and be done with it. What is required to run ZTP though? There are things that you need to be aware of. There are conditions to be met such as having an internet transport and that the transport needs to have an IP address via DHCP. Trying to get a public IP via DHCP from a SP is no easy task, let me tell you… Imagine having planned for a implementation, sending out routers to all branches, which could be thousands, only to realize that your design does not support ZTP. A person with experience will warn you in time. This person will also know what works, doesn’t work, what bugs to avoid, and what the best software to run is.

Best practices – How low should you go with those timers for convergence? What’s the best way of reaching your devices over their management IP? What’s the best way of designing your policies? Some of this may vary but much of it looks the same for each organization. There are timers that work well depending on use case and you can save a lot of time if you go straight for the “best practices” instead of trying to find these values yourself.

Getting rid of technical debt – When designing a new solution, what we often call greenfield, you have a chance of getting rid of some technical debt. This is often a “one moment in time” thing where if you miss the opportunity, it’s gone. The efficiency of your SD-WAN design, is dependent on how many “one-offs” and snow flake site types you have. A good Architect can help you get rid of some of that technical debt, so that you minimize the number of different site types, and the number of creative workarounds out there. This will improve both workflow and the operational efficiency.

Now, you may just think I’m telling you all this because I’m working for a systems integrator, and that’s perfectly fine. I am just highlighting that while running SD-WAN is a lot easier than a traditional WAN, say based on DMVPN or something else, there are still a lot of considerations, and either you have to walk into the mines yourself, or you get help avoiding them, it’s as simple as that.

Ethan and Greg’s discussion was more around the operational aspect of SD-WAN though. So how difficult is it to operate SD-WAN?

Not very, when things are working… Which is the case for most infrastructure that is working as intended. When things are working fine, you can get away with someone that is say CCNA-level in their knowledge. What you need more expertise for is, when doing redesign, adding components to the design, or when performing more advanced troubleshooting. Why is my traffic not going to the preferred DC? Why is my local breakout not working? Why are my apps not being classified properly? I can’t get the tunnel to zScaler to work. My policy is not having effect, and I don’t know why. Why are my routes from the LAN not visible at other sites? It seems I just created a routing loop…

SD-WAN solutions use routing protocols, they use IPSec, they use some form of policies and they use the usual suspects such as Ethernet, ARP, IP, TCP, and UDP. Even with all the abstractions in place, you still need competency in these protocols to understand when something breaks or to be able to do a proper design. In fact, sometimes you even need more knowledge because SD-WAN is all about catering the network to your apps. You can get away with having mostly junior staff, but you also need someone more knowledgeable, either on staff, or as a consultant. Using TAC as your only partner for design and questions, rarely works well, and is not how they are intended to be used.

So, how difficult is SD-WAN?

It depends… mic drop

How Difficult is SD-WAN?
Tagged on:             

One thought on “How Difficult is SD-WAN?

  • November 11, 2019 at 10:42 pm
    Permalink

    Precisely Dan. To my understanding , in-depth knowledge of legacy routing protocols is much needed for SDWAN especially when we need to migrate legacy WAN to SDWAN.
    With minimal knowledge of how organization’s WAN is laid out today in terms of it’s architecture and functionality, and where the business wants to see its WAN tomorrow in terms of scalability, security, cloud infrastructure etc, SDWAN implementation may become more pain than a smoother resolution.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: