Re: MPLS - RDs, RTs, and Import/Export

Shiran,

Thanks for expanding my example. Based on what you listed, I think that
jives with my current understanding.

CE -> PE is always eBGP
PE-> PE is always MP-iBGP

The only time routes are generated and marked is when they are sent from
the PE connected to the originating CE. That is basically why the config I
gave previously works as a central services VPN.

My confusion came from thinking that the Central Services VRF would
re-advertise customer routes with its own RT. That ended up being false.

Thanks for your insight -- MPLS is a really different way of thinking about
a lot of things, but I think I'm getting the hang of it!

Keller Giacomarro
keller.g_at_gmail.com

On Sun, Dec 18, 2011 at 2:29 AM, shiran guez <shiranp3_at_gmail.com> wrote:

> Actually no, the CE to PE is EBGP and PE to PE is IBGP. IBGP will
> advertise its IBGP neighbors only locally advertised and / or EBGP but that
> is not why you are not getting the NLRI of Customer 1 in 2 and 2 in 1.
>
> You can check your theory using route reflector setting the PE Router
> connected to CE Central Services router as Route Reflector client and even
> tough it be definition should re-advertise you should not see the RT of
> Customer 1 in Customer 2 and Customer 2 RT in Customer 1.
>
> PE have a EBGP neighbor relation with CE once the the PE get NLRI's from
> the CE it mark them according to the VRF with the appropriate RD and
> advertise (if there is an RT export) to all PE neighbors (IBGP)
>
> Lets give an example that can put some numbers and may be clear things up:
>
> I would like to change the numbers a little to it would be less confusing:
>
> Customer 1 RD 1 RT 111
> Customer 2 RD 1 RT 222
> Central Services RD 3 RT 333
>
> Central Services:
>
> 3:10.0.0.0/8 RT 333
> 3:20.0.0.0/8 RT 333
>
> Customer 1
>
> 1:30.0.0.0/8 RT 111
>
> Customer 2
>
> 2:40.0.0.0/8 RT 222
>
> Customer 1 import "3" export "1"
> Customer 1 will see:
> 1:30.0.0.0/8 RT 111
> 3:10.0.0.0/8 RT 333
> 3:20.0.0.0/8 RT 333
>
>
> Customer 2 import "3" export "2"
> Customer 2 will see:
> 2:40.0.0.0/8 RT 222
> 3:10.0.0.0/8 RT 333
> 3:20.0.0.0/8 RT 333
>
> Central Services import "1,2" export "3"
> Central Services will see:
> 3:10.0.0.0/8 RT 333
> 3:20.0.0.0/8 RT 333
> 1:30.0.0.0/8 RT 111
> 2:40.0.0.0/8 RT 222
>
>
> Notice that the import and export are related to the RT and not to the RD!
>
> Hope that clear some more :-)
>
> On Sun, Dec 18, 2011 at 9:49 AM, Keller Giacomarro <keller.g_at_gmail.com>wrote:
>
>> Thanks for your response!
>>
>> I've got some additional info that I think is helping clear this up for
>> me.
>>
>> Since this is iBGP, the only routers that will advertise a prefix into
>> MP-iBGP are the routers attached to the CE router that originated it.
>> Therefore, the Central Services router should not be doing any retagging
>> of prefixes.
>>
>> If this is the case, the scenario I outlined should work as expected.
>> Central Services will import routes from Customer 1 (RT 1) and Customer 2
>> (RT 2). It will also export its Central-Services-originated routes with a
>> RT of 3, which both Customer 1 and Customer 2 will import. However,
>> Central Services will NOT re-advertise Customer 1 or Customer 2's routes
>> with an RT of 3 as I was thinking it would.
>>
>> I believe this all hinges on the fact that we're doing iBGP, where BGP
>> routes are never re-advertised after being received. If that's the case,
>> does the SP MPLS network have to run MP-iBGP, or is there a way to do
>> MP-eBGP as well?
>>
>> Corrections, comments, and other thoughts appreciated, thanks for the
>> help!
>>
>> Keller Giacomarro
>> keller.g_at_gmail.com
>>
>>
>>
>> On Sun, Dec 18, 2011 at 1:42 AM, shiran guez <shiranp3_at_gmail.com> wrote:
>>
>>> VRF - Virtual Routing and Forwarding is a way to created within a single
>>> router a several virtual separated routers this separation is done by
>>> creating a unique routing table for each VRF there are no leaks between
>>> VRF's (you could cause it to leak but not without knowing what you are
>>> doing), VRF are configured per each router (they are not transited in any
>>> way) with MPLS-VPN they are only needed on PE (Normally)
>>>
>>> RD - Route Distinguisher is a 8byte header added to the NLRI sent
>>> between PE's using MP-BGP and used to have a unique identifier for each
>>> prefix.
>>>
>>> RT - Route Targets is an Extended Community value and it is used to
>>> filter and/or advertise in and out prefix's (using import / export)
>>>
>>> Now in your scenario
>>>
>>> Customer 1 performed import "3" and export "1"
>>> Customer 2 performed import "3" and export "2"
>>> Central Services performed import "1,2" and export "3"
>>>
>>> in that scenario you could potentially make 1 and 2 talk to each other
>>> trough 3 (Hub and spoke)
>>>
>>> I hope you can see from my explanation that Central Services is not
>>> allowed to export 2 and 1 back it is only exporting prefixes marked with RT
>>> of "3".
>>>
>>> I tried to keep it as simple as I can as I know it is a confusing topic
>>> :-)
>>>
>>> Regards,
>>>
>>> Shiran
>>>
>>>
>>> On Sun, Dec 18, 2011 at 6:45 AM, Keller Giacomarro <keller.g_at_gmail.com>wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm having some trouble wrapping my head around how VRF RDs and RTs are
>>>> being handled by the router.
>>>>
>>>> First, some things I know (I think...):
>>>> - A VRF holds a set of routes, and is a copy of the standard routing
>>>> table
>>>> - A RD is set per-vrf and its sole purpose is to create a way for BGP to
>>>> distinguish between identical prefixes from different VRFs
>>>> - Routers do not use the RD to make import/export decisions into VRFs
>>>> - An export RT on a VRF means that if the router advertises a route from
>>>> that VRF into BGP, it will attach the extended community specified in
>>>> the
>>>> export statement
>>>> - An import RT on a VRF means that if the router receives a prefix from
>>>> BGP
>>>> that has the specified community set, it will import it into the VRF
>>>> where
>>>> the import statement is configured
>>>>
>>>> It came as a revalation to me that the RD doesn't have ANYTHING to do
>>>> with
>>>> importing/exporting routes -- so much of the docs I've read seem to
>>>> imply
>>>> that it does!
>>>>
>>>> Okay, so here's what I don't get. Say we're doing a central services
>>>> MPLS
>>>> VPN. Two customers, one central services VPN so there are three VRFs in
>>>> play. Assuming only one PE per customer/server site to simplify a bit.
>>>>
>>>> Exports:
>>>> Customer 1's routes are exported from their PE into MP-BGP with a RT of
>>>> 1
>>>> (not valid, but this is an example).
>>>> Customer 2's routes are exported from their PE into MP-BGP with a RT of
>>>> 2.
>>>> Central services's routes are exported from their PE with a RT of 3.
>>>>
>>>> Imports:
>>>> Customer 1 imports routes with a RT of 3 to receive central services
>>>> routes.
>>>> Customer 2 imports routes with a RT of 3 to receive central services
>>>> routes.
>>>> Central services imports routes with an RT of 1 and 2 to receive
>>>> Customer 1
>>>> and 2's routes.
>>>>
>>>> Based on the reading I've done, at this point Customer 1 and Customer 2
>>>> should be able to communicate with Central Services but not with each
>>>> other. But that doesn't really make sense to me! Wouldn't central
>>>> services *import* routes from Customer 1 with an RT of 1 and then
>>>> *export* those
>>>>
>>>> same routes with an RT of 2? Wouldn't that mean that both Customer 1
>>>> and
>>>> Customer 2 are receiving each other's routes, with the Central Services
>>>> PE
>>>> acting as a route bridge?
>>>>
>>>> Any lead on what I might be missing, as well as confirmation of what I
>>>> think I know, would be very much appreciated.
>>>>
>>>> Thanks, experts!
>>>>
>>>> Keller Giacomarro
>>>> keller.g_at_gmail.com
>>>>
>>>>
>>>> Blogs and organic groups at http://www.ccie.net
>>>>
>>>> _______________________________________________________________________
>>>> Subscription information may be found at:
>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Shiran Guez
>>> MCSE CCNP NCE1 JNCIA-ENT JNCIS-ENT CCIE #20572
>>> http://cciep3.blogspot.com
>>> http://www.linkedin.com/in/cciep3
>>> http://twitter.com/cciep3
>>>
>>>
>>
>
>
> --
> Shiran Guez
> MCSE CCNP NCE1 JNCIA-ENT JNCIS-ENT CCIE #20572
> http://cciep3.blogspot.com
> http://www.linkedin.com/in/cciep3
> http://twitter.com/cciep3

Blogs and organic groups at http://www.ccie.net
Received on Sun Dec 18 2011 - 02:35:35 ART