The most important part of writing quality software is testing. Writing unit tests provide assurance the changes you’re making aren’t going to break anything in your software application. Sounds pretty great, right? Why is it that in networking operations we’re still mainly using ping, traceroute, and human verification for network validation and testing?
I’ve written in the past that deploying configurations faster, or more generally, configuration management, is just one small piece of what network automation is. A major component much less talked about is automated testing. Automated testing starts with data collection and quickly evolves to include verification. It’s quite a simple idea and one that we recommend as the best place to start with automation as it’s much more risk adverse to deploying configurations faster.
In our example, the network is the application, and unit tests need to be written to verify our application (as network operators) has valid configurations before each change is implemented, but also integrations tests are needed to ensure our application is operating as expected after each change.
If you choose to go down the DIY path for network automation, which could involve using an open source Continue reading
Arista is largely known for its operating system, best known as EOS. Arista has been known to deploy new features at a more rapid pace than other vendors and to have a more open OS–since EOS was the first production-grade network network operating system to expose any form of Linux to end users.
Because of this, I believe it’s perceived Arista has a better programmability strategy than other vendors. From what I can tell, it is not the case. However, given a few features Arista has in EOS, it makes programming EOS a bit easier than other platforms. Let’s take a look.
At Network Field Day 16, Arista reviewed their programmability strategy. There were 5 core components reviewed:
Before diving into each of these, I’ll first point out that when I look at “OS programmability,” what is important [to me] is device-level programmability (not controllers or streaming capabilities–those are important topics, but should be covered on their own). Programmability is the ability to program change on a device, isn’t it? Now let’s look at the 5 components in Arista’s strategy.
EAPI - it’s a great API for learning to program an EOS switch. This Continue reading
The latest in all the networking buzz these days is Intent-Based Networking (IBN). There are varying definitions of what IBN is and is not. Does IBN mean you need to deploy networking solely from business policy, does IBN mean you must be streaming telemetry from every network device in real-time, is it a combination of both? Is it automation?
This article isn’t meant to define IBN, rather, it’s meant to provide a broader, yet more practical perspective on automation and intent.
One could argue that intent-based systems have been around for years, especially when managing servers. Why not look at DevOps tools like CFEngine, Chef, and Puppet (being three of the first)? They focused on desired state–their goal was to get managed systems into a technical desired state.
If something is in its desired state, doesn’t that mean it’s in its intended state?
These tools did this eliminating the need to know the specific Linux server commands to configure the device–you simply defined your desired state with a declarative approach to systems management, e.g. ensure Bob is configured on the system without worrying about the command to add Bob. One major difference was those tools used Continue reading
I get asked often on how to perform specific network automation tasks with Ansible. There were a few questions recently pertaining to the
ios_config module within Ansible core, so I decided to record a video to show different options you have when using it to deploy global configuration commands on IOS devices.
Here is a summary of the four (4) options covered:
commands(or lines) parameter.
srcparameter and reference a configuration file with one or more commands in it.
srcparameter and reference a Jinja2 template such that it inserts variables into the template, creating a list of commands, and deploys them to a device.
templatemodule and reference a Jinja2 template to auto-generate a configuration file. In Task 2, use the
ios_configmodule and reference the config file built in Task 1 to deploy the commands from the file. This is often used instead of option #3 since it allows you to store/view the config file before deploying fully de-coupling the build and deploy processes.
The video does assume some existing knowledge on using Ansible. The Continue reading
Last year at Interop, there was a great mini-conference dedicated to the DevOps for Networking community. In that session, I kicked off the day with a general view of where the industry was with respect to the intersection of DevOps and networking with a focus on network automation.
One of the analogies I made was comparing network automation to self-driving cars posing the question, “Are they real?”…“Are they real for us (the consumer)?”
No, they are not, but I continued to make the analogy. Is complete network automation real today? While, the answer is yes, it’s not really a reality for most…yet.
So, what’s the connection between self-driving cars and network automation?
Start small and expand. Pick a problem, solve it, and integrate it.
While self-driving cars aren’t a reality for us to buy and purchase today, intelligent cars are– these are cars that have high-value services and features enhancing the way we drive, our safety, and much more generally, the way we in which we consume the streets and infrastructure around us.
These include automated features like self-parking, back-up cameras, automated beeping as you back-up, automatic-brakes, GPS, and computer systems that give Continue reading
I’ve had a general thought I’ve wanted to write about for quite some time now and after just seeing Matt Oswalt’s latest post Learn Programming or Perish(?), the thought finally makes it to paper so to speak in this post. The thought I want to expand on is something I say quite a bit as I talk about network automation. It is automate when you can, program when you must.
After reading Matt’s post, I’ll re-phrase to automate when you can, script when you must specifically targeting network engineers (note: even though this is what I mean, the word script makes it a bit clearer). This is a twist on the network industry’s old saying of switch when you can, route when you must.
Automate when you can is saying use some form of tooling when you can to do network automation. Why re-invent the wheel when you don’t have to? I’m a little biased these days, but this means using some form of extensible tooling, preferably open source, that does automation. Some of my favorites right now are Red Hat’s Ansible and Extreme’s StackStorm. However, this could just as well be other open Continue reading
Network Automation is just getting started and it’s odd to say that as IT professionals from other technology disciplines are always surprised to see how much manual interaction there still is between the networking engineering/operations teams and the actual devices they manage.
I’ll never forget the days in 2012-2013 performing my best Google searches to find ways to program or to automate network routers and switches. I didn’t care what programming language was being used or even what tool, but I found nothing. Every time I heard someone say they were using a network script, I’d say “email it to me, that sounds interesting.” Unfortunately, 100% of the time, it ended up being a notepad or a Word file, not a script. What a bummer.
I like to think I’m a solid Googler too. It was amazing though - there was near nothing. Do a search today on network automation or network programming and you’d be amazed on what you’ll find - we’ve come a long way in the past 36 months with respect to network automation, but I truly believe we’re still in the 2nd or 3rd inning (if we were playing a game of baseball, of course).
There is a lot of buzz around network APIs such as NETCONF and RESTCONF. Here we’ll take a quick a look at these APIs on Cisco IOS XE. On the surface, it seems Cisco IOS XE is the first network device platform that supports NETCONF and RESTCONF both driven from YANG models.
Technically, RESTCONF isn’t officially supported or even seen in the CLI to enable it, but more on that later.
When APIs are model driven, the model is the source of truth. If done right, all API documentation and configuration validation could occur using tooling built directly from the models. YANG is the leading data modeling language and as such, all API requests using RESTCONF/NETCONF are directly modeled from the YANG models IOS XE supports. For this post, we’ll just say the models can easily be represented as JSON k/v pairs or XML documents. We’ll cover YANG in more detail in a future post.
You can directly access the NETCONF server on IOS XE using the following SSH command (or equivalent from a SSH client).
The NETCONF server is a SSH sub-system.
$ ssh -p 830 [email protected] -s netconf
The full response from the IOS XE NETCONF Continue reading
I changed things up this week and wrote an article on LinkedIn about the launch of the Network to Code On Demand Labs platform.
It is a cloud based service that allows you to launch any number of network topologies in minutes for simulations, labs, demos, and testing.
Check it out if you want 22 hours free of on-demand network access to devices of your choice!
Last week I was in Dublin for business which just so happened to overlap with iNOG9, which was last Wednesday. As luck would have it, I had the opportunity to speak at iNOG9 about network automation.
You can watch the video if you want to see the presentation, but the three mini demos I gave were:
Few words about each.
Usually when the topic of network automation comes up, configuration management is assumed. It should not be as there are so many other forms and types of automation. Here I showed how we can verify cabling (via neighbors) is accurate on a Junos vMX topology. Of course, the hard part here is having the discipline to define the desired cabling topology first. Note: links for sample playbooks can be found below on the GitHub repo.
I built a custom Ansible module built around NETCONF (ncclient), but uses the OpenConfig YANG model for global BGP configuration. For example, this is the Continue reading
It’s been a long time since my last post, way longer than I’d like. For the last several months we’ve been neck deep in network automation. This post focuses on the highlights of not only what I’ve been up to, but also the rest of the Network to Code team. More detailed posts will come over the coming days and weeks.
As you can see from the website, we have a good number of public courses on network automation and even a few starting early next year that are completely virtual, but the majority of our training engagements have been private on-site instructor-led courses with Enterprises and Global Carriers. The private courses have varied from using the same course outline you see on the website, but have also been modified for a particular vendor, device type, and/or API. Popular topics covered in our training include Ansible, Python, NETCONF/RESTCONF/YANG, and various vendor APIs including Nexus NX-API, Arista eAPI, Juniper’s XML API, to Cisco’s new NETCONF/RESTCONF APIs on IOS XE.
Way too often do we want to learn a new technology, but end up spending countless hours just getting the product, tool, or technology downloaded, installed, and at a point to begin using. This is unacceptable.
We need a platform that offers on-demand network infrastructure labs that makes it extremely easy to test and learn how to use network device APIs, how to write code against a network device, and how to use DevOps tool chains in the context of networking.
It’s true, this has all become easier with tools such as Virtual Box and Vagrant, but you can still spend the same amount of time getting the underlying infrastructure setup as you spend on the actual tests you need to perform. In that model, you also need to be able have enough horsepower to run enough virtual machines as well, which often isn’t the case. On top of that, many Enterprises don’t allow tools such as these to be installed.
What I am proposing and getting ready to launch is a cloud based platform that allows you to launch pre-built network topologies in minutes. Upon launch, they are ready to be used, automated, and managed Continue reading
Big Switch offers on demand labs to get instant access to Big Cloud Fabric (BCF) and Big Monitoring Fabric (BMF). Using these labs, it’s quite easy to experience the products first hand and see what they are all about. The labs also come with lab guides that walk you through step-by-step on how to get started using BMF and BCF.
For me, one of the more appealing aspects of these labs is that Big Switch also exposes the APIs such that you can access them directly from your personal machine. This makes it possible to not only test the product, but also test the API on each controller platform (BMF and BCF).
The best part is, you don’t even need to use any docs because they offer a command that shows the API calls being made by certain show commands.
controller> debug rest ***** Enabled display rest mode ***** REST-SIMPLE: GET http://127.0.0.1:8080/api/v1/data/controller/core/controller/role controller>
Like the output from a
show version? Ensure
debug rest is enabled, and then just issue the command to grab the APIs being called to generate the text output on the CLI.
controller> show version REST-SIMPLE: GET http://127.0.0.1:8080/api/v1/data/controller/core/version/appliance REST-SIMPLE: http://127.0. Continue reading
From OpenFlow to Software Defined Networking (SDN), there has been a lot of hype, 100s of millions of dollars in venture funding, and billions in exits within the network industry over the past 5+ years. The one thing we know for certain about the industry in all of this is that change is here, and more is coming, which is exactly the reason for this post!
Ironically, I also started this blog 5+ years ago. In the beginning, this blog was a lot of speculation around OpenFlow and the future of Software Defined Networking (SDN). Nowadays, it’s rare to hear me mention SDN at all, and the focus is much more practical on tools and technology that can help solve real problems. For those that have been reading for a while, you probably saw this shift in addition to the career shift I made 18+ months ago. These shifts go hand in hand with a new project I’ve been working on.
It’s with great pleasure that I’m finally able to announce a project that started several months ago that falls in-line with exactly the same topics you read about frequently on this blog.
It’s a book! Continue reading
[Special thanks to Rob Shakir for taking the time to talk about OpenConfig and the related work he has going on. He definitely helped make the second half of this post happen- thank you, Rob. Note: all of the BGP code examples are borrowed from Rob and his original work can be found here.]
As more devices continue to add support for APIs, and the industry migrates from CLI to API, the question often arises, “is there ever going to be a common multi-vendor network device API?”
Let me answer that for you, “No!” Why? Think about it. What’s in it for the vendors?
If you keep reading, you may see that there is in fact a reason for vendors to develop a common API.
That said, this is the reason I initiated CPAL almost 2 years ago, which didn’t go anywhere for a number of reasons, and as an aside, we are re-visiting the idea beyond CPAL, and you should see something within a few weeks! And this is also the reason we have projects such as netmiko, ntc-ansible, NAPALM, and one that is the focus of this post, OpenConfig.
This Continue reading
It’s been a while since my last post, but let’s hope that changes with the flurry of posts planned for this month. Most of my recent time has been spent traveling and teaching courses that cover how to use Python and Ansible for Network Automation. I’ve written about many of these concepts in the past, but to re-iterate what I’ve been saying, and what I’ve written in the past, it’s crucial to start small when it comes to automation (otherwise it’s easy to feel overwhelmed trying to automate everything and then you never make any real progress). By starting small, you can get a quick win, and can gradually expand from there. In this post, I’m going to review one very small example of how to use Ansible for network automation. We’ll review how to use Ansible to dynamically configure interface descriptions populated with real-time LLDP neighbor information. While this post focuses on Cisco Nexus switches, note that the same approach can be used for any vendor.
The process that we’ll be using to auto-configure the interface descriptions is a three-step process:
1. Discover the device
While we are only using Cisco switches in this example, we still go through Continue reading
On Tuesday, I was boarding a flight heading to the west coast and realized I had 3 switches powered down in the colo that I needed for a presentation and demo on Wednesday. Not a good feeling.
We have an IP enabled PDU that I usually connect to with no issues from the office and home office since we also have an SD-WAN deployed using Viptela. The only issue — there is not a way to VPN into the colo (yes, that’s my fault).
As it turns out, I had exposed the Opengear console server, that we used for all out of band access, to the Internet a few months prior. On a flight that I was only planning to do offline work, I was forced to purchase Wifi…from there, the fix was pretty simple.
I SSH’d into the Opengear console server, got access to the Juniper SRX perimeter FW, and then added a temporary NAT configuration that exposed the PDU to the Internet. I was able to now access the PDU directly from 35K feet in the air, get the devices powered up, and have some peace that they could be used in the demo. Sure, I could have Continue reading
Virtual appliances not only provide for a great lab environment, but are the future of how network services will be tested, validated, and delivered within an Enterprise. And Juniper gets this – they spent a lot of time covering the vSRX and vMX product lines at the most recent Networking Field Day event.
Over the next few months, I’ll more than likely be spending a lot of time on Juniper gear, and it will be the virtual platforms, so it was good timing to get to be in the room to learn more about them along with many of the automation capabilities Juniper supports across their product families.
While I have not spent as much time on Juniper kit as I would have liked over the past few years, the one awesome thing to see and experience first-hand is that they have a unified API (NETCONF) across all of their products.
Why is this so valuable? Well, for one, we get to use the same libraries and integrations across platforms. As an example, we can use the Juniper Ansible modules across any of their devices. In this post, we’ll take a look at using one Continue reading
If you are frequent reader of this blog, it’s no surprise I’m focused on automation these days. It’s been primarily centered around using Python and Ansible with a little Puppet and Chef sprinkled in. I had the opportunity recently to change things up a bit using the Cisco ACI PowerTool and thought I’d share a few things about it.
First off, the ACI PowerTool is a PowerShell module that helps automate all aspects of a Cisco ACI fabric.
Second, it’s no a secret that the same rocket scientist created both the Cisco UCS and ACI object models. That said, the UCS PowerTool has been around for years and offers PowerShell modules that can be used to manage, operate, and automate Cisco UCS environments. As you may have guessed the Cisco ACI PowerTool is the same thing, but used to manage and automate Cisco ACI fabrics using PowerShell.
And as luck would have it, I’m still a Windows user, so I was able to get this up and running extremely fast. In full transparency, I haven’t spent much time with PowerShell at all before this, and it was super easy to get going, so no matter what your background, it’s worth Continue reading
Less than two weeks ago I wrote a post about an Ansible module called ntc_show_command. For those that didn’t read that post, you should, but ntc_show_command is a multi-vendor module that can automate converting raw text from show commands into structured data, namely JSON.
We’ve already had several pull requests enhancing the architecture, so the community support is off to a great start! But in order to really make an impact, we (me, you, and fellow network engineers) need to continue to contribute templates to the project repository. Templates are key to converting the raw text into JSON.
This post will walk through how to create a template for two different commands. We’ll take a look at show version for Cisco NX-OS and display version for HP Comware 7.
The first thing that we’ll need to do is get the raw text output that we want to JSONify. We’ll start with show version.
Below is the sample output that we’ll work with and this file will be saved as
tests/cisco_nxos/cisco_nxos_show_version.raw within our project directory.
Cisco Nexus Operating System (NX-OS) Software TAC support: http://www.cisco.com/tac Copyright (C) 2002-2014, Cisco and/or its affiliates. All rights reserved. The copyrights to certain Continue reading