Cloud Therapy: Episode 001 – What is SD-WAN? [Podcast]

May 17, 2016 Aerocom

What is SD-WAN and what are the benefits? How does it compare to MPLS and other business WAN services? We bring an extremely experienced, long-time provider engineer, David Kline from TPx (formerly TelePacific) Communications, to answer all of these questions for you (IT Professionals). You might be shocked at some of the value-add benefits SD-WAN can bring to the table… especially for your company’s back-up Internet access!?

To listen to more episodes, find and subscribe on iTunes and Stitcher!

Click the button to have an AeroCom expert help you shop all major SD-WAN providers and pick your company’s best 3 options.

 

Read below for a full transcript:

  Mike: Hey, IT Nation. Welcome to Cloud Therapy with AeroComInc.com where you learn about the latest cloud and telecom technology that is going to take your career to the next level.

I’m your host, Mike Smith. Let’s do it.

So, your company has multiple locations, you currently have an MPLS wide area network in place, and you’re starting to hear about this SD-WAN thing. Now, you might have heard about SD-WAN before and you’re ho-humming it a little bit, but you’re still thinking, “Will this be less expensive than MPLS?” and “Does it do the same thing as the network we have in place?” If this describes you, you’ll love our guest today.

His name is David Kline or “DK,” as he’s called by most of us, and he’s a long-time sales engineer from TelePacific Communications, which is a great telecom and cloud service provider who has just launched an SD-WAN service as one of their product offerings. David’s going to explain SD-WAN to me in this interview, which means he’s going to explain it to you as well. He’s also going to let us know how it compares to other WAN technologies like MPLS, point-to-point, and IPSEC VPN.

Now, please forgive me if I sound a little green during this interview. Full disclosure, I’m not scared to admit it, I knew nothing about what SD-WAN was before we did this interview. I’ve been in telecom a long time, been doing MPLS a long time, but I have to remind you guys, I’m not an IT professional myself. I’m a sales person by trade, so this SD-WAN thing was completely new to me, and I knew who to call to ask about it – David. He’s a great guy.

I’ve actually known David for many years. Our company AeroComInc.com has sold a lot of TelePacific services to businesses and David is one of our favorite sales engineers to work with. As you’ll hear soon, he’s obviously a knowledgeable engineer, but what’s cool is he’s got a very laid-back, likeable, easy to understand personality, which makes him a great podcast interview and I thought he’d be the perfect person to explain SD-WAN to myself and our audience.

Before we jump in to the interview though, I just wanted to let you know, I have a free, nice giveaway for you. Based on my conversation with David, I created a cool spreadsheet that compares SD-WAN capabilities side by side with all of the other wide area network technologies that companies can use. It’s a free gift to our listeners and all you have to do to get it is text the word “WANGUIDE” to the number 44-222. Again, just text the word “WANGUIDE” to the number 44-222 and get your free copy of this cool WAN comparison chart.

So, let’s get do it. Here’s my interview with DK regarding SD-WAN service:

Okay. Well, thanks for joining us, DK! Welcome to the program.

David: You’re very welcome. Thanks for having me, Mike. I appreciate it.

Mike: No problem. So, quickly tell us a little bit about yourself both personally and professionally.

David: So, Southern California boy. I was born and raised here. I went to high school at Cypress High, attended California Lutheran College because I wanted to play football, which is weird for a guy who’s got like no size, strength, speed, talent, so I had to go to a really small college so I could play football.

Then, I just, kind of, fell into telecommunications through my uncle, my dad’s brother. He was an old AT&T Central Office tech from way back when. He installed a lot of the [CoS 00:05:02] across the Midwest, and started one of the early interconnect companies. I’ve gone to work for him and then my dad and I started our own, kind of, family business. Did that for about twelve years where we would go to these big apartment properties, and we dropped phone systems and cable T.V. headends in there, and became the phone and cable company for all the residents in these apartments.

We decided, then, to make a change. I’ve been with the carrier side of things now for longer than I’d care to admit and, most recently, with a carrier called TelePacific. I’ve been with TelePacific now as a pre-sales engineer for about twelve and a half years.

