I was watching the Networking Field Day Exclusive videos with all the presentations about the new Aruba 8400 platform and its cool features like Integrated Network Analytics and programmability.
Product managers define it as a carrier-class switch/router and it well deserves this label. Hardware is designed with great performance and redundancy we come to expect from a core switch that is able to manage a big campus network.
A great point that is sometimes not considered enough is the fact that the power modules are replaceable from the front. This topic emerges many times during customer meetings. When switches are installed in small rack, access to the back means unplugging all the modules/cabling causing downtime.
In some cases it is possible to install the switch on a server rail and access the back for maintenance by sliding out the switch. This solution requires some attention to manage the cabling length. Enough spare cable slack is necessary to allow the switch to move outwards without unplugging any cables. Slides are usable for small size and light switches. However, the 8400 is a 8 rack unit beast so it hardly is a candidate for rail mount. The ability to replace the modules from the front provides much better maintenance.
Fans and fabrics mean time between failure (MTBF) is usually longer than Power supply unit (PSU) MTBF so it makes sense to put them on the back. The switch would occupy too many rack units putting everything on the front.
A very welcome design choice is decoupling of power cables from PSU. Too many networking horror stories are related to power cables zip tied together and the poor network administrator who gets blamed when pulling one power cable results in two simultaneous power disconnections. The silence that follows is quite alarming.
REST API and Spreadsheet
Frank Reischstein did a great presentation of REST API on 8400 platform available on ArubaOS-CX that has full support for automation and programmability.
The presentation shows how it is possible to integrate Google Sheet functions with REST API to retrieve information from the switch and actually do configuration changes.
Quite often this approach is used just for demos and is considered a simplistic way not meant to be actually implemented in production.
Let's think about it for a moment. In every network engineer/administrator dreams there's a Network Management System that solves all the problems, monitors the whole network and can perform all the possible configuration task with just a few mouse click.
But while we wait for this dream to become true we need a Minimum Viable Product (MVP) to fix real and immediate problems that maybe someday will be solved by Intent Based Networking and Telemetry.
Most engineers agree the CLI is not the right tool anymore and feel the need for something better. Becoming a full-fledged networking developer takes time and may not be the career path for everybody. Is it possible to define some intermediate goals in the path? Of course it is. A good strategy is to grasp the low hanging fruit while looking up for more ambitious results.
Let's go back to the spreadsheet with a real-world scenario a.k.a. war stories.
Use the spreadsheet, get the results
A customer wants to upgrade all the APs from 802.11n t 802.11ac. The problem is the former is a Power Class 3 devices (15W) and the latter is a Class 4 (30W). The question is: is there enough power budget on the switches for this transition?
The old-school way to do that would be to connect to each switch, type some show commands to check the power budget usage and do some calculations to ensure the new devices would fit the available power.
This process has many drawbacks: it's slow, manual, error prone and needs to be repeated if the network changes.
It's easy to imagine how it can be automated with a spreadsheet and a few functions that read the power budget directly from the API. The automation would remove all the drawbacks of the manual process and allows to reevaluate on-demand the status of the whole network.
This is a different way to approach the network that platforms like Aruba 8400 allow, a great new tool for Network Engineers for efficiency and effectiveness.
Wrap-up
Configuration changes are only part of a network administrator's job. Sometimes it is necessary to retrieve other information from the network to evaluate what-if scenarios and make data-driven decisions.
CLI does not allow to get fast and updated data. The provided tools sometimes don't have the right report ready on the GUI. API in these cases are there to help. The integration in a spreadsheet allows administrators to obtain all the necessary information without writing thousands of lines of code. Inside a spreadsheet it's straightforward to manipulate the data or to create graphs to visualize the results.
The intermediate goal of the process is to learn to read device's API documentation, a skill that is necessary for the next step: writing actual code to consume API.