The MPLS-OPS Archive

["Aries C" <cariesc@hotmail.com>]

Indeed...It's excellent.

Thanks, Martin, for spending sometime to clear my doubt from 
mis-interpretation.
I gave a wrong example for the RD below. Surely I have to use my own AS 
number within my own network. So, it should be 100:** and 100:** as you 
mentioned.

I have another question related to this in the book :

hostname San Jose
!
ip vrf EuroBank
rd 1:27
route-target export 100:27
route-target import 100:27
!
ip vrf FastFoods
rd 1:26
route-target export 100:26
route-target import 100:26


As you mentioned, the RD could be <AS number>:<any number (32 Bit)> or 
<official IP>:<any number (16 Bit)>. The book also mentioned RT as ASN:nn. 
But if you look at the above config, it seems that one of them (RD or RD) 
doesn't follow the mentioned rule.


It's likely the RT. If I am right, what's the typical rule of thumb for RT 
allocation planning? Just simply running number will do ?



TIA.


Aries C.


>From: "wanglei" <wanglei@harbournetworks.com>
>To: <MHeusinger@gmx.net>,"Aries C" 
><cariesc@hotmail.com>,<mpls-ops@mplsrc.com>
>Subject: Re: [MPLS-OPS]: Route Distinguisher Questions
>Date: Sun, 16 Feb 2003 21:21:46 +0800
>
>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
> > 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
> >


_________________________________________________________________
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