Re: MPLS Route Targets

Cool.

As you saw. The fact they come into 1 BGP RIB is why you are still able to
retain route policy between them. It just keeps them from looking the same
if both clients used the same IP Addressing scheme. Your 10.0.0.0 in this
case. They are technically 3 different routes that terminate to the same
place.

The clients may have to run NAT or the provider can do it but only if the
customer still uses the same addressing scheme on both sides of the cloud.

Paul

-- 
Paul Negron
CCIE# 14856 CCSI# 22752
Senior Technical Instructor
www.micronicstraining.com
> From: Carlos G Mendioroz <tron_at_huapi.ba.ar>
> Date: Tue, 24 Aug 2010 13:19:58 -0300
> To: Paul Negron <negron.paul_at_gmail.com>
> Cc: Narbik Kocharians <narbikk_at_gmail.com>, Adam Booth <adam.booth_at_gmail.com>,
> Brad Edgeworth <edgie512_at_gmail.com>, Cisco certification
> <ccielab_at_groupstudy.com>
> Subject: Re: MPLS Route Targets
> 
> Well, agreed, we are getting somewhere.
> In standard deployments this has litle if any impact.
> But... there are twisted scenarios where you can make it have some
> impact, and then, at least, having the same or a different RD will
> make a difference on the final result.
> 
> The reason why it does not usually matter at all is that all this
> happens inside iBGP, so the policy would be the same all over the place.
> 
> If you have different RDs, you will have two different routes and the
> decision of which one to use will be done by the receiving PE.
> If you have the same RD, the decision might be done by an intermediate
> P. If the policy is not the same, the result might not be as well.
> 
> Just to test this, I did a small star topology with R2 being hub
> and R1/R2/R4 spokes. R2 is a RR. R1 and R3 have two VRFs, one with
> common RD (65000:3), the other with different RDs (65000:1 and 65000:2),
> and both with one interface in the 10.0.0.0/24.
> 
> Here's R4 routes:
> R4#sh ip bgp vpnv4 all
> BGP table version is 1, local router ID is 192.168.3.2
> Status codes: s suppressed, d damped, h history, * valid, > best, i -
> internal,
>                r RIB-failure, S Stale
> Origin codes: i - IGP, e - EGP, ? - incomplete
> 
>     Network          Next Hop            Metric LocPrf Weight Path
> Route Distinguisher: 65000:1
> * i10.0.0.0/24      192.168.1.2              0    100      0 i
> Route Distinguisher: 65000:2
> * i10.0.0.0/24      192.168.2.2              0    100      0 i
> Route Distinguisher: 65000:3
> * i10.0.0.0/24      192.168.1.2              0    100      0 i
> 
> R4 is presented with both routes for the vpn with different RDs, but
> only one for the vpn with common RDs. R4 is free to choose using a local
> policy the route to use in one case, and the decision is already made in
> the other.
> 
> As you envisioned, I have progressed thanks to this. Thanks.
> 
> -Carlos
> 
> Paul Negron @ 23/8/2010 14:10 -0300 dixit:
>> Now we are getting somewhere.( and being 100% Puerto Rican from the East
>> Coast should be enough for you to know where I am coming from). Ha !!  :-)
>> 
>> Addressing this statement in the thread below:
>> 
>> "... I'm saying that if the RDs of two VRFs
>> that have access to the same network do not match, the route that will
>> be used by some (other) site to reach that network might not be based
>> on BGP metrics. I've to check this though."
>> 
>> 
>> It is. I manipulated the path chosen by modifying the LOCAL PREFERENCE
>> through the VPNv4 peering sessions.
>> 
>> I still encourage you to check though. I want you to be very sure.
>> 
>> A disagreement should always lead to progress. No matter which side you
>> choose. :-)
>> 
>> Paul
> 
> -- 
> Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net