ACI is Cisco’s take on Software Define Networking (SDN). We have all heard by now that SDN is going to be the new way of doing things that will make networking more agile, easier, and cut down cost. Unlike the Openflow approach to SDN, Cisco maintains that SDN is a software and hardware solution. ACI does not view the network as composed of generic “white boxes” taking instruction from the controller. ACI requires Cisco routers and switches to form the infrastructure.
The routers and switches will take policy enforcement from the brain of ACI, the Application Policy Infrastructure Controller (APIC). Cisco is starting ACI at the Data Center and in the future support in Campus and WAN. To do this, Cisco plans to incorporate ACI capabilities to a selection of i'ts existing product line of routers, switches, firewalls, and wireless devices. From this perspective, there is the promise of investment protection. The picture is a little different in the Data Center space. More on that later. Basics of ACI
The building blocks of ACI are End Point Groups (EPG), Contracts, and Application Network Profile (ANP). EPG’s are network elements defined by the network Administrators. EPGs can be VLANs, Subnets, Hostnames, service ports such as HTTP, etc. Network Admins create Contracts to define parameters such as QOS policy or Access Control to allow multiple EPG to communicate with one another. Contracts are the policies that glue the EPG’s together. The conglomeration of EPG’s and contract is called an Application Network Profile. For example, if you have an EPG of Web Servers and you have them communicating to a Database EPG via explicit contracts, this constitutes an ANP. The ANP is then pushed out to the ACI infrastructure via the controller. Integration
As of now ACI works with the new Nexus 9000's. One catch is that the actual Controller will not be available until April 2014. By the second half of Cisco's FY14 (after April), UCS, Nexus 1000v, Cisco ASA firewalls, and Cisco ASR routers should integrated into ACI. In addition, Cisco has partnered with all the major vendors such as VMWare, Microsoft, Citrix, F5 and others to allow ACI to manage these hypervisors and appliances in the context of building Contracts and stitching the EPG’s together into an ANP. Data Center
In November 2013 the Data Center hardware to support ACI was released. These are the Nexus 9300s and the Nexus 9500s. The hardware was developed by Insieme, the latest Cisco spinoff company that was recently reacquired. ACI at the Datacenter requires this new product line and will not work with the current Nexus portfolio. This is an interesting position to take because there is a large install base of Nexus 2K, 3K, 5K, and 7K. These are excellent DC switches and will continue to be for the foreseeable future. Incompatibilities aside, the Nexus 9K are excellent high end DC switches with many innovations. They are capable of running either in stand-alone mode or in an ACI deployment.
The Nexus 9300 and 9500 ACI capable switches
In an ACI deployment, the Nexus 9Ks are deployed in overlay Spine and Leaf setup to form the ACI Fabric in the Datacenter. This should sound familiar if you have been thinking about or using technologies such as Cisco’s Fabric Path and and IETF’s TRILL. Unlike Fabric Path and TRILL, the ACI Fabric is layer three running IS-IS, carrying VXLAN packets. In Cisco’s defense, VXLAN has to be in hardware for switching speed, making ACI not backward compatible with the existing Nexus portfolio. For those not familiar with VXLAN, it is an overlay protocol that allows for Layer 2 Frames to be routed over layer three networks. Cisco added proprietary tagging to the VXLAN header for flow control. Cisco calls it eVXLAN tag. Throw in the APIC controller into this Fabric and you have the base ACI deployment in the DC.
Learn More: www.ciscolive.com/online/connect/flowPla...lat/SUPDCT-2572e.mp4 newsroom.cisco.com/release/1332017/Cisco...ility?utm_medium=rss