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

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