Carlos,
Just so you know...I am writing this email with a complete calm demeanor, so
don't feel threatened. I am simply in complete disagreement with your point
and don't feel it is an issue that we can disagree agreeable on. I do not
want others to think you may be correct on an issue that is poorly
documented.
RD's do not have to match ....period! You can see the route easily in the
other RD section under BGP even when the RD's don't match.
They are only used to present the potential overlapping addressing
condition. Also, if you are running Overlapping VPN's, which RD is the
Central Site going to get? It can only match one site or the other if I take
your view.
There are many that have thought as you have and ended up reconfiguring MANY
MANY sites due to poor planning. I do not speak from a position of "I
Think" mentality. I am using may large SP's as an example.
Look back in the thread. I never over simplified the issue by stating that
the RD is a "syntax need". You cannot run MPLS VPN without them.
As for your example in the thread below which stated: "If your customer has
two entry/exit points to the same network across different PEs, THEY BETTER
MATCH (RDs) for BGP being able to know they actually are the same network
and route based on metrics."
You have my complete attention now. What would happen if the RD's did not
match in your example?
Paul
-- Paul Negron CCIE# 14856 CCSI# 22752 Senior Technical Instructor www.micronicstraining.com > From: Carlos G Mendioroz <tron_at_huapi.ba.ar> > Date: Mon, 23 Aug 2010 06:36:18 -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 > > I'd like to state a litle different view, just to be... picky. > You make it feel like RD's are just a syntax need, a BGP "have to deal > with it" thing and "they don't have to match anywhere". > > Well, RDs do have a concrete meaning, they make the route destination > and as such, BGP chooses the best way to RD+prefix. > If your custommer has two entry/exit points to the same network across > different PEs, they better match (RDs) for BGP being able to know they > actually are the same network and route based on metrics. > > -Carlos > > > Paul Negron @ 23/08/2010 3:26 -0300 dixit: >> Narbik, >> >> It9s funny you should say this cause I just did the same thing a couple >> of weeks ago. >> >> Just in case anyone was wondering: >> >> The VRF is a carrier for both pieces of information and is only locally >> significant. The RF does not identify the VPN. >> >> RD is simply added to the VPNv4 NLRI update of a packet to make the >> potential overlapping addresses between customers to be a 96 bit VPNv4 >> address. It is only relevant to BGP so it can route these unique >> addresses through a different Address-Family. The RD does not equal the >> VPN. This value does not need to match anywhere. ( I often recommend >> they should not for practical deployments). Not that it wouldn9t work. >> >> RT is nothing more than an extended community that is actually fixed to >> the BGP prefix itself as an attribute. These must match on both sides >> and Identifies the VPN. >> >> >> I have seen where the books tend to explain Control and Data plane a >> little messed up sometimes. >> Nothing will challenge your routing skills more than Multicast and MPLS >> from a Control Plane and Data Plane perspective. Especially with Carrier >> Supporting Carrier or Inter-AS VPN. >> >> Paul >> -- >> Paul Negron >> CCIE# 14856 CCSI# 22752 >> Senior Technical Instructor >> www.micronicstraining.com >> >> >> >> ------------------------------------------------------------------------ >> *From: *Narbik Kocharians <narbikk_at_gmail.com> >> *Date: *Mon, 23 Aug 2010 15:34:53 +1000 >> *To: *Paul Negron <negron.paul_at_gmail.com> >> *Cc: *Carlos G Mendioroz <tron_at_huapi.ba.ar>, Adam Booth >> <adam.booth_at_gmail.com>, Brad Edgeworth <edgie512_at_gmail.com>, Cisco >> certification <ccielab_at_groupstudy.com> >> *Subject: *Re: MPLS Route Targets >> >> Paul, >> >> The problem here is that many of the students don't really understand >> the difference between RT and RD, and control plane and data plane. And >> i mainly blame some of the books that are written about this subject. I >> was laughing because in my R&S class we constantly talk about it and NOT >> long ago i was trying to clear one of my student's understanding about >> the same subject. >> >> On Mon, Aug 23, 2010 at 3:24 PM, Paul Negron <negron.paul_at_gmail.com> wrote: >> >> What9s so funny dude? >> -- >> Paul Negron >> CCIE# 14856 CCSI# 22752 >> Senior Technical Instructor >> www.micronicstraining.com <http://www.micronicstraining.com> >> >> >> >> ------------------------------------------------------------------------ >> *From: *Narbik Kocharians <narbikk_at_gmail.com> >> *Date: *Mon, 23 Aug 2010 15:03:52 +1000 >> *To: *Paul Negron <negron.paul_at_gmail.com> >> *Cc: *Carlos G Mendioroz <tron_at_huapi.ba.ar>, Adam Booth >> <adam.booth_at_gmail.com>, Brad Edgeworth <edgie512_at_gmail.com>, Cisco >> certification <ccielab_at_groupstudy.com> >> >> *Subject: *Re: MPLS Route Targets >> >> hahahahaha >> >> On Mon, Aug 23, 2010 at 12:13 PM, Paul Negron >> <negron.paul_at_gmail.com> wrote: >> >> Carlos, >> >> I think you understand it just fine. The point is, you do not >> want the >> Operations guy supporting MPLS VPN's to see routes that they >> should not be >> able to see. However, you are correct practically in saying that >> this is an >> unpleasant surprise to those of us who fat finger numbers. (I >> believe that >> is ALL of us). >> >> P Routers do not normally participate with the updates unless >> configuring >> INTER-AS VPN and CSC but if they should, you are also correct in >> noticing >> that this problem would exist ANYTIME a router does not have the >> route-targets configured. >> >> Now the confusion points: >> >> 1) The RD is BGP related, so be careful with the statement that >> it is only >> RT related. I'm sure you understand this. It just sounded weird >> and I want >> to make sure I understood you correctly. >> >> 2) I did not say "required to send". I said " This proves that the >> route-target filter command is NOT required to be configured to >> send BGP >> information to a BGP peer. Even when they are EBGP peers that >> DO NOT have >> the RT's configured. >> >> 3) This is a control plane thing that allows the P routers to >> use an inner >> label that they did not originate for the use of FORWARDING >> traffic from one >> AS to another. (This is the DATA PLANE INTERACTION that is >> strange to some.) >> If this did not take place. The DATA PLANE would be broken as >> there is no >> TOP label to hide the MPLS VPN label between AS's. >> >> Paul >> -- >> Paul Negron >> CCIE# 14856 CCSI# 22752 >> Senior Technical Instructor >> www.micronicstraining.com <http://www.micronicstraining.com> >> <http://www.micronicstraining.com> >> >> >> >>> From: Carlos G Mendioroz <tron_at_huapi.ba.ar> >>> Date: Sun, 22 Aug 2010 22:26:33 -0300 >>> To: Paul Negron <negron.paul_at_gmail.com> >>> Cc: Adam Booth <adam.booth_at_gmail.com>, Brad Edgeworth >> <edgie512_at_gmail.com>, >>> Cisco certification <ccielab_at_groupstudy.com> >>> Subject: Re: MPLS Route Targets >>> >>> Sorry, I don't get a clear message from you, although I think I do >>> understand what the command does :-/ >>> >>> Confusion items: >>> * You put in the bag RDs and RTs, and AFAIK, this is only RT >> related. >>> * You talk about being required to send... and that make no >> sense to me. >>> * You even talk about LDP and second label, when AFAIK this is >> a control >>> plane thing, BGP only. >>> >>> What my understanding is now is that this is an implicit filter >> based on >>> import targets to reduce the BGP table size of PEs. >>> And a nasty surprise if your PE talks eBGP to someone that >> wants that >>> information, or if the router is a reflector, or confed intra >> AS boundary. >>> Or said another way, this filter is designed for leaf PEs that >> only care >>> about prefixes for their VRFs, and you'd better disable it if >> the router >>> is in a BGP transit path. >>> >>> -Carlos >>> >>> >>> Paul Negron @ 22/08/2010 3:16 -0300 dixit: >>>> Man I almost confused myself. Here is the answer simplified. >>>> >>>> By default, a router that DOES NOT have the RT and RD >> information will >>>> reject the routes as not supporting the extended-community >> value and will >>>> NOT be visible in the bRIB. >>>> >>>> The route-target filter allows a VPNv4 participating router to >> view both the >>>> route-target and the RD information even when it does not have >> the RT or RD >>>> information defined. >>>> >>>> The newly learned RT and RD information can then be shared >> with ANOTHER >>>> VPNv4 (E)BGP peer. When the route-target filter is removed >> from the new EBGP >>>> peer, the bRIB learns the RD and RT information from the >> Originating EBGP >>>> peer. >>>> >>>> This proves that the route-target filter command is not >> required to send BGP >>>> information. It is ONLY used to reveal information that was at >> one time >>>> rejected. This also allows the BGP peer to advertise these >> routes to another >>>> peer. >>>> >>>> >>>> Sorry folks. A little late for me to be answering questions. >>>> Hope this helps. >>>> >>>> Paul >>>> >>>> Paul Negron >>>> CCIE# 14856 CCSI# 22752 >>>> Senior Technical Instructor >>>> www.micronicstraining.com <http://www.micronicstraining.com> >> <http://www.micronicstraining.com> >>>> >>>> >>>> >>>>> From: Paul Negron <negron.paul_at_gmail.com> >>>>> Date: Sat, 21 Aug 2010 23:15:23 -0600 >>>>> To: Carlos G Mendioroz <tron_at_huapi.ba.ar> >>>>> Cc: Adam Booth <adam.booth_at_gmail.com>, Brad Edgeworth >> <edgie512_at_gmail.com>, >>>>> Cisco certification <ccielab_at_groupstudy.com> >>>>> Conversation: MPLS Route Targets >>>>> Subject: Re: MPLS Route Targets >>>>> >>>>> Ah! I think the confusion here is the purpose of the command. >> The purpose is >>>>> to prevent a PE router from making those route-targets >> visible to ANY >>>>> upstream BGP peer that does not configure the RT that matched >> the Downstream >>>>> PE. >>>>> >>>>> That said, If the 2 EBGP P routers can remove the >> route-target filter and >>>>> use >>>>> the inner most label to send traffic, then the command is NOT >> REQUIRED to >>>>> pass >>>>> on RD and RT information with the (NON-LDP) VPNv4 EBGP peer. >> Try and say >>>>> that >>>>> 10 times. Crap!! :-) >>>>> >>>>> Does this make sense? >>>>> >>>>> >>>>> -- >>>>> Paul Negron >>>>> CCIE# 14856 CCSI# 22752 >>>>> Senior Technical Instructor >>>>> www.micronicstraining.com <http://www.micronicstraining.com> >> <http://www.micronicstraining.com> >>>>> >>>>> >>>>> >>>>>> From: Carlos G Mendioroz <tron_at_huapi.ba.ar> >>>>>> Date: Sat, 21 Aug 2010 08:02:43 -0300 >>>>>> To: Paul Negron <negron.paul_at_gmail.com> >>>>>> Cc: Adam Booth <adam.booth_at_gmail.com>, Brad Edgeworth >> <edgie512_at_gmail.com>, >>>>>> Cisco certification <ccielab_at_groupstudy.com> >>>>>> Subject: Re: MPLS Route Targets >>>>>> >>>>>> Cool. >>>>>> Just one question, as I have never labbed nor have experience in >>>>>> inter-AS mpls vpns: You say "in order to see" the route targets, >>>>>> but my impression of the command (no bgp default >> route-target filter) >>>>>> is that it actually filters, so for a reflector or a vpnv4 >> eBGP peer, >>>>>> you would actually need it in order to exchange such routes >>>>>> (those with no RTs used by local VRFs). Is that correct ? >>>>>> >>>>>> Thanks, >>>>>> -Carlos >>>>>> >>>>>> Paul Negron @ 20/08/2010 21:52 -0300 dixit: >>>>>>> All, >>>>>>> >>>>>>> When configuring Inter-AS VPN, The P routers ARE >> participating in BGP >>>>>>> under >>>>>>> the VPNv4 Address-Family and will use the inner label to >> switch from >>>>>>> carrier >>>>>>> to carrier. The default route target must be lifted in >> order to see the >>>>>>> route-targets on the P router. The only other way I know of >> is to >>>>>>> configure >>>>>>> the route-targets on a vrf that is on the P router but not >> applied to any >>>>>>> interfaces. >>>>>>> >>>>>>> A similar problem would take place when using Confederations. >>>>>>> >>>>>>> The command that dumps the information on that P router or >> ANY router that >>>>>>> the route-targets are not configured on, is " no bgp >> default route-target >>>>>>> filter" under the BGP process. All of the RD information is >> seen. Even >>>>>>> more >>>>>>> than a router that has the RT's configured. >>>>>>> >>>>>>> >>>>>>> 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 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> 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 >> >> >> >> >> >> >> >> >> >> >> -- >> Narbik Kocharians >> CCSI#30832, CCIE# 12410 (R&S, SP, Security) >> www.MicronicsTraining.com <http://www.MicronicsTraining.com> >> <http://www.MicronicsTraining.com> >> Sr. Technical Instructor >> YES! We take Cisco Learning Credits! >> Training And Remote Racks available >> >> >> >> >> -- >> Narbik Kocharians >> CCSI#30832, CCIE# 12410 (R&S, SP, Security) >> www.MicronicsTraining.com <http://www.MicronicsTraining.com> >> Sr. Technical Instructor >> YES! We take Cisco Learning Credits! >> Training And Remote Racks available >> > > -- > Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina Blogs and organic groups at http://www.ccie.netReceived on Mon Aug 23 2010 - 08:50:46 ART
This archive was generated by hypermail 2.2.0 : Wed Sep 01 2010 - 11:20:53 ART