Jason Edelman's Blog

Author Archives: Jason Edelman's Blog

Automated Testing & Intent Verification for Network Operations

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 Continue reading

Automated Testing & Intent Verification for Network Operations

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 Continue reading

Arista’s Programmability Strategy

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:

  1. EAPI
  2. OpenConfig
  3. NetDB Streaming
  4. Turbines
  5. EosSdk

Arista Programmability Strategy

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

Arista’s Programmability Strategy

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:

  1. EAPI
  2. OpenConfig
  3. NetDB Streaming
  4. Turbines
  5. EosSdk

Arista Programmability Strategy

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

Intent-Based Network Automation with Ansible

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.

Intent isn’t New

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

Intent-Based Network Automation with Ansible

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.

Intent isn’t New

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

Using the Ansible ios_config Module

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:

  1. Embed commands in your playbook and reference them using the commands (or lines) parameter.
  2. Use the src parameter and reference a configuration file with one or more commands in it.
  3. Use the src parameter and reference a Jinja2 template such that it inserts variables into the template, creating a list of commands, and deploys them to a device.
  4. Use two tasks. In Task 1, use the template module and reference a Jinja2 template to auto-generate a configuration file. In Task 2, use the ios_config module 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.

Using the ios_config module

The video does assume some existing knowledge on using Ansible. The Continue reading

Using the Ansible ios_config Module

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:

  1. Embed commands in your playbook and reference them using the commands (or lines) parameter.
  2. Use the src parameter and reference a configuration file with one or more commands in it.
  3. Use the src parameter and reference a Jinja2 template such that it inserts variables into the template, creating a list of commands, and deploys them to a device.
  4. Use two tasks. In Task 1, use the template module and reference a Jinja2 template to auto-generate a configuration file. In Task 2, use the ios_config module 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.

Using the ios_config module

The video does assume some existing knowledge on using Ansible. The Continue reading

Self Driving Cars and Network Automation

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)?”

Self-Driving Cars

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.

Self-Driving Cars are Coming

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.

Intelligent Cars

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

Self Driving Cars and Network Automation

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)?”

Self-Driving Cars

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.

Self-Driving Cars are Coming

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.

Intelligent Cars

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

Automate When You Can, Program When You Must

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

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

Automate When You Can, Program When You Must

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

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

Automating Cisco Nexus Switches with Ansible

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.

Note: We’ll see in later posts how we can use these models and a third model to accomplish intent-driven automation as well.

For this post, we’ve chosen to highlight Nexus as there are more Nexus Ansible modules than any other network operating system as of Ansible 2.2 making it extremely easy to highlight these two models.

CLI-Driven Automation

The first way to manage network devices with Ansible is to use the Ansible modules that are supported by a diverse number of operating systems including NX-OS, EOS, Junos, IOS, IOS-XR, and many more. These modules can be considered the lowest common denominator as they work the same way across operating systems requiring you to define the Continue reading

Network Automation Survey

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).

Continue reading

Network Automation Survey

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).

Continue reading

NETCONF, RESTCONF on IOS XE

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.

YANG

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.

NETCONF

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 ntc@csr1kv -s netconf

The full response from the IOS XE NETCONF Continue reading

NETCONF, RESTCONF on IOS XE

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.

YANG

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.

NETCONF

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 ntc@csr1kv -s netconf

The full response from the IOS XE NETCONF Continue reading

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

1 2 3