I was introduced to the concept of Virtual Private Networks (VPNs) quite a while back, I can’t even remember when that was; I must have been in my teens then. I am strictly speaking about remote-access VPNs, such as PPTP, L2TP/IPsec, and OpenVPN. I was enamored by the idea that a device on a remote network can connect remotely to a local gateway and appear as though they were actually on the local network. The first idea that came to mind (back then) was a VoIP-based application where you can be in one place, yet appear to be calling from a totally different place.
Shortly after, and as my intrigue developed in the subject, I began to consider what it would be like for an entity/company to be dispersed across multiple locations, and yet still be able to connect them to one another with such a type of technology, which then led to the question of who would be the server, and who would be a client, and why. The solution didn’t make sense (or I just didn’t find it logistically efficient) and thought that I want something more along the lines of a site-to-site VPN, without necessarily having a client and a server, but rather two sites connecting to one another, appearing as one unified network. That’s when I came across IPsec (minus the L2TP part) and its capability to implement such a topology.
All this was great and dandy, until I came to yet another realization… “So we need to set up a point-to-point connection for every single location?” (Otherwise known as a full mesh) That all seemed pretty impractical, especially that you had to sit there and worry about an exponentially growing number of connections with every additional location. A while (couple of years) later after having delved into multiple other topics, I came across this topic once more, and decided to do some research. Next thing I knew, I struck gold! MPLS VPNs!
The MPLS VPN network architecture is a rather elegant one that depends on the inter-functionality of a number of networking mechanisms. Once set up and configured correctly it poses a platform architected for security, multi-tenancy, and scalability. Furthermore, a relatively well-defined line is placed between the service provider and the client networks. Even the terminology used to define the different nodes in the network is descriptive of the role and jurisdiction of each device. There are three main names to consider really, the Customer Edge (CE) node(s), the Provider Edge (PE) node(s), and the Provider (P) node(s). The CE nodes reside at, well, the customer locations; the PE nodes reside at the edge of the network of the service provider, and the P nodes are located at the core of the service provider network. When you read about it in more detail you begin to see that the service provider network can be visualized as an island (the P nodes), surrounded by gatekeepers/ports (the PE nodes) that control what goes in and out, where to, and how. I developed a well-founded understanding of this architecture, however I never really appreciated it fully until I was actually able to configure it, and see it put to work. This didn’t happen until years later though… and by years later this brings us to now.
As I mentioned in a previous post, I began my journey to becoming a CCIE about a week ago. When I first started studying for the Cisco certification track (just about a year prior) one technology that I was extremely excited to learn more about was the MPLS VPN network architecture. 10 months and 5 exams later, I still did not even come across the topic being mentioned in the study material – ok, maybe just once or twice in passing. So as I had achieved my CCNP-level certification, and began my CCIE studies, I decided to jump right into it, because I was getting restless. I wanted to know how this monster is configured… until I finally found it! I instantly set up a lab and began to get to work deep diving into the subject matter.
One thing that I had come to appreciate from all the certifications that I was doing is that when you get right down to it, and begin the configuration process you have to ask yourself a number of questions about the task at hand that you probably wouldn’t have even thought of, had you not tried to configure it yourself. And so accordingly, even though I understood the technology pretty well by now after all the reading that I had done, practically putting it all together was an experience on its own.
When I started writing this blog post I didn’t expect it to get too long, but then as I started writing the ideas just kept on flowing. So I’m following up this post with a series of other posts that revolve around different MPLS VPN architectures that I have come across.