Automating Cisco Nexus Switches with Ansible

In previous posts, I’ve written about using Ansible for network automation. Few of them can be found here, here, here, and here. In one of the posts, I had a video that was automating Cisco routers with Ansible, and was using onePK as the API to communicate to the device. In this post, I’ll be focusing on automating Nexus switches – this means each of the Ansible modules will be using NX-API to communicate with the device. This also eliminates the need for the users of these modules to know Python as they’ll be using the Ansible platform for their specific automation needs.

While the demo below is for configuration automation and shows what can be done in just a few seconds, it needs to be understood that automation is much more than pushing configurations. I hope to show some of this first hand by doing more interesting things as it pertains to data gathering, verification, troubleshooting, that do increase speed and agility, but also predictability.

The following video shows how Ansible can be used to automate interfaces and VLANs on Nexus switches. This will be the first in a 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

Introduction to Using Cisco NX-API

I've posted a few times in the past about Cisco's NX-API and realized I hadn't provided any guidance on how to get started using the API itself. In this post, I share two videos that are meant to serve as a quick start to those who don't have a development background and are looking to test NX-API.

The first video looks at the NX-API sandbox and how you map the data represented in the sandbox back into objects that you can use while working in Python.

The second video shows where to get the modules that I use in the first video, namely xmltodict and device.py.

Note: the device module that I use is primarily used with XML data being returned from the device. The easiest thing for those who want to test is to follow the steps outlined in the videos although there are mechanisms to switch to JSON. This device module does not support json-rpc (as that is still fairly new in NX-API).

And, don't forget, you'll need to connect to your Nexus 3K/9K via the management interface to work with NX-API.

Other NX-API links to check out:

Cisco Nexus 9000 NX-API
Cisco NX-API 1.0 Update
Continue reading

Introduction to Using Cisco NX-API

I’ve posted a few times in the past about Cisco’s NX-API and realized I hadn’t provided any guidance on how to get started using the API itself. In this post, I share two videos that are meant to serve as a quick start to those who don’t have a development background and are looking to test NX-API.

The first video looks at the NX-API sandbox and how you map the data represented in the sandbox back into objects that you can use while working in Python.
The second video shows where to get the modules that I use in the first video, namely xmltodict and device.py.

Note: the device module that I use is primarily used with XML data being returned from the device. The easiest thing for those who want to test is to follow the steps outlined in the videos although there are mechanisms to switch to JSON. This device module does not support json-rpc (as that is still fairly new in NX-API).

And, don’t forget, you’ll need to connect to your Nexus 3K/9K via the management interface to work with NX-API.

Videos

Introduction Part 1

Introduction Part 2

Facebook Altoona Network Diagram in 2-D

Facebook recently wrote about the network architecture they are using in their new Altoona data center facility. If you haven't read through their article yet, it's definitely worth the read.

They have a few diagrams that outline the architecture. One of them is in 3-D. 3-D diagrams are always more difficult for my brain to conceptualize (maybe it's just me), so I re-drew it in a more typical 2-D fashion.

There aren't details on quantity and speeds of ports for the spine and edge switches, so I represented them similar to how they have them in their diagram. Assuming at least 144 ports of 40G in each spine switch it would allow the data center to be the home to over 100,000 servers. For every downward facing port a spine switch has (across the plane), 2300 servers can be added. That's the amount of servers per pod. 48 servers per rack * 48 racks per pod = 2300 servers. Based on the switch types being used, this number could be more, but I'm using the characteristics of 48 x 10G ports for host facing ports + 4 x 40G ports for uplinks.

My diagram depicts 8 racks in the POD Continue reading

Facebook Altoona Network Diagram in 2-D

Facebook recently wrote about the network architecture they are using in their new Altoona data center facility. If you haven’t read through their article yet, it’s definitely worth the read.

They have a few diagrams that outline the architecture. One of them is in 3-D. 3-D diagrams are always more difficult for my brain to conceptualize (maybe it’s just me), so I re-drew it in a more typical 2-D fashion.
There aren’t details on quantity and speeds of ports for the spine and edge switches, so I represented them similar to how they have them in their diagram. For every downward facing port a spine switch has (across the plane), 2300 servers can be added. That’s the amount of servers per pod. 48 servers per rack * 48 racks per pod = 2300 servers. Based on the switch types being used, this number could be more, but I’m using the characteristics of 48 x 10G ports for host facing ports + 4 x 40G ports for uplinks.

My diagram depicts 8 racks in the POD and 8 switches per plane. These numbers would be 48 in a fully built out network/diagram.

altoona

Feel free to comment and correct anything I may Continue reading

Using Schprokits to Automate Big Switch’s Big Cloud Fabric

I gave a presentation at Interop last month and tried to make two major points about network automation. One, network automation is so much more than just “pushing configs” and two, network automation is still relevant in Software Defined Network environments that have a controller deployed as part of the overall solution. And I’m referring to controllers from ANY vendor including, but definitely not limited to Cisco’s APIC, NSX Controllers, Nuage Controller/Director, Juniper Contrail, Plexxi Control, OpenDaylight, and Big Switch’s Big Cloud Fabric.

A few months ago, I was at Network Field Day 8 and got to see a live demo of Big Switch’s newly released Big Cloud Fabric solution. It seemed slick, but I was curious on automating the fabric using the northbound APIs exposed from their controller. As it turns out, I was able to get access to a small fabric (2 leafs / 2 spines) to get familiar with Big Cloud Fabric. In parallel to that, I started testing Schprokits as I mentioned in my previous post.

So, sure enough I spent some time putting together a demo to show what can be done with network automation tools and how they Continue reading

Using Schprokits to Automate Big Switch’s Big Cloud Fabric

So, sure enough I spent some time putting together a demo to show what can be done with network automation tools and how they could integrate with SDN controllers. The Continue reading

Automated Network Diagrams with Schprokits & AutoNetkit

Over the past few months I’ve written about Ansible and the intersection of DevOps and Networking quite a few times. As network vendors continue to develop better APIs on network devices (switches, routers, FWs, etc.) there is no doubt going to be an emergence of new tools for the network industry. One of these emerging tools is Schprokits. Schprokits (company name and product name), still in stealth, was founded by Jeremy Schulman, who previously worked at Juniper and did the initial work for integrating Junos with Puppet, Chef, and Ansible, and on top of that developed the Juniper PyEZ Python framework. Schprokits seems to be the outcome of Schulman’s experiences working with existing DevOps automation platforms and building one now purpose built for networking. Over the past few weeks, I've been fortunate to be able to be part of the first Schprokits user-test group.

In this article, I’m going to explore not only working with Schprokits, but also working with AutoNetkit. AutoNetkit, part of the PhD thesis work of Simon Knight, is an application and framework for modeling network devices, both from a configuration and visualization/diagramming standpoint. Some of Continue reading

Application Routes with onePK and the Need for Better Libraries

It’s been some time since I wrote about Cisco’s onePK. In this post, I’ll look at some of the good and the bad of onePK and also show an example of how to add a route to a device running onePK to help make a few points along the way.

The Bad

I’ve never heard anyone speak positively about onePK and I’m not sure I 100% agree, but I’ll save the positivity for the next section. onePK is a thick Software Development Kit (SDK). If you are a network engineer looking to learn to program from the ground up, it may NOT be the BEST place to start. That said, if you are looking to learn about object oriented programming, listener APIs, etc., and can spare some time, it’s a great place to start. If you’re already a developer, it probably won’t be much different compared to learning any other SDK.

Another thing to be weary of is that onePK was not intended to be a configuration API. I voiced my opinion on this already and I do think things are headed in the right direction, but it always helps knowing the history. Continue reading

VMware Meets The Physical Network — What If?

With other acquisition rumors floating around, I figured I would add my own 2 cents and do some speculating.

It’s not uncommon to hear that VMware might acquire Cumulus. Like others, it’s one acquisition that I’ve speculated about for a while. There is already an interesting dynamic between Cisco and VMware, but as both companies continue to go to market with their Software Defined Networking (SDN), or controller based solutions, VMware still needs to run over a physical data center network. The physical network market is still largely dominated by Cisco though. Does VMware want or need to control the physical network?

Extending the SDDC

If VMware took their network strategy one step further and kept true to the Software Defined Data Center (SDDC), they would need a network operating system (NOS) that could run on approved hardware, e.g. hardware compatibility list (HCL). They need a bare metal (white box) switch company. Cumulus fits this build well because they are focused on creating open IP fabrics using tried and true protocols and already have their own HCL. They’ve also already partnered with VMware and support VXLAN termination on certain platforms. Continue reading

Interop NYC & Software Gone Wild

Last week I had the pleasure of speaking at Interop in NYC. It wasn’t the best turn out for a conference, but all of the sessions that were about automation, APIs, DevOps, and programmability seemed to do fairly well. For those that didn't attend, the title of the presentation was A Practical Look at Network Automation --- the deck is posted below.

I also had the opportunity to be a guest on Ivan Pepelnjak’s podcast Software Gone Wild recently and it was just posted yesterday. Have a listen.

edelman-interopnyc-092014pv.pdf
File Size:	4237 kb
File Type:	pdf

Download File

Feel free to reach out with any questions or comments regarding any of the material.

Thanks,
Jason

Twitter: @jedelman8

Network Automation & Programmability Survey

Many vendors collect their own data that is more than likely a little skewed and biased. As I prepare for a few upcoming presentations, I thought it would be great to get some REAL data from REAL people doing great things or even those just starting on their automation journey.

If you would be kind enough, there is a link to a survey below that asks a few questions pertaining to network automation and programmability. No personal information is required.

Network Automation & Programmability Survey

If you wish to see the results, please fill the survey out :)

Thanks in advance,
Jason

Twitter: @jedelman8

Prescriptive Topology Manager (PTM) support with NX-API on the Nexus 9000?

Cumulus Networks has been talking a lot about Prescriptive Topology Manager (PTM). A great overview of PTM can be found here, but the high level is that PTM ensures “wiring rules are followed by doing a simple runtime verification of connectivity.” This means that as a user, you can define what the physical topology, or wiring, is supposed to be and compate it against what it really is by leveraging LLDP. The PTM daemon (PTMd) is what does this analysis on each switch running Cumulus Linux. There is even integration with routing protocols such that if two switches are improperly cabled, no routing adjacencies will be permitted on that link. You can check out the PTM code since it is available under the Eclipse Public License (EPL).

Cumulus is said to have a few, but very large customers --- these customers operate at the highest efficiency levels and it is customers like these (speculating here, just go with me) that probably drove Cumulus to develop a feature like this. However, this is a real problem for networks of all sizes. I’ve seen 100s to 1000s of pages of word docs and excel Continue reading

Network Automation with Python, Ansible, and Twitter Integration

Last month I wrote about using the Cisco Nexus NX-API to extract stats from a Nexus switch while using Ansible. For some reason, last night I finally went on to tackle how to integrate with the Twitter API and then integrated the two together. Integrating with Twitter has always been top of mind, but just put it on the back burner. Funny enough though, it was a pretty quick integration thanks to the great people at Google.

What am I talking about?

In the code I pushed last month, I created an Ansible playbook that pulls interface stats from a Nexus 9000 (or any other Nexus device supporting NX-API) and then creates a template report for those stats. It was pretty vanilla, nothing fancy about it.

There have been integrations with other social platforms, but to be honest, the one that has been stuck in my brain is Hubot that is used at GitHub. Several months back I remember hearing about Hubot for the second or third time while listening to the Cloudcast podcast with Mark Imbriaco (just before he went to Digital Ocean). It is amazing to see what can be done Continue reading

Integrating Spirent into an Automated Workflow Test Methodology

I’ve spent the last few days getting briefed by several vendors in Silicon Valley. They include A10, Big Switch, Brocade, Cisco, Gigamon, Nuage, Pluribus, Spirent, and Thousand Eyes. Over the next few weeks, I’ll try and get a few posts out about the briefings, but for the first one I wanted to focus on Spirent. Many are probably aware that Spirent provides packet generators and while that’s what they sell and are really good at, it’s the strategy, vision, and software integration with their products that was extremely intriguing.

I’ve engaged with many customers over the past 10 years and the majority have never felt a real need to test performance. It was and is usually very easy to over provision hardware when it comes to Layer 2 & 3 switching. This is still the case for the most part too – there are 1 RU and 2 RU switches that can forward traffic faster than those big monster boxes of just a few years ago.

Why Test Now?

There are network functions being virtualized from almost every vendor out there --- this usually falls under the Network Functions Virtualization (NFV) trend. It’s Continue reading

Internal Networking for the new UCS Modular Chassis

At the end of the day, any announcement that is NON networking focused NEEDS a networking focus. I just attended the UCS Grand Slam launch where there were a few announcements for UCS including the new UCS mini, capacity optimized UCS, and the UCS modular chassis (M series). The latter was of the most interest to me.

The new M series de-couples CPU and memory from other peripherals on board including networking and storage. CPU and memory exist on a replaceable / upgradeable cartridge and can be upgraded without touching the network or SSDs on board. This smells and feels like the disaggregation happening in the Open Compute Project (OCP), but of course, the Cisco solution can be managed with all existing and new UCS systems via UCS Manager. This could definitely be the start of a new computing paradigm for the Enterprise.

Platform Overview

Each UCS M series chassis has 8 cartridges in a 2 RU form factor. Each cartridge has two (2) quad core CPUs and 64GB memory, thus each server has a single quad core CPU and 32GB memory. There are also 4 SSDs and dual 1400W power supplies per Continue reading

Steve Jobs Thinks All Network Engineers Should Learn to Code

With some downtime this weekend, I was able to watch a few documentaries on NetFlix. There were a few great ones on Mark Zuckerberg, Warren Buffet, Mark Cuban, and Steve Jobs. Many of them came from the Bloomberg Game Changers series, but for Steve Jobs, I watched the Steve Jobs: The Lost Interview that was filmed in 1995, lost for almost two decades and then was released in 2012. I highly recommend all of them, but for this post, I want to highlight something Jobs said nearly 20 years ago.

What does this have to do with Networking?

There have been numerous articles over the past few months, some by me, that either advocate that network engineers should learn how to program, that there is no need for them to learn how to program, or they should simply learn to think like programmers.

Now check out what Steve Jobs said in the following video back in 1995:

…I think everybody in this country should learn how to program a computer – [they] should learn a computer language, because it teaches you how to think. It’s like going to law school. I don’t think anybody should be Continue reading

Ethane Changed Everything – DevOps for Networking Could be Next

It’s an interesting time in networking, isn’t it? I can probably quote myself saying that for as long as I’ve been blogging and about a year before that. Supposedly 2015 is the year of POCs, bakeoffs, and seeing which startups continue to get funding, and which ones slowly dissolve. As we start to see who the winners and losers may be, I thought it would be good to highlight the last 7 years and where the major focuses areas have been and see what could be next.

Hello OpenFlow!

By now, many of us know who Martin Casado is and what he’s done. His PhD work, Ethane, at Stanford with Nick McKeown and team led to the pre 1.0 work of OpenFlow. For the first several years of the network (r)evolution, it was all about OpenFlow. By 2009, the phrase Software Defined Networking had emerged and referred to OpenFlow enabled architectures. It was easy to understand.

As the industry chatter increased on OpenFlow architectures, hardware commoditization, and the de-coupling of the control plane and data plane, Casado had already started Nicira with McKeown and Shenker.
When limitations were seen on what Continue reading

Leveraging Cisco NX-API with Ansible to Make Your Life Easier

I had a conversation recently with someone who has more of a sysadmin background. We started talking about the intersection of DevOps and networking and while his environment wasn’t large, there was one pain point he talked about – he doesn't have access to the network switches to ensure they are configured properly for “his” servers and to ensure packets aren't being dropped, etc. when there are issues with the application, server, or network. And by the way, he really doesn't want access to the data center switches, because after all, many fear logging into network devices that are in production.

Could DevOps and network automation help here?

In fact, the answer is yes. The goal is to get the right data into the right hands as quick as possible. An automation platform can be used to query the switch to get the exact data the admin needs. For those that have help desks supporting large campus networks, the same philosophy can be used there as well. Help desk, junior admins, and cross-functional team members can now get what they need in just a few seconds.

In order to test this out, I’ve Continue reading

« Previous 1 2 3 4 5 Next »

Archive

CLI-Driven Automation

Videos