Mike: That’s awesome. So, you’ve been going on a lot of customer appointments and talking tech with a lot of IT folks, huh?

David: Yeah. You know, it’s been really exciting because the applications that we find ourselves getting in to seem like they continue to grow in complexity. There are lot of our customers and our partners that are moving applications in to the cloud. So, we get to look at what all that looks like and really, kind of, changing the way we’re thinking about network design. Yeah, it’s just been great.

Mike: That’s awesome. And then, you’re married with some kids, right?

David: Yeah. So, I’ve got three kids. The youngest one is now a junior in high school and we’ve been really fortunate. He’s actually special needs, but the high school has been amazing to him. They let him… He plays the cymbals in a marching band, he’s in the choir, he’s doing varsity cheer. It’s just been awesome.

Mike: Oh, that’s cool.

David: Thanks.

Mike: That’s awesome. Well, cool. It’s awesome getting to know a little bit about you there. I’ve worked with you, obviously, for a while, but I didn’t know the whole football thing. That’s funny. I think we share that in common. I played college football and it didn’t work out for me, so we’re in the same boat.

Alright, so, we brought you on the show today to talk about SD-WAN, so let’s dive in to it. Full disclosure here, I don’t know that much about SD-WAN at all. It’s a big buzz word right now that we’re hearing in the wide area network services arena with some different providers and there are some buzz going on about it in the IT community, but this will be fun for me because I don’t know much about it. So, what our listeners are going to get are some real stupid questions from me and, hopefully, they won’t be embarrassed having to ask the same one. I’m sure there are some people out there who probably got the same questions, but now they don’t have to ask them because they’re going to hear me ask them first.

So, let’s just start out with you telling us what is SD-WAN?

David: So, I like to say that SD-WAN could be considered SDN which is “Software-Defined Networking,” or SD-WAN which is “Software-Defined Wide Area Networking.” SDN is to data networking what virtualization is to computing. It’s really this idea of abstracting software from hardware and, kind of, making the separation between the control planes, which is how you control how packets flow, and the data planes, which are the actual moving and transporting of the packets themselves. Does that make any sense?

Mike: A little bit. From me, coming from a little bit more of the sales, non-technical perspective, can you give us a little bit of understanding of just how is it different from the networks that we know of today like MPLS, or point-to-point, or IPsec VPN? What are the real big differences between SD-WAN and those technologies?

David: That’s a great question. The big difference is that with current wide area networking technologies, typically, what you end up with is you end up with a router at the customer prem.

Mike: Right.

David: That router has got a bunch of intelligence built in to it and it can end up being pretty complex in terms of what you need to do, in terms of configuring and programming what we call that “customer edge router” to make it function in a way that is beneficial to the bigger wide area network as a whole. Then, with SDN or SD-WAN, the difference is what we’re doing is we’re kind of abstracting or pulling that intelligence off of the customer edge equipment and putting it in to the cloud, if you will. Then, the device that gets put on prem really is more, kind of, a commodity type of device, a dumb device that gets its intelligence and its information from that software that’s centrally located in the cloud. It centralizes management and control in to this cloud environment as opposed to having all that stuff distributed across all these different locations and all these different customer edge routers.

Mike: Oh, okay. There are some light bulbs going off in my mind there. That makes a lot of sense. So, instead of, like, with an MPLS network how you have routers at each site with these routing tables all programmed within them where you have several points of complications, several points of failure – all that’s located in the SD-WAN cloud and the devices on site are fairly simple.

David: Exactly. The nice thing about it too is that, the devices that are on site, they can be built based on standardized hardware and software. So, the cost of that equipment can come down dramatically because you do not have to load it up with all these proprietary technologies that are needed to appropriately get packets routed across the wide area network.

Mike: Okay, that makes sense. So, then, obviously, there are some conclusions I could draw on my own about possible benefits, but why don’t you expand on that? What are the benefits, really, to SD-WAN over these other technologies?

David: That’s a great question. The benefits start with… You end up with the ability to automate the provisioning of services through what’s called the “orchestrator” software that resides in the cloud.

