With some inspiration from some of my friends currently at Networking Field Day 17, I’ve created a simple product description generator for the next generation of networking products that always seem to be coming out.  Refresh the page for new versions of the amazing products you’re destined to hear about over, and over, and over, and over again.


Our integrated Multi-Cloud product programatically automates your environment through distributed policy, custom ASICs, and integrations.


I was recently working a project where I was significantly redesigning the WAN infrastructure for a large international organization.  This organization has between 400 and 500 sites, and many different methods of potential connectivity.  The issue that we were solving was that path selection wasn’t always predictable, especially in failure scenarios, and asymmetric flows caused havoc on some of their applications.

Due to the large nature of the change, it was split up into smaller components (phases) and planned to be implemented across a rather large window in a single day.  We had a need to verify that we had a consistent environment at the end of each of each phase, before moving on to the next.  We also needed a tool to rapidly test a multitude of failure scenarios during failover/user acceptance testing.  The other requirement is that this testing happen from many perspectives.  I needed to not only verify connectivity, but that the flow of traffic in both directions was selecting a consistent path.

Because of these requirements, I decided to use TCL (eventually EEM-TCL) and run the script from the routers and switches themselves.  I used this approach, because it wasn’t practical to set up machines at each of these locations to run the script locally.  This ended up working incredibly well for our purposes and since I couldn’t find any good pre-built examples of what I was trying to do, I’ve sanitized the script and posted it for others to use.  The functional information on how it runs is on the GitHub page. Simply put, the script is pre-configured with a bunch of test targets that have ping and traceroute run against them.  Output is simplified so only relevant information is displayed and so you can quickly determine if there is an issue.  For the change referenced above, there was about 20-30 different target IP addresses (internal and external) that gave a sampling of the different types of locations/connectivity types.

In larger organizations I could see this script could also being used as a level 1 troubleshooting tool.  Run the script, and validate against a “known good” output before escalating to an upper tier.  Escalation could have a copy of the output which would potentially point to trouble areas in the network.  You could also take this script and have it run whatever commands you like.  TCL gives you some pretty powerful options for variable handling and output filtering, so this could just be a good starting point on setting up whatever validations you would like to run.

See Script Here

One of the more popular misconceptions about SDN is that this new model of networking moves the control plane from a device to a controller.  As much as it sounds like a network controller would be the control plane for a network, it simply isn’t true.  For some, I believe this mistake is simply a lack of attention to terminology.  For others, it’s a fundamental misunderstanding of the way that controller based networking works.  Either way, it’s important that we, as network engineers, understand the concept as we move into the brave new world of orchestrated networks.

Before diving in to how SDN is changing the way your network works, we need to have a common understanding of the different levels, or planes, in your network.  There are others that have been defined, but for the purposes of this conversation these three are the important ones.

  • Data Plane:  This is the physical path that a frame or packet takes while traversing the network.  It includes SFPs, interfaces, ASICs, internal fabrics, etc…  These are the purpose built networking components of a switch or a router.
  • Control Plane:  This is the part of the switch or router that decides how to move frames and packets to their destinations.  The processor on a network device is usually the central arbiter of the control plane, distributing instruction sets to the data plane for how to move packets effectively.
  • Management Plane:  This is the part of the network that a network engineer is going to be interacting with.  Traditionally this has been a CLI or a GUI that exists on the device for the purposes of being able to program the control plane to match the intent of your network design.

The Problem

So what’s the big deal?  Adding a controller to your network is moving the control plane to a centralized device, right?  Not really.  The control plane is the logic center of any network device.  It is the place where decisions get made about how to forward traffic.  Those decisions are then given directly to the data plane to carry out.  In SDN networks this does not change. Each and every device retains its own control plane and programs the individual data planes directly.  If we removed the control plane from the device, the controller would be responsible for directly programming FIBs, managing TCAM, etc… 

