Re: VRF: exporting partial routing table

excellent man. You're the champ!
thanks for your time in labbing it up.

On Wed, May 26, 2010 at 2:32 AM, Ruhann <groupstudy_at_ru.co.za> wrote:

> Here is a little lab showing the different possibilities:
> - Default RT export with "rt export {asn:xx}
> - Explicit RT attach via route-map "set extcommunity rt {asn:xx}
> - Explicit RT attach but with the 'additive' keyword
>
> TOPOLOGY:
> R1 (CE) ----- R2(PE)------R5(PE)
> R2 runs a VRF called RED and R5 a VRF GREEN
>
>
> I configured 3 loopbacks on R1 which is advertised via eBGP:
> 100.100.100.0/24
> 100.100.200.0/24
> 100.100.33.0/24
>
> R1 config is standard. Three loopbacks and normal eBGP peering with R2.
> Here is R2's config:
>
> CONFIG-SET
> +====================
> | ip prefix-list loop100 seq 5 permit 100.100.100.0/24
> | ip prefix-list loop200 seq 5 permit 100.100.200.0/24
> | !
> | !
> | route-map R2export permit 10
> | match ip address prefix-list loop100
> | set extcommunity rt 100:100
> | !
> | route-map R2export permit 20
> | match ip address prefix-list loop200
> | set extcommunity rt 100:200 additive
> | !
> | !
> | ip vrf RED
> | rd 100:1
> | export map R2export
> | route-target export 100:1
> | route-target import 100:2
> | !
> | !
> | interface Loopback0
> | ip address 10.0.0.2 255.255.255.255
> | !
> | interface FastEthernet1/0
> | ip vrf forwarding RED
> | ip address 10.5.12.2 255.255.255.0
> | !
> | interface Serial0/1.25 point-to-point
> | ip address 10.5.25.2 255.255.255.252
> | mpls ip
> | frame-relay interface-dlci 105
> | !
> | !
> | router ospf 100
> | log-adjacency-changes
> | redistribute eigrp 100 subnets
> | network 10.5.25.2 0.0.0.0 area 0
> | network 10.0.0.2 0.0.0.0 area 0
> | !
> | !
> | router bgp 100
> | neighbor 10.0.0.5 remote-as 100
> | neighbor 10.0.0.5 update-source Loopback0
> | !
> | address-family ipv4
> | neighbor 10.0.0.5 activate
> | !
> | address-family vpnv4
> | neighbor 10.0.0.5 activate
> | neighbor 10.0.0.5 send-community extended
> | !
> | address-family ipv4 vrf RED
> | neighbor 10.5.12.1 remote-as 10000
> | neighbor 10.5.12.1 activate
>
> Looking closely at the route-map.
> It matches two of the loopbacks.
> 100.100.100.0/24 will get only one RT (100:100) attached
> 100.100.200.0/24 will get RT (100:200) attached as well as the default
> export RT (100:1)
>
> Then 100.100.33.0/24 is just a normal vrf route, that with normal
> treatment.
> IE it will only get the default export rt (100:1)
>
> Here you can see al three behaviour in the BGP output:
> Rack6R2#sh ip bgp vpnv4 vrf RED 100.100.33.0
> BGP routing table entry for 100:1:100.100.33.0/24, version 8
> Paths: (1 available, best #1, table RED)
> 10.5.12.1 from 10.5.12.1 (10.0.0.1)
> Origin IGP, metric 0, localpref 100, valid, external, best
> Extended Community: RT:100:1 !<-- ONLY DEFAULT RT
> mpls labels in/out 16/nolabel
>
> Rack6R2#sh ip bgp vpnv4 vrf RED 100.100.100.0
> BGP routing table entry for 100:1:100.100.100.0/24, version 2
> Paths: (1 available, best #1, table RED)
> 10.5.12.1 from 10.5.12.1 (10.0.0.1)
> Origin IGP, metric 0, localpref 100, valid, external, best
> Extended Community: RT:100:100 !<-- ONE CUSTOM RT
> mpls labels in/out 21/nolabel
>
> Rack6R2#sh ip bgp vpnv4 vrf RED 100.100.200.0
> BGP routing table entry for 100:1:100.100.200.0/24, version 3
> Paths: (1 available, best #1, table RED)
> 10.5.12.1 from 10.5.12.1 (10.0.0.1)
> Origin IGP, metric 0, localpref 100, valid, external, best
> Extended Community: RT:100:1 RT:100:200 <--CUSTOM & DEFAULT
> mpls labels in/out 22/nolabel
>
>
> R5's VRF config
> +===============
> | ip vrf GREEN
> | rd 100:2
> | route-target export 100:2
> | route-target import 100:1
> | route-target import 100:200
>
> So R5 will only import 2 of the 3 routes.
> 100.100.200.0/24
> 100.100.33.0/24
>
> Rack6R5#sh ip route vrf GREEN | i 100.100
> B 100.100.33.0 [200/0] via 10.0.0.2, 00:00:20
> B 100.100.200.0 [200/0] via 10.0.0.2, 00:00:20
>
> That should clear up all yoru questions :D
>
> I suppose let me include the group :)
>
> HTH
> --
> <ruhann>
> www.routing-bits.com
>
>
>
> On Tue, May 25, 2010 at 6:03 PM, Ruhann <groupstudy_at_ru.co.za> wrote:
> > The 'additive' keyword is community specific and not vrf specific, and
> > on Cisco IOS is specific to the route-map.
> >
> > Look at this config:
> >
> > | route-map EX-MAP permit 20
> > | match ip add 55
> > | set extcommunity rt 444:777
> > | !
> > | ip vrf CLIENT-B
> > | rd:444:555
> > | route-target import 444:444
> > | route-target export 444:444
> > | export map EX-MAP
> >
> >
> > This will accoumplish the following:
> > > If a route matches ACL-55, it will have RT 444:777 ONLY attached.
> > > Other routes not matched by the ACL will have the default RT
> > attached 444:444,
> > as per the default export statement.
> >
> > Now say you want to attach multiple communities to the BGP route?
> > This is when the 'additive' keyword will be used.
> >
> > If the config is changed to :
> >
> > | route-map EX-MAP permit 20
> > | match ip add 55
> > | set extcommunity rt 444:777 additive
> > | !
> > | ip vrf CLIENT-B
> > | rd:444:555
> > | route-target import 444:444
> > | route-target export 444:444
> > | export map EX-MAP
> >
> > The the following changes:
> > > If a route matches ACL-55, it will have RT 444:777 attached and in
> addition
> > RT 444:444 would also be attached. I.E. 10.1.1.0/24 will have two
> RT's.
> > > Other routes not matched by the ACL will have the default RT
> > attached 444:444,
> > as per the default export statement.
> >
> > Just two other notes.
> > 1- The RT/RD values should be ASN:{number}.
> > You are using different ASN in your config: 444:444 and 555:555
> >
> > 2- The 'set' in the route-map for RT's attaching is "set extcommunity
> rt",
> > Dont forget the RT keyword :)
> >
> > On Tue, May 25, 2010 at 4:22 PM, Radioactive Frog <pbhatkoti_at_gmail.com>
> wrote:
> >> also do we need AADDICTIVE IN ROUTE MAP?
> >>
> >> On Wed, May 26, 2010 at 12:20 AM, Radioactive Frog <pbhatkoti_at_gmail.com
> >
> >> wrote:
> >>>
> >>> quick one...
> >>> can you validate it?
> >>>
> >>> lets say i have a Shared VRF where all Customer's VRF terminates for
> >>> shared services.
> >>>
> >>> ip vrf SHARED
> >>> RD:444:444
> >>> route-target export 444:444 ! export shared vrf all route
> >>> route-target import 555:555 ! import filter routes from CUST-A
> >>>
> >>> ip vrf CLIENT-B
> >>> rd:555:555
> >>> route-target import 444:444 ! import full routing table from
> SharedVRF
> >>> export map EX-MAP
> >>>
> >>> access-list 55 permit 10.1.1.0/ 0.0.0.255
> >>> !
> >>> route-map EX-MAP permit 20
> >>> match ip add 55
> >>> set extcommunity 444:444 ! set RT on ACL 55 to 4444:444 so that it
> can
> >>> be imported by Shared VRF
> >>>
> >>>
> >>> Let's say shared vrf has 200 routes - they will get all imported into
> >>> CLIENT-B's table.
> >>> also Only ACL 55 will be imported by Shared VRF because we've specified
> >>> export map in Client-B's vrf and told it only export route-map EX-MAP
> >>>
> >>>
> >>>
> >>>
> >>> On Tue, May 25, 2010 at 8:25 PM, Ruhann <groupstudy_at_ru.co.za> wrote:
> >>>>
> >>>> nope
> >>>> You have to manually attached the RT's you want that usually happens
> with
> >>>> the
> >>>> command "route-target export 1:2"
> >>>>
> >>>> Have a look as this example
> >>>>
> >>>> CONFIG-SET: MPLS-VPN - Selective VRF Export
> >>>> +--------------------------------------------------
> >>>> | access-list 55 permit 10.1.1.0 0.0.0.255
> >>>> | !
> >>>> | route-map EX-MAP permit 20
> >>>> | match ip address 55 ! References ACL-55
> >>>> | set extcommunity rt 123:55 ! Attaches RT 123:55 to
> 10.1.1.0/24
> >>>> | !
> >>>> | !
> >>>> | ip vrf CLIENT-B
> >>>> | rd 123:789
> >>>> | export map EX-MAP ! Applies the export-map
> >>>> | route-target import 123:789 ! Imports all MPBGP routes with a
> RT
> >>>> of 123:789
> >>>> | route-target export 123:789 ! All VRF CLIENT-A RIB routes not
> >>>> matched by
> >>>> | the EX-MAP is
> exported
> >>>> with a RT of 123:789
> >>>> |
> >>>>
> >>>> HTH
> >>>>
> >>>> --
> >>>> <ruhann>
> >>>> www.routing-bits.com
> >>>>
> >>>> On Tue, May 25, 2010 at 9:21 AM, Radioactive Frog <
> pbhatkoti_at_gmail.com>
> >>>> wrote:
> >>>> > thanks Ruhann,
> >>>> >
> >>>> > will below do the job or I have to add another line in route-map ?
> >>>> >
> >>>> > export only 100.100.100.0/24 (blueVRF) routes into RED vrf
> >>>> >
> >>>> > ip vrf RED
> >>>> > rd 1:1
> >>>> > route-target export 1:1
> >>>> > route-target import 1:2
> >>>> >
> >>>> > ip vrf BLUE
> >>>> > rd 1:2
> >>>> > export map BLUE
> >>>> > route-target import 1:1
> >>>> >
> >>>> > route-map BLUE
> >>>> > match ip address 1
> >>>> >
> >>>> > access-list 1 permit 100.100.100.0 0.0.0.255
> >>>> >
> >>>> >
> >>>> > On Tue, May 25, 2010 at 5:12 PM, Ruhann <groupstudy_at_ru.co.za>
> wrote:
> >>>> >>
> >>>> >> yip that is purpose of the export route-map, to selectively export
> >>>> >> only certain routes.
> >>>> >> you on the money as usual. :)
> >>>> >>
> >>>> >> On Tue, May 25, 2010 at 5:44 AM, Radioactive Frog
> >>>> >> <pbhatkoti_at_gmail.com>
> >>>> >> wrote:
> >>>> >> > trying to find quick and easy way - What is the best way to
> export
> >>>> >> > partial
> >>>> >> > routes into/between the VRF(s)
> >>>> >> >
> >>>> >> > VRF: red - 10 routes (192.168.1-10.x/24)
> >>>> >> > VRF; blue - 10 routes ( 193.1.1-10.x/24)
> >>>> >> >
> >>>> >> > I want only 5 routes to export from RED_vrf to Blue VRF.
> >>>> >> >
> >>>> >> > route-target export exports everything.
> >>>> >> >
> >>>> >> > I haven't tried MAP with route-export so would like to see
> group's
> >>>> >> > openion
> >>>> >> > on quick way to do it.
> >>>> >> >
> >>>> >> > thanks
> >>>> >> >
> >>>> >> >
> >>>> >> > Blogs and organic groups at http://www.ccie.net
> >>>> >> >
> >>>> >> >
> >>>> >> >
> _______________________________________________________________________
> >>>> >> > Subscription information may be found at:
> >>>> >> > http://www.groupstudy.com/list/CCIELab.html
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>> >>
> >>>> >>
> >>>> >
> >>>
> >>
> >>
> >
> >
> >
> > --
> > <ruhann>
> > www.routing-bits.com

Blogs and organic groups at http://www.ccie.net
Received on Wed May 26 2010 - 09:25:53 ART