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
-- Paul Negron CCIE# 14856 CCSI# 22752 Senior Technical Instructor www.micronicstraining.com > From: Adam Booth <adam.booth_at_gmail.com> > Reply-To: Adam Booth <adam.booth_at_gmail.com> > Date: Fri, 20 Aug 2010 20:07:42 +1000 > To: Carlos G Mendioroz <tron_at_huapi.ba.ar> > Cc: Brad Edgeworth <edgie512_at_gmail.com>, Cisco certification > <ccielab_at_groupstudy.com> > Subject: Re: MPLS Route Targets > > 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 > > _______________________________________________________________________ > Subscription information may be found at: > http://www.groupstudy.com/list/CCIELab.html Blogs and organic groups at http://www.ccie.netReceived on Fri Aug 20 2010 - 18:52:17 ART
This archive was generated by hypermail 2.2.0 : Wed Sep 01 2010 - 11:20:52 ART