The MPLS-OPS Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] RE: Route Distinguisher Questions
Big Thanks for that all Martin. Now that the coin has dropped for me on the RD RT issue... on to the next thing. regards, Dana -----Original Message----- From: Martin Heusinger To: dwk@danakonkin.com; mpls-ops@mplsrc.com Sent: 19/02/03 12:39 Subject: Re: [MPLS-OPS]: Route Distinguisher Questions Dear Dana, you are quite correct with your summary! May I cite you in future? :-) The merit of RD = RT ... none for the routers, these are just two Bit patterns, that are coincidentally the same (but will never be compared!). But MAYBE it´s more simple for us humans being in charge of configuring and trouble shooting a real world installation. On the other hand this thread proves this to be an optimistic assumption ;-) kind regards Martin On Wed, 19 Feb 2003 06:28:21 -0500, <dwk@danakonkin.com> wrote: > Many thanks Martin, > > > If I may take this a step further... > > > > Would the following summary be correct and adequate to describe the > funnction of RT and RD ? > > 1) > RD is necessary to create a globally unique address on the PE (VPN-IPv4 > ie. > xxx:yy:a.b.c.d) from an IPv4 address learned from the CE. However the > config... > > PE2(config)#ip vrf HOSTNAME PE2(config-vrf)#rd 100:27 > > > > 2) > ...will not result in any prefixes that exist in vrf HOSTNAME on PE2 > being > announced by MP-BGP. For that to occur, we need to add the following > config. > > PE2(config-vrf)#route-target export nn:mm (pick your numbers for the > variables) > > > > 3) > Further, no MP-BGP learned VPN-IPv4 prefixes will be installed into vrf > HOSTNAME unless you add the command: > > PE2(config-vrf)#route-target import ff:gg (again, pick your numbers for > the > variables) > > > (AND of course ff:gg matches the extended community attribute on a MP-BGP > learned VPN-IPv4 prefix !) > > > > > btw-Could anyone elaborate on the merits/demerits of having the value for > RD > = RT ? > > ie. > PE2(config)#ip vrf HOSTNAME PE2(config-vrf)#rd 100:27 PE2(config-vrf) > #route-target export 100:27 > PE2(config-vrf)#route-target import 100:27 > > > > I wish to extend my appreciation to all for this forum. I can only state > that no matter how well a book may be written, it is a great help to have > peolpe to bounce back and forth with on some topics. > > > thanks, > Dana > > -----Original Message----- > From: Martin Heusinger > To: dwk@danakonkin.com; mpls-ops@mplsrc.com > Sent: 18/02/03 13:58 > Subject: Re: [MPLS-OPS]: Route Distinguisher Questions > > Hi Dana, > > see my comments inline. > > Cheers > > Martin > > On Tue, 18 Feb 2003 08:09:27 -0500, <dwk@danakonkin.com> wrote: > >> Apologies, for after reading the last few weeks of this list I am > still >> unclear on the RD/RT issue, so I hope you do not mind if I ask another >> question. >> >> >> The config: >> >> PE2(config)#ip vrf HOSTNAME PE2(config-vrf)#rd 100:27 PE2(config-vrf) >> #route-target import 2:2 >> >> My humble understanding is this will result in the creation of a vrf > on >> PE2 >> (assuming there exists appropriate BGP address-family config) of >> 'HOSTNAME' >> and the prefixes will be 'converted' to VPN-IPv4 by prepending the RD >> 100:27 >> onto the IPv4 prefix. >> Additionally, any prefixes carried by MP-BGP to PE2 with the Extended >> Community attribute as 2:2 will be installed into the 'HOSTNAME' vrf > on >> PE2 >> as routes. (please tell me if I am wrong) > > This is quite right! One question: Where do you think these routes with > 2:2 would come from? Or more specific: How are these VPNv4 prefixes > "marked" > > with the extended BGP community 2:2? > >> >> >> PE2(config-vrf)#route-target export 2:2 >> >> Hmmm, I am not sure about this. 1. What purpose does this serve if > those >> VPN-IPv4 prefixes already are being >> carried in MP-BGP ? > > Well here is the answer to the question I asked above: this is the way > to tell the PE (and similar VRFs on other PEs) to add the RT 2:2 to all > VPNv4 prefixes learned from CE routers attached to this VRF when sending > MP-BGP updates to other PEs. > > >> >> 2. Or does this export the ENTIRE set of prefixes in the 'HOSTNAME' > vrf >> with >> the Extended Community attribute of 2:2 ? > > Not quite! The entire set of prefixes consists of those learned from CE > routers (Rt 2:2 is attached by this PE when sending them to other PEs) > and those learned through MP-BGP. The latter have already a set of RTs > attached. They will not be modified nor will they be sent to other PEs > in MP-iBGP. > >> >> 3. Does this mean that he RD (rd 100:27) on PE2 for vfr 'HOSTNAME' is >> only >> locally significant to PE2 ? > > No. It is globally (i.e. in the whole world of MPLS VPNs) significant. > There is however no special meaning to a RD. Its only purpose is to make > > VPNv4 (f.e. 100:345:10.1.0.0) globally unique. > >> >> and then, >> 4. Does the RT 2:2 determine that all the prefixes contained in vrf >> 'HOSTNAME' will be propagated from PE2 into MP-BGP with Extended >> Community >> attribute 2:2 ? > > Not all prefixes. Only those learned from CEs attached to this VRF. The > PE is not allowed to treat all IPv4 prefixes like this, as they might be > coming from VPNv4 routes learned through MP-BGP - in short, this is > normal MP-iBGP loop prevention. > > >> >> >> Many thanks , >> >> Dana Konkin >> >> ------- >> The MPLS-OPS Mailing List >> Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml >> >> > > > -- 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 |
|