Re: MPLS VPN Route Target Rewrite

Carlos,
Yes encryption will add to the confusion, i'm glad it was easy to break ;)
now i really feel like CCIE is a quest for knowledge with many
hidden obstacles :)

"If you had different RDs for R5 and R6, you would have 3 or 4 copies
of that route instead of just 2."

I think this is what I'm thinking:

Based on this debug (debug ip bgp vpn4 unicast import), the prefix *100:1:
172.16.5.0/24* comes in and has to be converted to *100:2:172.16.5.0/24, *but
because it's using RT of 100:55 (with no corresponding RD on that router),
that prefix is put under both MP-BGP subsets of VPN_A and VPN_B. A route
like 155.1.5.0/24 will not be displayed in both subsets of MP-BGP for VPN_A
and VPN_B as it has a matching RD from the other router. Am I correct here?

*Feb 1 00:22:24.024: vpn(4): Start import processing for: 100:1:
172.16.5.0/24
*Feb 1 00:22:24.024: vpn(4): Import check for VPN_B; flags match
*Feb 1 00:22:24.024: vpn(4): Import for VPN_B permitted; import flags match
*Feb 1 00:22:24.024: BGP(4): Prefix *100:1:172.16.5.0/24* to be imported as
*100:2:172.16.5.0/24* -- Permitted nexthop 150.1.5.5, origin ?, localpref
100, metric 0, originator 150.1.5.5, clusterlist 150.1.4.4, extended
community RT:100:55 Path added
*Feb 1 00:22:24.024: vpn(4): 100:1:172.16.5.0/24 (ver 3), imported as:
*Feb 1 00:22:24.024: vpn(4): 100:2:172.16.5.0/24 (ver 10)

R6#sh ip bgp vpnv4 all
BGP table version is 13, local router ID is 150.1.
Status codes: s suppressed, d damped, h history, *
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network Next Hop Metric Loc
Route Distinguisher: 100:1 (default for vrf VPN_A)
*>i155.1.58.0/24 150.1.5.5 0
*> 155.1.67.0/24 0.0.0.0 0
*>i172.16.5.0/24 150.1.5.5 0
Route Distinguisher: 100:2 (default for vrf VPN_B)
*>i155.1.5.0/24 150.1.5.5 0
*> 155.1.76.0/24 0.0.0.0 0
*>i172.16.5.0/24 150.1.5.5 0
*> 192.168.6.0 0.0.0.0 0

On Mon, Jan 31, 2011 at 4:47 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar>wrote:

