This page is a summary of previous blogs that involve some type of network automation from integrating with open source DevOps tools to custom development and working with vendor APIs.
DEMO: Using Ansible for Network Automation
5/18/2014
There is so much discussion on if network engineers need to be programmers that I was almost getting pissed off last week. It was an odd and funny feeling. Anyway, I've written in the past here and here about the use of Ansible for networking. In this post and video, the goal is to show why network engineers don’t need to be "hardcore programmers."
Read More
There is so much discussion on if network engineers need to be programmers that I was almost getting pissed off last week. It was an odd and funny feeling. Anyway, I've written in the past here and here about the use of Ansible for networking. In this post and video, the goal is to show why network engineers don’t need to be "hardcore programmers."
Read More
Network Test Automation with Ansible
3/29/2014
In the last post, I talked about how Ansible could be used for various forms of network automation. In thecomments, Michael asked if Ansible could also be used for network test automation and verification. Since I’m just starting to explore Ansible, I figured why not try it out. The short answer is, it’s possible. Let’s take a look at an example proving this out.
Read More
In the last post, I talked about how Ansible could be used for various forms of network automation. In thecomments, Michael asked if Ansible could also be used for network test automation and verification. Since I’m just starting to explore Ansible, I figured why not try it out. The short answer is, it’s possible. Let’s take a look at an example proving this out.
Read More
Ansible for Networking
3/24/2014
[This article is the outcome of some great conversations and exchanges I’ve had recently with Jeremy Schulman (@nwkautomaniac) around automation and Devops in the world of networking. Thank you to Jeremy for those late tweaks before getting this posted! Thanks to Kirk Byers (@kirkbyers) as well - he was also gracious enough to respond to clarify a few things and assisted with this post indirectly.]
There have been numerous articles written that describe the what and the why of Devops. Reading through a few of these, you find references to CAMS --- you’ll read how “Devops is about CAMS.” CAMS stands for Culture, Automation, Measurement, and Sharing. Imagine working in an environment where automation is embraced? We know most networks are not leveraging nearly any type of automation. While we usually talk about engineers (of all types) not embracing automation, is the harsh reality most organizations are from having the right culture to embrace automation?
Read More
[This article is the outcome of some great conversations and exchanges I’ve had recently with Jeremy Schulman (@nwkautomaniac) around automation and Devops in the world of networking. Thank you to Jeremy for those late tweaks before getting this posted! Thanks to Kirk Byers (@kirkbyers) as well - he was also gracious enough to respond to clarify a few things and assisted with this post indirectly.]
There have been numerous articles written that describe the what and the why of Devops. Reading through a few of these, you find references to CAMS --- you’ll read how “Devops is about CAMS.” CAMS stands for Culture, Automation, Measurement, and Sharing. Imagine working in an environment where automation is embraced? We know most networks are not leveraging nearly any type of automation. While we usually talk about engineers (of all types) not embracing automation, is the harsh reality most organizations are from having the right culture to embrace automation?
Read More
Demo: Common Programmable Abstraction Layer
3/10/2014
Over the past few weeks, I’ve written about the idea behind a common programmable abstraction layer. Previous articles are here and here. It’s worth stating that something like a CPAL can be used with or without SDN controllers and with or without cloud management platforms. As can be seen from the previous write ups and the video/demo below, today its primary focus is data extraction and data visibility. It can use device APIs or controller APIs. It’s about accessing the data you need quicker. It’s that simple. No more jumping from device to device and having to manage text and excel files.
If there is a controller in the environment, you can still view data around particular physical and virtual switches in the environments by creating the right modules. Same can be said if there was a CMP/CMS deployed. While a CPAL can easily make changes to the network, it’s about taking small steps that can have a larger impact on how we use new APIs on network devices and controllers. And if we don’t strive for a common framework now, we will end up with many more APIs than there are CLIs. What good is that?
Read More
Over the past few weeks, I’ve written about the idea behind a common programmable abstraction layer. Previous articles are here and here. It’s worth stating that something like a CPAL can be used with or without SDN controllers and with or without cloud management platforms. As can be seen from the previous write ups and the video/demo below, today its primary focus is data extraction and data visibility. It can use device APIs or controller APIs. It’s about accessing the data you need quicker. It’s that simple. No more jumping from device to device and having to manage text and excel files.
If there is a controller in the environment, you can still view data around particular physical and virtual switches in the environments by creating the right modules. Same can be said if there was a CMP/CMS deployed. While a CPAL can easily make changes to the network, it’s about taking small steps that can have a larger impact on how we use new APIs on network devices and controllers. And if we don’t strive for a common framework now, we will end up with many more APIs than there are CLIs. What good is that?
Read More
The Power of a Programmable Abstraction Layer
2/18/2014
In the previous post, I talked about a common programmable abstraction layer (CPAL). To better understand the thought process behind having a common PAL, it makes sense to review some of the workJeremy Schulman has been doing. Jeremy often refers to the Python interactive shell as the new CLI for networking. When you watch him give a demo using the Python shell as a CLI, it is second nature and looks exactly like a network CLI. It makes perfect sense.
Read More
In the previous post, I talked about a common programmable abstraction layer (CPAL). To better understand the thought process behind having a common PAL, it makes sense to review some of the workJeremy Schulman has been doing. Jeremy often refers to the Python interactive shell as the new CLI for networking. When you watch him give a demo using the Python shell as a CLI, it is second nature and looks exactly like a network CLI. It makes perfect sense.
Read More
Leveraging Python on Network Devices to Monitor Interfaces in Realtime
2/9/2014
In a recent post, I wrote about some Python work I was testing on the Nexus 3000. The end conclusion was that open Linux platforms will offer more flexibility --- for the consumer of the technology, ultimately the customer. In this post, we’ll take a look at an example that integrates Python with the native Linux operating system.
Read More
In a recent post, I wrote about some Python work I was testing on the Nexus 3000. The end conclusion was that open Linux platforms will offer more flexibility --- for the consumer of the technology, ultimately the customer. In this post, we’ll take a look at an example that integrates Python with the native Linux operating system.
Read More
Nexus 3000, Python, Linux, and Open Switch Platforms
1/11/2014
This post shares some thoughts on some recent testing I’ve done with a Cisco Nexus 3000 and its built-in Python interpreter. It also touches upon why open and programmable could benefit the community with some concrete examples.
The application that I have started to build is all about more efficiently and more easily managing devices programmatically without using the CLI. You will see that the Python APIs (methods, functions, etc.) are still fairly limited on the 3K, so I did have to use the “CLI” function to send commands from Python to the native Cisco NX-OS CLI. Having access to Linux could have made it possible to modify the files needed instead.
Read More
This post shares some thoughts on some recent testing I’ve done with a Cisco Nexus 3000 and its built-in Python interpreter. It also touches upon why open and programmable could benefit the community with some concrete examples.
The application that I have started to build is all about more efficiently and more easily managing devices programmatically without using the CLI. You will see that the Python APIs (methods, functions, etc.) are still fairly limited on the 3K, so I did have to use the “CLI” function to send commands from Python to the native Cisco NX-OS CLI. Having access to Linux could have made it possible to modify the files needed instead.
Read More
SDN Applications – Going beyond RESTful APIs
10/30/2013
Yesterday was an interesting day in that I attended a full day ONUG academy session that was all aboutwriting SDN applications. Big thanks to Matt Davy and Chuck Black for leading the session. While we weren’t hacking on code, there was a lot of discussion around APIs, network programmability, and the approach to take when building SDN applications [that leverage northbound APIs of a controller]. I’ve made it pretty public that I’ve been working with onePK building my own controller (using the term controller very loosely here) communicating directly with network devices as opposed to natively integrating with an existing controller like OpenDaylight, Floodlight, etc. and leveraging their northbound APIs.
Read More
Yesterday was an interesting day in that I attended a full day ONUG academy session that was all aboutwriting SDN applications. Big thanks to Matt Davy and Chuck Black for leading the session. While we weren’t hacking on code, there was a lot of discussion around APIs, network programmability, and the approach to take when building SDN applications [that leverage northbound APIs of a controller]. I’ve made it pretty public that I’ve been working with onePK building my own controller (using the term controller very loosely here) communicating directly with network devices as opposed to natively integrating with an existing controller like OpenDaylight, Floodlight, etc. and leveraging their northbound APIs.
Read More
Network Control Manager - onePK in Action
10/7/2013
A few weeks ago, I wrote about where I was in the world of programming. As I said then, I am still focused on building a onePK application. This onePK application now dubbed Network Control Manager is a central interface to the network. It can be used to gather real time data as well as make changes to the network in a more centralized, automated, and real-time fashion. Following the SDN model, this application can be seen as a SDN controller if you wish to call it that. The southbound API used is Cisco’s onePK and the northbound API is self-defined as “je-nb-API” :). The application/controller exposes northbound RESTful interfaces to be consumed by 3rd party applications and control programs, the first of which is a CLI application that interacts with the network via Network Control Manager.
Read More
A few weeks ago, I wrote about where I was in the world of programming. As I said then, I am still focused on building a onePK application. This onePK application now dubbed Network Control Manager is a central interface to the network. It can be used to gather real time data as well as make changes to the network in a more centralized, automated, and real-time fashion. Following the SDN model, this application can be seen as a SDN controller if you wish to call it that. The southbound API used is Cisco’s onePK and the northbound API is self-defined as “je-nb-API” :). The application/controller exposes northbound RESTful interfaces to be consumed by 3rd party applications and control programs, the first of which is a CLI application that interacts with the network via Network Control Manager.
Read More
Are you a Network Engineer looking to learn a Programming Language?
8/23/13
It’s been something I’ve wanted to tackle for a while, but choosing one is damn hard, especially as a network guy who hasn’t programmed in a while. I had two years of Advanced Programming (AP) in high school, but that was it and that was a long time ago. With network agility, automation, APIs, and SDN on the horizon, how should you pick a language and what do you even want to program? For everyone, it will be different, but I’ll let you know the path I’m taking and how I ended up where I’m at today.
Read More
It’s been something I’ve wanted to tackle for a while, but choosing one is damn hard, especially as a network guy who hasn’t programmed in a while. I had two years of Advanced Programming (AP) in high school, but that was it and that was a long time ago. With network agility, automation, APIs, and SDN on the horizon, how should you pick a language and what do you even want to program? For everyone, it will be different, but I’ll let you know the path I’m taking and how I ended up where I’m at today.
Read More
The Future of Networking and the Network Engineer
4/9/2012
I mentioned in my previous post Nick McKeown, uber smart Entrepreneur and Professor at Stanford, gave what I thought was the finest presentation of the week at the Open Networking Summit hosted in Santa Clara this week. As I wait to board my plane back to the East coast, here is a more detailed recap of the presentation and what I took away from it…
Read More
I mentioned in my previous post Nick McKeown, uber smart Entrepreneur and Professor at Stanford, gave what I thought was the finest presentation of the week at the Open Networking Summit hosted in Santa Clara this week. As I wait to board my plane back to the East coast, here is a more detailed recap of the presentation and what I took away from it…
Read More