Why does it matter?  There are two main reasons.  First, removing the control plane from individual devices would make all of them fully dependent on the centralized controller.  If that controller were to go down, or become unavailable for any reason, the network would cease to function.  As it is, with localized control planes, a network would be able to continue on without controller availability but would be unable to facilitate any changes to traffic flows.  Second, it would be wildly inefficient.  The processors on networking devices are constantly working at managing all sorts of things.  Adding latency for centralized control would slow this management down considerably.  It’s been tried.  It doesn’t work well.

What Does SDN Change

Ultimately, an SDN controller orchestrates each of the independent control planes of your network devices to act in unison.  Is the controller making decisions about who can talk to who?  Absolutely.  However, it is not directly telling your network devices how to carry out that plan.  Instead, the controller feeds each networking device’s control plane with the information it needs to forward as desired, and the localized control plane translates that into a data plane instruction set that matches the provided intent.  This means each and every device, when presented with a frame or packet, is making a wholly internalized decision about how to forward it, utilizing the centralized view of the network that it has received from the controller.

So what has moved?  Well the management plane has moved.  In an orchestrated network, we shouldn’t be managing each device individually.  We will program the controller with our intent, the controller will then translate that to each of the networking devices control planes, which then program the data plane to act accordingly.  Many solutions leave a reduced management interface on the device for simple troubleshooting, but configuration of policy will always be done at the controller.

Final Thoughts

Whether in the datacenter or the WAN, centrally orchestrated networks are going to be playing a larger role in our environments.  Understanding how this orchestration changes things is the best way to understand how you can leverage it to improve the overall performance of your network.  I know it can feel a bit pedantic to nit-pick on control plane vs management plane, but the distinction matters and it is an important one to understand.

Network Collective

Two weeks ago I was able to announce a side project that a couple of friends and I have been working on called Network Collective.  Network Collective is a live-streamed, video roundtable, where network practitioners of all experience levels talk about the things that interest them, and hopefully the things that interest you.  Rather than explaining what Network Collective is (that’s already been done here), I want to share a bit about why I’m so passionate about it and why I believe we need something like it in the networking community.

Over the past couple years, I have been observing that highly technical conversations are moving from public to private platforms.  Quite a bit of what used to take place in the open on Twitter, and on networking podcasts, had moved to Slack channels and other private chats.  It makes sense since Twitter’s 140 character limit makes communicating complex ideas difficult.  The introduction of Slack, and other communication platforms like it, allow for a more nuanced conversation to occur.  The problem is that you have to be aware that the channel exists, and be invited to participate in it.  For those of us who are established in this community it is great, but it leaves out the up and coming and even the experienced engineers who are just joining this socially minded community of network engineers.

I know that my career trajectory changed when I was introduced to the network engineering community on Twitter (thanks again Jeff).  I didn’t understand half of the acronyms or content when I first started, but you better believe that Google was my friend.  I found inspiration in hearing my peers talk about things that I had never considered, and my perspective became broader and better informed because of it.  This public discussion satiated my innate curiosity and was the fuel that drove me to dig deeper in to this career that I had chosen.  I am the engineer that I am today because of this exposure to other peoples experiences and passions.  It bothers me to think that this environment doesn’t exist, to the same degree as it did for me, for those who are just starting down this path now.

As time went along, my involvement in this community not only exposed me to the collective experience of the network community, but it also afforded me opportunities to start dialog with some of the people I admired most.  One of the most incredible things about the public figures in the network engineering community is just how approachable they are.  From dialog, relationships and friendships have grown, and those relationships make both online, and in-person experiences like conferences, all the more rewarding.

