Jason Edelman's Blog

Author Archives: Jason Edelman's Blog

OpenConfig, RESTCONF, and Automated Cable Verification at iNOG9

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:

  1. Cable verification on Juniper vMX devices using Ansible
  2. Automating BGP on IOS-XR using OpenConfig BGP models using Ansible
  3. Using Postman to explore and demo the new RESTCONF/YANG interface on IOS XE.

Few words about each.

Cable verification

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.

OpenConfig BGP Automation with Ansible

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

Network to Code and General Update

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.

Training

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.

Software Development

We’ve contributed to various open source projects, but key highlights include contributions to Ansible modules that are now part of core as well as adding Palo Alto Networks (PAN) Continue reading

Network to Code and General Update

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.

Training

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.

Software Development

We’ve contributed to various open source projects, but key highlights include contributions to Ansible modules that are now part of core as well as adding Palo Alto Networks (PAN) Continue reading

On Demand Network Labs [FREE]

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.

On Demand Network Labs

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

On Demand Network Labs [FREE]

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.

On Demand Network Labs

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 Meets Ansible

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

Big Switch Meets Ansible

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

The Network Automation Book

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.

What is the Project?

It’s a book! Continue reading

The Network Automation Book

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.

What is the Project?

It’s a book! Continue reading

OpenConfig, Data Models, and APIs

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

Introduction

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

Network Automation with Ansible – Dynamically Configuring Interface Descriptions

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

Opengear Saves the Day from 35K Feet

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

Juniper vSRX Automation with Ansible

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.

NETCONF Rules All for Juniper

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

Cisco ACI PowerTool

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

Creating Templates for TextFSM and ntc_show_command

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

From CLI to API at Networking Field Day

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.

Please realize this is not an extensive list, but only what is relevant to the specific products covered in the sessions at Networking Field Day. In order of their presentations…

Cisco

The APIC-EM, used as part of the IWAN solution, has a full REST API. No SDK or libraries were mentioned, but it doesn’t seem like it’s officially shipping yet anyway — more details can be found here on the APIC-EM.

Big Switch

Both of Big Switch’s controller platforms have complete REST APIs. You can find some code examples here: https://github.com/bigswitch/sample-scripts/tree/master/bcf/webinar

Riverbed

Riverbed also talked quite a bit about their APIs across the SteelHead product suite. You can find plenty of Python libraries on their GitHub page. You can get started here: https://github.com/riverbed/steelscript

Gigamon

Gigamon also released REST APIs so that users can Continue reading

Big Switch Improves Day to Day Network Operations

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.

Command & API History

The first feature is simple – it shows command history, but also API history across the entire Big Cloud Fabric (BCF). The feature is accessed through the central UI of the BCF controller and you can simply look at the last N commands or APIs that were executed on the system. The great thing is that you don’t need a separate AAA system to capture the commands being made and should you want to see the API calls being generated from the CLI commands (because remember the CLI is just an API client), you can also view them. If the CLI isn’t being used, you can also still see each API call that has been recently made on the fabric. It’s my understanding that there is a certain amount of storage dedicated to this function so when the space does fill up, the history Continue reading

Getting Structured Data Back from CLI Devices

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.

The overall feedback about the Ansible module (aka netget) shown in that post was great — it was ultimately taking input parameters such as the template file along with the CLI command to execute on the devices in order to return structured JSON data back using Ansible. In other words, the module used Ansible and TextFSM to create a pseudo-API for accessing data in traditional (no API support) devices.

Since then, we have been using TextFSM for a few customer projects and found out there was another capability within TextFSM to create what’s called an “index” or a mapping between CLI commands, vendors, and TextFSM templates. By integrating this functionality, instead of users needing to know what template to call, they can simply just send in the show command, while the index maps the command to the proper template! Pretty sweet!

Needless to say, the Ansible module is officially online and is now called ntc_show_command.

With the right amount of community support, it shouldn’t be Continue reading

DevOps Meets the Internet of Things

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.

Background

I was set to arrive at Cisco Live on Saturday to attend a DevOps forum on Sunday, but after booking travel and continuing to browse the Cisco Live website, I found out they were having an Internet of Things hackathon that would be starting on Saturday, go through the night, and finish on Sunday. It seemed intriguing because around the same time a highly valued peer of mine had just been telling me about a Cisco device that is still in beta, codename doublemint (more on this later), that is helping consume and deploy IoT-enabled devices. Now I needed to dig in and try to attend the hackathon. Being that I was set to arrive after the hackathon was to start, I emailed the DevNet team Continue reading

Week in Review

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.

NYC Ansible Meetup - Tuesday June 2

Clearly the presentation was about network automation with Ansible. That probably goes without saying since it was an Ansible meetup! I’ve used these slides in other presentations throughout the year, so some are repetitive, but they usually hit some key points on the topic of network automation. Unfortunately, I did not know this was being streamed lived when it took place, but luckily the organizers recorded it too. Link is below.

Note: the presentation doesn’t start until about the 30:30 mark. From there on out, it’s about half presentation and then half live demo of using Ansible for Network Automation.

Here is the link to the video: Network Automation with Ansible

High School Talk - Wednesday June 3

A local high school about 20 mins from where I grew up asked me to come in to talk about a career in IT. The school is the Pascack Valley Regional Continue reading