SDWAN for Dummies
SD-WAN defined.
If SD-WAN had to be defined in one word, it would be “efficiency”. So, that begs the question… are current networks inefficient?
You betcha.
There has long been a need for the WAN. Many businesses are distributed geographically and have the need to share resources across these locations. In fact, this is more common than not.
Unfortunately, at some point, the applications and data that we have been sharing across these WANs outgrew our ability to manipulate it efficiently across the current technologies we have transporting it thus making our networks inefficient.
If you want to learn briefly about some of the basics of legacy WAN technologies, check out my other post here.
This post aims to demystify SD-WAN and get to the roots of why it’s so revolutionary. You might find yourself at the end of this post wondering why this took so long to emerge in the marketplace. And you would be right in wondering that. These concepts are very basic. Yet the fly in the face of traditional WAN architecture. This makes the industry shift towards SD-WAN a generational moment.
Let’s start with an example of a traditional WAN.
In this example you can see we have two different branch offices connected with a traditional VPN. Nothing too special at all. Does it get the job done? Absolutely. And this is something I want to be clear about. It’s not that traditional WANs don’t get the job done. They do, and they do it well it most cases.
They could just be so much better.
Now if we look at the below image of how to configure the traffic to traverse the VPN we can then start to understand the simplicity of what we are dealing with here.
The picture illustrates two basic options. We have one Internet connection. When traffic enters the router destined for a remote network, a decision will be made that says whether you are to be sent over the VPN or not.
That’s it.
No fluff here.
Just a simple A or B decision. Since a router uses IP addresses to make forwarding decisions, you either fall into the first ‘bucket’ of IP addresses or the second. Once that simple decision is made, you are off on your merry way.
Like I pointed out before, there is nothing wrong with this at all. In fact, most WAN’s today operate on some version of this simplistic decision-making tree.
It could just be a bazillion times more efficient. (that’s a rough estimate)
Now, this wouldn’t be completely fair to the router if we said that that’s the only way to configure the decision-making logic. There are things you can augment the efficiency of this A/B decision. Such as, IP-SLA or QoS functions to name a few. What these can do is add a level of complexity that will enhance your traffic manipulation.
If you add another element like QoS to the mix, you can make even more decisions. QoS will allow you to make sure all of the different traffic you are sending over the VPN is treated differently.
This is important since not all traffic is created equally – I.e. Voice traffic being more crucial to your business then let’s say Netflix (sorry Netflix) traffic.
One thing to add here is that the decision of what traffic is important or not is completely left up to the network administrator. Additionally, the “what’s more important” decision the router makes is typically made after the original A/B decision we made earlier. Therefore, this traffic has already been determined to be destined for the VPN or not.
Let’s use a picture to explain further.
Here you can see how the ‘what’s more important’ logic effects the bandwidth of the VPN using a pipe as an example. We start with 100MB of bandwidth but we have to make sure that the phone traffic we are sending over the VPN prioritized so we carved out 90MB to make sure that if someone is on the phone there will be enough bandwidth so that we don’t lose call quality. Without getting into too many details here, the reason we are picking on VOIP is due to its sensitivity. Let’s just say it’s a bit needy.
This only leaves us with about 10MB to share for all of our other traffic. Doesn’t matter what it is, it’s only getting 10MB… TO SHARE!
The example is a bit exaggerated but I did that to make the point crystal clear.
OK - Quick Check-in
Up until this point we have created an A/B decision based off IP and added QoS functionality to our WAN. This takes a lot of knowledge and configuring to accomplish so while it may have sounded simple, it certainly is not.
Since that’s the secret sauce to creating a traditional wan let’s enter the future, shall we?
What if I wanted to make YouTube my most important traffic type because my company watches training videos using that platform? I mean let’s be serious here for a second… there’s a wealth of information on the aaron engineered YouTube channel. Why wouldn’t I want to share that with my team??
Well first off, try again. YouTube isn’t a traffic type necessarily, it’s an application. If you tried to prioritize YouTube, you might inadvertently prioritize all similar services such as; Hulu, Vimeo, or Disney+ to name a few. Why is that? All of the traffic types are the same! It’s streaming video, duh!
But wait a minute, that’s not what we want here. We want just YouTube!
Remember, routers can only make decisions based on some very basic criteria such as the IP address in our A/B decision example. Or the transport protocol it uses like TCP, UDP, or RTP to name a few.
Wait a second, doesn’t YouTube have an IP address? Can’t we just use that?
Well sure, but that could open up more than a can of worms. What if the IP changes? What if there are other things being hosted on that IP address, are those included too? - There is just not enough control here.
Inefficient.
Right about know the sun is poking through the clouds with a big beam of light and the bottom of that beam of light is a Software Defined Router.
While all SD-WAN vendors vary in their product offerings, the basic idea is the same.
Instead of manipulating traffic decisions based on a few criteria such as IP or transport protocol, let me control my traffic based off of all the applications my business uses.
Oh, on top of that, why don’t you go ahead and set up all those site-to-site VPN’s for me.
Also, make sure you give me a nice graphical user interface so I can see everything that is happening in my network then give me easy-to-use knobs and switches to more easily change configurations and make decisions based off of the cool stuff you are showing me.
SDWAN!
There are two major concepts that any SD-WAN vendor has built their foundation on.
Insights and control. They are married closely together like peanut butter and jelly.
Insights and Control
Insights give us visibility into everything that is happening in our network. You see, the trick is here; the more I can see, the more I can use. Let me explain further. If I can see everything that is happening in my network, I should be able to control(manipulate) what’s happening too. At least, that’s the idea. So, if I can get more granular details about what is happening in my network, I can make more granular traffic forwarding decisions. Make sense? Good.
OK – let’s take that a step further.
Using our previous diagram, let’s illustrate what having more visibility into applications looks like when traffic tries to leave our network.
Oh boy this is already like a bazillion times better!
Before, we were only able to pick which direction to go based on IP or even what protocol type – at best. Now, we see that because of the insights we are able to able to obtain we have SOOO many more options.
RAD.
User Interaction
One of the most often overlooked ‘nice to haves’ about SDWAN is user-friendlyness. Bye bye CLI! It makes configuration so much easier. In fact, it makes it sort of fun! Maybe I’m weird, I dunno.
Again, all of the vendors may vary in the look and feel of their GUI. The point is very much the same though because you will get a lot of nice graphs and automation at the touch of your fingertips.
The configuration of all this is no longer done via CLI (command line interface) like days past. The CLI is exactly how it was 40 years ago. You get a better graphical experience from playing one of those tiger handheld games from the 80’s.
A brief comparison of the differences between the look and feel of traditional WANs vs. SDWAN.
The first picture is of a classic command line interface(CLI) - The second is an SDWAN graphical user interface(GUI)
This GUI is a picture of the Viptela user interface. Viptela is Cisco’s SDWAN offering. There are quite a few different vendors out there so of course there are many different options but this should give you an idea of what is possible in a GUI.
This is QUITE the difference wouldn’t you say? In fact, if you just had an idea of what you were trying to accomplish – I bet you could figure out how to do it. Using the YouTube example from earlier, I have no doubt that even someone with the most basic of networking knowledge could go find the button that makes YouTube choose the VPN connection and then prioritize it.
While these aren’t all of the characteristics of traditional WANs and software defined WANs we did highlight some of the most important differences.
Key takeaways so that you can sound like an ultraprofessional in your next SDWAN conversation:
Insights and Control – or peanut butter and jelly. Whichever you prefer.
Once we can see what is in our network, we can control it. Getting more granular insights means we can make more granular traffic steering choices.
GUI > CLI
The ‘SD’ in SDWAN means that we are able to make decisions based on the applications(software) we see being used in our network. Additionally, you get some pretty nice software to look at while you do it.
Thanks for reading! Be sure to share with everyone you know and just go ahead and pretend you wrote this so you can impress all your friends an colleagues!