People new to MPLS VPN are often unclear on what functions route distinguishers and route targets serve, and the difference between the two. Let's see if we can clear up some of that confusion. If you could use a refresher on VRF fundamentals, I encourage you to first check out my earlier articles on the topic, Intro to VRF lite and Inter-VRF Routing with VRF Lite.

Route Distinguisher

As you know, VRFs allow IP address space to be reused among isolated routing domains. For example, assume you have to connect to three customer sites, all of which are using 192.168.0.0/24 as their local network. We can assign each customer its own VRF so that the overlapping networks are kept isolated from one another in their respective routing domains.

This works well, but we need a way to keep track of which 192.168.0.0/24 route belongs to which customer. This is where route distinguishers come in. As its name implies, a route distinguisher (RD) distinguishes one set of routes (one VRF) from another. It is a unique number prepended to each route within a VRF to identify it as belonging to that particular VRF or customer. An RD is carried along with a route via MP-BGP when exchanging VPN routes with other PE routers.

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.