In a typical MPLS network, for example, instead of some IP administrator having to log in to every one of those customer edge routers and add all the routing tables, the routing protocols, all that stuff to make that router function appropriately, you build that kind of template in to the orchestrator software in the cloud and then it pushes that information out to the SD-WAN customer edge devices or appliances as you call them. Those appliances, they could be like a stand-alone box or it could even be a software that’s loaded in to some like you know, machine that could be run virtualized – it could take that shape as well. But, I think the majority of what you’re probably going to see would be the appliance-based where there’s a box that the wide area network circuits are plugged in to.

So, that’s number one. You provision it once and it’s through a GUI interface in to the orchestrator software. You setup how you want the network to run and then that gets replicated out across the entire network, so you get this automated provisioning.

Mike: Okay. Now, is it priced per location, typically? Because I’m just thinking in terms of the overall theory of how this is working, but since it’s all on one cloud, do you pay, like, on a monthly basis? You don’t have to give me the exact price or anything, but does the customer pay per location or is it just they pay for one SD-WAN cloud and they could add a bunch of locations? How does that work?

David: Yeah, that’s a great question. So, because the technology is still relatively new, I think there are still different organizations trying to figure out different ways to implement this.

At TelePacific right now, I know of two customers that have implemented their own iteration of an SD-WAN network. My understanding of how that works from a cost model for them is that they pay for licensing for the orchestrator software and then they pay for the individual appliances that go out to the individual sites. If I’m not mistaken, I believe that’s a one-time expense. You know, I’m not a 100% on that, but I think that’s how that worked.

The other thing that you’re going to start to see is, you’re going to see the carriers implementing this technology within their networks. For an example, the way with TelePacific, I think, the pricing model that you’ll see from a carrier like TelePacific will be that we’re going to use this as, sort of, an add-on to your traditional access or transport, and that would be whether it’s an MPLS circuit that’s provided by TelePacific or maybe it’s a customer-provided broadband circuit, for an example. Then, on top of that, I think, TelePacific is going to charge a monthly recurring charge for the appliance as well as for, sort of, the overall management of the network, and that would be on a site-by-site basis without any centralized charge for the orchestrator software and all that stuff.

Mike: Okay. That makes sense. Let me just make sure I’m understanding it correctly. So, the customer’s end-point is connecting to the SD-WAN network through the public internet. They’re using a public internet connection where the device is finding the SD-WAN network on the public internet. So, maybe, they’re connecting to like the nearest POP that’s close. The closest POP to that location is where it jumps on to the provider’s network. Is that how it works?

David: Yeah. So, that’s the current TelePacific model. We’re actually looking at a couple of different configs, but, yeah, the idea is that the traffic actually gets tunneled across these third-party internet circuits in to one of the… So, we talked about, kind of, the orchestrator software and the second piece of that is the gateway.

So, then, the traffic gets tunneled to one of the gateways and the appliances at the customer prem, they would always be aware of more than one geographically diverse gateway that they’ll have access to. The orchestrator software will be constantly reading the connectivity between those multiple geo-diverse gateways and the appliance on prem, so it’s always going to be connected to the one that’s providing the least latency and the least packet lost, and giving the best, overall, performance. Yeah, so it will tunnel the traffic to that gateway and then, from there, the carrier, like TelePacific, will then get that traffic moved to wherever it needs to go. If it needs to go back out through our internet peering, for example, we can do that. It needs to get directed to another customer location across the SD-WAN network, it’ll do that. So, yeah, that’s, kind of, one way it’s done.

The other way it’s done is you could still use, in addition to like a broadband internet circuit, you can plug in an MPLS circuit into the box as well. You can do multiple carriers even because the idea is that… I’ve kind of heard SD-WAN referred to as, you know, “MPLS-killer” and, to a certain extent, there may be some of that. But, the way I see it going forward, Mike, is I see it as customers are probably still going to want, like, a traditional carrier circuit and probably, at least for the foreseeable future, say they’ve got VoIP, traffic that’s going to be running in [to our company 00:18:27] between their offices and maybe they’ve got IP video conferencing going on, well, they may still want an MPLS circuit for that, and they may want a cheap broadband circuit for additional capacity/redundancy. What the SD-WAN would be able to do is, it’ll go, “Okay, for the VoIP application, yeah, I’m going to send that across the MPLS circuit, unless there’s a problem with that circuit and then I’ll send that across the broadband circuit.”

