Cisco ACI vs. OpenFlow SDN Implementation

Many of the IT staff we work with involved in a Data Center refresh of 100 racks or more are befuddled by the many choices and nuance of SDN.  The concern is no one wants to make a purchase to find out 2 years later that a bad choice was made because a certain protocol or feature is lacking. Not to mention contention between open standards and closed proprietary functionality will bifurcated the market into the "have" and "have not ."

Having a dilemma instead of an knee jerk "oh' let's just get Cisco"  is the increasing norm because no one wants to buy throw away technology or, even worse, get fired for not doing due diligence.   As a result, many are having discussions and meetings with Cisco, HPE, Arista and less frequently VMware to understand the SDN differential to vet options that align with a 5 year plan.   Unfortunately, many organizations get stuck on overlay vs. underlay and some never get pass this first stage of investigation.   No need to worry, the key anatomical parts are in the Control Plane, OpFlex or OpenFlow, declarivive vs imperative.

Cisco supports OpFlex in its Nexus 9000 switches – the control logic of ACI and included in Nexus 1000V virtual switch, ASR 9000 routers, Nexus 7000 switches and SourceFire security platforms.

Even though Cisco is the diminishing leader in the networking industry, OpFlex may become an easy choice. Cisco many times is put in a defensive position having to explain a significant difference from the rest of SDN players leading the market. 

OpFlex is designed for communications between a central controller and network devices, but has a different way of distributing the message. While OpenFlow centralizes the network control plane on a controller and can push commands down to OpenFlow enabled network devices. OpFlex centralizes policy control and relies on traditional and distributed network control protocols to push commands down. 

OpenFlow limits an SDN Controller’s ability to verify that switch flow tables are configured within the expected rules. Because of the centralized nature of OpenFlow, special care must also be taken to avoid denial of service (DoS) in applications.