imelamory - Fotolia


Juniper OpenContrail vs. Cisco ACI: Making an SDN decision

Juniper and Cisco have radically different SDN strategies. Here's some crucial information about the Cisco ACI vs. Juniper OpenContrail decision.

It's often said that choosing an SDN strategy boils down to a Cisco vs. VMware decision.

Yet, many network engineers will seek SDN technology from their trusted networking vendors. As such, they're just as likely to make a Cisco ACI vs. Juniper OpenContrail decision.

But the differences between Juniper's OpenContrail and Cisco ACI are stark, and the two can't be explored in an apples-to-apples comparison.

OpenContrail is a software strategy that relies on a centralized controller and a virtual network overlay built on top of an abstracted physical underlay. OpenContrail provides two key components of a software-defined network: the open source network controller and a hypervisor-resident virtual router. The virtual router is deployed on a virtual server hypervisor and provides links between servers within the host as well as across the physical underlay using tunneling protocols. So far, only open source hypervisors such as kernel-based virtual machine (KVM) and Xen are supported in the OpenContrail ecosystem.

By contrast, Cisco ACI is a pre-assembled, integrated hardware and software strategy that also enables a virtual overlay, though one that is much more closely integrated with the underlying physical network made up of ACI-supportive switches. The overall infrastructure consists of three components: the Application Policy Infrastructure Controller (APIC), Nexus 9000 series switches, and Cisco's own hypervisor-resident Application Virtual Switch (AVS). AVS is the Nexus 1000v rebranded and upgraded with the necessary integration into the APIC. As result, there is "enterprise-friendly" hypervisor support for VMware ESXi and Microsoft Hyper-V, as well as KVM for cloudier organizations.

ACI vs. OpenContrail: A hardware vs. software debate

One of the central questions that arises in the OpenContrail vs. Cisco ACI debate is whether hardware should be a central part of an SDN deployment.

For Cisco ACI to be its most effective, enterprises must invest in Cisco switching. Meanwhile, OpenContrail software can be implemented over basically any underlying physical infrastructure as long as the right hypervisors and virtual routers are in place. It's a simpler investment, but critics say the software overlay approach doesn't do enough to address the health of the underlying physical network.

The good news for Cisco users is the company is retrofitting the existing Nexus 1000 to 7000 series to support the new ACI ecosystem. When ACI was first announced, it was to be used with new Nexus 9000 switches, but there was no support in earlier Nexus versions.

The advent of an upgrade path opens the door to SDN for many existing Cisco shops and broadens the enterprise appeal. Indeed, the official documentation acknowledges that for ACI to succeed, it must be integrated easily into existing data center architectures. Inevitably, existing Cisco customers are likely to be the earliest adopters.

Cisco's joint hardware and software approach without doubt has merit. However, the history of computing is littered with the corpses of superior technologies sidelined in favor of those that were cheaper and easier to implement.

OpenContrail doesn't provide any of the underlay networking components. Instead, network pros can implement it with existing infrastructure as the network underlay, and build upon it to link virtual hosts and entire data centers.

However, this approach will only work if the current network infrastructure is up to the task. Overlay networking will inevitably make demands on existing switching and routing capabilities. Many users are concerned about problems that will arise if there is not enough of a connection between overlay and underlay.

It is perhaps understandable then why Cisco attempted to solve SDN by making high-end, state-of-the-art switching part of the solution from the outset. If you want to software-define networks, then the capacity and performance hardware platform must be unimpeachable.

Cisco ACI and Juniper OpenContrail are missing important case studies

When a technology is shiny and new like SDN, early-adopter case studies are critical. Early adopters can shape the entire market's perception of how well a technology will work.

This is a problem for both Cisco and Juniper. Cisco has nice videos of customers talking about ACI, yet none admit to having deployed it in production environments. I have no doubt that the Nexus 9000 series is selling like hotcakes, but without a deployment of APIC and the inevitable infrastructure changes it will require, it's still just a big switch that could be migrated to SDN at some point. Users simply need to have some idea of the potential pitfalls or challenges they'll have to tackle.

The picture is a little rosier with OpenContrail, but not much. I could only find one customer/developer reference story in a French service provider. There are rumors of another in the Far East taking the plunge, but this single swallow hardly makes an SDN summer.

It's quite possible that SDN use case studies are simply difficult to produce because few organizations have attempted it, and those that have are finding it so challenging that they don't have time to sit around writing rosy reviews.

Rebel alliances: Just how important are vendor partnerships?

Both Juniper and Cisco aim to have an ecosystem of partners that will develop applications to run on top of their controllers. These applications will bring flexible Layer 4-7 services and orchestration among other features to programmable networks.

Both Juniper and Cisco have formed important partnerships with a host of vendors and application developers. Yet the two ecosystems may take different shape due to the open community aspect of OpenContrail.

OpenContrail has been busy forming alliances and posting code, and the ecosystem has started to grow. The gains are modest but important; there is working integration for common platforms, including Juniper's MX, Cisco ASR, Apache CloudStack and Citrix CloudPlatform.

The reality of an open source approach to OpenContrail is that it's probably in the hands of more developers and network administrators than any other SDN component. A cursory look around Juniper's github repository shows the project is under active development by a small, but invested, community. While a proportion of these developers may only be tinkering for their own amusement, the OpenContrail standards and methodologies will start to gain acceptance as the norm. Even if OpenContrail itself never reaches wide deployment, it's likely to found the thing that ultimately replaces it.

Cisco has not been idle. The company has picked up big-name corporate alliances with Microsoft, F5, IBM, Citrix and others, specifically around the ACI technology.

While such corporate alliances are important, they are often fragile, and are only one acquisition deal away from experiencing their own Red Wedding. That said, loose alliances are often tolerant of failure; if a key vendor drops out, then another may step into the breach. The verticalized nature of Cisco ACI means the whole ecosystem is only as strong as its weakest link; the challenges and resolution of issues can only come internally within an enterprise. With an open source set of technologies backed by a major vendor, users have support in tackling issues.

VMware's role in the ACI vs. OpenContrail decision

For both platforms, VMware will continue to be the elephant in the room. The vendor-agnostic approach and lack of specific hardware dependencies of VMware's NSX will challenge both camps. Plus, VMware already has a huge hypervisor presence in so many enterprise data centers.

However, NSX's growth is likely to be constrained by prohibitive licensing and support costs. For most organizations looking for an SDN technology partner, I believe it will always be one of two two-horse races: Cisco vs. VMware or VMware vs. Juniper OpenContrail. It will be interesting to see how Cisco and Juniper work out future partnerships or working relationships with VMware in the network virtualization arena.

About the author: Glen Kemp is a professional services consultant for Fortinet Inc. in the U.K. His words are his own and do not necessarily reflect those of the company he works for. He designs and deploys network and application security tools, including access control, remote access, firewalls and other "keep the bad guys out" technologies. His blogs can be found at and at the Packet Pushers Podcast. Follow him on Twitter@ssl_boy.

Next Steps

Juniper open sources Contrail network virtualization

Why one cloud provider adopted Juniper Contrail

Understanding the Cisco ACI licensing model

Cisco APIC controller extended to campus and WAN

This was last published in July 2014

Dig Deeper on Software-defined networking