14.5 Inter-VRF export & Import

Hi,

any body has done this lab? with me its not working with give configs :(

what debug command will be used to see how import/export is working.

 

Frustrated... for any help thanks in advance.

 

 

Best Regards,

Comments

  • I am going to start putting documentation links in the forum for these labs..  Please add other useful CCO links.  Ideally, I would like these links to be in the documentation or at least the document Header so that we can find the docs and understand what Cisco is calling these features.

     

    Task 14.5 Inter-VRF export import

     

    CCO link:

    MPLS VPN—Route Target Rewrite

    http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_vpn_rte_target_rw_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1054641

     

    The above link may not be correct or it could be another option... 

     

    the solution references something else: http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_bgp2.html#wp1015138

     

  •  

     

    I just did this lab....

     

    It worked, and I was able to do see the changes when I was properly importing Loop 102 route via BGP from R6 (vrf_b) to R5 (vrf_a).

     

    sho ip route vrf VPN_A

    issue the above command before and after you configure the "Route-targe import 100:102"

    R5#

    ip vrf VPN_A
     rd 100:58
     export map VPN_A_export  <---- this is setting the Loopback 101 to RT 100:101 and BGP sends this to R6
     route-target export 100:1
     route-target import 100:1
     route-target import 100:102  <----- This is saying "accept" BGP routes with Route-target 100:102

     

    The VPN_A route table will once you issue the above commands (assuming R6) was previoulsy configured.

     

    I used a simple approach to validate; perhaps there is a command that will show the Route-targets before and or after the Route-map manipulates the EXtended Communities, but i am comfortable with looking at the RT.

    Here is a little more deeper review of my values.. first look at the BGP table for VRF VPN_B wichi is RD 100:67 and then I look at the extended community for the Prefix of loo102...

     

    Rack6R4#sho ip bgp vpnv4 rd 100:67
    BGP table version is 10, local router ID is 150.6.4.4
    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:67
    *>i155.6.67.0/24    150.6.6.6                0    100      0 ?
    *>i192.168.6.0      150.6.6.6                0    100      0 ?

    Now let's pick the loopback 102 prefix and see what the extneded community is as seen at R4 (after Export Map worked its magic).

    Rack6R4#sho ip bgp vpnv4 rd 100:67 192.168.6.0
    BGP routing table entry for 100:67:192.168.6.0/24, version 8
    Paths: (1 available, best #1, no table)
      Advertised to update-groups:
            2
      Local, (Received from a RR-client)
        150.6.6.6 (metric 2) from 150.6.6.6 (150.6.6.6)
          Origin incomplete, metric 0, localpref 100, valid, internal, best
          Extended Community: RT:100:102
          mpls labels in/out nolabel/23

     

    NET_OG

     

  • Just watched an MPLS tshoot video and the light switch has now been turned on!

    The main tasks requirement was as follows: Make sure R6’s VPN_A does not see the prefix 172.16.5.0/24 and R5’s VPN_B does not see the prefix 192.168.6.0/24.

    Well after some real head scratching and not been able to work out the route-map! Yes I know it's right but I think the task could do with some additional explanation with regards to the additional route-target contained within the route-map and to why it was been used...

    Anyway, "sh bgp vpnv4 unicast all neighbors 150.1.x.x advertised-routes" executed on the PE routers clearly shows that the routes to be filtered are being advertised to the opposing MBGP peer.  Now hop over to the peer and perfom a "debug bgp vpnv4 unicast updates" and you will see the contents of the route-map being dropped.

    I would have captured the debug output but Dynamips crashed!


    Rack1R5#sh bgp vpnv4 unicast all nei 150.1.4.4 adver
    BGP table version is 110, local router ID is 150.1.5.5
    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)
    *> 150.1.8.8/32     155.1.58.8               2         32768 ?
    *> 155.1.8.0/24     155.1.58.8               2         32768 ?
    *> 155.1.58.0/24    0.0.0.0                  0         32768 ?
    *> 155.1.108.0/24   155.1.58.8               2         32768 ?
    *> 172.16.5.0/24    0.0.0.0                  0         32768 ?       <-----------  R5 is advertising the route to R4 yet in R6's vrf VPN_A below it does not appear due to the export/import maps
    *> 172.16.8.8/32    155.1.58.8               2         32768 ?
    Route Distinguisher: 100:2 (default for vrf VPN_B)
    *> 155.1.5.0/24     0.0.0.0                  0         32768 ?

    Total number of prefixes 7

    Rack1R5#

    Rack1R6#sh ip route vrf VPN_A

    Routing Table: VPN_A
    Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
           D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
           N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
           E1 - OSPF external type 1, E2 - OSPF external type 2
           i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
           ia - IS-IS inter area, * - candidate default, U - per-user static route
           o - ODR, P - periodic downloaded static route

    Gateway of last resort is not set

         155.1.0.0/24 is subnetted, 4 subnets
    B       155.1.8.0 [200/2] via 150.1.5.5, 00:10:42
    B       155.1.58.0 [200/0] via 150.1.5.5, 00:10:42
    C       155.1.67.0 is directly connected, FastEthernet0/0.67
    B       155.1.108.0 [200/2] via 150.1.5.5, 00:10:42
         172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
    B       172.16.8.8/32 [200/2] via 150.1.5.5, 00:10:42
    O       172.16.7.7/32 [110/2] via 155.1.67.7, 00:11:07, FastEthernet0/0.67
    O       172.16.0.0/16 is a summary, 00:10:41, Null0
         150.1.0.0/32 is subnetted, 1 subnets
    B       150.1.8.8 [200/2] via 150.1.5.5, 00:10:42
    Rack1R6#

  • what if i just set a extended comminity in prefix which is not being imported by other PE than it will not be in virtual route table.

    thanks

    kamlesh

  • kamlesh,

    I am not quite sure what you are asking. The route-target is one of the extended community attributes that can be set:

    c3640a(config)#route-map VRF_EXPORT
    c3640a(config-route-map)#set extcommunity ?
      cost  Cost extended community
      rt    Route Target extended community
      soo   Site-of-Origin extended community
    c3640a(config-route-map)#set extcommunity rt ?
      ASN:nn or IP-address:nn  VPN extended community <cr>
    c3640a(config-route-map)#set extcommunity rt 500:500

    For VRF import/export the route-target (extcommunity rt) is the only attribute that is relevant.

    If you export a prefix with a route-target that no other router imports into a VRF, you are correct - that prefix will not appear in any other router's VRF routing table.

    Furthermore, unless "no bgp default route-target filter" is configured, or a router is a route-reflector for VPNv4, the prefix that nobody imports will not appear in the VPNv4 BGP table of any router except the PE router that exports the prefix from the VRF.

    what if i just set a extended comminity in prefix which is not being imported by other PE than it will not be in virtual route table.

    thanks

    kamlesh


  • I need to redo this lab.... thanks for the update.  I haven't touched MPLS for at least two months. 

Sign In or Register to comment.