The MPLS-OPS Archive

[Ajay Simha <asimha@cisco.com>]

On Sun Feb 16 21:21:46 2003, wanglei wrote:
> Martin's explaination is so good ^_^
> 
> ----- Original Message ----- 
> From: "Martin Heusinger" <MHeusinger@gmx.net>
> To: "Aries C" <cariesc@hotmail.com>; <mpls-ops@mplsrc.com>
> Sent: Sunday, February 16, 2003 8:29 PM
> Subject: Re: [MPLS-OPS]: Route Distinguisher Questions
> 
> 
> > Hi Aries,
> > 
> > to answer your questions:
> > 
> > Route Distinguisher (RD) has only one purpose: make IPv4 prefixes globally 
> > unique. MPLS VPNs are based on the distribution of routing information of 
> > IPv4 prefixes. Now customers may all use private IP addresses (RFC 1918). 
> > To be able on a PE to distinguish between f.e. 10.0.0.0/8 from one customer 
> > to 10.0.0.0/8 of another customer one adds the Route Distinguisher. In 
> > Multiprotocol BGP the PEs are routing VPNv4 prefixes, i.e. VPNv4=RD+IPv4. 
> > There is no other special meaning to the RD than to make addresses globally 
> > unique. Especially RD has nothing to do with VPN membership.
> > 
> > VPN membership is solely determined through import and export rules based 
> > on Route Targets (RT). Those are extended communities attached to VPNv4 
> > prefixes. One VPNv4 prefix may have one or many different RTs attached to 
> > it, i.e. a IPv4 prefix may be seen in one VPN or in many VPNs or customer 
> > locations.
> > 
> > In a first approach you might say an RT identifies a VPN. A customer site 
> > is part of several VPNs, when it´s IPv4 prefixes (f.e. 10.0.0.0/8) can be 
> > reached within several VPNs. This CAN be achieved by attaching the 
> > respective VPN-RTs to the VPNv4 prefixes in every PE a customer site is 
> > connected to.
> > (I am aware, that there might be different usages for RT, like in central 
> > services VPN, but as an MPLS instructor my experience is, that this 
> > approach is the most simple and understandable one "for the beginner").
> > 
> > You can think of VRFs as a virtual Router the customer Edge router (CE) is 
> > attached to. Within one PE very VRF has to have a unique RD. IF a customer 
> > has two CEs (CE1, CE2)with the same connectivity requirements connected to 
> > the same PE you could use ONE VRF in the beginning. This VRF would have a 
> > routing table with all the IPv4 prefixes to be seen by the two customer 
> > sites.
> > Now assume a more complex VPN topology. F.e. CE1 might be part of 

Another good example of where a single VPN needs two RDs is hub and spoke:



spoke1----------------------------------------+          +------CE1
                                              | vrf1     |       |
                                              +--Hub-----+      FW
                                              +--Router--+       |
                                              | vrf2     |       |
spoke2----------------------------------------+          +------CE2
                                              

In the above case spoke1 can only speak to spoke2 through the hub router. Which has two
outgoing (physical or logical) interfaces towards ce1 and ce2. It exports the routes it learnt
the spokes to say ce1 and ce2 learns about it through the firewall/central app. vrf2 learns
it from ce2.

For this you need two RDs for vrf separation even though they may be serving VNP-X for customer
X.

-ajay 


