Re: MPLS Route Targets

I am just happy that you guys are discussing a topic that is on at least one of the CCIE blueprints!

Woooohooooo!

On Aug 24, 2010, at 4:47 PM, Carlos G Mendioroz wrote:

> Paul Negron @ 24/8/2010 16:17 -0300 dixit:
>> Carlos,
>> I did not miss your point. YOU MISSED YOUR POINT.
>
> That can be the case, just let's agree where did I that, ok ?
> Stay calm, you hot blooded costa rican :)
>
>> You need to pay attention Sir. You did not complete your lab testing before
>> making yet another incorrect assumption. That's 4 times in this thread.
>
> That's what I'm traying to find. I'm open to being wrong, but waiting to be shown where. Nobody is born knowing everything, that means all of us
> have a time in our history or present when we don't know X, for all X.
>
>> Did I not tell you that I modified the path using LOCAL PREFERENCE to choose
>> the very same prefix using 2 unique RD's? How can you say that " If you use
>> different RDs then BGP does not compare those routes *while they are vpnv4
>> routes*."
>
> Because your information is kept with different RDs up to the time where
> RDs are discarded to become ipv4 vrf, at the router that imports the
> vpnv4 routes based on the import targets.
> Being that router in the same BGP AS, local preference aplies.
>
> Let me show a line art of my topology, may be I was so into the thing that I did not express myself in a clear way:
>
>
> 10.0.0.1/24 (VPN1) R1 --- --- R3 (VPN1) 10.0.0.2/24
> 10.0.0.1/24 (VPN2) | | (VPN2) 10.0.0.2/24
> | |
> R2
> |
> |
> R4
>
> All R1/R2/R3/R4 inside AS 65000, R3 is a RR so it receives R1 rooutes
> and R2 vpnv4 routes.
> No VRFs there.
> That means that the routes are vpnv4 routes while they transit R2
> from R1 and R3 towards R4.
>
>> You are making absolutely NO SENSE. Your lab output does not reflect the
>> complete story. Also, the fact that you continue to try and prove yourself
>> correct in spite of the evidence you provided, incomplete if I might add,
>> proves you have more issues than just observing MPLS behaviors.
>
> As I said before, that might be the case, but instead of making a lot of noise, please point to a specific thing that is meaningless in what I say, ok ?
>
>> Here, let me show you how to test something.
>> A) This is the topology
>> C PE P PE C
>> R1 -> R2 -> R3 - > R4 -> R5
>> | ^
>> | |
>> | |----> R6 -> R7
>> PE C
>> B) Here is the VPNv4 Table on R2 prior to routing changes.
>> R2#sh ip bgp vpnv4 all
>> BGP table version is 1, local router ID is 200.200.200.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:1001
>> * i5.0.0.0 200.200.200.4 0 100 0 65015 i
>> * i7.0.0.0 200.200.200.4 0 100 0 65015 i
>> * i55.0.0.0 200.200.200.4 0 100 0 65015 i
>> * i77.0.0.0 200.200.200.4 0 100 0 65015 i
>> Route Distinguisher: 65000:1002
>> * i5.0.0.0 200.200.200.6 0 100 0 65015 i
>> * i7.0.0.0 200.200.200.6 0 100 0 65015 i
>> * i55.0.0.0 200.200.200.6 0 100 0 65015 i
>> * i77.0.0.0 200.200.200.6 0 100 0 65015 I
>> 2 different sets of routes from 2 different PE's with 2 different RD's. They
>> are the same prefixes, but not to MP-BGP.
>> C) Here is the output of R6 prior to changing the policy.
>> R6#sh ip bgp vpnv4 all
>> BGP table version is 53, local router ID is 200.200.200.6
>> 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:1001
>> *>i5.0.0.0 200.200.200.4 0 100 0 65015 i
>> *>i7.0.0.0 200.200.200.4 0 100 0 65015 i
>> *>i55.0.0.0 200.200.200.4 0 100 0 65015 i
>> *>i77.0.0.0 200.200.200.4 0 100 0 65015 i
>> Route Distinguisher: 65000:1002 (default for vrf VPNB)
>> * i5.0.0.0 200.200.200.4 0 100 0 65015 i
>> *> 131.1.67.7 0 65015 i
>> * i7.0.0.0 200.200.200.4 0 100 0 65015 i
>> *> 131.1.67.7 0 0 65015 i
>> * i55.0.0.0 200.200.200.4 0 100 0 65015 i
>> *> 131.1.67.7 0 65015 i
>> * i77.0.0.0 200.200.200.4 0 100 0 65015 i
>> *> 131.1.67.7 0 0 65015 I
>> R6 has options from PE4 and itself due to the matching Route-Targets. 2
>> different RD's.
>> D) here we apply and verify the policy:
>> R6(config)#router bgp 65000
>> R6(config-router)#address ipv4 vrf VPNB
>> R6(config-router-af)#neighbor 131.1.67.7 route-map LOCALPREF in
>> R6#sh ip bgp vpnv4 all
>> BGP table version is 61, local router ID is 200.200.200.6
>> 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:1000
>> *>i1.0.0.0 200.200.200.2 0 100 0 65015 i
>> *>i11.0.0.0 200.200.200.2 0 100 0 65015 i
>> Route Distinguisher: 65000:1001
>> *>i5.0.0.0 200.200.200.4 0 100 0 65015 i
>> *>i7.0.0.0 200.200.200.4 0 100 0 65015 i
>> *>i55.0.0.0 200.200.200.4 0 100 0 65015 i
>> *>i77.0.0.0 200.200.200.4 0 100 0 65015 i
>> Route Distinguisher: 65000:1002 (default for vrf VPNB)
>> *>i1.0.0.0 200.200.200.2 0 100 0 65015 i
>> * i5.0.0.0 200.200.200.4 0 100 0 65015 i
>> *> 131.1.67.7 200 0 65015 i
>> * i7.0.0.0 200.200.200.4 0 100 0 65015 i
>> *> 131.1.67.7 0 200 0 65015 i
>> *>i11.0.0.0 200.200.200.2 0 100 0 65015 i
>> * i55.0.0.0 200.200.200.4 0 100 0 65015 i
>> *> 131.1.67.7 200 0 65015 i
>> Network Next Hop Metric LocPrf Weight Path
>> * i77.0.0.0 200.200.200.4 0 100 0 65015 i
>> Notice how the PE not only sets the routes in MP-BGP VPNV4 context but it
>> also makes a routing decision and passes on the BEST routes. Just as you
>> thought.
>> E) The PE2 VPNv4 peer not only sees the LocalPreference but obeys it's
>> wishes. From 2 different PE's that have 2 different RD's concerning the same
>> prefixes.
>> R2#sh ip bgp vpnv4 all
>> BGP table version is 33, local router ID is 200.200.200.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:1000 (default for vrf VPNA)
>> *> 1.0.0.0 131.1.12.1 0 0 65015 i
>> *>i5.0.0.0 200.200.200.6 0 200 0 65015 i
>> *>i7.0.0.0 200.200.200.6 0 200 0 65015 i
>> *> 11.0.0.0 131.1.12.1 0 0 65015 i
>> *>i55.0.0.0 200.200.200.6 0 200 0 65015 i
>> *>i77.0.0.0 200.200.200.6 0 200 0 65015 i
>> Route Distinguisher: 65000:1002
>> *>i5.0.0.0 200.200.200.6 0 200 0 65015 i
>> *>i7.0.0.0 200.200.200.6 0 200 0 65015 i
>> *>i55.0.0.0 200.200.200.6 0 200 0 65015 i
>> *>i77.0.0.0 200.200.200.6 0 200 0 65015 i
>> What? It sets the routes in a different RD? I'm sure you are still puzzled.
>> I am so happy for the rest of the forum that I am not.
>
> No, I'm not. That's the consequence of your import statement at the R6 vrf. You are importing routes, discarding the RD as you go from vpnv4
> to ipv4 vrf and assigning the new RD as per local vrf. New route,
> that you send to vpnv4 neighbours, for them to use.
>
>> Like I said, I will protect the Integrity of the Forum by eliminating Facts
>> that are materialized through presumption and invalid or incomplete testing.
>> You should have stuck with your original posture...here it is:
>> You admitted that you "have never labbed nor have experience in
>> inter-AS mpls vpn." That statement is why you were and still are confused
>> about how RD's work.
>
> Oh, well, if you insist.
> I'm not going to say I'm right period. But please show me where I'm wrong ?
>
> The forum does not need integrity keepers, just technical insight.
> I'm a firm believer that to get CCIE level you should be able to get past confusion into understanding. I don't feel confused yet.
> But have no problem in admiting being wrong, if you (or anybody else
> for that matter) kindly point me to the spot.
>
>> The reason why I mentioned NAT, which you also missed, is to make the point
>> that although the routes are kept separate, that does not excuse the C
>> routers from making mistakes. By NOT making the RD's match, the customer
>> cannot blame the cloud for the Route not making it to the other side. It is
>> also very useful for troubleshooting in a NOC environment.
>
> The reason I mentioned that is that in my example, all routes in each VPN referred to the same network, so bringing up NAT was pointless
> or sign of missunderstanding.
>
>> I did not mean to come off irritated but this was getting out of hand.
>
> I don't see why this is out of anything. Is a technical discussion of a
> CCIE related thing. Exactly what this forum is (or should be) all about.
>
>> You
>> should have unicasted me to get your facts straight before we presented it
>> to the forum for the benefit of all. If you are an instructor, I hope you
>> don't do this to your students or I might have to change your name to the
>> Minister of Misinformation.
>
> Calling me names is not going to drive this to any meaningful end.
> And a forum is not a place to present things, well... whatever.
> I don't see why unicasting is the right thing to do either.
>
> Yes, I'm an instructor, but you are in no position to qualify me in this forum. Let's keep it technical, please ?
>
>> Paul
>
> --
> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at: http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Tue Aug 24 2010 - 17:43:11 ART