Preview: Networking Field Day Exclusive with Aruba (HPE) – The 8400 core switch



Back to Silicon Valley!

As a network type, it’s hard not to be excited when heading to a Networking Field Day event. I joined then NFD club by attending NFD14 and have been hooked ever since.

Not only is it an honor and a privilege to be invited to an NFD event, the personal relationships that are forged in the larger TFD community are some of the most valuable I’ve ever had in my career.

This go around we’ll be visiting Aruba (A Hewlett Packard Enterprise Company) in Santa Clara to deep dive on the newest addition to the Aruba product line – the 8400 core switch.

A new face in campus town – the Aruba 8400

It’s been a while since anything exciting happened in the world of campus networking. It’s a steady segment for most vendors but nothing disruptive has really happened in the last few years.

And that’s not incredibly surprising. For better or worse, as long as campus networks aren’t broken in most enterprises, they are often neglected in favor of the data center and cloudy pursuits.

Aruba is touting the 8400 to increase automation and visibility in the campus core – both are areas that network engineering teams have traditionally struggled to implement.

Couple that with a brand new API enabled NOS that has built-in analytics and Aruba may have a serious claim on the ‘game changing’ campaign it has been running since announcing the 8400 in June 2017.

The 8400 quick specs:
  • 8 slot chassis (for linecards)
  • Provides up to 19.2 Tbps switching capacity (8.571 billion packets per second)
  • Supports a maximum of 256 10GbE (SFP/SFP+) ports, or 64 40GbE (QSFP+) ports, or 48 ports 40/100GbE (QSFP28) combination
  • Full 8400 data sheet is here

First impressions:

What I like

Speeds/Port Density – The speed/port density specs for the 8400 read more like a data center switch than a campus core which means even the largest campus networks will have plenty of available ports with up to 100 gig if needed.

Security – Encryption at wire speed is becoming more and more of an issue as new security and compliance requirements force network teams to treat private links that were previously trusted as untrusted. The availability of MACSEC on linecards is big plus.

Automation – In reading the product literature, one of the differentiating factors listed is the ability to automate manual tasks like the provisioning of network switches to support wireless access points. This is a task that can be fairly daunting in a network with a large number of switches and no automation. I’ll be interested to see how the ‘zero touch’ provisioning for APs that Aruba describes actually works.

Visibility/Troubleshooting – Enhanced visibility and troubleshooting tools are a welcome feature for any engineering team. Aruba has developed a Network Analytics Engine that is listed as being at the heart of this set of capabilities. Onboard network analysis modules have been tried before by other vendors with varying degrees of success and so it will be interesting to see what Aruba’s take is on built in analytics.

Virtual Switching Framework – As a designer of networks, i’m a big fan of leveraging link aggregation in my designs for path redundancy coupled with switches than can support multi-chassis LACP.  The 8400 supports Aruba’s Virtual Switching Framework which allows both chassis to work together in similar fashion to a switch stack which allows for a single LACP channel to contain links in two different chassis. While this isn’t a groundbreaking feature, it’s critical to competing in the campus core market.

Complete REST API – Aruba describes the REST based API in this blog post as having access to “every network function and state, both persistent and ephemeral, within the switch.” This opens up a world of possibilities for integration and automation into enterprise applications as well as automation/orchestration engines.

Initial questions I have for Aruba:

Code maturity – The Aruba OS-CX network operating system seems to be the heart and soul of the new switch. As with any new NOS, one of my first questions is around interop and bug testing. What interop testing has been done and what are the results from current field deployments?

Software licensing and support – Software/feature licensing and support can be a source of frustration fro enterprise clients. Understanding the software and support model that Aruba uses will be one of the initial questions that I have.

Depth of the L3 feature set – As much as we try to avoid complexity in the core, sometimes advanced features in OSPF and BGP are needed such as dynamic routing within a VRF or a complex set of REGEX values to build a route map for a BGP peer. One of my goals in attending this NFD is to better understand the capabilities of Aruba’s routing stack in OS-CX.

To disaggregate or not

Often the opinions we have on new technology are shaped by our daily work. As someone who is frequently engaged in whitebox integration, disaggregation has become more and more prevalant in my daily work.

I suspect the decision by Aruba to use a chassis to offer port density rather than a disaggregated leaf/spine architecture stems from the lack of demand by enterprises to use leaf/spine in the campus.

Chassis is what everyone is comfortable with and expects to implement when designing the campus core. As such, nobody in the world of disaggregated networking has taken aim at the campus from a software standpoint.

That said, it will be interesting to see if a small leaf/spine core is considered for future hardware iterations of the OS-CX family aimed at campus deployments.

More to come!

As I write this, I’m enroute to #NFDx and am looking forward to the presentation by Aruba so that we can deep dive and really understand what makes the 8400 tick and the problems Aruba is trying to solve.

Please tag me @stubarea51 on twitter with the #NFDx hashtag if you have questions you’d like to ask Aruba about the 8400.

Stay tuned!

Read More

Whitebox networking – coming soon to an edge near you?

What is whitebox networking and why is it important?


A brief history of the origins of whitebox

One of the many interesting conversations to come out of my recent trip to Network Field Day 14 (NFD14) hosted by Gestalt IT was a discussion on the future of whitebox. As someone who co-founded a firm that consults on whitebox and open networking, it was a topic that really captivated me and generated a flurry of ideas on the subject. This will be the first in a series of posts about my experiences and thoughts on NFD14.

