IEOC - Internetwork Expert's Online Community

I would like to get clarifcation on these very confusing (to me) concepts.

1. RD pre-pended onto IGP prefix together become the VPN-v4 prefix as the IGP redistributes into MBGP in the VPN-v4 BGP table on the PE. RD has nothing to do (?) with where the the VPN-v4 prefix will initially be exported or eventually be imported at the destination PE. RD may have the same syntax as route-target, but not necessarily.

2. Route-target import is the data structure in the VRF set up definition that signals the IGP redistribution (from MBGP) process which route-target extended community value is accepted.

3. Route-target export is the data structure in the VRF set up definition that signals the BGP restribution (from IGP VRF) process what values to write into the extended community for the VPN-v4 prefixes (which would also have RD prepended, but unrelated to the route-target export string.

4. Each address-family in BGP has its own BGP table. Each VRF has its own RIB and CEF table.

I am getting more confused than ever.

May I ask INE experts to correct where I am wrong.

 

 

 

josephc,

RD is a tag that makes the VPNv4 prefixes unique - RT is an extended community value in BGP that determines which prefixes are imported into which VRFs.

For VRF-Lite the RT is not needed, because BGP is not involved, but RT is required for MP-BGP.

Thanks Darrel.

I am trying to understand the meaning of route-target import|export|both A:n.  It would seem to me "import" works one way, "export" works another way (see my original post. More importantly I am trying to understand where these data structures are within control plane operations from end to end.  Then I also have the question of what happens if I only configure the statement route-target  import, or only route-target export. Theoretically, the import and export values, as well as the RD value don't have to be the same?

 

They are merely "tags" of different types used to sort what goes where...

The route-distinguisher is ONLY used to make sure that Customer-A's 10.1.1.0/24 network doesn't look the same as Customer-B's 10.1.1.0/24 network.  otherwise, the MPLS provider may decide "one" is better/correct and then someone else loses out.  But being not-equal, they are coexisting unique routes.

Route targets are extended communities (64-bit tags) used to sort what goes where.  You can use the same RT both directions if you want, or different ones...  But let's say Customer A has three sites.

We'll use 1:101, 1:102 and 1:103 for simplicity in one example, and ONLY 1:100 in another.

To keep things the same, ALL sites would both import and export to 1:100.  Routes entering or leaving would all be under the same criteria, so no problem (easiest).

If there were sometimes differences where some sites would get SOME information, others would get all information and things like that, I may choose to go with a multi-community setup.  If we wanted to fully share still:

Site 1:  export to 1:101 but import 102 and 103.
Site 2:  export to 1:102 but import 101 and 103.
Site 3:  export to 1:103 but import 101 and 102.

Or any exclusions to change in there as desired.  But it's all just a game of mixing and matching.

HTH,


josephc wrote:

Thanks Darrel.

I am trying to understand the meaning of route-target import|export|both A:n.  It would seem to me "import" works one way, "export" works another way (see my original post. More importantly I am trying to understand where these data structures are within control plane operations from end to end.  Then I also have the question of what happens if I only configure the statement route-target  import, or only route-target export. Theoretically, the import and export values, as well as the RD value don't have to be the same?

 

Internetwork Expert - The Industry Leader in CCIE Preparation
http://www.internetworkexpert.com

Subscription information may be found at:
http://www.ieoc.com/forums/ForumSubscriptions.aspx

josephc,

In order to use a prefix in a vrf, there must be a match with at least one rt added when the prefix was exported from the originating vrf.

In the simplest case, the rd = rt export = rt import for all PE routers with the vrf, but this doesn't provide for a common Internet access for all vrf's.

There must be a match between an rt export value (on the PE router of origin) and an rt import value (on the PE destination router) for a prefix to make its way into a vrf routing table (RIB).

Site 1:  export to 1:101 but import 102 and 103.
Site 2:  export to 1:102 but import 101 and 103.
Site 3:  export to 1:103 but import 101 and 102.

--------

Scott,

Thanks for very clear explanation.

 

 

 

Thanks Darrell.

A "trouble ticket" with unmatched RT values is fair game in the exam ...

 

DarrellEscola:

For VRF-Lite the RT is not needed, because BGP is not involved, but RT is required for MP-BGP.

That is incorrect. Route-targets are certainly needed with VRFLite if you want to do inter-VRF route leaking. Very useful in a service provider environment with 6500s.

Hi Jent

 Inter-vrf route target import and export works only with MPBGP, that is even if we configure under different vrf configuration tables route-targets for import/export  in order to enable route-propagation between vrfs we must configure BGP and apply setting per vrf under BGP address family (redistribution-- although its not required to peer using BGP with anyone). There are platforms also that support this vrf-light capability (for example Nexus 7K) but  they lack the RT functionality.

 

BR

Orestis

orestis46:

Hi Jent

 Inter-vrf route target import and export works only with MPBGP, that is even if we configure under different vrf configuration tables route-targets for import/export  in order to enable route-propagation between vrfs we must configure BGP and apply setting per vrf under BGP address family (redistribution-- although its not required to peer using BGP with anyone). There are platforms also that support this vrf-light capability (for example Nexus 7K) but  they lack the RT functionality.

 

BR

Orestis

I didn't say BGP wasn't involved, did I :)

And yes, you'll have to use the BGP table. 6500s and most medium scale (3560,3750,4948...) Catalysts support it and it's coming to Nexuses H2'10 (the current VRF implementation on 7k is simply lame). So it is also meaningful in vrflite implementations. (though, VRFLite refers to a different usage than in CCIE SP lab exam where it refers to multi VRF CE).

 

Its easy to get misinterpretation on wording Jent ,propably i translate it somehow else, but more or less often we might see also the case of a CE that wants to differentiate traffic localy (isolate traffic between different attached networks without any exchange between them, so RT might be ommited). This can save complicate route-filtering and multiple routing process between these separate networks. Further control of course points to the use of RT for any traffic exchange/manipulation found in a service provider environment.

...waiting for a real implementation on N7K for this

BR

Orestis