Open networking is based on open standards, interoperability, and open source software such as Linux. One of the things that has made Linux so ubiquitous is the unparalleled control it offers to users in terms of customization and building intelligence into the network. Much of this advantage comes in the form of the automation and orchestration possible with Linux-based networking.

First adopted by hobbyists, widespread use of Linux in production environments only started to take off in the mid-1990s in the supercomputing field, where organizations such as NASA started to replace their overly expensive hardware with clusters of inexpensive commodity computers running Linux. Today, Linux systems are used throughout computing.

Linux can be found in servers, clouds, and network equipment. Linux is ubiquitous in the embedded systems space, and is the operating system upon which virtually all modern supercomputers are built. Even Microsoft (which once derided Linux as “a cancer”) now champions Linux, building its own Linux distributions for its Azure cloud networking and making it possible to run Linux on top of Windows.

Linux offers organizations numerous ways to automate devices and workloads. This includes task scheduling, scripting, automation, and policy management. Because Linux is used widely in so many different types of systems, automation knowledge and experience can be reused, simplifying orchestration across silos within the data center.

Let’s take a quick look at the types of automation available in Linux, from basic to dynamic, and how these automation capabilities help to enable data center-wide orchestration.

Task scheduling

Task scheduling is among the most basic forms of automation available to any operating system. Typically used for scheduling CPU- or I/O-intensive tasks for predictable lulls in demand, task scheduling can be part of data center-wide orchestration when it’s used to roll changes out to multiple devices or workloads. While this is rare, this sort of distributed task scheduling does occur when a series of changes need to be made which are likely to cause a disruption in connectivity between devices or workloads.

One of the task scheduling options built into Linux is the cron daemon, which runs tasks in the background at specific times. This is similar to the Task Scheduler in Windows. Scripts, application executions, and other scheduled tasks can be configured using a crontab, which is essentially a calendar that holds the information about the scheduled tasks.

Another option is anacron, which is a simplified cron that complements the existing cron system. It’s made to handle jobs that run daily or less frequently and jobs for which the precise time doesn’t matter. Anacron’s chief advantage over cron is that it runs jobs that were scheduled to go when the computer was off.

Additional task scheduling options exist. GNUbatch, for example, allows administrators to set specific conditions for every job or make a scheduled task depend on the previous one. With Linux, no matter when you want a task to occur, for whatever reason, or according to which requirements, there’s a tool to ensure those tasks can be appropriately triggered.


Scripting is a catchall phrase that can encompass a number of activities. Traditionally, scripting in Linux is writing a series of commands for the Linux shell to execute; however, there are a number of programming language interpreters available.

Interpreters allow scripts to be written in the development languages familiar to an administrator, without them having to learn Linux shell scripting. Common programming languages used in IT automation, and thus open networking scripting, are Python and Perl.

Scripting is useful because it can combine lengthy and repetitive sequences of commands into a single text file, which can be easily edited, stored, and executed at any time. Scripting is regularly used as the basis for IT automation efforts.

Scripts give administrators the ability to perform complex or interdependent tasks in response to a stimulus, and can be triggered by traditional task scheduling, environmental triggers, and more. Scripting on an individual device or workload is considered automation of that device, while scripting across multiple systems—especially where multiple changes are being made to multiple systems in response to a single event—is orchestration.

Automation beyond the network

Network administrators perform any number of mundane tasks on a regular basis, such as assigning VLANs to a port, configuring SPAN ports, or adapting network topology to adjust to the addition of new networking equipment. Automation can make those very specific tasks easier and less error-prone, but automation really starts to take off when it’s used across silos.

Consider for a moment some simple automation tied to Network Access Control (NAC) policies using standard enterprise policy enforcement technologies. NAC extends the familiar notion of granular access control beyond the familiar access control lists (ACLs), and provides feedback to administrators about the endpoint computer’s configuration and network environment.

The capability for enhanced examination of the endpoint (or target) machine is generally implemented through a proprietary software agent. This agent harvests the data required to determine whether the endpoint is in compliance with local security requirements. The agent transmits the configuration information to a stand-alone policy server, which evaluates the data and establishes the appropriate level of network access.

Combining automation with policy enforcement is where automation and orchestration truly begin to blur. Consider, for example, some simple automation efforts to isolate a workstation from a network if it’s infected.

Two simple tests could be used to determine if an endpoint is infected: The antivirus program on the endpoint could report an infection, or a script could determine that the antivirus application isn’t running. Relative to checking mandated patch levels or registry settings for network services, checking to see that a given process is running is pretty simple, and killing the local antivirus application is usually the first thing that malware will do.

If an infected machine is taken offline or assigned to a restricted network until it has been cleaned, once isolated it’s no longer able to infect its neighbors or overload the network with undesirable traffic. Tying together simple automation in multiple silos automates administrative response to an infected endpoint, reducing risk. This is one of the simplest examples of automation and orchestration that cross-functional IT teams can engage in.

The importance of open networking

Open networking requires open standards, interoperability, and open source software. Beyond simply allowing organizations to choose between different hardware vendors, open networking provides a basic platform for networking devices, software, and services from multiple vendors to interact.

Open networking is the hub of a modern network. It coordinates policy enforcement and enables automation beyond the boundaries of the open networking devices involved. A triggering event received by an open networking switch can not only drive changes on that switch, but can drive changes on other switches from the same vendor. Thanks to scripting and open networking standards, that triggering event can be used to push changes in network configuration, topology, and policy to products from other vendors.

Today’s networks are complex, and automation is a requirement to operate them. Open networking based on Linux provides a solid foundation upon which to build the automation of your organization’s future. There’s a reason Linux powers so much of the world’s IT, including our own Cumulus Linux. It’s time it powered your network, as well.