ENCOR - SD-WAN Principles

happy wednesday everybody welcome back to the cisco encore study group last week we took a look at cloud versus on-prem deployments and we've been kind of working our way through the encore blueprint and this week we're on to a very exciting topic software wide area networks or sd-wan cisco acquired a company called viptela a few years ago and that has become the cisco sd-wan product software-defined way is one of these technologies that has been very buzz worthy for a long time but this one might actually live up to live up to the hype because we have seen all kinds of enterprises deploying sd-wan technologies whether cisco's technology or other technologies either way it's a technology stack that really delivers a lot of benefits up front and helps solve pain points and i tell you what if you can come up with a solution that solves pain points that enterprises are experiencing you're never going to find budgetary restrictions or anything that gets in the way of deploying that technology we are all about solving problems and solving pain points in our industry and sd-wan is just one of these technologies that actually solves real pain we're going to be covering that today in this session so as for our agenda we are looking at first of all we need to understand what traditional wands are all about and what those pain points are you know because again if if we don't have pain points that we're solving then who cares about this technology and so it helps to start with what we have and then that way we can move into why this is so great so we're going to start with traditional sd-wans we're going to talk about again then why sd-wan what exactly are we gaining by deploying sd-wan that would be the you know solving the pain points part of this conversation sd-wan architecture from there we're going to look at cisco's architecture specifically we want to see how they designed their sd-wan solution and i say they designed it of course i'm referring to viptela because cisco had a product and didn't really work out so they went out and bought another one it's kind of a tale as old as time at this point with cisco they can't quite make their own version of this work which was called iwan they couldn't make iowan work they went out and found a solution that was working again that would be viptela but the solution at this point is called literally cisco sd-wan we went from a fancy name like iwan to now just simply sd-wan which is the generic term for this so kind of interesting marketing decision that cisco made there but that is what it is and then with as much time as we have left at the end we're going to explore different ways of deploying sd-wan different topologies that we can deploy and how exactly that's going to look all right so without further ado let's dive into the whiteboarding or blackboarding or chalkboarding or whatever you want to call it so traditional wins now when we talk about a wide area network we're usually talking about connecting a lot of different disparate i guess buildings or locations network locations so i might have you know if i'm a branch for example i might have a lot wait when i say that right if i'm a bank i might have a lot of branches out there that i need to connect to or maybe i'm a restaurant or maybe i'm a what's the word i'm looking for retailer i've got stores all across the country or what have you and i'm reaching out and connecting all of these different sites and usually what i want to do is i want to connect them back to my headquarters maybe i've got i'll draw that a little bit bigger down there or maybe i've got a data center location data centers where all of my applications and data live we talked about this last week with that whole cloud versus on-prem conversation and somewhere on here the internet exists and so we'll we'll draw the internet as if it's hanging off of the headquarters because in a lot of cases that's where it's going to be or possibly off the data center as well it's a popular location and so this can look a whole lot different than this this is just sort of an example but we have here in the middle is this wide area network service provider in some way we're going to have a service provider that's providing the connection to all these locations now ideally this is one service provider and in most cases it's going to be every now and again we might have to go out and find a different type of service provider because maybe my favorite service provider doesn't reach this site or what have you and so that can start to get a little bit complicated and the reality is is that what we're going to find here is that this whole mess can get really complicated that's just one of the ways that it can be that way ideally we have one service provider i'll say per network and again this is where the complexities start to stack up because the reality is that if i am running mission critical business out in this world then i'm probably going to want a second wide area network service provider i want to have a second cloud so to speak and i'll draw that as a different color by the way i neglected my typical intro where i say because this has been pre-recorded i am available in the chat right now to be answering any questions so make sure to chime in with any questions at any time about this topic or any encore conversation because you know this is a study group i know we're going through this together through the blueprint maybe this is hitting at a good time for you maybe you already studied this and you have questions about something else or you want to go back in time further either way that's fine just again toss your questions in there and me or somebody else will hopefully be able to help you out with that okay so if we were to draw a second wand service provider you know maybe i'll use a different color because green doesn't really work very well it doesn't stand out there we go that neon pink kind of stands out a little bit better so now i've got a second service provider we'll call the service provider too and now i'm running connections to all of these routers as a secondary link well we can start to see where this complexity is increasing because now i've got two different paths to all of these different routers and i need to make sure that my routing domain can handle a failure what if this link goes down right here is my routing domain going to converge around this additional path it's great that we have two connections but is it actually going to fail over and when it fails over what's that going to look like or my application's going to take a big hiccup because you know routing converges and my users get disconnected from their services that they were running to the data center what have you i mean there's a lot here that could potentially go wrong just from a simple outage of a circuit you know we want to avoid that okay so the dual sp calls again dual service provider right but the dual sp design already introduces a lot of complexity into traditional lan deployments on top of that we have to worry about different media types i'm going to change my color here again so now we've got different media types we have to worry about some of these sites might be t-ones and e-ones some of these sites might be a metro ethernet connection some of them might be mpls or um what are some other ones this might just be a vpn across the internet it could be 4g it could be 5g i mean we've got all kinds of different ways of connecting our sites now and this can be completely different at every single location if we're not careful and so you know managing the configuration for all of these different media types can can be a hassle we have to worry about our application so what if i have an application here that is a high priority in an application here that is low priority so just looking at this as this these two different types of traffic come into this location into this router and the router has to make its forwarding decision by default what's going to happen well by default one of these service providers is probably not as good as the other one i'm probably not paying premium dollars or whatever your currency is i'm probably not paying a top top dollar i don't know how to say otherwise for these different circuits um for both of these circuits but one of them is probably very high quality and that one's that's gonna be my primary and then one was gonna be lower quality and so the question is if the let's say my yellow my first one is my priority like that's nicer bandwidth maybe this is 100 meg on the yellow line and the pink line is i don't know call it 50 meg that's my backup circuit so can i easily tell again this router here can usually tell that router where to send those applications uh what if i want both of these to go across the larger connection 100 meg because you know they're both high they're you know high priority and low priority sure but i want them to take advantage of that bandwidth maybe the low priority um traffic flows need a lot of bandwidth well if that's the case then i need it to go across my high bandwidth line i mean that 50 meg link could also be a 10 meg link and maybe it just doesn't have the bandwidth to support the the lower priority app even though it's low priority it still is kind of important we want that to stay fully functional and so in a lot of cases we're going to find that traffic easily goes into the primary wind service provider and only leverages that backup connection if that primary goes down that's a lot of bandwidth that's just sitting there getting unused i mean is that really what i want i mean and and if i were to split them up then can we handle when they come together if one of them goes down can we fail over uh that that can be a problem what about security in all of this security can be a very difficult um i guess generally speaking it's very difficult to properly lock down a wide area network and part of the reason for that is because this wide area network in here this is multi-tenant they've got a lot of different clients that are running across this wide area network and the bizarre thing is that when we are running mpls in a lot of generally speaking in a lot of cases we're going to be exchanging routes with our service provider so now we're trusting the service provider to advertise these routes to my sites which is well and good but we don't want them to route it to their other customers and so we're kind of trusting them that they're not actually um we're trusting them that they're not going to accidentally advertise our routes to other customers but also in the meantime is this traffic encrypted i mean couldn't somebody in the service provider look at that traffic and see what it is because it's all being sent in clear text i mean this is these are not ipsec tunnels none of these are none of this traffic is getting encrypted by default it's not being protected and so security is something that traditional wins usually don't do either we've talked all about the complexity of this what about managing all of it i mean flat up flat out i'm going to have to manage this router this router this router all of the routers on my network now we i used to work help a bank that has i think over a hundred different branch sites and every single one of those routers was manually configured and so you talk about dual home connections at a hundred different locations that's a lot of routers that we have to manage and so manageability is very difficult what about visibility how do i even know what's going across my white area network i made this example up here where we had two different apps that were coming in and going across my wand my white area network i mean are one of those apps getting starved is are they doing all right there's quality of service or quality i should say like this users are having problems and they're reporting problems with an application is it the wan or is it something in the data center maybe the data center is acting up i mean i don't have answers for in most cases how things are doing in this wide area network environment and so that gets to be a problem and so as we've seen there's just a lot of issues that we're going to hope that we can solve with a new way of doing things and the new way of doing things in this case will be software-defined wide area networks so let's clear this out uh oh wait we need that there we go okay so here we have our um yeah well you know what that's funny we lost our second link so let's go and get that drawn back up here without all of the other stuff so how is a wide area network i'm sorry a software defined wide area network any different well one of the biggest things is that when we hear the phrase software defined we're usually talking about this concept of an overlay what is an overlay an overlay is typically well first of all it's paired up with an underlay you are going to have an overlay and an underlay and here's how i usually describe it usually what we're going to be dealing with here is let's say we have a network with five physical routers all connected together in some fashion and we don't necessarily want our topology to look like they're physically connected this is the physical world and so instead what we do is we map all of these devices to a new logical topology and that logical topology might look a little different we might do have our logical topology be looking like this and so what we did was we connected all four of the corner routers to the middle router maybe we can run some security policy on that middle router that will you know identify traffic or what have you i mean that's a much preferred topology so here's the question how in the world am i just arbitrarily deciding that my physical topology is no good so i'm going to deploy a different logical topology well the way i accomplish this is with the concept of tunnels an instructor once told me that the tunnels are a swiss army knife of networking and it's true i mean tunnels are actually banned on the ccie if you go take the cci lab they'll tell you do not use tunnels because they know that most of well i should say unless you're instructed to or unless it's a required part of the solution because you can actually use tunnels to shortcut pretty much anything in a network the problem with tunnels is that they don't really scale very well from a management perspective so if i'm going to deploy hundreds of tunnels in my network to give me the topology that i want that's great except who's going to manage those hundreds of tunnels and he's going to make sure that they stay up to date over time and who's going to make sure that they don't have problems or troubleshoot them when they go down and such tunnels give us some great opportunities but traditionally they've been very difficult to manage well in the software defined infrastructure world in this case we'll say software defined networking or software defined when and all of these i mean we're going to have a controller and the creation of these controllers is really what's driving our ability to deploy software-defined networks because the controller is going to handle the complexity of the tunnels for us and therefore now we can have kind of the best of both worlds where we have tunnels giving us exactly what we want from a topology perspective and but not from a complexity perspective so what this is going to look like is i'm going to take my physical routers here i'm going to build build tunnel interfaces there's going to be four different tunnel interfaces on that middle router and now the purple lines these would be my tunnels my tunnels are going to form this logical topology so i sometimes describe it as saying place a place a sheet of tracing paper on top you know you've got your physical i'm not explaining as well yeah your physical topology on paper place a sheet of tracing paper on top and figure out you know draw the network you really want basically and that's that's the idea of an underlying and overlay this is my overlay my overlay rides on top of or over my underlay so the underlay is the physical wait a second oh yeah okay sorry i did that wrong the overlay is the purple here but the underlay is the physical yeah i got that mixed up there we go the underlay is the physical network that's how we equate the two we say that the underlay is the physical network the overlay is the logical network okay so in cisco's ipsec world we're going to hear a lot about this but these tunnels would be ipsec tunnels i just mentioned that concept of ipsec tunnels saying in traditional wands we're not using those we can pretty well imply by the name ipsec that that sac right here is also going to give us some security which is absolutely the case we're going to get some good actual security in this environment whereas in a traditional way we don't get that um because we're now building tunnels well i should let me let me make something clear here so what we're going to end up doing is we're going to form tunnels between our routers so we'll form a tunnel between uh let's just call this i don't know site three i guess three two and one so site three router will form a tunnel through the yellow network to land on the data center but will also form a tunnel across the purple network that lands on the data center and if for any reason the physical network changes well guess what the logical network didn't actually change yes this second tunnel will have to re-home through the yellow network and at that point yes our redundancy is gone and we're running two tunnels across the same physical network but think about that if we've got if we had a link fail physical link went down but the logical link never went down did the topology change as far as the network is concerned did the topology change and the answer is no it did not those tunnels are going to remain up as long as they have a path we could have 15 different service provider networks i don't know about literally but [Laughter] in theory we could have 15 different service provider networks all coming into that router and we're going to be able to keep as many tunnels up throughout process as we want it as those 15 are going up and down or what have you okay so because we're building tunnels we don't actually have to share networks and remember we had to sit we had to share our routes with the service provider we don't have to do that anymore because the routes that we're connecting are are subnet so let's say data center has subnet a site three has subnet b well the whole reason we're advertising our routes subnets a and b into the service provider space is so the service provider could receive the traffic that's destined for subnet a maybe as traffic comes in to the servicewriter network here it's destined for subnet a the wind provider needs to know what to do with that in a traditional when well that's not actually the case in sd-wan topology because we're using these tunnels and my destination traffic once it's encapsulated in the tunnel will always be a router that is directly attached so yeah it might be a loopback that i have to advertise to the router for those who are to the service provider for those who are really following along here but at the same time the point is simply i don't have to advertise all of my client subnets to the service provider anymore so we just mentioned security by using ipsec tunnels that's going to encrypt our traffic that's amazing that our traffic is in the wan service provider's network encrypted but on top of that i don't have to share my routes with my service provider if i'm not sharing my routes with the service provider that's one less security risk that i have to worry about which is amazing okay i mentioned this controller this controller is going to usually be a virtual machine that's going to sit on my network or in the cloud or what have you but the point is this me as the network admin here i'm doing my administrative work by logging into a single controller i no longer have to manage every single router in this topology i don't have to go to every single router anymore and configure i can configure everything from a single pane of glass that's the phrase we used to say that it doesn't matter how many different pieces i have in the network single pane of glasses just i've got one paint a glass i don't know how else to say it i've got one management interface to roll them all let's go that way i don't have to log into everything anymore um and last but not least this management uh management tool i don't know this management interface is going to give me access to all kinds of application aware policies and we're going to talk more about this here as the session goes on but we can do a lot of the things that we were talking about in the last video or in the last on the last slide where we were showing like hey how do i direct these different applications out different uh wand service provider links so it's pretty fascinating when you really look at it as an overall solution how much is how much of our earlier problems that we talked about are solved by really i would say two main concepts one would be this underlay overlay that would be the software defined part of software defined when but then the other part of most software-defined solutions would be this controller so the fact that we have an overlay now with the tunnels and the fact that we have a controller at play to to really you know help me with my management those two are making a huge difference with how my traffic is well how the whole sd-wan architecture works um and then the third thing would probably be this concept of using ipsec as my tunneling mechanism i could use any tunneling mechanism but the fact that i'm using ipsec now allows me to encrypt the data that is going across the wide area network all right so that is the why of sd-wan again if you have any questions about any of this feel free to chime into the chat we'll do my best to answer let's talk about um i'm not going to don't think i need do i need that yeah i'll go and keep that all right let's talk about cisco's solution what is cisco sd when what is that all about okay cisco sd-wan is um boy how to where i lost my train of thought but either way so uh cisco see when the architecture for this is going to look different from other vendors so if you have experience with other vendors then you know it's still a lot of the same principles apply we're still building the overlays and we're still doing this via software-defined infrastructure et cetera but the way cisco's you know viptela's sd-wan environment is built it's going to be a little bit different than than what everybody else's is all right um we divide sd-wan into four planes i'll go ahead and list all of these out we've got the management plane we've got the control plane we've got the data plane those two should sound familiar right and then maybe a less familiar one we've got the orchestration plane there we go all right so let's go through each one of these now the management plane is as you can imagine it's going to be how we manage this environment we already mentioned it but we're going to do is we're going to deploy a controller and the controller will be a virtual machine that is either again in our network or it's in the cloud somewhere and in a cisco sd-wan environment we call this the vmanage now cisco has done a great job i guess it's great i don't know i don't well either way they have they've done a great job of rebranding everything so we don't see viptela anymore a whole lot but one place we do see viptela is this concept of this little v we've got a lot of little v devices that we're going to talk about v manage v smart v edge etc the little v actually doesn't stand for virtual it stands for viptela so be sure to keep that in mind because we're going to see v edges that are physical pieces of equipment so the v does not stand for virtual in a lot of cases especially if you're used to vmware anything that starts with a v is basically a virtual something v switch v whatever even a vlan we talked about that last week right it's a virtual lan so just want to clarify that and you'll see why here in a little bit as well why that's important now the vmanage is again it's it's my entire interface me as the admin this is how i configure everything in this environment slight asterisk slight caveat here cisco unlike some solutions cisco does actually open up my ability to log into an individual router and do configuration on it but the goal is that i don't need to do that okay that's primarily for troubleshooting if i'm having major issues and i can't figure things out then i can use the cli to gain access to an edge router and i can do things at the command line but again the goal is that i never have to do that and that really isn't how we should be managing our environment because again what's one of the goals is that i can log into one interface and configure everything and if you're a site with five or five i'm sorry if you're an organization with five sites not that big of a cost savings or time savings but guess what as soon as you get that to you know 100 sites or a thousand sites i mean i can't tell you how much time that's going to save you it's going to be enormous interestingly by the way yes i can use a graphical user interface or a gui in order to configure vmanage i can also use rest apis this is the modern programmatic way of configuring network well not just network really it's configuring anything any system can allow direct access to it via these rest apis and what that allows me to do is to set up automated scripts and whatever else you want to toss in there will automatically go out and perform configuration for you so you could have uh you could write a script that automatically goes out and tests the availability of everything even though the vmanage itself is doing that i mean you could in theory do that that's just an option that we have so you know for the most part i think especially when you're first starting with sd-wan you're going to spend a lot more time at the gui than by doing rest apis that's if you're coming from a traditional networking background you don't need to freak out about the availability of rest apis it's actually just another tool on our belt and if you're not using them great but if you are even better all right um that would be the v manage now um v manage oh by the way i should i should be drawing these out with their icons so cisco gives us and i say cisco because this also came from viptela we've got some icons here that you'll see a lot of especially as you configure things so um the vmanage looks kind of like a resource tree and i believe that's because when you're configuring it you configure resources in an environment etc so um that is that is the v manage icon you'll again i i wouldn't be drawing it if you weren't going to see it again you will see these icons a lot and forgive my rough interpretation of that okay next is the v smart the v smart icon is it's like this like atomic star looking thing i i don't know what exactly it is um i i think it's supposed to look like an atomic model because it's smart i guess i don't know that's my interpretation of it somebody's like probably like no that's a person dancing or something i have no idea what it is but either way this is responsible for the control plane the you know write that down control plane i'll just say that one the control plane protocol that we're using in a cisco sd-wan environment is called the overlay management protocol or omp i'd write it out but i don't have room here so omp again overlay management protocol is what we're going to use to configure the edge devices now vmanage is actually going to push anything i configure so i'm going to do my management up here right i'm managing via vmanage but vmanage does not directly push those policies out to the edge devices instead it pushes the policies down to the v smart and the v smart is going to further push this down to the these edge devices and it's going to use omp to push those policies down okay next would be the data plane and this is where we're going to spend a lot of time talking about these whoops so the this would be the v edge i keep calling them edge devices it's literally in the name right it's the v edge is this this is a v edge it's an edge router that's connecting to the sd-wan environment however we also have another device type in here that we call the sea edge now the reason i gave you that little lesson earlier about what the little v stands for is because of this because you can probably guess what the little c stands for maybe you can't i don't know but um the little c stands for cisco whoops then there goes my camera the little c stands for cisco and that means that we are actually running ac edges running on real cisco hardware say well isn't the v edge running on real cisco hardware well no actually the v edge is running on viptela hardware and so cisco is slowly phasing out the v edges in favor of this concept of a c edge but we'll dive a little bit more into the nuances of that later the icon for a v edge is truly just going to be a router symbol so you kind of got the arrows going out and the arrows going in etc something like that all right so you'd think well hold up we're not done yet so the vsmart again is pushing these policies down the basically the configuration down to the v edges and it's using omp for this um by the way the policies up here these are being pushed down by netconf that's another programmatic language that's a little bit more like rest api is more about interfacing with a system and netconf is very specifically for how to configure network devices so kind of an interesting nuance there but i shouldn't have written that all in green that kind of was all blurring together let me let me draw a little couple lines in here so there we go and there we go okay so we can see again these planes developing where cisco's got the management plane that's what the v manage is for we've got the control plane that's with the v smarters for it's going to receive the policies and you say okay well why do we have this man in the middle concept why do we have the v smart that's receiving policies from v manage and pushing them down to the v edges why isn't v managers push that down a couple of reasons for that first of all we want to scale okay so imagine thousands of the edge devices when we have thousands of devices like that in our sd-wan we don't want a even a single v smart being responsible for all of those let alone a single v manage okay we're never going to have more than one v managed we want that to be the absolute tip of the pyramid it is our single pane of glass as soon as soon as we have multiple vmanages it's like well now we need a super manager for those i mean i remember that back in the day with wireless like we were deploying these wireless lan controllers and we advertised them to our customers like yeah i was working for a cisco partner so we were selling these like oh yeah it's this single pane of glass management for all your access points because remember back then it was like we had these autonomous access points you had to configure every single access point in the entire environment manually and like what a nightmare oh now we've got these wireless lan controllers you can go to one spot and configure all of your access points and that was great other than well guess what i'm going to play one wireless lan controller here i'm going to deploy a second one for redundancy and then oh at that site we're going to play another wireless lan controller and a second one for redundancy there and then over at that third and we'd end up with like eight wireless lan controllers and so we had like eight single panes of glass right like it's not a single pane of glass that's that that's eight different management systems i mean it's better than a thousand access points but still eight it's not a single one so then cisco had their you know solutions for for that which eventually evolved into cisco prime infrastructure and such it was originally a wireless control system which became the ncs network control system which became part of prime infrastructure why are we talking about this i don't know but all that to say vmanage we want that to be the tip of the pyramid we want that to be a single pane of glass so since that doesn't scale out to managing thousands of devices that allows us to deploy multiple v-smarts and those v-smarts which i didn't say this these are virtual machines as well um virtual appliances that are going to run probably in our own environment but they can run in the cloud either way the purpose of the one of the reasons for this is simply the scale so i can push all my policies down to two three four five different v smarts and those different vs each one of those v smarts can push the policy down to hundreds or thousands of devices per vsmart or what have you and so that's the purpose of this multi-tier infrastructure because again the goal is eventually to get the policies i define policies here and i want those policies to be manifested on those v edges well the way we get there is via the v-smarts that's the primary reason i will say there is another reason for why we have the v-smarts and that is because cisco likes to again cisco didn't design this to be fair but they did acquire the company and after evaluating everything cisco loves what we call declarative sd infrastructure sd network software defined declarative sdn models let's say like that declarative software defined networking models cisco loves declarative models well a declarative model is one where the manager so in our case v manage sort of sits off to the side and is like hey you guys do this and if i disappear if i'm like you know i'm gone for whatever reason i my virtual machine went down if v manage goes down it's already declared the policies it's already said hey this is what you're supposed to do and so just because the controller goes down remember we we're a software defined infrastructure we have a controller if the controller goes down we want to keep the network online yeah and so if the vmanage goes down those v-smarts are still there telling the v-edges what to do and the v-edges have all kinds of intelligence to be able to accomplish what they set out to accomplish and so that's one of the reasons that's another reason why cisco wanted or has this multi-tier infrastructure i think that can just kind of get lost in the shuffle a little bit but the fact that it's a declarative model and by the way the the the opposite the other side of the coin of a declarative model is imperative an imperative sd model is where the controller is absolutely mission critical a very important part of the software-defined infrastructure meaning that if i have a controller over here that's imperative and it goes down for some reason the network completely falls on its knees it can't exist without the controller because it's not telling them anymore how to behave it's truly doing the behavior for them so it's like learning routes and it's installing routes into the various routing tables and the nice thing about this and the reason why some companies go with an imperative model is because the hardware can be a whole lot dumber it can be a whole lot less beefy because it doesn't have to do anything on its own anymore so the imperative model offloads all of these network devices to the controller it just makes the controller that much more mission critical in the infrastructure now again we don't we don't like losing access to our whoops we don't like losing access to our management i'm not telling you to go out and just shut down your vmanage willy-nilly i'm just saying that a declarative model makes it so that you can afford those kinds of outages and a lot of those outages are going to happen by the way simply by upgrading the software on your controller ucs manager was this way by the way it's not really ucs cisco's ucs server platform was sort of a software-defined infrastructure before software-defined infrastructures were cool and one of the neat things about it is that was that the manager was also this declarative model where it kind of pushed the configurations down and you know ucs manager was built into cisco servers so to speak into the fabric interconnects and so it's not like the hardware could go down without affecting things but in a way the bigger thing would be when you want to upgrade the software you go and upgrade it and you lose total access to the management domain but guess what all the traffic is flowing still you can't make changes while the manager is down but as long as the network stays up and all the bits and bytes are flowing then who cares if you can't make changes as long as for a short amount of time at least that's in theory right i mean obviously if if changes need to be made or or something happens that you need the controller's input for and the control is not available it will cause problems but assuming it's a short outage we should be able to sustain that all right how we doing here we have about 20 minutes left now we're actually doing all right here okay so let me just do a quick checklist here for the first three planes we've got the management plane we've got the v smart running omp let's keep that in mind it uses omp pushes that down to the v edge and the c edge ah yes one other thing about the v edges and c edges okay and let's go ahead at this point and define them a little bit better so these v edges and sea edges these are going to be forming the vxlan tunnels with each other we already drew this out but i just want to make sure that the point is made that we will be deploying a tunnel per wand service provider one thing to keep in mind with cisco not just cisco with any sd-wan deployment is if you're running on a single wan connection per site there's not nearly as much need for sd-wan like it can help you manage all of these different routers but one of the biggest benefits is its ability to fully manage multi-pathing and so if you don't have multi-pathing if you only got a single service provider per per branch or what have you then there's not as much reason for an sd-wan solution so we're going to assume in most cases that we have multiple uh service providers like we do here in this case and so we're going to have multiple ipsec tunnels where again we talked about this if one of these physical links goes down logically i can forward this tunnel traffic over to the other wan service provider and i my logical topology never changed my logical topology never changes i don't have to worry about routing re-convergence i don't have to worry about applications going across the wrong link you know like if if truly traditional wands right if i have two different circuits and i'm forwarding traffic out different circuits it's a lot harder for when one of them to go down to make sure that everything goes out that i've got the qos enabled that i need to make sure that they can you know all my traffic can survive on that link or what have you and then when it comes back online to actually fail over i mean it seems like it's a simple concept but it takes a lot of configuration a whole lot of effort and that's assuming i even go so far as to do some kind of load balancing across my two links in a lot of cases i'll just go active standby i'm just going to use link a until it dies and then i'll use link b until link a comes back up you know that's most of our wan deployments today so that's one of the biggest benefits to to this and again leveraging the policies in v manage v managed through this process if i tell it hey i want application a to go across you know that link in application b to go across that link well v manage via the v smart is going to configure the v edges in order to make that happen and we're going to be talking i think we've got time to talk about the topologies well i really do think we have time for it today um so at that point we'll take a look at how exactly that that works okay um the other thing i wanted to clarify um i said it briefly but it's worth just spending a little bit more time on a v-edge is truly a piece of viptela hardware oops it's a piece of hardware that cisco acquired yeah they're still manufacturing these and they're still supporting these but we're we're not we're not really supposed to be but we're not going to be doing a whole lot of deployment of these v edges okay instead we're going to be taking advantage of is this concept of a c edge what a c edge is is a cisco piece of hardware so like an isr this would be a very common use case for for this we'd use an integrated services router and we will put a very special version of ios xe on top of this router now this ios xe version is basically running the same code as the v edge so the point i really want to drive home is a c edge even though it is an isr i will not be configuring it like a traditional isr in fact i won't be configuring it all because it'll be managed by my vmanage but some of the capabilities that are pretty common with cisco isrs might not be available so we have to be very careful about this obviously the scope of this conversation is not to go into all of the nitty gritty details of of the two but you have to be careful about committing to not committing to you have to know what you're giving up when you move from a traditional isr to a csr um the main reason why we'd want to do this by the way versus especially if the edges are still available or what have you and yes isrs are phenomenal routers i mean i can connect uh to the pstn right the public switch telephone network i can use my uc this way i can deploy servers into my isrs i mean there's a lot of things i can do with an isr and some of those things will work in a c edge and some of them will not some modules will work like again some of the uc stuff and some won't you just have to do your research and make sure that if you're going to upgrade one of your current isrs to a c edge which you can do just really just takes a software upgrade that whatever hardware you have installed into these isrs will be supported on the other side of the upgrade okay so just something to keep in mind there um one other point i wanted to make by the way this v edge even though i said the little v does not stand for virtual there is a virtual version of this you can deploy virtual v edge into a data center infrastructure or into a cloud and that's usually where you're going to see it the most is when you have a cloud up here so you've got infrastructure virtual machines that live inside of microsoft or amazon or some other vendors cloud you've got these virtual machines so i can deploy a virtual v edge up here and guess what that virtual v edge by leveraging you know usually the cloud let me draw in a different place because usually the cloud is hanging off of the internet so i've got my cloud provider i've got my virtual machines here and i can deploy a v edge a virtual v edge into this cloud space and have it form vxlan tunnels vxlan tunnels ipsec tunnels sorry i'm getting my tunneling mechanisms mixed up i can form my ipsec tunnels through the internet and connect to where the rest of the world the rest of the sd-wan world i mean technically speaking i could i could make tunnel connections to all of these other devices all the other all the other v edges and sea edges in my physical wide area network so there is reason for deploying this as a virtual appliance but again i just mostly wanted to point out the difference or what what the little v was because clearly we have a viptela version and we have a cisco version okay um the last thing we need to cover on this slide is this concept of the orchestration pane now this is getting to be a little bit busy um should i clean it up i'll clean it up a little bit let's get rid of all that yeah that worked okay so the orchestration plane what's going on here well we have this concept of a v bond and the v bond icon oh shoot i forget what the v bond icon looks like it's just like a line through it or something like that with a dot in the middle that's a poke ball never mind i don't know maybe no that's baymax okay well we'll look up the v box i got later i should have done that um just google it real quick you'll see a picture of it but either way the v bond you say okay well we've got all of this already figured out i mean what what could possibly be left what is this orchestration plane doing when a router comes online how does it know where to go how does it know how to get to the v manager or the v smarts i should say and how does the v manage know that this is a viable connection this is the responsibility of the v bond the v bond will be the first thing that this router reaches out to and it's sort of the i guess it's the um arbiter i don't know the negotiator it's the person it's the device that's going to bridge these connections it's going to help the new v edge or c edge that just came online connect to the v manage to get um to get registered and then the v manager will push that information to the v smart and the v smart will reach out etc so that's that's a very important part the other thing the v bond is responsible for is helping deal with nat issues okay in a lot of cases a router my via droughter might not be at the internet edge and if it's not at the internet edge i might not have a reserved public ip address for that router if that makes sense so think about like this let's say i've got two different devices hanging off of here and i've got some kind of i don't know some kind of internet modem router thing this is just a small branch site and then off of that i'm going to hang my 2v edges okay these two v edges are going to now have a private ip address 192.something or 10. something and they're not they're not on the internet directly okay and and this can happen by the way not just with internet connections but with a lot of service providers as well well they'll they'll hand off a a private ip address rather than a public ip address this can happen with some service providers usually smaller service regional service provider players and so if they're both nadded behind this ip address here we're using pat etc i can't come in and connect to that router it can come out and make the connection and that's great but how do these two routers forum avx vxlan my goodness an ip section how do they form an ipsec tunnel with each other this is a very difficult concept in fact any peer-to-peer application is going to deal with this on the internet without a having a man in the middle and that is exactly what the v bond is the v bond is the man in the middle it's the device that's going to help facilitate this because what we can do is we can have both of these devices reach out to each other at the same time this is called a nap punch through or pass through or any other kind of through type of deal with these gnats what we're doing is we're both reaching out the same time and our packets kind of cross each other up and come back in so when i send my packet out all of a sudden a return packet comes in or at least that's what the edge router thinks the device that's doing the nat so if the device that's doing the net thinks that it's return traffic coming in mission accomplished right i've i got my traffic i sent my traffic out the traffic came in that happened on both sides same thing over here came in at the same time it went out or what have you and so by doing that i can punch a hole through the net and allow them to communicate and form that ipsec tunnel the v bond helps orchestrate that and by the way the most important thing about the v bond that we need to consider is that this has to be behind well okay ideally it has a public ip address but it can it can be behind a one-to-one nat absolutely must have a dedicated public ip address because of this situation we need a man in the middle out on the internet if the v-bond is behind a nat and behind a really poor address translation right if it's behind a pat situation um ain't nobody gonna have a good time with this so um a lot of cases the v bond is deployed into the cloud it can be deployed into your own data center but it must be uh given a public ip address so probably at that point it would live in your dmz or something along those lines okay let's talk about topologies for this we're going to clear the whole screen i think as always you got any questions chime in let us know what you're thinking here okay topologies so there's two sides to this conversation one is how do we do how do we form these ipsec shouldn't say how we form them how what do these ipsec topologies look like let's start with that um i mentioned that you can connect to all of the different devices right so we're going to look at that and then we're going to look at what i'd alluded to earlier which is when i've got two connections what do i do with them okay so first of all we're going to start with the topology options what you're going to find with sd-wan in a lot of cases is that what we deploy is going to have to do with how we license it unfortunately it's just the reality of our lives where if i have a certain type of license then i can do things if i if i need more features then i have to go to a higher licensing level okay our topology we've got four different types of topologies we have hub and spoke oops hub let's say hubspoke hub and spoke we have point to point we have partial mesh partial mesh and we have full mesh full mesh like how my letters went from lower case to upper case eventually but either way so what we have is we have a bunch of routers and again this could be thousands of routers it could be dozens of routers it could be six routers and we're going to form some kind of tunnel topology so this tunnel topology will choose a color that shows up again it could be a hub and spoke so let's say my headquarters is up here hub and spoke is just like it whoops is just like it sounds where i've got a bunch of ipsec tunnels that connect all of the routers in my environment to my headquarters location or whatever my hub location is okay i could also have a point to point where i simply connect two routers that they have services that they need maybe it's a i don't even know a medical clinic and a research center or something like that where they are going to be sending a lot of information to one another you might as well just have a dedicated point to point rather than sending it back to hq having it get de-encapsulated processed re-encapsulated and sent back out right any traffic that has to traverse this go through hq is going to have to go through the encapsulation re-encapsulation process you're saying okay jeff why wouldn't we just do a partial or full mesh well that's because the anything above hub and spoke requires a license i have to go with a more advanced license i believe it is the highest level of licensing in cisco sd-wan if i want to deploy full mesh now as you can imagine with a full mesh full mesh is what it sounds like i can now build all kinds of oh boy what do i what do i gotta do here do do do i can only do one thing at once i already had the point to point there so i didn't need that one there is that all of them yeah something like that so now we've got a full mesh of ipsec tunnels going to all of these other routers in this environment so um yeah i mean that would be ideal but it also might not be necessary and so if i have the license for full mesh you'd think well we'll just go full mesh it might make sense to do partial mesh you might not need all of these different connections built for you know i mean if these two sites are never going to talk to each other they're truly just two bank branch locations or two restaurant locations that truly will never have communications with one another there's no reason to have this tunnel between them just one less thing that we have to worry about yes it's managed for us but it's one less thing we have to worry about getting a flag that tunnels down for some reason right so keep our topology as simple as possible if you've got an environment where all of these locations are going to be talking to one another then a full mesh makes the most sense absolutely so these are the four different let me check my notes here yes these are the four different topologies that we are going to look at doing and again a lot of it's going to depend on whether you are licensed for it or not hub and spoke if you're not licensed for advanced topologies then hub and spoke is going to be what you end up deploying next let's look at this concept of um i have room for this i think we'll i think we'll be okay so let's say i've got my v edge i've got my two connections and really my two connections of course are two tunnel connections this is what i really care about i don't care about the physical connections i care about the tunneled connections so now we need to talk about traffic forwarding let me go and change colors here there's always something else to cover something else to talk about traffic forwarding is one that we need to think about and the question is this as i bring traffic into this v edge what happens to it do i send it out link a or do i send it out link b and we covered a lot of different options earlier maybe these are the same bandwidth maybe one is a higher priority bandwidth or i'm sorry higher priority link maybe it's higher reliability let me just hold up let me just get rid of this what layer was that on it wasn't on that layer either all right there we go all right i'm just gonna get rid of this license word because it's in my way uh oops all right there we go so maybe maybe one is again high reliability but it's uh low bandwidth or maybe one is a high bandwidth but it's high cost maybe you're actually paying per megabit that you send across it i don't know what the situation is all of these concepts have to be taken into account with this traffic forwarding methodology and so we have four primary ways of figuring out what we're going to do with this and usually it's going to be assigned per application because i might have an application like voiceover ip voiceover ip doesn't need bandwidth it needs reliability so we'd want to send it out this link on the left but maybe we've got email or i don't know video conferencing video conferencing is important especially in this day and age we need a lot of video conferencing right now but video conferencing takes a lot of bandwidth and i don't want it to impact my voice over ips i'm going to send out a different link and so on a per application basis we're going to take a look at the different options that we have available to us the first option we have available is simply active active load balancing again i can't tell you how difficult it is you know load balancing i cannot tell you how difficult it is in a traditional way many of you know this to simply load balance traffic across two different wind leaks it's usually more trouble than it's worth and the fact that i just have two tunneled connections going out i mean total connection is like a virtual ethernet cable it's a beautiful thing and so the fact that i can just run active active load balancing is is amazing now the other option so this is the first option is active active load balancing the second option would be active active weighted and they're really two sides of the same coin because if if these are both 100 meg links then we do active active load balance but if it's if one's like 200 meg then we'd probably want to do it weighted now again because this is a per application configuration maybe this is still 100 meg but i actually want most of it to go out one link but some of it to go out another you know i mean the just event invent a use case for this we have total control i think that's the point we have total control over how these applications are going across our wan we did not have that with traditional wide area networks but we do have it with sd-wan next would be this concept of wait which one's next application pinning application pinning says that i'm going to take this application and basically now instead of active active this would be active standby so the idea here would be my application whatever this application is comes in and it will always use the link on the right unless the link on the right goes down at that point i use my standby connection i go out the other way so in a way we've covered three different concepts that are roughly the same in this case it's simply a hundred percent you know i'm weighted but i'm weighted 100 to zero or what have you however you want to think about it but we're saying okay this application again video conferencing i don't want you to touch the low bandwidth link i want you to go 100 out that big bandwidth link and if there's a problem with that or well i should say if it goes down then i'll swing you over the reason i clarified that is because of our fourth option our fourth option is called application aware and sla stands for service level agreement so this concept of sla if you've ever used cisco's ipsla commands on their routers etc is that we're going to be running active probes oh my camera shut off again oops we're going to be using active probes to go out or sending some i say this we're sending active probes out both of these links to test the quality of the link so in networking there's always this concept of yes if a link goes down then i need to respond to that what happens if a link doesn't go down but it's having major issues i mean do i keep forwarding traffic out it or not i mean if i'm running a traditional routing protocol my neighborship is up i'm getting packets in it might be dropping half of the packets i sent out but my neighborship is still up and so i'm going to keep sending traffic across that link and this is where you can use concepts like cisco ipsla and you can tie a you know a what is it called a track statement to it and so we apply that track statement maybe to um to our first type redundancy protocols or our routing protocols or shut down that link and swing traffic over it gets very complicated right i mean that's the whole point of all this and so it's going to be able to do this for us where i might say okay yes with video conferencing use the link on the right until the until it goes down that would be number three but i might also say use the link on the right unless jitter exceeds a certain amount because if general exceeds a certain amount then there's no point in using this link i might as well swing over to the other link by the way this works very well in reverse as well because what if my application is voiceover ip and i'm going out this reliable link well that reliable link might have a problem one day and if that reliable link is having major general issues i can swing this traffic over to the other high bandwidth link imagine doing this in a traditional lan i mean i a lot of configurations where i've got a high bandwidth link and i'm sending some stuff over there but i'm always sending my voice over ip out mpls it's highly reliable low bandwidth yes but super super reliable and so that's why i send my voice over ip across it even though it's super reliable it doesn't mean it's always reliable doesn't mean it's always going to be there and so if i'm having problems with my mpls link why can't i use this other link as a backup well with sd-wan we finally can do that in a seamless way by the way i keep mentioning that this is a per application setting the way we identify this application we can do one of two things cisco does include deep packet inspection as part of the solution but it does require a license okay so this is where again great feature but we might not have access to it license um if we don't have a license for deep packing inspection dpac inspection is basically going to look at the packet itself or the data inside look at you know within the headers and such try to figure out what this is okay and it's got thousands of different applications that can identify this way which is cool um if it can't if we don't have the license then we're going to use this concept of a six tuple which you know is source and destination ip source and destination port qos tag and um yeah maybe it's what what's the other what's the sixth one oh well um i'm sure i'm sure uh sure somebody in the chat maybe knows maybe i know by now but either way um it's going to identify the the packet based on more or less just information in the ip header that's all we can do at that point so it's less accurate but it will still help us identify our applications and then the policies that we define in vmanage will be able to apply to this traffic as it comes in it will identify that application based on the sex tuple all right so um i do believe that we are i do believe that's the end of it so hey we're almost right on time today just a few minutes over i apologize for that but thank you very much as always for coming to these sessions sd-wan again is very exciting hopefully you see why because it actually truly um it's a game changer it solves so many pain points and what we're going to find too in later conversations it can actually save money by allowing me to go with less reliable links and more cost-effective links and so because of that in a lot of cases sd-wan also pays for itself so you have the solution that can solve problems and that pays for itself over time and you see now why so many enterprises are racing to deploy sd-wan which by the way if you're not experiencing that yourself you might be scratching your head saying why why is the industry so abuzz about sd-wan well that that would be why um on top of all that of course cisco has a enterprise networking specialization that is sd-wan so we at cbt nuggets we are actively working on uh that right now we don't have a release date that we can speak to but i get to be a part of that and so hopefully very soon you'll find if you have a cbt nugget subscription that you'll find some sd-wan training that will help you go and pass that exam and if you've already passed the encore at that point get to your ccnp how about that so with that um next week we are covering the well we're going to keep talking about sd-wan we're going to talk a little bit about the the called the components of sd-wan all the different pieces that we need in a little more detail we covered some of those pieces in this video but this is very much an overview of what sd-wan does for us we'll be going over the next two sessions so each session is two weeks apart over the next two sessions we'll be covering more detail on sd-wan so hope you join us for that in the meantime take it easy we'll see you see you see you next see the next time yeah anyways check it out see ya [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] you

Channel: KishSquared

Views: 3,907

Rating: 5 out of 5

Keywords: cisco, sd-wan, encor, ccnp

Id: VMRlt_r6bO4

Length: 70min 0sec (4200 seconds)

Published: Wed Aug 26 2020