The cool thing with SD-WAN is it’s constantly monitoring the health of all the circuits that are plugged in to it regardless of circuit type. It could even be like a 4G LTE data circuit that could also be plugged in to the appliance on prem. So, the software is constantly monitoring those circuits for available bandwidth, how much capacity is left, latency, packet loss, and then it’s checking it’s algorithms to say, “Okay, I know that VoIP needs to be set priority number one across whatever link has the least latency.

So, it’s constantly looking at those things and not doing… What’s really, really exciting about it is it’s not looking at the applications anymore at the packet layer where it has to go in to the packet and look for a code that tells it what type of application it is. It’s seeing the traffic at the application layer, so it knows intuitively that the VoIP is VoIP, and that the video is video, and that the RDP is, you know, remote desktop. It knows all that stuff by looking at the application as opposed to the packet. So, you get all these amazing performance benefits, which is why some are calling it the MPLS-killer. You’ll go “Why would you need MPLS anymore?” because you’ve got all these tremendous, sort of, intelligence built in to it that can guarantee performance.

But, at some point still, even though the software has that capability to constantly monitor performance, you’re going to need a really reliable circuit if you’ve got latency-sensitive apps that you want to make sure are performing very well all the time. I don’t see businesses that really need voice quality, good video quality going with just strictly low-end broadband type of circuits because even though you’ve got options, if they’re all having latency, or loss, or something like that, then that’s something that even SD-WAN won’t be able to fix.

Mike: Right, because what I was thinking is that, still, the link or the public internet from the customer’s prem for that… For on-site to get to the SD-WAN network POP, that’s still the public internet, right? So, there’s no guarantee of, like, low-latency levels, low packet loss, low jitter on that leg, right? Once it joins the SD-WAN network, then, yeah, it’s probably fine across that, but those links to reach there, that’s still a little bit unstable, correct?

David: Absolutely correct. Yeah, you hit the nail on the head. That’s exactly right.

Mike: Okay. So, that makes sense. It’s like, maybe, if a company really wanted to risk it a little bit, it might be a good idea if they want to go low-end bandwidth, or two separate types of low-cost/bandwidth, you know, a low-cost high-balance solution in place if they wanted to go strictly SD-WAN.

David: Yup.

Mike: Maybe if they have, like, a fiber circuit and then like a high-speed cable connection, or something along those lines, where they could have two diverse connections connect in to the SD-WAN network. That might give them a little bit better chance to always have a decent connection for VoIP or video, but if they’re going from one fiber connection, they might be better off for voice or video to still stick with MPLS for that type of traffic?

David: Yeah, exactly.

Mike: Okay. That makes sense. What might be some of the drawbacks of SD-WAN? Obviously, that’s one of them – if you have voice or video. Are there any other drawbacks with SD-WAN like that still might not be a great fit if you have this type of scenario?

David: You know, I can’t really think of any drawbacks to the technology, none that I have seen as of yet. Again, it’s still early on, but one of the things that we run in to sometimes that customers are concerned about is point of failure, right? You might think, well, SD-WAN with the customer-premise appliance, then now that becomes a single point of failure and that could be a drawback. There are a lot of different manufacturers of this technology, and, more and more, they seem to be getting in to the fray every day. One thing that I know most about, we’re currently testing with. They have the ability to deploy those customer-premise appliances in a high-availability configuration, so even that becomes, kind of, a non-issue. I’m sure at some point we may figure out some type of a drawback, but, at this point, I’m not really seeing any drawback whatsoever associated with this technology.

Mike: Cool. What about comparing it to an IPSEC VPN connection? Because I know there are some businesses out there in the last few years that have gone away from MPLS now that fiber is more readily available and these higher bandwidth connections are more readily available. I’ve heard some rumors out there where they’re saying, “Hey, MPLS is dead. We’re just going super high bandwidth at all of our sites and going IPSEC VPN.” There’s a, kind of, going backwards in technology on that wide area network connection just because the bandwidth is so big now. I’m just, kind of, thinking, as you’re describing SD-WAN, I was thinking this might be a good solution for those types of customers. But, from your perspective, from a sales engineer perspective, do you see that as, kind of, a step above for those customers who are going in between an MPLS and an IPSEC VPN?

