Why Cisco is Warming to Non-ACI Data Center SDN

There are three basic ways to do software defined networking in a data center. One way is to use OpenFlow, an SDN standard often criticized for poor scalability. Another, much more popular way, is to use virtual network overlays. And the third is Cisco’s way.

The networking giant proposed its proprietary Application Centric Infrastructure as an alternative to open-standards-based data center SDN in 2013. It is similar in concept to virtual overlays but works on Cisco gear only.

Some Cisco switches support OpenFlow, but not the current-generation Nexus 9000 line, although the company has said it is planning to change that sometime in the future. Now, however, there’s a new, more interesting twist to Cisco’s SDN story.

Last week the company announced that Nexus 9000 switches will soon (before the end of the month) support an open protocol called BGP EVPN. Older-generation lines will also support it in the near future. The aim is essentially to make it easier to implement virtual overlays on the latest Cisco switches. Theoretically, support of the protocol would also open doors for third-party SDN controllers to be used to manage these environments.

The move indicates a realization on Cisco’s part that ACI is still a tough sell for many customers, and that interest in Nexus 9000 switches is there, while interest in going all-in with its proprietary SDN is trailing behind. The company’s own sales figures confirm that reality. According to Cisco, out of the 1,000 or so Nexus 9,000 customers, only about 200 have bought the Application Policy Infrastructure Controller, the SDN controller for ACI environments, since it started shipping in August.

“This is an interesting move by Cisco in that [the open protocol-based overlay technology] is a difference from their ACI stack,” Mike Marcellin, senior vice president of strategy and marketing at Cisco rival Juniper Networks, said. “Cisco is acknowledging that ACI is not for everybody, and [that] they need to think a little more broadly.”

A Control Plane for VXLAN

BGP EVPN is a control plane technology for a specific type of virtual overlays: VXLAN. The VXLAN framework was created by Storvisor, Cumulus Networks, Arista, Broadcom, Cisco, VMware, Intel, and Red Hat. While it describes creation of the overlay, it does not describe a control plane, which is where BGP EVPN comes in.

EVPN is a protocol generally used to connect multiple data centers over Wide Area Networks. It enables a service provider to create multiple virtual connections between sites for a number of customers over a single physical network while keeping each customer’s traffic private.

Cisco, Juniper, Huawei, Verizon, Bloomberg, and Alcatel-Lucent have authored a standard for using EVPN as a network virtualization overlay. An NVO is essentially a way to isolate traffic between virtual machines belonging to lots of different tenants in a data center. It is powerful because it enables private connectivity between VMs sitting in different parts of a data center or in entirely different data centers. It also enables entire VMs to move from one host device to another.

The BGP protocol has played a key role in enabling the Internet. Disparate systems operated by different organizations use it to exchange routing and reachability information. In other words, BGP is the language used by devices on the Internet to tell other devices that they exist and how they can be reached.

EVPN relies on BGP to distribute control plane traffic, to discover “Provider Edge” devices (devices that connect the provider’s network to the customer’s network), and to ensure that traffic meant to stay within a specific EVPN instance doesn’t venture outside.

Making VXLAN on Cisco Easier

Customers have been able to set up VXLAN overlays on Cisco switches before, but without BGP EVPN it was a tedious, complicated task, Gary Kinghorn, product marketing manager for Cisco’s Data Center Solutions Group, said.

The VXLAN spec requires users to enable core switches in their networks to run multicast routing. With multicast, if one VM needs to reach another, several copies of a packet get sent out to several destinations, and only one of them reaches the intended recipient. BGP EVPN introduces an alternative and more scalable approach, where the controller simply keeps track of where each VM resides, so only one copy of a packet is sent directly to its destination.

The controller also gels with OpenStack, so users of the popular open source cloud architecture can use it to provision and automate their virtual networks.

While BGP is not a requirement for using EVPN, most people that adopt EVPN will use BGP, because it’s so widespread and well known, Kinghorn said.

Juniper No Stranger to EVPN

Juniper has supported EVPN for some time now. “It’s always been our preferred data center connectivity solution, because it is standards-based,” Marcellin said. “We support EVPN today on our routing platform. We basically built it into Junos.” Junos is the company’s network operating system.

Juniper has its own SDN controller, called Contrail, which also leverages BGP. While it can potentially be used with VXLAN overlays, it is really an alternative overlay technology. Contrail can interoperate with Cisco gear or even create overlays on top of Cisco switches, he added.

Interest is growing in using the combination of EVPN and VXLAN, although Marcellin hasn’t seen widespread adoption at this point. “It’s actually a pretty elegant way to solve basic challenges some people face.”

In Nascent Market, Variety is a Good Thing

By adding support for EVPN, Cisco is broadening its potential reach in the growing SDN market. This is a new area, and it’s too early to tell which of the various technological approaches will ultimately enjoy the most use. While it may no longer have the reputation of the cutting edge tech company, Cisco still enjoys the biggest install base among rivals in the data center market, and broadening the variety of data center SDN ideas it supports only puts it in a better position to preserve its market share in this quickly changing environment.

Correction: A previous version of this article erroneously said Juniper was looking into adding support for OpenFlow to Contrail. That is not the case, and the article has been corrected accordingly.