Selecting shapes and connectors one-by-one in Visio can be tedious, especially when working with large or repetitive drawings. If you've been drawing for a while, you've probably gotten the hang of selecting just the right subset of shapes using the rectangular select tool, and employing the control key to add or remove any outliers as desired. This can be time-consuming though, especially when you want to pick out just a few connectors from a jumble of criss-crossing lines.
Here's a trick to try next time you find yourself excessively control-clicking: Identify each logical group of shapes or connectors that you'll likely want to tweak, and bundle them up into to their own layer. You can then use Visio's "select by layer" option to grab them all at once later. Take the drawing below, for instance.
Regular readers no doubt have noticed that I haven't posted anything new in the past few months. I've been pretty busy with the holidays, home projects, and adjusting to a new job, and haven't had much time or motivation to devote to writing. Good news though: I have started on a long-overdue refresh of the Packet Life design and code base.
When I originally debuted Packet Life, I ultimately wanted it to serve as major community hub, so I built in features like the wiki and discussion forum. Although Packet Life has grown quite popular over the last few years, these areas of the site have seen little activity. Acknowledging that there are more active and useful sites out there which serve these functions, I've decided to chop off some of the bloat in favor of focusing on the blog and the site's other more popular features.
Here's the fate I've outlined for each function of the site:
Blog: The blog is the heart of the site and will remain mostly unchanged, albeit refreshed and optimized. I'm considering allow guest posts but haven't committed to the idea.
Lab: No, there are no plans to bring the community lab back online in the immediate future. Sorry. And if it is revived, it will move to LabKeeper.net (once I get back to work on that site).
I've been selling physical copies of my 36x24" IOS Interior Routing Protocols poster for a while now. Unfortunately, Google Checkout is going the way of Google Reader next month and soon I will no longer be able to accept payments. Thus, October 31st will be the last day to order copies of the poster.
The PDF will of course remain freely available for download if you'd like to print the print poster yourself after the deadline.
VRFs are an excellent tool for maintaining segregated routing topologies for separate customers or services. I've previously covered inter-VRF routing using route targets, but what if we only want to export a subset of the routes within a VRF? Here's a scenario in which this would be desirable.
Customers A and B each have a site network and a colocation network, and both customers need access to the 192.168.0.0/24 network in the Services VRF. The customers must utilize unique IP space in order to prevent overlapping networks, so each customer has been allocated dedicated IP space from their common provider out o 10.0.0.0/8. Unfortunately, customer A is still has some networks within the 172.16.0.0/16. These networks need to access services in the host colo, but the service provider can't allow this space to be advertised into the Services VRF as it's not approved IP space.
Our goal is to export only the networks within the 10.0.0.0/8 space from the customer VRFs to the Services VRF. How can we accomplish this?
Let's have a look at the initial network state. (This lab was performed using a single router for simplicity. In the real world, these customers would typically be connected via an MPLS VPN.) Each customer and colo network has its own VRF and dedicated route target (RT). The Services VRF has been configured with an import/export RT pair for scalability reasons. No export among VRFs has yet been configured.
It's been nearly a year since I had to take the community lab offline to relocate my home, and I still get frequent emails asking when it will be returned. Sadly, my plan to host it with my current employer didn't pan out, and I'm still searching for a suitable host in the Raleigh-Durham, North Carolina area. (If you might be able to give the lab a good physical home, please let me know!)
I also get a lot of emails asking if I can share the scheduling application I used to make the lab available. In short, no, I can't. Not because I don't want to or because it's secret, but simply because that code was written specifically for the packetlife.net site and is not in the least bit portable. But these requests got me thinking: A lot of people obviously would like to be able to share their labs, they just need a platform. Maybe I could rewrite and improve upon the scheduling application to spin it off as its own service.
If you follow me on Twitter, you may have caught one or two references to a new project recently. Indeed, this is exactly what I've been working on for the past couple months during my precious free time: A centralized authentication and scheduling service people can use to make their own training labs available to friends, coworkers, or the general public. I call it Labkeeper.
A while back, I set about developing a modest configuration templating system for my employer. When I first joined the company, new network devices were being provisioned using configuration templates stored as Microsoft Word files, which, as you can imagine, was pretty painful. Each variable had to be identified and replaced by hand in a tedious and error-prone process. I wanted something better, but also cheap (or free) and simple. So I started building something.
To kick off my crazy project, I first decided to build a web application based on the Django Python framework (the same platform on which PacketLife.net runs). Django and similar frameworks handle most of the mundane tasks involved in writing a web application and allow for rapid prototyping. It also includes a built-in administration interface for creating and manipulating data independent of the front-end user interface. I spun up a modest internal VM running ...
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.
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.
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.