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

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