If you read this site often, you already know I’ve been doing quite a bit of work with Ansible specifically as it pertains to networking. While I will be showing another video very soon in a follow up post, I wanted to take a step back and cover a few things before doing so. The focus here is less about the technology and more my general mindset around automation PLATFORMS, code, open source, and why I do it. Just something I’d like to share because I’m occasionally asked questions around these topics.

When networks are deployed in a box by box model, network admins know exactly what, where, and how something is being configured. In highly dynamic environments, this may not be the case. This is why it’s crucial to understand what is really going on behind the scenes. In OpenStack, there are several components that together are comprised to make OpenStack Networking (aka Neutron). These include the Neutron server, dhcp agent, metadata agent, L3 agent, and then the agents that would reside in the infrastructure to be programmed (on either physical and/or virtual switches). For example, in Open vSwitch deployments, there would be a Neutron OVS agent on each host/server. And this could vary based on which particular vendor plugin is being used too! In this post, I’m going to mainly focus on the Neutron Layer 3 agent because I had a hard time grasping this one at first. It turns out that it’s not so bad after all.

[Special and huge thanks to Scott Lowe for answering an endless amount of questions I had while writing this post and testing with NSX/OVS over the last few days. Thanks to Deepesh as well who I bounced OVS questions off of when I needed to give Scott a break. ]

In the last post, I talked about how Ansible could be used for various forms of network automation. In the comments, 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.

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

You can’t listen to an interview or podcast, an industry panel, or read a Q&A about the future of networking that doesn’t involve skill sets. The biggest question of them all – what skills should network engineers focus on so they don’t become irrelevant? If you really want to know what skills make sense, why ask, when you can do an easy search to see what skills companies are looking for these days in a variety of roles. Combine SDN with DevOps into your search criteria and the results may surprise you. They sure surprised me.

It’s been two weeks since I attended my 3rd consecutive Open Networking Summit (ONS) and I’m glad to say, I finally found some time to get some notes and thoughts on paper about the conference. Here are some on SDN at Google and Microsoft, and how they compare and contrast to industry incumbents’ solutions, but also how programmable NFV can be game changing in the Enterprise. I also include thoughts on how Embrane and Big Switch play into this.

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.

Two of the three companies promoting white box, now more commonly known as bare metal, switching are Cumulus and Big Switch Networks. There has been coverage on each of these companies, but the question always arises, “does Cumulus support OpenFlow?” I had the chance to talk to JR Rivers, Cumulus CEO, at the last Open Networking User Group (ONUG) during a Tech Field Day video and heard the answer from him then, but hadn’t seen anything documented publicly.

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 work Jeremy 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.

In late January, there were some big names on stage at the latest Open Compute Summit. I’d like to focus on one keynote panel that was called, “Opening Up Network Hardware.” The panelists for this session included Martin Casado (VMware), Matthew Liste (Goldman Sachs), Dave Maltz (Microsoft), and JR Rivers (Cumulus) and was led by Najam Ahmad (Facebook). If you haven’t watched the session already, it’s definitely worth it. You can check it out here.

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.

If you haven’t heard, there is a new switch vendor in town – Pluribus Networks. That’s right. In the new world where hardware is being dominated by software, there is an upstart that is trying to sell ASICs (along with their value added software, of course). This actually isn’t too common these days. Since Software Defined Networking (SDN) became the latest craze, the only startups going after major incumbents have been Plexxi and Pica8. Before them, Arista.

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.

Software Defined Networking (SDN) is the new way of networking. It’s plain and simple. And one of these days we’ll just go back to calling it networking because at its root, the network will still be forwarding the data needed for businesses to operate and thrive. In this post, we’ll look at several new products and companies that have emerged over the last few years within the SDN Ecosystem and see why SDN is already the new norm in networking.

After reading Ivan Pepelnjak’s (ipspace) and Martin Casado’s (networkheresy) blogs recently, I noticed they were making general comparisons on network tunneling protocols. These protocols are nothing new, for example using UDP, GRE, EoMPLS, VPLS, and a new one being mentioned over the past several months, VXLAN. However, what caught my attention was CAPWAP was also a protocol each of them used to compare to GRE, UDP, and VXLAN. As you’ll recall in my recent OpenFlow post, I spent quite a bit of time comparing OpenFlow to CAPWAP in the sense OpenFlow is being used to separate the control and data planes on switches and CAPWAP is being used to separate the control and data planes on Access Points.

There have been numerous articles, blogs, and columns written over the past few months on OpenFlow and Software Defined Networking, but I still feel like many of them aren’t breaking it down for the typical Enterprise Network Engineer. Having followed OpenFlow since mid 2010, I do not claim to be an expert in this space, but I will give my take on what could be the game changer for the networking industry.

There are a few different warranty programs available from Cisco that are not widely advertised and discussed. However, given that every customer has different technical and business requirements, it is also true that each customer has different SLAs that have to be met internal to their organization. So let’s examine some of the options available.

The Nexus 7000 is constantly evolving and there seems to be more and more design parameters that have to be taken into consideration when designing Data Center networks with these switches. I’m not going to go into each of the different areas from a technical standpoint, but rather try and point out as many of those so called “gotchas” that need to be known upfront when purchasing, designing, and deploying Nexus 7000 series switches.