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?

The Network is the Application

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.

DIY Testing

If you choose to go down the DIY path for network automation, which could involve using an open source framework as a foundation, e.g. Salt, Ansible, Puppet, you may also go down the path of writing tests manually. The types of tests that you should be using for production network changes are limitless from verifying neighbors to the quantity routes to even more basic things such as MTU consistency and the enforcement of Enterprise standards for names and descriptions. Writing these tests to verify your intent is no easy feat. It’ll take time and dedicated resources for each part of your network.

Commercial Testing Platforms

On the other hand, if you prefer to have a hand to shake, or throat to choke, you may also want to consider platforms such as Forward Networks or Veriflow. I recently saw Veriflow at the latest Networking Field Day and Forward at ONUG. Veriflow has dozens of built-in consistency and intent-checks–they basically collect the output of operational show commands and offer a platform to define automated tests/checks against that data. If I must admit, Veriflow was one of my favorite presentations of the NFD event. It’s worth noting that everything they offer is also exposed via a RESTful API.

From API to Platform Integrations

These types of vendors that are focused on intent-based verification need to provide more than an API though. In conversations with both companies, the focus is using the UI and doesn’t fully reflect an API-first strategy. We haven’t quite crossed the chasm of network automation going main stream, but as they say, skate to where the puck is going, not where it is. What do I mean by this?

In the network automation space, the puck is heading to leveraging CI/CD pipelines for network operations. This means companies need integrations, not just APIs (same as I’ve said in the past about network vendors touting APIs). In this case, companies have the opportunity to be CI platforms for the network. This could be in the form of git integrations, e.g. just like Travis has a native plug-in to GitHub. Think about describing your tests in a YAML config file stored in a repo that triggers Veriflow tests when ever a pull request is opened. Think about doing a deployment with Ansible, but having Ansible trigger post-deployment verification tests (if you aren’t already writing your own tests with Ansible).

Closing

The truth is all of that is possible today, but wouldn’t it be nice if there were native integrations available so that everyone wasn’t re-inventing the wheel?

The network automation space and its surrounding ecosystem of tools is still in its infancy and I truly look forward to its future.

Thanks,

Jason (@jedelman8)

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.

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?

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.

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.

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.

For the past several years, the open source [network] community has been rallying around Ansible as a platform for network automation. Just over a year ago, Ansible recognized the importance of embracing the network community and since then, has made significant additions to offer network automation out of the box. In this post, we’ll look at two distinct models you can use when automating network devices with Ansible, specifically focusing on Cisco Nexus switches. I’ll refer to these models as CLI-Driven and Abstraction-Driven Automation.

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.

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.

I changed things up this week and wrote an article on LinkedIn about the launch of the Network to Code On Demand Labs platform.

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.

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.

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.

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.

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!

[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.]

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.

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.

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.

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.