Probable reasons BGP isn't installing a route

Although perhaps only one route to a destination exists, there are a number of reasons BGP might not select it as a "best" route (consequently omitting it from the routing table). Below are some of the most common causes.

Synchronization is enabled and the route is not known by an IGP

If synchronization is enabled, BGP requires each route to be known by an IGP before placing it in the routing table. This is considered legacy behavior and isn't typically enforced on modern networks. Synchronization is easily disabled:

Router(config-router)# no synchronization

In fact, synchronization is disabled by default beginning with IOS release 12.2(8)T.

NEXT_HOP is inaccessible

If the router doesn't know how to reach a route's next hop, a recursive lookup will fail, and the route can't be added to BGP. For example, if a BGP router receives a route for 10.0.0.0/8 with a NEXT_HOP attribute of 192.168.0.1, but doesn't have an entry in its routing table for a subnet containing 192.168.0.1, the received route for 10.0.0.0/8 is useless and won't be installed in the routing table.

AS_PATH includes the local AS

If a route advertised by an external (eBGP) neighbor includes the local AS in its AS_PATH attribute, the route will be rejected. This is a loop prevention mechanism used by BGP, and it is a fundamental concept of the protocol. However, there may be instances when you want to bend this rule and allow such routes anyway. This can be accomplished by appending the allowas-in keyword to a neighbor statement:

Router(config-router)# neighbor 1.2.3.4 allowas-in

As this configuration results in somewhat abnormal BGP behavior, exercise caution to avoid creating routing loops.

Attempting to readvertise iBGP-learned routes to iBGP neighbors

BGP won't advertise a route learned from an internal (iBGP) neighbor to other internal neighbors. To achieve full convergence within an autonomous system, it is recommended to configure mesh adjacencies, or to employ route reflectors or confederations.

Rejection by inbound policy

Routes may be being unintentionally blocked by an inbound route-map applied to the BGP neighbor. This can be inspected by comparing the output of two variations of the show ip bgp neighbor command:

Router# show ip bgp nei 172.16.0.2 received-routes
BGP table version is 6, local router ID is 192.168.1.1
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
*  192.168.2.0      172.16.0.2             100             0 65200 ?
*  192.168.3.0      172.16.0.2             100             0 65200 ?

Total number of prefixes 2

The first command displays all routes being advertised by the specified neighbor. Note that inbound soft-reconfiguration must be enabled for the neighbor in order for this command to produce any useful output.

Router# show ip bgp nei 172.16.0.2 routes
BGP table version is 6, local router ID is 192.168.1.1
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
*  192.168.3.0      172.16.0.2             100             0 65200 ?

Total number of prefixes 1

This second command lists all routes from the neighbor which have been entered into the routing table. The above output reveals that only one of the advertised routes (192.168.3.0/24) is being allowed through the inbound routing policy for this neighbor. When this happens, double-check the route-map applied inbound.

VRF Import map / Export map

Hello everybody,
today I dived into some MPLS and I stumbled upon VRF Import map and VRF Export map
I was a bit confused by Keith's explanation (INE MPLS class) when he implemented VRF Export map.
He created a route-map to add specific Route-Target to a matching route and then said then an empty route-map entry needs to be created so that other updates (without modifying RT will be permitted to be exported as well)

However, when I labbed it up, it worked even without that permit any entry in the route-map

So I digged deeper and here is what I found out
when I want to control what is going to be imported into VRF I have 2 options
route-target import AS:NN and optionally import map NAME
-> when using only the route-target import AS:NN, all routes that have the extended community set to AS:NN will be imported
-> when using only import map NAME, nothing get imported
-> when using both, only the routes that have the extended community set to AS:NN AND are allowed in the route-map will be imported

