Re: MPLS Route Targets

Joseph,

Good for you. You should always check for yourself. Do not simply believe
anyone. That is exactly what I wish for each and every one of you. It is
also what I believe Carlos is trying to do.( I will give him the benefit of
the doubt). CCIE's are full of it man!!! :-) Ha!!!!

Happy labbing!!!
 
Paul Negron
CCIE# 14856 CCSI# 22752
Senior Technical Instructor
www.micronicstraining.com

> From: "Joseph L. Brunner" <joe_at_affirmedsystems.com>
> Date: Mon, 23 Aug 2010 10:57:32 -0400
> To: Paul Negron <negron.paul_at_gmail.com>, Carlos G Mendioroz <tron_at_huapi.ba.ar>
> 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>
> Conversation: MPLS Route Targets
> Subject: RE: MPLS Route Targets
>
> Perfect job interview questions I can use on people. Thanks Paul!
>
> "Do RD's have to match between PE routers?"
>
> "How would you CONFIGURE THE NETWORK to reflect a scenario where different
> companies were not using the same RD's"
>
> Wow, I'm going back on dynamips to answers those :)
>
> Thanks!
>
> -----Original Message-----
> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of Paul
> Negron
> Sent: Monday, August 23, 2010 10:51 AM
> To: Carlos G Mendioroz
> Cc: Narbik Kocharians; Adam Booth; Brad Edgeworth; Cisco certification
> Subject: Re: MPLS Route Targets
>
> 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.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 Mon Aug 23 2010 - 09:14:31 ART