ENCOR - SDA Fabric Operation

happy wednesday everybody welcome back to another encore study group i'm super excited because we're finally going to be going over sda fabric operation it's what we've been driving towards for a while and we had to kind of take a detour just to make sure that we understand lisp and vxlan for example and a couple of other key concepts and so hey here we are we're finally ready to take a look so let's take a look at the agenda here what we're looking at today so even though we looked at lisp and we looked at vxlan list for the control plane and vx line for the data plane we're gonna have to take a look at one new technology today and that is cisco trusec cisco trustsec is what well it handles what cisco calls the policy plane so we have control plane data plane and policy plane that would round out the three different planes of operation that cisco says exists inside of an sda fabric so we're going to take a look at cisco trustsec and again that policy plane implementation then once we understand all of our different planes we'll be ready to look at what it looks like when a client comes onto the network how the network learns where the client is and how traffic flows as information is propagated around software-defined access uh nodes uh then we're gonna take a look at wireless how wireless differs from wired clients and there is a pretty big difference at least as far as how traditional wireless networks work uh between that and the sda world then we have to look at border nodes so then there's this whole concept of hey yeah it's great that we can exist inside of an sda fabric but how do we interface outside of the sda fabric which because chances are we've got a lot of clients that live outside of software to find access and when i say chances are i mean really we should have a lot of clients living outside of sd access because sd access is not designed to be the entirety of our network at least at least not yet not at the time of this video and lastly we're going to take a look at anacast gateways that would be a pretty quick conversation just a way to wrap things up to make sure that we understand how default gateways are handled in an environment where we've got clients living everywhere around our network and now we've got layer three segmentation between access switches with layer two extended between those access switches those fabric edge nodes and so anycast gateways are going to save us a lot of headache from just our devices accessing their default gateway so we'll take a look at that and how that compares to traditional infrastructure which usually relies on for stop redundancy protocols so let's go ahead and dive in here again first thing we need to look at is well first thing we need to look at really is cisco's uh cisco trust sec that would be cts or the policy plane but just a quick review here let's think through this so we've got lisp lisp is running at the control plane now if you happen to miss the last couple of videos that we've done the last couple of study sessions then this might be new to you the the gist of lisp is that we are going to track what we call the endpoint identifiers in most cases that would be the ip address of a client and we're going to track which routing locator or r-lock that client is attached to so if we have a client attached to switch one this client's ip address let's say it's 10.1.1.1 we would store that we'd say 10.1.1.1 is stored it's attached to switch 1. and the reason we want to track this from a list perspective or from a control plane perspective is because at the data plane we are running vxlan now vxlan is a tunneling mechanism that not only stores layer 2 or transfers layer 2 information but also layer 3 information such as vrf information and we'll talk about security group tags here in just a moment so what that means is once i know for example that traffic is coming in destined for switch well i guess destined for 10.1.1.1 switch to what thanks to lisp is going to know to tunnel that traffic via vxlan over to switch one again 10.1.1.1 is mapped to switch 1. so we send that out the vxlan tunnel and because the vxlan tunnel again transmits layer 2 and layer 3 information we enforce vrf data so if this is a multi-tenant environment with multiple organizations we make sure that those don't cross but also we might be having our source ip address might be 10.1.1.2 which is saying something because these clearly are on the same subnet and yet this is a layer 3 underlay so the fact that we can tunnel that layer 2 traffic through the layer 3 underlay is a pretty big deal and what it essentially allows is for us to maintain our campus infrastructures which for the most part our campus infrastructures are built on layer two layer two to the access layer there's all kinds of debates about which is best layer two or layer three and finally we have a solution that says hey let's do both let's do all the advantages or provide all the advantages of layer 3 no spanning tree no broadcast domains or not stretched broadcast domains we push layer 3 out to all of our edge devices and then we rely on vxlan to actually deliver the other benefit or the benefits of layer 2 which is clients on the same subnet and being able to broadcast to one another so again really truly sda is the best of both worlds it's the best of layer 2 to the edge and the best of layer 3 to the edge we always appreciate that so that's the quick very quick review of the last study session where we went over lisp in vxlan again if you missed that it's probably worth tuning into because lisbon vxlan are two protocols that are they sound complicated and i think they intimidate a lot of engineers i know and they greatly intimidated me when i first learned about them but as i dug into it and as i learned about it oh you know what this isn't so bad it's actually really cool set of technology a really cool set of protocols and at a minimum software defined access relies heavily on lisbon vxlan and so if we're going to be deploying software-defined access into our infrastructures then we need to understand where these protocols are or what they're what they're trying to accomplish so on to the world of cisco trust second cisco trustsec is again existing at what we call the policy plan let me write that cts cisco trussec exists at the policy plane so we have control plane data plane now we have policy plane in traditional networks we don't really have a policy plane of operation the best we could come up with is maybe the management plane on top of control and data planes but this policy plane is a new concept and what's essentially doing or what it is essentially accomplishing for us is enabling for us to deliver policy effectively into the sda world when i say policy for the most part i'm speaking about access control policy which is a security concept so we're thinking about things like making sure that what if 10.1.1.1 is not able to communicate with 10.1.1.2 in a traditional networking environment we'd maybe think about deploying an access list right to to an svi or switch virtual interface which is a vlan interface so we would apply access lists and try to block this behavior but svis the default gateways are not consulted in a layer 2 world so if 10.1.1.2 was going to speak directly to 10.1.1.1 that's going to happen at a layer 2 level never hit a vlan interface which means our acl is completely ineffective but we're not we're not comfortable with that in an sda environment we want rock solid robust security we want to be able to block this communication even though it happens at a layer two level and cisco trusstic is how we're going to accomplish that now cisco trisec has been around for a long time it has it was not developed for software-defined access or sda it's just the tool that we're going to to be clear none of these protocols were developed for sda one of the beautiful things about software-defined access is it takes protocols that already existed and uses them in a new way so we're not reinventing the wheel here we're simply taking components like list from the service provider space and vxlan from data center and cisco trustsec from the security world and we're combining them all to create a technology that by and large is going to deploy a lot of this for us the automation elements are real in this solution set here's here's how cisco trustsec primarily works we have this concept of scalable groups or sgs a scalable group is going to determine for us um how do i get this we group together similar clients into a scalable group so in other words we create one scalable group and let's say 10.1.1.1 is part of this scalable group as well as a bunch of other clients maybe there's 100 clients all in the scalable group then we create another scalable group and 10.1.1.2 is part of that along with 500 other clients in the scalable group by aggregating our clients into logical groups like again what we have here these scalable groups what we can do is we can define policy between these groups in a way for those who have worked in the security world this is going to sound a lot like a zone based firewall because in firewalling we used to have it where you know if you have three interfaces on a firewall maybe even like four interfaces on a firewall you're gonna you have to create a full mesh of access control lists as traffic tries to traverse all of these different interfaces but really you could look at and say well these are two inbound inter or internal interfaces and these are two external or outbound or out well okay put an e external interfaces and so the zone based firewall concept says okay well this is a zone and this is a zone we'll just reuse our you know e there there we go so we have two different zones we just need to define policy between these zones that way it doesn't matter if it arrives on interface one and interface two and whether it's destined for interfaces three or interface four it doesn't matter anymore we don't have a full mesh because really we just have two zones and we just have one policy between those zones very similar concept here rather than having a policy that directly tries to block communication between a bunch of different clients or among a bunch of different clients place them into two different security groups and define one policy that that determines how we can communicate between those two groups so so this is a concept by the way that we call micro segmentation you've probably heard this term it's been around for a while micro segment i'm not even done right micro segmentation what a long word that is i almost never write it all out when i'm doing whiteboard and that's why i thought i'd just go ahead and do it micro segmentation wow key word there being micro because really what this is is we're we're creating segmentation down at an extremely granular level to a point that we can specify that ten one one one well what did i say ten one one one two here can't communicate with ten one one one one that's micro segmentation that's anything about micromanaging right when somebody's like hovering over your shoulder telling you exactly what to do that's what we're doing we're hovering over the network shoulder and we're saying hey these two clients they can't communicate with one another so that's this concept of micro segmentation it's a big deal inside the data center because inside the data center we want to make sure that clients that are on the same subnet can't necessarily speak to one another because we data centers like our golden goose right i mean all of our eggs are in the data center and so a very fit i call it famous really an infamous example of this was targets breach target the the stores of the um worldwide i guess i don't know what they are retailer yeah retailer they got hacked really badly a lot of their information was stolen and the way that it happened was the bad guys went in through a effectively an hvac system i believe it was a vpn that gave you access to the to the system and so on the one hand great the vpn really only gave access to that one hvac system but then on the back end of that the hvac system was on the same subnet as the credit card machines and it's really really hard to say to deploy policy against that because again that traffic never hits a vlan interface and so even though says target i'm sure had a ton of security mechanisms in place at the svis and layer three boundaries and firewalls and everything all of a sudden you just have the weakest link and easily compromise relatively so i'm sure hvac system that once the hvac system is compromised it's got access to the credit card machines none of us would ever look at that including target and say oh yeah that was by design that's exactly what we want it simply is an issue of how exactly especially back when this happened in the early 2010s how exactly do we stop that from happening certainly we could place them on different subnets that would have been a the right answer in that scenario but at the same time now we've got the tools to deal with that and one of those tools is cisco trustsec so how are we accomplishing this well the way we're accomplishing this is with a concept called a scalable group tag or sgt again if you live in the security world at one time these were called security group tags i was told by cisco that it actually started as a different name and i can't remember what it was but sgt has evolved several times as security world got a hold of it they changed it to security group tags and as the sd a world got a hold of it they renamed it to scalable group tags but again sgs being scalable groups and now we've got scalable group tags what's effectively going to happen is that the packet itself is going to be given a tag it's going to be tagged and that tag is going to be embedded inside the vxlan header so we recall i think i recall i hope we talked about this cisco's implementation of vxlan let me change colors here that work cisco's implementation of vxlan is called vxlan dash group policy option so vxlan gpo cisco invented this as a way to carry the scalable group tag inside of the header so it's a slightly different header format it's only going to work with other devices that are speaking vxlan gpo we couldn't do this for example to a non-cisco device that you know vxlan is a standard and we could form a vxlan tunnel but we wouldn't be able to use vxlan gpo since that cisco proprietary or at least they'd have to deploy i don't know offhand if it's cisco proprietary or not certainly they created it i just don't know if they've open sourced it so now we can carry the scalable group tags in there along with by the way that concept of the virtual network identifier so the vnids every now and again we call that a vni virtual network identifier either way so the vnid vni this is a lot of us think about this as like as if it's a vlan id which i guess it sort of kind of is i mean we're all too often people a lot of situa learning situations it's explained that vx vlans are evolving into vx lands and we had 4 000 vlans and now we have 16 million vx lands and that's true but we're not like it's not a one-to-one replacement we're not like replacing vlan with vxlan and so this analogy breaks down pretty quickly really what we're doing is we're going to use the 16 million different segments as as different vrfs in other words each vxlan segment is going to be its own entire routing domain and so what this the reason why this is a big deal is because in service provider spaces where we actually had problems with hitting the 4000 vlan limit well now i can deliver all 4 000 vlans to every one of my customers because i can just assign one vxlan per customer so now i've got up to 16 million different customers that i can support instead of four thousand and on top of that before every customer effectively got one vlan now every customer gets four thousand vlans um again that's a that's the service provider data center world where vxlan came from but the reality is that we still have this concept of a venid inside of vxlan and so what we can do is we can map this to our virtual routing and forwarding instance or vrf the vrf comes back to exactly what i just said what if we're running an sda fabric as a service provider what if i have a bunch of different customers maybe i'm managing some kind of metronet and i've got these devices i know i've i've configured this type of network before so i know it exists we've got devices physical devices a bunch of different metro sites and every one of those metro sites we can bring multiple customers into those metro locations so if we were to deploy sda on top of that i'm not necessarily saying it's the best solution for that situation but we could deploy sda over that but at that point we have multiple customers on a single sda fabric well the way we distinguish it we would distinguish those customers from each other would be a vrf id which effectively becomes a v-net or vni so this is the concept of macro segmentation i probably shouldn't bother trying to write that all out we'll just say macro segment dot and um the macro segmentation is going to tell us again organization to organizational um allow us to block traffic from going to another one another from one to another all right um let me clean this up if you have i didn't say it at the start by the way um for those who might be new and you're watching this live absolutely chime in to the comments i am you know this this has been pre-recorded so i am in the comments section or the i guess the live chat it's not comment section the live chat i'm answering as questions as as they come up so be sure to chime in with to the chat any questions you might have given that this is an encore study group if you are studying something other than software to find access right now then absolutely chime into the chat ask your questions we've got a bunch of people in here who are studying for the encore who are otherwise just able to answer those questions and again i'm there as well so i'm going to be doing my best to answer everything as it comes in so if you have any questions about any of this be sure to ask i'm going to go ahead and clear the screen here well i'll leave the vxlan stuff there um i'll i'll leave that as well all right mostly i just wanted to gain access to this drawing again so now let's say i have actually let me change colors again now i've got clients let's say that this client is part of organization a and this client and we'll draw down here this client is also part of organization a so organization a it we can't tell organization a not to use 10.1.1. i don't know whatever the subnet is 0.24 can't tell the customer yeah our customer we can't tell the organization not to use an ip address so they might have 10.1.1.1 attached to the same switch and 10.1.1.2 attached to the same switch over here this is a legit situation so what are we going to do well fortunately this is organization b and this over here is also organization b so two different organizations but we've got the macro segmentation concept in mind so when the traffic shows up on the switch once traffic arrives on the switch it's going to identify which vrf it belongs to and as a result it's going to identify it's going to map it to rv nid and put that into the vxlan header so again that's the macro segmentation so ultimately what we have is we have this concept of virtual networks and each virtual network is going to effectively represent an organization so we might have organization a on the left organization b on the right and within each virtual network we can have multiple scalable groups so i can have a let's say scalable group maybe 10 and 20 on the left and maybe on the right as well but the point is i can add as many scalable groups as i want per virtual network so virtual network again macro segmentation high level organizational level scalable group micro segmentation nitty gritty right i'm drilling into a network and telling the network which hosts can communicate with which hosts hopefully that all is making sense let me make sure oh yeah so i mentioned that the vnid gets assigned on ingress so does the scalable group tag and again once we embed that into the vxlan packet and send it across once i uh one when the oh yeah we'll just finish that so once i receive that we're going to check the v nid is this trying to go to the wrong interfaces is trying to go from organization aid organization b if so i can drop that traffic or maybe it's good okay if so we're good check mark now we're going to check the scalable group tag does the scalable group tag allow me to go to the client that i'm trying to get to so is 10111 able to communicate with 10.1.1.1 and if not at that point we are going to drop that traffic now note that this does violate one of our favorite security rules which is to drop traffic as close to the ingress of the network as possible it would be lovely for us to look at this and say well switch one should have recognized it was going to get dropped and just dropped the traffic because instead what we did was we sent that traffic all the way through the network which might have been across two three four network devices inside the underlay who knows and so we had to process that it consumed network bandwidth it got all the way over to the other side and only to get dropped why didn't we just drop it sooner the primary reason for that is because of policy sprawl this concept that if i have 10 000 devices in the network and i expect this device right here to drop traffic regardless of where it's going in the network i'm i'm gonna have to have the policy for every single part of the network right there in other words i'm gonna have to be able to know the entire network's policy on every single device in the network whereas the opposite direction if it's as traffic comes in then this device really only needs to know the policy for anything that's downstream so it contains the amount of information that i need to know on a per node basis so you just ultimately have to decide i mean it's going to consume resources regardless and cisco decided to consume the resources inside the underlay because the underlay resources are pretty cheap quite frankly i mean we're not this isn't a situation where we're deploying this across like uh you know nexus 7k switches or you know the highest end catalyst 9600s our internal uh intermediary nodes should be pretty cost effective nodes and we should have a lot of bandwidth in there because that that's pretty cheap these days and so better to make it so that we're consuming network bandwidth than to drastically increase the cost of all of our switches that's the theory behind why cisco did this the way they did it but just just be aware of that it's an interesting conversation for sure okay moving right along oh yeah all right 23 minutes i like it the wrong thing there we go all right let's go ahead and clean this up again i'm just going to clean it up all the way so let's let's take a look at what happens when a client comes on line and there we go so we have a client uh and we've already talked a little bit about this but i just want to like this what we're about to talk about like if you can understand this from start to finish then you have a good grasp of software defined access this this right here is sort of the culmination of all of the information that we've been processing and and after this we're gonna again talk about wireless uh how that differs uh as well as a little bit of you know border node connectivity anycast gateway just things that like layer on top of it but like this is the concept all right so first of all we have a client that shows up and our initial fabric edge node that would be an access layer switch in most cases our fabric edge node is going to inform the uh you know what i should have yeah that's fine we'll just go around we're going to send a map register message this is a lisp term lisp likes the map stuff map registers map replies negative map replies um now i think there's even a map yeah map response so maybe maybe i'm making that up but either way we're going to send this map register message to the control plane node now in the lisp world again that we've got some terminologies here um that even though we're in the sda world we still use the list terminology quite a bit so this is our map server from a lisp perspective the control plane node is a map server we remember that there's a map responder the mr that is really meant more for scale and so lisp lisp is designed to be able to scale out to thousands of nodes in the service provider space we're not usually dealing with that in an sda world because the sda is supposed to represent a single site and even though you can stretch it to other like you know maybe other buildings on your campus it's still really not you're not going to see the same scale and so we combine those roles onto the control plane node it's just one device i mean you can deploy a couple for redundancy you should deploy a couple for redundancy but we're not scaling this out at lisp levels so the map register message is sent and um we get an acknowledgement back so okay we we know now where this um oh wait okay what are we registering sorry skip that step um what we're registering is the endpoint identifier so in our case let's just call this again 10.1.1.1 so it'd be 10.1.1.1 and we're going to map that to the routing locator another lisp term so the writing locator again being the fabric edge node in an sda environment to which that endpoint is attached so this will be mapped to switch ones switch one switch one's ip address and you know the the the routing locator for switch one interesting by really by the way um that switch is also going to alert the control plane node to the virtual network identifier to which we're attached so uh i don't call this out a lot so um really what i should do is i should put that up here so i don't call it out a lot because for the most part we we kind of get it and the v-net is tracked through the environment but when you look at the control plane node it is going to track the endpoint identifier to the routing locator as well as the v-net to which it's attached um and so the routing locator the switch one in our case the the ingred i guess the switch receiving the new endpoint is going to inform the control plane node of that information so let's just call this organization i think i think we said organization b was blue now well um i believe that's the case so organization b in this situation i'm we're not going to deal whole lot with multi-tenancy for the rest of the time but just worth noting um let me double check where where we are so the endpoint identifier by the way one thing to note in an sda world is that this is effectively a slash 32 route it is a host ip address in the lisp world where in service provider land we're primarily dealing with subnets because we're not dealing with a in a layer 3 service provider environment you're not going to have subnets that are split among locations so really what we're doing is we're not advertising hosts we're advertising subnets i've got the 10.2.0.0.16 or what have you attached to switch 2 it would advertise that into the lisp domain but we're not doing subnets in sda we are doing endpoint identifiers that are the endpoint identifier is going to be the ip address for our end host um okay so next let's say we've got another device here that attaches this is our 10.1.1.2 so same thing we'd send a map register control plane node now knows 10.1.1.2 is attached to switch 2 which belongs to organization b uh that vnid would actually be an identifier not literally a string called orgb or anything like that it would probably be a number like i don't know pick a number between 1 and 16 million 5 million 235 631 you know or whatever it is so now traffic is going to arrive on switch 2 with a destination ip address of 10.1.1.1 okay this makes this device in in [Laughter] an ingress tunneling route or an itr my brain split on whether i wanted to give the acronym or not the itr the ingress tunneling router is is going to receive the traffic that has to figure out what to do with it we already know you know spoiler alert that switch one in this case is going to be the egress tunneling route or the etr itr and etr those roles will always flip depending or will always represent the direction of traffic flow so itr will be where the traffic is received initially etr is going to be where the itr sends it etr will de-encapsulate it and send it down to its final destination so again just i want to make that part clear if the traffic reverses and 10-1-1 is sending it to 10-1-1-2 switch 1 would be the itr and switch 2 would be the etr just want to again make that clear so the relative roles to the specific traffic the specific flow of traffic all right so we're going to send a map request let me go and change colors here just to start to differentiate we are going to send a map request to the control plane node to find out where in the world this ipaddress lives and and i want to pause on this for a moment because this let's not just jump past that we live in a world from a networking perspective that if i've got a network and i'm running some kind of routing protocol like eigrp or ospf or what have you and if i am attached here and i send my traffic upstream that network or that this device right here has to know every possible destination in the network it's got to have a complete routing table completely filled out yes potentially with the default gateway default gateway would would work if that's d g w there we go if my default gateway is part of the writing table then i do have a route to everywhere uh because i can just forward it out to my default gateway but that doesn't necessarily work especially in the service provider world it's one of the reasons why the routing tables are so huge in the service provider space bgp tables are are approaching where we say about a million routes in the routing table but but the fact that this router has to know everything is is interesting because we've never really thought at least i've never really thought about the fact that yeah that's that's we're pushing information like all information everywhere it's why we have things like rap summarization and default gateways is because we want to minimize the amount of information they have to have to have all the information so that router sends it up to this router and this router also has to have a routing table with all of the information and then i send it to the next router and it's got to have a routing table with all the information so that it can finally arrive on subnet a or what have you it's just interesting that our networks have always relied on this concept this push concept i'm going to push this information everywhere when when really that we could have developed networking to have an authoritative source somewhere out here such that when this packet arrives on the first router it sends a message to this device and says hey where is subnet a and that device just lets it know like oh okay here's where subnet a lives i forward it out to this router and this router does the same thing and and at that point we start to see the inefficiencies but the same time there's nothing wrong with that idea and that's exactly what we're going to be doing in the sda world this concept is a often talked about in the software defined networking world it's called control plane data plane separation and what we're doing separation what we're really doing is we're saying all right the data plane can exist on the routers it can store a routing table but instead of running a routing protocol instead of exchanging information with each other we're going to have an authoritative source somewhere else that we just check in with so we're going to pull that information right again rather than pushing it everywhere i'm simply going to pull the information down when i'm ready for it think about what that does from a resourcing perspective on the router itself i no longer need to have a beefy cpu such that i'm running ospf uh you know hello packets every so many seconds i'm not running bfd like we've talked about and um you know the resource requirements go down now clearly we still have to have something that knows everything and so we're kind of moving our resource needs off box to to this device off the data plane that just exists somewhere that has all the information but in a weird way that reflects what we do with cloud infrastructures because we're pushing a lot of stuff out to the cloud such that i i don't even need to necessarily run applications on my pc i my i use an art program on a website i don't have to install anything onto my computer it's just a dumb terminal so to speak i've got my web browser open and i do all of my edits for my youtube thumbnails and everything in this application that's just a web tab now because all the processing is in their data center so it's just this is kind of interesting like i said i just didn't i didn't want to run past that concept because it's really when you start talking about control plane and data plane separation it's hard at first because we've always had control and data plane on the same device i've always had a router that has not only a routing table but the control plane that populates that routing table i run eigrp or ospf or bgp or isis or heaven forbid rip and i run this control plane to get all the information and that control plane populates the data plane so that now i've got a routing table and cisco builds a ceph table off of that and and we we know how to forward traffic based on that but there's just because we've always done it that way doesn't mean that we're necessarily always going to do it that way and indeed pulling the control plane off of these devices is the way that we do pretty much all of these software-defined infrastructures sda works that way sd-wan works that way cisco aci works that way as well okay so all very interesting stuff [Music] where are we where are we at because that was a distraction i think a good distraction um checking time okay so let's just kind of get back to where we were so this packet arrives um i'm on the wrong layer there we go so this packet arrives on switch to switch 2 doesn't know where it is it sends the map request and i get that map reply back i'll write it up here map reply get sent by the control plane node down to the switch um one interesting note by the way um this is this is probably more information than we all need for encore but it's still worth noting um in traditional lisp the control plane node or the map server is not going to respond directly to um it's not going to respond directly to the the map request it will actually forward that map request down to the appropriate etr allow the etr to send that information to send the response and the only reason for that is just to make sure that nothing has changed make sure that we've got all the information and allow that it also makes it so that the map server isn't doesn't get bogged down by things the uh the map responder uh but but that option has always existed in lisp to directly respond to the map request and in the sda environment uh that node is going to be by default configure to respond directly so it's going to respond directly to switch to switch to i'm sorry yes now switch 2 this is the interesting thing we form a cache so remember we just talked about how you know we're going to pull this information down where are we going to store it we're going to store it in a cache we're not going to call it a routing table because it operates a little bit different but ultimately it sort of is a routing table i mean this is our data plane information and so now we are going to know that 10.1.1.1 is attached to the routing locator for switch one so probably a loopback address or some other layer 3 way of routing towards that fabric edge node so now i can look it up i can look that information up when the the packet arrives incidentally by the way um what do you think that switch 2 is doing with this packet that we that that we've um we've brought in that packet arrived destined for an ip address and in the meantime my cache was empty we skipped that step i didn't say that specifically but switch 2 does check its cache first and if the cache is empty then it's going to send the map request but switch two isn't going to just like stop everything and wait for that response to come back i mean that packet might get dropped the map server might be completely overwhelmed it might take a long time to respond and so this traffic is actually going to get dropped that's kind of an interesting thing that we just you know i mean packets get dropped all the time and networking but our inclination might be to believe that on some level that we want to protect that packet we want to make sure it gets to its final destination that's not what happens it's just going to drop that traffic until it gets a populated entry in the cache so that packet arrives on switch 2 it gets dropped in the meantime we do this whole process we populate our cash now we know where it is so you know hopefully ideally in a low latency not overloaded environment we get a response back by the second packet so ideally by the time we get a second packet in you know maybe maybe that we would time out on that tcp packet so we send it again or what have you or maybe it's a udp stream and it just kind of keeps sorting traffic hoping that it gets to its destination either way that next packet arrives now we've got a cached entry and now switch 2 knows as we said earlier to throw it into the vxlan tunnel that it has already established with switch 1. the vxlan tunnels are all up in an upstate constantly we don't dynamically build those up and tear those down the vxlan tunnel has been established already and now we know which vxlan tunnel to send it out so we're going to send it towards switch one switch one receives it dean encapsulates it and let's not let's not miss the important part once it de-encapsulates it it's going to see that it has a virtual network identifier and a scalable group tag and it's going to enforce the policy that we have specified with those identifiers so again vnid making sure it's part of the same organization that's macro segmentation that'd be our vrf identifier effectively assuming that looks good which we already know from our diagram they're both part of the same organization both part of the same vnid so that part checks out uh check mark there and then we've got to check the sgt the scalable group policy can 10 1 1 1 10.1 speak to 10.1.1.1 if so then check the box we're good there and we forward the traffic down but do not skip this part the policy evaluation is very important i mean cisco specifically calls out that there's a policy plane as part of an sda environment and so we absolutely do not want to forego that that part of the process uh all right so let me just double check my notes here and make sure that i think we've covered everything i guess the only thing to mention worth mentioning is that this cash every entry lasts 24 hours um of every i would say uh it's 24 hours of inactivity after 24 hours of inactivity it will drop an entry from its cash so the cash it should stay populated um uh you know this this concept of dropping the first packet that we talked about is interesting but it shouldn't affect much at all uh is you know this cat these caches can get pretty sizable i mean it's it's all of the information for anybody we're actively in communication with or have been over the last 24 hours but again that's the cool thing about it is it's only the information for the devices that i'm currently sending traffic towards i don't have to know where everything in the network lives at any given moment in time in case i get a packet destined for one of those locations right i can just rely on the fact that if i don't have that information i know where to go to get it okey dokey um wireless let's we're gonna have to uh step it up just a little bit here we're doing all right on time we got another 17 18 minutes or so um all right wireless now a lot of the same principles are going to apply i would just learn i mean ultimately we're still using vxlan tunnels uh we're still using the control plane node we're still mapping endpoint identifiers but there are some differences first of all when i attach an access point to the network the first thing that has to happen is that this switch one i mean it has no idea that this is an access point and not a an end client i suppose and so it's still going to send uh the the map register to the control play node and and so we're going to have an endpoint identifier to the writing locator mapping for that access point so that's interesting incidentally by the way the virtual network identifier the vrf is going to belong to what we call the infrastructure vrf it's the vrf that all of these devices belong to so this access point will be able to directly route to this upstream switch and any other switch in the infrastructure the access point is going to use that connection by the way to connect to the wireless lan controller where in the world is the wireless lan controller in this environment well the wireless lane controller is going to have to exist upstream of the sda fabric so we've got some kind of fabric border node here and that's connecting into the rest of our network we're assuming that's a layer 3 network and that wireless line controller is just going to have to connect up there so it can connect to the layer 3 infrastructure it could by the way connect to the border node that would be fine we have options there it just can't be hanging off of a fabric edge node somewhere it can't be inside uh the sda fabric that that wouldn't work so right away the first thing that's going to happen this should look familiar is the access point is going to form a cap web tunnel to the wireless lan controller this is nothing new we use this for control information in traditional wireless we're going to use it for control information here as well radio resource management for example images updating access point images it'll download the latest you know version of code for example from the wireless lan controller when it first comes online it'll get all of its information that way life is good however in an sda environment if a wireless client connects to the access point in a traditional infrastructure it would send that information or that client out the capweb tunnel anybody see a problem with that in the sda world i mean we just talked about the policy plane and the security group tags or scalable group tags there you go i tripped up on it the scalable group tags and the virtual network identifiers the macro micro segmentation all that policy framework is going to be completely bypassed if we send it out the cap web tunnel because it's just going to go in a tunnel and get forwarded through the infrastructure to get to the wireless lan control wireless lan controller will encapsulate it or de-encapsulate it and send it back out onto the network that's what it's designed to do in traditional infrastructures we do not want that in an sda world we want that traffic to arrive on the switch on the fabric edge node so that it can send it through the sda fabric and have it land on a switch and get enforced like it traditionally does um so that's that's one good uh yeah i'll come back to that all right so i'm getting a little my ahead of myself here but that's all right so we're gonna talk about the data plane and control plane from a wireless perspective i was gonna do control plane first but we're talking data planes let's keep going with the data plane so what's going to happen here is the a axis point is going to form believe it or not a vxlan tunnel with the upstream fabric edge node that means that these access points are capable of running vxlan which is really cool i wouldn't have necessarily expected cisco to deploy vxlan technology onto access points but yes these access points are capable of forming vxlan tunnels now we are not what we don't have on an access point is the ability to run lisp okay so we're going to get to that in a moment because you know this whole control plane node thing is kind of important and registering information so you know we want to register these clients somehow and so we'll we'll handle that in a moment here's what matters when this wireless communication hits the access point it's not going to send that wireless data through the capweb tunnel it's going to send it through this vxlan tunnel which means it's going to land on the fabric edge node a fabric edge node at that point will de-encapsulate it and treat it like a normal packet it'll it'll do its map register i'm sorry map request information get a map reply populate the cache figure out where it's supposed to go and send it off via the vxline tunnel to its destination wherever that is same same concept here if a packet arrives from somewhere out on the fabric for this device and it's destined towards a wireless client it's going to send it through that vxlan tunnel to the access point allow the access point to encapsulate that and send it down so yeah that's the yeah that is the gist of what i want to cover from a data plane perspective we're using the vxlan tunnel instead of the capweb tunnel yeah okay the one other thing i'm just going to check my notes here as far as that's concerned in order for this to occur this access point has to be directly attached to the fabric edge node so in theory we could have like a downstream switch hanging off of this fabric edge node and our inclination might be to attach an access point there for whatever reason but we're not allowed to do that in an sda fabric we have to directly attach it up to the fabric edge node so be aware of that in your designs all right so what's going on with the control plane because we just said this is a big problem lisp cannot run on these access points so how are we letting the control plane node uh know about all of our wireless clients well the answer here is wireless lan controller the wireless lan controller is lisp capable and so what we're going to do is when a client arrives on the access point the access point will i mean it's going to do what it normally does it registers that client with the wireless lan controller that happens regardless of whether it's a traditional or sda environment and so once the wireless device has been registered on the wireless lan controller it will send a map register message to the control plane node on behalf of that wireless client or on behalf of the access point however you want to say it so now we know that the we have an endpoint identifier mapped to an r-lock and the question at this point is what's the endpoint identifier and what is the r-lock well when we're registering this we're registering it at a layer 2 level which means that this endpoint identifier even though it's usually an ip address it's going to be a mac address in this case so it's actually the wireless mac and it is being tied to the switch one the fabric edge node um in our case it would be the switch switch one so technically we could use i mean the access point is vxlan capable we could use that as a um as as our attachment point but what think about what that means if i have um if i've got i'm just trying to think here let's say i've got 10 network switches fabric edge nodes and i've got 100 access points i mean that's not a huge environment but at that point if i'm registering my access point as the routing locator that means that if i've got another access point over here that needs to communicate from one wireless client to another then i'm going to form my vxlan tunnel from here to the access point and i've got 100 access points which means that if i'm going to have a full mesh of vxlan tunnels that's a lot of vxlan tunnels terminating on an access point so i think it's really cool that cisco gave us the ability to terminate vxlan tunnels on these access points but i don't think there's enough resources there to cover a hundred vxlan tunnels instead we create one vxlan tunnel and that allows but but in order for that to happen what that means is if we're going to send traffic to this wireless client we need to destin our traffic for the fabric edge note which is why the routing locator that we register from the the wireless lan controller is registering that end device as being attached not to the access point but as being attached to the upstream fabric edge node i hope that made sense please ask questions if that didn't make any sense um but just to repeat one more time the endpoint identifier for the client is being mapped to the routing locator for the fabric edge node not for the access point okay so we dust in our traffic for the upstream fabric edge node this upstream fabric edge node let's say his traffic arrives here it will de-encapsulate it realize where it needs to go and forward it down via its vxlan tunnel its little separate vxlan tunnel dealio to the downstream access point all right that that is about that one other thing i guess again this is a big deal from a wireless perspective what happens if this client roams from one fabric edge node to well from one access point to another but ultimately from one fabric edge node to another at that point the wireless line control is going to step in it's going to perform a map register to our control plane node and let it know hey this device has now moved it's attached to a different routing locator and so life is good there so again the routing the the wireless lan controller is going to handle all of our lisp functionality for us from an access point perspective so just that's that's the bigger takeaway or the big takeaway from that uh all right we're going to race through border nodes and uh any cast gateways we might run a few minutes over here's hoping we don't there's not much to this conversation but we we have mentioned a few times this concept of a border node the border node is a node that sits between the sda fabric and the non-sda domain so this is basically everything else this would be our network core this would be our data center this would be other sites our wireless i'm sorry we're not wireless our wide area network our wan would be out here sd-wan space so there's a lot of devices that aren't part of an sda fabric and we need to know we need to be able to get to those so the way this is going to work is cisco gives us actually two different types of borders border nodes we have the internal border node which i'll just draw there and then i'll draw down here we have an external border node which really cisco actually started calling this the anywhere border node and so you'll still find documentation referring to it as external but for the most part we call this an anywhere border node at this point so two different types of border nodes now these can be combined onto the same heart piece of hardware so at that point it's called a hybrid border node but just understand that there are two different roles that we're playing here internal and external the internal is going to connect to the rest of our network so in some way we're running usually in igp probably ospf or eigrp and we're exchanging routes normally between these two devices once it's an internal or if it's an internal border node the internal border node is going to do all of the normal stuff with this control point node it's going to do for example map register it's going to register at this point we're talk we're registering subnets so any subnet that i learned from ospf let's say i will be injecting into the sda domain by performing map registers to the control plane node that way when traffic arrives on a device and it's destined for something out here let's just call this 10.100.1.1 so 10.100.1.1 it's going to send its map register map request trying to go a little too fast get the map reply back with the routing locator for my internal border node because this has been registered we know that the 10.100.1.0 24 subnet is mapping to the the internal border node so i get that routing locator and now i know that i need to encapsulate that into a vxlan tunnel and send it up to the internal border node that's a internal border node is basically a fabric edge node um as far as its operation is concerned it does all the same map register map reply you know if traffic is coming in to the internal border node and it's destined for something inside we've used 10.1.1.1 as our example so we'll use that again here we'll we'll do the map right again moving too fast we will do the map reply map request we'll do the map request to the control plane node we'll get the map response back and so it can send its traffic out the appropriate vxlan tunnel as well so internal border nodes again not a whole lot different than anything we've talked about up until now the anywhere border node the idea here is that this is where the you know i'm sure the internet lives but really it's our default gateway on some level we're sending all of our non or all of our catch all traffic is going to be sent to an external anywhere border node the way this works is when i have a device that's sending traffic to something let's just say it's something on the internet now 50.1.2.10. well same thing i mean switch 2 doesn't know any better it's going to perform a map request got it right that time to the map to the control plane node control plane node is going to send back a negative map reply the negative map reply means i checked my database and i don't have a clue where this device is at that point in a traditional environment we might say well we just have to drop the traffic then because we don't know where that is what's actually going to happen is we're going to send that in a vxlan tunnel to the external border node the external anywhere border node i i learned it as external then cisco changed the name to anywhere so call what you want but the anywhere border node then is going to receive that and send it on so the difference between an internal and external is that remember an internal is performing these map register messages via the control plane node we're not doing that with an external node the assumption here is that anything upstream of an external border node specifically the default route doesn't need to be advertised in so if we're running bgp and we've actually got a lot of internet routes because we're running partial bgp to an internet service provider or what have you we have an internet edge situation it might not just be a default route it might be a list of hundreds or thousands of public ip addresses but because it's an anywhere border node and again effectively it's a default route as far as sda is concerned we're not going to register any of that with the control plane node so that's the big difference between an internal border node and an anywhere border node the anywhere border node does not register its upstream subnets with the control plane node okay um one other note which we don't have time to get into here because we're truly uh running out of time at this point um there is this concept of a fusion router some of you have probably heard of it i'll try to squeeze this in did that get in all right barely the concept of the fusion router would largely well you know what i put it in the wrong spot the fusion router is going to help our internal border nodes sometimes we're going to need a fusion router right here the reason why we need a fusion router is if we have a multi primarily if we have a multi-tenant environment we need to do vrf route leaking if that all sounded pretty scary and you're not doing any of that then don't worry about it but if you have multiple organizations hang off your sda fabric you need to for example share a default route you need to share a dhcp server anything that we need to use vrf route leaking for we're going to require a fusion router in order in order to accomplish that so knox hutchinson had some have some great material on how to configure a fusion router as part of the cbt nuggets sda skills one thing to know about the fusion router is we are responsible for this we as the network admins are going to be logging in via cli the old-fashioned way and configuring this fusion router dna center does not help us configure fusion routers at least as of the time of of the study session i'm sure that one day cisco will include that that would be wonderful all right as promised one very quick section on anycast gateways and yeah we're like basically right out of time so about five more minutes i think we'll be good the the ending cast gateway comes down to this conversation if i draw this out logically what i have in an sda space is the ability to run a subnet stretch a subnet among different edge devices so i've got my 10.1.1.1 here right next to my 10.1.1.2 you know we know that they can communicate via layer 2 and we know that physically what that means is they're going to be vaulting across this vxlan tunnel in order to communicate with one another so the question is if i draw this out if this is a traditional environment where these two devices are maybe my distribution switch and i've got a layer two connection where do my svis live well my svs i'm gonna have an svi here and so maybe this is 10.1.1.250 and maybe i've got an svi here that's 10.1.1.251. and ideally i actually you know deploy a first operator dynasty protocol so we've got maybe.254 as the virtual ip address that's being shared and life is good in a traditional environment this way here's the problem in an sda world even though that i shouldn't say it i shouldn't i probably could have left the line there technically speaking we still have layer two communication right we've got layer two communication across the vxlan tunnels so i could still deploy first top redundancy protocols i could still deploy hsrp and i could run 254 and that's great except how does hsrp work again that means that all of the you know.254 is going to belong to one of these devices at a time let's say switch one is the active that means that these devices have to go out this way logically to get to their default gateway again not a problem from a traditional architecture from an sda perspective this is problematic because we know that there's actually a gap right here and so 10.1.2 10.1.1.2 has to go up here get encapsulated get sent across to switch one just to get to its default gateway does this work sure it works is it efficient of course not expand this out to a hundred different access layer switches for this particular vlan do we want all 100 switches to be basically tromboning traffic to one of our switches being the default gateway the answer should be no we do not want that here's what we do instead um well i wanted to keep some of that but i guess i won't that's fine here's what we do instead we're going to use this concept called anycast gateways what anycast gateways allows is let's say we've got that 2. or i'm sorry that 254 ip address as our default gateway i'm going to deploy this to every switch in my network i'm going to deploy 2.4 and svi here i'm going to play a 2. or dot svi on switch two and now really what i have is i have my clients here's my dot one here's my dot two dot two can go upstream to get to its default gateway that one can go upstream to get to its default gateway and life is really good now you say well wait a second jeff you just deployed the same ip address to every single switch in the environment so if we have 100 switches i just deployed 254 to all 100 switches so there's 99 duplicate ip addresses out there and nobody knows which one is the real one well that's actually not a problem because anycast the concept of anycast is a legitimate networking technique it simply says go find the nearest device that has that ip address and so yeah if i were off off network somewhere and i somehow pinged 254 or not somehow being but if i were to ping that 254 um i'm just going to land on whichever network device i get to first that has dot 254 on it and it will send my its ping response back so yeah i mean i'm not going to use 254 from a management perspective i'm not going to like try to log into a particular device using an ip address that is an anycast address but this works great for delivering the default gateway out to every single device i'm sorry every single fabric edge node so the local clients don't have to go anywhere to get to their default gateway because again remember we have stretched this subnet across these two different switches in our example here these two are still able to communicate with each other via layer 2 but from a layer but from you know getting off the network perspective all we need to do is an individual one each individual wanting to go up to its local default gateway this concept has been around for a long time i did a lot of data center designs and you know when you're doing data center designs i did an otv deployment once where effectively you have uh i had a nexus 7k on one side and nexus 7k on the other and we're running otv across it like this well we had a bunch of different devices here on i'm just calling it vlan 10 and we have a bunch of different devices here on vlan 10. well where do you want the default gateway to live not at either one of those locations you want the default gateway to live at both locations and so the exact same concept you had to do a little bit more manual configuration for this so you had to like basically block hsrp messages because really i had two 7ks on that side and two 7ks on this side so i still wanted to run hsrp between the hsrp between the 7ks on the right i still wanted to run hsrp between the nexus 7ks on the left but i wanted to block that hsrp communication from going out so that really i had i had an active on this side and i'd have an active on this side and that works fantastic so this anycast gateway concept has been around for a long time it's used extensively in cisco aci these days it's used extensively in software to find access so absolutely a great technology and i hope that makes sense again just ask questions if not so that holy cow i need a drink as always it seems like we cover about five hours worth of material in uh an hour but uh thanks for those who stuck with it if you need to watch this video again a couple of times or watch it slower i know i spoke fast quite a few times because uh just trying to get everything out there but um for those who again aren't used to this what's gonna happen i'll go ahead and close this out i'll leave the video up for about five to ten minutes somewhere in that range i'll stick around answer any questions if you've got anything please stick around ask if you're not watching this video live you can always leave comments i pay attention to those and try to respond if you have any questions there do not hesitate to to ask anything that comes up other than that next time we will be meeting uh two weeks from today so that should be the 16th of december and we're going to be wrapping up our conversation on software defined access so um just perfect timing end of year we're going to stop talking about sd access and switch gears and talk about something else moving forward i don't have that off the top of my head we'll talk about it next time but on the 16th we're going to wrap up by talking about different hardware platforms that cisco has and we've spoken generically about fabric edge nodes and and different things but you know at some point we do need actually most of us who are working for organizations you have to like go deploy hardware and so we'll take a look at what hardware platform cisco has that can map to all the different roles that we've talked about so it won't be a terribly intense conversation not nearly as intense as as we've had for a few weeks now but it will still be fun so be sure to come hang out until then everyone have a great rest of your day and we'll see you in two weeks [Music] bye [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] you

Channel: KishSquared

Views: 2,962

Rating: 5 out of 5

Keywords: ccnp, encor, cisco, sd-access, sda

Id: 0L7ipxZRcrg

Length: 75min 12sec (4512 seconds)

Published: Wed Dec 02 2020