Jump to content


7
[Tutorial]

Understanding MPLS VPNs



25 replies to this topic

#1 mashti

mashti

    Microsoft TE

  • Technical Expert
  • PipPipPipPipPipPip
  • 1552 posts
  • 38336 thanks
  • LocationActive Directory Inside

Posted 16 September 2010 - 08:31 PM

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.

Posted Image

Figure 1 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 of Figure 1 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.

Posted Image

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 in the last post:
http://www.networkworld.com/community/node/24420
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, 16 September 2010 - 08:33 PM.

Whenever death may surprise us, let it be welcome if our battle cry has reached even one receptive ear and another hand reaches out to take up our arms.
I know you are here to kill me. Shoot, coward, you are only going to kill a man.


Che Guevara

Thanked by 97 Members:

#2 mashti

mashti

    Microsoft TE

  • Technical Expert
  • PipPipPipPipPipPip
  • 1552 posts
  • 38336 thanks
  • LocationActive Directory Inside

Posted 16 September 2010 - 08:33 PM

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:

 -	   User A, at  site 1:			 1:1:10.1.1.0/24
 -	   User B, at  site 1:			 2:1:10.1.1.0/24
 -	   User C, at  site 1:			 3:1:10.1.1.0/24
 -	   User D, at  site 2:			 4:2:10.1.1.0/24
 -	   User E, at  site 3:			 5:3:10.1.1.0/24

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
Whenever death may surprise us, let it be welcome if our battle cry has reached even one receptive ear and another hand reaches out to take up our arms.
I know you are here to kill me. Shoot, coward, you are only going to kill a man.


Che Guevara

Thanked by 30 Members:

#3 Jmed

Jmed

    Junior Member

  • Members
  • PipPip
  • 1 posts
  • 2 thanks

Posted 25 January 2011 - 10:03 PM

thankyou for sharing.....

Thanked by 2 Members:
panguila , dejavue

#4 Joe

Joe

    Advanced Member

  • Members
  • PipPipPip
  • 276 posts
  • 157 thanks

Posted 30 January 2011 - 08:04 AM

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

Thanked by 2 Members:
jobinbao , mmsaqiby

#5 jungle_boy

jungle_boy

    Member

  • Members
  • PipPip
  • 46 posts
  • 1100 thanks

Posted 19 February 2011 - 06:13 AM

Thnx alot for tha share ,really very usefull.

#6 cisconoshut

cisconoshut

    Junior Member

  • Members
  • PipPip
  • 4 posts
  • 4 thanks

Posted 26 February 2011 - 02:24 AM

thank you
cisconoshut, proud to be a member of IT Certification Forum since Oct 2008.

#7 sakis

sakis

    Advanced Member

  • Members
  • PipPipPip
  • 60 posts
  • 879 thanks

Posted 27 February 2011 - 08:38 PM

thank you mate  :rolleyes:

Thanked by 2 Members:
mmsaqiby , tipawi

#8 rat30

rat30

    Member

  • Members
  • PipPip
  • 15 posts
  • 2 thanks

Posted 02 March 2011 - 06:08 PM

thx
good post

#9 kadm

kadm

    Junior Member

  • Members
  • PipPip
  • 7 posts
  • 143 thanks

Posted 06 March 2011 - 08:27 AM

View Postmashti, on 16 September 2010 - 08:31 PM, said:

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.

Posted Image

Figure 1 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 of Figure 1 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.

Posted Image

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 in the last post:
http://www.networkworld.com/community/node/24420
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


Thanked by 11 Members:
adrianst303 , MaHdaPuH , Ronger , ozainkhan , tekuboy , Namnam , abdelazizsaidu , anoop , tipawi , Sridharp , farhan77

#10 hc08

hc08

    Junior Member

  • Members
  • PipPip
  • 1 posts
  • 1 thanks

Posted 15 June 2011 - 11:10 PM

Superb!!

#11 soryo

soryo

    Junior Member

  • Members
  • PipPip
  • 5 posts
  • 3 thanks

Posted 19 November 2011 - 05:35 AM

thanks alot

#12 Ptasha

Ptasha

    Junior Member

  • Members
  • PipPip
  • 7 posts
  • 1175 thanks

Posted 04 December 2011 - 01:27 PM

Very informative. Thank you.

#13 myuddin

myuddin

    Junior Member

  • Members
  • PipPip
  • 1 posts
  • 0 thanks

Posted 26 December 2011 - 08:45 PM

Thanks for this valuable information.

#14 djmckc

djmckc

    Junior Member

  • Members
  • PipPip
  • 7 posts
  • 42 thanks

Posted 17 June 2012 - 03:00 PM

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..
djmckc, proud to be a member of IT Certification Forum since Oct 2008.

Thanked by 2 Members:
dejavue , ixohoxix



0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

Organization

Community

Downloads

Test Providers

Site Info


Go to top