Whitebox is a critical movement in the network industry that is reshaping the landscape of what equipment and software we use to build networks. At the dawn of the age of IT in the late 80s and early 90’s, we used computing hardware and software that was proprietary – a great example would be an IBM mainframe.

Then we evolved into the world of x86 and along came a number of operating systems that we could choose from to customize the delivery of applications and services. Hardware became a commodity and software became independent of the hardware manufacturer.

ONIE – The beginning of independent network OS

A few years ago, an initiative called the Open Network Install Envrionment or ONIE for short was started by Cumulus Networks and shortly thereafter received support from NFD14 presenter, Big Switch Networks, among others. It was the first open project that developed a common multi-vendor framework for separating a network operating system from the hardware – just like we did with x86 and computing in the late 80s and early 90s.

The importance of whitebox in 2017 and beyond

Whitebox is critically important to the future of networking because it is forcing all incumbent network hardware/software vendors to compete in an entirely different way. The idea that a tightly integrated network operating system on proprietary hardware is essential to maintaining uptime and availability is rapidly fading.

Tech giants like Google, Facebook and Linkedin have proven that commodity and open network hardware/software can scale and support the most mission critical environments. This has given early adopters of whitebox networking the confidence to deploy it in the enterprise data center.

Whitebox is only a data center technology…right?

White box has been so disruptive in the data center, why wouldn’t we want it everywhere?

As we visited the presenters of NFD14 who had been developing whitebox software and hardware (Big Switch Networks and Barefoot Networks), one idea in particular stood out in my mind – White box has been so disruptive in the data center, why wouldn’t we want it everywhere?

The use case for whitebox in the data center has grown so much in the last few years, that it’s now a major part of the conversation when selecting a vendor for new data centers that I’m involved with designing. This is a huge leap forward as most companies would have struggled with considering whitebox technology as recently as two or three years ago.

A clear advantage to come out of the hard work that whitebox vendors have done in marketing and selling data centers on the proposition of commodity hardware and independent operating systems is that it’s paved the way for whitebox to make it to the branch and edge of the network.

Vendor position on whitebox as an edge technology

The idea that whitebox can be used outside of the data center seems to be prevalent among the vendors we met with during NFD14. This is a question I specifically posed to both Barefoot and Big Switch and the answer was the same – both companies have developed technology that is reshaping the network engineering landscape and they would like to see it go beyond the boundaries of the data center.

I would expect in the next 12 to 18 months, we are going to see the possibility of use cases targeted to the edge and maybe even campus distribution/core. A small leaf spine architecture would be well suited to run most enterprise campuses and the CAPEX/OPEX benefits would be enormous. Couple that with smaller edge switches and you’ve got a really strong argument to make for ditching the incumbent network vendor as well as breaking out of vendor lock in.

And it makes a lot of sense for whitebox companies to expand into this market, there are already edge platforms in the world of commodity switching that support 48 ports of POE copper with 4 x 10 Gpbs uplinks. Aside from the obvious cost savings, imagine taking some of the orchestration/automation systems that are being used right now for the data center and applying them to problems like edge port provisioning or Network Access Control. Also, being able to support large wireless rollouts and controllers in a more automated fashion would be a huge win.

Role in Network Function Virtualization and the virtual enterprise branch

Network Function Virtualization (NFV) has gotten a lot of press lately as more and more organizations are virtualizing routers, firewalls, wan optimizers and now SDWAN appliances.

One of the endgames that I see coming out of the whitebox revolution is the marrying of NFV and whitebox edge switching to create a virtual branch in a box. The value to an enterprise is enormous here as the underlying hardware can be used in a longer design cycle while the software running on top can be refreshed to solve new business requirements as needed.

The other major benefit of hardware abstraction is that it simplifies orchestration and automation when interfaces are VLAN based and not tied to a specific port/number.

What are the challenges to getting whitebox into the hands of the average enterprise for edge or campus use?

While not an exhaustive list, these are a few of the challenges to getting whitebox into the average enterprise.

  • Perception is one of the key challenges to moving towards whitebox in the edge. Most enterprises tend to be hesitant to be early adopters unless there is a clear business advantage to doing so.
  • Vendor lock in is another major barrier as most enterprises tend to stay within one vendor for routing and switching.
  • Confidence is a key part of the hardware selection process and this is an area that I feel whitebox is gathering serious momentum. And that will help make the edge case an easier sell when it becomes a more common use case.
  • Training and Support is always one of the first questions asked by a network team to see how easy it will be to support and get the techies up to speed on care and feeding of the new deployment. This is another area of whitebox that has seen a huge amount of growth in the last few years. Big Switch has a fantastic lab for learning data center deployments and hopefully as the use cases expand, we’ll see the same high quality training for those areas as well.

Closing thoughts

Whitebox at the edge is closer than ever before and there are small pockets of actual deployments which are mostly in the service provider world.

However, we’ll likely have to wait until the use cases are specifically developed and marketed towards the enterprise before there is significant momentum in adoption. As a designer of whitebox solutions, it’s something that i’ll continue to push for and evaluate as it has the potential to make an enormous impact in enterprise networking.

That said, the future of whitebox is incredibly bright and 2017 should bring a significant amount of growth and more movement towards commodity switching as a mainstream technology in all areas of networking.

Read More