A couple months ago, I announced a proposal to start a Stack Exchange site dedicated to answering questions concerning network engineering, similar to how Stack Overflow and Server Fault cater to the concerns of programmers and systems administrators, respectively.

I'm happy to announce that the proposal has made it through the definition and commitment phases and last week was opened as a public beta site at networkengineering.stackexchange.com! The beta process is critical for shaping the content and style of the site, so the more people use it the better we can refine and nurture its content.

Why a Stack Exchange site? The platform has proven immensely useful for directed troubleshooting and answering targeted questions. As opposed to discussion forum threads, which often digress into tangents and off-topic conversation over the course of days or weeks, the streamlined question-and-answer format of the site leverages community feedback and voting to promote what is accepted at the best answer (which the asker can optionally confirm). This medium is much better suited to questions which can be directly answered (e.g. "How can I...?" and not "What's the best...?"); please keep this in mind if you decide to participate in the beta.

Check out the beta!

Most readers are probably familiar with the switchport analysis (SPAN) feature on Cisco's Catalyst switches. SPAN replicates all ingress and/or egress traffic from one or several interfaces to another for the purposes of packet capture or traffic monitoring. This is especially helpful when deploying a network-based IDS. Unfortunately, it's often not possible to install the IDS on the same physical switch as the ports from which you want to capture.

Remote SPAN (RSPAN) can be employed to extend a SPAN session between source and destination points on disparate switches, however it requires a layer two path end-to-end. When we need to replicate layer two traffic across a layer three network, we turn to encapsulated remote SPAN (ERSPAN). ERSPAN transports traffic inside a point-to-point GRE tunnel between arbitrary IP endpoints.

For this lab, we'll configure an ERSPAN session from an NX-OS source (a Nexus 7K) to an IOS destination (a Cisco 7600) to provide an example configuration for both platforms. MPLS transport is used between the two switches and routing of the ERSPAN tunnel will take place inside a VRF named Capture.

If you follow any number of news feeds or vendor accounts on Twitter, you've no doubt noticed the term "software-defined networking" or SDN popping up more and more lately. Depending on whom you believe, SDN is either the most important industry revolution since Ethernet or merely the latest marketing buzzword (the truth, of course, probably falls somewhere in between). Few people from either camp, however, take the time to explain what SDN actually means. This is chiefly because the term is so new and different parties have been stretching it to encompass varying definitions which serve their own agendas. The phrase "software-defined networking" only became popular over roughly the past eighteen months or so.

So what the hell is it? Before we can appreciate the concept of SDN, we must first examine how current networks function. Each of the many processes of a router or switch can be assigned to one of three conceptual planes of operation:

• Forwarding Plane - Moves packets from input to output
• Control Plane - Determines how packets should be forwarded
• Management Plane - Methods of configuring the control plane (CLI, SNMP, etc.)

For example, you might SSH into the CLI of a router (the management plane) and configure EIGRP to exchange routing information with neighbors (the control plane), which gets installed into its local CEF table (the forwarding plane). All of these operations occur within the same device, and each node in the network operates autonomously to make its own forwarding decisions based on its local configuration. It's critical to recognize that, although this allows for highly dynamic and automatic forwarding decisions through the use of robust protocols, the end result is ultimately dependent on each node's independent configuration. For the purposes of establishing context, we can think of this as administratively-defined networking.

I came across an interesting problem today that I think serves as an excellent example of why packet analysis is such a critical skill for network engineers.

A few days ago, the internal network belonging to one of my employer's customers was compromised by a malicious party. Since the customer had connectivity into our network by way of a VPN tunnel and we didn't want to knowingly expose ourselves or other customers to the threat, we saw fit to temporarily sever the VPN while the breach was tended to by another party. We also upgraded the site's core switch to better support a feature useful in the analysis of the breach.

Shortly thereafter, we began receiving reports of problems with Internet connectivity from the site. Everything was reachable, it was just... slow. And worse, the issue seemed not to have any uniform effect: One person experiencing the issue might sit next to someone else who was completely immune and who noticed no difference from the day before. This of course made troubleshooting frustrating, to say the least.

First we tried reversing the firmware upgrade on the core switch, as it was reasonable to suspect we may have encountered some obscure bug, but this was quickly revealed to be a red herring as the issue persisted. On-site engineers verified that they could still reach everything (excluding of course our internal resources which were no longer reachable as a result of severing the VPN) and speed tests showed mostly normal results. There was no correlation between affected users and any access switch, VLAN, or IP subnet. We also confirmed about seventeen times that Internet traffic was in fact traveling from end hosts through the firewall directly to the Internet, with no proxy or caching servers in between.

Today marks the five-year anniversary of my first post on Packet Life. (Funny, it doesn't feel like it's been that long.) Those of you who follow the blog regularly no doubt have noticed that I don't post as often as I used to. Several factors contribute to this, probably the largest of which has been the increasing burden and tedium of my day job. My wife and I also relocated here to the Raleigh-Durham area of North Carolina last year, so getting settled has eaten up a good amount of time over the past months.

Rather than rehashing the past year, I thought it would be interesting to discuss what's coming up in the near future. We've seen quite a number of new technologies and ideas pop up recently, so many in fact that I've been having a difficult time keeping sense of it all. Here's my take on what will be big in our world over the next few years.

Software-Defined Networking (SDN)

The functions of any network device can be assigned among three planes of operation: control, forwarding, and management. Traditionally, routers and switches (or switch stacks) have been deployed as autonomous units which operate independently on all three planes. A router, for example, might be configured via SSH (management plane) to learn routes via OSPF (control plane) which are then installed in its forwarding table (forwarding plane). Software-defined networking (SDN) is a broad term which refers to offloading the functions of the control and management planes from individual devices to a centralized controller.

If you've spent any time writing code, you've undoubtedly come across Stack Overflow, a question and answer forum dedicated to the discussion of computer programming which has become quite popular in recent years. Its popularity led to the formation of the Stack Exchange network of sites with a similar format focused on various other topics ranging from systems administration to English grammar to LEGO. But nothing for us networkers.

What's particularly interesting about Stack Exchange is that anyone can propose a new site. Poking around, it seems that a networking-oriented site has been suggested at least once in the past but was dismissed as overlapping with the sysadmin-focused Server Fault site (which, with respect to our IT brethren, is simply rubbish). I think a networking-focused Stack Exchange could do quite well, and a lot of folks on Twitter agreed.

I've created a proposal for a networking site and I'd like your help in getting it spun up. The deal is that we need 60 followers and 40 highly-rated (10+) questions to move the proposal from the definition phase to the commitment phase. Considering the size of the community here, I'm sure we can meet these numbers in no time. If you're interested, please sign up as a follower and help make this a reality!

Update: The proposal was briefly closed as a duplicate of Server Fault as describe above, but Robert at Stack Exchange was sympathetic to my pleas and the proposal has been reopened for development. Let's prove that us networkers are too big a deal to share ground with server folk!

Update 2: We've reached the commitment phase in just three days! That has to be some kind of record. Now, we just need people to commit to being active (writing questions and answers) for the beta site to launch, essentially signing a petition. We can really use people who are already active on other Stack Exchange sites, so please spread the word to friends and colleagues in sister fields.

Update 3: Thanks to all your support, the proposal has been accepted and a beta site is in the works! A successful beta trial is the last step in the process of founding a new site, so continued support and involvement is critical.

Update 4: After just nine days the site is now in public beta at networkengineering.stackexchange.com! Everyone is welcome to join and contribute.