David: Yeah, and it’s a good point. I’ve seen a lot of that shift in wide area network design as well, Mike. I mean, we had this one customer bought to us by a partner that was a dental group. Because there are multiple sites, everybody, initially, was thinking MPLS, but as we’ve dug in to their applications to determine, you know, “Okay, so what apps do you use to run your business?” Where are those apps located? Are they in a data center? Are they at the headquarters’ office? Where are these servers that are running these practice management applications or different applications? What we found out is they have already moved all of those apps in to the cloud. So, my recommendation was what we should be doing is deploying internet circuits to everyone at your locations, providing some type of a back up to the primary internet circuit for business continuity purposes. Let’s forget the MPLS because it didn’t make sense for us in that case to centralize everything in to an MPLS cloud just to have it go back out and get to the public internet.

But, the downside to those networks, especially for the network administrator, is that then you still have these firewalls at all these different locations, which have to be administered, and that’s an administrative nightmare. You also then have all these different points of failure or, not failure, different points of concern from a security perspective. Whereas, if you’ve rolled all that in to an SDN provided network (like the way the carriers might be doing, the way TelePacific is going to do it) then we could get all that traffic in to the SDN network still. We could route that out through, maybe, a couple of redundant, geographically diverse internet drain points and run it through firewalling equipment that could protect it, could put in the web content filtration, all that type of things. You still get the benefits of having all these multiple internet circuits, but still get the performance, security, and administrative benefits of having the configuration at a single point within the orchestration software, then pushed out to the end points as opposed to, again, having to configure all these end points to make the network work.

Mike: Yeah, that makes sense. Just thinking about it from their perspective… With MPLS, those are all the features that we’ve been talking about with MPLS for the last ten-fifteen years, the network-based firewalling and all that type of stuff, but, hey, you’re right when they go back to IPSEC VPN environments, either having to manage that whole thing themselves. I could see where that would be the benefit of, hey, you’re getting the benefits of MPLS without having to pay for huge MPLS circuits because that’s what everybody wants, right? Now 100Mbps connections, 500Mbps, gigabit connections are out there, everybody wants that speed, but to duplicate that speed of MPLS and have a gigabit MPLS connection, that’s really expensive as opposed to a gig public internet connection. So, they could still have that super high-speed of like 500Mbs connection or a 100Mbs, a gig, but then get a lower cost, MPLS-ish so to speak benefits. That’s cool. I could definitely see where that bridge is over.

David: The other thing that’s cool about SD-WAN is you could also configure it to where some traffic would go just straight out the Internet, almost like, a term you may have heard of, called “split-tunneling.” So, some of the traffic go direct out to the Internet, you know, no fuss no muss, other traffic could be pulled back in to the SD-WAN network. If its destination is somewhere else within the organization, within the SD-WAN network, it’s got that ability as well to, kind of, split tunnel the traffic out for increased performance, which I think is great. Yeah, like the more I learn about the capabilities, the more amazing it gets.

The other thing that we haven’t touched on or talked about as of yet, that comes at least with the SD-WAN technology that we’re looking at built in, is monitoring. So, monitoring and troubleshooting are already fully-baked. In the past, what we had to do, for example, TelePacific, had to buy this big SolarWind installation that we used to provide our customers access to looking at bandwidth utilization, latency, packet loss, all that kind of stuff. It’s a bolt-on that we have to try and join in to our network, whereas with the SD-WAN software, all that the troubleshooting and the monitoring are already built in.

A traditional network monitoring software package, yeah, you set it up to take a snapshot every so often, right? Every five minutes. Every fifteen minutes… Whatever. With the monitoring software that comes with SD-WAN, it’s real time like every five seconds, so if there’s ever a customer issue, you can, literally, go back to that specific exact point of time. You have full visibility to every application that is running across the network at that point in time, what the utilization is, who the users are. I mean, it takes troubleshooting to such a whole different level because all that intelligence, again, is built in to the software that comes with SD-WAN.

