The MPLS-OPS Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Re: Route Distinguisher Questions
Aries, there are different point of views. The MPLS VPN architectual point of view would be to follow the mentioned numbering scheme. >From a PEs point of view any RD or RT would do ... they are just different bit pattern. >From an operational point of view AS:<Customer number> for RD and AS:<VPN number> might be a good approach. Though this could be different for any real world Provider involved. >From an educational point of view the example in the book is preferable, as it minimizes the confusion arising from the fact, that RD and RT look the same. Using them with totally different numbers makes it more simple for students to see where which of them is used. So in the book the educational point of view may take precedence, for a real world Provider a different numbering scheme may be advisable. Whatever scheme is applied, please note: the RT is a BGP extended community. So it can be changed at any router, f.e. through a route map. So RT nummber assignment is not so critical. However the RD can not be changed so easily. This is especially important, when considering Inter-AS MPLS VPNs. You may compare this with a company accessing the internet. Inside the companies network any IP addressing could be applied (and very often is!). The Internet however does not allow you to use any other address than the "official" ones. The result is NAT all over the place in many companies at the internet gateways. Comparable to NAT would be changing RTs for VPNv4 prefixes at the MP BGP peering points. (Be aware however: NAT operates on the data plane, whereas changing RTs is operating on the control plane). There is no such thing like "VPNv4 NAT", i.e. replacing RDs! So choosing the RD is the critical part of any real implementation. kind regards Martin On Sun, 16 Feb 2003 14:08:34 +0000, Aries C <cariesc@hotmail.com> wrote: > 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 > > -- Dr. Martin Heusinger Consulting Manager Central European Region CCIE #5980 CCSI 98285 Global Knowledge Hungener Str. 6 60389 Frankfurt Tel.: +49 69 90556700 FAX: +49 69 90556729 mailto:Martin.Heusinger@GlobalKnowledge.de web: www.globalknowledge.de ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
|
|