A Hardware-Software Bridge

The switch abstraction interface is important to understand the idea behind free operating systems for switches. Basically, manufacturers of network hardware face the challenge of providing the software on their switches access to the network hardware built into the standard equipment. As with any network card, network chipsets are built into classical network hardware: A few manufacturers (e.g., Mellanox) make the silicone themselves, whereas most providers rely on ready-made chips (e.g., from Broadcom).

For an operating system to use the hardware, it typically has to talk to the firmware – which is the whole point: For standard operating systems such as Linux to address and use the network hardware of a switch, the manufacturer has to ensure that these operating systems can access the firmware of the installed chipset via a defined interface.

With classical network hardware, you face a monolithic block: The vendor software runs directly on the device, and it communicates directly with the hardware through the proprietary firmware of the respective chipset. The user has no influence on the nature and extent of the interfaces offered by the switch software. SAI, though, starts with the firmware of the switch chipset. If it has a standardized interface, any software can run on the switch itself (e.g., a normal Linux kernel) by accessing the chipset directly via the SAI layer.

Dell has done exactly this with OS10. An abstraction layer based on the SAI specification resides between the hardware and software the end user sees. The abstraction layer communicates downward with the hardware and exports standardized interfaces upward; in the case of Linux, for example, it generates netlink events for the kernel (Figure 1) when a new device is connected. A normal Linux version 3.16 kernel runs on this abstraction; moreover, it routes an interface for the switch firmware (i.e., the SAI) to the system.

Figure 1: The network processing unit (NPU) is part of the SAI interface and exports a normal network interface and netlink events to the Linux side [3].

On the basis of this setup, it is up to you to configure the switch: You can use the system resources of the current Linux instance in the usual way and deploy additional network services, or you can rely on Dell's Control Plane Services (CPS), an object-oriented framework that directly accesses the SAI layer (Figure 2) and comes close to a legacy vendor solution.

Figure 2: Overview [3] of OS10 architecture clearly shows that SAI is the focal point of the platform. It supports Linux and CPS.

Dell will offer different modules for CPS, including such functionalities as L2 networking and L3 routing (i.e., ready-made solutions). The important point is: If you do not want to use CPS, you can implement comparable functions from a standard Linux system. At the same time, this approach means that OS10 does not need to run exclusively on Dell switches. Any switch that implements the SAI standard should be capable of operating on OS10.

Dell makes it clear, however, in the OS10 Open Edition guide that the combination is currently only officially supported on some Dell switches. The fastest way to discover whether a Dell switch officially supports OS10, according to Dell, is to go to the product page for the respective device on the Dell website.

Debian Base

Dell offers OS10 in the form of several modules that mesh together. The Open Edition includes the kernel of the Linux operating system: This basic module runs on the switch (Figure 3) and provides a standard, working Linux. Dell advertises OS10 as an unmodified Debian "jessie," so you will have access to Linux 3.16 on your switches.

Figure 3: OS10 is fundamentally modular: The basic package is freely available; extensions or CPS modules will be available separately (illustration from the Dell website [1]).

The SSH login on the switch for the OS10 installation takes you to a normal Linux shell, which is already notable: If you want to delve the depths of the Cisco or Juniper CLIs, you have a steep learning curve ahead. A Linux-based switch with a normal shell can be managed by typical Linux admins because a complete and familiar environment is available.

Running ip a makes this clear: Thanks to the SAI abstraction, you see all the ports on the switch as configurable network interfaces on the OS10 switch. From here, you can walk the tree as required. Because it is a Debian system, you can, for example, call apt-get to install new software.

This opens up all the opportunities available on a normal Linux server. For example, in terms of monitoring: SNMP support can be set up with snmpd in the usual way; traffic statistics per port (e.g., using RRD) are also easily set up. The pure Linux on the switch does not seem to be very powerful until it comes to typical networking functionality: With the border gateway protocol (BGP), you can convert a Layer 3 router into a Layer 2 switch.

Layer 3 Routing for Cloud Setups

Layer 3 routing is popular with cloud providers. The idea is that, instead of simple switching in Layer 2, the switch acts as a router to deliver packages in Layer 3. For this to happen, BGP daemons, such as Quagga or Bird, run on both the switch and all connected hosts, and each host is connected via two NICs to two different switches and announces routes to its main IP on those links.

Because this solution does not offer high availability via bonding, it avoids the problems that come with bonding if specific offloading features (e.g., for VXLAN) are used. Additionally, the switches act as routers, and hosts on different networks can thus be linked easily to one another at the switch level.

This solution is very convenient in cases where, for example, clouds are distributed across multiple locations and rely on different local networks: Thanks to L3 routing, such constructs no longer need a centralized router (Figure 4). Moreover, this type of routing integrates in a significantly better way with a typical leaf-spine network architecture, such as those commonly used to achieve scalability in clouds. In the event of a router failure, the entire BGP setup then automatically reconfigures so that only working paths remain and defective ones are dropped.

Figure 4: A leaf-spine architecture can be achieved on OS10 [3] with on-board resources and, say, Quagga.

Although such a setup can also be created with the proprietary firmware of various manufacturers, you can usually look forward to non-trivial costs, and it is precisely these costs that quickly make the solution unattractive. OS10 solves this task much better: Quagga or Bird can be installed, each operating with their own configuration files; the routing part of the setup, then, is already implemented at the switch level.