We’re just absolutely so thrilled because, specially, seeing one of these issues that your customer has that just happens every now and then – It’s very intermittent. Those are so difficult to troubleshoot with a traditional network monitoring software or a traditional troubleshooting platform, but, again, with SD-WAN, it makes it absolutely simple to go and pinpoint that issue at that given point in time, so this is another component to the software that we find so attractive.

Mike: Yeah, that’s cool. There have been so many times we’ve worked with customers who, maybe, aren’t so thrilled on their current MPLS provider, but, at the same time, they’re adding a location or they’re doing something like that where I could see where this would be a benefit to them. Where before, if they were in the middle of a contract with their current MPLS provider and they want another location, they were stuck; they had to add another node with that current MPLS provider. They had no choice because the location had to be up and running. Even though they would love to try a different provider, they were kind of stuck, whereas, this might give them an alternative to try out a new provider and try out SD-WAN to complement their existing network as opposed to just being forced to just extend their contract out even more because once they add another circuit, it was always like, well, if they’re a year and half in to a three-year contract, they at least have to sign a one-year to two-year contract on this other node, and then they have all these different agreements everywhere. It’s just a mess, but now that, kind of, gives the customers some freedom to do what they want with these additional sites or requirements, probably.

David: Yeah. I’ve got another example that we used this new SD-WAN software to facilitate. We had an existing customer with a big MPLS network and then they acquired this other location. This other business that they had acquired had just signed a deal for, like, a 100Mbs Internet circuit with some other carrier. They wanted to get the site connected in to the MPLS network, but they don’t want to now go and pay TelePacific for a whole another circuit when the company they acquired had just purchased a circuit and still have three years left on their term.

Mike: Right.

David: So, we were able to just deploy the SD-WAN appliance out to the customer prem and then just tunnel that traffic across that new internet circuit they had just acquired back in to our network, and then connect it back in to the existing customer’s MPLS network easy-peasy. It really does, to your point, create so many different new options that really weren’t available in the past. It’s pretty amazing.

Mike: That’s cool. What’s the – you know, you don’t have to give me the exact numbers – what’s the approximate price point per appliance out there that you guys deploy?

David: So, obviously, subject to change, the price that’s kind of being [batted 00:34:56] around right now is somewhere between $20 & $40 per month for the appliance, and then…

Mike: Wow, that’s cheap.

David: Yeah. Again, it’s due to the fact that we can leverage standardized hardware or the manufacturer actually can leverage standardized hardware to build those appliances. It’s looking like probably somewhere between another $20 to $40, maybe $50, something like that, as, sort of, an overall management fee on top, but, again, subject to change on that.

Mike: Right. But, it’s like if you compare that to the cost of MPLS of a, say, 100Mbps connection, the cost differentiation between public internet 100Mbs and an MPLS 100Mbs connection, it’s a lot more than $50 or a $100. There’s that differentiation point. I could see where just the price point is driving people that way too.

David: Well, yeah. You know, think of a Cisco router that you would need on a 100Mbs MPLS circuit, most carriers are charging a $150/$300 a month for that purpose-built Cisco router. Now, with more, you know… The standard-based appliance that the price drops dramatically.

Mike: Yeah, that’s great. What would you say are some of the ideal company scenarios for an SD-WAN? What are the applications that are absolutely prime for an SD-WAN network?

David: I think the one that always comes to top of mind for me would be, like, a retail or maybe a fastfood environment where a customer that’s got three/four/five/six hundred sites across the country and all they’re really doing is they’re processing credit cards. They’re not really doing much more than that, but because that’s critical for them to be able to run that business, that restaurant, that retail store, whatever it may be, they need redundancy and they need the ability to make sure that those are up constantly.

So, for that environment you could get, maybe, a T1, a 1.5Mbs circuit; something like that primarily. Then, some type of maybe like a 3G/4G wireless backup for relatively inexpensive… Or, maybe, DSL or cable, or something, and then now you can have those plugged in to the SD-WAN appliance.

It goes on prem, and you can deploy those services so easily because it could be completely automated where you put the appliance out there, you plug in your DSL, your cable, your wireless whatever, you push out the config from the orchestrator software – boom – and it’s done, and you’re good. So, now, you have a high-performing, extremely reliable wide area network at a fraction of what you would have to pay to, kind of, set that up in the past.

