Big Switch Networks and the (possible) Future of Networking Hardware


Over the last couple of years, two major philosophies for SDN have evolved which I will call the overlay model, and the flow programmability model. Overlay networks are the notion of building multiple virtual networks in parallel on top of a physical network fabric, using some means of separating the virtual networks — typically an encapsulation method like VXLAN or NVGRE. Then we have the “flow programmability” model, based on the idea of programming SDN behaviors on a flow-by-flow basis into your existing (or new) physical and virtual network switches using a protocol like OpenFlow.

Lately, the overlay model has been getting a lot of attention with solutions like VMWare NSX, and the increasing support for VXLAN encapsulation in several networking and server products like Cisco UCS and a variety of switch manufacturers that hopped on board with NSX.

Personally, I still question whether overlays are SDN or whether overlays are an application enabled by SDN (like L3VPN is an application of MPLS). Regardless, this model is favored by some vendors as a means to SDN-enable your existing network, possibly just with the addition of a few “gateway appliances” which can introduce those not-yet-virtualized resources into a specific overlay.

Right around the time of Networking Field Day 6, Big Switch Networks announced they were moving away from overlay designs and embracing SDN-capable hardware switches — what I’m calling the “flow programmability” model. Again, the idea here is that you would be defining those SDN behaviors, associations, affinities, etc., by programming the actual hardware (or virtual!) switch forwarding planes via some centralized control point. Many people get excited about API-enabling this capability, but I think the concept is just as valid using a GUI or CLI on the central control-plane.

Each camp flings FUD at the other: Flow programmability vendors and OpenFlow advocates seem skeptical of the scalability of overlays that just keep getting… overlaid on top of one another. On the other hand, flow-level tracking of thousands of hosts in a central controller also seems to have potential scalability problems. Some vendors have come up with innovative solutions to some of these scaling problems, but that’s fodder for a future blog post. (PS- I’m well aware both linked articles in this paragraph are by the venerable Ivan Pepelnjak, but he illustrates the FUD very well, even though he is not the one slinging it)

Back to Big Switch and what their change in deployment strategy might mean. Big Switch is now moving toward the flow programmability model using “bare metal” switches, running their SwitchLight software for “native SDN” capability. As you can see from this slide out of Big Switch’s presentation, they consider this a key element of the evolution of SDN.


I was amazed to learn that we’re already at SDN 2.0! It took much longer to reach Web 2.0…

Anyway, “bare metal” switches are a pretty new concept, and are a fascinating idea to me for a couple reasons:

  • They decouple the hardware and software. It’s like buying an old Linksys WRT54G and then sticking DD-WRT or Tomato firmware on it. The device may have come with some firmware to provide basic functionality, but other third-party software can be loaded to unlock amazing potential. Want to try different software for a bit, and maybe revert back to what you were using? No problem, just flash and go.
  • Attractive pricing. Based on some quick Google research of the models on the Hardware Compatibility List of Cumulous Networks, which is following a similar strategy to Big Switch, the prices of 1G and 10G bare metal switches aren’t earth shattering, but they’re definitely cheaper than the ones with a little picture of a famous bridge on them. More notably, they really do commoditize the switching hardware. They all use the Broadcom Trident family of ASICs, and mostly come from low-name-recognition manufacturers. But the idea is “who cares?” If you can get a better deal on a switch from vendor X this week, and vendor Y next week, that’s supposedly fine as long as they’re on the HCL.
  • Physical deployment and integration becomes trivial. Just rack the switch and PXE boot it to load your desired OS on it. I bristle a bit at the idea of PXE booting network hardware (there’s a chicken-and-egg problem in there somewhere), but that model has worked spectacularly in the wireless space to make deployment of large fleets of network devices extremely easy.

