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

From: Keller Giacomarro <keller.g_at_gmail.com>
Date: Sun, 18 Dec 2011 01:49:00 -0600

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

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

This archive was generated by hypermail 2.2.0 : Sun Jan 01 2012 - 08:27:00 ART