Re: MPLS Route Targets

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