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.

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.

Just a quick heads up for CCIE candidates: A reader contacted me today to point out yet another company who has ripped off my (free) content and repackaged it as their own. The offending company is a bootcamp named CCIE University, at ccieuniversity.com. They are offering my collection of free cheat sheets, stripped of attribution, to trick people into signing up for their email list. The collection being offered is the same as the cheat sheet ZIP archive (but with each file slightly corrupted due its manipulation).

The purpose of this post is not to rant about having my stuff plagiarized again (well, maybe a little), but to serve as a reminder to thoroughly investigate any training providers you're considering doing business with. There are plenty of reputable CCIE training companies to choose from providing quality materials and instruction worldwide. Don't cheat yourself by settling for regurgitated content.

I don't know if it's greed or just a complete lack of integrity which drives individuals to such tactics. I can only wonder from whom they stole the products they actually sell.

There are a variety of approaches to connecting multiple sites across a wide area network (WAN), ranging from leased lines to MPLS to IPsec VPN tunnels. Unfortunately, many of the options and potential WAN topologies are often misunderstood or confused with one another.

Point-to-Point

A point-to-point circuit, as its name implies, connects exactly two points. This is the simplest type of WAN circuit. Packets sent from one site are delivered to the other and vice versa. There is typically some amount of processing and encapsulation performed across the carrier's infrastructure, but it is all transparent to the customer.

A point-to-point circuit is typically delivered as a layer two transport service, which allows the customer to run whatever layer three protocols they want with an arbitrary addressing scheme. A customer can change or add an IP subnet in use on a layer two circuit without coordinating with their provider.

Earlier today on Twitter, I asked:

What networking concept do you wish you could go back in time and explain to your newbie self?

I received some interesting responses, ranging from understanding what purpose the OSI model serves to RIB versus FIB, from spanning tree to VRFs. Having taught a number of CCNA classes and been in a position to gauge student reactions, some of the responses were predictable. Others, like Bill's comment about not understanding the benefit of the OSI model, were intriguing.

I think that many of the knowledge gaps common in our field can be traced to a phenomenon in professional education where concepts are not thoroughly explained simply because the explainer has forgotten having learned them. An author of a book on spanning tree, for example, may be intimately familiar with the operaton of the protocol, and explain in numbing detail the root bridge election process, but fail to explain why a root bridge is necessary. I thought it would be an interesting exercise to take a casual poll along readers and see what other fundamental knowledge is commonly not well understood until one is several years into his or her career.

Back to the question at hand: For me, I think it would be IPsec. Not that I truly understand how it all works under the hood still today, but learning about IKE and ISAKMP and phase one and phase two early on was harsh. What about you?