 Good afternoon Welcome to the Cisco sponsor track sessions. My name is Gary. I'm gonna be your host MC for the afternoon We've got four great sessions coming up today I hope you can join us for obviously this one and any of the other three. We've got two talks after this on our Cisco virtual infrastructure manager our NFV solution coming up right after this and some Cisco and ACI talks After the afternoon break, so Settle settle in if you didn't get one of our notebooks and pens when you came in you can catch one on your way out There will be a test so take notes I'm just curious Personal curiosity for how many people is this your first open-stack summit really? That's okay. That was not the answer. I was expecting okay. Well, great welcome. I hope you guys are having a great week There's lots of great stuff going on So I'm gonna just get things going our first session is multi-cloud networking Deployment options with one of our Cisco distinguished engineers Shannon McFarland So my content plus me speaking plus right after lunch makes this perfect nap time So it's it's okay because I'm blinded by these lights and I won't notice that you're sound asleep through this talk So it's it's great. So welcome and thanks for appearing in the first of several of our Cisco sponsored sessions so that our discussion today is around multi-cloud networking and this is a very abbreviated version of the talk that I usually do on this which shows a lot of demos and CLI and a bunch of stuff around that But we're gonna we're gonna introduce this topic in here over the next 40 minutes My name is Shannon McFarland. I work in the cloud CTO group at Cisco focused on OpenStack and Kubernetes and Istio and linking all of these technologies between Enterprise on premises locations to a multitude of different public cloud sites And so we're gonna spend a little time together on this topic The best way to get ahold of me is at IPv6 with EYE IPv6 is also another technology area that I've covered for about the last 18 years of my time at Cisco So hit me on Twitter. That's a great way to get ahold of me So a quick look at our agenda We're going to just kind of do a level set of what it means to talk about multi-cloud networking And again, we're not talking about the entire umbrella topic of multi-cloud in here, which is Movement of workloads etc. Our topic today specifically is around the networking piece So we're going to talk about the traditional hybrid cloud networking and how multi-cloud differs from that Then we're going to kind of walk through some of the design options that are available to you From a high level on how you extend on-premises environments via networking into the public cloud and then begin to add Multiple public clouds to that mix and then we're going to wrap up with some automation around it So a quick level set so The first thing that comes to mind is how does multi-cloud networking differ from hybrid cloud networking? Well, they really are the same thing You're just dealing with multiple locations instead of just between a single on-premises environment and a single public cloud provider So when we look at multi-cloud networking, we are in many ways when we are taking a cookie cutter approach to design We want to basically link an on-premises environment to a public cloud and then formulate a nice repeatable design from that first Effort and then we want to repeat that across multiple cloud providers. So this brings a lot of Consistency to our design. We can reuse a lot of tool sets that we have between providers and we'll work through some of those elements in here today Again, you know consistency is pretty important. So some of the things that we're going to talk about in here today When we have a goal set around consistency like using identical technology and tool and product sets Brings that level of consistency that we're after we can reuse technologies such as IP sec or BGP or a Wide variety of other technologies. We'll talk about between them But sometimes we actually have to alter the types of tools and the types of technologies we use between two given Entities such as our on-premises in a public cloud site. So we'll talk about those You're going to have common network Transports that you're going to use in nearly every one of these types of designs. So you categorize those with first dealing with encryption So most enterprise info sec accounts are going to have a requirement for some level of encryption. This could be a plain You know HTTPS 443 type of over-the-top design. This could be a dedicated IP sec tunnel between locations Whatever the case is you're going to have some level of encryption to deal with Next you're going to deal with some level of routing and we'll talk about that when we get in the topology options But routing could be just as simple as creating a static routing Configuration between your on-premises environment and within your public cloud It could be that you're leveraging the BGP support that a public cloud provider has and then you may even want to Extend the routing topologies that you have inside of your existing enterprise and extend those IGPs inside the public cloud itself and again, we'll talk about when you would want to do that and how you would do it and Then finally you're going to have some sort of encapsulation You're going to wrap that encapsulation with some sort of IP sec and then you're going to Start to push your actual data plane traffic inside of that and again We'll graphically kind of walk through what all of these look like You also have common network endpoints between most of the public cloud providers and we'll talk about the big three in here We'll talk about Amazon Microsoft Azure and Google Cloud platform And all of them provide pretty much identical support when it comes to native VPN support Colo or service provider peering support And then some level of hybrid between those two and we'll talk about each of those Now one of the things that people come to me from a from a customer perspective and they ask Why would I want to even go down the path of dealing with multiple cloud providers? Well, sometimes it has to do with just plain old high availability You've got you know multi region support multi AZ support within the public cloud providers But sometimes you want multiple service provider more multiple cloud provider support And so this is definitely something that has been a recent trend in the enterprise space where? Someone has been a traditional AWS they Account they have dealt with multiple AZ multiple region and they've got that nailed down pretty good But for continuity of their business they want to add at least one other public cloud provider So that's a you know the first relevant driver The second one is probably the most relevant driver This is something that I encounter all the time and this is where the enterprise is Happily moving along with one of their public cloud Relationships and then they acquire or are acquired by a company that uses a different public cloud provider And for a period of time at least they're going to have to deal with at least two public cloud providers It may be something that over time they migrate back to a single cloud provider But for the most part most of the customers I know that go through an M&A and an adding another public cloud into the mix most of the time They stay that way for quite some time So that's that's another driver and we'll actually speak to these these last three as we kind of move through some of the designs So let's talk about Extending our on-premises environments to these public clouds and then see what some of the design options look like so For today there are many public cloud providers out there, but for today. We're actually going to talk about You know what we typically call the big three Amazon Microsoft Azure and and Google cloud platform but since we are at the open stack summit you can go down and Refer to all of the open stack public cloud providers as well so that there's Definitely topologies that fit into that environment So the first couple of options that we want to look at when we're extending our on-premises environments into a public cloud provider is What type of connections do we want to look at? So one of the best ways to begin this relationship between An encrypted private connection between an on-premises environment and a public cloud provider is what we call going over the top This is simply allowing public internet connectivity to public internet connectivity and creating an Encrypted transport between those two and that's basically what the top picture looks like and we'll spend Most of our time in that space The second is okay. I have matured to the point where I like this relationship. I like what I'm doing in the public cloud I like what that particular provider is doing for me as it relates to my needs for my workloads Now I want to establish a higher speed higher Available type of transport option between the two and that's where you would sign up for something that is based upon either a service provider Or a co-location Relationship this topic we could spend an entire day on on what all of the the options are from each public cloud provider and So forth and I've got some links at the back where you can go find some more information about that But we're not going to spend a whole lot of time in here because it's it can be quite an involved discussion Because the way you do it varies wildly between each of the public cloud providers So the place we're going to start is going over the top using native IP sec VPN services So all three of the big public cloud providers provide this service and it's absolutely the fastest way for you to get up and running Between connecting your on-premises environments to a public cloud provider So we can see here on the left side of this slide. This is Google cloud platform. We're showing but again AWS and Azure have these exact same services So what the service components look like is that from the on-premises environment? You are going to use a virtual or physical platform that can support whatever encryption and routing type you care about in this example We're using IP sec, but you can do SSL VPN or You know wrap encapsulation with a wide variety of tunnel types GRE VX LAN, etc And also you would look at whatever your routing type is in this example. We're looking at BGP Inside of the public cloud provider you're going to have at least two components involved in this relationship For example in the Google picture. We're looking at here. We have the Google cloud VPN service This is strictly an IP sec VPN service that you can build as either a single connection Or you can have a high availability connection. We'll talk about here shortly And then the second component is the routing component and again all of the cloud providers offer these two discrete components So that the Google cloud router very similar to what? AWS and Microsoft provide is strictly the BGP component. So this allows you to have dynamic routing relationships Inside of your public cloud provider and exchange those routes Dynamically with the routing infrastructure inside of your enterprise and so so we'll begin to kind of expand on these designs so then you begin to add more and more stuff to this right and so this begins to Kind of take over from a design perspective is that you you find an easy place that's repeatable It has the bandwidth you're looking for you settle on a good high availability design And then you start to add from there and so from this graphic We can see that we've got multiple clouds Maybe these may be multiple locations you have inside of your enterprise And you just create more and more IP sec connections into each of these regions that you care about Now What happens on the enterprise side is up to you of course right? This is your choice on how you want to build these out so you can use virtual routers You can use physical routers as the as the Cisco ASR 1,000 at the top of this you can use firewalls you can even even though I'm a Cisco employee here you can use virtual routers that come from the open source community, right? This is a pretty popular option that you can have I don't really care what you use in this regard But you need to make sure that you are building up on something that's repeatable When you start to move into the multi-cloud arena because there are very strict requirements that each of the public cloud providers have Around what type of IP sec and I parameters you can support how your BGP? Configurations look and you need to make sure that whatever platform Whether it be hardware or software that you begin with is something that can carry you through when you move into a multi-cloud environment So now let's begin to start to move into a multi-cloud view So again, whether it's because we want service provider or cloud provider high availability Or if it's because we have acquired or have been acquired by a company that has a different cloud provider than we began with Whichever one of those reasons you have We can begin to add these public cloud providers into this view and so we can kind of see here as we walk through these slides that we began with a Google cloud platform Let's for the argument's sake in our example that we have acquired a company. That's an AWS customer And we are simply beginning to extend the same design that we had with Google. We're extending With AWS and again, you can flip that out for Microsoft as well So what happens though is as we begin to modify our encryption and our routing Infrastructure for this for example, we may be wanting to actually link workloads that exist in one public cloud To workloads to another public cloud and we want to do that without ever traversing our head-in site, right? This is the you know, the hairpinning problem that we have in traditional WAN topologies And so we begin to build a mesh in this environment where we are establishing not only connectivity from the main site to the public clouds But between the public clouds themselves the challenge we get with this is the WAN mesh problem This is where we begin to add multiple sites with multiple regions with multiple Availability zones and we begin to get things completely out of control from a routing in an IP sec and an operations perspective so the challenge we tend to have here is Where do we stop and make a change in our operations? especially if this is a production environment to begin to Embrace something that's a little more modular. It's a little more dynamic And this is obviously up to you when you hit the brakes on this type of static built design And move away from these native VPN services So some of the justification for stopping and rethinking this design is on this particular slide, right? When we start to encounter Wanting to extend the things we have in our enterprise Directly inside the public cloud. These are the items that we consider from a justification point of view Now we now not only have to do that from a business Perspective what are the costs associated with doing this? How much does it cost me to run this full mesh type of environment in this static built environment? But you also have to look at the technical aspects of those designs as well. So the first one Is actually a bigger problem than you think Everyone understands what network address translation is right when the IPv4 world we are providing some level of Translation most likely between an RFC 1918 private addressing Scope to a publicly routable addressing scope and when we do that we are doing that behind that Well, when you introduce address translation and encryption into that mix You've got to have some pretty robust support for things like not transparency This is an RFC that allows you to discover that your encrypted components are on one side or the other of that This can become a challenge when you are starting to do encryption Between yourselves and a public cloud provider So you need to make sure that the public cloud provider that you are using Has support for that transparency or if they don't you need to have a good plan to work around that transparency. So This may be a loan a driver for you to change how you are building your IP second environments because By default when you are using a public cloud providers environment with Without that transparency you will you will absolutely have broken IPsec connections. So you need to check for that provider support another one Maybe that you want to extend your routing Topology inside of your enterprise directly inside the public cloud So this is actually one of the biggest drivers that I help customers with is when they're an OSPF shop or an EIG or P shop inside of their own enterprise and they want the routing Infrastructure inside their public cloud to look just like the rest of their network. Maybe it looks like a van office Maybe it looks like another data center, but they want to extend That routing support between those two another one could be that you want to take advantage of features such as quality of service or High availability or network monitoring in the same way that you're doing inside of your enterprise All of these are drivers towards moving away from a traditional Native VPN service inside of that public cloud provider and moving into something that you control on both ends So one of the views of that is a great technology It's been around a long time that Cisco invented many years ago. It's now actually in the open source community It's called DMV PN dynamic multi-point VPN And so you can take a look when you get the slides here or just do a search on Cisco DMV PN And this is a technology that allows you to Drop in a virtual router inside of the public cloud in this example. We're using the Cisco CSR 1000 v Which is just a virtual iOS router that you can grab out of the Amazon marketplace, etc And deploy it in replacement of the native VPN router that the public cloud provider offers When you do this you get all of those things that we talked about on the previous slide It's iOS on one side and iOS on the other so I can now run All of the VPN support all of the IGP support quality of service network monitoring all of the Programmability that I'm used to an iOS from Cisco perspective now exists not only in your own premises side But also in your public cloud side, so you really get Continuity operationally as well as feature continuity on both ends of this And so this allows you to break out of that full mesh point-to-point manual configuration By utilizing dynamic multi-point VPN this allows you to create a set of hubs for example in your head in and build the spokes out in your public cloud Environment and the two will discover one another through their configuration and establish point-to-point connectivity Not only between themselves in the head in but they will also Dynamically discover any other spokes that are out there So this is super powerful when you are wanting to dynamically link workloads from one public cloud provider To another public cloud provider without ever having to reconfigure anything and again We don't have a lot of time to talk about that from a configuration perspective in here But if you go and take a look at this link in here that I provided there's some great information on how you do this in and within the CSR environment especially in areas such as Azure and AWS now another option that you have available to you is Utilizing SD-WAN or software to find WAN technology So Cisco has two SD-WAN derivatives One is through the Maraki family product set and the other one is the VIP tele Acquisition product set and the SD-WAN is a great addition to your multi-cloud solution Because what you may be doing from an SD-WAN environment today, which is traditional branch connectivity In a traditional WAN environment, but you can also place virtual form factor routers again in AWS as Etc. In the form of what we call edge routers of the V edge router or the C edge router and again There's some more information here on this link, but you can again go to the the marketplace of your favorite public cloud provider Do a search for? As Cisco SD-WAN appliance and you can launch this appliance in a high availability configuration And then just add that connectivity into your existing WAN transport So this is really great in a branch office solution where you may have branches that want to have Conditional access maybe into office 365 as a SaaS service, but then you also now have Maybe AI or ML connectivity requirements from a branch And you don't want that branch to traverse the hub to go all the way back across to another VPN You can actually link those two dynamically Directly from your branch site directly into the public cloud provider And never have to touch the configuration and never have to deal with traversing your hub site So that's that's a nice option for you Now once you've kind of settled a wand what do you have from a transport perspective? How would you go about automating some of that? So some of the challenges that we have an automation Have nothing to do with technology most of the challenges We have with automation has to do with your own political environment inside of your organization, right because You may have a network operations team that uses a completely different tool set Then you know somebody that's actually running the workloads Between the two sites so some of the challenges that you have is not only the tool set themselves You've got a you know, maybe one group likes terraform another group likes ansible or chef You also may have totally different environments that you're programming against Maybe you're running OpenStack on-prem and you're running Kubernetes workloads inside of AWS from an EKS service Whatever the case might be you've got to come to terms with understanding Which tool sets are appropriate for which environments and then settle on how you figure those out You also may be using Vendor specific tool sets and so this is where you need to settle our are you Deploying your WAN and routing topology using something like Cisco NSO or Cisco prime or you're doing netconf Yang Programmability against them and then you want those same tool sets to actually tie into programmatic Deployment of the workloads themselves So there's no silver bullet to any of these but if this is your first go into Programmatically controlling some of these things Some of the things that I recommend customers start with are kind of listed here first off Don't start out Learning a brand new automation framework when you're building a very robust Multi-cloud environment use what your team already knows so pretty much all of these automation frameworks have modules for each of these cloud providers So if you're example if you're a hashy corp, you know terraform shop They've got modules for the public cloud providers as well as open-stat And so you can start with that figure out if you need to add to or change that environment Also automate the things that hurt the most to do a lot of So a lot of times customers will use just plain Jane CLI If they're deploying a resource that very rarely changes. It's something that's fairly static It's a high availability kind of configuration. They don't change a whole lot of it Then you can kind of tend to Move with a manual kind of tool set The second one there is where you are doing a lot of change on one side of the cloud Connection for example, if you've got a lot of change going on in the public cloud side Then customers tend to gravitate towards the tool set from that cloud provider. So GCP deployment manager AWS cloud formation or resource manager from Azure Those work great natively in that framework the challenge you tend to have with that model though is once a Team learns that cloud providers tool set the second you add another cloud provider I guess what they're learning all over again that cloud providers tool set So that's when you want to then potentially look at Abstracting your tool sets from an automation perspective again back up to something like Terraform or maybe even look at a commercial Solution such as Cisco Cloud Center, etc. That can kind of abstract those back-end environments away from you So before we jump into Q&A, I know this was kind of a quick trip through multi-cloud networking a high level But but there's a lot of information for you to go and grab in this first bullet point So the Cisco multi-cloud solutions page We'll talk about all of the products that we just talked about what the transport types are what the MVP in looks like what SD WAN looks like we've got Automation guides to include cloud formation templates, etc. That will help you deploy virtual routers IP sack BGP all of those things so you can go and find that information at the top lane You know some of the high-level things in this summary. I'm not going to read them all but you know public cloud Connectivity works great if you are trying to just start out But you will very quickly find that you're probably going to need better feature support Larger and more robust tool sets around Dynamically provisioning those IP sack links and that's probably going to trigger you into an alternate design Two of which we talked about in here today DMVP and an SD WAN The final thing here is there is an awful lot to think about and multi-cloud We just kind of I mean barely scratch the surface of multi-cloud networking, but you need to really thoroughly research The things that each one of the tool sets that your team is going to have to consume What the impact is from a production environment when you start with one transport type and then move to another transport type Those are some of the big ticket items that you have okay, so that's our time I've got ten minutes left here that I want to take questions on and jump Or you're just like blown away by the pace of this and want to leave so all your multi-cloud networking problems have been solved in 30 minutes No, we have two mics in the center. I've got one up here for questions. We've got about nine ten minutes This is your chance Cisco Hall of Fame presenter Shannon McFarland. You don't get this opportunity often They're just not waking up Gary Don't don't frighten them. It must have been a very carb heavy launch. That's right Great, I'm here all week. No questions now Stop by the Cisco. Okay. All right fine. Oh go ahead someone's got to break the ice Yeah, it's watch and break the ice just run around in question It could be completely useless, but from a developer developer point of view be really awesome to have something like You know a couple of Kubernetes Helm deploys where you kind of deploy into three different Isolated clusters where there's some kind of public internet connectivity And then just kind of link them all up. Is there anything on your SD1 or something where you kind of do you have any more experience? Going up the stack towards Kubernetes Yeah, so I mean hopefully everybody heard the question with the mic But as you know, do we have experience with basically going up the stack from you know adding into the services themselves in addition to the multi-cloud networking so there's actually a Great solution out there one of them from Cisco Is the CCP platform the Cisco can container platform, which is a Kubernetes environment that allows you to run on premises and then If you want to can conditionally begin to trigger the behavior of a public cloud providers Kubernetes environment and so those types of things are Available from a technology perspective the challenge that you tend to have is operationally Do you also want those same tool sets that are dealing with the programmatic deployment and operation of Kubernetes to also? programmatically deal with the networking under them and so that begins to leave you not from a question of a technology point of view because you absolutely can programmatically deal with spinning up for example VPCs and subnets and that gateways and all the other things you know VPN you can do all of that programmatically But you've got to make sure that operationally your your Staff and your info sec and all those other things are going to allow that because a lot of times It ends up actually being a roles problem versus a technology problem To allow those linkages actually to take place from a programmatic perspective So if that I mean we can talk more about programmatically what types of tool sets you could do to actually chain those series of events together But yeah, there's there's all kinds of ways of doing that not to mention. There's all kinds of ways of actually establishing Different types of Kubernetes deployments that are stretched or are they, you know federated types of environments? There's many things to consider that in addition to the networking I have a question about the network service Modeling we know that some of the community are looking at the Tosca some of them looking at young. What's your opinion about the? Service modeling when we're fixing the multicloud networking I don't have an opinion I mean to be honest with you it really is a it depends right because some things are Perfectly applicable for some use cases and not other use cases But again, it's less about the technology consumption or even the policy consumption and more about what's aligned with the actual Enterprise or even the service providers case in that regard So I mean we can we can talk about what your specific environment looks like and take that one offline But generically I I'm not the kind of guy that stands up here and says thou shalt go do this particular technology or implementation type Because what I would recommend with one customer could probably most likely blow up in another customer, right? So I kind of take those on a one-off view Anything else anybody else? Now I know Shannon you had a bunch of links and stuff in your presentation for those And I know we saw a lot of first-time hands when we asked the question OpenStack Foundation generally has these the videos of these talks up on their YouTube channel within 24 to 48 hours So if you didn't manage to catch a screen grab of a link or a reference Or resource that Shannon had in his presentation Go to the OpenStack Foundation YouTube channel and you can find Shannon's talk Go back to parts that you want to go over find a link or a resource that he mentioned in his talk. I think Let any last chance two more minutes That's it. I'm around all week. Thank you. Thank you Shannon