Probably if you work in a Fairly big company, you would have heard of the the word MPLS and MPLS VPN. And if you are fair guy into networking, you often play with it. This article should be knowledgeable to both kinds of audience.
MPLS popularity has increased exponentially in the last 5 years. One of the most compelling drivers for MPLS in service provider networks is its support for Virtual Private Networks (VPNs), in which the provider’s customers can connect geographically diverse sites across the provider’s network.
First thing people confuse is the usage of the words MPLS and VPN. Both are seperate terminologies. MPLS is the protocol that runs on top of your routing protocols. And VPN is all about creating a virtual network end to end across the internet. Traditionally VPN were based on IPsec (layer 3) or TLS (layer 2) which were slow and sluggish and merely less on features. MPLS had all these points into consideration as it evolved right inside cisco labs, where it took birth. Later on, it was adopted as an industry standard in late1990s.
Enough about the history and importance, lets take a look at different types of MPLS-based VPNs
– Layer 3 VPNs: With L3 VPNs the service provider participates in the customer’s Layer 3 routing. The customer’s CE router at each of his sites speaks a routing protocol such as BGP or OSPF to the provider’s PE router, and the IP prefixes advertised at each customer site are carried across the provider network. L3 VPNs are attractive to customers who want to leverage the service provider’s technical expertise to insure efficient site-to-site routing.
– Layer 2 VPNs: The provider interconnects the customer sites via the Layer 2 technology – usually ATM, Frame Relay, or Ethernet – of the customer’s choosing. The customer implements whatever Layer 3 protocol he wants to run, with no participation by the service provider at that level. L2 VPNs are attractive to customers who want complete control of their own routing; they are attractive to service providers because they can serve up whatever connectivity the customer wants simply by adding the appropriate interface in the PE router.
– Virtual Private LAN Service: VPLS makes the service provider’s network look like a single Ethernet switch from the customer’s viewpoint. The attraction of VPLS to customers is that they can make their WAN look just like their local campus- or building-scope networks, using a single technology (Ethernet) that is cheap and well understood. Unlike traditional Metro Ethernet services built around actual Ethernet switches, service providers can connect VPLS customers from regional all the way up to global scales. So a customer with sites in London, Moscow, Hyderabad, Hong Kong, Seattle, and New York can connect all his sites with what appears to be a single Ethernet switch.
The “Virtual” in VPN is that the individual services have the appearance of being distinct, but are in fact built on a single shared infrastructure – the MPLS network. The advantage to the service provider is that he can build a portfolio of services to attract a range of customers, without significantly increasing his capital investment or operational expenses.
But it’s the “Private” part of VPN that I want to discuss. Not only must services remain distinct even though they are supported over a single MPLS network, but individual customer’s networks must remain securely separated from each other:
– Customer A and customer B, both using L3 VPNs, must not see each other’s IP prefixes. In fact their respective address spaces can overlap; for instance, both can address their networks using the same 10.0.0.0 addresses, and the service provider network keeps the customer’s prefixes separate.
– Customer C and customer D, using L2 VPNs, must not see each other’s Layer 2 addresses or any sort of connection other than to their own sites.
– VPLS customers E and F, while both “seeing” the provider’s network as a single Ethernet switch, must not have the appearance of being connected to the same Ethernet switch. That is, the virtual Ethernet switch interconnecting customer E’s sites must not be the same virtual Ethernet switch interconnecting customer F’s sites.
On the left, figure shows the key elements for creating privacy between VPNs: Individual information tables for each customer and each customer site, interconnected by individual MPLS LSPs (MPLS virtual circuits). What the information table contains depends on the type of VPN the table supports:
– The information tables for L3 VPNs contain IP prefixes and are called Virtual Routing and Forwarding Tables (VRF). VRFs are simply dedicated routing tables.
– The information tables for L2 VPNs, called Virtual Forwarding Tables (VFT), contain the Layer 2 addresses of whatever L2 technology it supports; Frame Relay DLCIs, for example.
– The information tables for VPLS contain Ethernet MAC addresses and, if VLANS are being used, VLAN IDs, mapped either to local ports or to LSPs leading to other sites. These tables serve the same role as the MAC tables in Ethernet switches.
The VPN network in the figure is simplistic; it only depicts three customers with two or three sites each. A production MPLS VPN network is likely to have at least hundreds of customers and thousands of information tables. Keeping a basic LSP structure like the one in Figure 1 would quickly lead to scaling limitations.
So rather than switch each table-specific LSP individually in the MPLS core network, LSPs are created between each of the PEs, and shown in Figure 2. The table-specific LSPs are then tunneled within these PE-to-PE LSPs, permitting much better scaling in the core; switching only must occur among these much fewer tunnel LSPs.
And that is the reason for emphasizing label stacking: It is an essential function for MPLS VPN scaling. When a PE receives an IP packet or a Layer 2 frame from a locally connected CE, it does a lookup in the local information table. If the destination of the packet or frame is to a CE at another site, it is encapsulated behind an MPLS header with the correct label for the LSP connecting to the remote information table. The resulting MPLS packet is then encapsulated behind another MPLS header, with the outgoing label of the tunnel LSP connecting to the remote PE in which the remote information table resides.
At the remote PE the outer header is popped, and the label of the inner header is examined. That label tells the PE what local information table to consult. The inner header can then be popped, and the decapsulated packet or frame can be forwarded to the locally connected CE as specified by the correct information table.
That gives you the basics of how forwarding is accomplished for MPLS VPNs. In future, I’ll discuss how the reachability information contained in the various information tables is signaled across the MPLS core to remote PEs. The core concepts of MPLS network traffic flow.
loading...
loading...