Tuesday, September 13, 2011

MPLS VPN - VRF Export Map


In MPLS VPN environment, VRF Export map provides better granularity to set the RT value to specific VPN prefix. Many people tempt to use export map as a filtering mechanism to identify which prefix to be advertised to remote PE neighbors. Please be aware that VRF Export Map cannot be used to filter prefix advertisement but to export RT value in a controlled manner.


 
Below are few test cases to understand how export map works in the above topology,

Test case 1 :

In this example, we will configure route-map with no match, but only set option to set RT value as 1234:5678 (without additive). We also configured “route-target export 100:100”.

ip vrf TEST
 rd 100:100
 export map NIL
route-target export 100:100
 route-target import 100:100
!
route-map NIL permit 10
 set extcommunity rt 1234:5678

 
With the above configuration, it can be observed that all VPN prefixes which were advertised as part of this VRF will be exported only with RT value of 1234:5678. Though we have “route-target export 100:100”, it will be overwritten by 1234:5678. This can be confirmed by looking into the BGP table of RR router as below,

R5#show ip bgp vpnv4 all 10.1.117.0
BGP routing table entry for 100:100:10.1.117.0/24, version 18
Paths: (1 available, best #1, no table)
  Advertised to update-groups:
     2        
  Refresh Epoch 1
  Local, (Received from a RR-client)
    10.1.7.7 (metric 51) from 10.1.7.7 (10.1.7.7)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:1234:5678 OSPF DOMAIN ID:0x0005:0x000000640200
        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.1.117.7:0
      mpls labels in/out nolabel/47
R5#

Since remote PE doesn’t import RT 1234:5678 in any of its VRF, the received BGP update with RT value of 1234:5678 will not be installed in BGP table. It will be dropped with below error message,

*Sep 13 14:55:42.003: BGP(4): 10.1.5.5 rcvd UPDATE w/ attr: nexthop 10.1.7.7, origin ?, localpref 100, metric 0, originator 10.1.7.7, clusterlist 10.1.5.5, extended community RT:1234:5678 OSPF DOMAIN ID:0x0005:0x000000640200 OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.1.117.7:0
*Sep 13 14:55:42.004: BGP(4): 10.1.5.5 rcvd 100:100:10.1.117.0/24, label 47 -- DENIED due to:  extended community not supported;
*Sep 13 14:55:42.004: BGP(4): no valid path for 100:100:10.1.117.0/24

Test case 2 :

In this example, we will configure route-map without any match statement, but with set option to set RT of value “1234:5678” along with additive option. We will also have “route-target export 100:100”.

ip vrf TEST
 rd 100:100
 export map ADDITIVE
 route-target export 100:100
 route-target import 100:100
!
route-map ADDITIVE permit 10
 set extcommunity rt 1234:5678 additive

With the above configuration, it can be observed that all VPN prefixes which were to be advertised as part of VRF will be exported with both RT of value “1234:5678” and “100:100”. Since we had additive option configured, route-map will not overwrite any existing RT community value in the UPDATE. This can be confirmed by looking into the BGP table as below,


R5#show ip bgp vpnv4 all 10.1.117.0
BGP routing table entry for 100:100:10.1.117.0/24, version 20
Paths: (1 available, best #1, no table)
  Advertised to update-groups:
     2        
  Refresh Epoch 1
  Local, (Received from a RR-client)
    10.1.7.7 (metric 51) from 10.1.7.7 (10.1.7.7)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:100:100 RT:1234:5678
        OSPF DOMAIN ID:0x0005:0x000000640200 OSPF RT:0.0.0.0:2:0
        OSPF ROUTER ID:10.1.117.7:0
      mpls labels in/out nolabel/47
R5#

Since RT 100:100 is imported in remote PE, it will be installed in BGP table and the corresponding VRF FIB and RIB tables as below,

R9#sho ip bgp vpnv4 all 10.1.117.0
BGP routing table entry for 100:100:10.1.117.0/24, version 72
Paths: (1 available, best #1, table TEST)
  Not advertised to any peer
  Refresh Epoch 3
  Local
    10.1.7.7 (metric 21) from 10.1.5.5 (10.1.5.5)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:100:100 RT:1234:5678
        OSPF DOMAIN ID:0x0005:0x000000640200 OSPF RT:0.0.0.0:2:0
        OSPF ROUTER ID:10.1.117.7:0
      Originator: 10.1.7.7, Cluster list: 10.1.5.5
      mpls labels in/out nolabel/47
R9#

Test case 3:

In this example, route-map was configured to explicitly deny prefix 10.1.117.0/24 while allowed other prefix (10.1.11.11/32) with set option to set RT of value 1234:5678.

ip vrf TEST
 rd 100:100
export map SELECTIVE_DENY
 route-target export 100:100
 route-target import 100:100
!
ip prefix-list PREFIX seq 5 permit 10.1.117.0/24
!
route-map SELECTIVE_DENY deny 10
 match ip address prefix-list PREFIX
route-map SELECTIVE_DENY permit 500
 set extcommunity rt 1234:5678 additive

With above configuration, it can be observed that the prefixes which were denied in route-map were sent with RT of value 100:100 as per “route-target export 100:100” configuration while others were sent with both 1234:5678 and 100:100. This can be confirmed in remote PE or RR BGP table as below,

R9#sho ip bgp vpnv4 all 10.1.117.0
BGP routing table entry for 100:100:10.1.117.0/24, version 73
Paths: (1 available, best #1, table TEST)
  Not advertised to any peer
  Refresh Epoch 3
  Local
    10.1.7.7 (metric 21) from 10.1.5.5 (10.1.5.5)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:100:100 OSPF DOMAIN ID:0x0005:0x000000640200
        OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:10.1.117.7:0
      Originator: 10.1.7.7, Cluster list: 10.1.5.5
      mpls labels in/out nolabel/47
R9#
R9#sho ip bgp vpnv4 all 10.1.11.11
BGP routing table entry for 100:100:10.1.11.11/32, version 71
Paths: (1 available, best #1, table TEST)
  Not advertised to any peer
  Refresh Epoch 3
  Local
    10.1.7.7 (metric 21) from 10.1.5.5 (10.1.5.5)
      Origin incomplete, metric 11, localpref 100, valid, internal, best
      Extended Community: RT:100:100 RT:1234:5678
        OSPF DOMAIN ID:0x0005:0x000000640200 OSPF RT:0.0.0.0:2:0
        OSPF ROUTER ID:10.1.117.7:0
      Originator: 10.1.7.7, Cluster list: 10.1.5.5
      mpls labels in/out nolabel/41
R9#

Conclusion:

From the above testing, it can be observed that export map cannot be used to filter prefix advertisement to remote PE devices. While Export map helps us to export RT value in a controlled manner, it doesn’t help us to filter prefixes.


Posted by at
Labels:

3 comments:

  1. AnonymousJanuary 26, 2012 at 6:17 AM

    Hi Nagendra,

    Great post, very clear and concise. It helped me understand the feature better.

    However, there is a way to use the export map as a filter. If you remove the "route-target export 100:100" from under ip vrf TEST, only routes permitted with the route-map will be assigned a RT and be exported.

    Routes denied by the filter will not have a RT assigned and therefore cannot be exported.

    Cheers

    ReplyDelete
  2. AnonymousJune 9, 2013 at 7:14 AM

    From my experience in some version of IOS "route-target export" is required to make router filter works at all. But It still possible to filter out some routes by assigned some fake RT by default and use route-map to assign proper RT to routes which need to be redistributed.

    ReplyDelete
  3. AnonymousJune 25, 2013 at 2:14 PM

    Hi, does the Route Map apply on a BGP neighbor. I would like to set RT depending to several WAN. Rgds.

    ReplyDelete

Subscribe to: Post Comments (Atom)