DATA CENTERS

  • 06/22/2015
    8:00 AM
  • Rating: 
    0 votes
    +
    Vote up!
    -
    Vote down!

Network Automation: More Than Scripting

Automating rote network tasks isn't all script-driven. Network automation also can mean intelligent control and policy-based networking.

Many companies today tout network automation capabilities in their hardware and software. Network automation means tasks are performed automatically. At the simplest level, it automates what used to be typed manually into command line interfaces (CLIs).  

Some people equate network automation with scripting, but it’s a lot more.  It can start with script-level automation, progress to intelligent network control, and at the highest level, translate network administrators' intent via policy.

Here are some different types of network automation:

Script-driven automation: Administrators (often DevOps staff) write scripts that automate changing the network devices’ configuration settings. RESTful APIs, Yang, Netconf, even traditional CLI-scraping or SNMP may be used.  The scripts may be written in Python, Puppet, Chef, or other languages. The intelligence resides in the scripts.  Many network operating systems support APIs, such as Arista EOS (eAPI), Cisco NX-OS (Python API), Cumulus Linux and Juniper Junos (PyEz micro framework).

Automatic configuration and provisioning: Automation capabilities such as provisioning are embedded into the network systems’ architecture. Many are considered standard features today, but often started their lives as automation features.

A basic example is DHCP since you don’t allocate static IP addresses for client devices. It's so fundamental that we don’t think of it as automation, but has become so useful we can’t think of deploying client devices without it. A more modern example for infrastructure networking systems is Brocade’s Zero Touch Provisioning for switch image and configuration downloads since it makes configuring switches a lot easier.

Automatic operation and management: Automation assists with day-to-day operations, such as reacting to events and reconfiguring device settings. There are too many items in this category to list here, but whatever takes manual tasks out of the “examine and react” loop qualifies.  An example: Software-defined or hybrid-WAN systems that automatically steer traffic between MPLS WANs and Internet links if one goes down. (Examples of this growing area are Cisco iWAN, CloudGenix, Talari, Viptela, VeloCloud, to name a few).   

Network security systems such as intrusion detection and prevention systems also can fall into this category, since they act as automated network sensors with appropriate corrective actions, such as blocking connections.

High-level orchestration: Integrating an SDN controller with other parts of the infrastructure enables orchestration of virtual machines, networks and storage in a coordinated manner. SDN has many definitions, but at the core level, separation of the data plane from the control plane enables the provisioning and configuration of these elements. Depending on the system capabilities, this may lead to app-driven networks. This means is that it’s possible to load apps that implement networking features into the network controller and those capabilities are rolled out to the network.

Before SDN, IT groups needed to deploy new firmware, or perhaps even new hardware to deploy new features.  With SDN, decision-making behavior can be delegated to an app. For example, HP has an SDN App store to program OpenFlow-based networking devices. OpenDaylight, an open source SDN system, accommodates apps that plug into the system, which makes it extensible.

Policy-based networking: This is also called declarative-intent SDN, which means you describe what you want performed in the network, and the system has the smarts to figure out how to implement it. This is an advanced form of automation since it enables those who are not in the networking team, such as application owners, to define how they want the network to behave. Examples include Cisco’s Application Centric Networking (ACI) and Nuage Networks VSP. In the open source community, some examples are Group-Based Policy (GBP) and Network Intent Composition.

In my next blog, I will write about the benefits network automation offers IT organizations.


Comments

network automation

Thanks for defining the different types of automation Dan. While there are forms that organizations are using today, it seems there are others that require more of a breakdown of traditional enterprise silos. Are you seeing that starting to happen?

Re: network automation

When you see turnkey solutions such as Cisco ACI, as opposed to a "DYI" DevOps methods, you close the gap between application owners and the infrastructure owners by moving the responsibility to those who understand the apps.  In the DevOps case, the networking team and the DevOps team work together. (sometimes, the networking team becomes more adept at scripting)

But in some cases, the end-to-end turnkey solutions sucha s policy driven atuomation, are so transparent, the networking team does not need to get involved in approving and reviewing all elements, so in some sense, the breakdown of silos is not necessary, thanks to some technical innovations.  

Re: Network Automation: More Than Scripting

I really like the approach you have going here, Dan; like your previous pair of articles, we're talking about a a complex mix of hardware and software - context, definitions, and examples for enterprise users wading into network automation for the first time are important. So are broader use cases, enterprise-wide needs, and the impact on processes. I think trying to cram both into one blog is an oft-made mistake that leaves out a lot of nuance and just ends up reiterating what people already know. As for what's here, when I look at a propiertary API or OS that runs on one vendor's hardware vs. an open-source one that runs on any OpenStack or OpenDaylight environment, it does make a strong case for the value of open-source in this ecosystem.

Seeing the wide variety of APIs and languages you've listed reinforces for me how network automation can have different uses for IT organizations of all types and sizes, not just large enterprises. I know a network admin who swears by Puppet. Though he works at a large lab supporting many power users (computer scientists, engineers), he's actually part of a very small dedicated IT team. Anything that can save them time is a godsend. While standards are coming into view, we're talking about a huge variety of use cases (like you said, security could be counted as network automation), and while it's transformative to our infrastructure, it's also becoming something we use every day and take for granted. To be honest, I'd call that a good sign.

Re: Network Automation: More Than Scripting

Thanks for your comments.  I'm not against Puppet (or Chef, or Ansible) when I say it's more than scripting. It's all good, but I want people to realize that it is one approach, and if you want to something turnkey, there are other methods too.  

There are no clear standards yet for automating all things networking, but some things like YANG or NetConf is a good step.  

Re: Network Automation: More Than Scripting

Great read. We also use automation for daily audit against our network Standards, to ensure each single device is configured and operating the way it designed.

We feel that the industry is lacking such thorough auditing tool (not just using Regex match-or-no-match checks like Solarwinds or Tripwire, but way more sophisticated) and we urge that all Data Centers to audit their devices as freqently as they can.

We name this "Network Standard & Quality Control" which may be a new term in the industry.

www.ironwoodnetworks.com