Re: MPLS VPN Route Target Rewrite

Tom,

Tom Kacprzynski @ 31/01/2011 21:35 -0300 dixit:
> 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 :)

Well, you got over it quick enough :)

>
> "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:

Be careful with this kind of meta statements :)

>
> 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?

Ouch, it's hard for me to follow this. But...
"that prefix is put under both MP-BGP subsets of VPN_A and VPN_B"
does not sound right to me.

vpnv4 routes come from 2 places:
-MP-BGP neighbours
-vrfs via export

The former come with RD already set by the neighbour.
The later are made by combining the vrf BGP prefix and the vrf RD.

And this process is controlled by import targets, export targets and
export route maps.

Try to draw it. Remember that a vrf can import a route from vpnv4 and
export it with another RD (and RT). This works much like redistribution.

-Carlos
>
>
> *Feb 1 00:22:24.024: vpn(4): Start import processing for:
> 100:1:172.16.5.0/24 <http://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
> <http://172.16.5.0/24>* to be imported as *100:2:172.16.5.0/24
> <http://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 <http://172.16.5.0/24>
> (ver 3), imported as:
> *Feb 1 00:22:24.024: vpn(4): 100:2:172.16.5.0/24 <http://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 <http://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 <http://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
> <mailto: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> <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
> <http://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> <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>
> <http://172.16.5.0/24>
> *> 172.16.7.0/24 <http://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> <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> <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>
> <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> <http://155.1.67.0/24>
> 0.0.0.0 0 32768 ?
> *> 172.16.7.0/24 <http://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>
> <mailto: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>
> <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> <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>
> <mailto: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>
> <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>
> <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>
> <http://155.1.67.0/24> 0.0.0.0
> 0 32768 ?
> *> 172.16.7.0/24 <http://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>
> <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>
> <http://172.16.5.0/24>
> *> 172.16.7.0/24 <http://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>
> <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>
> <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>
> <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>
> <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>
> <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>
> <mailto: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> <mailto:tron_at_huapi.ba.ar
> <mailto:tron_at_huapi.ba.ar>>>
> LW7 EQI Argentina
>
>
>
> --
> 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