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.