5.5 Cisco SD WAN Cloud onRamp for IaaS, P 1 Overview and Operation with Amazon Web Services AWS and

[Music] hello my name is David Clemen F I am a leader in Cisco Sdn technical marketing organization and today we're going to talk about cloud specifically we're going to talk about the cloud on-ramp for an infrastructure as a service so cloud plays a very pivotal role in Cisco as 2n this is the place where most of our customers host their infrastructure elements the controllers the V bond the V manage the V smart so cloud is important but in this particular presentation we're going to look at a different angle of a cloud is how the sd1 fabric is easily extended to the cloud to include those cloud resources in the Sdn fabric that a customer has so let's take a look traditionally when we're looking at how cloud technologies were adopted and specifically we're talking about the popular infrastructure as a service clouds such as the Amazon Web Services and the Microsoft Azure those are predominant to infrastructure as a service cloud services that we see customers are M are using the most right so inside those clouds AWS has a concept which is called V PC and AWS and Microsoft Azure has the concept called V net these think about those as the containers where the actual hosts the actual VMs reside in a traditional wide area networks that consist of remote offices campuses that require connectivity into those cloud resources the connectivity is mostly a provision from the data center through the use of tunnels so what are those tunnels those are traditionally IPSec tunnels that get stretched from the data center into those infrastructure as a service cloud environments what's wrong with this first of all the connectivity between the remote offices and the campuses has to back hole through the data centers in order to get to either AWS or Microsoft Azure it introduces a high degree of latency for those critical applications that may be hosted inside those public cloud environments it also lacks the advantages of the wide area network in regard to security in regard to segmentation in regard to providing better application quality of experience so all of those things that you may have inside the wide area network are actually not present and are not extended to those infrastructure-as-a-service clouds because these are just standard IPSec connections that have no further intelligence so you get connectivity you get back hold connectivity through the data center but nothing more what are we after how do we provide direct cloud access from the branch offices so we what we want to make sure is that we have a direct connectivity from the remote site that goes straight into the AWS environment or go straight into the Microsoft Azure environment without passing through the data center that will eliminate the latency that would have been incurred if the traffic was going through the data center so we're definitely after how to provide this direct access we're also after how do we provide security features segmentation features quality of service reliability all of those things that are important for applications that are hosted within the data center we want to make sure that the same set of features and the same set of advantages are extended to those applications that are now hosted inside those public cloud environments so how do we go about that Cisco sd1 has a set of features instead of functionalities that we call a cloud a cloud on-ramp it's a set of functionalities it's not a single functionality it's a set of functionalities that combined together provide a solution of extending the Sdn fabric to those infrastructure-as-a-service environments so let's take a look first at AWS as you're going to see in a subsequent slide the logic behind performing this cloud on RAM for Microsoft Azure environment is exactly the same so let's take a step by step approach and see what actually happens under the hood the first thing we start with is we have the host V pcs those are the existing containers that we mentioned in the beginning the existing containers that's where the existing virtual machines are inside the AWS environment so this is our starting point because this would have already existed in the customer environment before we ever even rolled out an SD one fabric as general or before we configured any cloud M on-ramp features so this is our starting this is the day 0 status where we have this AWS environment and in this case we're looking at a specific region where the person has multiple regions that it can be deployed at but AWS region here and multiple host V pcs you may have multiple availability zones within the within the host VPC these are all the internal workings of the M of the AWS environment so what we want to do is we want to make sure that we now have this sd1 fabric that exists somewhere in here and we want to make sure that we connect into those host V pcs from the branch that is what we're trying to achieve everything starts with we manage we manage is a single pane of glass for all the operational tasks that we perform against the sd1 fabric cloud on RAM is not an exception it is a highly automated feature and it all starts with v manager so V manage is the customer Erica is if is a system is a system element that manages the customer sd1 environment login it into the V manage we can launch a configuration wizard for the cloud on-ramp and as I mentioned it's a highly automated feature later on in the presentation we're actually going to go through the steps that are required to configure this feature but you're going to see that it's highly automated we are logging in into the V manage and we are launching this configuration wizard in order to make the cloud on-ramp settings in place now as the wizard is running and it's as I said highly automated what is actually happening under the hood so what's happening under the hood is V managed initiates a connection into the AWS and it uses api's to take over the configuration in a specific account or in multiple accounts that exists in AWS so think about this as having an account details to log in into the AWS account or multiple accounts and provide through API calls this entire set up so what is being set up so the first thing that is being set up is what we call a gay two V PC so think about a gateway V PC as a representation of a customer Sdn network inside the AWS region what gets put inside is the when edge in our particular case it may be VH cloud the script the wizard takes one from the marketplace so both of those are actually taken from the marketplace they're taken from the marketplace and they're put inside this new entity this new VPC that we are calling the gay to VPC they're put inside to for redundancy different availability zones for redundancy what happens next we are instantiating what is called a V G W stands for VPN gateway it's an element it's a VPN termination in IPSec VPN termination element that is inherent to the AWS we are spinning it up for every host V PC that we are trying to connect into the sd1 fabric so in this particular case you see that we have two hosts v pcs we're spinning up to VG W's in addition to that we are stretching this links in here in a fully redundant fashion what are those links these are standard based IPSec connections as you know Cisco Sdn leverages IPSec technology for tunneling between different SD websites in this particular case this is not the SD when IPSec tunnel this is the standards-based ike based IPSec tunnel each one of those links represents two tunnels why to redundancy so as you can see redundancy is taken taken very seriously here you have to one edge devices in the gate with EPC for redundancy you have them in separate availability zones for redundancy you have full mesh connectivity between those when edge and the VPN gateway for redundancy and each one of those is a redundant IPSec connection so really taken an extra step to make sure that we eliminate any single point of failure in this particular setup so we have the standards-based IPSec x 2 between every V edge between every when edge router inside the gate to V PC and the vgw that gets spun up in the host V PC that is the underlying connectivity what do we do next we need to run routing in order to advertise the prefixes that exist in the host V pcs in to the rest of the sd1 fabric so think about the host V PC as having a cider block that block can be something like 10.10 / 24 for one of them and 10.10 dot dot 0 / 24 for the second one we need to make sure that those are advertised into the sd1 fabric for reach ability through the Sdn fabric into those resources for that reach ability we have BGP running between the vgw and the when edge devices so later on we're going to see how that actually looks like but for now just keep in mind bgp over all of this redundant infrastructure to make sure that we are advertising the reach ability or between the host v pcs and the the rest of the the sd1 fabric as I mentioned in order to inject this information into the sd1 fabric we are leveraging BGP to OMP redistribution think about OMP as a smart overlay management and overlay routing protocol that can send around and distribute routing information across the entire fabric so we have a BGP protocol that runs here between the host V pcs and the wedge and then we have the OMP protocol that runs here between the when edge and the V smart controllers this injection of a BGP information this 10-10-10 slash 24 and 10 10 11 / 24 that is what this is for injection of a BGP learned information into the OMP so the question why are we not doing it the other way we could but in order to simplify this setup in because all of this host PPC's pretty much have the only way out is through this one edge instead of doing the redistribution of OMP into BGP and potentially having a lot of routing State inside this vgw we are actually just advertising through bgp a default route this default route is sufficient in order for these hosts inside the host VPC to get access outside and from the host PPC to the when edge and then potentially to another host EPC or to the resources that are in the sd1 fabric so as you see bgp 200 MP and default route that is advertised into the BGP to draw the traffic from the host he pieces into the one edge the gray area you see here this is the sd1 fabric what you can see now is my sd1 fabric now had been extended all the way from my branch offices from my campuses from my home offices all of that has been directly extended into my AWS environment and as you know Sdn provides direct connectivity between all of the entities connected within the sd1 fabric and now what we have is this direct connectivity is now extended between those Sdn locations and the hosts VP sees through the gate VPC gay to the PC as we mentioned this is the representation of a customer's network within the AWS environment so the actual flow of communication between let's say a user trying to consume the resources in the age of the u.s. there would go to their branch sd1 edge device go over the sd1 fabric into the one edge one of the wane edges because both of them will be advertising the same information so we can have equal cost multi passing so we will end up with either one of them and per flow hashing we'll make sure that we're using both of them and from here write the standard based IPSec tunnel to the vgw at the destination host VPC and hit the actual resource so as you can see straight-line connectivity which is exactly one of those issues that we we were after to address to make sure that we eliminate the latencies of hopping between the data center and then going into the into the AWS environment so really achieve that straight connectivity between between the remote patience and the and the AWS environment in this case so what else did we achieve fully-automated so the logic that we had outlined before is fully automated in a in the V managed through wizard everything we had before the IPSec tunnels the BGP routing the the redundancy of the connections all of that is fully done by the wizard obviously once the VA once the when edge routers come online they are automatically joined into the sto and fabric and that's just the operation of the estaban fabric it has nothing really to do with the wizard itself but it's just the zero touch approach of the of the fabric itself so fully automated it also greatly simplifies the brownfield integration why is that because as you can see we did nothing to the host V pcs we didn't have to re I P them re address them we had to spin up the vgw which is an element there is a non-intrusive to the workloads that existed inside those host V pcs inside those resources that already would have been resident in AWS before we ever started the cloud on-ramp flow so really simplifies the brownfield because of the no changes that are required to the host T pcs now since the fabric since this is an ST when fabric now we now inherit all of the advantages of Cisco Sdn in this particular setup so particularly we have the multi passing through both of the when edge routers end through the redundant IPSec connections that go between the when edge and into the host T pcs we have segmentation capabilities we have quality of service capabilities I can add here I have an app aware routing capabilities to choose the best worming path towards the AWS environment and which one of the when edge devices which one of the transports that are connected to this when edge devices are actually performing adequately for this particular application so in this case we're seeing internet which is the predominant way of connecting things but it's not exclusive to Internet there are some deployments that are using things like Direct Connect there are some deployments that which would come from the MPLS Network there are some deployments that are using colocation facilities and direct connect from the colocation facility so you could actually have another transport and in fact I'll let the slide build that we have the MPLS connection that goes over the direct connect here and I can also add the Kolo that can also be connected here through Direct Connect right so you have this multi passing that you can be taken from this branch office in here into the AWS environment through either this path this path or this path so their ability to do this multi passing ends application of a route and to choose which one complies with the SLA s and make sure that we're choosing only the ones that comply with an SLA that's something that comes inherent with an SDN fabric and the ability that we have now is because we have this Sdn fabric extended all the way to the very doorsteps of the hosts that are there are inside this AWS environment and at the end it's the speed of failover we talked extensively about the high availability of this environment so the ability to fail over is important and BGP as the protocol that allows us to failover between different connections that are failing in here connection this connection between this one edge and this vgw may fail even though it's a it's two IPSec connections but let's say both of them failed I can still reroute through this another one edge right the failure over when edge itself I can reroute through another one edge so there's lots of things that come with the abilities to fail over quickly because we are using routing protocols as the underlying mechanism to make it happen and of course we have the OMP on the sd1 front to make sure that we accommodate for any failures inside the sd1 fabric so you have really a combination of OMP that takes care of the high availability and redundancy in the sd1 and then we have the BGP that takes care of the high availability and redundancy for rich ability between the s2 and fabric and the hosts bbc's so really all of this together have the greatest benefits for using the cloud on-ramp now in the beginning we talked about cloud on-ramp for is and we talked about AWS and we talked about Microsoft Azure so how is Microsoft Azure different same starting point same we managed in this particular case instead of V pcs we have V Nets it's just a different term that comes from AWS from excuse me from Microsoft Azure same starting point as the V managed and if I just follow the steps that we've done before you will find it strikingly similar same API calls same gateway entity instantiated same to an edge devices same entity to terminate IPSec connections in this case called VPN gateway remember it was vgw on AWS same standards-based IPSec same BGP same redundancy mechanisms through availability sets same extension of the sd1 fabric all the way to the doorstep of those host v nets the information exchange between the BGP and OMP the ability to you Express route for multipathing and the ability to use Kalos as well to make sure that the branch office has multipathing - this is your environment in fact everything we had as an advantage for AWS is equally applicable for Microsoft Azure so the same thing around automation simplification of a brownfield because of the no changes to the existing V Nets existing infrastructure the multipathing the key OS the segmentation the app aware routing the speed of convergence because of the BGP and OMP in the sto and fabric all of those things are factors that make this deployment Universal across different infrastructure as a service environments so as you can see you can leverage the cloud honorum functionality to do both now do you have to choose one or the other absolutely not you can have a same Sdn deployment that has a presence in Microsoft Azure and at the same time has the presence in AWS how would that look like it's exactly the same they gateway VPC in that case would be something that would be resident on the sd1 fabric and it would link to the VG w's and go to AWS it's exactly the same as we had before it's just another element on the st1 fabric alongside with branches campuses on Prem data centers it's all part of the fabric it's part of the same communication medium that I can now communicate branch to data center campus to branch campus to data center branch to AWS branch to Microsoft Azure all of that is part of the communication within the sd1 fabric as you can see really uniform model for connectivity across the multiple elements that reside on the SDN fabric and really Sdn is the glue for all of them you

Channel: 鴻愜意

Views: 2,300

Keywords:

Id: OCZY8LNE9gQ

Length: 26min 21sec (1581 seconds)

Published: Sun Jun 28 2020