Cisco ACI Overview with Soni Jiandani and Joe Onisick

and yes my name is sonia guillén Donnie I'm the senior vice president of marketing for insieme business unit obviously that is not true sony will be here in a moment and I'll just get it started while we're waiting on her to show up she's just a minute late if you don't know who Sony is the reason I wanted to bring her in is I know you come to Cisco a lot for these events and most of the time we bring in a product manager or a technical marketing engineer an idiot like me that type of thing we wanted to bring in somebody who has a lot of history in the networking industry everyone here I'm assuming has worked with the catalyst product line so Niemann team brought the catalyst product line to market at Cisco's for switching product Sounion team then spun out a company called on the ammos systems and Andiamo systems built the Cisco MDS product line and that Cisco storage and networking product that's about 50 percent market share today in storage networking after that they spun out a company called nuova systems and nuova systems built Nexus 5000 Nexus 2000 and the Cisco UCS platform UCS today Cisco's first server number one blade server in North America number two worldwide this is the same the same team Sony being the marketing lead for that Mario Prem Luka and Sony are the full executive team that have done this affectionately known as MPLS which is perfect in this industry right so we're gonna talk again a little bit about ACI and I know we've done that in the past of it I'm just gonna go through this is your little market extra pitch I am NOT going to be presenting all day today or presenting again today I know you are tired of hearing me talk so I brought in Carly Stoughton who is one of our top tMI's on the team and she's gonna spend all day on the whiteboards and skip the slides for you because I'm sure you'll see plenty more slides the rest of the day kicking into just a little bit of what a CI does and where we're at the market extra stuff if you look at where the industry is going and what we're doing we've got several shifts that have happened we went through this idea of unified fabric with land and sand we took fibre channel and we started to put it over Ethernet we started to unify how we deliver storage and it was a very successful technology especially at the access layer if you're using UCS most likely using fiber Channel over Ethernet and you most likely don't know it's there then we started to move into taking compute and taking storage and networking and blending those pieces together these are the Cisco transitions that we've been trying to take our customers through now we're moving into the application centric infrastructure and ACI this is the next evolution of where we're going what we want to do is look at the network as a delivery system for applications and services because that's what it's there to do as networking professionals were there to support the apps and services that our customers or our business is run fair enough so we're trying to tie what the application is what the business policy for that application is into the network and do that in an automated fashion how many of you have been involved with bringing a new application online on the infrastructure one that was maybe developed or just architected in a prebuilt pre-canned application even most everybody would you say the big I would say would you agree the biggest challenge when you start to do that is the human interaction between the people that understand application architecture and what we have to do is support it on infrastructure turning tiers of applications security compliance governance and risk into VLANs ports protocols and firewall rules is that one of the more difficult parts of what we do and we typically do this in a throw it over the fence fashion right they develop develop develop develop now it's ready here go make it work when they developed it they probably didn't develop it with firewalls and load balancers in place is that's not how we develop code then they throw it over you and you've got to insert these layer 4 through 7 devices and now you end up finding things that are broken that have nothing to do with the code they have to do with the way the code is being implemented on a different set of infrastructure does this make sense so we're trying to tie that policy down and we're trying to do it in an automated fashion we're not trying to do something that eliminates a network engineer we're not trying to do something that eliminates a developer we don't think that network engineers have to go learn how to build software but it would be good to have some development skills but most of us already have some scripting knowledge and things like that so when we look at ACI the thing that we're really trying to do is an automatic translation of what the app requires down into how the infrastructure provisions it and then visibility that's rel and back up to whoever is getting that visibility if I'm an application owner looking at a CI and I go into the ACI GUI or the ACI interface CLI whatever it is I see my application tears I see that this is my exchange server it's attached to this other group of servers I see what my application looks like from an architecture perspective I know how they connect and it makes it's the same way I would whiteboard it if I was the app architect if I'm the network engineer and now I have to troubleshoot exchange I don't now have to go to a spreadsheet to go and translate what VLAN or subnet is this sitting in to go down and figure out where I need to start looking for connectivity problems so in I get information that shows me this is the application I'm actually troubleshooting this is where the problem is and then I can drill down into latency packet loss drop throughput all the things that we have to deal with the troubleshoot and mitigate and get things back up does that make sense the other piece that we focus on quite a bit with application centric infrastructure is not just getting apps to pull more quickly because agility is one of the things that everyone is talking about in the industry right now from an infrastructure perspective any conversation you have somebody's going to talk about apogee of all blah blah getting an application online fast is great but once an applications online now you have users and now you have SLA s and I have expectations we have to be able to keep these applications online so one of the things we focus on quite a bit is that ability to troubleshoot down into where the application is having a problem one of the things I think we do best with a CI over a lot of the solutions out there and this is my personal opinion as a guy who's paid to sell a CI so take it with a grain of salt is troubleshooting an app if a user can't send an email they don't call and say a servers down they call and say emails broken and when that troubleshooting team whatever they maybe gets that call who's the first team they call it's the networks fault it's the networks fault right it's always the networks fault and then the network team usually says it's a security teams fault firewall but networks job and most of our jobs when we're working on a network on a day to day basis is mean time to innocence how long does it take me to prove to you that I'm not the problem does that make sense so one of the things ACI really focuses on is that ability to show hey the network is up and healthy now the application itself from the virtual to physical components that drive the packets is healthy and then when it's not healthy to drill down and show you where it's broken it's this tear of the app not talking to this tear the app but the packets are being lost or the throughputs bad or whatever it may be now when you look at a network today you're all very smart networking engineers it's why you're here if if I said it's very easy to tell that an ftp server is dropping packets on a network would you agree with that statement I have an FTP server to find out that that particular FTP server I know which one I'm looking at that it's dropping packets is that pretty easy it's easy but it's tedious yeah easy but ease just for a single server just to know that it's dropping packets it's tedious you can you can look at the port and see that you've got you know Sarah it's like just a single port right now if you want to if you have a real data center network multiple switches access switches but however three-tier design two-tier design doesn't matter to find out where those packets are dropping how easy is that today running down the path multiple switches multiple command lines finding it all with a CI we look at the network as a system for the delivery of applications and services so when packets are dropping when you're having lost when something like that is going on we don't tell you you have packet loss and latency occurring we tell you which link it's happening on what the latency of that path is in real time and where the packets are dropping it's part of the telemetry and troubleshooting pieces that we built into the system so yes sir you had me earlier with services you didn't quite say it but one of the problems I'm seeing a lot is services applications are undocumented so it takes a while to find out what are the IP addresses of the servers delivering that application and a CI implicitly is it does that for you so absolutely you know in a lot of places how many of us work with our networks based on spreadsheets that are showing me what I've subnet at what VLANs here what's there when you have to go troubleshooting an application you're going back to these spreadsheets and sometimes we move those spreadsheets up in a software they do it a little more intelligently so on and so forth but it's still a difficult thing to go and take that application and figure out what the infrastructure looks that it has to transition so a CI is tying that Network application and policy down into the network and looking at it as a system for delivering applications to help run the businesses and it's a step in getting up to enabling the cloud it's a step to getting our customers to be able to live our IT as a service or whatever other buzzword you want to use it's a step in being able to build private clouds and more importantly hybrid clouds which is where the majority of the market is moving today now with that being said I'm gonna turn this over to a much better speaker with a much better title my boss's boss Sony G and Donnie senior vice president about NCMA business unit and I think you're in really good hands thank you very much we do need a mic huh yes okay no problem I will use the mic I guess it's for the folks that are remote okay all right so as we were just walking you through this none of these innovations are in point in time one builds on the other so if you take a look at the unified fabric it was about IO consolidation LAN and San convergence the whole evolution of allowing or enabling applications to run across a unified fabric that built on the fact that you see has used the unified fabric as a core element of it but we did much more than that the unified fabric was one element of innovation the other elements of innovation were bringing together compute networking and storage access into a converged platform which really became the basis of what we call converged infrastructure with Vblock and flexpod at that time we were trying to solve the converged infrastructure side of the marketplace as you see the same elements that we brought together on the UCS platform including the constructs for policy-driven service profile we are taking those exact same pieces of innovation and now bringing it closer to the network which is policy driven and that has embedded capabilities through that policy driven model to accommodate applications that can now get the types of services out of the network and the infrastructure in a far more agile manner and a far more programmatic manner and in a far more secure manner at scale so that is basically the crux of a CI and that becomes the foundation for Cisco to deliver on cloud whether it is the ability for our customers to bill on-premise private clouds that are secured with embedded security whether it is they have the ability to use that same policy driven model as they burst to the hybrid cloud and even go beyond it to the public cloud so that as we integrate through Azure pack into Microsoft Azure you could foresee using a common portal with that same policy driven model to define the workloads and applications that you want to have corresponding to your on-premise secure private cloud infrastructure and go back to that same portal and use the exact same policy model to define the applications and their policies that you want to burst to your your cloud so this becomes a foundational building block for Cisco to enable the cloud models going forward for the duration of the policy that you have defined the policy and the security elements move with your workloads and with your applications so what is the end state for ACI the end state and where we want to take the market with ACI is day one have the ability for our customers to automate their physical networks their multi vendor hypervisor virtual networks or even containers driven networks the ability to automate through this policy driven model their existing layer four through seven services which includes firewalls intrusion prevention systems and intrusion detection systems physical and/or virtual and the ability to span multiple data centers initially through the stretch fabric spanning up to 100 kilometers and in the near future the ability to span wide area network and geographic boundaries so now you can foresee having a disaster recovery a high availability alternative data center location with full policy Federation that you would have the ability to apply in the short term as I said spanning up to 100 kilometers and in the mid term the ability to take it beyond into the wide area okay this policy model is not just constrained to your network and your network services but is extensible to accommodate and move into the compute as well as into the storage arena so day one we allow you to connect any endpoint into this network it could be any compute it would be any storage element it could be any hypervisor because we normalize the endpoint it could be any bare metal environment for us because we are a networking the level of automation and policy driven models is driven out of the network we would accommodate any and point physical virtual or containers it is ultimately about your applications and to allow your applications to be placed where you need them when you need them whether it is across different data centers with the same policy driven model that can run on Prem and into the hybrid cloud with full visibility to your physical and your virtual this is a very unique element that only the network and Sdn principles in the network and support the reason is because when you are building an underlying infrastructure you will still need to support and maintain that underlying infrastructure so when you support an SDN model you need an SDN architecture to give you the visibility of real-time information whether you wanted it at an infrastructure level or whether you want that visibility at an application centric level or whether you want it at a tenancy level and what we have done is that we have enabled you to manage your physical annual virtual networking assets with real-time visibility across this model with a CI so if there are any issues your mean time to repair is very quick because you're able to quickly identify is the network the problem if it is the problem where is the problem and quickly isolated whether it's down to a port level a link level or a box level et okay the three key elements of a CI really are focused around the tenants of the following value the first one is around automation 95% of all of our a CI customers that have taken this technology into production are automating their networks that's table stakes for them the ability to free up 40% of the affects budget is the net value that they experience through the automation of the network so the amount of time that a networking team is spending in deploying networks delivering services over that network shrunk by 40% teams that reducing their epics or their archaic time spent on that sort of stuff what are you seeing and do are they like with that extra time are they going well okay I can see a you you you you're not required anymore or are they using those people in a different way what what are they doing with that they are reusing those people it's providing the networking teams and opportunity to develop skills around writing to programmatic api's because one of the things that we have delivered in addition to a zero touch provisioning networking model is we have driven to our customers an object driven networking model which is highly programmatic and if you have the ability to write to the api's there are a lot of automation and capabilities that you can derive out of knowing that API driven model well you can add value not just within your day job of a networking person but you can add value to your security organizations you're seeing people you you use it and use those skills and better ways do more like all the stuff that we want to do but those resources now those and now you're able to repurpose those folks into delivering more cloud enabled IT practices more service oriented delivery vehicles because you have now freed up their time you're helping them develop themselves by going and learning how to write to a Python or to how to write to an XML driven API and you're saying that stuff as well the network engineers moving to that model as opposed to I guess you know you can sort of come at it from the network sorry you can come at it from the developer side so you're seeing change is sort of taking those network people and moving them towards that programmatic it is early days I would not say that I think this is the evolution this is how we see the trend going because that thinking is that I don't have to do we with my subject matter expertise but if I can free up the time because now I'm automating a lot of those functions then I can repurpose those people give them more talent allow them to learn new skills and now they have the ability really to sit with the application teams and other cloud teams and to deliver the right services that the infrastructure team can now deliver to that application development organization right because if I can do more with less I can then repurpose my team to now meet the needs in a more agile manner of the app teams without leaving behind the applications that I had that were over ten years old yeah because this missile everywhere exactly so the key point is that as our customers are evolving towards this cloud development model whether it is using containers moving towards a DevOps model we want to enable that success with a CI but we don't want to go back to our customers and say but by the way that a CI Network cannot support your old your 15 year old mission-critical workload that bare-metal workload that you we don't leave that behind because an ECI network ultimately at its root at its base looks like an IP routed big IP routed network right it looks like one big gigantic IP router you could connect any device with an Ethernet address into it you would be able to connect any device with an IP address into it and that's the advantage of bringing together the physical and the virtual we don't leave behind our customers heterogeneity and our mission and the mission critical environments and the ability to have real-time health metrics of that infrastructure whether it's your physical networking infrastructure or whether it's your virtual networking infrastructure through a single pane of glass gives you the ability then to have real-time telemetry and visibility now for us security is not something that sits outside security with stateless firewall functions is an embedded part of the network so when I turn on an ECI network seventy percent of our customers use cases that are oriented towards stateless firewall functionality a lot of those use cases are embedded at wire rate in this network okay and when it comes to having an open strategy we definitely not only have an XML northbound API but we also have delivered across the southbound API the set of calls to the IETF with seven other companies and where this policy model never existed we have contributed it into the open source community so this group policy model you can go to open daylight today and you'll be able to download the entire group policy model we also have contributed it into OpenStack this policy model also has been embraced into the Linux kernel that's today and OVS implementation of this policy model available in open source the second key element of security one being the stateless firewall is the second capability from a security point of view is multi-tenancy so when I define these policies I have the granularity to define it across tenants so from a cloud provider and I have Coke and Pepsi or if I'm a semantic and enterprise customer that is going through a divestiture I can have one network with two completely separate tenants and meet very different needs if that one business is in the security business and has a huge compliance requirement and the other tenant which is my storage business and I'm now I'm giving you the example of Symantec because they had an ACI underlying infrastructure it they were prepared to go through this divestiture with a CI being the common foundation for them with built in multi-tenancy and a policy driven model that allowed them the ability to go through with immense flexibility and yet deliver the compliance and security elements to businesses that needed to be treated very differently any questions on this chart at the base of ACI there is a cloth fabric a leaf spine architecture that is centrally managed through a centralized management controller if for any reason that controller cluster were to fail your network will keep running your policies continue to be retained even as your workloads move around that network the policies will Traverse with those workloads it's only when you have to deploy new policies it's for which that you would require the controller this is a very unique implementation from software defined only controllers where the controller is either in the data or the control path solution it's only when you're pushing out a change as such but ongoing dynamic stuff or whatever it's never in the data part it's never an important link styling whatever stuff like that the network is on it's it's an autopilot you've got the network doing its portion of the business and the portion of the business that is the apec controllers business is to purely management and policy engine but the policy repository is sitting distributed across this entire network and any movement of workloads will not require the interception of this epic controller the policies will move with the with the workload or the endpoints that you have already defined without any intervention therefore with just a cluster of three epic controllers I can support up to a million endpoints here v4 or v6 Breen to the v6 when I yep now we have complete investment protection for the networking infrastructure that our customers have already invested in when I was at Cisco live in Europe I had the opportunity to invite a few customers up on stage with me in my keynote one being Hugh branch they're a cloud provider in Europe in Sweden they are the largest hosted cloud provider and q-branch has a huge investment in the catalyst 6k so as they were taking a ACI stretch fabric into production they didn't go out there and rip out the cat 6k infrastructure they retained their existing customers onto that cat 6k network and through VLAN they were able to map those sets of clients that were on the cat 6k network into the policy driven model of the ACI network so with the ability to have full investment protection ACI will allow your customers to will allow our customers to retain the investments they have already bought and in parallel move towards a policy driven model with a CI we don't leave behind the existing IP networks that our customers have deployed ok this architecture normalizes the endpoint so whether you are coming into this network with a VMware hypervisor that you are managing using vCenter there's full integration of our epic control of it V Center today or if you happen to have a Red Hat hypervisor k vm and you're connecting a vm based host into this network we have the ability to have full integration with OpenStack and the Red Hat distribution through the epoch controller and I ability to support that if you have a Microsoft hyper-v set of users connecting into this network we have the ability to support that and in a future release it because fully gonna be integrated with the Microsoft System Center vmm and the exact same thing holds true for Xen where we have today integration with cloud stack through the northbound API and the ability to support then SunGard is one customer who's in production with a CI with a Zen's cloud stack implementation we normalize the endpoints so you may have the ability to route and switch classic networks overlay networks coming in from hypervisor environments of today okay from a computer perspective full integration with all the computer environments our customers have and in the future we will be driving further synergies into the UCS storage we are tightly integrating with the api's of Nara and EMC and today we completely support the storage as an endpoint layer four through seven services this is a unique advantage that we have over the rest of the marketplace in the ability for us to have and protect the rules that our customers already have whether it's on the f5 devices the checkpoint devices and our ability to integrate those rules and those devices through the integration of our policy model and plugins that these companies ship the ability to have them supported through a consent relized policy model what's the net advantage of that for our customers they don't have to disrupt their existing firewalls and intrusion prevention systems environments they have the ability to come to one location one policy controller for policy and compliance information as opposed to going to ten different locations and as they make changes in the policies they have to come to one place to update their policies allowing them the ability that tasks that used to take them four to eight weeks to complete between tickets that would go from the networking team to the application delivery controller teams to the security teams can now be done in minutes you're now automating not only your networks but your security operations teams your placate application delivery controller teams less human prone error right because you don't have humans repeating the same set of tasks manually and a far more agile IT experience our own IT organization has experienced 58% quicker response times as an infrastructure team to our app teams as a result of this functionality just a couple of questions coming in by Twitter this is what we do is take field days talking about some of the integrations say with checkpoint and so Keith just have interested and what's what are people doing going and how is that working in terms of real workflows and stuff is this a like a service chaining type thing or what's how how is that actually working in practice what are people doing so we are basically doing two functions one function is chaining of services in the network so you you would have the opportunity now to have multiple devices let's say you might happen to have five application delivery controllers and you would happen to have you might happen to have rules that you have already preset with checkpoint you would have the ability once you have the plugins available shipping out of f5 but you can access it on our website or the f5 website and plugins shipping from checkpoint checkpoint starting to do plugins as well exactly because for a CI yeah cuz like I've done a lot of work chicken in the past and they've always been kind of paying fold and to correct with other things only be changing that on their side as well right but they are they're going to be releasing if they already have not released the ACI plug-in it was later to come earlier this quarter but if it has and we can check that and get back to you as to the status of the plug-in but I hadn't seen any announcements around that so in December yeah so I haven't heard of really of it being released or anything so it's we can come back to you and give you the exact date of the release or this plugin Thanks so there are two advantages with this model the advantage number one is if I happen to have f5s I rules which are very sticky and many enterprise customers financial services customers have got an immense sophisticated way of integrating into these I rules you don't go in there and you don't disrupt it it's like the holy grail for the TSA's admins right we protect those we retain those but we have the ability to integrate using this plugin there big IP and the big IQ appliances through this plug-in so I retain those rules but from now on as I add more policies I not only have the ability to retain and protect those policies that they all the users had already deployed but I now come to one place to enter new policies i either a pic controller and now i have the ability to not have to go to multiple different places to apply those rules those policies i think this is tying into something else that keeps asking about around similar workflows being created with different hypervisors because if you know you're supporting beam wear so you get some VMware's and KVM whatever going on you know there's there's always different caveats around this hypervisor i can do these functions this i can do that you know you've all got their own ways of doing things and whatever i guess i think what he's asking is around you know if I can deal with this more at the epoch layer I can kind of abstract those lower levels you know I want to do a similar workflow and apply that across the different ones that's exactly right you would come to one place which is the epoch controller and whether that policy we call it a policy or a profile whether that policy or profile that you're creating is for a physical service as part of you in that profile you would define what is the collection of these endpoint groves you can define it to be correspond to a VLAN and at least common denominator level right when you say an endpoint group is defined as VLAN one endpoint group two is defined as VLAN two right let's take the basic model of doing this definition but I want to have the ability to stitch the services or firewall coming from vendor a and it could be checkpoint and application delivery controller coming from enderby and I also want to have the ability to have a virtual network service that can be chained into this policy model and I want the network to not only support the service chaining of my physical workloads but also my virtual workloads because the apec serves for you as one place for you to come to in order to support network chaining for physical and network services right and one place for you to come to for automating and driving that policy model driven model through these plugins okay so it's really got two advantages for a customer when now I'm not manually physically stitching those services in a network across my different organizational silos I'm automating that function it's an embedded part of the networking functionality the second thing is I come to one place for the policy driven model for my network and network services whether they are physical or virtual I can do it with a single pane of glass you were talking about integration with external vendors like firewall vendors does that mean that you are effectively doing firewall configuration in AP or do you still have to configure additional parameters let's say in the firewalls themselves so for our customers it was extremely important if you if you start with a Greenfield deployment we would have the ability now to through the plugins that we are offering for vendors like f5 you would have the opportunity to drive because their plugin is very sophisticated where you have the ability to integrate their I rules the big IQ appliance and the big IP appliances there's a lot of functions where you can come to the epoch controller and through the plug-in you will be able to launch some of those services but you you won't necessarily have to keep going back and forth between their appliance and our appliance you would come to one place ie the epoch controller and through the sophisticated plug-in we are striving to go the deeper integration to deliver our customers the experience of allowing them to come to one place as much as possible however there is another set of customers that want for compliance reasons the ability to have their security organization come in and do that piece of the work so you have to support both models you cannot say there's only one way I do it and the other key attribute which is a differentiation for Cisco these are the other Sdn models is we allow our customers to protect their existing rules we cannot go to a customer and say throw away all your appliance rules let's go redefine it it's a different way of doing things you have to support what they already are running in production you have to allow them to protect those assets and those programs and those rules that they've already implemented glad you mentioned that now if I believe in full integration with APEC and I already have a brownfield environment can I somehow import the existing load balancer and fireworks figuration in APEC yes not into epic you are now mapping through the plug-in of that device you are retaining those exact same rules that you had defined you don't you don't change those I would say 90% if not 95% of our deployments are doing exactly what I just told you they are retaining the state of what they are using but they are moving towards this notion of network stitching which is dynamically happening in the ACI network and coming for one location which is through the plug in the epoch controller but retaining what they already have deployed in a brownfield 90% of our deployments are brownfield and they are retaining those rules okay and last but not least our ability to integrate across our when routers so by the in this calendar you you should expect both the ASR 9k as well as the Nexus 7 K both being a multi data center data center interconnect platforms to have the policies that they are managing through the epoch controller to span your data center interconnect that's primarily talking when there is best primarily yeah connecting you DC's it's not so much about broader land connecting DC's yeah yeah in DC's cuz I'm interested in the Borah weigh-in as well but okay just yeah so we should have that convey my car but can talk a little bit about that very good awesome and then our ability through the northbound API is to integrate into customers existing system management tools hypervisor management tools are already touched upon orchestration frameworks including OpenStack as well as Microsoft Azure and systems management tools coming from BMC CA Tivoli

Channel: Tech Field Day

Views: 20,457

Rating: 4.7692308 out of 5

Keywords: Tech Field Day, Networking Field Day, Networking Field Day 9, NFD9, Cisco, ACI, SDN, software defined networking, policy, Joe Onisick, Soni Jiandani

Id: 8mG505mWE0Y

Length: 41min 22sec (2482 seconds)

Published: Sun Feb 15 2015