> Tom Kacprzynski @ 31/01/2011 19:33 -0300 dixit:
>
>> Carlos,
>> Thank you again for your response. I think i'm following what you are
>> saying. I guess my main question is why R6 that receives a 172.16.5.0/24<
>> http://172.16.5.0/24> MP-BGP routes with a RT set to 100:55 is displayed
>> in the MP-BGP table for VRF VPN_A where that VRF does not have an import of
>> RT 100:55?
>>
>
> It is not the "MP-BGP table for vrf VPN_A", but the MP-BGP subset
> with RD corresponding to vrf VPN_A in this router.
>
> Subtle, but important difference.
> What is a VPN is your design decision. What is a VRF is something that
> cisco has defined how it works.
>
>
> I understand that this route is not imported (by design) to the actual
>> forwarding table for VRF VPN_A and only appears in VRF VPN_B; to me it seems
>> that both the BGP table and the ip forwarding tables should show
>> corresponding data.
>>
>
> Well, they have corresponding data, not the same data because you have
> the ability to filter what goes from BGP vpnv4 (global) to BGP vrf
> unicast, and then to vrf RIB.
>
> Pay attention, you have actually 2 172.16.5.0/24 routes in vpnv4!
> Ready for more confusion ? Don't think so, so this goes rot13:
>
> Vs lbh unq qvssrerag EQf sbe E5 naq E6, lbh jbhyq unir 3 be 4 pbcvrf
> bs gung ebhgr vafgrnq bs whfg 2.
>
> -Carlos
>
>>
>>
>> Output for reference:
>>
>> Rack1R6#*show ip bgp vpnv4 all*
>> BGP table version is 41, local router ID is 150.1.6.6
>> Status codes: s suppressed, d damped, h history, * valid, > best, i -
>> internal,
>> r RIB-failure, S Stale
>> Origin codes: i - IGP, e - EGP, ? - incomplete
>>
>> Network Next Hop Metric LocPrf Weight Path
>> Route Distinguisher: 100:1 (*default for vrf VPN_A*)
>> <----- VPN_A, why is it displayed here, 100:55 RT is not imported into this
>> VRF, and it does not have the RT 100:1 set as an extended community on the
>> advertised route.
>> *>i155.1.58.0/24 150.1.5.5 0 100 0 ?
>> *> 155.1.67.0/24 <http://155.1.67.0/24> 0.0.0.0 0
>> 32768 ?
>> **>i172.16.5.0/24 150.1.5.5 0 100 0 ?
>> <*---- 172.16.5.0/24 <http://172.16.5.0/24>
>> *> 172.16.7.0/24 <http://172.16.7.0/24> 155.1.67.7 0
>> 32768 ?
>>
>>
>> Route Distinguisher: 100:2 (default for vrf VPN_B)
>> <----- VPN_B
>> *>i155.1.5.0/24 150.1.5.5 0 100 0 ?
>> *> 155.1.76.0/24 <http://155.1.76.0/24> 0.0.0.0 0
>> 32768 ?
>> **>i172.16.5.0/24 150.1.5.5 0 100 0 ?**
>> <*---- 172.16.5.0/24 <http://172.16.5.0/24>
>>
>> *> 192.168.6.0 0.0.0.0 0 32768 ?
>> *> 192.168.7.0 155.1.76.7 0 32768 ?
>>
>>
>>
>> Rack1R6#*show ip bgp vpnv4 vrf VPN_A*
>> BGP table version is 41, local router ID is 150.1.6.6
>> Status codes: s suppressed, d damped, h history, * valid, > best, i -
>> internal,
>> r RIB-failure, S Stale
>> Origin codes: i - IGP, e - EGP, ? - incomplete
>>
>> Network Next Hop Metric LocPrf Weight Path
>> Route Distinguisher: 100:1 (*default for vrf VPN_A*)
>> <----- no 172.16.5.0/24 <http://172.16.5.0/24> route (see below)
>>
>> *>i155.1.58.0/24 150.1.5.5 0 100 0 ?
>> *> 155.1.67.0/24 <http://155.1.67.0/24> 0.0.0.0 0
>> 32768 ?
>> *> 172.16.7.0/24 <http://172.16.7.0/24> 155.1.67.7 0
>> 32768 ?
>>
>>
>>
>> Thank you for you help on this.
>>
>> TK
>>
>>
>>
>> On Sun, Jan 30, 2011 at 12:23 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar<mailto:
>> tron_at_huapi.ba.ar>> wrote:
>>
>> Tom,
>> RDs make part of the route identifier, i.e., the update object that
>> MP-BGP transmits. RTs are communities, i.e., information elements
>> that go with the update.
>>
>> You are seeing the 100:1:172.16.5.0/24 <http://172.16.5.0/24> in
>>
>> both R5 and R6, and it has
>> the RT 100:55.
>>
>> Now, at R6, you can see this route with "show ip bgp vpnv4 all" because
>> you are asking for ALL vpnv4 routes.
>> It is even listed under the 100:1 section, wich is VPN_A RD at R6
>> (and R5, which is generating this route).
>>
>> But at R6, you are importing only RT 100:1 into VPN_A, and this route
>> does not have this RT, so the route does not make it into vrf VPN_A.
>>
>> Makes sense ?
>> Some guys will advise you not to use the same RD at different routers,
>> so you will not get this confusing states. In production, I would
>> actually agree. But for the IE, I'd prefer to have it very clear how
>> it works.
>>
>> -Carlos
>>
>> Tom Kacprzynski @ 30/01/2011 12:49 -0300 dixit:
>>
>> Carlos,
>> Thank you for your reply. My configuration is below, but
>> basically i'm
>> trying to take the route 172.16.5.0/24 <http://172.16.5.0/24>
>>
>> from VPN_A on R5, rewrite its
>> extended community route tag to 100:55 and have that route-tag
>> imported into
>> VPN_B on R6. I have to say that it does work in terms that only
>> VPN_B sees
>> it, but i don't understand why it shows that route in both BGP
>> VPNv4 tables
>> for VPN_A and VPN_B.
>>
>> R6#
>> ip vrf VPN_A
>> rd 100:1
>> route-target export 100:1
>> route-target import 100:1
>> ip vrf VPN_B
>> rd 100:2
>> route-target export 100:2
>> route-target import 100:2
>> * route-target import 100:55*
>>
>> R5#
>> ip vrf VPN_A
>> rd 100:1
>> export map VPN-A-EXPORT
>> route-target export 100:1
>> route-target import 100:1
>> route-target import 100:55
>> ip vrf VPN_B
>> rd 100:2
>> route-target export 100:2
>> route-target import 100:2
>>
>>
>> R5#sh route-map VPN-A-EXPORT
>> route-map VPN-A-EXPORT, permit, sequence 10
>> Match clauses:
>> ip address prefix-lists: LO101
>> Set clauses:
>> extended community RT:100:55
>> Policy routing matches: 0 packets, 0 bytes
>> route-map VPN-A-EXPORT, permit, sequence 100
>> Match clauses:
>> Set clauses:
>> extended community RT:100:1
>> Policy routing matches: 0 packets, 0 bytes
>>
>> Thank you.
>>
>> TK
>>
>>
>> On Sat, Jan 29, 2011 at 11:45 AM, Carlos G Mendioroz
>> <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>wrote:
>>
>>
>> Sounds like a problem with the import RT for vrf VPN_A ?
>> The route is there with RT 100:55. What are you importing ?
>> -Carlos
>>
>> Tom Kacprzynski @ 29/01/2011 14:23 -0300 dixit:
>>
>> Hello experts,
>> Doing a lab wiht MP-BGP and can't seem to figure out how
>> is it possible to
>> get this output. When I do *show ip bgp vpnv4 vrf VPN_A
>> *I don't see
>> 172.16.5.0/24 <http://172.16.5.0/24> route, but when i
>>
>> do *show ip bgp vpnv4 all *I see that
>> same
>> route. Shouldn't both of them show the same information.
>> I this lab (INE
>> 14.5) I'm asked to rewrite that prefix's route target
>> and export it from
>> one VRF table to the VPN_A table.
>>
>> Rack1R6#*show ip bgp vpnv4 vrf VPN_A*
>> BGP table version is 41, local router ID is 150.1.6.6
>> Status codes: s suppressed, d damped, h history, *
>> valid, > best, i -
>> internal,
>> r RIB-failure, S Stale
>> Origin codes: i - IGP, e - EGP, ? - incomplete
>>
>> Network Next Hop Metric LocPrf
>> Weight Path
>> Route Distinguisher: 100:1 (*default for vrf VPN_A*)
>> <----- no 172.16.5.0/24 <http://172.16.5.0/24> route
>>
>> (see below)
>> *>i155.1.58.0/24 150.1.5.5 0 100
>> 0 ?
>> *> 155.1.67.0/24 <http://155.1.67.0/24> 0.0.0.0
>> 0 32768 ?
>> *> 172.16.7.0/24 <http://172.16.7.0/24> 155.1.67.7
>> 0 32768 ?
>>
>>
>>
>> Rack1R6#*show ip bgp vpnv4 all*
>> BGP table version is 41, local router ID is 150.1.6.6
>> Status codes: s suppressed, d damped, h history, *
>> valid, > best, i -
>> internal,
>> r RIB-failure, S Stale
>> Origin codes: i - IGP, e - EGP, ? - incomplete
>>
>> Network Next Hop Metric LocPrf
>> Weight Path
>> Route Distinguisher: 100:1 (*default for vrf VPN_A*)
>> *>i155.1.58.0/24 150.1.5.5 0 100
>> 0 ?
>> *> 155.1.67.0/24 <http://155.1.67.0/24> 0.0.0.0
>> 0 32768 ?
>>
>> **>i172.16.5.0/24 150.1.5.5 0 100
>> 0 ?
>> <*---- 172.16.5.0/24 <http://172.16.5.0/24>
>> *> 172.16.7.0/24 <http://172.16.7.0/24> 155.1.67.7
>> 0 32768 ?
>>
>> Route Distinguisher: 100:2 (default for vrf VPN_B)
>> *>i155.1.5.0/24 150.1.5.5 0 100
>> 0 ?
>> *> 155.1.76.0/24 <http://155.1.76.0/24> 0.0.0.0
>> 0 32768 ?
>>
>> **>i172.16.5.0/24 150.1.5.5 0 100
>> 0 ?**
>> <*---- 172.16.5.0/24 <http://172.16.5.0/24>
>>
>> *> 192.168.6.0 0.0.0.0 0
>> 32768 ?
>> *> 192.168.7.0 155.1.76.7 0
>> 32768 ?
>>
>>
>>
>>
>> Rack1R6#*show ip bgp vpnv4 all 172.16.5.0*
>> BGP routing table entry for 100:1:172.16.5.0/24
>> <http://172.16.5.0/24>, version 31
>>
>> Paths: (1 available, best #1, *no table*)
>> Not advertised to any peer
>> Local
>> 150.1.5.5 (metric 66) from 150.1.4.4 (150.1.4.4)
>> Origin incomplete, metric 0, localpref 100, valid,
>> internal, best
>> Extended Community: RT:100:55
>> Originator: 150.1.5.5, Cluster list: 150.1.4.4
>> mpls labels in/out nolabel/25
>> BGP routing table entry for 100:2:172.16.5.0/24
>> <http://172.16.5.0/24>, version 34
>>
>> Paths: (1 available, best #1, table *VPN_B*)
>> Not advertised to any peer
>> Local, imported path from 100:1:172.16.5.0/24
>> <http://172.16.5.0/24>
>>
>> 150.1.5.5 (metric 66) from 150.1.4.4 (150.1.4.4)
>> Origin incomplete, metric 0, localpref 100, valid,
>> internal, best
>> Extended Community: RT:100:55
>> Originator: 150.1.5.5, Cluster list: 150.1.4.4
>> mpls labels in/out nolabel/25
>>
>>
>> Thank you for any help.. i'm really stuck on this and
>> can't figure it out.
>> I
>> fee like i'm missing some piece of information.
>>
>>
>> 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
>> <mailto: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 <mailto:tron_at_huapi.ba.ar
>> >>
>> LW7 EQI Argentina
>>
>>
>>
> --
> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina

Blogs and organic groups at http://www.ccie.net
Received on Mon Jan 31 2011 - 18:35:28 ART