Archive

Category Archives for "Keeping It Classless"

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

Handling “Multiples” in Cisco NX-API with Python

A few weeks ago, I was working with the NX-API currently found on Cisco’s Nexus 9000 series switches, and ran into some peculiar behavior.

NX-API returns all information in terms of Tables and Rows. For a specific example, let’s look at what NX-API returns when I ask the switch for running OSPF processes:

There’s actually a lot more information in this snippet that pertains to the OSPF process itself, but I have omitted it for brevity. This specific example focuses on the section that describes the areas in this OSPF process.

{
  "ins_api": {
    "sid": "eoc",
    "type": "cli_show",
    "version": "0.1",
    "outputs": {
      "output": {
        "code": "200",
        "msg": "Success",
        "input": "show ip ospf",
        "body": {
          "TABLE_ctx": {
            "ROW_ctx": {
              ### OSPF process information omitted for brevity ###
              "TABLE_area": {
                "ROW_area": {
                  "age": "P15DT15H27M6S",
                  "loopback_intf": "1",
                  "passive_intf": "0",
                  "last_spf_run_time": "PT0S",
                  "spf_runs": "9",
                  "lsa_cnt": "5",
                  "no_summary": "false",
                  "backbone_active": "true",
                  "stub": "false",
                  "aname": "0.0.0.0",
                  "total_intf": "2",
                  "auth_type": "none",
                  "act_intf": "2",
                  "nssa": "false",
                  "lsa_crc": "0x18d91"
                }
              }
            }
          }
        }
      }
    }
  }
}

NXAPI uses a special tag that starts with TABLE, and within that, tag(s) that start with ROW, whenever it needs to describe something that would normally be Continue reading

Handling “Multiples” in Cisco NX-API with Python

A few weeks ago, I was working with the NX-API currently found on Cisco’s Nexus 9000 series switches, and ran into some peculiar behavior. NX-API returns all information in terms of Tables and Rows. For a specific example, let’s look at what NX-API returns when I ask the switch for running OSPF processes: There’s actually a lot more information in this snippet that pertains to the OSPF process itself, but I have omitted it for brevity.

Handling “Multiples” in Cisco NX-API with Python

A few weeks ago, I was working with the NX-API currently found on Cisco’s Nexus 9000 series switches, and ran into some peculiar behavior. NX-API returns all information in terms of Tables and Rows. For a specific example, let’s look at what NX-API returns when I ask the switch for running OSPF processes: There’s actually a lot more information in this snippet that pertains to the OSPF process itself, but I have omitted it for brevity.

[SDN Protocols] Part 1 – OpenFlow Basics

This entry is part 2 of 4 in the series SDN Protocols

Let’s get into our first topic. And what better place to start than with the protocol that arguably started the SDN madness that we’re experiencing today – OpenFlow! I got fairly carried away with writing about this protocol, and understandably so – this is a complicated topic.

That’s why I’ve split this post (which is already part of a series – very meta, much deep) into two parts. This post – Part 1 – will address OpenFlow’s mid to high-level concepts, exploring what it does, why/how the idea of control plane abstraction may be useful, and  some details on how hardware interaction works. The second post – Part 2 – will dive a little deeper into the operation of OpenFlow on supporting physical and virtual switches, and the differences in some popular implementations of OpenFlow.

 

The State of Modern Control Planes

Before we get into the specifics of OpenFlow, it’s important we address the relationship between the control plane and the data plane, and how OpenFlow changes this relationship. You’ve undoubtedly heard by now that one of SDN’s key traits is the “separation” or “abstraction” of the control plane from the Continue reading

[SDN Protocols] Part 1 – OpenFlow Basics

Let’s get into our first topic. And what better place to start than with the protocol that arguably started the SDN madness that we’re experiencing today - OpenFlow! I got fairly carried away with writing about this protocol, and understandably so - this is a complicated topic. That’s why I’ve split this post (which is already part of a series - very meta, much deep) into two parts. This post - Part 1 - will address OpenFlow’s mid to high-level concepts, exploring what it does, why/how the idea of control plane abstraction may be useful, and some details on how hardware interaction works.

[SDN Protocols] Part 1 – OpenFlow Basics

Let’s get into our first topic. And what better place to start than with the protocol that arguably started the SDN madness that we’re experiencing today - OpenFlow! I got fairly carried away with writing about this protocol, and understandably so - this is a complicated topic. That’s why I’ve split this post (which is already part of a series - very meta, much deep) into two parts. This post - Part 1 - will address OpenFlow’s mid to high-level concepts, exploring what it does, why/how the idea of control plane abstraction may be useful, and some details on how hardware interaction works.

[SDN Protocols] Part 1 – OpenFlow Basics

Let’s get into our first topic. And what better place to start than with the protocol that arguably started the SDN madness that we’re experiencing today - OpenFlow! I got fairly carried away with writing about this protocol, and understandably so - this is a complicated topic. That’s why I’ve split this post (which is already part of a series - very meta, much deep) into two parts. This post - Part 1 - will address OpenFlow’s mid to high-level concepts, exploring what it does, why/how the idea of control plane abstraction may be useful, and some details on how hardware interaction works.

[SDN Protocols] – New Series

This entry is part 1 of 4 in the series SDN Protocols

The networking industry in the last few years has seen an explosion in buzzwords, slide decks, new technologies, and SDN product announcements.  The honest truth is that the networking industry is still in a great state of flux, as we collectively discover what SDN means to us.

There’s a lot of new terms floating around, and what makes things even harder to keep up with, the marketing engines are alive and well – muddying the waters, and making it nearly impossible to get technical facts straight. I’m fortunate enough to know a few people that remind me that what matters most is when the rubber meets the road (which usually manifests itself in “shut up and code”).

52770151 [SDN Protocols]   New Series

To that end, I am kicking off a series that will be completely dedicated to explaining the various protocols and technologies you might encounter in researching SDN.

 

Who Can Use This Series?

If you’re into open source implementations, all of this will be immediately relevant. Much of what I’ll be exploring pertains to the nitty-gritty under-the-covers operation of these protocols, and will often use real-world examples rooted deeply in open source, Continue reading

[SDN Protocols] – New Series

The networking industry in the last few years has seen an explosion in buzzwords, slide decks, new technologies, and SDN product announcements. The honest truth is that the networking industry is still in a great state of flux, as we collectively discover what SDN means to us. There’s a lot of new terms floating around, and what makes things even harder to keep up with, the marketing engines are alive and well - muddying the waters, and making it nearly impossible to get technical facts straight.

[SDN Protocols] – New Series

The networking industry in the last few years has seen an explosion in buzzwords, slide decks, new technologies, and SDN product announcements. The honest truth is that the networking industry is still in a great state of flux, as we collectively discover what SDN means to us. There’s a lot of new terms floating around, and what makes things even harder to keep up with, the marketing engines are alive and well - muddying the waters, and making it nearly impossible to get technical facts straight.

[SDN Protocols] – New Series

The networking industry in the last few years has seen an explosion in buzzwords, slide decks, new technologies, and SDN product announcements. The honest truth is that the networking industry is still in a great state of flux, as we collectively discover what SDN means to us. There’s a lot of new terms floating around, and what makes things even harder to keep up with, the marketing engines are alive and well - muddying the waters, and making it nearly impossible to get technical facts straight.

What is Unidirectional Automation?

I was pleased as punch to wake up the other day and read Marten Terpstra’s blog post on getting over the fear of using automation to make changes on our network infrastructure. He illuminated a popular excuse that I’ve heard myself on multiple occasions – that automation is great for things like threshold alarms, or pointing out the percieved root cause of a problem, but not actually fixing the problem. The idea is that the problems that occur on a regular basis, or even performing configuration changes in the first place – is a specialized task that a warm-blooded human being absolutely, no-doubt must take total control of in order to be successful.1266464746097 What is Unidirectional Automation?