> > additional VPNs, whereas CE2 is not. This clearly means, that CE1 should 
> > see a different set of IPv4 prefixes than CE2. This means one needs TWO 
> > VRFs one for CE1 and one for CE2. So there have to be two RDs as well. 
> > Starting with the simple approach of one RD for all VRFs a customer is 
> > attached to, this means to create a new VRF (with a unique RD) and to 
> > reconfigure the PE. This leads to a network outage. for at least one CE.
> > 
> > 
> > now on to your questions:
> > 
> > 1. is definition RD per VRF : all RDs are unique regardless which VPN it 
> > belongs to ?
> > Yes, this is the most flexible setup. VPN membership can be easily changed 
> > by adding or removing RTs
> > 
> > 2. Is definition RD per VPN : one RD is used acrossed all VRF belongs to a 
> > VPN ?
> > Yes, this can be used in a "simple VPN" scenario, i.e. all customer sites 
> > have connectivity to each other.
> > 
> > 3. Why the paragraph mentions RD per VRF is more recommended ( because 
> > configuration conflict and reduce the memory requirements), as compared to 
> > RD per VPN ?
> > The answer is: RTs are BGP communities. Changing/manipulating them is 
> > rather simple. To change the RD (in Cisco routers) one has to delete the 
> > VRF and to add it again. This means a lot of work and network outage.
> > 
> > 4. Can I use RD per VPN, though a site could belong to multiple VPN. 
> > Because theoritically, we can use Route Target to control export and import 
> > (again the uniqueness is taken care with RD, and also different VPN has 
> > different RD anyway i.e. VPN A = RD 100:27 and VPN B = 101:27).
> > 
> > No. VPN and RD have nothing to do with each other. Also PLEASE: the 
> > official RD format is <AS number>:<any number (32 Bit)> or <official 
> > IP>:<any number (16 Bit)>!! Using any different numbering scheme is like 
> > using "unofficial" IP addresses! DO NOT DO THIS!
> > Use 100:27 and 100:28 IF AND ONLY IF your official AS number is 100.
> > 
> > The confusion about RD and RT and their usage is unfortunately pushed by 
> > the fact, that RT has the same format.
> > 
> > Hope this helps more than it confuses ;-)
> > 
> > Martin
> > 
> > P.S.: The book is right, Ivan understands the matter :-)
> > 
> > On Sun, 16 Feb 2003 08:58:10 +0000, Aries C <cariesc@hotmail.com> wrote:
> > 
> > > Hi All,
> > >
> > > I m reading a book of Ivan Pepelnjak's book (MPLS and VPN Arch.)
> > > At page 191 Chapter 10, there's 3 paragraph get me confused :
> > >
> > >
> > > "Each VRF within the PE router configuration needs to have an associated 
> > > RD, which might or might not be related to a particular site or VPN 
> > > membership of that site. In the most common case, where a site belongs 
> > > only to one intranet VPN, it's technically possible and recommended, to 
> > > use unique RD for the VPN. However, if this site at some point in the 
> > > future will become a member of an extraner VPN, do not take this approach 
> > > because it might incur config. issues when trying to provision the 
> > > extranet VPN.
> > >
> > > For example, suppose a different RD is used for each VPN. If a particular 
> > > site wants to be a member of multiple VPNs, it's not possible to to 
> > > identify which route distinguisher to use for the site because it belongs 
> > > to more than one VPN.
> > >
> > > Therefore, for network topologies other than simple intranet model, use 
> > > the same route distinguisher per VRF, rather than per VPN, to avoid this 
> > > type of conflicting config. and to reduce the memory requirements of the 
> > > PE router. In the case of an extranet VPN, this means the VRF that makes 
> > > up the VPN uses the same RD regardless of the particular VPN site to 
> > > which the VRF belongs. "
> > >
> > >
> > > The question are :
> > >
> > > 1. is definition RD per VRF : all RDs are unique regardless which VPN it 
> > > belongs to ?
> > > 2. Is definition RD per VPN : one RD is used acrossed all VRF belongs to 
> > > a VPN ?
> > > 3. Why the paragraph mentions RD per VRF is more recommended ( because 
> > > configuration conflict and reduce the memory requirements), as compared 
> > > to RD per VPN ?
> > > 4. Can I use RD per VPN, though a site could belong to multiple VPN. 
> > > Because theoritically, we can use Route Target to control export and 
> > > import (again the uniqueness is taken care with RD, and also different 
> > > VPN has different RD anyway i.e. VPN A = RD 100:27 and VPN B = 101:27).
> > >
> > >
> > > Could anyone educate me on this.
> > >
> > >
> > > TIA
> > >
> > > Aries C.
> > >
> > >
> > >
> > >
> > >
> > > _________________________________________________________________
> > > Hotmail now available on Australian mobile phones. Go to  
> > > http://ninemsn.com.au/mobilecentral/hotmail_mobile.asp
> > >
> > > -------
> > > The MPLS-OPS Mailing List
> > > Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> > > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
> > >
> > >
> > 
> > 
> > 
> > 
> > -------
> > The MPLS-OPS Mailing List
> > Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
> > 
> 
> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml