Module 01 Part 2 What is Cisco ACI In Depth

so now we have to ask the question what is it are we solving what are we trying to solve well if you think about it and this kind of does take a little bit of a step back so you if you're new to networking maybe you'll have to go read some history books or talk to some older folks if you've been around for a while then you probably remember back to before we even had VLANs we still had hubs or bridge domains and we separated those through routers right we broke up broadcast or bridge domains through routers but then you know these new fancy cisco or actually crescendo switches that cisco acquired for the catalyst line of switching introduced I think was 98 this concept of VLANs now a VLAN or virtual LAN of course was a way to have multiple separations or multiple LAN multiple broadcast domains or bridge domains on a single physical switch and break up those broadcast domains we have to ask ourselves why did we need to break up the broadcast domains well because there was a lot of broadcast of course there was what kind of broadcast well the number one kind of culprit of broadcasts is ARP of course right address resolution protocol we have to resolve a MAC address for an IP address so that we know at a layer two Ethernet level where to forward traffic on the network on the switch domain which of course is done through MAC addresses so VLANs were used but they were kind of tightly coupled with subnets so could we have multiple subnets with one VLAN well you could but it typically was kind of shunned right so if you ever walked into a network and you saw 15 separate IP addresses so IP address and then IP address secondary IP address secondary secondary secondary secondary on a single SBI which I'll say a lot so switch virtual interface or the interface VLAN okay or even on a routed interface this was typically tion typically a bad idea why well because we were we had a lot of separate broadcast domains on one particular bridge domain or VLAN if it happened to be that and again this was because we had a lot of broadcasts we had art we also had unknown unicast flooding and there's some other things as well certainly but those are the two predominant ones so we'll talk about how ACI basically issues the need for those or obviates the need to have those art eliminates the need to have art or unknown unicast now of course there's times when we want to or have to turn it on and we'll certainly discuss all of those throughout the course in series of these modules as well however we do have the ability to turn it off and actually it's off by default for every Bridge domain and again we're gonna talk a lot about bridge domains we're not going to use the word VLAN a lot because in ACI we're not using VLANs we're using the X LAN now of course the LANs are still very important to us we still have to learn VLAN information through dot1q trunks there are South that southbound devices into our leaf switches but once and we'll demonstrate that on the white board a lot more but once we've learned that VLAN ID we strip it and we map it to a VX land and so we'll just simply refer to these as bridge domains so we'll talk a lot more about that but we've typically had getting back to the slide one subnet per VLAN was the general rule of thumb and we then placed constructs on top of that so our network policies for permit deny QoS mark or possibly redirect through policy based routing or logging with ACLs permit deny as well ACLs we base those on subnets which were based on VLANs our SLA SR QoS was based on VLANs and even l4 through seven services okay we base those on VLANs or we routed traffic or really kind of herded traffic our VLANs so Network constructs got overloaded with unintended or at least originally unattended functionality the other main issue is we have a huge language barrier so why does our data center exist now you may say why do I care about developers if you're a developer watching then obviously you know the answer to that but if you're a network guy you might say why or girl why do I care about developers well without them there's no need for a data center right applications are the reason that we have our data center so there's been a huge disparity between developer language and infrastructure teams so developers talk about things like application tiers provider consumer relationships and API call flow infrastructure teams say I don't know what you just said but I need to know how many VLANs you need how many subnets you need what protocols and ports you're gonna need to have allowed and if you need load balancing or do you need you know next-gen or you know firewalling or deep packet inspection or anything like that so we have to have someone to translate between these disparate languages so another issue and this is really a huge issue so we'll take a little bit of time to talk about this here's just a very simple three-tier application we've got our and when we say three-tier we've got our web server tier our application server tier so let's say this is an Apache web server a tomcat application server and a my sequel database very common stack for application development and of course we have our outside users data centers are they run a lot better without users but obviously limited need for them without the user so we need the users coming in from the outside to get in from the outside we want to obviously route that traffic in so they come in through a layer 3 firewall now we probably have multiple firewalls so they probably come in through a switch and we have a VLAN defined through that so we have our initial switch with a VLAN and our router config is only showing one switch and one router and we now have either three separate switches with VLANs or we could even use the same physical switch with separate VLANs but security policies typically dictate multiple switches and of course we're gonna have redundancy in switches so if we see three switches here in one router we haven't even got to the firewall yet really double that because we want redundancy so then comes in the firewall configuration next comes another switch with our next VLAN as well as our SSL offload and load balancers okay so here's our load balancer and my animation is slightly off so we're now extending from the VLAN from the switch down into the web tier and now we also have it possibly another firewall so that those web servers can then get down through the load balancers into the application tier where we have at least one more switch with a few VLANs or a few more switches possibly probably one switch and then either a firewall or maybe just regular you know no firewall but just a switch config with maybe an ACL before we get down to the database layer and again all of this is just with single devices we haven't even gone into the duplicate devices that we would have for redundancy now maybe they're VPC and we're using config sync just kidding don't use config sync uh-huh but you get my idea double all this work now think about this that's not only a lot of work to do but this is a we're doing these on most likely production switches that have shockingly other traffic on them so they either have to be done at a maintenance window we want to be safe or they have to be done in a way that isn't going to affect anything else so if we are if we have a human doing this raise of hands real quick who don't worry I can't see you this isn't a live class who has ever configured a distribution / aggregation switch and you've gone to run switch port mode I know these are all switch port mode access but let's say switch port mode trunk of course was already configured and switch port trunk allowed VLAN was there and you had a list of VLANs well now we need to add a new VLAN for this new application this is the reason why we have what in DevOps terms we would call a waterfall deployment meaning we save up all the changes that we have until a maintenance window and then we make it during a maintenance window so everything just waterfalls all at once all the changes get pushed immediately during a maintenance window and then we of course have regression testing to make sure that everything still works why do we do those maintenance windows well again show of hands who has ever gone to add a VLAN to a production aggregation or distribution switch and issued the command switch port allowed VLAN or switch port VLAN allowed I can never remember which comes first question mark right switch port VLAN allowed the number of the VLAN enter and you think I forgot to hit add it's too late it doesn't matter whether we were in a live environment or not doesn't matter if you can even well first of all you'd have to go back and remember what all VLANs were allowed because probably PCI or other compliance is going to require that you not allow all VLANs you can't just have switch port mode trunk also it could really impact the traffic flow so now you have to go back in your change history if you keep regular backups of your configuration files which hopefully you do and you have to remember what all VLANs were there that I need to add back this is a problem actually if you've ever done that and that was the show of hands right behind the behind the screen I can't see you if you were honest either you've never done it and you just started in networking or you've at least done it once I doubt there's many people out there that have never done that not even once in a production network which that can be a rge a resume generating event depending on how important the production traffic was or the production switch that you hit it might be a CLM a career limiting move because that word might get out to other people and other companies the idea is that humans make errors and waterfall deployments or everything all at once even during a change window is potentially catastrophic if you don't have proper regression testing and if you're doing it during a live production deployment even more so possibly catastrophic so this is some of the major problems so that's not even talking about the redundancy or what if we add a few more web servers well now we need to go back to the switches back to the load balancers and make some changes so let's talk now about what is an application as it pertains to the network well it's more than just a virtual machine or a bare metal server it's really a collection of all the applications endpoints + the layer 2 - layer 7 really layer L 4 through 7 network policies including L 2 and through 4 right we might have VLAN ACLs we might have layer 3 ACLs so the idea of what we want to get to is to build teamwork to create a logical abstracted stateless model that supports the application so we create our model we define the endpoint groups which of course are simply collections of endpoints and by the way we'll refer to these endpoint groups as EP G's so this is a term you'll hear quite a lot in all the future modules for ACI we define any layer 4 through layer 7 services like firewalls load balancers ids/ips network data broker or monitoring gigamon things like that we create this logical model that supports the application we create our contracts well we'll actually talk a lot more about that we haven't defined that yet our contracts are what allow ok in the same way that think of a contract if you go and get a job you interview maybe it's a higher level position that requires a contract maybe it's just a regular job you essentially have a contract whether it's legally binding or not that basically says you know you will provide work and your employer will consume the work right your employer on the other hand they will provide you with a paycheck and you will consume that paycheck you'll put it in the bank you'll be a consumer you'll use that money so you essentially have this contract between two different parties well think of our different endpoint groups as the parties the web server is let's say for instance the actually let's just say the outside EPG is the user or person going to work and the web server is the boss right the company so the web server provides a position and you consume that position right so they provide the paycheck you consume the paycheck and then the outside EPG it does the work okay and we'll talk about single contracts with bi-directional filters much later and we'll also talk about unidirectional contracts but multiple so another relationship where the outside EPG provides work and the web server or boss or company consumes the work okay so we'll talk about these provide consumer relationships for contracts and the contracts define what happens so who's the provider who's the consumer what are the ACL or stateless or stateful firewall rules that are being implemented in the ACI fabric so in the ACI leave switches or if the contract is told to use let's say an outside or external firewall load balancer SSL offload ids/ips things like that so these are our service policies we'll define all these logical constructs in the apec and then from there we will deploy these so these will be packaged up into an application Network profile which then get instantiated or pushed out to the fabric to the leaf switches and we can actually use these as models for let's say our development environment or development tenant we could export change anything we need essentially copy and push this over to a test or QA tenant and then we could add what we need and then we could essentially export change whatever we need and copy this over to our production tenant or production environment and all of these could be running side by side on the same leaf switches now let's say all of a sudden an application goes away and we don't need it anymore we could delete a single tenant with or even just a single application at work profile from the fabric and it's gonna go out and it's going to remove all constructs that we're using or any leaf switches resources that we're using the constructs from this either a full tenant or even a sub of the tenant which is a application network profile the profile of the application as it pertained to the network now this is one of the other large things that most people in environments don't do so for instance what's the largest ACL you've ever seen the largest I've ever seen is 40,000 I talked to someone the other day that actually had seen a 60,000 AC e or application control entry line ACL okay why do they grow that large because people are afraid to remove the cruft they're afraid to go out and remove any of the old configuration with good reason in the same way that if you forgot to add the add command to a switch port trunk allowed VLAN you very well if you remove some lines of an ACL without a lot of planning you could very well accidentally take down a lot of pretty in traffic and cost the company hundreds of thousands possibly very possibly millions of dollars depending on how long it was down so with a CI if we know that we're done with an application and we've spent our time planning that I can simply remove the a and P the application network profile and it will go destroy everything else associated with that without impacting any other traffic wildy provision my firewalls D provision my partitions in my load balancers or even entire load balancers it will take care of all of that so let's talk about the logical model overview we already began to talk about if you remember UCS and stateless computing taking the idea of our storage specifics the server specifics for BIOS and firmware and adapters and our network specifics and packaging that in a stateless abstracted construct or framework called a service profile well now we're doing stateless networking so we have these application network profiles with our endpoint groups and our contracts of defining what an end point group exposes to other application tiers as well as how now we have stateless filtering we actually also now have stateful filtering so let's define some terms we've really gone over these but we'll just have them here on a page for your reference so an endpoint group or EP Jia's will refer to it after this these are containers for objects or virtual machines hosts could be routers could be switches that'll require the same policy treatment a tenant this is a high-level logical separation for a customer or a business unit or a workgroup or whatever a tenant is something that we really don't have a equal to in traditional networking you might think of it loosely like a VDC in a nexus 7 k although a VDC is actually a separation of physical traffic as well an a tenant a CI to some degree that we'll unpack later has a separation of physical traffic but we have another way of doing that which is our layer 3 verse V ahrefs or context so a tenant does require a new vrf there's no way to have 2:10 and so actually that's not even true there really is we even could have two tenant share of ers so a tenant is mainly a logical separation of administrative functions and again this is only I've gone on a lot of worked with a lot of cloud public and private cloud deployments and designs and everyone wants to use separate tenants it's not always necessary it just depends on who or what is going to be accessing the ACI apec directly if you have multiple groups that are never gonna touch through the API programmatic interface or directly through the web GUI they're never gonna touch the actual apec controller then you don't need separate tenants okay but you do have that as an option for separating administrative control we then have our private network what ACI calls a private network now this is a layer 3 context or a ver a vrf we then have a bridge domain it is not a VLAN it's actually a VX LAN segment okay so this can be used to define a layer 2 boundary we also have subnets within our bridge domains and we can have multiple subnets within a single bridge domain for the reasons that I talked about earlier we used to be able to have multiple subnets for a VLAN on an SPI an IP address and then secondary secondary secondary we didn't but that was because of a lot of broadcast traffic we can eliminate that broadcast traffic by turning off and like I said on our bridge domains in ACI by default they are off or ARP flooding and unknown unicast flooding so as long as we leave them off we can very safely have multiple subnets we'll talk about any implications of those as we go on contracts they represent the policies between our endpoint groups they're provided by one EPG and consumed by another so the provider is the one that has the services you want to access so a web tier would provide port 80 and port 443 for instance and then the users the outside users would consume that now one of the things that we'll go over in a lot more detail much later especially as we begin talking about more details about all of these specific things in a CI but then also as we begin talking about the restful api is later is this concept of the management information model so everything in a CI is a managed object okay an mo or managed object and this management information model or management information tree basically goes as such we have our top layer which is our tenant technically we have the top layer which is the universe uni or root and then under that we have one or multiple tenants within a tenant that's where we create our application network profile and notice that one tenant can have many application network profiles so it's a 1 to n relationship or a one-to-many on the contrary an application network profile and a and P can only belong to one tenant it's an end to one one tenant can have multiple layer two or layer 3 outside networks it can have multiple bridge domains the bridge domain has to be a part of one vrf or private network or context they're called all three are the same thing ok so that's an end to one but one vrf could have one two n could have multiple different bridge domains a bridge domain can have many subnets but a subnet can only belong to one bridge domain our a NPS can contain many ep geez whoops but the EP G's can only be a part each individually of one ANP and of course the EP G's must actually belong or be mapped to a bridge domain but of course one bridge domain can have many EP G's and this is actually an end-to-end doesn't show the other end over here but the EP Gees are an end to n so there can any number of ep G's can have any number of contracts contracts and we'll talk a lot more about these in detail later contain one or more subjects and then subjects contain the filters and subjects two filters are also an end-to-end relationship okay so we can have one subject per contract actually sorry we can have multiple subjects per contract but a subject what I meant to say is can only belong to one contract but then the actual filters the ports the ACPs if you will inside of an ACL think of a contract like an ACL for stateful or stateless firewall there are a CES or filters and subjects can have multiple filters now of course the contracts are not only ACLs they can also redirect to layer four through seven services so here's a little bit more complete construct or framework of an A&P and will actually begin adding on to this as we go on so for instance we have our database EPG with multiple endpoints that's providing a my sequel SQL contract being consumed by the application EPG the a PPG has its endpoints and it's providing a Java contract for Tomcat being consumed by the web EPG which has its webserver endpoints and it's providing the web-based contract over to the public outside with multiple subnets all of these belong inside of a layer 3 vrf or context they could belong in multiple and then each of these EP G's is mapped to a single bridge domain they could share bridge domain so web and app could both be a part of the same bridge domain and we'll talk later about design aspects of when you might and when you won't use at least for now multiple EPG within a single bridge domain but in a simple model like this it would be perfectly fine if all three shared a same the same VX land bridge domain so this was the logical model in order for this to be pushed down or instantiated to the fabric we need to have an understanding of the concrete model so first of all how do we apply policy to endpoints well the endpoint attaches to the fabric the APEC detects the endpoint and learns its source EPG and we'll talk about how it learns that how we know what endpoint vm router switch bare-metal machine how it goes or gets classified into which EPG and that's designated as its source EPG and then the APEC pushes the required policy down to the leaf switch so does that source EPG have a particular bridge domain well it has two okay so what VX LAN VN I is going to be added as upper as a V Thep or which leaf switch I guess I should say is going to be a V tap and have pushed down for a particular VX LAN v ni virtual or VX LAN network identifier which verbs need to be instantiated okay which ACL policies so the a pic manages pushing of this policy to the leaf and enforcement and and the leaf becomes the enforcement point when the endpoints connect so we don't you don't have to know all of this right now but here is a kind of an overview of the APEC controller having a policy controller as a subset of it a logical model that we've defined and then the policy update being pushed down so this is actually to a the subset of the logical model and again you don't have to understand all this right now we'll go into a lot more detail later when we talk about the API and programming of ACI which will probably be one of the later last modules once we understand what's happening this renders implicitly a concrete model and basically how does that apply to ports line cards physical interfaces VLANs Irv's switch nodes this gets added to the nx-os process which is running on the leaf switch in the Linux distribution and deployed to the actual network year itself

Channel: LumosConsulting

Views: 10,537

Rating: 4.9130435 out of 5

Keywords: Lumos, LumosCloud, LumosConsulting, Cisco, ACI, SDN, Networking

Id: QgbR_myeqGo

Length: 29min 11sec (1751 seconds)

Published: Wed Jan 11 2017