I will start with the very fundamentals of what / why Network Automation is around today, and then go further into some concepts regarding it.
Network Automation – What goals does it achieve?
- Reducing node by node updates with bulk updates to the network
- Eliminate repetitive tasks entirely
- Standardize the network and documentation (consistent images and backups)
- Utilize automation tools to perform mass upgrades or updates to network
- Reduce time spent troubleshooting (via scripts or good network deployment)
What can be Automated on the network?
- Provisioning new devices throughout the network
- Automated / Dynamic Security Policies via Network Overlay
- Automated and Dynamic QoS policies for devices
- Automate scheduled software deployments w/check they succeed
- Automated discovery of Network / Dynamically created Network Diagram
- ARTIFICIAL INTELLIGENCE(!) and Machine Learning can be utilized to Automate and reduce troubleshooting problems on the network!
That’s right, we are bringing AI to the table to get our Networks humming now adays! 🙂
Something to keep in mind about things that CAN be Automated on the Network
They probably CAN somehow be Automated via Python or YAML to Dynamically enforce AAA type security or QoS, however a lot of these are meant as features of “zero touch provision” solutions of SD-WAN like Meraki, Viptela, VeloCloud (VMWare).
Just wanted to throw that disclaimer in there that we may not cover how to dynamically apply QoS across your network (that I am aware of) yet, but wanted to list those as some things we have newly acquired SD-WAN vendors doing already, polling one internet line to see if its having issues move QoS sensitive traffic over to a secondary line.
Network Automation “Origination Points” in the network
This means where the Automation comes from in the network, of which there are really three different places that it can originate from, meaning executing the Automation into the network and not actually creating the Automation of the network itself.
These three different Origination Points being:
- SDN Controllers
- Network Servers running Automation Software
- TCL Scripting / IOS Scripting
SDN Controller (Software Defined Networking)
This is generally referred to as an Orchestrator or Controller, which can come in the form of a Physical Device that you plug into your own network to perform this SDN fucntionality, but typically I see it in the secondary option – The Cloud.
Cloud based controllers never become unreachable, are actually very convenient to reach from just about any PC with Internet Access, and can run the software from the vendors Servers / Cloud rather than hosting it yourself.
Network Servers running Automation Software
There are different types of Automation software that runs directly on a Network Server that can perform Automation, which should be familiar from the ENAUTO Blueprint:
- Ansible (Tower)
- Chef
- Puppet
- Others like Salt Stack
These software solutions were not actually intended initially for network automation but for server automation, and are not new and exciting solutions, but repurposed software applications to Automate the network rather than Servers (as VMware has kind of cornered that market in the last couple decades) 🙂
TCL Scripting and other IOS Scripting
I don’t even really like putting this on here as an option as if you are going to go for Network Automation, it is not going to be kicking off a TCL Script on an IOS Device via SSH on your network, but I had to list it because it is theoretically an option.
For example I’ve seen Nexus switches “run bash” that brings up a Bash Shell to run a Bash Script on it, then type “python” and it even further lets you drop into a Python prompt – However if your going to go to this trouble of Automation unless its a TINY network I would look at a larger scope solution.
Common Network Management Tools and Communication Methods for them
Here I wanted to review some of the current tools we use to manage the network, what protocols we use (and how we use them) to communicate to the Management Tools.
A couple Network Managements Tools in todays networks might be:
- SNMP Managers
- Netflow Collector
Some common languages and protocols used to communicate:
- SSH or SSL (of course without you being on the CLI because… Automation)
- SNMP (Can be use to carry Automation traffic to devices)
- NETCONF/YANG – NETCONF = Network Configuration Protocol (Uses SSH)
- RESTCONF/YANG – No idea the Protocol name, uses HTTPS or TLS
- OpenFlow – Industry Standard Language
- Cisco OpFlex
- REST APIs
When NETCONF initiates a session to a remote device, it is also establishing what format of communication the devices will be using, NETCONF specifically uses XML and RESTCONF can use either XML or JSON to communicate (JSON is actually preferred).
YANG acronym stands for “Yet Another Next Generation” <— Literally. This is a data modeling language used for NETCONF and RESTCONF along with other languages. It determines how to send certain parts of a script in different types of output such as ‘Strings, Integers, Binary, etc’ when sending traffic to devices.
So for example if “sh int fa1/0” were sent, YANG might send “sh int fa” as a ‘String’ in the communication, while it would represent “0/1” as an integer as sending a number in string format would not make sense to the devices.
OpenFlow is an Industry Standard “Controller” that takes the Control Plane off of the Routing / Switching devices themselves, the OpenFlow Controller itself determines all best paths and forwarding decisions that its devices should make, then forwards that table down to its devices so they only have to worry about forwarding Data.
Cisco OpFlex takes a step back from this approach as Cisco Routers and Switches are already heavily outfitted for Dynamic learning of routes and MAC addresses, so instead they allow the Cisco devices to do their usual dynamic learning operations while an OpFlex Controller might push down certain additional policies such as ACL’s or Protocols for the device to use in addition to what its already learned itself.
REST APIs are typically used when an External Application needs to talk with a Controller, for example you could write some kind of additional script / Automation on another server and use REST API to communicate to the network via the Controller.
This would be for example if you have a main SDN Controller with Automation built in and has complete network access, and you have a secondary controller from a different vendor that doesn’t have quite that capability but a script you would like it to execute, you could create that script or task on the secondary controller and use a REST API to have to main Controller of the network execute that task.
That will do it for this intro!
I will dive a bit deeper into some Automation concepts in my next post, but for now wanted to touch on the topics, then full steam ahead!
The DEVNET GRIND! 