In this blog, I will cover the basics of White box switches, current software models in White box switches, architecture overview of popular White box vendors(Cumulus, Big Switch, Pica8), popular Opensource projects related to White box switches and some final thoughts on the future direction.
In the current Networking switches, hardware and software are tightly coupled and it is not possible to change the software from 1 vendor to another keeping the hardware as same. This is different from Server space where hardware and software are decoupled completely.
The term White box Switch refers to a Networking Switch where hardware and software are loosely coupled and it is possible to change 1 of them keeping the other as same.
Following are some of the advantages of White box switches.
- Multiple choices and no vertical lock-in to a single vendor.
- Can increase speed of innovation.
- Can reduce capex and opex.
Following are 3 models that seems to be emerging among White box switches.
In this model, the software vendor will sell networking software stack that consists of base OS as well as traditional L2/L3 software that has been validated for specific hardware platforms. The hardware platforms would typically use merchant silicon for switching functionality. The software vendor here will tie in the control software with the merchant silicon sdk.
I could not find a better title for this model. The title goes against the SDN definition of splitting the control and data plane. You can refer to this video from JR Rivers where he says that disaggregating hardware and software, allowing the capability to add and remove software modules and using latest software tools is more important than the control, data plane seperation model that some folks tie SDN to.
Cumulus Networks fits into this model perfectly. Infact, Cumulus Networks created this model… Following block diagram gives building blocks of Cumulus architecture.
Following are some notes:
- Kernel space consists of core networking components and networking applications like routing are present in user space.
- There is a tight integration between the kernel components to the switch sdk.
- There is no Openflow agent provided, that means direct access to switching logic is prevented.
- Since Linux OS is used, this means all the tools associated with Linux can be used here.
- The user space modules provides apis that allows for third party integration. For example, Virtualization solutions like Vmware NSX and Midokura Midonet have already integrated with Cumulus software.
Openflow switch model:
In this case, the software on the switch consists of a light OS with just the Openflow agent and the sdk needed to access the switching asic. All the intelligence is offloaded to an external controller. Intelligent applications can be written on top of the controller. The applications can either be written by the vendor providing the light OS and Openflow agent or can also be written by third-party.
Big Switch Networks fit into this model. Following block diagram gives the components of this model from Big Switch Networks.
Following are some notes about Big Switch model:
- Switch Light OS is the base OS that has been validated with standard hardware platforms with merchant silicon.
- Indigo is the Openflow agent to talk to the merchant asic.
- Big Network controller talks to the Indigo Openflow agent to provision the switch.
- Applications can be written on top of Big Network controller.
- Big Switch Networks have application products like Big Tap monitor and cloud fabric that they sell commercially, these applications reside on top of the controller.
The software vendor here allows for both the traditional L2/L3 networking stack as well as Openflow agent to co-exist in the same Switch. The customer can then decide which mode to use. Pica8 seems to be using this model.
Following 2 pictures illustrate Pica8 model:
Popular Opensource projects:
Following are some popular Opensource projects that are helping out this White box revolution.
Open Network Linux – Linux distribution for “bare metal” switches.
ONIE – ONIE is a small operating system, pre-installed as firmware on bare metal network switches, that provides an environment for automated install and provisioning.
Floodlight, Opendaylight – These are SDN controllers.
Indigo – Indigo is an open source project aimed at enabling support for OpenFlow on physical and hypervisor switches.
Some final thoughts
White box switches market is here to stay. That does not mean the traditional switching market will go away. Big Enterprises might not make the switch immediately. Big Cloud providers like Amazon, Google are already using baremetal switches with their own software. I think the initial market for White box switches would be the Data center space after which they will try entering into SP and Enterprise space.
Between the 3 models above, which model will win? I think it is possible for all 3 models to co-exist. Initial Openflow switches were not scalable because of Open flow protocol limitations as well as Openflow agent limitations. Recent Openflow protocol versions removed some of the scalability issues. If I look at some of the Open flow applications like Big tap, policy based routing, they seem to be targeted towards specific use cases. Its not clear to me if Openflow can be used for a distributed complex application.
Regarding the hybrid model, what I understood from some reading is that it is difficult for traditional L2/L3 switching to co-exist with Openflow model since its difficult to share the hardware resources cleanly between the 2 models. I was wondering if a Flowvisor model could be adapted here where the hardware resources can be virtualized between Openflow and traditional applications.
This is a wide topic. If anyone has thoughts on this, I would be happy to hear and discuss.
- Cumulus Networks
- Big Switch Networks
- Jason’s Blog
- Techtalk from Big Switch
- Blog from Ethan banks
- Basics of bare-metal switches
Pictures used in the above blog are from the references.