Mike: Yeah, that’s cool. So, would that appliance be able to take in two separate connections in to it? Because I’m thinking, obviously, you’ll be taking on more risks, but for a lower cost option for those tiny sites, like we talked about earlier. Could you put in, like, just a business cable connection and then a 4G cellular connection in to the same appliance, and you have two inexpensive connections that are high-bandwidth, and that appliance can manage both of them and kind of fail over?

David: Yeah. Again, some of the manufacturers that I haven’t looked at may operate a little bit differently, but I think it’s pretty much the same. What’s cool about them is… Today, what you typically find in a business continuity configuration from carrier is you find an active-passive config where you’ve got a primary circuit that’s active and then you’ve got this back up circuit that’s just sitting there idle. It’s one of the things that drives customers crazy because they don’t want to pay for a secondary circuit to have it just sit there and possibly never even be used. So, with SD-WAN, because of the intelligence built in to it, you can set it up active to active where the device will send traffic down both circuits all the time and then adjust automatically according to the real-time performance associated with multiple circuits.
These appliances, they’re designed to have multiple circuits plugged in to them. I mean, it’s not just two either. You could potentially haven three/four/five different circuits plugged in to these devices and, again, it’s monitoring every single one of them and sending traffic potentially across all of them all the time.

Mike: Huh, that’s cool. That’s, kind of, confusing my non-tech mind. So, how would that work with… If the customer, I’m just assuming, say, they have things on site that requires static IP. How can that appliance or piece of equipment be used off both different Internet connections if it needs a static IP like some type of a mail server or something? How would that work?

David: Yeah, that’s a great question. The way that TelePacific is currently looking at accommodating that is that the IP that would be advertised would be a TelePacific IP. So, that would be, sort of on the edge of our network, if you will, so that any external traffic that needed to get inbound to this customer, would be pointed to that TelePacific IP, which would be sitting within our cloud, within our network.

Mike: Okay.

David: The traffic would then get routed through the SD-WAN gateway across all these different circuits towards the appliance – the SD-WAN appliance on the customer prem. So, it would point towards these different ones, but none of those individual Internet circuits, none of those IPs would be advertised for incoming routing purposes. Does that make sense?

Mike: Yeah. Let me just make sure I’m understanding it. So, if they had TelePacific for their SD-WAN service, but they had third-party Internet providers for, let’s just say, both connections at a single site, or all the connections or whatnot, they would still get an IP from TelePacific for the SD-WAN service on the SD-WAN network side. So, they could have third-party Internet providers, they wouldn’t have to have TelePacific and your guys company there for every connection.

David: Correct.

Mike: That’s cool. That’s really cool because, speaking of you guys specifically, you guys have always had the ability to do that because you guys offer different types of connections from an ISP standpoint. But, we’re talking about a whole network and doing the SD-WAN side to be able to do it with third-party connections. That really opens up a lot of doors. That’s awesome.

David: Yeah. That’s always been a bit of a limitation with multiple carriers because, you know, back when the ISPs were handing out class C or /24 blocks of public IPs, it wasn’t that big of a deal. You could have dual carriers and then you could run BGP between them, and you could advertise the same IP out both carriers, and it worked well. Now, that we have basically exhausted the IPV4 public IP address space pool, none of the carriers are giving out class Cs anymore, and that’s the minimum requirement to advertise address blocks using BGP across the public Internet.

So, now, with SD-WAN, we head back in to a situation where you could have those multiple different ISPs with all their multiple, different public IP address blocks, but because that IP is taken cared of through the SD-WAN carrier cloud, you can get back to still being able to send traffic inbound to that IP across some carrier even though that carrier doesn’t even use that IP address, so it’s really exciting.

Mike: That’s awesome. So, all you IT professionals out there, if you didn’t hear that exactly, what we’re saying here is that you can have two third-party Internet connections at your office, high-bandwidth connections like a 4G connection, business cable, whatever, and all your applications can be using both of those connections at the same time, so if one fails over, it’s automatically going to the other one. You’re utilizing both Internet connections every day, all the time, in addition to all the benefits that we’ve talked about earlier that SD-WAN is giving you. That’s awesome.

