Cisco SD-WAN: Multicloud Overview and Demonstration

hello my name is aaron and in this abbreviated demo we're going to take a quick look at how cisco sdn delivers multi-cloud connectivity security and automation to help simplify and accelerate our customers digital transformation to a cloud-first world our journey begins within the cisco sd-wan cloud on-ramp for multi-cloud workflow cloud onwrite for multi-cloud is a single pane of glass workflow designed to help it teams navigate increasingly complex cloud infrastructures by abstracting the complexity involved with interconnecting users with cloud workloads since cloud onramp extends the organization's sd-wan fabric to the cloud our first step seen here is to define how our cloud-native catalyst 8000v routers will be instantiated in the case of aws we can decide on things such as how we leverage transit gateway our default compute instant size which software image we prefer to run and how these devices will be plumbed into aws similar options exist for microsoft azure as well as google compute next we need to define a set of credentials that our vmanage will use to authenticate to the cloud infrastructure for purposes of automation vmanage utilizes deep api integration to provision cloud onramp for multi-cloud features here we're demonstrating aws though microsoft and gcp utilize similar constructs our next step will be to begin the process of instantiating cloud native virtual routers into each of our providers here we'll instantiate a pair of catalyst 8000v routers within the us west 1 region of aws note that the software image instant size ip subnet pool and tunnel count are all default parameters pulled from the global settings we configured in the beginning but for the sake of demonstration we'll adjust some of these defaults to suit our deployment here once complete vmanage begins the process of programmatically provisioning aws with a transit vpc transit gateway and all the necessary plumbing to get our cloud routers natively integrated while that's working let's take a peek at google compute similar to aws we're provisioning a pair of catalyst 8000v routers in the u.s central region the remainder of the parameters on this screen as with aws are defaulted using global settings here in an effort to be cost conscious we'll adjust our network service tier to be standard rather than premium again once we click add vmanage begins the process of provisioning catalyst akv routers within google network connectivity center finally we'll get a pair of routers stood up inside microsoft azure virtual wan as well to round out our geographical coverage we'll choose the east us region for these routers note that in this case vmanage also programmatically instantiates a v-hub in this region after a few minutes and a cup of coffee our sd-wan fabric has now successfully been extended to aws gcp and microsoft azure for those folks who are more net ops or devops minded cisco sd-wan can also leverage terraform and ansible to not only customize a cloud deployment but easily automate new router onboarding moves adds and changes to cloud infrastructure when the need arises here terraform is being used to provision an entire sd-wan fabric while ansible manage template creation and modification so now that our routers are stood up within their respective cloud environments it's time to plumb them into our workloads so that those workloads become available to users in the sd-wan fabric to do this we start by discovering where our workloads live within the cloud regions wherein we have presence for the sake of demonstration let's assume that one of our cloud regions is in australia where we have a workload sitting in the aeres vpc sydney vpc vmanage utilizes a tagging mechanism for cross visualization purposes by tagging this vpc not only are we making it available to the cloud on-ramp workflow we're also making it easier to track within the aws console we've already taken the liberty of tagging other vpcs within aws azure and gcp to speed along this demonstration before we connect our workloads let's take a quick look at the routing table of our aws and gcp routers in the aws router note that there are no routes present in the routing table for any cloud resources though the router has been instantiated we've not plumbed it into any workloads similarly on the gcp router we can see a few routes but we're missing some routes that belong to our host vpc we can verify this lack of connectivity with a simple ping from our aws host to our gcp host our aws host ip address is 1053 2.101 while our gcp host is 1033 0 101 and as expected the ping fails let's fix that back in the vmanage cloud onramp for multi-cloud workflow we'll head to the intent management section here we can specify precisely how our cloud workloads are presented to the sd-wan fabric and even how these workloads present to each other note how this table is laid out allowing a user to map specific vpcs to specific brfs or other vpcs this means that not only can you facilitate intra-cloud connectivity from here but organizational security and segmentation policy can also be extended deep into each one of the cloud providers here we'll map our sydney vpc we discovered earlier to vrf10 similarly we'll map our sydney vpc within google to vrf10 as well and with that we're ready to test again making our way back over to the aws router note the presence of many new routes in the routing table namely the 10.53.0.0 subnet where our aws host lives and the 10.33.0.0 subnet where a gcp host lives so with a few clicks we've not only brought our cloud workloads into the sd-wan fabric but we've also interconnected two clouds aws and gcp within our sydney region no complex policy required though not part of this demonstration it's also important to note that cisco sd-wan can also programmatically access cloud provider and co-location backbones to provide premium high-speed interconnects between different regions of cloud providers of your choice by onboarding sd-wan traffic into a cloud or co-location backbone we can minimize that traffic's exposure to the uncontrolled internet and minimize long-haul latency all dynamically and at a fraction of the cost and time it used to take but what sd-wan cloud conversation is complete without discussing security earlier you saw how cisco sd-wan can extend segmentation policy into cloud constructs here we'll take it a step further starting in cisco sd-wan version 20.6 aside from an enhanced user interface seen here enterprise it operators can now also leverage microsoft secured virtual hub a secured vhub is an azure virtual wan hub with associated security and routing policies configured by azure firewall manager in our case as traffic traverses our azure deployment we can easily insert firewall policy into the transit path without the need for any additional sd-wan policy we start the process by onboarding our microsoft v-nets into the sd-wan fabric much the same as we did with our aws and google vpcs in previous sections as you can see our branch router does not currently have any routes present for our azure host 10.152 first we discover each of the workloads or v-nets in their respective regions and tag them next we'll visit our intent management workflow to map these workloads to the sd-n fabric segments once complete our sd-wan users can now access azure resources as seen here now let's assume that we want to block traffic to this v-net using the azure firewall moving over to the azure portal we'll create a simple policy to do just that the policy is then attached via the security provider's workflow and finally inspection of our branch to cloud traffic is enabled through the security configuration workflow seen here now heading back to the command line we can see that our test traffic is now blocked this same methodology can be used to provide outbound internet filtering as well when the azure firewall is enabled for internet bound traffic notice how cisco sun automatically ingests a default route from the v hub to start directing traffic that way here we can see that our internet traffic is blocked due to our policy let's update the policy quickly to allow our branch traffic again now our ping is successful in cases where region to region filtering is necessary cisco sd-wan can be leveraged to construct all of the necessary plumbing between v-hubs and azure firewall can provide the filtering in between

Channel: Cisco SD-WAN and Cloud Networking

Views: 740

Keywords:

Id: 7tLJPFHhIeo

Length: 8min 33sec (513 seconds)

Published: Wed Jul 14 2021