With the right implementation, this idea is, of course, rubbish. I asked a question on Twitter not too long ago in preparation for a presentation I was about to give. I have a decent amount of experience working with VMware vSphere, and knew there were some experienced server virtualization folks following me, so I asked about a feature that was thought of in similar light not too long ago:

What is Unidirectional Automation?

I was pleased as punch to wake up the other day and read Marten Terpstra’s blog post on getting over the fear of using automation to make changes on our network infrastructure. He illuminated a popular excuse that I’ve heard myself on multiple occasions - that automation is great for things like threshold alarms, or pointing out the percieved root cause of a problem, but not actually fixing the problem.

What is Unidirectional Automation?

I was pleased as punch to wake up the other day and read Marten Terpstra’s blog post on getting over the fear of using automation to make changes on our network infrastructure. He illuminated a popular excuse that I’ve heard myself on multiple occasions - that automation is great for things like threshold alarms, or pointing out the percieved root cause of a problem, but not actually fixing the problem.

Spine/Leaf Topology Explorer with Ansible

I’ve mentioned before the need for networks to be addressed in a very programmatic way. Very often, I’ve found the discussion is actually a lot less about “programming language” details and more about getting rid of the methodology of addressing the network as a mere “collection of boxes” (see “Box Mentality“).

Instead, we have the ability to address the network as any developer would address the distributed components of an application. We acknowledge that networks are a distributed system – it’s what makes them as scalable as they have been. However, it’s important to understand we can address configuration and troubleshooting needs in a unified, automated way as well.

My goal in this post is to explore one particular application of such a methodology. I will use Ansible to first create a dataset that represents a spine/leaf network topology – also demonstrating how it might scale beyond my small lab implementation – then I will move into some kind of network task based on this information.

I have access to a few Cisco Nexus 9000 switches in the lab, and I wanted to be able to model a spine/leaf topology in a very elegant way that would (theoretically) scale as Continue reading

Spine/Leaf Topology Explorer with Ansible

I’ve mentioned before the need for networks to be addressed in a very programmatic way. Very often, I’ve found the discussion is actually a lot less about “programming language” details and more about getting rid of the methodology of addressing the network as a mere “collection of boxes” (see “Box Mentality”). Instead, we have the ability to address the network as any developer would address the distributed components of an application.

Spine/Leaf Topology Explorer with Ansible

I’ve mentioned before the need for networks to be addressed in a very programmatic way. Very often, I’ve found the discussion is actually a lot less about “programming language” details and more about getting rid of the methodology of addressing the network as a mere “collection of boxes” (see “Box Mentality”). Instead, we have the ability to address the network as any developer would address the distributed components of an application.

Network Automation or SDN?

With all of the activity going on in the networking industry right now, and all of the new terminology (as well as old re-invented terminology), it’s quite easy to get messages mixed up. After all, there’s no centralized dictionary for all of this stuff. I’d like to address something that has bugged me for a while.

I’ve now heard from quite a few folks that SDN to them means the ability to automate network tasks. This almost totally misses the point, in my opinion. Network automation should literally be thought of a prerequisite for what we’ll likely be doing on our networks in 10 years; call it SDN if you want. My logic involved with coming to this conclusion is almost 100% about the people involved. Allow me to elaborate.

 

What’s Missing?

In my experience the main thing that’s missing from 90% of enterprise networks today is that networking teams have not properly defined their workflows, and/or have not formalized a service catalog to other parts of the business. As a result, everything is fire-fighting, or one-off requests.

Tracking changes historically, and pinning them to business processes is totally impossible (if it’s even attempted), and garbage collection does not occur. Continue reading

Network Automation or SDN?

With all of the activity going on in the networking industry right now, and all of the new terminology (as well as old re-invented terminology), it’s quite easy to get messages mixed up. After all, there’s no centralized dictionary for all of this stuff. I’d like to address something that has bugged me for a while. I’ve now heard from quite a few folks that SDN to them means the ability to automate network tasks.
1 12 13 14 15 16 38