SD-WAN Magic: Multiple Bucket of Things
Hi. Max Clark. This is 20 minutes max. I've been on an SD WAN kick lately with a lot of projects, So I'm recording a lot of SD WAN content. Let's do a dive into SD WAN, and let's talk about SD WAN.
Speaker 1:So let's let's back up and go way back in time. And 10 years ago let's just go back 10 years. Let's just go to, like, late 2000. It's a little more than 10 years. I guess, let's go 15 years.
Speaker 1:Late 2000, bandwidth was still very expensive and relatively slow. Right? So late 2000, if you had a 100 meg network circuit in your office, 100 meg Internet circuit, you had a smoking fast Internet circuit. If you had a giggy circuit, you know, oh my goodness, light speed. Now big issue with corporate networking a lot of times is consumption of the network and what is using bandwidth and how do you control what uses bandwidth.
Speaker 1:When your applications and your infrastructure is on premise, you know, 15 years ago, that was you still had a a GigE network in, you know, your office and maybe you had some servers on 10 gig connections, but you had your office was all GigE to the server. And it was low latency because it was in your office. As things started shifting, off prem as we started implementing, you know, hosted hosted PBX's and then, you know, what became unified communications as a service as UCaaS product. Right? So, you know, think of what, RingCentral, 8 by 8, Vonage, Zoom, anything that's Microsoft Teams related infrastructure, Dialpad.
Speaker 1:I'm missing a bunch. Sorry if I didn't call you up by name. It's morning here. You know, and as your servers went off prem and whether that was just like Dropbox or Box, so you went to SharePoint and OneDrive, or you did Google Drive, or, you know, whatever it is. You know, applications went into, you know, AWS or Azure or whatever whatever it is you're using.
Speaker 1:All of a sudden that fancy GigE circuit, those GigE that GigE network, your desktop to your servers, became the fastest thing and your construction became your internet circuit. And now the performance and the speed of the internet circuit became really critical but maybe it was only a 100 meg circuit and maybe you had events where, you know, you had windows update running and Microsoft does a really good job of making these updates go as and use as much bandwidth as humanly possible and suck up all the application. Or maybe you didn't have any sort of filtering or restriction on your office, network connection and, you know, Netflix or YouTube became an issue for you. Or, you know, maybe you're doing large file transfers. You're using a spare because you're a mean entertainment company.
Speaker 1:You're doing big transfers. Well, now you have applications that are latency sensitive or or jitter sensitive or or packet loss sensitive or just network sensitive running. Okay. So your voice applications, your video applications, things along these lines. You know, 15 years ago it's actually a little bit more than 15 years ago.
Speaker 1:So I'm just gonna say 15 years ago. 15 years ago, if you were a service provider in the voice world, you were solving this problem, and we had, the Edgewater Edgemarks came out. This is in in my mind really one of the the big precursors to what we see in the SD WAN market space today. Edgemark was a was a magic device and they branded it as, you know, an Edge SBC. It did a lot of different things.
Speaker 1:You could terminate, you know, a voice traffic to it. But the big thing that it really did was it sat in between the firewall and the ISP connection and it was there for a very important reason and that reason was it could issue TCP resets. Now what what the heck am I talking about? When when you think about your your your network connection and you're thinking about your your internet circuit, you know, like your pathway to the internet. So here's the internet and here's you over here and you've got this pipe in between you.
Speaker 1:When you start downloading stuff from the internet how much you can get how fast you can get it is this this pipe and the, best analogy I can think of up off off hand is like, trying to suck a milkshake through a straw. You can only you can only get so much data through. And as soon as you clog up this side, like, if you like me and you like Oreos in your milkshakes, you know, chunk of Oreo hits the end of that straw. It plugs the straw, and there's nothing you can do on this side, on the office side to deal with it. You've already saturated your capacity in your in your network circuit and there was no way to deal with this.
Speaker 1:Right? So if you were, you could subscribe to a really fancy service with the with the lek and you could get into qs traffic shaping with that lack. And this was usually done on MPLS circuits as part of the reason why MPLS circuits were so much better for people for so long was because the telco could actually set the, QS rules and provide priority to different things, provide variety, of priority to your video and to your voice applications and your critical application and then have, like, this generic data layer underneath of it that, you know, could use whatever was left over. But in order for QS to work properly, you have to have it on both sides. Both sides need to know what's going on.
Speaker 1:Far end of that straw needs to know your circuit's a 100 meg, and the circuit's saturated. So prioritize your voice traffic and tell everything else tough you get what you get. Tell our children you get what you get, and you don't throw a fit. So what Edgemark did, because it was on this end of the straw, as traffic was coming into it, it obviously couldn't control what was happening over here. But what it could control was the rate at which traffic was was accepted.
Speaker 1:And it did this by when it detected a saturation of the network, it would issue a TCP reset and it would slow down that transfer. Fun little quirk of TCP, it would see this as a, you know, packet loss, and it would start doing retransmits. And your your window sizes would reset, and it would slow that transfer down. And edge markets in it could could provide this, like, artificial rate limiting for you. And the behavior on what you saw or you experienced was you might have a period of, like, you know, like, your voice would get a little wonky and then this thing would kick in and it would, you know, wreak havoc with everything else, but your voice traffic would improve.
Speaker 1:And, you know, your your overall experience was much better. And so if you were like us and you were doing any sort of host hosted VoIP, hosted PBX, you know, SIP trunking PBR, you know, PRI replacement, whatever it was, you know, these these were all, this was a phenomenal client to send out into the world because it solved a lot of issues for you before those issues popped up. You know, around that same time, what was else was really popular? Fat pipe. Fat pipe was really popular.
Speaker 1:And fat pipe was and still actually is a way of doing circuit aggregation. So if you had a cable modem, plus a DSL line plus a second cable modem plus something else, you could take and you could effectively slam all those together and aggregate all your bandwidth together and and have better Internet performance. And this is not like a new technique. I mean, we were doing this, you know, the late nineties, early 2000 with modem bonding, you know, Microsoft proxy server, you know, 1 dot o. You could take and have a, you know, a before you as robotics modems plugged into the back of a computer and and have it and the and the trick was we'd use, like, EarthLink.
Speaker 1:We'd use, like, EarthLink in an ISDN account because they couldn't tell you that you were dialing in multiple times because that's what ISDN was. It was effectively a digital digital modem dial in with 2 circuits at the same time. So they would remove so they would remove any sort of rate limiting that would prevent you from dialing in more than once. So we take, you know, 4 modems back of server, get an ISDN account from from EarthLink, and and just dial in. And all of a sudden, you went from, like you know, it was just 56 k to a 128 k to, you know, 256 k.
Speaker 1:It was, like, smoking fast. I mean, late nineties, 256 k of dial up was like a rocket ship. And then DSL came out, and then we started transitioning. Of course, that was because t ones and frame relay were just so just like expensive still. And then they started getting cheaper, and then there was a wholesale migration of t 1 and yadayada yada.
Speaker 1:When we look at SD WAN now, the easiest way I can express what SD WAN is is it's multiple different buckets of things. Right? So it is, you know, a cloud based orchestration and automation tool to do configuration. Right? So you can have a Meraki and you're going to the Meraki cloud in order to configure your endpoint.
Speaker 1:So when you plug a switch into your network, it knows to phone home to Meraki and say this is who I am. What should I do? And then, Meraki will push that configuration down to the switch and the switch will configure itself and and it's it's, you know, it's magic. Right? Like, if if you've never consoled into a switch and had to configure it from scratch, then maintain its config and then hopefully you didn't lose your config, if you weren't using something like Rancid, you know, it's wonderful.
Speaker 1:RoCE is wonderful for this stuff. You know, point and click VPN between MX firewalls. Again, magic. You know, if you've if you've configured VPNs from hand on a CLI versus if you just go and click click click and turn the VPN on. So you've got you've got configuration based v p SD WAN.
Speaker 1:You've got, got this Internet optimization. Right? So you've got this continuation of what this idea of Edgemark was or fat pipe, where there's, you know, special, SD WAN service providers that give you an appliance with failover and the ability to aggregate. So bond multiple circuits together. In in most cases, we only really see people bonding, you know, 2 circuits.
Speaker 1:We're we're using it for failover and survivability. So, fiber circuit with cable cable circuit, cable circuit plus wireless circuit, fiber plus wireless. Just the the the big important thing is different carriers, different medium of access into the building, and also inbound, you know, gateway, you know, foreign gateway with inbound survivability of IP addresses. And, you know, and there's some negatives with this version of SD WAN. The big one is your MTU sizes.
Speaker 1:When you're running VPNs inside of VPNs at some point, it may or may not be a problem for you, may or may not be an issue for your application. Wonderful wonderful option for, you know, SD WAN. Talk a lot about, like, this MPLS replacement SD WAN. You know, if you're if you're really looking at, you know, your primary application is providing, connectivity between branch locations and and HQ or branch locations and data centers. So really just like hub and spoke kind of infrastructure, you know, central locations with remote locations, you know, excellent options in the SD WAN space is probably the most common SD WAN we see in the market right now is is serving that use case.
Speaker 1:You know, these things have been in an extended and augmented with with, you know, techniques and approach and approaches to deal with SaaS applications or hosted cloud cloud hosted applications. So UCaaS of voice being the big one and, of course, interactive video. So Teams and Zoom and and whatnot being the other one. And my last bucket of SD WAN that I talk about a lot is, you know, really more like, latency and performance orientated cross continent, you know, low late, you know, low, low speed links, high latency applications. If you've ever dealt with a, a gas station in the middle of nowhere on the 10 freeway in the United States, It's got a, you know, old school satellite uplink that needs to have a point of sale terminal with some sort of ear picking on in order to process credit cards to drive transactions.
Speaker 1:It's doing just boatloads of money, you know, a day because that's the only gas station. And as far as the eye can see in each directions, Well, you know, there's not a lot of options in the middle of nowhere. You know, a gas station's doing great business because it's the only option in the middle of nowhere. It also means that there's no network options in the middle of nowhere. You know, SpaceX and Starlink is starting to make changes here but it's still you're dealing with applications that are not gonna have the same amount of performance as you would in other scenarios.
Speaker 1:Evaluating SD WAN, you know, I've I've I've kinda given, some generalized buckets here pretty quickly. The amazing thing about this is if you're in a selection and purchase process we haven't even talked about s Sassy. I mean, it was ranting about that in another recording here recently. But, if you know nothing about SD WAN, you just think about it in those kind of groupings. You're gonna know pretty quickly what problem that you're trying to solve.
Speaker 1:What is the issue that your business has? What do you use the issue that you actually have? And the sooner you actually appreciate or accept that, the easier it is for you to to focus on it. Right? Like, why send why do an RFP with, you know, a dozen vendors when, you know, 9 of those vendors don't actually do what you need them to do?
Speaker 1:Or they can claim that they do what they need you to do, but, like, they actually don't do it or they don't do it well or it's another core competency. Right? So there's no point. Right? Like, this is the whole thing.
Speaker 1:RFPs are garbage in most cases because they're just playing out, like, spray and pray out to everybody. And and guess what? You know, you're not even actually evaluating whether or not that vendor is gonna do what you need before you send them this document to say, do you do what I need you to do? Right? Don't waste your time.
Speaker 1:Identify what it is that you want and what kind of network infrastructure and architecture that you actually want. Where are you today and where are you trying to go? What problem are you trying to solve? You know, when you think about it 3 years, do you wanna still have on premise firewalls? Do you not how does your SD WAN architecture actually apply into that?
Speaker 1:Are you gonna maintain data centers? Are you not? What applications do you have? Are you are you going from an on premise voice to, you know, a hosted voice or to a UCaaS environment? How does that impact things?
Speaker 1:Are you gonna maintain it on, you know, do you have, critical applications on-site that are never gonna leave site? You know, like, all these things kinda swirl into this this little, like, pot. Right? You stir the pot and say, okay. Great.
Speaker 1:This is what we need. You know, that's that's all that's all, you know, super critical. You know, word of word of warning because this has come up a bunch. There's no SD WAN on the market that solves the issue of data center and survivability. I mean, SD WAN is a great, like, just magic button to solve all your remote site edge issues, you know, pick your category of edge issues and solve it.
Speaker 1:But when you actually start talking about getting into a data center application of, you know, I wanna have, you know, QS inbound on my transit links into my data center, just buy bigger transit links. You know, if you're in a data center, it's no you know, it's easy to go get 10 giga links. Right? Go get a bunch of them. But you're gonna have to run BGP or you're gonna have to have a, a really solid really solid network, provider, you know, transit provider that can give you redundant circuits and provide that redundancy for you ingress and inbound.
Speaker 1:Now there's trade offs running BGP and having different carriers and different AS's that you're connected with versus a single AS with a single carrier. And, seriously, I say I'm more than happy to nerd out about this all day long on a whiteboard. And, you know, there's nothing I like more than, you know, designing data center network applications because that's just the way my brain works. And, you know, everybody has their hobby, things they do for fun. That's what I do for fun.
Speaker 1:Just gonna put it out there. Anyways, you know, SD WAN is magic, and it, it solves real problems. And if you're on the customer end or if you're on the service provider end, do you want SD WAN in place? And if you're, you know, I mean, crazy. If you're if you're turning over IT staff or if you're an executive that's just taken on, you know, more responsibilities or slotted in and replaced an executive that has purview over infrastructure and you're looking down your line items on your on your budget and you see these things that are called SD WAN.
Speaker 1:That thing is there to make your life better. And the reason why your life is good right now and your IT team's life is good is because it's there. Don't get rid of it. Big secret. I'm gonna tell you I mean free information here.
Speaker 1:SD WAN is good. Keep it. Don't get rid of it because what happens is if you get rid of it all these issues you didn't realize that were there because your SD WAN is hiding it from you because it's doing its job. It's gonna bubble up to the surface, and then all of a sudden, you're gonna have to start talking about, like, why is our why is our voice terrible? Why can't we get to our application?
Speaker 1:Why is our productivity down? Why did this web why did why did this location go down? Why are we having outages? Well, the outages came about because you got rid of this magic box, That magic box is there for a reason, so keep it. So SD WAN good.
Speaker 1:No SD WAN bad. Pick the right SD WAN. Don't waste time, you know, circling around with people that can't do what you need them to do. I'm Max Clark, and that was 20 minutes max.
