This article is part 3 of a series on the Aruba 8400 chassis switch, launched in August 2017. See the links section at the bottom of this article for the other articles in the series.
Aruba Networks touts the ArubaOS-CX operating system as the heart of their campus core and aggregation products. In other words, ArubaOS-CX is not unique to the 8400, but is found in other Aruba products as well. A new network OS might be discouraging to those who have a history with HPE networking, as the OS lineup has been anything but consistent over the last several years.
Much like Cisco, HPE has been positioning different network operating systems for different environments. As HPE networking soldiers on under the Aruba brand, we’re seeing this multi-OS strategy continue. If you are an Aruba consumer wishing for one NOS to rule them all, I’m afraid that today is not your day. That said, ArubaOS-CX has much to commend it.
ArubaOS-CX Key Features
Aruba bragged about several ArubaOS-CX key features. I highlight them here in the context that these are what Aruba felt were most key to raise during the product launch.
Programmability. This is accomplished via a well-documented REST API. The API documentation is rendered using Swagger as part of the web GUI. Oh and yes, you caught that–there’s a web UI in addition to the API to manage the 8400. The web UI is modular. Users can drag and drop components to make their very own single pane of glass.
Besides the API and GUI, there is a CLI that’s meant to be intuitive, simple, tidy, and consistent. Interestingly, the CLI is not a REST API consumer, but rather is directly attached to the in-memory database. More on this database architecture below.
Security. I covered some of core aspects of what security means to the 8400 platform in the previous article in this series.
Extensibility. There is some flexibility in the OS to run what you want to run, which I believe is what Aruba is getting at with this adjective. The OS is also database-driven, using an in-memory database architecture that is effectively a forked version of OVSDB. In addition, Aruba rolled their own embedded Linux using the Yocto Project.
The database feature is core to how Aruba maintains state in the operating system. Processes read their state from the database, and write their changes to the database. As I understand it, nothing happens in ArubaOS-CX without the database’s involvement. The database is the single source of truth.
This architecture lends itself to extensibility, in that processes with functionality to add have a single structure to attach to–the database. That’s more straightforward than trying to glom onto several processes to provide a new OS feature.
Resilience. To Aruba, resilience in ArubaOS-CX means that every component of the OS must be able to stand on its own. This goes back to the database architecture, the single source of truth where all state lives. OS daemons do not build matrix dependencies to every other daemon. Rather, each daemon expresses its desired state into the database. If a daemon crashes, the daemon restarts and reads its state back from the database.
This reliance on the database and the database alone for OS state limits failure domains. One daemon crashing does not take down other daemons, as there is no dependency web among daemons. Traffic forwarding is not impacted, because forwarding tables are populated via the state in the database.
Does that mean there will never be an outage on a box running ArubaOS-CX? Of course not, but the key is to think of the impact of a given failure, and what the ultimate outage actually looks like. For example, an outage that might be experienced could be OSPF gracefully restarting, a subsecond task. However, the restarted OSPF process will have missed any changes in the OSPF LSA database until synchronization with neighbors has completed. That resynchronization process will likely take more than a second.
In that scenario, was there an outage? In a stable topology, probably not. It’s unlikely that the OSPF database would have changed enough to impact the FIB, i.e. change the routing table and therefore the forwarding table of the 8400. But in a complex topology with a lot of churn, it’s possible that for the second or so it would take for the restarted OSPF process to get the latest database and re-run Dijkstra’s algorithm, that some packets would be blackholed or stuck in a microloop.
That sounds pretty good compared to a complete NOS crash, race condition, or memory leak that impacts the OS globally. Limited failure domains are a network engineer’s friend.
Innovation. Innovation is a word that should be stricken from the marketing vocabulary of technology companies everywhere, as it’s so overused to be devoid of meaning. I cast innovation on the compost heap already steaming with cloud, SDN, and machine learning.
Are there some interesting features in ArubaOS-CX, especially for those folks who are used to monolithic network operating system approaches? Absolutely. Are they “innovative”? I couldn’t identify any features that aren’t also available in some other operating systems, at least in some form. In fact, some of what’s in ArubaOS-CX is re-purposed code from the open source community. Much of the other code hails from ProVision. And there’s nothing wrong with any of that. I’m just not sure I’d call it innovative.
The Importance Of Linux To ArubaOS-CX
The Linux kernel is crucial to ArubaOS-CX, as the Linux kernel is in the middle of programming everything on the box. For example, if a packet needs to traverse the software slow path because the fast path hasn’t been programmed yet, that traffic is going through the Linux kernel.
The centrality of the Linux kernel also means that the Linux kernel’s networking capability as developed by the open source community is keenly interesting to Aruba. Aruba reports that there are features coming up in the Linux kernel that they want to take advantage of eventually.
Although Aruba didn’t mention that I could find in my notes, I wonder if the eXpress Data Path (XDP) project is part of the equation in ArubaOS-CX. XDP seems to be an up-and-comer as some in the Linux kernel community have railed against the DPDK approach for fast packet processing in Linux.
As an ArubaOS-CX operator, the Linux kernel is interesting to you, as it means you can do all sorts of powerful (and potentially silly) things. For example, you can get into the Linux shell and run tcpdump directly on the device. The 8400 interfaces are accessible to you just like network interfaces are accessible on any Linux platform. The rope Aruba is giving you is both handy and long enough to hang yourself with, as it should be.
Managing ArubaOS-CX Configuration State
In some network operating systems, configuration is handled with a simple write or commit process. Rollback might or might not be available, all depending on the OS. ArubaOS-CX is big on configuration management, offering what I feel is a mature way to handle configs.
ArubaOS-CX uses automated configuration checkpoints. Assuming the configuration has changed, the operating system will create a checkpoint as often as every five minutes. The OS will store a maximum of 32 checkpoints. Each saved checkpoint is stored as a diff. That is to say, each checkpoint stores what’s different between the current and previous configuration, similar to an incremental backup.
Aruba describes the configuration process as declarative. Declarative in this context means that you declare a specific state you wish the configuration to be in, possibly as a JSON blob containing structured data variables and values. The operating system will compare the current configuration state to the desired state by performing a diff operation. The diff between what is right now and the desired state results in specific actions the operating system will take to update the configuration.
If, after all of that, the final configuration you’ve declared isn’t quite what you wanted, you can rollback the 8400’s configuration.
Coming Up Next
In the final article in this short series, I’ll cover the integrated network analytics and automated root cause analysis features of the Aruba 8400.
- Aruba Picks A Fight In The Campus Core With Its New 8400 Switch
- The Aruba 8400 Chassis Switch. Yes, But Why?
- The Aruba 8400 Hardware Highlights
- The Aruba 8400 ArubaOS-CX Network Operating System
- The Aruba 8400 Integrated Network Analytics & Automated Root Cause Analysis
This article underwent a technical review by Aruba Networks to ensure accuracy, which I appreciate. I sat for an entire day during the launch event hosted by Tech Field Day listening to several hours of presentation on this complex platform. I like to be sure I got it right.