Jump to content
mashti

Understanding MPLS VPNs

Recommended Posts

PART-1

 

 

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.

There are three kinds of MPLS-based VPN:

 

- 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, Dubai, Bangalore, Hong Kong, Los Angeles, 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.

 

Hidden Content

    Give reaction to this post to see the hidden content.

 

And that is the reason for emphasizing label stacking in the last post:

Hidden Content

    Give reaction to this post to see the hidden content.

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 Part II, I’ll discuss how the reachability information contained in the various information tables is signaled across the MPLS core to remote PEs

Edited by mashti
  • Like 11

Share this post


Link to post
Share on other sites

PART-2

 

 

The last post discussed the forwarding plane of MPLS VPN networks – in particular, how they remain private by maintaining separate information tables at each PE and connecting the traffic related to each of these tables over separate LSPs.

 

But there is also the control plane: How is the local reachability information contained in each information table advertised to the other PEs?

 

Keeping in mind that one of the fundamental objectives of MPLS VPNs – and MPLS in general – is to support multiple services over a common, shared infrastructure, in makes sense that the the advertisement of local reachability information among the PEs should also be handled by a single, shared protocol.

 

And indeed it is, using BGP.

(For Layer 2 VPNs and VPLS you have the alternative of using LDP for this, but in my mind that just adds a protocol unnecessarily; using BGP to support all of the VPN functions makes more sense to me. Perhaps a discussion of the pros and cons of this would be a good follow-up post.)

 

However, using BGP commonly to communicate all reachability information among all VPNs raises a concern: If all reachability information from each PE goes into a shared BGP table and is advertised using the same BGP Update messages, how is each VPN’s information kept private?

 

And what about overlapping information? For example, Layer 3 VPN users A, B, and C might all address their networks out of the 10.0.0.0/8 private address space. Let’s say that at PE_1 users A, B, and C each have a connected site, and each of those sites are addressed out of – and individually advertise – 10.1.1.0/24. Within the local PE_1, the three overlapping prefixes are kept separate by the sites’ separate connections and separate information tables. So the 10.1.1.0/24 advertised by user A’s site is kept in user A’s VRF, the 10.1.1.0/24 advertised by user B’s site is kept in user B’s VRF, and the 10.1.1.0/24 advertised by user C’s site is kept in user C’s VRF. You get the picture.

 

But now PE_1 must advertise these three prefixes – numerically identical, but in actuality different because they belong to three different users – to all other PEs in the network, using a single BGP process. So prefix 10.1.1.0/24 is added to the BGP table from three different VRFs; to make things even more interesting, let’s say users D and E also advertise 10.1.1.0/24 from sites connected to other PEs in the network. From BGP’s viewpoint, it is just receiving five different routes to the same destination, not five different destinations. At every PE, BGP would just pick what it considers the best route to 10.1.1.0/24 and install that in all the local VRFs. That’s obviously not what we want.

 

We need to meet two requirements in order to support these overlapping addresses:

 

(1) We need an identification mechanism that takes the identical prefixes and makes them unique, so BGP does not interpret them as simply multiple reachability advertisements to the same destination.

 

(2) We need a means to set policy around the prefixes, so we can control what prefixes are accepted into what information tables.

 

The first requirement is met by using a Route Distinguisher (RD). The RD is a 64-bit value that is prepended to a prefix to associate it with a specific VPN user. The VPN service provider assigns a unique RD each user, and possibly to each user site. The RD is prepended to every prefix advertised by each user before the prefix is added to the BGP table.

 

In our example of five different VPN users advertising 10.1.1.0/24, RDs might be prepended as follows:

 

Hidden Content

    Give reaction to this post to see the hidden content.

 

You can easily see that because of the RDs, the five prefixes that were numerically identical are now unique.

 

But they are also no longer IPv4 addresses. The addresses created by prepending an RD belong to an address family called VPN-IPv4. And because BGP must advertise this VPN-IPv4 address family in addition to the default IPv4 address family, we use Multiprotocol BGP (MBGP).

 

For the second requirement, creating policies to determine what prefixes belong in what information tables, a solution might be to create VPN-IPv4 prefix filters for each local information table. But prefix filters don’t scale well operationally, particularly in the presence of hundreds or thousands of individual VPN users.

 

Filtering on VPN-IPv4 addresses also isn’t as flexible as we would like. For example, user A and user B might want to create a VPN-based intranet between them, advertising a limited subset of their mutual address spaces to each other.

 

Fortunately, BGP already has a policy tool created especially for applying flexible policies to large groups of prefixes: Communities. The BGP Communities path attribute is a “tag” that can be applied to BGP prefixes. As the name implies, prefixes sharing the same tag comprise a “community” to which some common policy can be applied.

 

Communities also provide for wide policy flexibility, because a single prefix can have multiple Communities attached to it. So you can create a policy that applies only if a specific Community is recognized, or if some combination of Communities is recognized.

 

BGP Communities also come in two “flavors”: Standard Communities are 32-bit values; Extended Communities are 64-bit values. And that brings us back to the VPN discussion.

 

MPLS VPNs use a 64-bit Extended Community attribute called a Route Target (RT). At a given PE, you create an outgoing policy that attaches an RT to prefixes advertised by a VPN user site attached locally to the PE. You then create an incoming policy at all other PEs where that user has attached sites, recognizing the user’s one or more RTs and accepting the associated prefixes into the user’s local VPN information table.

 

The difference between Route Distinguishers and Route Targets tends to be a source of confusion for many networkers, primarily because they are both 64-bit values that are formatted in exactly the same way. Each has a 2-byte Type field that specifies one of two format types: Either Type 0 or Type 1. Two fields, the Administrator field and the Assigned Number field, follow the Type field. Type 0 RDs and RTs have a 2-byte Admin field and a 4-byte Assigned Number field; type 1 RDs and RTs have a 4-byte Admin field and a 2-byte Assigned Number field. In both cases the Assigned Number field is some arbitrary number that you define; although the Admin field can also be an arbitrary number if you like, the two types allow you to make that field either a 2-byte AS number or a 4-byte IP address.

 

The important point, though, is that although RDs and RTs are the same in format they are entirely different animals performing entirely different tricks. Remember that Route Distinguishers serve only to make potentially identical prefixes unique, while Route Targets are a type of BGP Communities attribute that enable distribution of reachability information to the correct information table

  • Like 5

Share this post


Link to post
Share on other sites

JEFF DOYLE is the undisputed networking GOD.................Wish he published more books............. :rolleyes:

Share this post


Link to post
Share on other sites

PART-1

 

 

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.

There are three kinds of MPLS-based VPN:

 

- 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, Dubai, Bangalore, Hong Kong, Los Angeles, 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.

 

Hidden Content

    Give reaction to this post to see the hidden content.

 

And that is the reason for emphasizing label stacking in the last post:

Hidden Content

    Give reaction to this post to see the hidden content.

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 Part II, I’ll discuss how the reachability information contained in the various information tables is signaled across the MPLS core to remote PEs

Share this post


Link to post
Share on other sites

hi masthi,

 

thank you for your tutorial.. hope to read more knowledge about this from you.. i'm still learning and need to learn so much from you..

 

it's superb mate..

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...