Lots of great things have been happening with Network Collective lately, but I wanted to call attention to a big announcement that we made yesterday on the show. Network Collective is going to be offering two new membership tiers for our listeners. We talk about it in quite a bit of detail on the latest episode, but figured I would write out the whole story here for those who may have missed it.

Let’s start with why we’re doing this.

There’s two primary reasons why we wanted to go down this path. The first has a lot to do with our identity as a show and what we want to provide in the network engineering community, and that is mentorship. There’s a lot tied up in that word but we feel network engineers are often left on an island in the organizations that they work for. Even with peers within an organization, the scope of what you can learn is usually limited to the things you deal with day to day.

We want to change that by building a community for networkers where they can come to learn new things, develop new and vital skills, build a broad personal network, and ultimately take the next steps in their networking career. Network Collective is lucky to have access to world class networkers who want to share their experience and knowledge with you.

The second reason for this approach is a bit more functional for us. While we appreciate and respect the vendors that build the equipment and software we work on, we also recognize that our value to the community is dependent upon us retaining and independent voice. Advertising doesn’t inherently change that independence, but becoming fully dependent on it does. By offering subscription options we allow our listeners to participate in keeping Network Collective independent of vendors and manufacturers to keep the show going.

What exactly are we offering?

We’re offering our listeners two tiers of membership:

Supporter

The supporter tier is for those who want to help us keep an independent voice or just generally support the show. Maybe you don’t need the exclusive content or mentorship that we can provide, but you like the content we produce and can help us keep it going by sending a few dollars a month our way. As a thank you for supporting us in this way, we will give you access to all of our content without any advertising included.

Price: $5.00/month with no commitments

Community Member

A community member will receive a number of additional benefits not received by the general public or supporter tier of membership.

Exclusive Content

The first and primary benefit will be exclusive Network Collective content created just for you. This content will look familiar, being delivered in both podcast and short take formats, but will focus on training, development and mentorship in a much deeper way than we can on the public podcast channels. We’re committing to two additional podcast and three additional short takes every month, but that by no means is a limit on what you can expect to see added in this section monthly.

Live Expert Q&A

In addition to exclusive podcast content, we’ll be arranging a monthly live question and answer session with a distinguished guest contributor. This is an opportunity for you to directly engage with leading experts in our field and to actively participate in the conversation.

Network Collective Member Slack

Becoming a Network Collective Community Member will also get you access to the invite-only Network Collective Membership Slack. In this group you can engage with your peers and the hosts of Network Collective on the topics that matter to you.

Ad Free Content

As a Community Member, you will receive all the same benefits as a Supporter. This includes access to ad-free versions of all publicly available content.

Price: $250.00/year

What’s changing with the public feed?

Absolutely nothing. We’ll continue to produce Community Roundtable, History of Networking, and Off The Cuff episodes of Network Collective, just like we always have. These will never be moved behind a registration or pay wall. If you choose not to pay for either of our subscriptions methods, we will support this content with advertising.

Who is this for?

This is for anyone who could use some training, guidance, mentorship, or a solid community focused around network engineering.

Who is providing the content?

Russ, Eyvonne, and myself will be doing a fair amount of content production for this membership site, but we won’t be alone. Part of the benefit of a site like this is that we can now offer a great place for knowledgeable engineers to offer their insight and knowledge, and get paid for doing so. We’re big believers in making sure content creators are fairly compensated for their knowledge and effort, and this is what a portion of your subscription amount is going to pay for. We’ll be bringing in experts from many different disciplines to talk about technology and the other skills required to be good at what you do.

So when does all this happen?

We’re launching the membership site on June 1st. You’ll start seeing some changes on the Network Collective site over the next couple weeks in preparation for these changes.

Final Thoughts

I hope this answered any questions that you might have had. If you want to hear us talk about the membership site, you can listen to the second half of the episode I’ve embedded below. If you have any more questions you can leave me a comment here, hit me up on twitter, send us a comment via Network Collective, or find me/Network Collective on any of your favorite social media sites. We hope you’ll join us when we get things rolling on June 1st.

Ep27 – State Of The Podcast from Network Collective on Vimeo.

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 event-driven Linux Foundation product predectively simplifies your infrastructure through workbooks, DevOps, and RESTful APIs.

 

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