Understanding the Cisco ACI Policy Model

all right so my name is Karli sotin I'm a technical marketing engineer with the NCMA business unit which handles the 9k AC I and our nexus 3,000 product line I've got about 200 slides for you today just kidding this is all I'm going to show you and we're going to go to the whiteboard I tell people when they ask what I do for a living I draw pictures so let's enough with the market tech chure we're going to get technical I know that's what you guys are here for so let's go ahead and get started with that so I would like to first talk about understanding the policy model so what makes ACI special one of the things that differentiates us is that policy model starting to think about networks in a different way than we have in the past right so let's take a look we're going to start over here so with the policy model what we want to start thinking about is really the needs of the application alright who's on the network what do they need to talk about and who can talk to who instead of thinking about configuring 20 routers 50 switches firewalls load balancers right all these different devices individually that may have different operating systems and may have different teams that we're configuring we want to make it simple all right who's out there who can talk to who and what are they allowed to talk about so we're going to start by kind of looking and breaking down holistically what an application looks like what the pieces of an application are some of the terminology that we use in a CI so you guys can start to get an understanding of how it actually works and then we'll look at how those pieces connect and tie into our spine leaf architecture with the Nexus 9000 so when we think of an application we typically start thinking about front-end web tier alright maybe this is my SharePoint application and this is my front-end web interface all right and then I have my users we'll say this is my user Billy Bob here and yes I like to draw but no you're not going to get anything more than a stick figure I cannot draw more than that for you but we'll have our users Billy Bob here it's going to be talking to our front-end web tier but we've got a little more going on so we think of that first when we start to breakdown holistically what an application looks like but we've got a little more going on so I've probably also got some application servers that are presenting up to my web tier what am I missing database database yeah I probably have a database also on the backend that's serving up information for the other tiers of application so those are the main pieces when we try to look holistically of what an actual application again something like SharePoint or a typical three-tier application this is this is typically what we think about I may also have some things like shared services right things like Active Directory DHCP DNS so we'll go ahead and add those in as well so now we have kind of a picture of what an application looks like basic three-tier app this is not what every application looks like Shore but this is a simple model that we can look at and yes we don't always know what our applications look like even if we're an application person but this is a basic layout of the different tiers that we have different pieces of an application the who of what's in the data center that's the first part that we're figuring out and what we call each of these clouds that I've drawn up here in the ACI policy model as EP GS and point groups okay first acronym we'll have a few I'll make sure I call those out but that's a what we call end point groups collection of endpoints that are going to need similar treatment on the network so then that's the who but with a CI we're again thinking about networking in a different way and a CI is actually a whitelist model so by default in a CI on an a CI fabric none of these guys can talk to each other until we explicitly allow them to a very different from our traditional Ethernet networks kind of plug it in spray-and-pray broadcast sprint spanning tree same thing we've been doing for 30 years so different with a CI right now if I had just defined these endpoint groups nobody's going to be talking on the network how do you define the endpoint groups are these VLANs are these MAC addresses is this five topples is it all of the above so there are multiple ways to do that today and there are more coming the ways that we support today is to sort things into these buckets that we call endpoint groups we can do this based on VLAN which is a very easy way to do it that's the way we've seen a lot of our initial customers do it now web anything in web is in VLAN 10 anything in app is VLAN 20 database is VLAN 30 right that's maps into VMware port groups and we are done right we will so I will have another session that will discuss the VMware integration but that is another option we can also look at things like tags other tags besides 802 dot1q tags we can look at VX LAN tags we can identify traffic based on NV GRE tags we can do physical port and say maybe anything that comes in on this port I want to be part of my web endpoint group and then I can also do virtual port so leading into your question about integration with VMware and port groups we can also sort things into these buckets using virtual ports with that require ABS on vSphere host or not does not require ABS that's an option but we could use a standard we can actually push in a vmware distributed switch and that'll cover in another session yes so those are some ways that we can sort things into these end point group buckets we can also do things like static endpoints based on say a MAC address we're also going to be doing cool things down the road one of the ones I'm really excited about is virtual machine attributes so maybe I could say any VM that starts talking to my fabric here that's called production - wild card put that into a certain endpoint group that's just one of the ones that's coming so these are the ones that are supportive today and we're going to have others down the road just a question on that VX land there sir does that mean if the hypervisor is you is using VX land and cap like using ZC NS for example you would be able to look into that and then do filters between endpoint groups based on the payload of the VX Lam packet so the intention more with VX lan is let's say this is a VMware server here and I'm actually doing VX LAN inside of the hypervisor and I'm applying a VX landtag to the packet it's looking for that specific bit not specific beam in on the leaf or NV GRE tag if we're in a Microsoft environment so yeah VLAN that's certainly a common one that's one we've seen a lot of customers start start out with because sure we don't always know what an application looks like but as if we're networking folks we probably know which VLANs sort into which groups it's closer to the current connectivity model right right and that's normally how we think about that we are changing how we're thinking about networking you know what's actually happening on the fabric here is different than we do in the traditional ethernet world but frankly it's time for a change all right who likes spanning tree oh we got one because if you understand you can be like the genius guru guy but nobody does it currently be still do that ever sucks less easy isn't it your loop take one out yeah that's it it's great one that lets go unplug the cable you're good to go right so there is there is a lot more that is that we're doing on the fabric itself here no things like taking off the tags putting on our own tags running an overlay technology using standards based protocols on this actual fabric eliminating the need to do things like flooding across here like we have to do in normal Ethernet network that's one of the innovations that we have in the Nexus 9000 that's actually happening on this fabric here other questions so far okay so let's talk a little more about this policy model so we talked about endpoint groups those are the ways that we support today that you can sort things into these endpoint groups via and vgr evx LAN physical port virtual port all right so I have my endpoint groups but again whitelist model nothing can talk until I put policy in place and the way that we implement policy and ACI is in the form of what we call contracts so I need to put contracts that's the who can talk to who and what can they talk about we've got the who now we're going to put in in what we call contracts which can be unidirectional or bi-directional so for example I want my users to be able to talk to my web tier want those endpoint groups to talk but I don't need the users to go talk to the databases all right I don't need to add that piece in this contracts can be packet filters or traffic redirection right yes so in the contracts there's multiple actions that you can take you can do things like permit deny redirect log copy those are the different actions that we can put inside of a contract and it's easiest when we get started with a build with a CI when we go and roll this out with customers as we'll start by permitting all traffic between two end point groups and then we can narrow it down from there as I probably only want maybe billy-bob here maybe I only want him to be able to come in on ports 80 and 443 so I can start to get pretty granular with what I'm permitting and I can have multiple subjects that are allowed in this contract so that I can limit what they're allowed to talk about and because you're doing this in Hardware on the switch yes you're effectively limited but why by what teakamp can do which is up to layer four right right so essentially with a CI since we do a whitelist model it essentially gives us a stateless firewall now if you want to do stateful inspection yes we still need a separate firewall but by having this whitelist model it really gives us a stateless firewall at the box but we will be able to integrate and we do support integration with some layer four through seven services today those Citrix f5 a SaaS AV right more of that coming but but yes if we want to do stateful inspection we're still going to need something like a firewall now as I look at this people some people might become Rule happy so they will just build loads and loads of rules in the contracts between the individual tears eventually we might run out of the hardware resources on the switch so what happens then so the nice thing about this policy being implemented is it's also dependent on where the devices are we're only going to program these rules into the t cam on the switches where these devices these end points actually live so if I don't have any web servers connected to this leaf those rules aren't going to be programmed ended you can you know if the web server virtual machine moves over there then the controller has to push down the new yes then it will push the role and it's not that's not I thought about that we said earlier that the controller didn't have to push out there that was my next question so yeah that was about saying that the control is pushing out like a new policy or ever as such but if it's workload migration then that should be dealt with within fabric without requiring the controller so correct the souther controller which is a cluster of three that's simply a policy repository that's where we configure these policies and where they get pushed out there are two different ways that you can have policy pushed out you can either do immediate or on-demand and if we do immediate it's going to go into T cam if we do on-demand it's going to go into one of the hard drives that are sitting on these apex which are essentially UCS e-series servers so if you're light on resources you can go for immediate and then it gets deployed everywhere and as you start running out of that then you go for on-demand which requires controller in the real time but allows you to survive in cases where you're sort of close to the T cam limits ah let's see let me think on that one for a moment so you're saying if we had say a complete controller failure and we had a VM move would that Zoe be present I believe that it would be pushed already to the hard drive that's present on the leaves that's something I would want to check though and get back to you so you have hard drives on the leaves sorry not our tour drives on the leaves the the memory on the leaves yeah the memory mm-hmm yeah so be I guess each leaf knows about the policy it's just whether it's installed that and TK mana so it's like you push the config to the switch but the config is not used until you actually have some need for it in which case it gets into T camp right or guys do this on the existing switches come on that one I can't help me there yes if immediate though it would go to T Kim whether or not we needed it yeah so I've heard that as sort of conversational learning to use a former term right yes yeah the way that we're actually learning the end points in the way that we can I will make sure that we're not flooding here so the spines know where everybody lives the leaves know who's connected to them and who they've talked to across the fabric which is similar to conversational Mac learning like we've heard about technologies like fabric path yeah but it's topology driven not traffic driven right so it could be both it depends what kind of integration you're doing but the moment I have say let's say this is a bare metal server the moment I have a packet come in here the leaf is going to say okay who are you are you web or you app or you database and we're actually going to tag in our headers across the fabric the source EPG because we have to enforce this policy that we have here yep yeah so the leaves are really the ones that are doing the policy enforcement and we go one level deeper yes if I have a conference between a web and app EBG and then I have all sorts of other contracts I might get into this state explosion where I have this enormous number of rules because of all these different contracts are you somehow optimizing that so that half of the processing is done on ingress and then half of the processing is done on Ingram or on egress or do you do everything on the ingress as the packet gets in so ideally we do policy enforcement on ingress because why pass a packet across the fabric that we're just going to have to drop when it gets to the other side granted sometimes I know the source EPG but this leaf may not have spoken to the destination EPG in that case we have to send it across fabric so that we can do the enforcement when it gets to the destination leaf but we want to do what we call opportunity opportunistic policy enforcement so I want to drop the packet as soon as possible if it's not allowed so you only send it out if you don't know who the other guy is right but either way it's three hops that's the beauty of this finally topology is that whether or not I know the destination leaf or not I have to hit a spine anyway so it's a three hop predictable latency predictable bandwidth that's why we have this architecture so the other leave its ingress there right which piece so if you're going to talk to the other leaf we don't know the destination it's sent across and then it's enforced on the other leaf right in gross so packet comes in and I don't know the destination end point group that would have to go across the fabric which will be equal cost multi path across the fabric spine does know where everyone is so then the spine is going to go ahead and send that to the destination leaf leaf is going to learn is it the source EPG is tagged and this guy knows all of his guys so he's going to look at the destination and say yay or nay Oh a tricky one sorry but go there are enter so for it I love it well let's say you're sending the packet to the right spine if doesn't know where to go so it sends packets back it to one of the spies let's say it chooses the right and the link between the right spine and the right leaf is down okay this link yeah okay what what what candace find you now it cannot reach that leaf and it's stuck there with the packet looking at the packet what we do so if we so just that link is down we still have another path yeah but the left leaf didn't know that but the spine knows that okay so how does it get the packets to the other side so the spine can send it back over here okay and over to the leaf it'd be a B there would only be a short term micro loop type situation wouldn't it because presumably if you lost that link it would pretty quickly the network would reconverge around that but yeah you'd be like it'd be a micro loop situation I guess and the link failure detection is actually 125 microseconds yes I'm sorry it really only happened like you started serializing a single packet yeah I mean you'd only get if you had serialized a single packet it's already going across that wire sterilize and you lose that Lincoln that while it's you know serializing going across it would be like a packet or two right exactly yeah so we're not doing protocol based we're not waiting on timers and protocol protocol based convergence that's one of the innovations that we built in to the Cisco Asics that we have on the Nexus 9 case that's why we have this hardware solution as well yep all right let's make sure we finish covering the policy model here great questions though on the fabric architecture and we have a lot more information on that that's available so contracts nothing too talked till we have these contracts I can permit all I can reuse contracts I can again I can do actions like permit deny log redirect copy or all actions that are supported within these contracts a level of statefulness like when you're doing port level filtering like that with level of statefulness is ur so we can do ports protocols you can also do as down to tcp tcp state so like get a flags and stuff like that you know established or whatever there's a base layer for but it's all stateless at that stateless yeah we're not we're not totally replacing firewalls here yeah if we want to do deep packet inspection we want to do stateful filtering then we need a firewall but we can integrate firewalls and have those program from the apec yes so I can say just Billy Bob here is only allowed to talk to the web servers on ports 80 and 443 but I'm probably going to want to do a little more than that and maybe I don't totally trust Billy Bob here maybe I'm going to want to have a firewall maybe I'm going to want to have a load balancer so again getting back into that layer four through seven service insertion I can actually add within this contract what's called a service graph which is essentially a service chain and I can say first you're going to go through a firewall and you're going to go through a load balancer then you're allowed to talk to the web tier I could either do that by redirection or if I can if I have integrated a device like the a sa then I could have that ordered right here in the service graph so all that can be contained in a contract that's reusable between tiers between tenants between different applications uh if you send a packet through a layer 2 firewall then obviously the MAC address doesn't change so you know is the same packet but if you send the package balancer it appears as a totally different packet on a different VLAN with a different set of source and destination IP addresses when it comes out how do you know that it's still that same packet that is bound by that same contract let's see so if we had redirected to we'll say this is a load balancer if we'd redirected and we changed so defining an EPG doesn't have to be just one of these things so maybe you would include both of those VLANs in that e PG definition so you would include the VLAN coming out of the load balancer into that same definition yeah yeah because you can an EPG I can have you know because I for example and I'll we'll have a session on looking at different ways to set up these but my databases some of these might be VM some of these might be bare metal server some of them might be hyper-v the key is it doesn't matter so in a single EPG I could have devices that are running on different ah different platforms the contract a pool on the loop that's like four in half contract yes exactly blegh yes the EPG so I would put both of those VLANs that the inbound and ingress and egress in EPG definitely I'll probably have to split this into two domains because if you put the output of the load balancer in the same EPG as the users what prevents that packet to go through the load balancer again because of the contract well once it's already passed through the load balancer it's going to be aware traffic came from the load balancer and we're going to be able to go ahead and forward it on to the fabric so all this definition this could be say this is my production SharePoint application all of this these EP G's are endpoint groups the contracts the definitions of what we have in here all that is what we call an application profile so ideally I would have an application profile for each application I had out there on my network and these are very repeatable objects it each of these can be exported as a JSON or XML file everything is essentially a hierarchical object through our restful api so i could export this application profile make a couple changes push it back in i don't have to be a developer to do this there's a tool there's actually a plugin called a postman and google chrome that allows you to push and post back into through our controller into a api it's very reputable programmable but this is essentially what we get with the policy bottle is let's think about who's out there who needs to talk to who and what are they allowed to talk about that's what we get with the policy model you have something like read-only mode or you could figure out what is actually going on and tracking the sessions and then you go like wow i hope i'm hundred percent done now let's push this yes you could do something like span between EP g's the beauty of this is we and will see in some of the other sessions that provide demos but we'll see that everything has a health score that we can monitor and we can actually see that at an application level so instead of just looking at a switch or a port or a link when someone picks up the phone and says i can't access my email i can go look at my exchange profile look at the health score and start drilling down and seeing what the problem is troubleshooting a lot easier because we're thinking about it at the application basis it's definitely a shift in how we think about traditional networking but this is going to make it a lot easier to roll out new applications make changes Oh kind of decouple all of these networking concepts that we've mushed together over the years in the OSI model another thing just crossed my mind sorry about the question no no that's what I'm here for you said that one of the actions you have between the EP G's in the contract is copy is that how granular is that can I say well I permit packets to port 80 but I permit and copy package to the DNS port so that one's still being worked on we'll see more on that coming okay I was hoping for a fabric wide span the old span we can do yeah yeah span you can generate GDP gee yeah so it's yeah it definitely makes it easier to troubleshoot because I can look it between these two applications and it's an on an end to end basis how is that application performing on the network oh you can do span today yes regular port the port span yes but you can't yet do the contrary based copy action in a contract is coming but span is there today yes so that's really the policy model and again all of this you would configure in the APEC which is our controller cluster of three devices open API northbound and southbound GUI is one way that you can interact with it or we could use Python all right it says open API so buoys have a minimum of three epic ices in production we do have lab bundles that you can get that have one a thick though what's the reason for that the reason is for redundancy and actually all three APICS are active and all of the data is actually sharded across all three a picks which I hate that I have to say that word a bunch all of the data is charted across all of the apex right now three will be able to scale out to more apex in the future if we have a larger environment has a lot of policy don't have anything do is like split brain or making so the reason it's three is so that we have quorum I we only had two we wouldn't have that ability right only have two reloading big brain yeah which part of brain you killed yeah yeah so three gives us quorum again all active I could go to any one of the three a picks and configure from there the data is charted across all three affix oh you can work with a peek through the UI or through the API yeah there any chance that I could get something out of a pic in a text file oh that I could use that for version control or do you think or something like that yes absolutely so and we encourage backups but there is yes that's part of the GUI you can set up automated backups of either partial configuration entire configuration of the whole a pic I could take that I can push it into a different fabric somewhere else or I can export individual objects and if I just want to take this EPG and replicate it somewhere else I can right click save as and it'll give me an XML or JSON formatted version of that object yeah so essentially the a pic is really it's the API that we're going through so the GUI is really talking to the API home-brewed it is cisco GUI but it you could write your own right since we have that api is open both northbound and southbound you could have your own device or interface that you write that's programming the APEC and the APEC is also capable of programming other devices like the ones I mentioned that are supportive today so you could write your own tool if you wanted to what is the GUI is it the GUI we will show in a separate session but we'll get a little peek at the GUI yes all right so that is the policy model that is an application profile that is what we're starting to think about now in terms of networking is we want to bring the language of the application to the network

Channel: Tech Field Day

Views: 61,352

Rating: 4.8614321 out of 5

Keywords: Tech Field Day, Networking Field Day, Networking Field Day 9, NFD9, Cisco, ACI, Policy, SDN, Software Defined Networking

Id: d6ErTjKSpA8

Length: 35min 43sec (2143 seconds)

Published: Sun Feb 15 2015