Re: MPLS Route Targets

Yep. although didn't want to throw this at this stage but he MIGHT be
hitting the "*bgp default route-target filter" *feature which is on, on his
PE boxes.
Let's see what's going to come out...

PS1: As a bit of real world experience you usually don't see problems like
that in "real world" service providers; things like what's my RD or where's
my RT; everyone has their own numbering/naming convention that addresses
their issues.

PS2: The "no *bgp default route-target filter" command *could kill a real
world backbone! please don't use it just to make things look "clear"!
<disclaimer>

Kambiz Agahian

CCIE Instructor/Consultant
M.Eng Telecom, CCIE# 25341, CCSI# 33326, MCSE, MCSA

*
*
On Thu, Aug 19, 2010 at 9:05 PM, Adam Booth <adam.booth_at_gmail.com> wrote:

> 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
Received on Thu Aug 19 2010 - 21:16:30 ART