The MPLS-OPS Archive

Cell Relay Retreat>MPLS-OPS Archive>month:2003-Feb> msg00131



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Fwd: RE: Route Distinguisher Questions

  • From: Roger Clark Williams <rogerw@nordlink.com>
  • Date: Wed, 19 Feb 2003 08:55:30 -0500
  • Resent-Date: Wed, 19 Feb 2003 10:34:06 -0500
  • To: MPLS-ops Mailing List <mpls-ops@mplsrc.com>
  • X-Sender: rogerw@together.net@pop.mindspring.com

Dana, you have it right.

As to your last question, a metaphor: I know two guys named Bill who play 
on the same basketball team. Their names are the same. but one plays 
forward, the other  plays guard. In other words, they are announced by the 
same "word" but their function and use within the system are not the same. 
They play on the same team (RD and RT within one VRF) but there is no 
correlation between them other than that fact and their names. So no, there 
is no underlying reason the RD and RTs have to be the same number. In fact, 
there are all kinds of instances in which there are multiple RTs within a 
single VRF and yet perhaps only one pair (if that) have the same "name" as 
the RD.


Roger Williams


>Resent-Date: Wed, 19 Feb 2003 06:51:38 -0500
>X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to 
>mpls-ops-request@mplsrc.com using -f
>From: dwk@danakonkin.com
>To: mpls-ops@mplsrc.com
>Subject: RE: [MPLS-OPS]: Route Distinguisher Questions
>Date: Wed, 19 Feb 2003 06:28:21 -0500
>X-Mailer: Internet Mail Service (5.5.2653.19)
>Resent-From: mpls-ops@mplsrc.com
>X-Mailing-List: <mpls-ops@mplsrc.com> archive/latest/5327
>X-Loop: mpls-ops@mplsrc.com
>Resent-Sender: mpls-ops-request@mplsrc.com
>
>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
>
>-------
>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