Cloud Therapy: Ep 003 – 5 Ways to Prepare for an SD-WAN Install

So you’ve decided to move to SD-WAN. What should your IT department do to make sure you have a smooth installation?

To answer these questions, we invited an expert SD-WAN engineer, Jack Dolan from Aryaka Networks, to speak with us. Aryaka has been doing SD-WAN as long as anyone so they absolutely know what needs to be done!

Jack explains 5 specific tactical items that IT Departments need to do in order to transition from SD-WAN from MPLS or any other type of business WAN… flawlessly!

For more episodes, find Cloud Therapy on iTunes!

Have an AeroCom expert help you sort through every major SD-WAN offering to find your top 3. Click below.

MY TOP 3  

 or

Click here to see how IT professionals rate their SD-WAN provider.

See below for the full transcript:

  Mike: So, you just finished getting some quotes on this new SD-WAN stuff and it looks like a service that might be a great fit for creating a better WAN connection for those two remote sites on your network. But, before you pull the trigger and sign paperwork, you stop. There is something you need to know. Your boss is going to ask you how much work this transition will entail and your brain is a little foggy about that question. If that describes the situation you’re in or you think you might be in, you’ll love this podcast.

On the podcast, today, I’ve got a great guest. His name is Jack Dolan and he’s a sales engineer with Aryaka Networks. Now, Aryaka Networks has been an SD-WAN service provider for about seven or eight years, so they’ve been in the game for a long time. They really know what they’re doing and Jack knows some great stuff.

Today, Jack is going to tell you the five things IT departments need to do in order to transition from an MPLS network to an SD-WAN network. In addition to that, he’s also going to help clarify his points by walking us through what needs to take place to install an SD-WAN network if something like Office 365 is a big priority in your environment.

Then, as if that was enough, something really cool he’s going to talk about is Aryaka Network’s ability to give you a free trial. So, a lot of times, I don’t like to get too salesy on the podcast with providers, but just because it’s a free trial, I thought it would be really cool to ask him: Hey, what does that entail? How do our listeners get to try your service for free? What are the stipulations with that? So, we walk through that a little bit too.

So, it’s a great episode packed with a lot of good information from someone who’s very knowledgeable about SD-WAN, and I hope you enjoy it.

But, before we get started, I wanted to also offer you something free from us. I mentioned it a couple of episodes ago and I’m going to mention it again, it’s a free breakdown of SD-WAN and all of the different capabilities it has versus MPLS, point-to-point, and IPSEC VPN. So, it’s basically a breakdown of how SD-WAN compares to all the other wide area network technologies out there, and we’re giving it away for free as a gift to our listeners. All you have to do to get it is text the word “WANGUIDE” to 44-222. Again, text the word “WANGUIDE” to the number 44-222 and we will email you a free copy of this comparison we made comparing SD-WAN to all the other wide area network services out there. Enjoy the free gift and let’s get on with the show.

Alright, Jack, welcome to the program. Thanks for coming on.

Jack: Thanks for the invite, appreciate it.

Mike: Awesome. Well, can you tell us a little bit about yourself both personally and professionally?

Jack: Sure. My name is Jack Dolan. I’m out of Greenville, South Carolina. I’ve lived here for about eleven years. I have three wonderful kids, two grandchildren. I’ve been to a few companies before Aryaka Networks, which I’ve been employed with for about two/two and a half years.

Mike: Awesome.

Jack: Before that, it was with Riverbed Technology for four and a half years. Before that, I was with Blue Coat. Before that, it was with RouteScience Technologies. RouteScience was one of the first companies I did where WAN optimization- where we were looking at quality of paths. So, you got multiple paths, you get to choose which path is best for your applications, which is, kind of, what SD-WAN is today. So, I’ve got a lot of experience even up to WAN optimization and byte caching and compression that Riverbed provided. What’s really neat about the company that I’m at now is that it provides a lot my background all in to one product or service. So, that’s, kind of, interesting. So, that’s my background.

Mike: Very cool. That’s an awesome background and I think that really helps our listeners out in terms of knowing a little bit more about SD-WAN. You’re a great person to talk to, which is why we have you on the show.

So, Jack is going to talk to us today about five things that an IT department needs to do in preparation to successfully transfer from an MPLS network to an SD-WAN network, because I know a lot of you guys out there, Sys Admins, IT departments, you guys currently have MPLS and you’re considering SD-WAN, but you’re thinking what’s involved with that transition.

