Re: basic mpls doubts

Hi Imran,

A customer may want VRF lite is having two services delivered on the same
access needing logical separation. A common example is having an IP-VPN
service from the Service Provider and an Internet Access tail from the same
Service Provider delivered on the same ethernet access separated by VLAN at
a major site like a head office.

Keeping these separate can allow the deployment of a firewall that has one
leg in the internet VRF and one in the ipvpn VRF (possibly on the customer
LAN segment) that is reachable via the rest of the IP-VPN without needing a
lot of complex (read hard to provision and troubleshoot) access lists or
routing policies to keep things separated if everything was in the same
routing instance. Alternatively the customer would need a front end switch
to split services to their internet router and vpn CE router, so vrf lite
could be seen as a method to reduce cost (less boxes) and increase
flexability.

The RD can be different between the customer and the SP (remember the
purpose of the RD is to provide a prefix infront of the routes to help
support IP address overlapping) - it is quite likely that neither the CE nor
PE will be the wiser as what RD values are being used (if you're using BGP
it would be a plain ipv4 unicast address family peering and if I remember
correctly those particular extended communities will not be propogated by
default)

Cheers,
Adam

On Mon, May 16, 2011 at 11:16 PM, imran ali <immrccie_at_gmail.com> wrote:

> Dear all
>
> why would a customer wnats to have VRF lite feature ? what advantage will
> he
> gets using vrf lite. ?
>
> in vrf lite senario does RD of a ce-VRF match with Rd of pe -vrf ?
>
> i mean to ask can the VRF of CE AND PE HAVE DIFFERENT RD BELONGING TO SAME
> VPN ?
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Tue May 17 2011 - 09:50:22 ART