The MPLS-OPS Archive

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



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

Fwd: RE: RE: RE: Route Distinguisher Questions

  • From: Roger Clark Williams <rogerw@nordlink.com>
  • Date: Thu, 20 Feb 2003 21:43:34 -0500
  • Resent-Date: Fri, 21 Feb 2003 11:19:49 -0500
  • To: MPLS-ops Mailing List <mpls-ops@mplsrc.com>
  • X-Sender: rogerw@together.net@pop.mindspring.com

Dana, were I near my lab I could do it. I am on the road just now. Anyone 
else out there have a config like this ready to go?

Roger Williams


>From: dwk@danakonkin.com
>To: rogerw@nordlink.com, mpls-ops@mplsrc.com
>Subject: RE: RE: RE: [MPLS-OPS]: Route Distinguisher Questions
>Date: Thu, 20 Feb 2003 11:32:28 -0500
>X-Mailer: Internet Mail Service (5.5.2653.19)
>
>hehe
>That's WICKED dude !
>
>Many thanks Roger :>
>
>Hmmm, this isn't over for me yet (and the audience emits a great YAWN...)
>Damn.
>About your very recent posting beginning 'John, it is my understanding...'
>
>Would you be able to post an example config of how Company A could do that ?
>So far I am only able to visualize how that could be accomplished if
>Accounting has its own separate VRF and RT statements from the rest of
>Company A's network, but that would require a separate interface
>(logical/physical) on the PE. - This is not a challenge at all btw: Tell me
>I'm wrong, no prob. Tell me how I am wrong and I am happy !
>
>(Or maybe Source IP based vrf selection, but I would rather avoid that
>anyway :)
>
>
>best regards,
>
>Dana
>
>-----Original Message-----
>From: Roger Clark Williams
>To: MPLS-ops Mailing List
>Sent: 20/02/03 09:44
>Subject: Fwd: RE: RE: [MPLS-OPS]: Route Distinguisher Questions
>
>Dana, although I understand that you interpret this all to mean that RD
>has
>no significance in terms of a VPN other than that the RD
>is necessary to create a VRF on the PE peering with a site which wants
>to
>have 'membership' in that VPN, correctly I believe, and that you also
>feel
>unable to state it without using a run-on sentence, I can only remind
>you
>of the late President Nixon's off-the-cuff remark during the Watergate
>hearings to the effect of, "I know you understand what you thought you
>heard me say, but what you heard me say is not what I meant", so I now
>see
>that what you heard me say was what I meant.
>
>Got it. Now can I breathe?
>
>Thank you for that; I got a chuckle out of the whole thing!
>
>Roger
>
>
> >From: dwk@danakonkin.com
> >To: rogerw@nordlink.com, mpls-ops@mplsrc.com
> >Subject: RE: RE: [MPLS-OPS]: Route Distinguisher Questions
> >Date: Wed, 19 Feb 2003 10:48:58 -0500
> >X-Mailer: Internet Mail Service (5.5.2653.19)
> >
> >Ahh, thanks Roger. It feels good to be grasping it for once !!! :)
> >
> >It is strange though, as I (possibly still incorrectly) interpret this
>all
> >to mean that RD has no significance in terms of a VPN other than that
>the RD
> >is necessary to create a VRF on the PE peering with a site which wants
>to
> >have 'membership' in that VPN.
> >It is also strange in that I can't ever seem to describe any of these
> >concepts without creating a run-on sentence ! ;>
> >
> >Take care all,
> >
> >Dana
> >
> >-----Original Message-----
> >From: Roger Clark Williams
> >To: MPLS-ops Mailing List
> >Sent: 19/02/03 08:55
> >Subject: Fwd: RE: [MPLS-OPS]: Route Distinguisher Questions
> >
> >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
>
>-------
>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