So, Jack, with that, I’m just going to turn it over to you, and let’s hit on number one.

Jack: Sure, alright. The first thing that I would think about as far as if I wanted to move from MPLS to SD-WAN is know that SD-WAN do not have to be an all or nothing solution. It can, and we will talk about that, but it can be a solution for something very specific.

Let’s say you have a specific application that you need better performance for. Let’s say you have to get Office 365 and MPLS doesn’t provide that capability, and you don’t want to use the internet to get to Office 365, SD-WAN might be a very good solution for that. So, keep in mind that whatever your goal is, stay focused on that goal and attack that goal so that, at first, you might be just wanting to accomplish something small to get to something big. So, know what you want to achieve with your SD-WAN solution, stay focused on that, implement that, and, obviously, later on MPLS, and replacing that would just be the evolution – it’s the normal progress of things.

Mike: Awesome. That’s an angle that I wasn’t as familiar with – going for a specific application. What are some of the other reasons that someone might want to go to an SD-WAN network in addition to improving their performance on one specific application. Are there other reasons why?

Jack: Yeah. One of the biggest reasons is just, you know, total cost of ownership. So, MPLS, when you compare the price, specially when you go overseas and also the agility that they don’t have, it could take weeks, months, something like that, to bring in an MPLS link to that location would be very expensive. You can pop in an SD-WAN solution pretty quickly, usually in less than a week and have it up and running very quickly. Therefore, it’s more of a strategic play than it is a tactical play. You’re not trying to fix something. What you’re really trying to do is- You know what? I just want to go and… I want to get rid of MPLS or I want to reach places that MPLS can’t reach and get the same quality of service that MPLS could do, but MPLS is having a hard time doing because of hard to reach places.

So, there are a couple of other reasons. Most customers, what they do is they’re looking for something specific to improve. A lot of customers will, just right of the bat, “Hey, I don’t want to deal with MPLS anymore. It’s too expensive. They’re support isn’t what I thought it was. How do I get to an SD-WAN solution that’s better? Either they can maintain it or they can get a service like ours to maintain it, you know, be proactive or whatever, and it’s a very simple this or that type of a decision. So, we see both.

Mike: That makes sense. So, some of the top three that I heard were: obviously, improving the performance of a specific application, number one. Number two, cost savings over MPLS, and number three, reaching a location that MPLS network cannot reach; those are, kind of, three examples of the top priorities that companies might have when they’re looking to transition from MPLS to SD-WAN. Is that fair?

Jack: Yeah. Those hard to reach places are sometimes places where MPLS say they’re reaching, but it’s really a DIA, which is, you know, direct internet access. So, they’re really getting an internet link to do MPLS, which means they’re really riding the internet. So, why pay the extra money for MPLS after that location when you can just use your internet link and do an SD-WAN from there?

Mike: Right. Now, how would that affect how they approach their implementation? Say, if somebody is focused on cost savings over MPLS versus trying to improve the performance of a specific application. I mean, there are some assumptions I can make there, but rather than assume stuff, I figure I’d just rather ask you. How would that really change how they’re implementing it or how they’re evaluating providers?

Jack: That’s a great question because a lot of times what customers want to do with SD-WAN is, “Hey, I’ve got this specific issue or a problem that MPLS is not able to handle,” so they’re, kind of, laser-focused on that one problem. Can SD-WAN help with that problem? So, there are a lot of features that SD-WAN can bring to the table for them, a lot of opportunities to tweak certain things whether it would be “Hey, let’s use both links,” if you’ve got two ISP links and you want to be able to use both of them. We want to use the lowest latency one for voice, the one with the least packet loss – we want to use that link.

Of course, if something doesn’t meet the criteria or the quality of service requirements that you wanted to meet – let’s say, 40 milliseconds round trip as far as ping time. If it goes above that and if the loss has increased… If it goes above, let’s say, 1% loss, then go ahead and move it to the other path as long as the other path is good enough. This is the kind of technology that MPLS doesn’t have, right?

So, we could actually make voice better simply by taking advantage of the two paths that we have. The probability of those two paths having loss at the same time is pretty nil, therefore we could improve your voice, we could improve your virtual desktop interface where people are doing screen space back and forth with Citrix or with VMware VDI, things like that, or video. So, some of these things are what SD-WAN, kind of, prides ourselves on and the fact that we can even take these things that normally require quality of service, and yes we can provide that too, but we can also specifically fix applications through certain features that we wall have that MPLS doesn’t.

Mike: Got it. That makes sense. Cool. Okay, so, number one was staying focused on the purpose of your SD-WAN. How about number two?

Jack: Well, the second one is understanding your SD-WAN deployment. How are you going to deploy this? All SD-WAN solutions require some kind of appliance that goes on site at the customer’s site. The appliance has the intelligence that’s needed to properly route traffic based on performance over the best path. Some of these appliances also have certain features that you can take advantage of such us byte caching and compression, TCP (algorithms might different from everybody else), secure tunnels, time to replay, there are a lot of things that you can take advantage of. These are some of the features that talk about the first criteria.

But, part of that deployment, depending on what features you want to use, could affect how you want to deploy that appliance at each site. You want it to be like a next hop router, just like any other service provider – if you go left, it’s MPLS, If you go right, it’s the SD-WAN, or you can have it sit, literally, replacing the firewall. A lot of our devices can replace a simple firewall. It doesn’t do all the Palo Alto stuff, but if you’re basically just trying to replace an ASA, you know, it’s real simple to do. If you have an ASA that’s up for renewal, this might be a good opportunity. We’re killing two birds with one stone, right?

Mike: Right.

Jack: You can place it transparently bridge. This is where as the traffic comes through it, it’s in path, just like the firewall, what happens is the appliance would intercept only interesting data – traffic that needs to be routed across the SD-WAN, if it doesn’t need to be routed, it’s simply passed through a bridge through. So, there are a couple of deployment models.

So, understand your environment for deployment. Keep in mind, are things like appliance redundancy required? Path redundancy, is that required? Path diversity. Path diversity is very, very important because if you’re trying to communicate between two locations across two different paths and using those paths at the same time over the internet. You don’t want them to actually converge in to one autonomous system on the internet at some place because that means you don’t have full path diversity end to end. What you really want is that diversity so that if that one path is having an issue (loss, latency, jitter), the other path, probably, isn’t having that issue, therefore, you can move the traffic to that immediately, usually in less than a second.

Mike: That’s awesome.

Jack: So, these are some of the things that need to be thought about as far as how you’re going to deploy. At my company at Aryaka Networks, that’s what we do. That’s what my job is – to help design and deploy this piece of it.

Mike: Awesome. So, this is, kind of, like developing a little cheat sheet prior to an IT department quoting different SD-WAN providers. It would be to understand a little bit about the deployment models or spend some time, maybe, with the first provider that they talk to, and really understand how that provider deploys their SD-WAN service.

Jack: Exactly. For instance, at Aryaka, we don’t need two links. One link is fine in a lot of cases. I can get in to that a little bit later, but basically most SD-WAN provides two links, and that’s great if you can do that – we highly recommend it – but, we can get pretty far with a single link as well. So, I can get in to that too.

Mike: Awesome. Okay, so we’ve got two down. Hit us with number three.

Jack: Before you go to do the implementation, obviously, part of the design – and this is more like a two and a half than it is a three – but make sure that your network topologies are updated. I can’t tell you how many times we go to implement and the data that we’re working with is just out of date. So, that’s the big thing. I mean, if you have ten sites, ten branch offices, when was the last time you updated your Visio diagrams, so something like that. So, that’s very, very helpful specially when you want to know how to put them in, which deployment model you use, so make sure that that’s all up to date. So, that’s pretty easy to do.

Mike: Yeah. I could see that where if a company’s been around a long time or there has been some turnover in the IT department, a lot of times, I’ve seen, myself, talking to IT departments where some of that stuff is out of date, so I think, yeah, that’s a good point. How does that affect their implementation in terms of implementing SD-WAN? What’s like a scenario where if it’s not up to date, it could really hurt the implementation?

Jack: Well, such us they have two carriers where they may have replaced the carrier and it’s just not updated on the information. Therefore, the IP addresses might be incorrect and, therefore, the IP addresses that we could be assigned or that the appliance could be assigned are just not right. So, when the system or when the appliances ship out there with the configuration doesn’t work, we may not have hands on experience on site – that slows things down. So, that’s why it’s very, very important to have updated information.

Mike: Yeah, good point. Awesome. Alright, what about number four?

Jack: Number four is when you actually go to install or implement. So, you have this model, it’s deployed. In our case we’ll bring up secure tunnels to our closest POP to get it on to our core network, so now we have reachability end to end. The next step is to simply route the traffic over your SD-WAN. That could be as simple as a static route; that could be as simple as listening to RIP updates from the appliance or BGP updates from the appliance. It’s simply pushing the traffic on to the network. Also, if it’s in-path, the traffic is already going through, you just simply turn on “Hey, intercept this traffic,” and it would start sending it over the SD-WAN.

The most important thing is that when somebody implements their first time traffic going over the network with default settings, nothing should break. Their applications should still run fine. What you want to do after that is that’s when you want to start tweaking. So, first of all, you implement, make sure everything’s running fine. It should only take a couple of hours or something like that. Then, later on, you might want to do some tweaking if necessary. So, this is where you would say for this application I want to watch for these network characteristics or network performance characteristics, and then if anything like this happens, move. So, make sure that you get a good baseline first, okay?

Mike: That makes sense.

Jake: The other thing is, you know, keep it simple. There’s no reason to add complexity just because it exists. That’s huge in the network world, right?

Mike: Right.

Jake: Just because you can tweak this now doesn’t mean you need to. So, keep it simple for you because, you know, routing by itself is hard. When you start tweaking with performance routing… Hey, when this traffic reaches this much bandwidth usage, okay, move it over to this. Well, that application, by moving it over to the other route or other path, could affect other applications that are in route back to the other one, you could actually cause some serious performance issues thinking you’re doing well. So, just keep your policies very simple.

Mike: That’s a great tip. Then, going back to the actual implementation, are there ways to do it where your current network is still up and running and you’re kind of setting up your SD-WAN network without interruption to your current network?

Jack: Yeah, absolutely. So, like I said, a lot of appliances can be placed in-path and it’s simply a pass through box, so however your routing is doing today, we’re not going to interrupt that. The only time we interrupt it is, you know… It takes what? Five seconds to put in a box, right? We actually plug in LAN port and WAN port and it just goes right on through.

So, we can implement without affecting their specific production traffic, but what we like to do is when they start moving the traffic over to the SD-WAN, okay, it’s simply a route change. Let’s say you have a branch office and that branch office was Network A and the data center is Network D. In the branch office you say, “Hey, the next hop for Network D is this appliance” and then the appliance takes it from there. Then, simultaneously, in a lot of cases depends on which vendor or SD-WAN solution you’re talking about, the other side has to do the exact same thing at the same time. That’s because some of the features, such as byte caching and compression, TCP acceleration, that requires symmetry, route symmetry.

Mike: Right.

Jack: So, this is where, you know, if you send out an SD-WAN, it has to come back SD-WAN – very, very important for those features, those acceleration features, to work. Alright? So, it’s simply a routing statement.

The answer to your question is it’s simply a routing… Route convergence happen all the time on MPLS, so going from one path to another within their MPLS cloud happens all the time. This is no different, so it’s not really impacting your network. What you do is you simply move the traffic over so that, between those two sites where you’re using the SD-WAN network, you’re taking a look at all the visibility portal, and the graphics, and the reports to see how well your traffic is doing. Obviously, you want to take baseline testing, performance testing before, and take those same baseline testings after to make sure you’re getting improved performance. Okay?

Mike: Got it.

Jack: Making sure you’re hitting your goal, which is… Remember, the first one was know your goals, know what you’re trying to achieve. If you’re trying to achieve better performance for an application, you want to have some baseline testing and you want to have some after the SD-WAN was deployed testing to see if your performance has improved.

Mike: That’s a great point to do the baseline testing, and then test again afterward, and then tweak as needed, maybe, share that with the provider as well that the goal to improve this and make sure that they’re bought in, that they’re going to be able to do that so that that way, if it’s off, they can tweak it, and they know what your goal is.

Jack: Right.

Mike: Yeah. Is there, like, a day and time that you typically like to install networks with companies? Like, I know, being in telecom and ISPs over the years, a lot of times they’ll say, like, a Friday at, like, three in the afternoon is usually ideal because it’s not your busiest time of the day – typically. Obviously, it depends on the company, but they always say, “Hey, don’t do it after hours because we don’t have as many people working here at the provider after hours,” or things like that. Are there days and times that you think is typically ideal for companies to make the transition?

Jack: Well, I typically leave it up to the customer based on their comfort level or if they have a change control window that’s from every Wednesday at, you know, 11:00 p.m. or something. However, if they leave it up to me, I usually say let’s do this at 7:00 a.m. at whatever time that they’re up for that branch office. Again, it takes five minutes to route traffic over our solution. And, as customers come in or as clients come in to work and as they’re working, we actually see the traffic, we can monitor things. Now, it’s usually me and the customer, it’s not our support because we all know it’s going to work. We just don’t break things, right?

Mike: Okay.

Jack: If we see certain things that we could tweak, then we’ll let the customer know. A lot of times we’ll go ahead and tweak it during the middle of the day if it doesn’t hurt anything to improve performance for a couple of applications. Again, that’s something else that we, kind of, pride ourselves on. We’re not just providing a service that provides connectivity end to end, we care about the application. If our customers call us and say, “Hey, email just doesn’t seem as fast as it should be, but everything else is really working fast,” they can call us and we can help them try to tweak it to make it faster.

Mike: Got it.

Jack: Not a problem.

Mike: That makes sense.

Jack: So, that’s one of the key things about as far as what time to do it. I like it when there’s going to be traffic up there, so we can get something done, and monitor things and look at things, but we’ll do it any time they want to do it.

Mike: Got it. That makes sense. Alright, how about number five?

Jack: The fifth thing is more of to make sure that their comfort level is going to increase once they deploy SD-WAN. They don’t have to do all sites to replace MPLS day one. They can do two or three if they want to. Take their problematic sites and let’s do those first, you know, a data center and two other sites, or something.

So, what’s nice about that is you can piecemeal it. You don’t have to do it all or nothing. Now, when you do that, your comfort level is easily going to grow, like, “Wow! This SD-WAN works pretty darn well. And, you know what? Next time around, I’m just going to call this company and we’re just going to do it. We’re just going to cut everything over and then we’ll get rid of MPLS.”

Now, one thing I did forget about one of the previous points is… Obviously, routing – when you’re actually doing the routing, it can be with static routes, it can be with dynamic routing, with BGP, some of that stuff you want to get your routing engineer. If you’ve got a very large network, you want to get your routing engineer or one of our solutions architects to really help you out to make sure that you implement that right, because BGP can be, kind of, complex sometimes depending on the customer’s network.

Mike: Got it.

Jack: So, really, what it is, once you get a couple of sites under your belt, the rest of them are just cookie cutter from there – it’s real simple.

Mike: Awesome. Alright, just to summarize for everybody:

#1: Stay focus on the purpose of your SD-WAN solution.

#2: Understand the different deployment models and which one fits your requirements the best.

#3: Make sure you’re using the most current network diagrams and topologies including routing.

#4: Install and implementation should not break anything. It should do the exact same things that your current network is doing, and making sure that you’re setting some baselines both before and after you install it.

#5: Consider, possibly, piece mealing your installation. So, maybe doing one site at a time as opposed to thinking you have to do it all at once.

So, did I get that right, Jack?

Jack: Yeah, sounds great.

Mike: Awesome. So, what I’d like to do now is have you tell us a little bit about how Aryaka, specifically, would deploy by giving you an example. So, say, a company had around ten or so sites and Office 365 was the cloud service they have that was a big priority. How would Aryaka look at installing that solution?

Jack: Great question. In fact, this is what I do day to day. It’s a lot of fun.

So, let’s say a customer comes to us and they say, “Hey, we’re ready to deploy, you know, Aryaka.” First of all, I need to really talk about a couple of really big differentiators between, probably, all of the SD-WAN solutions and Aryaka. First of all, the definition of SD-WAN is the ability to, from a centralized location, push policies, whether it be application performance policies or business policies, down to the edge so that something can be configured from a centralized location and therefore making an impact almost immediately – that’s the big thing.

So, the way our SD-WAN works is we have a core Layer-2 network. Inside that core Layer-2 network… It’s not MPLS. MPLS is Layer-3. There’s too many route convergences going on there and that makes your latency loss jump up and down all the time. With us, we have a flat line latency wherever it is. It might be from India back to the United States – it might be 200 or 300 milliseconds, but it’s a flat 200/300 milliseconds.

So, the great thing is we, kind of, have an MPLS. Whereas, most SD-WAN providers, what they do is they want an SD-WAN to augment or to enhance their MPLS services, so they’ll keep some traffic on MPLS, but they’ll bring it over to the IPSEC world with the SD-WAN. What we do is we can allow MPLS to run as it is, we bring in SD-WAN, and what we’re doing is we’re bringing in to our own private core which is better than MPLS for a lot of reasons. Number one, again, it’s a Layer-2 core.

Two, we terminate – we’re a TCP proxy both at our POPs as well as on our appliances on our customer sites. Therefore, we can tune, we can have our own proprietary TCP stack between our appliance and the POP. That allows us to tune our TCP stack so that we can maintain the highest throughput possible. That’s huge. MPLS doesn’t provide this. A lot of SD-WAN appliances don’t apply this. They don’t have this. They can’t do this.

So, that’s just the TCP aspect of it for TCP traffic, but on top of that, we can also do byte caching and compression, a lot like Riverbed or SilverPeak. That’s also included, no extra charges, part of the service. So, you’ve got those two things working for you.

On top of that, we can also do some edge things. The way the customer connects to our POPs is from our ANAT to our POP, you have two IPSEC tunnels. Those IPSEC tunnels, we can send them over to different, diverse paths. This is where path diversity and redundancy is important over the internet. So, if you have two internet links or even one – and I’ll get in to that in a second – but if you have two internet, we can send both those tunnels over the two different links just to get it to our closest POP 10-15 milliseconds away. We’re not talking about end to end internet, which is what most SD-WAN providers have to deal with, and the longer you go, the more susceptible you are to loss, jitter, high latency going up and down, that kind of stuff – we’re keeping it very short.

Mike, do you have voice over IP at home?

Mike: Yes.

Jack: So do I. That’s what we’re talking about. We’re talking about how good is your voice over IP at home. Because the distance that we’re travelling from your site or the customer site to our POP is so minimal, the latency and loss is so small, we can use it all the time and it’s not a problem now.

What if there is a problem though? We’ve got really cool features such as Smart Link, which includes path replication. For that important traffic such as voice, why not send it down both paths, the same packet, down both paths at the same time so that the POP, 20 milliseconds away, will take the first good packet and keep it going across our Layer-2 core.

Now, SD-WAN products or solutions, they do the same thing except they do it from, let’s say, LA to New York. LA to New York is 70-80 milliseconds and, depending on what providers you have, you may have to switch from one path to the other. That, actually, can create high levels of jitter and that’s bad for voice. So, you may be trying to solve a voice problem, you could actually be causing other problems with voice by switching paths too often. With us, what we’re simply doing is right there on the edge, 20 milliseconds away. Let’s say one path is 20 milliseconds, the other path is 15, we’re creating a 5 millisecond jitter, any voice buffer can handle that all day long.

Mike: That’s awesome.

Jack: So, we have all these that are both from the edge, from a UDP, from a video, from a virtual desktop – these are great for the Smart Link capabilities. That’s a great application that’s going to prove that. Then, from the TCP side and the data transfer side, we’ve got the byte caching and compression, we’ve got the proprietary TCP stack, the multi-segment architecture (which, by the way, we just received a patent on that) that’s basically breaking up your client to server TCP session in to multiple segments and then controlling each segment individually in order to provide the fastest throughput possible.

So, now let me explain the network. It’s real simple to deploy Aryaka’s solution. Customer, we get their network topology from them, we get IP addresses assigned to our appliance, we ship the appliance, we ship it unconfigured, and we also email them the config file. They take the config file and put it on a USB stick (we ship a USB stick with every appliance), they plug in the USB stick in to their laptop, they put the configuration on there, they pull it up, they put it in to the appliance, and they power it up – boom – they’re configured.

Mike: Wow.

Jack: Now, if they’re in-path like a firewall, our tunnels will be up and running. It doesn’t mean we’re routing any traffic over Aryaka, we don’t do that until the customer says to go, you know, they say, “Hey, let’s do this,” but the tunnels can be up and running. We might have to wait for another site to come up anyway, right? Because you need at least two sites.

So, we do the same thing at all sites where, literally, we could ship a box out, have it configured, and have it up and running in less than a week. That kills MPLS. Doesn’t matter where in the world, most of the time it’s a week, sometimes, with customs, it’s two to three weeks, but, again, still much faster than MPLS, so we’re more agile by far.

Once we get the tunnels up, at least two locations, it’s simply, “Okay, Mr. Customer. Go ahead and turn on your routing.” They route traffic over Aryaka simultaneously at both sites because we do the WAN optimization – in some cases, we definitely had the TCP acceleration, TCP proxy – and what happens is we are accelerating that traffic day one. Most of the time, customers don’t have to do a thing after that at all.

Now, when we route, again, this is where part of our job is: Is it going to be BGP? Is it going to be RIPv 2? Is it going to be static routes? So on and so forth.

So, we’re routing traffic, off it goes. If customers have SSL sites in their data center, they can load their private key and certificate up to our secure vault. It automatically gets distributed to our POPs and our appliances. That way, we can be that authorized man-in-the-middle to see that raw data, so that we can apply byte caching and compression, and make that so much faster than normal – think Sharepoint, right? Something like that.

Mike: Right.

Jack: Same thing with, let’s say, cloud service. I mean, yeah, they can have access to it over the internet, but let’s say you have a cloud service, Salesforce.com, sitting at Chicago – that’s where the data resides. If you want to take your Singapore office, and your Singapore branch office needed to get to that data constantly every day, then what we can do is we can say, “Hey, for those routes going to Salesforce, your next hop is now Aryaka, through our appliance.” We route the traffic all the way to Salesforce.com. It comes out of our Chicago POP, which, by the way, just like most SAS offerings, they’re in the same building we are. We’re just a few racks down. So, we NAT outbound, that forces to come back to us, okay, right there two milliseconds away, and then we bypass the internet completely to get it to their branch office in Singapore.

Mike: Got it.

Jack: So, this is how we can improve any, you know, any SAS offering anywhere on the internet. It doesn’t matter where they are, we can improve performance for any SAS offerings. Whereas, MPLS – How do you get MPLS in to that service? They’ve got to bring in one link for every single customer that might be in there, right? So, it, kind of, gives you an idea of how flexible we are and how quickly we can deploy.

Once they bring up routing, you know, basically, you’re done. Here’s one of the great thinsg about Aryaka, we’re proactive with support. We will tell the customer, “Hey, your latency just went up by 40 milliseconds,” and usually within five minutes, or “Hey, your loss just jumped from none to 5%.” We’re going to let you know almost immediately. Also, if you want, for a small fee, we can be authorized to call your ISPs, so that way you don’t have to call them. That way, we’re not just notifying you, we are fixing it, we’re getting it worked on if it’s, you know, an ISP problem. Obviously, if it’s within our core, which rarely, rarely happens, we’re already working on it. We’re getting it fixed. By the way, it’s redundant core, you know, where we can switch from link to another link in usually less than a minute or less than a second in some cases.

Mike: That’s awesome.

Jack: Yup.

Mike: Yeah.

Jack: So, it’s more of a managed service. Our solution is a managed SD-WAN solution, whereas other solutions are “Here’s your box. Good luck. We’ve got training if you want to go to it.” It’s like the Riverbed approach, which is not a bad thing. I mean, they’ve got a pretty good box there for what they do, but if you want the combination of Riverbed, plus Talari, plus MPLS, or whatever, better MPLS core, that’s who Aryaka is. In fact, I always like to say, the other SD-WAN providers, they want what we have, which is a core. What they typically rely on is MPLS as their good core and then they want to be able to use what’s available, what the internet is good at, right?

Mike: Right. Now, one thing I definitely wanted to bring up with you is I heard through the grapevine that Aryaka sometimes offers a free proof-of-concept. So, can you, kind of, clear up that “sometimes” for us and tell the listeners what’s involved with that? Because every IT department out there love to try stuff for free, but buying something without ever testing it is always a little bit scary, so can you fill us in on the “sometimes” there?

Jack: Yup. Absolutely. So, first of all, we’re the only service provider that I know of that would allow customers to have a proof-of-concept. Now, it is free, but there has to be specific criteria that’s met.

Mike: Okay.

Jack: One of the criteria is that they have to have something fixed. There has to be an application that’s not doing well that we believe, based on our technology, that we can fix.

Mike: Okay.

Jack: Such as file transfers are just dog slow. They take three hours – something like that. If they’re using Windows file sharing, we can probably turn that down to, instead of three hours, probably fifteen minutes. For that same file, instead of taking three hours, we bring it down to fifteen minutes, making the users more productive – so, something like that.

Or, we have a call center that is trying to use the internet and is realizing, boy this is not a good idea to use the internet. It’s just not as stable as it should be specially if it’s some place, like, out of, I don’t know, Mexico or something – that’s where their call center is. So, they need a way to make their voice calls better. So, that’s where we would say, “Well, if we implement Smart Link and path replication between two paths. We’re sending both packets down both paths, the probability of both those paths losing that packet goes from – let’s say, it’s 1% loss on both paths – it goes from 1% to 0.01%. There’s your four nines” Okay?

Mike: Yeah.

Jack: So, these are the things that we know we can fix. Great use cases where – You know what? If we slap this in, if we bring this up as a POC, you’re obviously going to buy, right?

Mike: Right.

Jack: So, the second criteria is that when we’re done, we’re expecting them to sign on and become a customer right then and there. Okay?

Mike: Okay, got it.

Jack: So, now, we do offer paid POCs, not a problem, if they want to bring one for a month. If they want to do just functionality testing and make sure we don’t break anything, which we know we don’t, we’re open to that. That’s not a problem. Okay.

Mike: Got it. Are there any limitations to the proof of concept? Is it just two sites or is it their whole network?

Jack: Yeah, great question. Two sites. We like to do 2Mbps. We can go up to 10Mbs for the two sites. We can add a third so long as it’s a cloud service. So, let’s say Office 365 or, you know, something out there, right? An ERP application that’s hosted in the cloud. So, we can bring up a third in that case.

What we also do is there’s a time limit from the moment… Now, remember it takes about, maybe, a week to get us up and running. Once the customer throws traffic on our network, the customer gets ten working days to test it out. Because, remember, before our equipment arrives, we expect that baseline testing be done, then traffic is thrown on to Aryaka, and then they retest, and they’re done. I mean, in reality, they need three days, but we will give them up to two weeks. At the end of two weeks, if we meet their success criteria, what they’re expecting, they’re a customer – and we’re looking forward to that.

So, one thing as far as our POC that we’re not, and this is, kind of, important – I know that people get to evaluate equipment from everywhere, from all these different vendors. We’re not just a vendor. We actually provision our core for the customer, actually using and spending our own money for their POC. So, while it’s free for them, it’s not free for us, which is why we limit the time. So, we appreciate those that definitely we’re getting this done in two weeks and we definitely get it done in two weeks. Okay?

Mike: That makes sense. I think that’s fair. It’s like you hear “free proof of concept,” your first thought is “awesome,” but then, obviously, there are going to be some stipulations in there. You guys can’t deploy a fifty-location network for free.

Jack: Exactly.

Mike: Yeah, for an unlimited amount of time. I think that’s awesome. I think that, hey, not a lot of providers do that. I’m not used to providers ever offering any type of free trial or anything like that. So, that’s great. I think you guys are breaking some new ground there, and I think that’s very valuable to anybody listening to know that they can try it a little bit, you know, dip their toe in the water to make sure it works as they thought it would. So, that’s awesome.

Well, great. I think that wraps it up. Thanks for joining us, Jack. I really appreciate you taking the time, and that were some really valuable information on SD-WAN that I think our listeners would definitely benefit from. Thanks, again.

Jack: Thank you, Mike. It’s been a real pleasure. Thanks a lot.

Mike: Man, Jack really knows his stuff, doesn’t he? It’s great to talk to somebody who’s working for a company who’s been doing SD-WAN for a long time since that’s, kind of, such a new buzzword. A lot of companies are just now rolling out an SD-WAN product, so it’s cool to talk to someone who works for a company that’s been doing it for a long time. So, I really appreciate him coming on the show and I hope you enjoyed it as much as I did.

Just one more, quick reminder: If you wanted to get the free SD-WAN comparison chart comparing SD-WAN to MPLS, point-to-point, and IPSEC VPN, comparing all the different capabilities of each, different technology, just text the word “WANGUIDE” to the number 44-222. Again, just text the word “WANGUIDE” to 44-222 and receive a free softcopy cheat sheet of our WAN comparison chart comparing SD-WAN to all the other WAN technologies.

So, that’s it. Have a great day and catch you next time.