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?

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.