Despite the interesting facets of bare metal switches, there are some non-trivial challenges that Big Switch (and similar vendors) will need to address:

  • Hardware acceptance: convincing customers that bare metal or white box switches are just as good as the brand-name switches they’ve been buying for years.
  • Support: Approved hardware compatibility lists certainly help, but as I pointed out in some quotes in this article on TechTarget, I think network vendors need to be cautious about getting into finger-pointing matches that can arise when the hardware and software package isn’t produced, integrated, and tested by a single vendor. Solid compatibility testing programs may take time to mature.
  • Investment: Pure overlays offer an easy entry for the curious. You can build an overlay network using software products and bag the experiment just as easily. While more big-name switches are starting to include some sort of OpenFlow capability, if you don’t have the right switch model you may have to convince the person in charge of the purse strings that this idea is worth pursuing which may mean more upfront work to build a business case versus a “try and see” model that may be easier to test with overlay SDN.

Overall, the concept of controller-based fleets of bare metal switches will require a fairly drastic mind-shift, but if Big Switch can convince customers that their controller platform and the bare metal switch concept is sound, it could really shake up the networking market. This is the SDN that the big 3 (or 4 or 5) switch manufacturers are nervous about.

To learn more about Big Switch’s products and strategies, be sure to watch their presentations from NFD6:

Big Switch Networks was a sponsor of Networking Field Day 6. In addition to a presentation, Big Switch Networks provided me a branded golf shirt and a small notepad organizer. At no time did they ask for, nor where they promised any kind of consideration in the writing of this review. The opinions and analysis provided within are my own and any errors or omissions are mine and mine alone.
Tagged , , ,

6 thoughts on “Big Switch Networks and the (possible) Future of Networking Hardware

  1. […] Big Switch Networks and the (possible) Future of Networking Hardware | Herding Packets – Bob McCouch provides some thoughts on Big Switch presentation from that last Network Field Day event. I also came away with positive view and note the similarities between Big Switch and Cisco’s ACI technology. Not exactly the same of course but similar in the use of hardware. […]

  2. […] hopefully result in attractive pricing. With vendors such as Big Switch and Cumulous pushing the whitebox movement, which revolves around Broadcom Trident- (and Trident 2-) based switches, and other vendors like […]

  3. […] それは Big Switch の 会社の将来における次のフェーズの為の重要なステップであり、Software-Defined Networking (SDN) アプローチにおける対立を強調しより深くする。: オーバレイ 対 Big Switch が統合 P+V アプローチと呼ぶものだ。(Bob McCouch は彼の Herding Packets ブログで “フロープログラム能力“と呼んでいる。) […]

  4. “Based on some quick Google research of the models on the Hardware Compatibility List of Cumulous Networks, which is following a similar strategy to Big Switch” – You are giving BSN way too much credit. Cumulus was here long before and actually has been shipping product. BSN was an early player in openflow mainly. They did Indigo but it is not comparable.

    • bobmccouch says:

      Hi Todd, thanks for reading! I understand and agree that Cumulous was really the first-in here, I was simply mentioning from a standpoint of an HCL of whitebox switches so I could find some prices. BSN doesn’t have an easily accessible HCL published, whereas Cumulous does and I think it’s fair to assume both vendors are focusing on whitebox switches based on Broadcom Trident and Trident II silicon so what’s on the HCL for Cumulous is probably typical of what might be on the HCL for BSN.

      Appreciate your comments and your taking the time to read!

  5. […] McCouch had a very interesting recent blog, at […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


Virtualization, Storage, and other techy stuff

The Stupid Engineer

I ask those questions you're too clever to.

Sunay Tripathi's Blog

Pluribus Networks Founder's Blog on OS, Networking, Virtualization, Cloud Computing, Solaris Architecture, etc

Ed Koehler's Blog

Just another weblog

Data networking, stray thoughts, nerdy fun...

Network Heresy

Tales of the network reformation

The Borg Queen

Jottings on the intersection of tech and humanness

Networking From The Trenches

Ramblings about my thoughts, experiences, and ideas.

Networking 40,000

Attaining my CCIE with the help of Warhammer 40k

Network Shenanigans

Making Packets Do Silly Things

It must be the network...

Ramblings of JD (@subnetwork)

Not Another Network Blog

Musings from yet another IT nerd

rsts11 - Robert Novak on system administration

Resource sharing, time sharing, (20)11 and beyond. A retired sysadmin's blog.

%d bloggers like this: