Cisco NX-API 1.0 Update
If you weren’t paying attention, it was easy to miss. NX-API, Cisco’s new JSON/XML switch API is now shipping as version 1.0. NX-API originated on the Nexus 9000 platform created by the Insieme group, and I’ve explored this in detail before.
In review, NX-API is a new, programmatic method of interacting with a Cisco Nexus switch. In many ways, Cisco is playing catch-up here, since this interface is really just a wrapper for the CLI (admittedly with some convenient output parsing), and most of their competitors have had similar interfaces for a while. Nevertheless, it is better than scraping an SSH session, so it’s worth looking into.
I’d like to go over a few new things you should know about if you are or will be working with this interface.
NX-API 1.0 Updates
From a strictly API perspective, not a lot seems to have changed. I would be more specific, but as of yet I’ve been unable to find release notes from Cisco on what’s changed from 0.1 to 1.0. If I ever find something like this, I’ll get my hands on it – part of publishing a good API means publishing good documentation, and Continue reading
Cisco NX-API 1.0 Update
If you weren’t paying attention, it was easy to miss. NX-API, Cisco’s new JSON/XML switch API is now shipping as version 1.0. NX-API originated on the Nexus 9000 platform created by the Insieme group, and I’ve explored this in detail before. In review, NX-API is a new, programmatic method of interacting with a Cisco Nexus switch. In many ways, Cisco is playing catch-up here, since this interface is really just a wrapper for the CLI (admittedly with some convenient output parsing), and most of their competitors have had similar interfaces for a while.Cisco NX-API 1.0 Update
If you weren’t paying attention, it was easy to miss. NX-API, Cisco’s new JSON/XML switch API is now shipping as version 1.0. NX-API originated on the Nexus 9000 platform created by the Insieme group, and I’ve explored this in detail before. In review, NX-API is a new, programmatic method of interacting with a Cisco Nexus switch. In many ways, Cisco is playing catch-up here, since this interface is really just a wrapper for the CLI (admittedly with some convenient output parsing), and most of their competitors have had similar interfaces for a while.Network Troubleshooting with ThousandEyes
My first experience with ThousandEyes was a year ago at Network Field Day 6, where they were kind enough to give us a tour of their office, and introduce us to their products. I’ve been fairly distracted since then, but kept an eye on what other delegates like Bob McCouch were doing with the product since that demo.
A year later, at Network Field Day 8, they presented again. If you’ve never heard of ThousandEyes, and/or would like an overview, watch Mohit’s (CEO) NFD8 introduction:
Debugging the Internet
One of the things that really stuck out a year ago, and was reinforced tenfold this year, was that ThousandEyes was not introducing any new protocols to the industry – at a time when all of the headlines were talking about new protocols (i.e. OpenFlow). Numerous tech startups – especially those in networking – are in existence purely to tackle the big “software-defined opportunity” gold rush.
Instead, ThousandEyes is focused on network monitoring. If you’re like me – you hear those words and immediately conjure up images of all of the…..well, terrible software that exists today to monitor networks. In addition, network monitoring is inherently very fragmented. You can really only Continue reading
Network Troubleshooting with ThousandEyes
My first experience with ThousandEyes was a year ago at Network Field Day 6, where they were kind enough to give us a tour of their office, and introduce us to their products. I’ve been fairly distracted since then, but kept an eye on what other delegates like Bob McCouch were doing with the product since that demo. A year later, at Network Field Day 8, they presented again. If you’ve never heard of ThousandEyes, and/or would like an overview, watch Mohit’s (CEO) NFD8 introduction:Network Troubleshooting with ThousandEyes
My first experience with ThousandEyes was a year ago at Network Field Day 6, where they were kind enough to give us a tour of their office, and introduce us to their products. I’ve been fairly distracted since then, but kept an eye on what other delegates like Bob McCouch were doing with the product since that demo. A year later, at Network Field Day 8, they presented again. If you’ve never heard of ThousandEyes, and/or would like an overview, watch Mohit’s (CEO) NFD8 introduction:[SDN Protocols] Part 4 – OpFlex and Declarative Networking
In this post, we will be discussing a relatively new protocol to the SDN scene – OpFlex. This protocol was largely championed by Cisco, but there are a few other vendors that have announced planned support for this protocol. I write this post because – like OVSDB – there tends to be a lot of confusion and false information about this protocol, so my goal in this post is to provide some illustrations that (hopefully) set the record straight, with respect to both OpFlex’s operation, and it’s intended role.
Before I get started, I would be remiss to not point you towards a brilliant article by Kyle Mestery titled “OpFlex is not an OpenFlow Killer“. At the time the article was written, Kyle was working for Noiro, a team within the INSBU at Cisco focused (at least primarily) on open source efforts in SDN, and the creators of OpFlex.
The Declarative Model of Network Programmability
Before we get into the weeds of the OpFlex protocol, it’s important to understand the model that OpFlex intends to address. OpFlex is the protocol du jour within a Cisco ACI based Continue reading
[SDN Protocols] Part 4 – OpFlex and Declarative Networking
In this post, we will be discussing a relatively new protocol to the SDN scene - OpFlex. This protocol was largely championed by Cisco, but there are a few other vendors that have announced planned support for this protocol. I write this post because - like OVSDB - there tends to be a lot of confusion and false information about this protocol, so my goal in this post is to provide some illustrations that (hopefully) set the record straight, with respect to both OpFlex’s operation, and it’s intended role.[SDN Protocols] Part 4 – OpFlex and Declarative Networking
In this post, we will be discussing a relatively new protocol to the SDN scene - OpFlex. This protocol was largely championed by Cisco, but there are a few other vendors that have announced planned support for this protocol. I write this post because - like OVSDB - there tends to be a lot of confusion and false information about this protocol, so my goal in this post is to provide some illustrations that (hopefully) set the record straight, with respect to both OpFlex’s operation, and it’s intended role.[SDN Protocols] Part 4 – OpFlex and Declarative Networking
In this post, we will be discussing a relatively new protocol to the SDN scene - OpFlex. This protocol was largely championed by Cisco, but there are a few other vendors that have announced planned support for this protocol. I write this post because - like OVSDB - there tends to be a lot of confusion and false information about this protocol, so my goal in this post is to provide some illustrations that (hopefully) set the record straight, with respect to both OpFlex’s operation, and it’s intended role.[SDN Protocols] Part 3 – OVSDB
Today, we will be discussing the Open vSwitch Database Management Protocol, commonly (and herein) referred to as OVSDB. This is a network configuration protocol that has been the subject of a lot of conversations pertaining to SDN. My goal in this post is to present the facts about OVSDB as they stand. If you want to know what OVSDB does, as well as does NOT do, read on.
I would like to call out a very important section, titled “OVSDB Myths”. I have encountered a lot of false information about OVSDB in the last year or so, and would like to address this specifically. Find this section at the end of this post.
If you’re new to OVSDB, it’s probably best to think of it in the same way you might think of any other configuration API like NETCONF, or maybe even proprietary vendor configuration APIs like NXAPI; it’s goal is to provide programmatic access to the management plane of a network device or software. However, in addition to being a published open standard, it is quite different in it’s operation from other network APIs.
Control vs Continue reading
[SDN Protocols] Part 3 – OVSDB
Today, we will be discussing the Open vSwitch Database Management Protocol, commonly (and herein) referred to as OVSDB. This is a network configuration protocol that has been the subject of a lot of conversations pertaining to SDN. My goal in this post is to present the facts about OVSDB as they stand. If you want to know what OVSDB does, as well as does NOT do, read on. I would like to call out a very important section, titled “OVSDB Myths”.[SDN Protocols] Part 3 – OVSDB
Today, we will be discussing the Open vSwitch Database Management Protocol, commonly (and herein) referred to as OVSDB. This is a network configuration protocol that has been the subject of a lot of conversations pertaining to SDN. My goal in this post is to present the facts about OVSDB as they stand. If you want to know what OVSDB does, as well as does NOT do, read on. I would like to call out a very important section, titled “OVSDB Myths”.[SDN Protocols] Part 3 – OVSDB
Today, we will be discussing the Open vSwitch Database Management Protocol, commonly (and herein) referred to as OVSDB. This is a network configuration protocol that has been the subject of a lot of conversations pertaining to SDN. My goal in this post is to present the facts about OVSDB as they stand. If you want to know what OVSDB does, as well as does NOT do, read on. I would like to call out a very important section, titled “OVSDB Myths”.Dealing with Schema Changes
It’s not often I get to write about concepts rooted in database technology, but I’d like to illuminate a situation that software developers deal with quite often, and one that those entering this space from the network infrastructure side may want to consider.
Software will often communicate with other software using APIs – an interface built so that otherwise independent software processes can send and receive data between each other, or with other systems. We’re finding that this is a pretty hyped-up buzzword in the networking industry right now, since network infrastructure historically has had only one effective method of access, and that is the CLI; not exactly ideal for anything but human beings.
These APIs will typically use some kind of transport protocol like TCP (many also ride on top of HTTP), in order to get from point A to point B. The data contained within will likely be some kind of JSON or XML structure. As an example, here’s the output from a Nexus 9000 routing table:
<?xml version="1.0"?>
<ins_api>
<type>cli_show</type>
<version>0.1</version>
<sid>eoc</sid>
<outputs>
<output>
<body>
<TABLE_vrf>
<ROW_vrf>
<vrf-name-out>default</vrf-name-out>
<TABLE_addrf>
<ROW_addrf>
<addrf>ipv4</addrf>
<TABLE_prefix>
<ROW_prefix>
<ipprefix>172.16.41.1/32</ipprefix>
<ucast-nhops>1</ucast-nhops>
<mcast-nhops>0</mcast-nhops>
<attached>FALSE</attached>
<TABLE_path>
<ROW_path>
<ipnexthop>172. Continue reading
Dealing with Schema Changes
It’s not often I get to write about concepts rooted in database technology, but I’d like to illuminate a situation that software developers deal with quite often, and one that those entering this space from the network infrastructure side may want to consider. Software will often communicate with other software using APIs - an interface built so that otherwise independent software processes can send and receive data between each other, or with other systems.Dealing with Schema Changes
It’s not often I get to write about concepts rooted in database technology, but I’d like to illuminate a situation that software developers deal with quite often, and one that those entering this space from the network infrastructure side may want to consider. Software will often communicate with other software using APIs - an interface built so that otherwise independent software processes can send and receive data between each other, or with other systems.[SDN Protocols] Part 2 – OpenFlow Deep-Dive
In the last post, I introduced you to the concept of control plane abstraction, specifically the OpenFlow implementation. I talked about how OpenFlow allows us to specify the flows that we want to be programmed into the forwarding plane, from outside the forwarding device itself. We can also match on fields we typically don’t have access to in traditional networking, since current hardware is optimized for destination-based forwarding.
In this post, I plan to cover quite a few bases. The goal of this post is to address the main concepts of OpenFlow’s operation, with links to find out more. With this post, you’ll be armed with the knowledge of what OpenFlow does and doesn’t do, as well as resources to dive even deeper.
NOTICE: This blog post was written referencing the specification and implementations of OpenFlow 1.3 – since this version, some aspects of the protocol may have changed (though it is likely the fundamentals discussed here will be mostly the same)
OpenFlow Tables
The OpenFlow specification describes a wide variety of topics. For instance, the protocol format that’s used to communicate with an OpenFlow switch Continue reading