Arguably a few of the bigger reasons for this move include disaggregation of hardware and software, easier virtualization of network functions and more consistent adoption of network automation solutions. However, there are some interesting benefits that have appeared as a side-effect of moving to Linux-based operating systems, namely:
- The ability to use Linux-based tools to monitor network equipment
- The ability to host containers and virtual machines in a shared space with the network OS
Enter the Cisco Catalyst 9000 Family Switches
Cisco released the Catalyst 9000 series of switches back in 2017 in an effort to consolidate their huge array of traditional enterprise or campus switches while maintaining the same functionality that customers have come to expect.
These switches are built on an x86 CPU architecture and run consistent versions of Cisco’s open IOS-XE operating system using Linux under the covers (CentOS 7, specifically). What this architecture allows for is surplus RAM, CPU, storage and network connectivity to be used within Linux containers (LXC) or even run virtual machines on a KVM hypervisor.
That’s all well and good, but so what?
If existing applications are designed to be hosted on a central server in a data center, then what good is hosting apps on a switch? Surely most organizations won’t host production monolithic applications on switches, but there are several use cases for running specific application types on a switch.
Use Case #1 – Configuration Auditing and Tracking
This use case may be most interesting to organizations who maintain tight change control processes, as well as managed service providers. By hosting a Python script within the Guestshell space on a Catalyst 9000 series switch that compares the current running configuration to the previous version that shows only the changes in configuration, administrators can then integrate this script to output the result into a shared team chatroom, such as in a Cisco WebEx Teams (formerly Spark) room. By seeing exactly what changed and when, troubleshooting can be greatly sped up. (See the code on GitHub here.)
Use Case #2 – Use of Linux Networking Troubleshooting Tools
While using Linux tools isn’t considered application hosting, it is clearly an advantage of open network operating systems. The two most common Linux tools that provide value for a network administrator are MTR and tcpdump.
- MTR: MTR (My Traceroute) is a Linux tool that combines functionality of traditional ping and traceroute into a single tool. It operates similarly to TraceRoute in that it will show every layer 3 hop between the source and destination but also continuously pings every hop in the middle to validate if there’s a specific hop that is leading to excess packet loss. Additionally, when troubleshooting latency issues, the administrator can easily spot the hop at which latency increases.
- tcpdump: Most network administrators are aware of the difficulty in analyzing packet captures at any given point in the network. Commonly, administrators will both physically plug a laptop into a switch and SPAN a local port on the switch or else ERSPAN ports are created on the fly to send packet capture (generally .pcap) files to a remote destination for analysis. In either case, an external computer is used to trigger the generation of a packet capture file and bandwidth and CPU is wasted on the switch given the traffic mirroring.
Catalyst 9000s have a couple different ways of generating packet captures: Wireshark or tcpdump. While Wireshark is built in to Cisco Catalyst 9000 series switches with Advantage licensing, many administrators may prefer tcpdump for its flexibility in filtering directly in the shell command prompt. In other words, tcpdump allows for administrators to visualize a .pcap file within the shell rather than sending the .pcap file to an external analysis tool.
Use Case #3 – Network Performance Monitoring
Administrators can now host performance monitoring applications directly on a network node.
One common tool that can be deployed directly on a Catalyst 9000 switch is perfSONAR, which acts as an endpoint to measure network statistics such as packet loss, latency, and jitter between not only between any path on the private network, but also extend it to the greater public perfSONAR community to monitor network statistics to external geographies. (A full list of public perfSONAR locations can be found here.)
Beyond network performance monitoring, administrators can also run traffic generation tools directly on the switches to assist with connectivity troubleshooting. You can use tools like iPerf to generate whatever traffic flows you would like and do it from any point in your network. For example, this can be useful to identify firewalls blocking specific TCP or UDP ports within a specific path or for throughput testing prior to an application deployment.
Use Case #4 – Fog Computing for Time-Sensitive Applications
Arguably, this use case is still in its infancy at the time of this blog, and how it develops is up to the software developers of the world. As applications are redesigned to be aware of distributed computing, there is a lot of promise in hosting applications at the network edge. Control and management of the application may be centralized, but data processing and computing can be performed on any device in the network.
The Internet of Things (IoT) movement is one of the first industries to adopt this strategy. Smart lights shouldn’t need to send data across the country to a data center to inform a controller that they should turn on because somebody walked into a conference room; they should just turn on as quickly as possible. Likewise, in the manufacturing world a sensor shouldn’t need to wait for a remote server to tell it to turn off when a heat threshold has been exceeded.
These are just a few use cases for hosting applications as well as generically performing tasks within the underlying Linux environment within Cisco Catalyst 9000 switches. The impact of these features will only continue to become more important as the application world becomes more abstracted from underlying hardware.