Frequently Asked Questions

Rate this content:
0 of 5 - 0 votes
Thank you for rating this article.

Great question!  One I have received many queries on lately.

Let's get some terms out of the way first:

ACI = This stands for Cisco Application Centric Infrastructure, so it is not one thing, but rather a collection of things.  From the Cisco ACI web page: Cisco ACI consists of:

  • The new Cisco Nexus 9000 Series Switches
  • A centralized policy management and Cisco Application Policy Infrastructure Controller (APIC)
  • A Cisco Application Virtual Switch (AVS) for the virtual network edge
  • Software and hardware innovations
  • Integrated physical and virtual infrastructure
  • An open ecosystem of network, storage, management, and orchestration vendors

APIC = This is a thing.  It stands for Cisco Application Policy Infrastructure Controller.  I will discuss this more below.

Now I can get to answering the question.  Cisco and SDN have had a bit of a rough start.  Cisco missed acquiring Nicira, which was acquired by their frienemy VMware.  What followed was some mixed messaging and marketing on SDN in general.  Let's face it, Virtualization has been a wild fire of innovation, and network virtualization is a hot bed within the wild fire.  Many companies that have been traditional hardware/software vendors are struggling as products within their portfolios are competing against each other.  If I can take a bare metal server and convert it into my top of rack switch/router, why do I need to buy hardware?  I am not saying that is entirely possible, nor am I saying that data center operators do not need to buy switches and routers.  What I am strongly suggesting is that this is one of those interesting areas that many of us are watching carefully.  

What the ACI and APIC are at the time of this writing is Cisco's giant step forward in term of the network virtualization and network function virtualization that are rapidly developing.  If you are an old school person, you could simply say that the APIC is a network management platform, and stop the discussion at that.  The APIC is about organizing data and designing work flows across a network infrastructure.  While it has the word "Controller" in its name, it is not like a typical SDN Controller.  SDN Controllers are part of the data plane in that they receive the first packet of an application flow and then send the corresponding policies to the network of switches, including path.  The APIC does not do this.  

Here is a summary comparison:

 Generic SDN Controller  Cisco APIC Controller
 See's Packets  Never See's Packets
 Controls Paths  Does not control path/routes (leaves this to the routing protocols)
 Defines Policy  Defines Policies via Network Profiles 


Screen Shot 2014-12-05 at 11.00.29 AMThe way that the APIC sees the world begins with End Point Groups.  

The slide shows three Web Servers that will be providing a similar set of applications to outside a certain enterprise.  These web servers will be treated similarly, so we can add them into an EPG. 

Via simple on screen click and group process, these network devices are easily grouped together and named.

If you think about the three tier model of Web Servers <> Applications Servers <> Data Bases, we could do the same process of grouping the applications servers and the database servers in this manner.

The next part is extremely important in the APIC.  Once your EPG's are specified you can then add what Cisco calls a "contract" between the EPG's to define what communications can occur.  Everything else is blocked by default.  For example the Web Server cannot talk directly to the Database Server.

Screen Shot 2014-12-05 at 11.12.01 AMPolicies are reminiscent of ACL's in router and switches, but of course much more powerful.  What the APIC system does it it then communicates the appropriate command line or protocol commands (the system supports OpenFlow as well as Cisco's home grown protocol) to then implement the policies onto the network infrastructure.

Next is where things get interesting.  Imagine for a moment that these policies all exists within a collection of Virtual Machines (VM's) at a data center for a particular customer and that customer decides they want to move servers to a different data center due to an impeding typhoon.  The APIC system allows the abstraction of the functions, policies/contracts and configuration to be transported to another APIC in the second data center.  This move can be accomplished in comparably minute time frames using this orchestration.

The answer then to the original question is that Cisco has developed an architecture called ACI that includes their APIC that can control network nodes and SDN controllers, dissimilar to the generic SDN controller which is in the data path.  I have heard and read some descriptions that Cisco is anti-SDN with their solution, and I would disagree because the APIC is not a replacement for the generic SDN controller.

I hope this explain and clarifies, albeit at a high level, and provides an answer to the question.  If you would like to look a little deeper into SDN you can look here.  Also, there are some details in our OpenFlow explanation you can find here.

I hope you find this article and its content helpful.  Comments are welcomed below.  If you would like to see more articles like this, please support us by clicking the patron link where you will receive free bonus access to courses and more, or simply buying us a cup of coffee!, and all comments are welcome!



Add comment


Did you learn something?
Did I save you time? 

Buy me a coffeeBuy me a coffee!

Find by Tag

5G Networks 6LoWLAN 6LoWPAN 802.11 802.11ah 802.11ax 802.11ay 802.11az ACL Addressing Analysis Ansible Architecture ARP Assessment AToM Backup Bandwidth BGP Bibliography Biography Briefings CBRS CellStream Cellular Central Office Cheat Sheet Chrome Cisco Clock Cloud Computer Consulting CPI Data Center Data Networking Decryption DHCPv4 DHCPv6 Display Filter DNS Documentation ECMP EIGRP Ethernet Ethics Flipping the Certification Model Follow Me Fragmentation Git GNS3 Google GQUIC Hands-On History Home Network HTTPS ICMP ICMPv6 IEEE 802.11p IEEE 802.15.4 In A Day Internet IOS Classic IoT IPv4 IPv6 L2 Switch L2VPN L3VPN LDP Learning Services Linux LLN Logging LoL M-BGP MAC MAC OSx Macro Microsoft mininet Monitoring Monitor Mode MPLS Multicast Name Resolution Netflow NetMon netsh Networking Network Science nmap Npcap nslookup Online Learning Online School OpenFlow OSPF OSPFv2 OSPFv3 OSX Parrot PIM Ping Policy POTS POTS to Pipes PPP Profile Profiles Programming Project Management Python QoS QUIC Requirements RFC RIP Routing RPL RSVP Rural SAS SDN Security Self Certification Service Provider Services Sharepoint Small Business Smartport SONET Speed SSH SSL Subnetting T-Shark TCP TCP/IP Telco Telecom 101 Telecommunications Telephone Telnet Terminal TLS Tools Traceroute Traffic Analysis Traffic Engineering Training Travel Tunnel Utility Video Virtualbox Virtualization Voice VoIP VXLAN Webex Wi-Fi Wi-Fi 4 Wi-Fi 5 Wi-Fi 6 Wi-Fi 6/6E Windows Wireless Wireless 5G Wireshark Wireshark Tip WLAN ZigBee Zoom

Twitter Feed