White box switches have been around for years, but adoption has been limited to niche companies that have large engineering departments. The rise of software-defined networking (SDN) has brought them into the public eye, though, as a lower-cost alternative to traditional network hardware. In fact, some of the early messaging around SDN revolved around using white boxes as a complete replacement for all network hardware.

Despite the promise that SDN brought, the use of white boxes has been limited for a couple of reasons. The first is that historically, any organization that wanted to leverage a white box switch needed to have a number of technical specialists that many enterprises do not have. This would include network programmers and engineers fluent in Linux. These skills are commonly found in companies such as Facebook, Google and Amazon, but not so much in your average enterprise.

The other reason is that the operational costs of running a white box could be high. While the price point of the individual boxes is low, the cost of hiring programmers, support people and other staff drives the operational costs up. It’s hard to justify lower hardware costs at the expense of an increase in operational costs.

However, much has changed in the past few years, and white boxes have come a long way from where they were. I believe they are now ready for a broader range of companies to use.  I’m sure many of you reading this will be skeptical, as you may have taken a look at white boxes in the past and decided they weren’t for you. But if you do a little bit of due diligence, you can see the white boxes have improved significantly in the following areas:

• Cost and reliability. It may seem odd to put cost and reliability in the same bucket, but they do go together because we generally believe things that cost more are also more reliable.

  The reality is that the silicon and other hardware are often sourced from the same companies that mainstream hardware vendors use. What the customer is often paying for is the software that rides on top of the hardware and the logo. From a reliability standpoint, white boxes are on par with brand-name systems because they are actually the same hardware. 

• Features and capabilities. The question for buyers with respect to white box features is, “Are you compromising the features you need to run a network?” To answer that, one must understand the features required for the role white boxes play. There’s no question that white boxes are not at feature parity with layer 2/3 switches for uses such as campus switching or aggregation.

  However, that doesn’t really matter because no one would buy a white box for that. White boxes typically are used as a top-of-rack switch and/or as part of an SDN deployment, and white boxes are at feature parity for those use cases. They support industry standards such as OpenFlow, are highly programmable and work with orchestration tools such as Ansible, Chef and Puppet. 

  Also, white boxes tend to have strong telemetry capabilities and are more open so network administrators can get whatever information they need, when they require it for whatever purpose. In fact, in this area, it’s fair to say white boxes are often superior to traditional layer 2/3 switches. 

  Think of a traditional switch as a Swiss Army knife with a number of features that you may or may not use. A white box is more like a hunting knife where it has no spoon and fork but is optimized for one specific task. A white box is the SDN equivalent of that and has capabilities that are geared towards new workflows and where the SDN industry is headed.

• Network operations. Here is where white boxes have taken a hit mostly because there’s a fear of the unknown. Most engineers, even novice ones, understand the process of pulling a Cisco switch out of the box and getting it up and running. With white boxes, there’s much more uncertainty, and questions pop into network managers’ heads that make them skittish—things like “Do I have to write my own operating system?” “How do I install a network operating system” “What do I buy?” “What are all the steps involved?” “Who will provide me support?”

Those are all valid concerns, and I understand why it would give someone the heebie-jeebies. The lower cost and flexibility is great, but if it’s harder to get up and running and manage, then all the benefit you hoped to get would be wiped out because of the complexity.

But times have changed, and network engineers should no longer despair because white boxes can now be purchased from mainstream networks vendors such as Dell and HP. Also, these will come shipped with tried-and-true network operating systems from vendors such as Pica8 and Cumulus.

Also, when one purchases a white box from a vendor like HP and Dell, those suppliers will offer the kind of technical support most engineers need. So, if the organization is used to procuring a solution from a traditional supplier that includes hardware, software and support, the experience for a white box will be almost identical. Lastly, technical expertise around white box has grown. The number of operators that are familiar with ONIE and ODM white box vendors is much greater. This has increased the learning and best practices, making the white box universe much larger—and it’s growing daily.

From the interviews I have done with mainstream companies, I know there is tremendous interest in white boxes. Despite the maturity of the products, there is a fair amount of trepidation around these products. It’s my opinion that white boxes are certainly ready for mainstream adoption. Obviously they aren’t for every use case, but in the right situation, like an SDN deployment, they can be as good or better than traditional switches with a much lower price point and equivalent operational costs.

My recommendation is that instead of fearing the unknown, take one out of a test drive and see for yourself whether it meets your needs.