ENCOR - SD-Access Principles

happy wednesday everybody we are back after taking last session off just to kind of take a little break and get ready to dive into the world of software defined access and that's exactly we're going to be doing today as well as the next several sessions possibly looking at maybe four or even five sessions just on software to find access because as you can imagine there's a lot to cover as far as sd access is concerned so as far as today is concerned we're going to be first of all looking at what the big deal is about these software-defined networks and in order to do that we need to start with the problems of what our traditional networks give us and so we're going to take a look at what you know what we do from a traditional networking perspective and then why sdn how does sdn just software define networking in general let alone cisco's sda platform but just how does sdn solve problems i mean if we can't solve any problems with sdn then why are we deploying sdn all over the place uh after that we're gonna be talking about you know now now we're gonna be drilling into sda itself and all the specifics around you know what makes a campus fabric versus a software defined access fabric and then diving into the specifics of the different uh the archive i guess first of all the architecture of sda and then also the different layers and the different components of an sda solution so for those who are new to this experience i suppose welcome to the encore study group what we're doing is we're just walking through each and every week looking at different blueprint items from the encore uh i guess the list of topics from cisco so if you're studying for a ccnp route switch or i guess they call enterprise networking now but if you're studying for that ccnp then the encore exam enterprise networking core is what that stands for the encore exam is going to be a required part of your journey and so this session has been pre-recorded you are welcome to chime into the chat and ask questions i am here right now live answering questions available in case you have anything so if it involves software-defined access then of course ask those questions as you have them if you're studying a different topic in encore then be sure to chime into the chat and ask those questions as well because we're all here to help and so if it's not me maybe somebody else can chime in and help but either way we're going to try to do our best to support each other as we're going after the ccnp certification all right so without further ado let's go ahead and dive in i think we are going to go here i'm excited i've got a new camera and the camera's not going to turn off every 30 minutes so that's very exciting those who have seen some of my previous videos the camera just decides to shut off after 30 minutes it's a wonderful thing so first of all we need to again explore the the pain point you know i was a called a pre-sales engineer for a long time with a cisco partner and one thing that we had to learn and i had to learn early on in my career is if you can't solve someone's problems they're not going to be interested in the solutions that you have right and we've all heard that phrase a solution looking for a problem somebody trying to convince you that you need something and if in your heart you don't feel like they're going to do anything to make your life better more enjoyable or fix a problem then none of us are going to be interested in that we've all endured sales pitches whether for a career or just wandering down a shopping district or something like that or maybe a mall you know someone's trying to sell you something it's like i'm just not interested i don't believe in my heart that i need that so if we're going to believe in our hearts that we need software-defined networking and we need software-defined access then we need to start with what are these problems that we're going to solve so let's talk about traditional networking so in the world of again traditional networking sounds really weird to say you know the way i used to network is now traditional but yeah it is what it is you know i'm getting old enough now where a lot of the things that i used to do growing up is considered retro by the kids these days so i guess that's representative of the age right but when it comes to traditional networking think about the way we build a campus network okay then think about if you've taken any cisco courses or you have you know studied for any cisco exams they're probably going to walk you through this concept of a campus architecture and the way that campus architecture is arranged is we typically have some kind of core network core we're going to attach those two switches together for example and then we're going to have a distribution layer and that distribution layer here right over here core layer then we have a distribution layer and we're going to interconnect all this is all going to be layer three we're gonna connect these together at layer three in some way and then we are going to extend this down to the access layer now the access layer is a bit unique up until now we've had only two switches in each um call it a a module you know we talk about the modular network architecture right so um but but really at this point we're talking about them as if they're layers so we have the core layer the distribution layer and so when we look at that distribution layer we're extending down to access closets we could have dozens of these access closets and each access closet could have multiple access switches within those closets and so when we look at our actual real life scenarios a lot of us have probably worked on networks maybe you're managing a network today that has this type of architecture built out and so i know when i worked for a medical clinic for example we had oh i'm trying to remember i think it was in the like the 16 closet range in one of our buildings so every single one of these closets had a pair at least of 4 500 cisco switches access layer switches and so we have as many of these access closets as needed in order to extend ethernet out to everybody and so things may you know things have changed over the years as we've adopted wireless we need less wired connections but ultimately in the vast majority of cases we still have access layer closets that are out there and so one of the questions that we have to ask ourselves when we are building an architecture like this is well how is this going to operate from a subnetting perspective how are we going to deploy our clients out there one of the traditional networking concepts is that if i create a subnet that subnet is going to belong to a broadcast domain and we know that broadcasting is bad in networking because ethernet is kind of a terrible protocol but it's what we built the entire foundation of our society on this point as integral as internet is to everything we do ethernet can't handle broadcasting very well and so when it'd be one thing to say well okay let's just not broadcast except all of our clients are constantly broadcasting for a lot of different services not the least of which is dhcp among other things and so given how much broadcast traffic is being created by our end devices we need to contain these broadcast domains because if we get up to you know we can maybe handle 256 or maybe even 512 devices on a single broadcast domain but when we get beyond that it really starts to impact us because our pcs are all handling thousands of broadcast messages per second and they just can't handle that on some level and so we want to reduce the broadcast domains and that's great except we also need to have some of our clients within the same broadcast domain because we leverage services that are built on relying and receiving broadcasting dhcp we know that we can use helper addresses and we don't rely on a pc being in the same subnet as a dhcp server like maybe 30 years ago it did but we do have other services that are going to want to reach out and find each other over broadcast you know some windows services and printing services and such and so we do like to keep our clients on the same subnet but we want to shrink these subnets down and so we we find ourselves in this design conundrum of how big are we going to make these broadcast domains now one thing that further exacerbates this problem is the idea of wireless because now we have to worry about connecting from one wireless access point and i'm roaming i'm walking down the hall and then all of a sudden i connect to a different wireless access point well if this wireless access point and this wireless access point are on two different subnets then that can create a problem and because now i have to do a layer three row my ip address has to change or we have to get into some sophisticated fancy ton you know anchor tunneling mechanisms and at this point even this concept of wireless roaming is a little bit archaic because with the advent of wireless lan controllers and again these these anchor tenants and things like that we just we've got these ways of dealing with this scenario but it still was a problem that we had to overcome and so really what this boils down to is we need to decide let me change colors here we have to decide at this point right here these connections between distribution and access layer are those going to be layer 2 or are they going to be layer 3 if they are layer 2 then we can have total control over this scenario we can decide how large to make each broadcast domain we can decide how small to make each broadcast domain we can make sure that everybody is able to communicate with each other across broad you know within the same broadcast domain if possible in other words if a pc is attached to this switch here on the closet here on the left and it needs to talk to a pc over here on the right via broadcast messages well we can make that happen we can place them both into for example vlan 100 on all sides and because these are layer 2 connections going up to the distribution layer you know vlan 100 can essentially be extended as one large broadcast domain i suppose at least physically it's spread out across multiple access layer closets that's the good news of layer two the bad news of layer two is a three letter word that we we all like to hate on and for good reason is spanning tree protocol spanning tree is a very difficult protocol to contain at scale it's one thing if we just have a few switches and a few closets and such etc but when we've got a large enterprise campus spanning tree can become a big deal and so even when running rapid spinning tree a multi-instance spanning tree it just it becomes problematic you know some cisco switches some people aren't even aware of this you might have a cisco switch that can support 4096 vlans that's all the vlans by the way but if you look at the data sheet it can only support somewhere in the vicinity of i don't know 128 or maybe 256 spanning tree instances and we know that with cisco spanning tree per vlan spanning tree we need an instance per vlan and so as soon as we think that we've got support for all 4096 vlans but as soon as we make that 129th vlan on the switch or 257th depending on the switch model as soon as i make that what plus 1 vlan it can't put a spanning tree instance to that vlan which means we're not running spanning tree on that vlan which basically means the network's gonna go down right because we love to loop our networks for redundancy and it just doesn't work if we're going to not run spanning tree on a vlan so we become very limited by this at scale um we we can just have problems you know uh conspiratory compatibility problems i know that i've told the story possibly even in this um in the study group i can't remember for sure i've told the story so many times but the the very short version of the story is i want to plug in an access layer switch very innocuous operation just plugging a switch into the distribution layer switch during working hours and because the distribution layer switch was running non-rapid spanning tree and the switch that i was plugging in was running rapid it didn't it failed to negotiate and because it failed to negotiate it formed a loop and it took down the entire organization at least that that branch that i was at and uh yeah that wasn't a fun conversation to have with anybody and i as a network engineer i can all day say look the technology should have worked and literally to fix it all i did was go back and do the exact same thing and that time it worked so it's sort of justified that what i did was not the wrong thing to do but it also just sort of created yet another part of a culture that said well everything we if we're going to touch anything on the network it has to be done after hours well okay yes we as network engineers we're all expect not only expected to but we're willing to put in time after hours we understand that there are sensitive um or keeping the network online should at least be a priority and that we want to be sensitive to that need but if you create a culture of everything has to be done after hours then well now now you've got network engineers who are putting in way more time a week than what is healthy and so spanning tree is just one of the contributing causes to that because not just my example but just in general spanning tree causes a lot of issues when spanning tree hiccups people lose network connection and people do not like to lose network connection in this day and age um on top of all this by the way oh wait wait we weren't done with the conversation all right so what if we went with a layer three solution say okay well jeff let's just get rid of spanning tree all together which is true we can i like to use dots to represent layer 3 connections so i'm just going to throw some dots on here and say look what if we just converted all of these connections over to layer 3. does that solve our problem well it certainly solves a spanning tree problem we no longer need spanning tree at all in this environment because we don't have broadcast domains but keep this part in mind over here if we do layer three to the edge it does force us to have small broadcast domains and so that actually is a good thing at least it helps us contain them but we are no longer in control of that because for example this scenario here where i need a client on vlan 100 here and a client of elon 100 over here that's a scenario that cannot happen when we have layer 3 to the edge now in a lot of situations in the modern network we have less and less need for this on a campus infrastructure in a data center layer 2 is everything like we have to control layer 2 inside a data center but out on the edge i mean how often are pcs really talking to each other on broadcast how often are we really relying on broadcasts for printers and scanners and such uh fax machines anybody so there are there are always things that will be out there but it is a scary proposition as a network architect to design a solution that you know cannot support something in the future even if today you ran all of you did your due diligence you ran all the tests you proved we're not using any broadcast services so we flip the switch over to layer three and we're running layer three life is good other than now a new application gets installed and now we need those layer two connections it's like we just went through all this work we just went through all this effort to convert our network over to layer three and now we have to convert it all back and i've been part of those migrations by the way there was one specifically i remember where i had to tell again i was a consultant so we're working with another company and had to tell them like look it was the right decision to put layer three in this network and this is specifically between two locations at the time and like we didn't have the need at the time but now now you have the need for layer two and so we're gonna have to extend this convert this link to layer two and extend broadcast traffic across it and so we had to go through a conversion process in order to essentially undo that which we had done intelligently right like we're trying to fix problems here and so we deployed layer three and but now we have to go back to layer two so neither of these choices are great uh layer two is certainly the safest from uh just making sure everything works all the time perspective or i shouldn't say like that layer 2 is the safest from the perspective of making sure that all of our services that we need are able to be provided right regardless of what application we deploy we can definitely support it on layer two layer three is safer from once it's up and running it's going to be robust because we are running ospf or we are running eigrp and ospf and eigrp are both worlds better than spanning tree protocol and so the fact that we can get rid of spanning tree is huge but now we're running the risk of just having to convert back as soon as one application gets installed that requires it so that is our conundrum in the traditional networking space now beyond that we also have to worry about this nasty concept of configuration management so i am again a traditional networking engineer i've been around for a while at this point and so i'm very comfortable at the cli and imagine a lot of you who are watching this a lot of you are very comfortable with cli commands and logging into a switch and making sure you can you know config t and do everything you need to configure a switch or a router to sing and dance for you but we have to zoom out and look at it from a call it an i.t director level uh per view because yes as technicians as the people who are on the front lines configuring these switches yes i love the ability to log into each individual switch and configure it and make it do all the whiz-bang feature features and give me everything that i need at my fingertips whatever i wanted to do it will do but here's here's here's the problem it's really easy for me to go to a whiteboard and define a policy what do i mean by policy i mean like a security policy or qos policy something that's just like this is how we are going to do this from now on and you know i t director level type of conversation maybe talking with network architects and saying okay we need these two subnets never be able to talk to each other right it's really easy to say that on a whiteboard vlan 100 should never be able to talk to vlan 101 okay how easy is it for us to take that policy and convert it into configuration i i would put it at a moderate to hard level of difficulty i mean for those of us who have had experience with configuring access control lists and for creating a lot of the qos settings that are completely different on every single cisco platform they've ever made whether it's uh you know back in the days of multi-layer qos or um of course we've got um boy mqc right module qos cli and so we've got all kinds of different ways of configuring qos and so if we just want to say hey voice and video traffic take priority on our network it's really easy to say that on a whiteboard it's really easy to decide those kinds of i want to say easy i don't want to minimalize that it actually can be very complex to create proper policies but at the same time that decision making process is usually not what is preventing us from deploying more strict security and qos policies in the network what's preventing us from doing that is this part right here and again i'm not going to say that it's impossible to go out and deploy a policy but what really can be the nail on the coffin for deploying a policy that should be you know that should be deployed can be the maintenance of that over time because how many of us can say with absolute certainty that our access lists every access list that's on the network is 100 clean right like no extra statements access control entries are all good um it's blocking everything that it should uh they're of course not right like we we all as network engineers understand that no once you put an access control entry into an access control list you never touch that you know i mean it might be referencing a server that was decommissioned 20 years ago but like just in case i mean it's not doing any harm right it's just i'm not gonna i'm not gonna remove an access control entry because that might just break everything and i'm not gonna be the one responsible for breaking anything i mean i've been there it's hard it's really hard to go back and clean up configurations whether it's a control list or something else because you know hey well maybe i want to know that that configuration was in there at one time or maybe maybe if i do remove that like what if i'm wrong what if that configuration is needed and and so the reward of cleaning things up seems small compared to the risk of cleaning up something that should not have been cleaned up and so maintaining this policy over time i mean i'll liken it to a beautifully cabled network closet i mean we've probably all seen this you deploy a brand new network closet the the cabling is beautiful immaculate it's tied cable ties cable trays everything is this is so great it looks amazing and then what happens within a year you go into that network closet and somebody just strung a cable from two you know from a network or switch port to a network jack it's like and we all just want to completely flip out but that's the reality i mean it's it's all it's science right it's entropy this concept that everything works towards chaos we have to put effort into maintaining order and so there's no difference between a network closet cabling and policy from that perspective so we can have we can put all the time in the world into this policy and then we can spend a bunch of time configuring it and we have to spend a bunch of time maintaining it and then guess what happens also we get something some kind of new application or something that is going to affect our policy so now this application or whatever this new need is shows up in our policy and says uh or i'm sorry shows up in our network and we look at our policy and say oh the policy needs to change so we push that policy down to the implementation team and of course we're the ones on the implementation team oftentimes and so we get that we're like oh my goodness you know i've gotta i've gotta go out and spend i don't know 20 40 100 hours whatever it's going to be pushing this policy out to the rest of my network okay now i know a lot of network engineers you're from all walks of life and all different types of organizations if you have a small network none of this is going to be particularly alarming and you're going to look at you you're probably your core or maybe even have a collapsed core so you're really looking at collapse corn distribution switch you've got two or three access lists on there not a big deal right i mean policy changes you're you're going to roll with those and you're going to get them up and running but as you scale this out and you think about a campus environment like like a cisco for example or like a remote user type of scenario i mean we live in a remote world right now where everybody's vpninting in and you say pushing policy out to all these remote places vpn policies i mean it it gets out of hand very very quickly and so that's the takeaway here that i want to really make um the last thing too in all of this is what are we binding our security and our policy our security in qos 2. um i mentioned access control list where do we apply access control lists layer 3 interfaces which layer 3 interfaces usually switch virtual interfaces or vlan interfaces okay so if if i have a policy that says vln100 can't talk to vlan 101 i mean that's the most granular i can get for them generally speaking in other words i can't say hey jeff's pc even though he's part of vlan 100 he he he works in it he really needs access to those resources in vln 101 so jeff's pc should have access to those resources and so what do we do well usually what happens is we put our i.t staff into a separate vlan that has special permissions but if you know i don't know bob from accounting comes in and plugs his computer into my network jack and gets a vlan 110 ip address well now bob from accounting has access to all the resources that i had access to because the policies are not applied to this guy or even my machine they're bound to an ip address range and that's true for qos as well in a lot of cases we're just going to mark our traffic based on the subnet that it's coming from and so it's just an archaic way of doing things you know we have the tools in place to say when jeff kish logs in to the network we're going to treat him in such in such a way and maybe jeff is the exception and everybody else on the subnet gets access to those resources but we know jeff's a troublemaker so we're not going to let jeff have access to those resources whatever our policy is it should be on a per really a per user basis as opposed to a per you know even even the machine argument you could say well you know if somebody gets access to jeff's machine and logs into it well now he's on jeff's machine and and they can still have access to all of jeff's stuff um well then that's a security breach in and of itself so you know take that for what it's worth but um you think about people logging into servers and this and that so there's a lot of different situations where you could tie it to a user but at least to a machine and not to an ip address because it shouldn't matter whether i as as me if i'm logging into vln-100 or login to vlan 110 either way i should have the exact same policy enforcement about whether i can access resources in vlan 101 so hopefully that makes sense there as well okay so it has only been almost half of our time and we've covered the first component of this so we'll see how far we get today we'll see how far we get and if we have to split this up into two sessions then we can certainly do that but if you again i'll call this back out if you have any questions or thoughts about any of this uh any like hey jeff why is that such a big deal or etc just you know free for to chime into the chat i imagine in a lot of these cases i'm preaching to the choir a lot of us have the experience enough to know that this is problematic and boy you know i wish we had a solution for this all right so let's talk about a solution for this what are we going to do what is well i was gonna say what is cisco to do but really what's the whole industry going to do okay well what the industry is going to do is they're going to create a solution called software defined networking sdn um i often joke that if you know if to you sdn stands for still don't know because you still don't know what sdn stands for or not stands for but what it is then you're not alone and i wish i could take credit for that joke i don't remember who i heard it from the first time but sdn is hard to explain it's hard to define i mean even preparing for this i was like well how am i going to define sdn because in a lot of ways sdn the definition can depend on the context like what are we trying to accomplish with sdn and i think that really is what drives the point home is sdn yes we understand it stands for software defined networking but this software defined sd part it's software defined it means that i can basically accomplish with it whatever i want because it's software hardware is rigid it can only do what it was created to do um i i can't i can't make a um i don't know i can't i can't make a i don't know what the analogy is gonna use on that one it doesn't really matter um but if i can take two different computers i can program them to do different things in other words apply software to them then i can actually change the underlying function of what that system is trying to accomplish whereas two hardware pieces that were built for different things are probably never going to be able to be changed all right what am i trying to say really all right here's what i'm trying to say what we're going to do is we're going to build a software layer to our networking we're going to abstract this concept of abstraction can can sometimes cause confusion as well so don't stick with me if it is but we're going to abstract our network topology away from our physical underlying topology what do i mean by this here's what i mean we're going to take this concept of our physical network let's say i have five routers and the five routers are physically connected like this okay and let's say that i said you know what this isn't what i want what i really want is a network topology that looks like this i want all five of these routers to be in a star topology well that seems all right i guess i guess that's cool but that is not at all what we have um we don't have anything like that from a physical perspective so to be clear this is the physical what we call in software-defined networking we call this the underlay so we have a physical network and then we have a i mean honestly it's usually just called the overlay i'll call it a i'll call it a virtual network but like don't get locked into that term really this is the overlay and overlay network okay uh really what i should call it and i'm going to call it is the logical network the physical network in a logical network and so we do have a tool to use in the networking world that helps us to accomplish this and it's the swiss army knife of networking tools we've talked about this before in the study group and it is the tunnel because i can connect these two routers directly to each other logically i can via a tunnel so if i build a tunnel that yes the traffic is going to travel up and then down in order to form that tunnel but ultimately what i'm doing is i'm creating a tunnel between those two routers and then i create a tunnel between these two routers and i create a tunnel between these two routers and i create a tunnel between these two routers there i have created the overlay i have created the logical topology that i want out of a physical topology that was nowhere near what i wanted just with tunnels okay well that's kind of cool um the other thing in all of this that we need help with is is all the policy stuff that we talked about and so what we need is a controller something that is going to leverage intelligence uh sophistication uh what's the word i'm looking for but it's going to leverage automation ultimately is what we're going to do to automatically configure this for us we don't want to have to well we could have done software-defined networking in 2005 just by manually configuring all the tunnels um if i had come to you in 2005 and told you hey this is how you should design your network and you slap me in the face it would have been a well deserved slap because who wants to manage all these tunnels i mean in this scenario it's four tunnels it's not that big of a deal but in a larger network it could be hundreds of tunnels and tunnels are at least traditionally they're bad news because i can't get visibility into the tunnels and if the tunnels were to go down i could cause recursive recursive loops and with my running protocols over them if the tunnel starts flapping and all these kinds of situations that where tunnels were just not a good idea for a long time at least not as a major foundational component of my network architecture and so what we really want in this day and age is something to automatically take care of the um the busy work i don't want my network text to go out and configure and maintain hundreds of tunnels over time i want the controller to do that component and i want that controller by the way to remember this concept of defining policy well rather than pushing that policy to my implementation team and having them configure and maintain that policy over time i want to push that policy into the controller and have the controller deploy that out to the network so we're really combining a bunch of different topics here a bunch of different concepts in software-defined networking but the idea is to do a few things with software to find networking again coming back to that trying to create a definition for it really it's creating a an abstracted logical topology that is managed and maintained by a controller rather than by human beings okay that's as close to a definition of software to find networking that i can really give you i mean you can go out and google it and you'll find all kinds of different uh descriptions of it um you know there are a lot of references you'll find a lot of references to when it first started and this concept of open flow and um the a lot of people were really hoping that because this was now going to be my logical network that this physical network could just be a bunch of cheap dumb switches and these could be maybe even white box switches or heaven forbid dell switches and dell routers but maybe i shouldn't poke fun at a specific vendor but in my experience those are about the bottom of the barrel as far as quality is concerned and so when you are looking at at least in the campus space they make good data center switches all right sorry my ragging on dell is done either way um when we when we looked at software defined networking over the years the goals have changed originally this was a big part of what they they being those who were really investing heavily into software-defined infrastructures this is what they really wanted they wanted to be able to deploy just cheap as cheap as possible switches out there that are managed by a controller and all of the intelligence is in the controller and then that way hey it's a commoditized market i can go out i could buy a cisco switch or a dell switch or an hp switch or whatever piece of hardware i want it doesn't matter if this one's cisco and this one is dell and this one is hp i mean if i did that today that's going to cause all kinds of problems because you know cisco chronic yeah grp and hp can't and dell's got some of their own protocols and cisco runs per vlans really cisco's the offender right i mean like hp and dell they run all the same stuff they're using a lot of the same underlying asic architecture but cisco of course is very different and so this is why again i don't know depending on how long ago you've really been tuning in to this concept of sdn um i remember i mean i was reading articles in 2011 time frame probably sdn is going to be the death of cisco and this was why because one of the goals of sdn was to make it so that everything we did was by a controller such that it does not matter what we deploy as our physical network is our physical network again it's just an underlay it's all it is it's all it is okay um so that was one of the early goals um certainly another goal of this is this concept of um i'll write this out because this is worth it control and data plane separation so what does that mean well what this means is when we have a network today we're running a cisco network we have two routers communicating with one another what does this look like well usually we have a control plane functionality in other words those two routers are running eigrp or ospf with one another and directly sharing routes and directly sharing lsas or whatever it is we're doing based on the writing protocol of choice and then we also have a data plane concept and so that would simply be um uh the control plane is running and running edger here on ospf and populating a routing table well now that i have a populated routing table out of my control plane as i get packets in i check the routing table the rounding table tells me what to do with it and i send it off okay that's the idea of having a data plane is the data plane just relies on the information that has been uh provided by the control plane and i run my own control plane operations this is the world we are all accustomed to so when we say we're separating the controlling the data plan from one another i don't know about you but i started to get panic attacks and i'm like well wait a second that's like i don't know like separating two things that i don't get how do you do that that's like taking a peanut butter and jelly sandwich and saying okay well what we're gonna do is we're gonna take the peanut butter part away and the jelly part away like you're going to have a sticky mess if you do that right well not really because what we're talking about is now having devices that are only data plane capable to say okay well they're only data plane capable that means that they have to have a populated routing table where are they getting that routing table information well where they're getting it from is the controller the controller is going to push the control plane information down to these devices so in a lot of cases i still have to share routes potentially i mean depends on how much automation is happening here i mean in a truly software defined world we don't care what subnets are where because all of our policy is based on like we said earlier about users and things like that we've got a long way to go before we kind of address how exactly all that happens but the idea is simply that i'm receiving information again think about from a data plane perspective do i care as a data plane if my routing table was populated by a local ospf process or a local eigrp process or if somebody else gave me routes all right so what's interesting about this concept is it's still if you look out there if you if you truly take some time to google software to find networking you're going to see that as part of a lot of definitions you're going to see that as a lot of like this is what sdn is and this is one thing that cisco cisco kind of turned this on its head a little bit from the perspective of cisco values hardware and cisco values intelligence on the local machines this is something that's i would say probably the biggest influence that cisco had in the way sdn turned out as of 2020 because again in 2011 2012 time frame sdn was going a completely different direction than where we ended up um cisco said hey our switches and our routers absolutely everything we talked about so far controller yes automation yes overlay and underlay here yes all of this makes sense and there's a ton of value to it but to put all of the control plane intelligence into a software controller puts way too much emphasis on that controller it can cause problems the controller goes down and frankly these devices all have to have some level of intelligence anyways let why wouldn't we use the intelligence that are on that's on there so in a weird way we don't separate the control and data plane and cisco technologies but at the same time we we do because we are going to still run for example lisp as a separate control plane protocol even though the same devices that are running lisp are potentially running eigrp or isis with the underlay devices um so that's important but um what we're going you know in aci for example cisco's application-centric infrastructure um the they they're all of the devices are still running both both layers on some level and so it's just sort of an interesting conversation the idea of controlling data plane separation was truly that you'd have a controller that pushed all control plane information down with cisco there is still some amount of separation but we do have to pay attention to the fact that um that hasn't been offloaded to the controller it might be offloaded to a different network device for example a lisp you know control plane node essentially is what we call those in the software to find wan space we have those vsmarts out there the vmanage as the controller is is not pushing this control plane information down it's it's you know running as a vsmart controller it's pushing the control plane information down so that's where we still see the separation but then we look at the devices themselves and they're still running some amount of control plane information as well so yes we do still have separation no it's not quite what the original sdn framework or the founders of sdn had in mind when they when they went through this exercise okay uh let's see here overlay underlay controller control plane data plane are separated all right so moving on to what exactly um cisco sda is and sort of where it came from has anyone heard of um well i'm going to hang on to this for a minute but i'm curious though go and chime in the chat has anybody heard of apic em is that name ring a bell application policy infrastructure controller dash enterprise module this is a mouthful um so we'll we'll come back to that i'm just kind of curious i want to see where people are as far as chiming into the chat on that so before we talk about sda we need to talk about a concept called campus fabric the reality is that we're not going to see a ton of campus fabric out in the real world but you might see a little bit of it it's essentially software defined access without the automation components okay we're going to start to see this as a almost a math equation start to develop here okay campus fabric says this we are going to use lisp as our control plane mechanism and if you're intimidated by lisp by the way um as i can promise you that i was when people started first start talking about it like whoa whoa what is the service provider protocol that's invading my campus network uh lisp is a very cool protocol um we've got if you're a cbt nugget subscriber absolutely take the time to go out and watch our videos on lisp i've got a i actually taught a couple of them i might be the only ones on the site at this point but either way it's it's very simple it's a very simple concept and we just once you understand it it really helps cement sda well fundamentally so all that to say don't be intimidated by lisp it's actually pretty pretty boiled down for us in the campus space all right so we're using lisp with the control plane we are using vxlan at the data plane okay so for those who aren't intimidated by lisp but maybe some of you are intimidated by vxlan all right lisp this is pretty cool how this all comes together lisp is a service provider technology vxlan is a data center technology now i'm a data center guy so i'm like all right yeah i understand vxlan i'm good with vxlan but lisp like freaked me out um if you're neither a service provider nor a data center engineer then you're probably freaking out by these the very mention of these of these concepts vxlan essentially boils down to a layer two tunnel okay just just leave it at that a layer two tunnel between layer three capable devices so hey guess what i can extend a layer two subnet between layer three devices with vxlan hmm i wonder why i'd wanna use that maybe going back to our earlier conversation right so listen to the control plane vxlan is the data plane and then we have this concept of cisco trustsec and cisco trustsec exists at something cisco invented they call it the policy plane not gonna lie i don't think that's an official thing outside of the cisco space but essentially what cisco trussec is doing for us is it's managing a security policy tied to identity and it basically turns the network into a firewall they call this network as enforcer at least they used to i don't know what the modern vernacular is cisco trustsec is a way of tagging traffic and and that tag is what determines policy so remember we said that policy gets enforced unlike the switch virtual interfaces so like when a switch receives it off of vln 100 i treat all vlan 100 traffic the same i have forced policy against the fact that you're on vlan 100. well i'm going to do the exact same thing with cisco trussec except when me and and my friend both log into vlan 100 ice which can look at our identity is going to say oh jeff we're going to give you a tag of 20. oh jeff's friend we're going to give you a tag of 25 and it's going to enforce security policy based on the tag itself so it's no longer looking at my vlan id it's looking at who i am first of all giving me a tag cisco trustsec is going to use this concept of a scalable group tag sgt and the scalable group tag on my packet is going to tell the switches how to enforce it okay so again it turns the entire network into an enforcement zone rather than simply the the edge you know the whole lichen likening it to like a uh an hard outer shell like an m m or something like that where you've got a hard outer shell and all you have to do is crack the shell and then you've got all this gooey chocolate on on the inside where our networks are the gooey chocolate and the edge is is like the firewall zone and the sbi so when it when traffic hits that if it doesn't get dropped at that point it breaks in then it's just got full access to the entire network uh we don't want that we want it to be a jawbreaker right where it's just completely solid inside and this would be well first of all it'd be a jawbreaker instead of an m m but second of all this would be a cisco trisec enforced network where at every single hop the switch is capable of dropping traffic based on security group tags or scalable group tags they used to be security group tags and they change it to scalable group tags because of sda and so sgt is is still sgt but it stands for something different yeah that's always fun okay so what is campus fabric well campus fabric is any time you build a network architecture on these founding principles so if i build a network manually and truly you can do this if i take a remember our drawing earlier so i've got a couple of distribution switches okay and then i've got my access switches access switch access switch access switch and so if i wanted to say you know what i'm going to build a layer 3 network in here layer 3 fabric and i'm going to build vxlan tunnels vx well i should do it like down up i should do it down here vxl so like i build the excellent tunnels between axis layer switches and then i use lisp to lisp there we go and i use lisp to uh to as the control plane separation so i'm pushing the policies down or the control plane information down and i'm using cisco trustsec to to enforce policy everywhere if i do this this is a campus fabric i have built a campus fabric but i can tell you a lot of people aren't too interested in doing this outside of lab environments because well what did i just say most of us network engineers are going to freak out about either lisp or vxlan or cisco trustsec or hey potentially all three of those and so we don't see a ton of cisco fabric or cisco campus fabrics out there but still cisco has validated designs for this you can go out you can you can build this again especially in a lab environment you want to get your hands on some manual lisp configuration or manual vxlan configuration thing then go for it um just keeping in mind that cisco trustsec does require the identity services engine or ice so you're going to have to have some ice licensing in order to play with this but that's great other than what if what if what if i could deploy all of this using the helpful assistance of a controller and what if that controller is called dna center dna center as my controller can deploy this fabric can deploy a campus fabric if i'm using dna center and i deploy or use it to deploy and maintain a campus fabric that is what we call software defined access so some of you were bizarrely excited about the fact that i promised math equations here they are okay here's the math equations campus fabric is equal to lisp plus vxlan plus cisco trustsec meanwhile software-defined access is equal to campus fabric campus fabric plus dna center or you can abbreviate it as dnac okay there's our math equations um and if you're going to go take the encore you're going to take a well actually there is no sda exam yet is there uh at least the time of this recording so if you're going to take the encore especially you need to know those you need to know those math equations because um well first of all you might get asked about it but second of all if you're going to talk to a cisco rep about potentially deploying this or monitoring managing it then you're going to need to know your terminology and you know what you're talking about ultimately software-defined access is automating the deployment of what would be a fairly complex environment okay oh so um let me see here i'm gonna make a judgment call we're gonna go into the architecture of software to find access but there's absolutely no way in the world that can possibly cover that in nine ten minutes um here's what i'll do all right i'll give you a quick overview of what we're going to cover and then we're essentially going to pivot and push a little bit back to next week and so we'll cover this in more detail as part of next week okay so here's here's what we need to know about the sda architecture i got so carried away talking about all the ways that our current or traditional networking is terrible like i got a bone to pick or something i guess i don't know um sd access architecture okay so the architecture we talked a little bit about it um well actually yeah i'm going to leave that one so all right so we talked about the control plane the data plane and the policy plane okay those are all good so we have um three different planes of operation again this is good for that terminology thing we just kind of gotta get used to way cisco laid this out three planes of operation control plane data plane policy plane then we have four layers of operation and no these aren't like the osi layers even though the first layer is physical and the second layer is network so i don't know it kind of is but it's also not um let's walk through these first of all we have the physical layer okay um the physical layer is is going to well for first of all we want to like break it down to like what we are actually supporting and what we're not so in the physical layer what you're looking at are the components so the components that we support in an sda fabric are going to be switches routers access points and wireless lan controllers and that's it okay we're not we're not supporting anything else we're not supporting uh data center stuff we're not supporting like ucs and and hyperflex we're not supporting firewalls for that matter we're only supporting switches routers access points and wireless lan control remember first and foremost this is a campus architecture solution this is not a solution that extends to the data center that's for aci this is not a solution i'll say it like this this is not a solution that extends into the wide area network because we have cisco sd-wan for that that said cisco is starting to integrate these solutions i think eventually you're going to find that cisco's brought sd-wan under the sd access umbrella i think eventually we're going to see aci also brought into that umbrella but it's going to take a lot longer to integrate that solution than it will to integrate sd-wan which we're already starting to see um the uh oh i yeah okay never mind i was gonna go somewhere somewhere a little bit different but um we've got several different roles then that these devices can play and so our different roles are going to be a fabric edge node i don't know if i can yeah i'll i'll abbreviate these so a fabric edge node is one option we have a fabric border node we have a fabric control plane node and we have a fabric wireless line controller okay so clearly wireless lan controllers are are going to always be a wireless lan controller and technically that would include the access points as well as part of that so wireless line controllers that's access points however the switches and the routers are going to be either one of these three it's either going to be an edge node a border node or a control plane node again we're going to go into more detail on what this all means and how how this all operates but a fabric edge node would be think of it like your axis layer switch okay so in a traditional network again think about your network today if you have an access layer switch in access layer closet that would be a fabric edge node in an sda infrastructure a fabric border node would be a device that connects to a non-software defined access infrastructure so for example if we were connecting to my data center well that data center again is not going to be running software to find access and therefore i'm going to need a border node to sit in front of the data center control plane node that's going to come back to lisp we need a device that sits out of band to give us all the lisp information okay so so that's where that that's the device that's going to be running the lisp mapping server is the word map resolver map server so that would be a control plane node in an sd access environment all right so we need to map essentially the the components to the roles and then also by the way we need to pay a little bit attention to the platforms in other words a cisco 9k catalyst 9k we know that cisco loves those 9ks and they're basically built for sd access but what can a 9200 be can a 9200 be a fabric edge node or a border node or is it only an edge node and the answer to the question by the way is it's only an edge node but a 9 300 9 400 9 500 they could be any of those and 9 600 can only be a border or control plane node and so we have to be careful when we're architecting our solution to put platforms in place in where they can serve the role that we want them to serve all right so that was probably too long of an overview of the physical layer and then we have the network layer so the network layer is primarily going to be consisting of these three planes so we can import this down here we already talked about them um and and also so i'll talk about the planes or i'll say that it consists of the planes it also consists of that concept of overlay and underlay so we have a lot to cover as far as that is concerned as well all right next we have the controller layer the controller layer basically tells us that we have controllers there's not a lot to this layer it's really just understanding that we have first of all dna center dna i can spell dna dna center that can be a standalone server it can be clustered into a group of three but at the time of my recording this it's physical only now if you do some google searching you can find people who have virtualized dna center it's out there you can um you know people like to talk about it but as far as like officially from cisco like supported by cisco and supported by tech the only option is a physical dna center controller at this point so that it's going to change at some point i i can tell you that they're already making headway or talking about different options for having a virtualized dna center controller but that's that's where we stand i know they're also talking about a hosted dna center controller so like you'd subscribe to a service in cisco's cloud and have that be your dna center option but that's where we are there this is where that apic-em question was going to come in uh dna center actually consists of two subsystems the network control platform which is apic-em it's just been rebranded um apic-em was really cisco's initial foray into software-defined networking they wanted apic-em to be able to be an open-flow controller but also a specialized cisco uh controller and then they also have the network data platform this is basically a big data engine that runs inside of dna center and it's a value that cisco's pushing for a ton of different applications so they want they want us to be able to run network assurance that's what this really leads to network assurance is looking at all aspects of our network and compiling again big data just taking data from everything and so when we need it we're like hey why was this person unable to connect to the wireless yesterday afternoon at 307 pm we can click a few buttons and get a lot of answers for what was happening there and so that's this idea of network assurance now obviously that would be a reactive reason to use assurance why did that person why was that person unable to connect there's a lot of proactive benefits as well like hey we're going to have problems down the line if we don't do something about this now okay and the last the last layer is the management layer the management layer primarily the emphasis of this is to understand well here i'll write it out like this that we're going to use a gui to do all the configuration so again i hear you i'm i'm a cli guy i love the cli but we've got to get away from this idea that cli is superior the reason cli has always been superior to graphical user interfaces in the past is because in the past the graphical user interface essentially performed cli commands underneath the hood and so i'd go into a graphical user interface and i'd click a button and click submit or save or whatever and it would push those cli commands and sometimes it would work and and if somebody made cli commands before i click that button then maybe the gui is going to freak out because it's really just an http interface and has no idea what's going on on this device it's just going to take the clicks that i do and execute a cli command on the back end that the days of that are over instead what the gui is doing is it's running rest apis which essentially are a very robust way of doing what i just described over http as well and so it's going to run those rest apis against dna center which is down here i suppose all right now on top of that i can skip the gui all together and issue the you know take advantage of the rest apis myself so what does that mean well grab an application like postman or run some python scripting uh go to cisco devnet zone and just you know online developer.cisco.com and make sure that you're very comfortable with this concept of rest apis um if you've yet to go out to developer.cisco.com and and log into that and start to explore some of the intro there's a great intro tutorial i guess for like a better word i mean it's basically a little training course if you haven't done that yet and you don't consider yourself well versed on rest apis and such highly recommended i'm highly recommending that you go out and do that in the next two weeks all right so that brings us to the end of our time again my hope was to be able to essentially spend probably five to ten minutes on each one of these layers and so we're going to have to push that back into in the next time but i just want to thank everybody for hanging out this was a lot of information and i can tell you this is very foundational at this point we barely even drew any network diagrams on here and so um this is going to come together a lot better once we once we're drawing networks and such in fact the next time we meet it's going to technically be on fabric operation we're going to cover what i didn't cover in this session as part of that but the fabric operation is what is where it's going to come together because you're going to see the packet flow and you're going to see okay well how does this differ from when packets are received by an access layer switch in a traditional network versus how packets are received in an sda fabric and i i just it's a beautiful thing a software defined access is a beautiful thing it's very exciting it's well worth diving into and a lot of the reason for that is it's just going to be how we do networking moving forward slowly but steadily as sd access and generally speaking software-defined networks are going to take over uh all networks on some level and so we as network engineers we need to be ready for that and we need to be making sure that we're protecting our business and making sure that our organization is having the best network that we can possibly deploy but also protecting ourselves and our career because i mean it's so easy to look in hindsight and say oh man you know back in the day the the analog voice engineers who who refused to learn ip telephony right like that was such an awful thing that they didn't you know they refused to update their skill set well this is the same thing that's happening right in front of our eyes and so you don't want to be the engineer that in 30 years 20 years they're looking back and saying oh yeah those guys who who never actually learned how rest apis work like oh my goodness like how could they have been so blind i can promise you that that's going to happen to a significant number of people and one of the things i care a lot about is making sure that at least those who i can reach are not going to be one of those so anyways with that i'm going to hang out in the chat for about five or 10 minutes after this so feel free to stick around ask any questions and um otherwise we'll see you next week when we're i'm sorry in two weeks no next session but in two weeks we'll talk about software software defined access fabric operation until then take care [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] this [Music] [Music] [Music] [Music] [Music] [Music] you

Channel: KishSquared

Views: 4,744

Rating: 4.973856 out of 5

Keywords: ccnp, encor, cisco, sda, sdn

Id: JrdPNq2-ycM

Length: 71min 14sec (4274 seconds)

Published: Wed Oct 21 2020