My goal with Network Collective is to bring the technical conversation back into the public square and to build a platform where listeners and contributors alike can start dialog and build stronger relationships within the community. Sure, we’re going to have a lot of fun geeking out about the things we’re passionate about along the way, but I want those conversations to benefit the community at large rather than a smaller subset of it in the back channel.  We would love nothing more than for you to join us.  The more people that participate in the conversation, the more valuable the conversation becomes.  Our fist episode of Network Collective is going to be airing tomorrow, April 11th, at 7:00 PM EDT.  You’ll be able to watch it directly on our website:  http://thenetworkcollective.com.  If you can’t participate in real-time, the video recordings will be posted on our website after the fact.  If you want the video feed delivered directly to you, you can subscribe to our YouTube channel directly as well.  While I believe the video format better enhances the community aspect of the show, we will be releasing an audio-only feed of the episode as well.  Just search for Network Collective in your favorite podcatcher or go to our Subscription Page to find the direct RSS feed.

As a final note, I just want to express how grateful I am for the response of the networking community. When we put this idea out there, the outpouring of support was nothing short of amazing.  I would be remiss to not mention two very important people who are making this vision a reality.  Eyvonne Sharp and Phil Gervasi partnered with me the moment that the idea was introduced and are an integral part of making this happen.  We’re very excited to get this started and very much hope that you will join us along the way.  We would love to have you.

Silver Peak LoogoSilver Peak was one of seven companies brave enough to demo their product in front of the Network Field Day delegates and the rest of the networking world at NFD11 in January. Silver Peak has a decade long history of providing WAN solutions focusing primarily on WAN optimization. That focus on WAN technology makes them a natural fit to enter the SD-WAN space and their SD-WAN product is exactly what they were showing off at NFD11.

The Silver Peak SD-WAN solution is named Unity EdgeConnect and consists of X86 based software that can run on commodity hardware or virtual form factors. Like most SD-WAN products, the primary goal of the solution is to abstract multiple sources of WAN bandwidth and provide intelligent decision-making regarding which paths WAN traffic should take. Rather than spending time here detailing every feature the EdgeConnect product offers, I’m going to focus on a couple of key features that piqued my interest. By no means does this indicate weakness in the areas I am not writing about. If you are interested in a more holistic view of the product offering, I highly recommend you watch the presentation here and check out the product information that can be found on the Silver Peak website.Continue reading

CloudGenix is one of the sponsor companies presenting at Network Field Day 9. They are the very definition of a startup being less than 2 years old and coming out of stealth mode in April of 2014. The founders of the company are all former colleagues from Cisco.

The Product: Well, that’s an interesting question as there isn’t much information out there about it. Their website claims that they are developing a SDN solution for the WAN that is currently in private beta. I couldn’t find anything online that showed any technical description beyond the typical flowery wording about mapping business process/priority to network traffic flows.

SDN WAN technology is very interesting to me as I believe it is likely going to be the real driver for mass adoption of SDN. Most of the hype around SDN has had a focus in the datacenter, supporting large and complicated implementations of cloud or distributed applications. SDN in the datacenter is solving many problems that large organizations are having, but most mid-tier organizations just aren’t fighting those same battles. However, just about every organization I have encountered has had to make decisions around routing, security, resiliency and prioritization of their WAN circuits. Any technology that makes this process easier, and is capable of mapping business objectives to technical implementation, has the potential to be a catalyst of change in how WANs are deployed.

Conclusion: CloudGenix has the potential to be a very interesting product but with so little information out there about them it’s hard to tell. I imagine their presentation at NFD9 has the potential to be something that leaves us excited about the possibilities but there are just too many question marks to have a solid opinion going in. Either way, I am looking forward to hearing more about what CloudGenix is working on.

I have been logging a considerable amount of time behind the Cisco IOS CLI lately while working towards my CCIE R/S lab. I am lucky enough to have access to my own lab hardware for study but one of the things I identified fairly quickly was that resetting my devices between labs was taking a considerable amount of time. This time is non-productive as it isn’t being applied to learning new technologies but rather to the “process” of getting set up. I needed to find a way to quickly get all my devices back to a base configuration without expending a lot of time and effort. Here is what I came up with utilizing the TCL scripting engine on Cisco devices.Continue reading