I think that is really something a lot of companies can benefit from because, these days, I just think it’s crazy for any business to rely on a single Internet connection. We’re using the internet too much. Businesses need it for almost everything they do, so I always recommend a backup connection. But, like you said, the problem is always that the backups are sitting there idle or they’re having to divide their network in to two separate connections, sending traffic for one application on one connection, and sending all other applications on a separate connection, but to be able to use both for all applications at the same time, that is really cool.

David: Yeah. And the nice thing too is, say, you’ve got, you know, some traffic on one circuit and some traffic on another circuit, and one of the circuits happens to die and the traffic needs to get moved over to the surviving circuit. With the intelligence built in to SD-WAN, that happens in less than a tenth of a second.

I was on a demo where one of our engineers who were demonstrating the SD-WAN box, he had a fiber circuit plugged in to one of the interfaces and he had a 4G wireless plugged in to one of the interfaces. He configured his active-passive just to, kind of, demonstrate the speed of the fail over.

So, he’s delivering the presentation – he was also on a VoIP phone through the SD-WAN box – and he pulled the interface on the fiber circuit. We saw the traffic automatically, seamlessly, moved to the 4G wireless and we didn’t even hear a hiccup in the conversation because it happened like that. So, the challenge is that, sometimes, we had, like with BGP fail overs, to deal with the convergence times, and there were timers, and there’s holddowns, and there are all these stuff. So, it may be thirty to ninety seconds before the traffic would fail over, so you’ve lost your call you’re your customer’s call [Inaudible 00:46:42] Again, with SD-WAN, all those convergence timings issues go away as well.

Mike: Yeah, that’s awesome.

David: Yeah, it’s incredible. I mean, when I was looking at that demo and it was me and a bunch of sales engineers at TelePacific, you know, we’re IMing each other back and fourth behind the scenes going, “Oh, my god! I can’t believe what this can do! This is amazing! I can’t…” You know we’re all just freaking out because we’ve never seen technology like this before. It really is quite a game-changer, specially on the carrier side, because we’re looking at just being able to bring our level of service to your customers up such another notch. It’s just phenomenal.

Mike: Yeah. Let’s be honest, us people in the ISP network services world, we’ve been waiting a long time for something exciting. It’s been a lot of boring stuff. It’s been a lot of the same-old, same-old. I mean, SIP has been the most exciting thing we’ve had come in to our world for the last ten years. It’s been a long time coming, so when something new comes out, I think all of us are a little bit giddy at least.

David: Absolutely.

Mike: Yeah, that’s awesome. Well, cool. I can’t think of anything else that I could ask you. I mean, from my perspective and all the IT professionals out there listening, the trigger points to maybe take a peek in to this might be either, obviously, adding a location, or your contracts coming up for your MPLS network, or you’d like to increase bandwidth at some of the sites, anything like that, I think, it’d just be worth, you know, peeking at these stuff just because you never know.

It just seems like such an open platform that there might always be a way that you could squeak in trying out SD-WAN, and maybe doing it for one site or something, and just give it a trial, where before you might have been stuck and it’s kind of an all or nothing scenario with the way you’re set up with MPLS. With this, it just really opens it up to give it a try. So, any type of in a new application you’re deploying, or cloud application, or, like I said, contract end date, all that type of stuff is a good opportunity.

David: Yup. I agree 100%.

Mike: Well, cool. Thanks, David. Thanks for coming on the show.

David: It was definitely my pleasure. Thanks for having me, Mike. I appreciate it.

Mike: Awesome. No problem. Have a good day.

David: Okay, buddy, you too.

Mike: Alright. Is DK a smooth-talking engineer or what? If you have any questions for DK or myself regarding SD-WAN, just email us at cloudtherapy@aerocominc.com and we’d be happy to help you.

Before you go, I just wanted to remind you again about our free gift – that’s a really cool comparison chart comparing SD-WAN to the other types of WAN services that your company can use like MPLS, IPSEC VPN, or point-to-point. It’s a free gift for you and all you have to do to get it is text the word “WANGUIDE” to the number 44-222.

Related Content

Tagged with: