Cloud Transformation for SaaS and IaaS
Traditional WAN network infrastructure is breaking the adoption of SaaS and IaaS. Connecting users of an enterprise to application and infrastructure in the cloud requires many transformational changes. For one, the network itself needs to be cloud aware. Next, there needs to be unified management capability for both cloud and on-prem applications. Last, there needs to be a dynamic management of application experience based on realtime network unreliabilities.
- SaaS / IaaS Challenges (ie. Quality of Experience, Onboarding Workflows, Scale, Security)
- Network Transformation and the Cloud onRamp Solution
- Benefits for IaaS (ie. Single Solution, Branch to Cloud Connectivity including AWS and Azure)
- Benefits for SaaS (ie. Improved Experience, Visibility for Office365, Salesforce, Dropbox and more)
- Use Cases and Case Studies
Ariful has 11+ years of experience spanning product management, sales, network architecture, service provider networks and operations. He has managed a number of product offerings in the MX routing platform and helped secure opportunities with large Content Providers, Public Cloud Providers, Cable MSOs and Service Providers across North America, Asia and Europe.
Cloud Transformation for SaaS and IaaS
[Start of recorded material at 0:00:00]
Ariful: Good morning, everybody. Good morning, good afternoon, good evening, perhaps if you’re in different geographies. My name is Ariful Huq. I’m in the Viptela product management team. And I’ll be presenting about Cloud transformation for Software as a Service and Infrastructure as a Service. So we will just give folks a couple of more minutes to join. So probably get started in about two minutes from now. So we’ll give folks a bit more time to join the…
Ariful: Okay. So let’s get started with the presentation. Again, my name is Ariful Huq. I’m in the Viptela product management team. And what we’ll be talking about today is product transformation for Software as a Service and Infrastructure as a Service. And we will highlight to you some very interesting announcements that we made recently, enhancements to our product that allow our customers to adopt Cloud based services.
So what we’ll do, just the first couple of slides, is to introduce a little bit of the Viptela products. Everybody’s on the same page. Viptela as a solution, we are an SUN vendor. Our value proposition is, and what you can really see from this slide is, the fact that we’re connecting users in the branch, whether it’s users’ devices, things to applications in the Cloud. And we do this over the Viptela fabric technology. The next slide will cover a bit more detail there. The solution is Cloud delivered, so essentially you have controllers in a public Cloud environment or an [unintelligible 0:02:51] environment. And you have other software service things like analytics that we offer as well.
On top of this Viptela fabric architecture we have multiple use cases. SUN is one of them. But what we’re really going to focus on today is access to Cloud and what we’re calling Cloud onRamp. The idea really is to connect users to applications, wherever they be, whether it’s in their data center on in a public Cloud environment.
So to briefly highlight a little bit of the solutions, and build this slide out, so there’s really three layers to the solution. There’s a data plane, which is the physical or virtual elements. So you can purchase CPEs from us, physical, or you can even get VMs. So you can instantiate the software on any platform that you have. In the Cloud based, Cloud delivered model, we have a control plane that is essentially VM-ed, that reside in a public Cloud environment or in a private data center.
The control plane essentially builds the connectivity between all the elements, that we’ve built secure connectivity across all the elements in the network, and we actually use IPSec for this. But our technology does not use the traditional [unintelligible] based IPSec. We’ve actually come up with a centralized controller based IPSec technology. On top of that you have a management plane, which is multi-tenant, or dedicated, so this can be a multi-tenant solution. Perhaps if you’re a managed service provider, or it can be a dedicated solution for an enterprise that’s consuming this type of a solution.
And the management plane really is your single pane of glass into the entire solution. It is what you use to configure, manage, get visibility into the entire network. Right? And the physical elements, they can use any type of transport. So you can use Internet, MPLS, or even 3G4GLP as well. The focus of the presentation today is actually going to be the virtual element, because that’s one of the focuses for connectivity. We’ll also focus on the branch element for connectivity into Cloud.
Okay. So let’s start by actually highlighting some of the challenges when a customer goes to consumer Cloud based services. So one of the thing is if you’re moving to, say, Office 365 or Sales Force or other types of Cloud based Software as a Service applications, if you are a customer that has been hosting some of these applications on [Prim 0:05:55], the question you might ask is what is my user experience going to be when I’m [unintelligible] public Cloud or other SaaS based applications. Is it going to – perhaps other issues with moving from a user experience perspective.
And this is a natural question to ask, because in some instances I could have my data centers in specific locations and my branches perhaps all over the country. So let’s take the example of North America. You may have branches in the West Coast but your data center is in the East Coast. And your Internet exit point is only from the data center. So now you have this problem of traffic tromboning through the data center, trying to access SaaS based services. You might actually have reduced user experience as a result of that.
But in the other hand, if you actually start doing things like direct Internet access, so essentially you are doing a split tunnel from your branch going out to the Cloud, then you need visibility. You need to figure out how to manage the split tunnel. You just don’t want to spray the packet to a SaaS based service and [unintelligible 0:07:03] gets that, right? That’s what we call a spray and pray problem. So these are some of the challenges from a user experience perspective.
Then there’s a question around branch to Cloud connectivity. When we talk to customers, they’re adopting Infrastructure as a Service. So if you’re going to adopt AWS or Azure as a public Cloud service, the typical answer we get is, it is an extension of the – it is an extension of your existing data center. So that is actually not a very good way of doing branch to Cloud connectivity. Again, it’s because you are essentially connecting users through the data center and then going out to your public Cloud. That is not an effective way of connecting your users.
And then if you have multiple exit points in our network, so for instance if you’ve decided to actually use direct Internet access, perhaps a Colo based connectivity model, in some cases some of our customers actually host their equipment in co-location facilities [unintelligible 0:08:19] some call it, to connect to Internet from there. Or you’re doing through a data center. How do you choose between these exit points to connect to your Cloud based service? That’s another challenge that our customers are faced today.
Resiliency. So if you have multiple transports in your network and you have multiple ways to get to your Cloud based service. How do you remediate brown out situations? So you have to be able to monitor that Cloud based service. So that is a challenge that we see as well. And then security. So if you’re doing direct Internet access, so you need to protect your branch users and the branch router.
So security needs to be inherent to the solution. If you’re adopting infrastructure service, how do you isolate your workload? So the instances that you instantiate in Azure or AWS, can you isolate specific units so they have access to specific instances in your public Cloud? That’s a question as well. And finally, the operational model. So if you were adopting public Cloud services, what we’ve seen today is customers want to do multi-Cloud deployments.
So they don’t want to just rely on a single public Cloud provider, either at AWS or Azure. They want you to do multiple. For resiliency or specific applications they may have, may work better on one specific Cloud vs. another. So consistency of deployment across multi-Cloud, right? Policy management across a branching Cloud. If you have a way to get to your Cloud based service, and perhaps you’re instantiating a virtual device in your Cloud, to get connectivity, how do you do policy management such that whatever policy you apply in your branch applies to your Cloud based service as well?
So that’s the challenge. And Brownfield Integration. So Brownfield Integration is the fact that if you have existing, you know, Infrastructure as a Service instances today, whatever solution you adopt, you need to be able to integrate very well into your existing environment. You don’t want to make changes to existing infrastructure services instances just to adopt a solution. So the integration needs to be very seamless. The Brownfield is another challenge.
So what are some of the things that you want to consider, or requirements for our Cloud read WAN. We think Cloud connectivity consumable through a single pane. Essentially whether it is infrastructure as a service or [unintelligible 0:11:06] offers the service, the connectivity, how you get there, how you build those connection, the monitoring and visibility needs to be through a single pane. And we believe as an SUN vendor that is something that we can actually offer.
Visibility into Cloud application performance across your WAN. So if you are adopting Software as a Service like Office 365 or sales force, and you would like to understand what is my loss latency and jitter towards Office 365 and sales force across my branches, I would like to understand that. So I can remediate any issues. That is visibility that you need to be able to get. Scalable transport independent any-to-any connectivity.
So if you want to do direct branch to Cloud, you need an any-to-any connectivity model, and what we mean by that is, your branches need to be able to connect directly to your Cloud, your infrastructure service instances, as opposed to going through a data center. And you need to be able to do this in a scalable fashion. Because you may have hundreds or thousands of branches.
Dynamic path resiliency for fault tolerance. So if you have multiple transport links and perhaps one of those transports is having a brown out situation. How do you remediate those types of scenarios? So path resiliency is a very important consideration. So what we’re focusing, what we’re going to focus on today is the Viptela Cloud onRamp solution and the benefits to this approach. So we’ve come up with a suite of capabilities to make Cloud consumption much easier for our customers. And so what I’m going to do is explain to you some of these capabilities.
Right now I’m actually going to announce some polls. So let’s take the first poll, which will be coming up right now, and the first poll has to do with do you have multiple Internet exit points you use today for access to Software as a Service? So I’m going to put that poll up. And we’re going to start gathering the data, but at the same time I’ll just continue with the slide and then we’ll stop and get your feedback.
So what are we doing to actually make Cloud connectivity much easier for our customers? So essentially what we have come up with is a suite of functionality, consumable through our management platform, what we call vManage. So if you’re a Viptela customer, if you’re looking into it, we have a management platform that we use as a highlighting to configure managing visibility into the entire network. What we want to do is use that platform as a way get information from you and do the right things in our network to build the right connections into Cloud based services.
So it’s a single pane for you to go and consumer this service. That’s number one. Number one, SaaS application performance visibility across all your branches. So we have the ability to essentially determine from your branch locations or your Internet exit points what is my loss latency and jitter to top 20 SaaS applications. And you can choose them. You can say, I’d like to monitor Office 365 sales forces and other applications that I’m very interesting in. And so we give you that visibility. We will actually send probes and determine what is the loss latency and jitter for those applications. And then we will expose all of this information to you through what we call a Viptela Quality of Experience score.
So this provides visibility into the application performance in a network and the probes that we’re sending, these are real time, right. So we’re sending these periodically, gathering the information and exposing them to you through a dashboard. And I’ll give you a preview of that dashboard.
Then we have a Cloud onRamp for SaaS Gateways. So essentially this means you designate points in your network. It could be your branch router, so if you decide to do direct Internet access, your branch router becomes the Gateway. Or if you decide to use a remote data center or a remote Internet exit point, those become your Software as a Service gateways. It’s important to designate these because these are the points from which we will monitor the performance to your SaaS application and we will also influence routing through these exit points.
And we’ll talk about more details in the next slide. And then we have a vManage Cloud onRamp for SaaS app. I’d like to show you this dashboard in the upcoming slide. Again, it’s just a single pane of glass for you to get visibility into application performance. So I’m going to – we’re going to close the first poll and get some of the data for this. Okay. So it’s looks like the answer for the first question was 100 percent. Everybody has multiple Internet exit pints for SaaS.
So as you can imagine, if you have multiple Internet exit points, you need to be able to determine performance towards your SaaS application across those exit points. So let’s take a look at how this solution actually works and how this is going to be beneficial for you. So what we’re essentially doing is we use probes which http-pinged, actually. So our devices are branch devices or Internet exit points which could be, you know, at your data center or in regional Colo facilities. From those locations we’re actually http-pings to your SaaS application that you’re interested in.
And we’re gathering that data and we’re exposing that to what we call the Viptela Quality of Experience Score. And we use that information to essential influence routings. So let’s take this example. So I have a branch with a local DMZ and I have an alternate path through my regional Internet exit point. So these green dotted lines indicate the probes that I’m actually sending to the Cloud based service. So I’m gathering that information. And if I have a situation where my local Internet carrier has a brown out situation or perhaps they have some sort of issue pairing with the Internet or with the specific SaaS provider, you’re going to have degraded performance.
What happens today is, you only this once users actually start complaining. They start saying, hey, there’s some shoes connected to [unintelligible 0:18:22] fast service. It’s probably because the path that you’ve chosen is not the most optimal path to get to that SaaS service at that point. Right? So with this type of a solution, what we will do is we will define SLA metrics. We will say for specific applications what is the loss latency and jitter tolerance. And if the SLA metric is violated, we will then choose the next best path.
So in this example, if the local branch has a brown out situation with the local Internet carrier, we’ll use an alternate path through the regional Internet exit points. So really in summary, you have just remediated an issue in your network that your branch users are not complaining about it, because there’s a brown out situation but you’ve been able to figure out an alternative path through your network to get to your SaaS based service. So that’s at a high level, what this solution is.
So this is a dashboard that we actually expose through our vManage platform. So if you look into this dashboard, I’ve taken about 13 applications here, you know, it doesn’t have to be all 13 applications, [use 0:19:39] any specific application that you’re interested in. And what we’re essentially doing is, we’re monitoring these applications from all these branches. So you’ll actually see in – there’s these bars and you’ll see the numbers on the side. The numbers on the side indicate, so for instance, let’s take the first application.
The number will actually indicate how many of those applications are meeting the SLA metrics for that application. If the bar is all green, it means great, all my sites are doing that. What is this red? Perhaps I have an issue. Some of my sites actually have an issue of getting to that SaaS application. So now I have visibility into the problem and I can try and remediate the situation. In our case we’re able to automatically remediate this type of situation where if you have poor performance, I can go in, we can go in and change those paths automatically.
All right. So that’s the stats portion of the Cloud onRamp product. So now we’re actually going to start talking about Infrastructure as a Service and what we’re doing in this space. So prior, before that, I’m going to put up a poll question here. The second question is, is your primary mechanism to reach public Cloud through your data center? So that’s the second pull, and it’s about to come up, so again, we’ll gather some of that data and we’ll come back to that poll in a bit.
All right. So Cloud onRamp for Infrastructure as a Service. So essentially this is how do you get to Amazon or Azure. Right? Today a lot of our customers, what they end up doing is, they build [IPSEC 0:21:28] tunnels from their data center into a public Cloud service, right? So they essentially in the case of Amazon, you might have heard of something called a VPN Gateway. And you build your IPSEC tunnel into that VPN Gateway and that is your mechanism to access that Cloud based service.
Now, again, as I highlighted before, the problem with this [unintelligible 0:21:48] approach is your traffic from the branch going to the Cloud is going through your data center. Imagine if you’re doing some sort of analytics based service where you’re streaming a lot of data, perhaps video, to a data leg that’s residing in Amazon. The sub-optimal path that you’re taking essentially from your branch, going through your data center, into the Cloud, the data center could actually be a bottleneck in that case. Right?
Or perhaps your branch is in a location that is not very close to your data center. And again, it becomes an issue. The direct branch of Cloud connectivity is a better mechanism. So what are we doing here? We’re essentially utilizing vEdge Cloud router, so our vEdge CPE as a virtualized solution, it’s available in the public Cloud marketplaces, so in Amazon or Azure. So we instantiate an instance of our vEdge Cloud in your public Cloud account, right? And we will talk about the details of how we do this. And we have a vManage Cloud onRamp for IS applications, essentially this application is what you use to go and configure, manage, instantiate, we will do this automatically so we actually make API calls into Amazon and Azure to take care of the instantiation of the vEdge Cloud instances.
So again, the entire solution is consumable through the vManage the Cloud onRamp for IS applications, essentially application is what you use to go and configure, manage, instantiate. We will do this automatically so we actually API calls into Amazon and Azure to take care of the instantiation of the vEdge Cloud instances.
So again, the entire solution is consumable through the vManage platform. So I’m going to close the second poll here and get some of these results. Okay, so it looks like the response to the previous question was, is your [unintelligible 0:23:43] of the Cloud through your data center? And 50 percent of you said yes, and the other 50 percent said no. All right, so that means essentially you could be using Internet based as well connect. So, which is great. This is actually part of our solution as well.
So let’s take kind of a workflow of how this actually, this solution would actually work. So you have the vManage platform, and you’re using it today to connect your branch and data centers together through the Viptela solution. Now, the natural questions becomes how do I use this to connect my branch and my data centers to my public Cloud service? So essentially what you do in the vManage platform is you put in – there’s going to be sort of an application or an area for you to go in and put in public Cloud credentials. So you will put in your, for instance, in the case of [unintelligible 0:24:37] yes. You’ll put in your IEM credentials, or your API keys.
Essentially what this allows us to do is go and pull your account to discover things like your virtual private Cloud instances, or your virtual networks. Right? So we will then go and discover your virtual private Cloud instances, or your infrastructure services instances, within your account for a specific region. Once we have discovered that information, we will allow you to say, okay, I would like to operate on the specific Infrastructure as a Service instances, I would like to in short, to connect these ones to my overlay network.
So once you’ve made the selection, we will ask some information as far as the vEdge instances that are being instantiated. So we will ask things like, okay, what is the bandwidth that you would like? So essentially this is going to be how much traffic you actually need to exit out of that specific region or out of that specific EPC. And we will also ask you what are the VPN segments you would like your Infrastructure as a Service instances to have access to.
So if you are an enterprise, you have specific VPN segments that are on your entire network. Through the Viptela Solution, we actually are able to segment the entire network through these VPNs. Perhaps you have multiple VPC instance, so one could be for finance, one could be for your HR. And you have different VPN segments within your network, right? You have finance VPN segment is different from your HR VPN segment. You also are completely isolated.
So you want to insure that your finance part of your company only has access to the VPCs that have the applications for finance. The HR should only have access to VPCs that belong to HR. You want to completely isolate those. So we allow you to map the VPCs into specific VPN segments within network. Once we have that information, what the vManage platform does is it actually invokes APIs into the public Cloud provider, and it actually sets the vEdge Cloud instances. It actually connects your Infrastructure as a Service instances to your vEdge Cloud instance, and it provisions that vEdge Cloud instance, insures the [VBAN 0:27:13] segments are revisioned correctly and it belongs to the overlay, your Viptela overlay.
So it is a very turnkey solution. All we need is specific information from you and we are doing the rest. You don’t have to go in and create VPC instances, create these connections, and manage those connections. We are taking care of that for you. And moving forward, as you add more infrastructure to service instances, all you need to do is go into the vManage Cloud onRamp app and you can go and discover new instances and then you can map those instances to VPN segments within your network. Right. So once this is set up, you can make use of it, like you might, you keep discovering new instances, and you keep mapping.
Okay, so this is a preview of the dashboard that we will actually have, so we are actually going to demonstrate this capability in a couple of months from now. So once we have that demonstration, it will actually be a live demonstration. But right now I’m just showing you a dashboard. So think of the left most picture essentially a multi Cloud dashboard, you have multiple regions within AWS, specific region within Azure.
You have a single dashboard where you’re getting information as far as how many of these instances do I have connected, are there any issues as far as connectivity? How many of these vEdge instances do I have launched in these public Cloud [unintelligible 0:28:44] providers? Do I have any issues with those vEdge instances? Is there a failure? Perhaps I need to go in and check things out if there is an issue with connectivity. So think of this as a single dashboard for you to go in, determine what’s going on as far as your Cloud connectivity, gives a very turnkey solution to go in and troubleshoot.
So to dive into this a little bit, because I realize there may be a lot of questions [unintelligible 0:29:13] so how exactly are you doing all of this for Infrastructure as a Service? So really the model we’ve chosen, and some of you who have worked, I’m taking the specific example of Amazon Web Services here. If you worked with Amazon Web Services, if you are, you know, building these connections, perhaps you’ve looked into a model that they have proposed recently called a Transit VPC. We’ve actually taken a very similar approach here. So what I’m highlighting here is sort of the architecture.
So think of host VPCs as where your applications reside, right? So you could have multiple availability zones, where your application’s residing. It’s all done in a redundant fashion, right? So we are not going to touch those host VPCs. These are your instances. This is what I mean by this great for Brownfield deployment.
We don’t have to go in and change new routing tables within your EPC instances. We don’t have to make sure specific subnets are allocated or if you need to make new changes, now you have re-instantiate a new VPC, none of that, right? Which is very good Brownfield integration. You have existing instances. You just need a better way to connect those instances into your existing enterprise overlay. That’s the problem we want to solve.
So that’s the whole CPC. Then we have the vManage instantiated Gateway VPC. So this Gateway VPC, the goal is to have one per region. It really depends on you though. You could have multiple per region, but the idea is, it’s a shared resource. You want to be able to share this Gateway VPC across multiple host VPCs in a specific AWS region, right? So you don’t have to instantiate a vEdge or a VM into every single one of your host VPCs, you can just instantiate it. A couple of these and those are going to be your Gateways to Internet and back [unintelligible 0:31:12] location.
Really, this is your data center Gateway sitting in the Cloud, right? So we instantiate the Gateway VPCs. We take care of the fact that these are instantiated in a redundant fashion, and we actually take care of building point to point tunnels from the vEdge Gateway to a VPN Gateway that’s attached to your host VPC. So the only way to build connectivity, or think of an overlay within Amazon, is actually to build IPSec tunnels.
So what we do is essential use [IKE 0:31:49] vEdge Gateway and the VPN Gateway. We actually BGP on top of that as well, and many benefits to that. I’ll just highly that in the upcoming [unintelligible]. So what are the architectural advantages to this approach? You can share transport so you have a Gateway VPC where you can have attached a direct connect that’s coming in to your MPLS carrier. You have an Internet that you can share across all your host VPCs in the specific region.
So really the fact that you can share is an aggregation point. That’s a pretty big advantage. I highlighted this before. You can share one Gateway VPC across all your host VPCs in the region. Then you can leverage all the redundancy for AWS components. So the VGW that we’re highlighting here, that is an AWS component and you just rely on the redundancy that they offer, and did you offer [unintelligible 0:32:44] you’re using the Internet Gateway to get out. That is also a redundant component.
The VPC router that exists within the host VPC, that is also a redundant component. You’re leveraging all of the redundant components within AWS, so for us instantiating a third party [appliance] has no impact to that. So, and we are instantiating to vEdge Gateway, so that is our way of making this a redundant solution. You’re utilizing Dynamic Routing. So between the vEdge Gateway and you’re VPN Gateway, you have a VGP session. So you’re discovering your VPC route table dynamically and advertising that information to the rest of your network.
That is a huge benefit, right? Even from, the VPC route table has a view into the rest of your network. So perhaps one of your paths is not the optimal path or one of your branches is not available. Were you able to detect those sorts of things? And perhaps one of your vEdge Gateways failed. We will detect. The VPN Gateway will realize the [unintelligible 0:33:51] session is down, so it will use the backup path. This is inherent redundancy. And we have some customers we’ve been talked to with the solution.
And one of the things I’ve expressed is, hey, what if I need to put in a firewall, what if I need to have some security posture within this Gateway VPC. That is entirely possible. You can instantiate a firewall, whichever firewall is of your choice. You can put that in the Gateway VPC and you can attach it to the VS Gateway and insure that any traffic that’s leaving your specific region goes through that firewall and then actually it goes out to the Internet. So there is that mechanism for you to insure there is security compliance as well.
All right, so I think we have one more slide and I’m going to post the last question here. And the last question is, do you think direct branch to Cloud connectivity will be beneficial for you? So really all of the things that we’ve talked about, is this valuable to you, is this something that would be interesting? So that’s the poll question. All right.
So we conclude on the Infrastructure as a Service benefits and I’m just going to build this slide out. So we’re doing direct branch to Cloud connectivity. It’s a homogenous solution across branch to Cloud. So policy management across all the branches becomes easy. So you – whatever policies you’re implementing at the branch is exactly the same policy you’re going to implement in the Cloud. Because you have the same solution between branch to Cloud and with our controller based architecture. You push that policy once, it gets enforced across multiple endpoints.
Again, you have resilient access [unintelligible 0:35:43] public Cloud provider. You can make use of multiple transports if you are a customer that has multiple connections, like Direct Connect and [INET]. You can make use of that. And you can do application steering. You can say my specific application leaving this region, I would like that specific application to always take MPLS, because it is a jitter – it needs lower, it has jitter tolerance that I need to consider. I need lower latency for that specific application.
You can make those types of decision to policies that you define on the vEdge endpoint that’s residing in your public Cloud instance. And finally, this is a multi-Cloud solution. Right. Because we’re building overlays across all these endpoints, really to us, we’re just connecting all your endpoints together, right? So it’s not just a multi-Cloud. It’s actually a multi-regent solution. So even if it’s a specific Cloud provider, one of the problem statements that we see is, how do I connect all my regents together? I’ve got US West, I’ve got US East, Central, how do I connect my VPC instances across all of these regents together?
So again, this solution is very, very beneficial in that respect as well. And the multi-Cloud aspect really means I could have AWS as your Google Cloud anywhere my application is residing, I can put in these VEdge Cloud instance and connect automatically into my Viptela fabric. So that’s the last slide, and we’re going to pause, we’re going to close that last poll.
And so really the answer to, you know, most of you, do you think direct branch to Cloud connectivity would be beneficial for you, so yes, so certainly I think this is, what we’ve just talked about today is beneficial to you. So reach out to us, and we’ll certainly be happy to do demonstrations, answer questions, and call up in more detail.
So there’s some questions here. How secure IPSec that you have come with? So just to highlight that a little bit, so what we do is, on the – to split this into data plane and control plane. On the data side we use, it’s actually standard ESP over UDP based encapsulation. We use ES256 GCM as our encapsulation mechanism. So that is probably one of the most secure ways to do that today. As far as the control plane, the control plane is actually unique in the respect that we don’t use [IKE 0:38:25], but what we actually do is actually we use a certificate based authentication mechanism that authenticates the vEdge to its controller mutually and we do this over a [unintelligible] tunnel.
So again, the control plane is established [unintelligible 0:38:38] tunnel, so again, it’s a very secure solution. So happy to reach out and we can talk about this in a lot more detail. How long does it take to [fail over] to the alternate path? So the [fail over] time is really dependent on the SLA metric that you’ve defined. But at the same time, you don’t want this to be too aggressive, right? So what we’re seeing is, customers do, defined these such that fail overs happen for instance for SaaS. So take this specific example of SaaS.
So if you’ve got a branch device that has direct Internet access and has connectivity through another remote data center or co-location facility. Now, if you have a brown out situation, in a specific location, most of our customers opt for something around the time of five minutes. But again, it’s up to you. You can define some of these time intervals and at the same time you don’t want to it to be aggressive because you don’t want traffic to flip-flopping between these things, right?
So you don’t want to be too aggressive, but again, most of our customers have chosen between five and 10 minutes for these. It also allows us to get enough data to make sure that, yes, there is actually something wrong. Now if you have a situation where the link is entirely gone, so for instance your carrier has 100 percent loss, then yes, your traffic is going to shift over immediately, right?
So that is something that we’ll take care of. But if you have a brown out situation, it’s typically within that five to 10 minute interval. Does Office 365 get accelerated? So we’re not accelerating traffic. That is not the value proposition for the solution. What we’re really doing is giving you visibility into performance and remediating issues in your network. That’s our value proposition. We want to make sure that we’re able to remediate failures. So, and preserve you, your experience, right? So we’re not trying to accelerate any sort of performance here. So that’s – so I think that is – if you have any more questions, you can keep them coming in. Okay.
So I think that’s pretty much what we have. Maybe a couple more questions if folks have them. If not, yeah, you know, I’d like to thank you for taking the time to join our presentation today. I hope you found this valuable. We’ll certainly make the slides available. Again, reach out to us. If you have any questions, if you’d like to learn more about the Viptela solution, about what we’re doing with the Cloud onRamp suite of application – suite of capabilities, happy to go through them in a lot more detail. Thanks, folks.
[End of recorded material at 0:41:43]