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.

The industry is in a shift from the CLI to the API, from manual to automated, and from closed to open. While some vendors just say they have an API, some provide libraries and tooling to make it easier to consume their APIs. This post specifically highlights open source code that is publicly available on GitHub by vendors that participated in Networking Field Day 10.

Big Switch recently launched major updates to their products Big Cloud Fabric (BCF) and Big Monitoring Fabric (BMF), formerly Big Tap. This post isn’t going to cover the updates or the products from an architectural standpoint, but rather two specific features that are meant to help general day to day network operations.

About 6 months ago, I wrote a post titled Programmatic Access to CLI Devices with TextFSM that talked about what was possible with TextFSM and even some things that could be possible with Ansible.

When I initially heard about the Internet of Things (IoT) sometime in the past few years, my initial reaction was okay here we go, we have another buzz word that means absolutely nothing. Add in Internet of Everything (IoE), it seemed even worse. After spending some time participating in an IoT Hackathon this past weekend in the DevNet Zone at Cisco Live, I can honestly say that my opinion has changed. Here’s why.

This week was a busy one. I had the opportunity to speak at a local NYC Ansible meetup, to a group of high school computer science students, and then on a panel at AnsibleFest yesterday in New York. Here is a short recap.

By now, you’ve probably heard of Cisco’s Software Defined Networking (SDN) solution that is centered around ACI, or the Application Centric Infrastructure. Like most SDN platforms, a key component is the controller otherwise known as the Application Policy Infrastructure Controller (APIC) in the case of ACI. The APIC provides a single pane of glass that centralizes policy, configuration, and monitoring of the complete fabric. It also more importantly exposes the complete system via an object oriented REST API, which is what we’ll look at in this post.

Going to Cisco LIVE? Interested in chatting about network automation or about how DevOps principles can be used on the network? Well, if you are, feel free to reach out - I would love to have a conversation out in San Diego! I just booked a trip to Cisco LIVE, but am only purchasing the $49 DevNet Explorer pass. This means I should have plenty of time to socialize and will likely be spending most of my time at the DevNet zone. I’ll have access to my remote lab and should be able to demo much of what I’ve posted about in the past few months too.

I’ll continue to update this throughout the next two days. Feel free to issue a pull request if you’re also here at the conference and want to add to this post.

NETCONF is an industry standard (IETF) network management protocol. It’s actually been around for quite awhile and supported by numerous vendors. While NETCONF is not always compatible across network switch platforms, it’s the closest thing I can see that could be a unified multi-vendor API. Of course, there are also vendor extensions for those device-specific features too.

Software Defined Wide Area Networking (SD-WAN) is bubbling up to be one of the prime use cases of SDN. The vendors that fall into the SD-WAN bucket often include Glue Networks, Nuage, Viptela, CloudGenix, VeloCloud, etc. As you dive into each of the solutions from the vendors, you may realize that some are truly unique technologically and some may just be offering a better way to manage existing wide area networking equipment (which is still a huge value add).

If you are a frequent reader of my blog, you know that last year I left my job to do something that I was intrinsically motivated to do. Unfortunately, because of this, I haven’t been able to write as much as I normally would. I do hope that changes. But, time is money now – literally. My time has been spent driving business, negotiating, writing Scopes of Work, building a website, managing finances, and producing quality work for customers, and I hope all of that continues.

One of the harder things to do when it comes to network automation is work with the majority of the install base that exists out there. This is true even if we focus purely on data extraction, i.e. issuing show commands and getting the results in an automated fashion. The reason for this is that most devices do not support returning structured data in formats such as JSON or XML, and this often times makes automation a non-starter for network engineers.

Over the past several months, I’ve found myself holding back on writing posts simply because my blog platform does not support the ability to embed code or even change fonts to resemble code, CLI, or working on a terminal. Screen shots are good, but offering the ability to copy and paste is nice, plus it just looks cleaner. This is unacceptable.

Over the past few years, I’ve written quite a bit about SDN and more recently more about what can be done today with existing products, APIs, and tools in terms of improving operational efficiencies. Most of the examples have leveraged modern network devices that have some type of API because it streamlines how to integrate with 3rd party systems be it a custom application or a platform like Ansible (a platform that I’ve written about frequently). I’ve posted examples here and there on GitHub on these topics, but nothing that starts from the ground up.

If you have ever worked with Ansible, it’s almost a guarantee that you have used their online docs to figure out what parameters a given module supports, how they should be used, or what their defaults are. Over the past few weeks, I’ve been working on a few custom modules and was trying to find a way to generate web docs for them, and have them locally accessible or easily posted to GitHub.

The way in which networks are configured, deployed, and managed is changing. The network industry is in a shift from managing devices box by box via the CLI to having more centralized ways to manage and deploy devices. While the CLI isn’t going away anytime soon, we can look at the two operational models that are gaining traction within the network community.

We’ve heard a lot of Software Defined Networking (SDN), Open Networking, APIs, and policy models over the past few months (and years). There are days where it’s sickening to hear the term SDN, but even on those darkest days, the reality is that the network industry has a bright and open future. In this post, I’m going to share a list of networking projects that I’m aware of that are not only open, but also open source. It is definitely eye opening and extremely positive to see so much open source activity in the network industry.

In previous posts, I’ve written about using Ansible for network automation. Few of them can be found here, here, here, and here. In one of the posts, I had a video that was automating Cisco routers with Ansible, and was using onePK as the API to communicate to the device. In this post, I’ll be focusing on automating Nexus switches – this means each of the Ansible modules will be using NX-API to communicate with the device. This also eliminates the need for the users of these modules to know Python as they’ll be using the Ansible platform for their specific automation needs. While the demo below is for configuration automation and shows what can be done in just a few seconds, it needs to be understood that automation is much more than pushing configurations. I hope to show some of this first hand by doing more interesting things as it pertains to data gathering, verification, troubleshooting, that do increase speed and agility, but also predictability.

I’ve posted a few times in the past about Cisco’s NX-API and realized I hadn’t provided any guidance on how to get started using the API itself. In this post, I share two videos that are meant to serve as a quick start to those who don’t have a development background and are looking to test NX-API.