OpenStack Networking: A look at Neutron network orchestration
A comprehensive collection of articles, videos and more, hand-picked by our editors
Arista Networks advanced its position in cloud networking and software-defined networking by adding Arista OpenFlow...
1.0 support to its 7050 switches and contributing a driver that allows any vendor to use OpenStack Quantum for unified orchestration of virtual and physical network elements.
Arista also introduced a new series of application programming interfaces (APIs) for its Extensible Operating System (EOS), eAPIs, which can integrate with orchestration and provisioning tools and applications.
Unified OpenStack orchestration
The multi-vendor driver that Arista contributed to OpenStack unifies how OpenStack orchestrates physical and virtual network elements. To work with this driver, networking vendors can write specific plug-ins, which Arista has already done. This new driver will be part of OpenStack production code with the upcoming Havana release.
"Prior to that, you were locked into a plug-in from a specific company and it wasn't always completely open and you did what a company told you to do," said Anshul Sadana, Arista's senior vice president of customer engineering. "Now physical switches are truly managed and monitored like virtual resources within OpenStack."
Concurrent orchestration of physical and virtual networks is a big deal, according to Bob Laliberte, a senior analyst for Enterprise Strategy Group.
"SDN includes network virtualization and [technologies like] OpenFlow on physical switches," Laliberte said. "What's important is combined management. Nicira says the physical network doesn't matter, but we know you still have to have control over the [physical] network. You may have [to] make changes to port configurations; to be able to control both the physical and virtual network is going to be important."
Arista's OpenFlow 1.0 support
Arista's OpenFlow 1.0 support will begin on its 7050 switches. This support includes a direct flow mode that allows administrators to program certain flows via a command-line interface (CLI) instead of through a central controller, Sadana said. This direct programming of OpenFlow flows allows administrators to use CLI to program exception flow handling, whereby the switch can default to traditional network protocols for flows that are not under the authority of the SDN controller.
"We've been in beta mode for nine months," Sadana said. "Some of the network administrators came back and said they like the flexibility that OpenFlow provides, but they're not yet ready to give full control of the infrastructure to controllers. They are looking at it almost as an ACL, but one that is very flexible. "
Like many other early supporters of OpenFlow, Arista is supporting OpenFlow 1.0 rather than OpenFlow 1.3. Supporting the earlier version of OpenFlow means that Arista's switches will have limits on the amount of flow definitions they can store.
OpenFlow 1.3 support will take time, according to Brad Casemore, research director for IDC. OpenFlow's custodian, the Open Networking Foundation (ONF), had been releasing versions of the protocol at a rate that was too fast for networking vendors to keep pace with, he said. Vendors like to see proof that a protocol is stable before they rewrite their firmware to support it. The ONF has since slowed down the pace of OpenFlow iterations to give vendors more time to support it.
"What we're seeing is OpenFlow is a relatively young protocol," Casemore said. "It's going to take some time to get that ecosystem in place."
Arista's eAPIs: Integrating switches with everything
"To me, [eAPIs] are just about opening up and getting greater levels of programmability," Laliberte said. "It's all around direct flow control and controller-less operations for flow matching. You can leverage that without a controller or through OpenFlow with a controller."
Let us know what you think about the story; email: Shamus McGillicuddy, news director.