All,
I have once again proved that RD's do NOT have to match under ANY
conditions.
I would like to explain it this way.
You want to think of the RD's as BGP's way of seeing an interface. Since
EVERY prefix that leaves the interface will receive the very same RD, this
allows BGP to maintain separation from other interfaces that apply a
different RD.
(This is not how it exactly works in the above sentence, it is just a better
visual)
They are treated like different prefixes between RD's while the route is a
VPNv4 route (96 bit address).
Once the prefix terminates to the other side, the routes moving from one
direction have nothing to do with the routes moving in the other direction
in BGP, only that they don't overlap with all 96 bits (tunnels are
unidirectional). That is why it is important that the RD not identify the
VPN. The Route-Targets do. When they are imported, they are seen as existing
in 2 different RD structures at the same time.
Even if the the same route comes from 2 different PE routers with 2
different RD's configured, they are still viewed by BGP as 2 different sets
of prefixes that need to kept separate throughout the BGP domain. However,
BGP attributes will be sent across this tunnel from one CE to the other. You
I Have the final configuration in Dynamips that proves this and will gladly
unicast it to anyone who asks. You can test the attribute theory by shutting
down the primary link.
I have already given Carlos his complimentary copy for his role in helping
with the discussion.
Paul
-- Paul Negron CCIE# 14856 CCSI# 22752 Senior Technical Instructor www.micronicstraining.com > From: Adrian Brayton <abrayton_at_gmail.com> > Reply-To: Adrian Brayton <abrayton_at_gmail.com> > Date: Tue, 24 Aug 2010 17:43:11 -0400 > To: Carlos G Mendioroz <tron_at_huapi.ba.ar> > Cc: Cisco certification <ccielab_at_groupstudy.com> > Subject: 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 > > _______________________________________________________________________ > Subscription information may be found at: > http://www.groupstudy.com/list/CCIELab.html Blogs and organic groups at http://www.ccie.netReceived on Tue Aug 24 2010 - 21:23:22 ART
This archive was generated by hypermail 2.2.0 : Wed Sep 01 2010 - 11:20:53 ART