Hey Folks! I realize this post is long overdue...lets just say things have been busy lately! Recently I started diving into the "Software Defined" world and wanted to share some of the foundational elements I learned. It should be noted that this journey started for me back in 2014 when I first started at Cisco working in the "Intelligent Automation for Cloud" Group. This post will be a very high level introduction because there are so many moving pieces. What I have found is that while say one tutorial does a great job of explaining XML, it assumes that the reader knows many (if not all) of the other pieces that goes along with it which just sucks when your trying to learn. So in this post I will attempt to explain it all in plain English so at the very least you have a direction and can get started at the level you need to.
For this post I will be keeping it as simple as possible and not pertaining to Wireless specifically, however future posts will include specifics on SDA/SDN/NSO and most importantly SD-Wireless.
The Ground Floor
The first thing you need to know about getting started with NSO/SDA/SDN (Network Services Orchestration, Software Defined Architecture/Networking) is hardware and/or virtualization. This section does not necessarily apply specifically to NSO/SDA/SDN, but it needs to be mentioned because it's often involved with automation and cloud so you need to be aware. You may have heard about the apps Docker and Kubernetes and/or you may be familiar with hypervisors such as VMware, KVM and HyperV. You may be wondering when to use one vs the other? Simply put, Docker is separate instance of say an application that can run independent of an Operating System. The word here is "isolation". If you were to run Windows 10 on traditional hardware and you wanted to use MS Office, you could only run one version of MS Office on that windows box...say MS Office 2016. However say for example that you had a REALLY old doc that only ran in MS Office 2000. Attempting to install MS Office 2000 would either corrupt or replace your Office 2016 and in most cases a user would first have to uninstall Office 2016 and then install Office 2000. In PC Gaming terms, older games that ran on older pre-Windows 7 OS may not be compatible with Windows 10.
Docker attempts to resolve these issues by isolating the application in a "container" which includes all of the necessary libraries and files in which to execute the application without altering or modifying the underlying OS. To use the previous example of MS Office, Docker would allow you to run multiple instances of MS Office at the same time, such as: MS Office 2000, 2003, 2007, 2012 and 2016. Why would you want to do this? Maybe your a software tester testing out some kind of extension for MS office but for the most part, vendors use Docker so that they can run applications isolated from other applications on the same host Operating System.
What about Kubernetes? Simply put, Kubernetes manages the docker containers. If you think of a cargo ship, one container contains cars while another contains Crayola Crayons.....one still requires a cargo manifest to know what container has what as well as the ability to open them, close them and move them. So what about Virtual Machines and why wouldn't i use Docker instead? Virtual Machines (VM) are a logical instance of an Operating System that runs on a physical host machine. Docker is a virtual operating system that runs applications inherited from a host Operating System. To put it even more simply, use Docker to isolate applications and use VM's to isolate Operating Systems.
So you may be asking yourself now, what the hell does this have to do with NSO/SDA/SDN? Without getting into the details of what the NIST actually defines as "Cloud Computing" the answer is that with modern day cloud computing and automation, cloud users need the ability to self-provision in the cloud. Unfortunately there are no johnny 5 robots that are going to unbox the physical server for you, add more RAM, re-cycle the packing materials, install applications and/or physically mount that server in a rack at some un-manned datacenter when you click the "create new instance" button in your cloud portal!
Foundational Components
In this section I will go over, at a high level, the parts and pieces that you will need to get started with NSO. It is important to note that there are many different ways to accomplish automation, however I'm simply providing you with a complete set of components to accomplish a network automation project. (Note I am still new at this too so i will be adding more and more to this blog as a move through my lessons)
XML - The Data
YANG - The Model
NETCONF - The Protocol
Python - The Engine
XML
XML is the markup language that contains the data fields that in the end gets applied to the target device and/or application. For example, if i wanted to order a soda from the vending machine in the breakroom without actually getting out of my chair i would need to send specific information to that vending machine. That information would include things like the container location of the soda...such as "A4" which contains a Dr Pepper...vs "A5" which contains a Mountain Dew. Not only would i need to know what forms of payment the vending machine accepts but I would need the ability to send that payment information such as a credit card number as well as obtain the price of the item from the vending machine so i know how much to pay. So my XML may look something like this:
<?xml version="1.0" encoding="UTF-8"?>
<Soda_Order>
<soda>
<name>Dr Pepper</name>
<price>$1.15</price>
<ContainerNum>A4</ContainerNum>
<CardType>VISA</CardType>
<CardNum>1234567891011121
</soda>
</Soda_Order>
YANG
Ok so we have all the information one requires to order a soda from a vending machine in the xml, however were talking about an inanimate object...a dumb refrigerator that doesn't understand this stuff...so we need a way to allow for interpretation. Also consider the fact that Windows doesn't speak soda machine and soda machine doesn't speak Windows! In other words, we need a model that defines the data fields coming from the xml. For example, a VISA credit card contains 16 numbers and typically requires the entry of the expiration date to complete a transaction. Unlike SNMP which cannot distinguish between "Configuration Data", say providing a credit card number, VS "State Data" which would be whether or not the vending machine's payment system is online and connected to the VISA financial network, YANG models can be configured for either and in most cases contains both strings and boolean leaf types. We can create our own Leaf Types as well, for example, we need to create a model that defines how a VISA credit card works VS say American Express. Our VISA custom data type might look something like this:
typedef visa-numbers { type string { pattern ''\d{16}'; } description "Matches a VISA credit card input containing \d (any digit) but no more/less than 16 digits; }
CONFIGURATION DATA - These are read/write configuration fields. For example, the code below
list sodacan { key "name"; leaf name { type string; mandatory "true"; description "Soda Can Name. Example value: Dr. Pepper"; } leaf CardNum { type visa-numbers; #notice this references our custom created data type# mandatory "true"; description "VISA credit card number. Example value: 1234567812345678";
}
leaf LocationNum
type string
mandatory "true"
description
"Provides the Row/Column location of the soda can. Example value: A4"
STATE DATA - These are read-only operational data fields. For example the code below could tell us the state of the soda machine's connection to the VISA financial network for payment processing.
list Connection-state {
config false;
key "conn";
leaf name {
type string;
description
"Interface connection to the VISA Financial network";
}
leaf oper-status {
type enumeration {
enum up;
enum down;
}
mandatory "true";
description
"Describes whether the interface that connects to VISA is physically up or down";
}
}
NETCONF
So we have the data fields (xml) and we have defined what those fields represent (YANG)...now we need a way of exchanging this information between two systems connected to each other over a network or on the internet. While NETCONF is technically a protocol, you can think of it as an interface. We all know about Graphical User Interface (GUI) and Command Line Interface (CLI)...but for two non-humans to communicate seamlessly, we needed a standardized protocol to be able to receive and manipulate our configuration data, our prior example being XML.
It should be mentioned at this point that our soda machine example is not a 100% finished solution (don't expect to copy/paste from this post and order a soda from your desk) It's important to keep in mind that our hypothetical soda machine must have the software that supports the automation components for this all to work...however if the soda machine software does infact support all of the mentioned components, ordering a soda from your desk would be very much possible (although you would still have to get off your ass and go get it!) However if there are any soda machine vendors reading this article, I would encourage you to add NETCONF API's to your software if only for the benefit of allowing us to work off those empty calories on our way to and from the breakroom! LOL
Going back to YANG for just a minute, the software developers who develop the software for our Soda Machine must include the RPC (remote procedure call) in the YANG model in order for us to connect and request information via NETCONF. For example since we cannot see the vending machine from our desk, we need to know what container our Dr Pepper is located in.
rpc get-soda-location-information { description "Provide us the row/column locations for the requested item"; input { uses command-forwarding; leaf item-name { description "Name of Soda"; type string; } leaf item-location { description "Soda Location"; type string; }
...
To establish a NETCONF session we could use an app such as postman, but we can also connect from linux CLI:
[user@centos-server ~]# ssh user@192.168.1.94 -p 830 -s netconf
Password:
<!-- No zombies were killed during the creation of this user interface -->
<!-- user root, class super-user -->
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:confirmed-commit:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:url:1.0?scheme=http,ftp,file</capability>
<capability>urn:ietf:params:xml:ns:netconf:base:1.0</capability>
<capability>urn:ietf:params:xml:ns:netconf:capability:candidate:1.0</capability>
<capability>urn:ietf:params:xml:ns:netconf:capability:confirmed-commit:1.0</capability>
<capability>urn:ietf:params:xml:ns:netconf:capability:validate:1.0</capability>
<capability>urn:ietf:params:xml:ns:netconf:capability:url:1.0?protocol=http,ftp,file</capability>
<capability>http://xml.machineINC.net/netconf/machineinc/1.0</capability>
<capability>http://machineINC.net/dmi/system/1.0</capability>
</capabilities>
<session-id>3275</session-id>
</hello>
]]>]]>Once connected we can call our RPC
<rpc>
<get-soda-location-information/>
</rpc>
]]>]]>The reply if successful would look something like this:
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:machineINC="http://xml.machineINC.net/soda2000/15.1X49/machineince">
<soda-loc-information xmlns="http://xml.machineINC.net/soda2000/15.1X49/soda-loc" machineinc:style="normal">
<soda-table-entry>
<item-name>Dr.Pepper</item-name>
<item-location>A1</item-location>
<price>$1.15</price>
</soda-loc-entry>
<soda-loc-entry>
<item-name>Pepsi</item-name>
<item-location>A2</item-location>
<price>$1.15</price>
</soda-loc-entry>
<soda-loc-entry>
<item-name>Monster Energy</item-name>
<item-location>A3</item-location>
<price>$3.25</price>
</soda-loc-entry>
</soda-loc-information>
</rpc-reply>Python
Finally we need some kind of engine that provides input/output logic and process the components. Python has become the standard for network automation due to its flexibility and laid back syntax. A common use for Python is to use it to parse input and provide useable output. For example, gathering the sales data from our soda machine and providing us a report of the most popular brand of soda from which could assist us with our stocking decisions.