Re: MPLS Route Targets

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