Re: MPLS Route Targets

I had some bad wording and lack of clarification.

With my example, I have my BGP peering of R2-R3 (R3 as a route reflector)
and then R3 (Route Reflector again) to R4. I did not do a straight BGP
peering of R2-R4. I'm not familiar with how this works in the SP world,
but I used to think that the RT & RD was interchangeable terminology &
unique to a VPN instance. (Lesson is now learned).

Wasn't looking at the bgp default route-target filter....

I've used this technique before in the past for troubleshooting (and missed
the gaping hole of the export map). I think the issue is
resolved/educated :-P I should be fine for the R/S TS section (if it's
on there) Sounds like I need to do some more reading on SP MPLS before I
try to complicate things further...

On Fri, Aug 20, 2010 at 5:07 AM, Adam Booth <adam.booth_at_gmail.com> wrote:

> Hi Carlos,
>
> P routers don't need to run BGP at all as they are purely LSRs and not
> LERs, Maybe the only reason you may see BGP routes there is if for some
> reason you decided to make one a route-reflector due to its centralised
> location (would someone do this in production though?)
>
> Thanks for the correction/clarification on the other points.
>
> Cheers,
> Adam
>
>
>
>
> On Fri, Aug 20, 2010 at 7:55 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar>wrote:
>
>> Couple of points:
>> -I seriously doubt you will see ANY RT at the P routers :)
>> -RDs are not attached/associated to routes, but part of it.
>> I.e., you can think of RDs as part of the prefix, and as such,
>> no way to have two of them in one update.
>> RTs, on the other hand, are markers and you may have many.
>>
>> (You may have two updates with the same IPv4 prefix and different
>> RDs, but those would be two different routes)
>>
>> -Carlos
>>
>> Adam Booth @ 20/8/2010 1:05 -0300 dixit:
>>
>> Good catch Kambiz,
>>>
>>> While we're waiting for Brad to elaborate, I will stumble back in and try
>>> making a guess as to what he was on about :) I thought he was just
>>> explaining why purely looking at the RD wasn't enough and showing how to
>>> achieve what he wanted manually.
>>>
>>> Although there is no particular requirement in having the RD and RT use
>>> the
>>> same 64bit values, common practice and/or lazyness appears to be where
>>> possible, have them be the same, so executing "show ip bgp vpnv4 all"
>>> which
>>> only shows the RDs is probably good enough in a number of simple
>>> circumstances.
>>>
>>> However while I don't think you would ever have more than one RD
>>> associated
>>> with a prefix (at least from the same PE since the point is point is
>>> really
>>> to add some uniqueness to the prefix - though perhaps you may want this
>>> for
>>> anycast routes within your vpn especially if you're using
>>> route-reflectors...) you can certainly have multiple RTs attached to that
>>> prefix and this is where you can create some interesting things beyond
>>> the
>>> basic full-mesh.
>>>
>>> For example you may want certain services to share
>>> infrastructure/connectivity via an extranet - the route-map used to
>>> export
>>> is probably called to classify which routes get the extranet RT attached.
>>>
>>> Cheers,
>>> Adam
>>>
>>>
>>>
>>> On Fri, Aug 20, 2010 at 1:35 PM, Kambiz Agahian <aussiecert_at_gmail.com
>>> >wrote:
>>>
>>> Brad,
>>>>
>>>> I see two questions combined in one post. The second question is picked
>>>> up
>>>> and nicely answered by Adam - yes you can find those posts by just doing
>>>> a
>>>> quick search. Marko, one of our readers and myself answered the same
>>>> question using different methods.
>>>>
>>>> But the first question in your email (IMHO) still seems to be kind of
>>>> unanswered:
>>>>
>>>> I'd like to get on a P router and do a 'show ip bgp vpn4 all' to find
>>>>> all
>>>>>
>>>> the routes for a particular VPN Customer.. THe problem is that this
>>>> may
>>>> not work right if
>>>> you have an export map...
>>>>
>>>> What do you exactly mean?
>>>>
>>>> Kambiz Agahian
>>>>
>>>> CCIE Instructor/Consultant
>>>> M.Eng Telecom, CCIE# 25341, CCSI# 33326, MCSE, MCSA
>>>>
>>>>
>>>>
>>>> On Thu, Aug 19, 2010 at 5:53 PM, Brad Edgeworth <edgie512_at_gmail.com>
>>>> wrote:
>>>>
>>>> So I recently learned that 'route distinguishers' are slightly
>>>>> different
>>>>> from route-tags. When I troubleshoot MPLS route issues, I'd like to
>>>>> get
>>>>> on
>>>>> a P router and do a 'show ip bgp vpn4 all' to find all the routes for
>>>>> a
>>>>> particular VPN Customer.. THe problem is that this may not work right
>>>>>
>>>> if
>>>>
>>>>> you have an export map. Is there another command to will show all the
>>>>> route-targets with each route?
>>>>>
>>>>> Example Usage:
>>>>>
>>>>> R1 (CE) -- R2(PE) -- R3 (P) -- R4 (PE --Not relevant from here on out.)
>>>>>
>>>>> R2 Config:
>>>>>
>>>>> Ip vrf VPN_B
>>>>> rd 100:2
>>>>> route-target import 100:2
>>>>> route-target export 100:2
>>>>> export-map CHANGE_ROUTE_TARGET
>>>>>
>>>>> route-map CHANGE_ROUTE_TARGET permit 10
>>>>> match ip address prefix PRE_CHANGE_RT
>>>>> set extcommunity rt 100:200
>>>>>
>>>>> route-map CHANGE_ROUTE_TARGET permit 20
>>>>>
>>>>> ip prefix-list PRE_CHANGE_RT permit 175.1.5.0/24
>>>>>
>>>>> router bgp 100
>>>>> no bgp default ipv4-unicast
>>>>> neighbor 150.1.3,3 remote-as 100
>>>>> neighbor 150.1.3.3 update-source Loopback0
>>>>> !
>>>>> address-family vpnv4
>>>>> neighbor 150.1.3.3 activate
>>>>> neighbor 150.1.3.3 send-community extended
>>>>>
>>>>> address-family ipv4 vrf VPN_A
>>>>> redistribute connected
>>>>> redistribute ospf 10 vrf VPN_A
>>>>> no synchronization
>>>>>
>>>>>
>>>>> Ideally I'd like to find the command (if it exists) that will dump out
>>>>>
>>>> all
>>>>
>>>>> the route-targets riding inside the MPLS VPN similar to combining these
>>>>>
>>>> two
>>>>
>>>>> statements:
>>>>>
>>>>> Rack1R3# show ip bgp vpn4 all
>>>>> Network Next Hop Metric LocPrf Weight Path
>>>>> Route Distinguisher: *100:5* (default for vrf VPN_A)
>>>>> *>i175.1.1.0/24 150.1.2.2 0 100 0 ?
>>>>> *>i175.1.2.0/24 150.1.2.2 0 100 0 ?
>>>>> *>i175.1.3.0/24 150.1.2.2 1 100 0 ?
>>>>> *>i175.1.4.0/24 150.1.2.2 0 100 0 ?
>>>>> **>i175.1.5.0/32 150.1.2.2 2 100 0 ?*
>>>>>
>>>>> Rack1R3#show ip bgp vpn all 175.1.5.0
>>>>> BGP routing table entry for 100:5:175.1.5.0/24, version 39
>>>>> Paths: (1 available, best #1, table VPN_A)
>>>>> Advertised to update-groups:
>>>>> 1
>>>>> Local
>>>>> 0.0.0.0 from 0.0.0.0 (150.1.3.3)
>>>>> Origin incomplete, metric 0, localpref 100, weight 32768, valid,
>>>>> sourced, best
>>>>> Extended Community: RT:100:200 OSPF DOMAIN ID:0x0005:0x000000050200
>>>>> OSPF RT:0.0.0.1:2:0 OSPF ROUTER ID:150.1.3.3:0
>>>>> mpls labels in/out 21/aggregate(VPN_A)
>>>>>
>>>>>
>>>>> 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.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
Received on Fri Aug 20 2010 - 13:58:07 ART