this is what Cisco material says as well (http://www.cisco.com/en/US/docs/ios/mpl ... #wp1012826)


when I want to control what is going to be exported out of VRF I have 2 options
route-target export AS:NN and optionally export map NAME
-> when using only the route-target export AS:NN, all routes being exported will have the extended community set to AS:NN
-> when using only the export map NAME, only routes allowed in the route map will have the extended community set and will be exported
-> when using both, all routes will be exported, no matter how restrictive the export map might be

so apparently if a export map is marking only some routes with the same extended community value and route-target export is marking all with the same extended community value routes, in the end all routes will be marked, even the ones that were denied by the selective route-map

which basically matches what Cisco says here (http://www.cisco.com/en/US/docs/ios/mpl ... #wp1012602)


so with this facts confirmed, let's have a situation like this
we have 4 routes that we are exporting

Code:

route-target export 10:43
route target export 10:44
export map ADD_45

route-map ADD_45 permit 10
match ip address prefix-list <IP PREFIX-LIST THAT MATCHES ONLY 1 ROUTE>
set extcommunity rt 10:45 additive

all 4 routes are have an extended community set to 10:43
all 4 routes are have an extended community set to 10:44
one of these 4 routes has an extended community set to 10:45

I confirmed this in my GNS3 topology

Sooo to sum it up
By default every route-map ends with an implicit deny any and this case is no exception
there is no need to add a permit any statement to the route-map

export map does not filter the routes being exported (unlike the import map), it only manipulates RT information associated to certain routes


I am sorry for such a long post
It took me some time to write it and to verify my assumptions and come to conclusions mentioned above.
I learned a lot while labbing it up and actually writing this.

The questions is, why did Keith add that permit any statement to the end of the route map?
I tried adding it while running debug ip routing and no new routes were added (the reason why is mentioned above in those 3 statements associated with an export map)
It certainly did not break anything but in my opinion it is not necessary / needed
Did this behavior change in a recent IOS version (I am runnign12.4(15)T13 advanced enterprise services) or did Keith add it just because of a habit (it is certainly required when doing route filtering when redistributing)


If you actually read it till here, please reply and say what you think about it 

//edit:
this topic here (http://www.sadikhov.com/forum/index.php ... xport-map/) also says that an export map is used to manipulate RT and not to do the filtering (unlike the import map)

Route Leak between VRFs with Import Maps and Export Maps

Prepare for a huge post. I will gradually configure MPLS network with VRFs and start doing route leak between VRFs. I will introduce route targets, import maps and export maps. To achieve desired effect, route maps, prefix lists and community lists are introduced as well. Everything is powered by OSPF, BGP and LDP. Let’s start!

Diagram Description

There are three routers. I have also three VRFs:

• MGT – used for management, has RD 1:1
• ABC – has RD 2:2
• DEF – has RD 3:3

Topology

Route target is the same as RD for both import and export. Interfaces are built based on the diagram. R1 and R3 have 6 loopbacks and R2 only two. Loopback 0 is for global table – no VRF. Loopback 1 is for VRF MGT. Loopbacks 2 and 22 are in VRF ABC. Router R2 doesn’t have those. Loopbacks 3 and 33 are in VRF DEF. Router R2 doesn’t have those. Loopbacks are from 10.0.0.0/8 range. Second octet is equal to router number (for R1 you have “1″). Third octet is VRF.

• 0 – global table
• 1 – VRF MGT
• 2 and 22 – VRF ABC
• 3 and 33 – VRF DEF

Physical interfaces are in MPLS network. LDP is used by default. No configuration for LDP is introduced. Everything is in default values.

OSPF is running for global table. It has networks from physical interfaces and loopback 0. Loopbacks 0 are used for BGP, so BGP starts convergence after OSPF ends it.

BGP in the whole network has AS 1. Neighbors are loopback 0 IPs with update-source to loopback 0. So connectivity is built from loopback 0 to loopback 0. Neighbors are activated under VPNv4 and they send community both. I don’t have full mesh of BGP in the network. R2 is here as core and R1 and R3 are distribution routers. In other words, R2 is P router and R1 and R3 are PE routers. BGP must be fully meshed, so R2 is route reflector. There is that extra command under VPNv4. Under corresponding address families, proper loopbacks are advertised.

I think that is it for now. Here are configs for all three routers. I encourage you to do this lab in Dynamips. It will really help you understand this topic.

R1:

hostname R1
!
ip vrf ABC
 rd 2:2
 route-target export 2:2
 route-target import 2:2
!
ip vrf DEF
 rd 3:3
 route-target export 3:3
 route-target import 3:3
!
ip vrf MGT
 rd 1:1
 route-target export 1:1
 route-target import 1:1
!
interface Loopback0
 ip address 10.1.0.1 255.255.255.255
!
interface Loopback1
 ip vrf forwarding MGT
 ip address 10.1.1.1 255.255.255.255
!
interface Loopback2
 ip vrf forwarding ABC
 ip address 10.1.2.1 255.255.255.255
!
interface Loopback3
 ip vrf forwarding DEF
 ip address 10.1.3.1 255.255.255.255
!
interface Loopback22
 ip vrf forwarding ABC
 ip address 10.1.22.1 255.255.255.255
!         
interface Loopback33
 ip vrf forwarding DEF
 ip address 10.1.33.1 255.255.255.255
!
interface FastEthernet1/0
 ip address 192.168.12.1 255.255.255.0
 mpls ip
!
router ospf 1
 network 10.1.0.1 0.0.0.0 area 0
 network 192.168.12.1 0.0.0.0 area 0
!
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.2.0.1 remote-as 1
 neighbor 10.2.0.1 update-source Loopback0
 no auto-summary
 !
 address-family vpnv4
  neighbor 10.2.0.1 activate
  neighbor 10.2.0.1 send-community both
 exit-address-family
 !
 address-family ipv4 vrf ABC
  no synchronization
  network 10.1.2.1 mask 255.255.255.255
  network 10.1.22.1 mask 255.255.255.255
 exit-address-family
 !
 address-family ipv4 vrf DEF
  no synchronization
  network 10.1.3.1 mask 255.255.255.255
  network 10.1.33.1 mask 255.255.255.255
 exit-address-family
 !
 address-family ipv4 vrf MGT
  no synchronization
  network 10.1.1.1 mask 255.255.255.255
 exit-address-family

R2:

hostname R2
!
ip vrf ABC
 rd 2:2
 route-target export 2:2
 route-target import 2:2
!
ip vrf DEF
 rd 3:3
 route-target export 3:3
 route-target import 3:3
!
ip vrf MGT
 rd 1:1
 route-target export 1:1
 route-target import 1:1
!
interface Loopback0
 ip address 10.2.0.1 255.255.255.255
!
interface Loopback1
 ip vrf forwarding MGT
 ip address 10.2.1.1 255.255.255.255
!
interface FastEthernet1/0
 ip address 192.168.12.2 255.255.255.0
 mpls ip
!
interface FastEthernet1/1
 ip address 192.168.23.2 255.255.255.0
 mpls ip
!
router ospf 1
 network 10.2.0.1 0.0.0.0 area 0
 network 192.168.12.2 0.0.0.0 area 0
 network 192.168.23.2 0.0.0.0 area 0
!
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.1.0.1 remote-as 1
 neighbor 10.1.0.1 update-source Loopback0
 neighbor 10.3.0.1 remote-as 1
 neighbor 10.3.0.1 update-source Loopback0
 no auto-summary
 !
 address-family vpnv4
  neighbor 10.1.0.1 activate
  neighbor 10.1.0.1 send-community both
  neighbor 10.1.0.1 route-reflector-client
  neighbor 10.3.0.1 activate
  neighbor 10.3.0.1 send-community both
  neighbor 10.3.0.1 route-reflector-client
 exit-address-family
 !
 address-family ipv4 vrf MGT
  no synchronization
  network 10.2.1.1 mask 255.255.255.255
 exit-address-family

R3:

hostname R3
!
ip vrf ABC
 rd 2:2
 route-target export 2:2
 route-target import 2:2
!
ip vrf DEF
 rd 3:3
 route-target export 3:3
 route-target import 3:3
!
ip vrf MGT
 rd 1:1
 route-target export 1:1
 route-target import 1:1
!
interface Loopback0
 ip address 10.3.0.1 255.255.255.255
!
interface Loopback1
 ip vrf forwarding MGT
 ip address 10.3.1.1 255.255.255.255
!
interface Loopback2
 ip vrf forwarding ABC
 ip address 10.3.2.1 255.255.255.255
!
interface Loopback3
 ip vrf forwarding DEF
 ip address 10.3.3.1 255.255.255.255
!
interface Loopback22
 ip vrf forwarding ABC
 ip address 10.3.22.1 255.255.255.255
!         
interface Loopback33
 ip vrf forwarding DEF
 ip address 10.3.33.1 255.255.255.255
!
interface FastEthernet1/0
 ip address 192.168.23.3 255.255.255.0
 mpls ip
!
router ospf 1
 network 10.3.0.1 0.0.0.0 area 0
 network 192.168.23.3 0.0.0.0 area 0
!
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.2.0.1 remote-as 1
 neighbor 10.2.0.1 update-source Loopback0
 no auto-summary
 !
 address-family vpnv4
  neighbor 10.2.0.1 activate
  neighbor 10.2.0.1 send-community both
 exit-address-family
 !
 address-family ipv4 vrf ABC
  no synchronization
  network 10.3.2.1 mask 255.255.255.255
  network 10.3.22.1 mask 255.255.255.255
 exit-address-family
 !
 address-family ipv4 vrf DEF
  no synchronization
  network 10.3.3.1 mask 255.255.255.255
  network 10.3.33.1 mask 255.255.255.255
 exit-address-family
 !
 address-family ipv4 vrf MGT
  no synchronization
  network 10.3.1.1 mask 255.255.255.255
 exit-address-family

Outputs before Any Route Leak

Here are outputs from show ip route. I will cut codes from the outputs to shorten length of this post. Outputs are from all VRFs and global table.

R1#sh ip ro
Codes: L - local, 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, + - replicated route

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 3 subnets
C        10.1.0.1 is directly connected, Loopback0
O        10.2.0.1 [110/2] via 192.168.12.2, 00:03:15, FastEthernet1/0
O        10.3.0.1 [110/3] via 192.168.12.2, 00:02:25, FastEthernet1/0
      192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.12.0/24 is directly connected, FastEthernet1/0
L        192.168.12.1/32 is directly connected, FastEthernet1/0
O     192.168.23.0/24 [110/2] via 192.168.12.2, 00:02:35, FastEthernet1/0
R1#sh ip ro vrf MGT

Routing Table: MGT
Codes: L - local, 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, + - replicated route

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 3 subnets
C        10.1.1.1 is directly connected, Loopback1
B        10.2.1.1 [200/0] via 10.2.0.1, 00:01:59
B        10.3.1.1 [200/0] via 10.3.0.1, 00:01:59
R1#sh ip ro vrf ABC

Routing Table: ABC

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 4 subnets
C        10.1.2.1 is directly connected, Loopback2
C        10.1.22.1 is directly connected, Loopback22
B        10.3.2.1 [200/0] via 10.3.0.1, 00:02:01
B        10.3.22.1 [200/0] via 10.3.0.1, 00:02:01
R1#sh ip ro vrf DEF

Routing Table: DEF

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 4 subnets
C        10.1.3.1 is directly connected, Loopback3
C        10.1.33.1 is directly connected, Loopback33
B        10.3.3.1 [200/0] via 10.3.0.1, 00:02:03
B        10.3.33.1 [200/0] via 10.3.0.1, 00:02:03

Here are few BGP outputs about routes:

R1#sh ip bgp vpnv4 all sum 
BGP router identifier 10.1.0.1, local AS number 1
BGP table version is 18, main routing table version 18
11 network entries using 1584 bytes of memory
11 path entries using 572 bytes of memory
6/6 BGP path/bestpath attribute entries using 792 bytes of memory
1 BGP rrinfo entries using 24 bytes of memory
3 BGP extended community entries using 72 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 3044 total bytes of memory
BGP activity 11/0 prefixes, 11/0 paths, scan interval 60 secs

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.2.0.1        4            1      13       9       18    0    0 00:03:22        6
R1#sh ip bg

R1#sh ip bg vpnv4 vrf MGT
BGP table version is 18, local router ID is 10.1.0.1
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: 1:1 (default for vrf MGT)
*> 10.1.1.1/32      0.0.0.0                  0         32768 i
*>i10.2.1.1/32      10.2.0.1                 0    100      0 i
*>i10.3.1.1/32      10.3.0.1                 0    100      0 i
R1#sh ip bg vpnv4 vrf ABC
BGP table version is 18, local router ID is 10.1.0.1
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: 2:2 (default for vrf ABC)
*> 10.1.2.1/32      0.0.0.0                  0         32768 i
*> 10.1.22.1/32     0.0.0.0                  0         32768 i
*>i10.3.2.1/32      10.3.0.1                 0    100      0 i
*>i10.3.22.1/32     10.3.0.1                 0    100      0 i

R1#sh ip bg vpnv4 vrf DEF
BGP table version is 18, local router ID is 10.1.0.1
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: 3:3 (default for vrf DEF)
*> 10.1.3.1/32      0.0.0.0                  0         32768 i
*> 10.1.33.1/32     0.0.0.0                  0         32768 i
*>i10.3.3.1/32      10.3.0.1                 0    100      0 i
*>i10.3.33.1/32     10.3.0.1                 0    100      0 i

Other routers have similar outputs. Look for yourself. As I want to do route leak between ABC and DEF, I will provide these outputs from R3:

R3#sh ip ro vrf ABC

Routing Table: ABC

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 4 subnets
B        10.1.2.1 [200/0] via 10.1.0.1, 00:00:26
B        10.1.22.1 [200/0] via 10.1.0.1, 00:00:26
C        10.3.2.1 is directly connected, Loopback2
C        10.3.22.1 is directly connected, Loopback22
R3#sh ip ro vrf DEF

Routing Table: DEF

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 4 subnets
B        10.1.3.1 [200/0] via 10.1.0.1, 00:00:27
B        10.1.33.1 [200/0] via 10.1.0.1, 00:00:27
C        10.3.3.1 is directly connected, Loopback3
C        10.3.33.1 is directly connected, Loopback33

Add Route Target under VRF ABC

If you want to learn more about route targets, read my earlier post. It explains it deeper than I do here.

I want to do route leak between VRF ABC and DEF. First I start by leaking routes from DEF to ABC. I want to learn those routes on R1. What I can do is to add route target of DEF. So I am importing everything what has RT 2:2 (ABC) and from now on 3:3 (DEF).

R1(config)#ip vrf ABC
R1(config-vrf)# route-target import 3:3

Do BGP clear. If soft clear is not helping, do the hard clear.

clear ip bgp *

Routing table for VRF ABC has changed. VRF DEF is not changed. Only R1 is effected. I have highlighted newly learned routes. If you look to baseline, you see four routes in VRF DEF. These routes are now in VRF ABC.

R1#sh ip ro vrf ABC

Routing Table: ABC

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 8 subnets
C        10.1.2.1 is directly connected, Loopback2
B        10.1.3.1 is directly connected, 00:00:04, Loopback3
C        10.1.22.1 is directly connected, Loopback22
B        10.1.33.1 is directly connected, 00:00:04, Loopback33
B        10.3.2.1 [200/0] via 10.3.0.1, 00:00:04
B        10.3.3.1 [200/0] via 10.3.0.1, 00:00:04
B        10.3.22.1 [200/0] via 10.3.0.1, 00:00:04
B        10.3.33.1 [200/0] via 10.3.0.1, 00:00:04R1#sh ip ro vrf DEF

Routing Table: DEF

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 4 subnets
C        10.1.3.1 is directly connected, Loopback3
C        10.1.33.1 is directly connected, Loopback33
B        10.3.3.1 [200/0] via 10.3.0.1, 00:00:09
B        10.3.33.1 [200/0] via 10.3.0.1, 00:00:09

Interesting are 10.1.3.1/32 and 10.1.33.1/32 subnets. Those are directly connected, but they are in different VRF. So you see them as learned via BGP and directly connected at the same time.

Once again, we are just importing stuff, so nothing changes on other routers or VRF DEF. Let’s try few pings:

R1#ping vrf ABC 10.3.2.1 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.2.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/26/36 ms
R1#ping vrf ABC 10.3.22.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.22.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/20/32 ms
R1#ping vrf ABC 10.3.3.1 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.3.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#ping vrf ABC 10.1.3.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.3.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

I am pinging from VRF ABC. 10.3.2.1 means R3, VRF ABC. 10.3.22.1 is also VRF ABC on R3. These routes are in VRF ABC on R3, so no surprise that it works. It worked before. Newly learned routes as 10.3.3.1 from VRF DEF on R3 or 10.1.3.1 from VRF DEF on R1 are not working. Why? Do those routers know how to route back to R1 VRF ABC? They don’t. VRF DEF has no knowledge about any routes in VRF ABC on any routers yet. So this is just step 1 in route leak. Before going to step 2, let’s continue with importing.

Add Import Map under VRF ABC

We are importing simply just everything with route target 3:3, which equals to VRF DEF. Maybe, you don’t want that. Maybe you want to leak only few routes from VRF DEF. This will ensure that. You add import map under VRF ABC, which is route map limiting networks.  Route map ABC-IMPORT-MAP matching extended community EC_ABC is permitted. Everything without exception. This extended community list permits route target 2:2. In other words, if route has route target 2:2 in it, it is allowed. This means that we are allowing all routes from VRF ABC from other routers to be learned. Without this statement, we will learn nothing from R3 VRF ABC.

Route map has second set of statements. Routes which are in prefix list IMPORT_TO_ABC_FROM_DEF and have route target 3:3 are permitted. This means that all routes from VRF DEF are permitted only if they are also included in prefix list. Here is config with assignment of route map as import map under VRF ABC, extended community list, prefix list and route map itself.

R1:

ip vrf ABC
 import map ABC-IMPORT-MAP
!
ip extcommunity-list standard EC_ABC permit rt 2:2
ip extcommunity-list standard EC_DEF permit rt 3:3
!
ip prefix-list IMPORT_TO_ABC_FROM_DEF seq 10 permit 10.3.33.0/24 le 32
!
route-map ABC-IMPORT-MAP permit 10
 match extcommunity EC_ABC
!
route-map ABC-IMPORT-MAP permit 20
 match ip address prefix-list IMPORT_TO_ABC_FROM_DEF
 match extcommunity EC_DEF

Do hard BGP clear by “clear ip bgp *”. Else it might not take effect. Here is output from show ip route under VRF ABC:

R1#sh ip ro vrf ABC

Routing Table: ABC

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 5 subnets
C        10.1.2.1 is directly connected, Loopback2
C        10.1.22.1 is directly connected, Loopback22
B        10.3.2.1 [200/0] via 10.3.0.1, 00:00:22
B        10.3.22.1 [200/0] via 10.3.0.1, 00:00:22
B        10.3.33.1 [200/0] via 10.3.0.1, 00:00:22

I have learned only one route instead of four. 10.3.33.1 is originally in VRF DEF, so it has route target 3:3. It is also part of the prefix list, so all conditions are met and it is put under VRF ABC on R1. All VRF ABC routes are permitted too. No changes on other routers or routing table instances. Ping is still not working, I have just limited number of routes imported into VRF ABC on R1.

Add Export Map under VRF ABC

If you want to learn more about export maps, read my earlier post.

Routes from VRF DEF to VRF ABC are imported. Actually, only one is. Now I want to export routes, so I have bidirectional connectivity from R3. I will export only one route.

Similarly, add route map as export map under VRF ABC. This route map has only one set of statements. Match statement limits routes to prefix list EXPORT_FROM_ABC_TO_DEF. Set statements adds extended community of 3:3. It adds 3:3 to the 2:2. In other words, all routes matching prefix list will have also RT 3:3 and will be exported from VRF ABC to… well… 3:3… is DEF.

ip vrf ABC
 export map ABC-EXPORT-MAP
!
ip prefix-list EXPORT_FROM_ABC_TO_DEF seq 10 permit 10.1.22.0/24 le 32
!
route-map ABC-EXPORT-MAP permit 10
 match ip address prefix-list EXPORT_FROM_ABC_TO_DEF
 set extcommunity rt  3:3 additive

You might need hard BGP clear: “clear ip bgp *”. Nothing changes in VRF ABC, because I am exporting. It has changed only under VRF ABC, when I was importing. Right? So the only change is exported route 10.1.22.1/32, which is now in VRF DEF on R1. Any changes to R2 and R3? Sure. this route is present also on R2 in VRF DEF and on R3 in VRF DEF. But that is it.

R1:

R1#sh ip ro vrf ABC

Routing Table: ABC

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 5 subnets
C        10.1.2.1 is directly connected, Loopback2
C        10.1.22.1 is directly connected, Loopback22
B        10.3.2.1 [200/0] via 10.3.0.1, 00:06:53
B        10.3.22.1 [200/0] via 10.3.0.1, 00:06:53
B        10.3.33.1 [200/0] via 10.3.0.1, 00:06:53
R1#sh ip ro vrf DEF

Routing Table: DEF

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 5 subnets
C        10.1.3.1 is directly connected, Loopback3
B        10.1.22.1 is directly connected, 00:06:55, Loopback22
C        10.1.33.1 is directly connected, Loopback33
B        10.3.3.1 [200/0] via 10.3.0.1, 00:06:55
B        10.3.33.1 [200/0] via 10.3.0.1, 00:06:55

R2:

R2#sh ip ro vrf DEF

Routing Table: DEF

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 5 subnets
B        10.1.3.1 [200/0] via 10.1.0.1, 00:00:13
B        10.1.22.1 [200/0] via 10.1.0.1, 00:00:13
B        10.1.33.1 [200/0] via 10.1.0.1, 00:00:13
B        10.3.3.1 [200/0] via 10.3.0.1, 00:50:13
B        10.3.33.1 [200/0] via 10.3.0.1, 00:50:13

R3:

R3#sh ip ro vrf ABC

Routing Table: ABC

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 4 subnets
B        10.1.2.1 [200/0] via 10.1.0.1, 00:06:58
B        10.1.22.1 [200/0] via 10.1.0.1, 00:06:58
C        10.3.2.1 is directly connected, Loopback2
C        10.3.22.1 is directly connected, Loopback22
R3#sh ip ro vrf DEF

Routing Table: DEF

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 5 subnets
B        10.1.3.1 [200/0] via 10.1.0.1, 00:06:59
B        10.1.22.1 [200/0] via 10.1.0.1, 00:06:59
B        10.1.33.1 [200/0] via 10.1.0.1, 00:06:59
C        10.3.3.1 is directly connected, Loopback3
C        10.3.33.1 is directly connected, Loopback33

Do you understand how export map is working? It is adding RT 3:3 to the community list for the route. All routers under VRF DEF have statement “route-target import 3:3″, so all routers import this route under VRF DEF. So again, import is importing routes locally and export is exporting routes to different VRF on all routers. Of course, when conditions are met.

You can build your import / export maps how you want. I use extended communities and prefix lists within route maps. Easy to maintain, easy to troubleshoot, easy to understand. Let’s do small ping bonanza to check, if we have some new connectivity between VRFs. Let’s try from VRF ABC to reach 10.3.33.1/32 network, which is originally on R3 in VRF DEF. It we have success, we have leaked route.

R1#ping vrf ABC 10.3.33.1 so lo2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.33.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.2.1 
.....
Success rate is 0 percent (0/5)
R1#ping vrf ABC 10.3.33.1 so lo22

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.33.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.22.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/23/28 ms

Yep, we are leaking. Why is connectivity with source IP of 10.1.2.1 not working and with 10.1.22.1 is? Look into routing tables again. Does R3 know 10.1.2.1 in VRF DEF? No. Does it know about 10.1.22.1 in VRF DEF? Yes! We have exported that route. Why am I even trying to reach 10.3.33.1? Because that is the one I have imported. Imported route 10.3.33.1 from R3 VRF DEF is reachable from R1 VRF ABC, when sourcing from 10.1.22.1, which is exported on R1 from VRF ABC to VRF DEF. Read previous sentence again.

To confirm bidirectional availability, I ping from R3 from VRF DEF destination of 10.1.22.1. Source loopback is 33 – VRF DEF. Destination IP is on R1, originally in VRF ABC, but now it is leaked.

R3#ping vrf DEF 10.1.22.1 so lo33

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.22.1, timeout is 2 seconds:
Packet sent with a source address of 10.3.33.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/26/28 ms

Now I try to reach 10.1.22.1 from VRF DEF. Source loopback must be with IP 10.1.22.1. I am trying to ping IP on R1 from R1, but in different VRF. Yes, it is the same IP as source and destination, but different VRFs – loopback 22 (source) is in VRF ABC and destination is in VRF DEF. Crazy.

R1#ping vrf DEF 10.1.22.1 so lo2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.22.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.2.1 
.....
Success rate is 0 percent (0/5)
R1#ping vrf DEF 10.1.22.1 so lo22

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.22.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.22.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms

Add Import Map and Export Map under VRF DEF

Route leak was successful. But I will not stop there. I will do route leak also in VRF DEF on R1. I will add import map and export map. It uses exactly the same logic. Route maps, prefix lists, everything is almost the same. This config will introduce route leak on R1 from VRF DEF to VRF ABC.

R1:

ip vrf DEF
 import map DEF-IMPORT-MAP
 export map DEF-EXPORT-MAP
 route-target import 2:2
!
ip prefix-list EXPORT_FROM_DEF_TO_ABC seq 10 permit 10.1.33.0/24 le 32
!
ip prefix-list IMPORT_TO_DEF_FROM_ABC seq 10 permit 10.3.22.0/24 le 32
!
route-map DEF-IMPORT-MAP permit 10
 match extcommunity EC_DEF
!
route-map DEF-IMPORT-MAP permit 20
 match ip address prefix-list IMPORT_TO_DEF_FROM_ABC
 match extcommunity EC_ABC
!
route-map DEF-EXPORT-MAP permit 10
 match ip address prefix-list EXPORT_FROM_DEF_TO_ABC
 set extcommunity rt  2:2 additive

Show ip route pls:

R1#sh ip ro vrf ABC

Routing Table: ABC

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 6 subnets
C        10.1.2.1 is directly connected, Loopback2
C        10.1.22.1 is directly connected, Loopback22
B        10.1.33.1 is directly connected, 00:00:17, Loopback33
B        10.3.2.1 [200/0] via 10.3.0.1, 00:00:17
B        10.3.22.1 [200/0] via 10.3.0.1, 00:00:17
B        10.3.33.1 [200/0] via 10.3.0.1, 00:00:17
R1#sh ip ro vrf DEF

Routing Table: DEF

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 6 subnets
C        10.1.3.1 is directly connected, Loopback3
B        10.1.22.1 is directly connected, 00:00:18, Loopback22
C        10.1.33.1 is directly connected, Loopback33
B        10.3.3.1 [200/0] via 10.3.0.1, 00:00:18
B        10.3.22.1 [200/0] via 10.3.0.1, 00:00:18
B        10.3.33.1 [200/0] via 10.3.0.1, 00:00:18

R2#sh ip ro vrf ABC

Routing Table: ABC

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 5 subnets
B        10.1.2.1 [200/0] via 10.1.0.1, 00:00:04
B        10.1.22.1 [200/0] via 10.1.0.1, 00:00:04
B        10.1.33.1 [200/0] via 10.1.0.1, 00:00:04
B        10.3.2.1 [200/0] via 10.3.0.1, 00:57:47
B        10.3.22.1 [200/0] via 10.3.0.1, 00:57:47
R2#sh ip ro vrf DEF

Routing Table: DEF

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 5 subnets
B        10.1.3.1 [200/0] via 10.1.0.1, 00:00:06
B        10.1.22.1 [200/0] via 10.1.0.1, 00:00:06
B        10.1.33.1 [200/0] via 10.1.0.1, 00:00:06
B        10.3.3.1 [200/0] via 10.3.0.1, 00:57:49
B        10.3.33.1 [200/0] via 10.3.0.1, 00:57:49

R3#sh ip ro vrf ABC

Routing Table: ABC

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 5 subnets
B        10.1.2.1 [200/0] via 10.1.0.1, 00:00:10
B        10.1.22.1 [200/0] via 10.1.0.1, 00:00:10
B        10.1.33.1 [200/0] via 10.1.0.1, 00:00:10
C        10.3.2.1 is directly connected, Loopback2
C        10.3.22.1 is directly connected, Loopback22
R3#sh ip ro vrf DEF

Routing Table: DEF

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 5 subnets
B        10.1.3.1 [200/0] via 10.1.0.1, 00:00:11
B        10.1.22.1 [200/0] via 10.1.0.1, 00:00:11
B        10.1.33.1 [200/0] via 10.1.0.1, 00:00:11
C        10.3.3.1 is directly connected, Loopback3
C        10.3.33.1 is directly connected, Loopback33

What just happened? Import map states that route 10.3.22.1 will be added into VRF DEF routing table on R1. Why? I am now importing routes with RT 2:2 or 3:3. All routes having RT 3:3 are imported without exception. Routes having 2:2 are imported only if they match prefix list. This is policy in route map. Route 10.1.33.1 is exported from VRF DEF to VRF ABC on router R1 and learned by every router in VRF ABC. Route 10.1.33.1 matches prefix list and has added RT 2:2 to the existing RT 3:3. You can see this route in both VRFs on all routers.

Let’s try couple of pings. I am trying to reach destination 10.1.33.1 from VRF ABC by using different source IPs. Loopbacks 2 and 22 are in VRF ABC, so it should be successful. Loopback 3 has IP 10.1.3.1, which is not learned. 10.1.33.1 is successful however, due to route leak. This route is originally on router R1 in VRF DEF. Source interface matters.

R1#ping vrf ABC 10.1.33.1 so lo2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.33.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.2.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
R1#ping vrf ABC 10.1.33.1 so lo22

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.33.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.22.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
R1#ping vrf ABC 10.1.33.1 so lo3 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.33.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.3.1 
.....
Success rate is 0 percent (0/5)
R1#ping vrf ABC 10.1.33.1 so lo33

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.33.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.33.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms

Now different test. I am trying to reach 10.3.33.1, which is originally in VRF DEF on router R3. I am trying to reach it from R1 from VRF ABC. Is route leak working? Let’s try different loopbacks.

R1#ping vrf ABC 10.3.33.1 so lo2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.33.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.2.1 
.....
Success rate is 0 percent (0/5)
R1#ping vrf ABC 10.3.33.1 so lo22

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.33.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.22.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/24/40 ms
R1#ping vrf ABC 10.3.33.1 so lo3 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.33.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.3.1 
.....
Success rate is 0 percent (0/5)
R1#ping vrf ABC 10.3.33.1 so lo33

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.33.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.33.1 
.....
Success rate is 0 percent (0/5)

Only working combination is source IP 10.1.22.1. Why? Look into routing table on router R3. Only one combination works due to route leak design. I have imported and exported only one route.

This is similar to one already tested. It is similar to “ping vrf ABC 10.1.33.1″.

R1#ping vrf DEF 10.1.22.1 so lo2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.22.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.2.1 
.....
Success rate is 0 percent (0/2)
R1#ping vrf DEF 10.1.22.1 so lo22

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.22.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.22.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
R1#ping vrf DEF 10.1.22.1 so lo3 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.22.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.3.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms
R1#ping vrf DEF 10.1.22.1 so lo33

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.22.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.33.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Next one is similar to “ping vrf ABC 10.3.33.1″.

R1#ping vrf DEF 10.3.22.1 so lo2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.22.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.2.1 
.....
Success rate is 0 percent (0/5)
R1#ping vrf DEF 10.3.22.1 so lo22

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.22.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.22.1 
.....
Success rate is 0 percent (0/5)
R1#ping vrf DEF 10.3.22.1 so lo3 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.22.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.3.1 
.....
Success rate is 0 percent (0/5)
R1#ping vrf DEF 10.3.22.1 so lo33

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.22.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.33.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/24/32 ms

Route Leak on R3

The same config, only with different IP addresses, is now introduced on R3 to provide route leak between VRF ABC and DEF and vice versa.

R3:

ip vrf ABC
 import map ABC-IMPORT-MAP
 export map ABC-EXPORT-MAP
 route-target import 3:3
!
ip vrf DEF
 import map DEF-IMPORT-MAP
 export map DEF-EXPORT-MAP
 route-target import 2:2
!
ip extcommunity-list standard EC_ABC permit rt 2:2
ip extcommunity-list standard EC_DEF permit rt 3:3
!
ip prefix-list EXPORT_FROM_ABC_TO_DEF seq 10 permit 10.3.22.0/24 le 32
!
ip prefix-list IMPORT_TO_ABC_FROM_DEF seq 10 permit 10.1.33.0/24 le 32
!
ip prefix-list EXPORT_FROM_DEF_TO_ABC seq 10 permit 10.3.33.0/24 le 32
!
ip prefix-list IMPORT_TO_DEF_FROM_ABC seq 10 permit 10.1.22.0/24 le 32
!
route-map ABC-IMPORT-MAP permit 10
 match extcommunity EC_ABC
!
route-map ABC-IMPORT-MAP permit 20
 match ip address prefix-list IMPORT_TO_ABC_FROM_DEF
 match extcommunity EC_DEF
!
route-map DEF-IMPORT-MAP permit 10
 match extcommunity EC_DEF
!
route-map DEF-IMPORT-MAP permit 20
 match ip address prefix-list IMPORT_TO_DEF_FROM_ABC
 match extcommunity EC_ABC
!
route-map ABC-EXPORT-MAP permit 10
 match ip address prefix-list EXPORT_FROM_ABC_TO_DEF
 set extcommunity rt  3:3 additive
!
route-map DEF-EXPORT-MAP permit 10
 match ip address prefix-list EXPORT_FROM_DEF_TO_ABC
 set extcommunity rt  2:2 additive

Do hard BGP reset. Here are routing tables:

R1#sh ip ro vrf ABC

Routing Table: ABC

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 6 subnets
C        10.1.2.1 is directly connected, Loopback2
C        10.1.22.1 is directly connected, Loopback22
B        10.1.33.1 is directly connected, 00:08:13, Loopback33
B        10.3.2.1 [200/0] via 10.3.0.1, 00:00:07
B        10.3.22.1 [200/0] via 10.3.0.1, 00:00:07
B        10.3.33.1 [200/0] via 10.3.0.1, 00:00:07
R1#sh ip ro vrf DEF

Routing Table: DEF

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 6 subnets
C        10.1.3.1 is directly connected, Loopback3
B        10.1.22.1 is directly connected, 00:07:40, Loopback22
C        10.1.33.1 is directly connected, Loopback33
B        10.3.3.1 [200/0] via 10.3.0.1, 00:00:09
B        10.3.22.1 [200/0] via 10.3.0.1, 00:00:09
B        10.3.33.1 [200/0] via 10.3.0.1, 00:00:09

R2#sh ip ro vrf ABC

Routing Table: ABC

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 6 subnets
B        10.1.2.1 [200/0] via 10.1.0.1, 00:08:19
B        10.1.22.1 [200/0] via 10.1.0.1, 00:08:19
B        10.1.33.1 [200/0] via 10.1.0.1, 00:08:19
B        10.3.2.1 [200/0] via 10.3.0.1, 00:00:13
B        10.3.22.1 [200/0] via 10.3.0.1, 00:00:13
B        10.3.33.1 [200/0] via 10.3.0.1, 00:00:13R2#sh ip ro vrf DEF

Routing Table: DEF

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 6 subnets
B        10.1.3.1 [200/0] via 10.1.0.1, 00:08:20
B        10.1.22.1 [200/0] via 10.1.0.1, 00:08:20
B        10.1.33.1 [200/0] via 10.1.0.1, 00:08:20
B        10.3.3.1 [200/0] via 10.3.0.1, 00:00:14
B        10.3.22.1 [200/0] via 10.3.0.1, 00:00:14
B        10.3.33.1 [200/0] via 10.3.0.1, 00:00:14

R3#sh ip ro vrf ABC

Routing Table: ABC

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 6 subnets
B        10.1.2.1 [200/0] via 10.1.0.1, 00:00:21
B        10.1.22.1 [200/0] via 10.1.0.1, 00:00:21
B        10.1.33.1 [200/0] via 10.1.0.1, 00:00:21
C        10.3.2.1 is directly connected, Loopback2
C        10.3.22.1 is directly connected, Loopback22
B        10.3.33.1 is directly connected, 00:00:21, Loopback33R3#sh ip ro vrf DEF

Routing Table: DEF

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 6 subnets
B        10.1.3.1 [200/0] via 10.1.0.1, 00:00:23
B        10.1.22.1 [200/0] via 10.1.0.1, 00:00:23
B        10.1.33.1 [200/0] via 10.1.0.1, 00:00:23
C        10.3.3.1 is directly connected, Loopback3
B        10.3.22.1 is directly connected, 00:00:23, Loopback22
C        10.3.33.1 is directly connected, Loopback33

R1 doesn’t have any changes in routing tables. R2 and R3 have. Actually, you see only newly exported routes. 10.1.22.1 and 10.1.33.1 are already present in routing table thanks to R1 export rules, so these new import rules on R3 have no effect. R1 is not effected by export maps from R3, because those routes are already in routing tables on R1. We can consider it as a “redundancy” in config.

Let’s test connectivity. First try to reach 10.1.33.1 (R1, VRF DEF, loopback 33) from VRF ABC on R1 with various source interfaces. Third is not working, because that route is not leaked. Forth route is leaked. Else it will not work.

R1#ping vrf ABC 10.1.33.1 so lo2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.33.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.2.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/8 ms
R1#ping vrf ABC 10.1.33.1 so lo22

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.33.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.22.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
R1#ping vrf ABC 10.1.33.1 so lo3 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.33.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.3.1 
.....
Success rate is 0 percent (0/2)
R1#ping vrf ABC 10.1.33.1 so lo33

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.33.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.33.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms

Now something harder. Try to reach 10.3.33.1 (R3, VRF DEF, loopback 33) from R1 VRF ABC. Only one combination works, the leaked one. Other routes are not leaked.

R1#ping vrf ABC 10.3.33.1 so lo2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.33.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.2.1 
.....
Success rate is 0 percent (0/5)
R1#ping vrf ABC 10.3.33.1 so lo22

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.33.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.22.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/44/60 ms
R1#ping vrf ABC 10.3.33.1 so lo3 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.33.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.3.1 
.....
Success rate is 0 percent (0/5)
R1#ping vrf ABC 10.3.33.1 so lo33

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.33.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.33.1 
.....
Success rate is 0 percent (0/5)

Summary

So what do you need for route leak?

1. Build your topology and decide, what has to be leaked where. In other words, what is the desired end-to-end connectivity between different VRFs.
2. Use route target import under VRFs.
3. If you don’t want to import everything from particular route target, use import map under VRF configuration. Build your route map. Consider prefix lists, extended community lists and route maps as I did.
4. Export routes by using route map. Use export map. You can also use route target export option, which exports all routes.

OMG that is the longest post I ever made. Do this lab at home and play with it. It looks hard, but it isn’t that hard. Just get familiar with it.