New Details about Cisco ACI: OpFlex

Peter Welcher
Architect, Operations Technical Advisor

Recently, Cisco generously provided a briefing to the CiscoChampions, updating the group with new details about Cisco ACI. The presentation was NDA until April 2, I presume coordinated with announcements to be made at InterOp. The biggest new item I noticed was OpFlex. I’ll tell you what I know about OpFlex below, somewhat below the tantalizing diagram. I’ll be posting this quickly in the morning, then off to various tasks. When I can, I’ll look at any announcements and apply corrections if necessary.


The CiscoChampions ACI update session started with a review of ACI policy, End Point Groups, etc. See my and other prior blogs, also recent CiscoLive presentations (links below).

If you’ve been paying attention, the Nexus 9K line is attractive for its cost effective 40 G ports, leapfrogging the 10 G generation of switches. Cisco partners are being incentivized to sell N9K as well. Cisco claims over 800 customers already for the Nexus 9K line, first announced in November of 2013. They run a cut-down version of NX-OS. See my prior blog What Features Does the Nexus 9K Support? for the features supported by the Nexus 9K right now.

Cisco is announcing the 9504, a smaller-sized Nexus 9500, shipping now. You’ve no doubt noticed the recent mentions of the large 9516 as well!

For what it’s worth, I personally somewhat expected ACI to be a big datacenter play, due to integration, early complexity, and relative value of automation. Somewhat to my surprise, I’m seeing smaller organizations are also interested. The agility, automation, doing more with less staff, and policy control all are getting favorable reception. I do strongly think such organizations are not going to know how to hire appropriate programmers, nor are they going to want to manage or support script development — a canned offering will be key to such customers.

Cisco also talked about the rather large Nexus product line, and positioning. They are becoming orientated towards use cases, and with such a large portfolio, there is at present some overlap. See also my prior blog. Nexus: What Goes Where

I see this as coming down to ports / speeds / costs plust “NX-OS with features”, DFA capable devices, or “vanilla NX-OS” with future ACI capability. (Still due second quarter of 2014.)

We were given a fairly lengthy demo of the ACI GUI, considering the 2 hours available. The presenters emphasized the GUI is like to change in appearance, so I’m not going to post screen captures. One note-worthy point was that the objects in ACI are to be exposed for consumption equally via GUI, API, CLI, and even Linux shell file system representation of objects. You can cd to a directory, vi a file, and save and the changes will automatically propagate. Not that doing so is the most efficient way of doing so.


Then we get to the New! Cisco is providing an open Southbound API for ACI. It is to be called OpFlex. As with most Cisco announcements recently, the ecosystems part is huge, including partners such as: Citrix, Embrane, F5, IBM, Microsoft, RedHat, SourceFire, Canonical. (Note who is not on that list!)

By the way, googling “Cisco OpFlex” reveals that there have been a couple of prior mentions, and some recent discussion.

OpFlex will come with an open source embeddable agent. It will peer with the ACI fabric and exchange policy. Cisco is proposing an open standard to provide investment protection. (Hence announcement at InterOp, and an RFC to be published at/around the time of the announcement.) OpFlex will come with an open agent for Open vSwitch (OVS), an ODL component, intended to be re-usable across device, i.e. a reference for porting code to other platforms.

The presenter discussed imperative control, where explicit orders must be given, and contrasted that to declarative control, where you set policy. The analogy provided was baggage handlers (read baggage label, place it on right belt) versus air traffic control (tell plane the runway and what to do, but not the details of how to do it). The point being that simpler interoperability requires abstract policies passed down to intelligent devices, with the policy endpoing then mapping the policy to the hardware.

One use case for this is for virtual switch integration with hypervisors, deploying policy across multiple hypervisors simultaneously. (Is this Cisco positioning ACI as a “meta-hypervisor”?)

Is ACI being positioned as a “meta-hypervisor”?

(Not to mention “InterCloud”?)

OpFlex also gives ACI a way to exchange policy with L4-L7 devices.

ACI gives vendors the ability to write device packages, as Cisco has previously discussed. By doing so, users can upload a script to ACI from the vendor, allowing direct calls to the vendor API. The vendor can leverage OpFlex as well.

Related Links

(There are more Practical SDN blogs listed at the beginning of that blog)

Hashtags: #CiscoChampion #ACI #OpFlex 

Twitter: @pjwelcher

Disclosure Statement

ccie_15years_med CiscoChampion200PX

Leave a Reply


Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.


Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.


John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.