Re: MPLS Route Targets

From: Paul Negron <negron.paul_at_gmail.com>
Date: Wed, 25 Aug 2010 10:12:40 -0600

I am satisfied with your last statement.

>Yes, I have changed from "same network should use same RD" to
>"same network may use same RD"

 ALL of the other stuff is banter. I will not argue semantics with you. This
was my only point from the beginning. Ask anyone on the thread. Since you
have changed your mind, I will wait for you do your testing to prove
anything else.

One thing I will say is that your persistant. That is good thing.
The way you come off after you say you don't know a subject that well.
That's bad.

Good Luck,

Paul

-- 
Paul Negron
CCIE# 14856 CCSI# 22752
Senior Technical Instructor
www.micronicstraining.com
> From: Carlos G Mendioroz <tron_at_huapi.ba.ar>
> Date: Wed, 25 Aug 2010 12:54:29 -0300
> To: Paul Negron <negron.paul_at_gmail.com>
> Cc: Adrian Brayton <abrayton_at_gmail.com>, Cisco certification
> <ccielab_at_groupstudy.com>
> Subject: Re: MPLS Route Targets
> 
> 
> 
> Paul Negron @ 25/8/2010 11:16 -0300 dixit:
>> I can do nothing for you if you do not concede that RT's identify the VPN.
>> (Not the RD). If this is true, you have fallen into a state of Ignorance. I
> 
> No, that is not true. Read all the thread, I have never said that.
> (you are putting your interpretation of my words in my mouth,
> or my fingers :)
> 
> I've never attached a VPN identity. In fact, given the flexibility of
> MPLS based VPNs, it is very hard to have a generic definition of
> a VPN id.
> 
> I have always talked about *route* identity. And I guess we can
> agree that a route and a vpn are different things.
> 
>> am sure ANY CCIE-SP will correct you on that point. You claimed you didn't
>> mind being wrong. I do not believe that is true for 1 second.
> 
> You insist in bringing non technical things into the thread.
> 
>> I just don't get how you can say you have little experience with Inter AS
>> VPN and you come out to correct me after I have used and deployed it for
>> years. I am not saying that I cannot be proven wrong but I know I would be
>> taking a different approach then you. I guess I could turn it around by
>> stating:
>> 
>> You show me ONE instance where the RD has to match and I will believe you. I
>> am tired of proving your statement wrong. You prove it right Sir.
> 
> Fair. I'll work on this. Basically, I need a situation where I need the
> central policy to override the PE policy. Weird, I admit.
> But I've seen many here admit that CCIE lab test is a test of
> understanding knobs even if used in non standar (or reasonable) ways.
> Given that... it's not hard to assemble something along the lines:
> 
> Given that you can control the policy on a route reflector, but
> not on the edge PEs, make sure that the route is chosen according
> YOUR rules and not the ones set by the final PE administrator.
> 
> Makes sense in a real world scenario? I do not think so. I take it
> that you have never encountered a case that needs this and you have
> experience. I do not.
> 
>> 
>> You keep changing your point. I know you don't think so, but EVERYBODY is
>> watching. I do not have to judge your Instructing skills, everyone else will
>> be judging you. You have done that to yourself.
> 
> Yes, I have changed from "same network should use same RD" to
> "same network may use same RD", and have learned more about detailed
> workings of the BGP selection process and VRF interworking.
> But I don't keep changing. It was just an "aha" time when I discovered
> how multiple vpnv4 routes are choped into the destination VRF
> using the same policy that applies to vpnv4 selection, and
> immediatelly back into vpnv4 via route targets, possibly under a
> different RD. It behaves just like a redistribution, or at least
> that is my view.
> 
>> 
>> Send the dynamips file to me so I can judge for myself concerning your point
>> that RD's should match.
> 
> -- 
> Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net
Received on Wed Aug 25 2010 - 10:12:40 ART

This archive was generated by hypermail 2.2.0 : Wed Sep 01 2010 - 11:20:53 ART