VRF Route Target

MPLS VPN implementation requires VRF and also exporting and importing routes for that VRF. I mentioned on my previous posts about VRF that the VRF name is locally significant and even the RD number. What counts is what you import and export. Importing and exporting route targets use the same syntax as the RD and it is ASN:NN as shown by the example below.

!
ip vrf ALL-VRF
rd 123:4
route-target export 123:4
route-target import 123:1
route-target import 123:2
route-target import 123:3

By definition the routes that you "export" are only the routes you advertise on the vrf address family in BGP. The routes that you import are the cummulative routes with the same label that were exported from the other routers participating in the MPLS VPN. Remember that you don't export what you have learned through importation. Check the diagram below and the scenario we need to accomplish in this lab.


Scenario Conditions:

1. EMEA should have full ip reachability to APAC and AMERICAS but APAC and AMERICAS should not see each other.
2. RR should only see the all the routes but will not be seen by the routers.

I have setup everything and configured MPLS as well. I have configured the clients on the RR on both ipv4 and vpnv4 address-families. The command "show ip bgp vpnv4 all sum" on the RR should show that its learning prefixes from the clients.

RR#sh ip bgp vpnv4 all sum
BGP router identifier 123.123.123.4, local AS number 123
BGP table version is 13, main routing table version 13
12 network entries using 1644 bytes of memory
12 path entries using 816 bytes of memory
4/3 BGP path/bestpath attribute entries using 496 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 3028 total bytes of memory
BGP activity 12/0 prefixes, 12/0 paths, scan interval 15 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
123.123.123.1   4   123      52      57       13    0    0 00:40:41        2
123.123.123.2   4   123      53      61       13    0    0 00:41:26        2
123.123.123.3   4   123      43      44       13    0    0 00:36:44        2

We can clearly see that its learning prefixes in the vpnv4 but will not put those routes in the routing table until it has been imported in one of the VRF's. In our case, I have configured vrf ALL-VRF in RR and imported all the route-targets 123:1, 123:2 and 123:4. In a VRF you can export and import as many route-targets as needed. Lets see if RR can see the routes now

RR

!
ip vrf ALL-VRF
rd 123:4
route-target export 123:4
route-target import 123:1
route-target import 123:2
route-target import 123:3

RR#sh ip route vrf ALL-VRF

Routing Table: ALL-VRF
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

 1.0.0.0/32 is subnetted, 1 subnets
B       1.1.1.1 [200/0] via 123.123.123.1, 00:46:26
 2.0.0.0/32 is subnetted, 1 subnets
B       2.2.2.2 [200/0] via 123.123.123.2, 00:46:26
 33.0.0.0/32 is subnetted, 1 subnets
B       33.33.33.33 [200/0] via 123.123.123.3, 00:46:26
 3.0.0.0/32 is subnetted, 1 subnets
B       3.3.3.3 [200/0] via 123.123.123.3, 00:46:26
 22.0.0.0/32 is subnetted, 1 subnets
B       22.22.22.22 [200/0] via 123.123.123.2, 00:46:26
 11.0.0.0/32 is subnetted, 1 subnets
B       11.11.11.11 [200/0] via 123.123.123.1, 00:46:28
 123.0.0.0/32 is subnetted, 1 subnets
C       123.123.123.14 is directly connected, Loopback40

Ok, we have meet the first condition. RR is now able to see the routes exported by the RR clients. They won't see the route advertised in RR because the clients are not even importing that route. Full reachability in MPLS VPN requires that one router's exported route-target should be imported by another and vice-versa, otherwise you can only see the route but you won't be able to reach it. The networks should be in the corresponding VRF routing table of the routers.

To illustrate this point, let's configure the second scenario. Below are the VRF configurations on the 3 clients.

APAC#

!
ip vrf APAC
rd 123:1
route-target export 123:1
route-target import 123:3

AMERICAS#

!
ip vrf AMERICAS
rd 123:2
route-target export 123:2
route-target import 123:2

EMEA#
!
ip vrf EMEA
rd 123:3
route-target export 123:3
route-target export 123:2
route-target import 123:1
route-target import 123:2

APAC is exporting route-target 123:1 and its importing 123:3 which is exported by EMEA. EMEA on the other hand is importing 123:1 and exporting 123:3. There should be full ip reachability between the two. By the way the route-target ID doesn't necessarily match with the RD. Normally for networks that should see each other in MPLS VPN both the export and import route target ID's are the same. It will get rid of any unnecessary confusion created by using different RT ID's. Take into consideration AMERICAS and EMEA routers. As you can see on the config above, AMERICAS is importing and exporting 123:2. One command can generate the both export and import and that is "route-target both 123:2". EMEA is importing and exporting also 123:2 which means they will reach each other. Let's test if we have accomplished the condition, we will show the routing table in APAC and AMERICAS and let's ping the networks in EMEA. The ping should be sourced on the loopback interfaces where we configured the VRF's.

APAC#sh ip route vrf APAC

Routing Table: APAC
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

 1.0.0.0/32 is subnetted, 1 subnets
C       1.1.1.1 is directly connected, Loopback0
 33.0.0.0/32 is subnetted, 1 subnets
B       33.33.33.33 [200/0] via 123.123.123.3, 01:04:51
 3.0.0.0/32 is subnetted, 1 subnets
B       3.3.3.3 [200/0] via 123.123.123.3, 01:04:51
 11.0.0.0/32 is subnetted, 1 subnets
C       11.11.11.11 is directly connected, Loopback10

APAC#ping vrf APAC 3.3.3.3 source lo0


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


AMERICAS#sh ip route vrf AMERICAS

Routing Table: AMERICAS
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

 2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback0
 33.0.0.0/32 is subnetted, 1 subnets
B       33.33.33.33 [200/0] via 123.123.123.3, 00:56:20
 3.0.0.0/32 is subnetted, 1 subnets
B       3.3.3.3 [200/0] via 123.123.123.3, 00:56:20
 22.0.0.0/32 is subnetted, 1 subnets
C       22.22.22.22 is directly connected, Loopback10

AMERICAS#ping vrf AMERICAS 3.3.3.3 source lo0

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


EMEA#sh ip route vrf EMEA

Routing Table: EMEA
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

 1.0.0.0/32 is subnetted, 1 subnets
B       1.1.1.1 [200/0] via 123.123.123.1, 00:00:00
 2.0.0.0/32 is subnetted, 1 subnets
B       2.2.2.2 [200/0] via 123.123.123.2, 01:07:06
 33.0.0.0/32 is subnetted, 1 subnets
C       33.33.33.33 is directly connected, Loopback10
 3.0.0.0/32 is subnetted, 1 subnets
C       3.3.3.3 is directly connected, Loopback0
 22.0.0.0/32 is subnetted, 1 subnets
B       22.22.22.22 [200/0] via 123.123.123.2, 01:07:06
 11.0.0.0/32 is subnetted, 1 subnets
B       11.11.11.11 [200/0] via 123.123.123.1, 00:00:03

It will take a while to get used to VRF Route-target if you are just learning it but this should be pretty easy. Remember, you can't reach a network that you have imported unless it exported your network. In MPLS VRF, entries in your VRF routing table doesn't assure reachability, the router in the destination network should also have your network in its VRF routing table. Ok, we are done! :)

IPSEC VPN Configuration

IPSEC VPN's have revolutionized the networking world. It is usually used over the unsecured network called "the Internet". It's a way to ensure secure transfer of data over the internet and used for site to site connections and telecommuters who need remote access from anywhere to the corporate Intranet or for remote branch offices that only have internet connection. We have a basic diagram below and lets configure a Site to Site IPSEC VPN. We will focus more on configuration not on the nitty gritty details of the protocols and the process of VPN creation.




Let's pretend ISP is the Internet Cloud. We have R1 and R2 connected through an internet leased line to their ISP's. Lets say R2 has a server 2.2.2.2 which R1 needs to access from 1.1.1.1 in its network. (1.1.1.1 and 2.2.2.2 are just loopback addresses in R1 and R2 respectively) We will build a VPN tunnel allowing 1.1.1.1 to access 2.2.2.2 and vice versa. Steps are numbered but not necessarily the standard way but a more favorable way of configuring.


1. Create an access-list on both R1 and R2. This will indicate the "interesting traffic". This means that anything that matches the ACL applied to the tunnel configuration will pass through the tunnel instead of exiting the interface facing the internet.

R1(config)#access-list 100 permit ip host 1.1.1.1 host 2.2.2.2
R2(config)#access-list 100 permit ip host 2.2.2.2 host 1.1.1.1

Notice that the ACL's mirror each other.

2. Configure an ISAKMP key. This key will be used to generate more keys for VPN tunnel creation and must match between the peers.

R1(config)#crypto isakmp key 0 myvpnrouter address 192.168.20.1
R2(config)#crypto isakmp key 0 myvpnrouter address 192.168.10.1

The ip address at the end of the command is the IP address of the peer router.

3. Create an ISAKMP policy. The policy components like hashing, authentication, Diffie-Helman group, and lifetime must match. You can configure many different policies and the routers will check the ISAKMP policy until it finds a match of its own. It is checked sequentially by using policy sequence numbers. ISAKMP negotiation is also called Phase 1.

R1(config-isakmp)#crypto isakmp policy 10
R1(config-isakmp)#group 2
R1(config-isakmp)#hash md5
R1(config-isakmp)#lifetime 28800
R1(config-isakmp)#encryption aes
R1(config-isakmp)#authentication pre-share

R2(config-isakmp)#crypto isakmp policy 10
R2(config-isakmp)#group 2
R2(config-isakmp)#hash md5
R2(config-isakmp)#lifetime 28800
R2(config-isakmp)#encryption aes
R2(config-isakmp)#authentication pre-share

4. Configure Phase 2 which are IPSEC parameters.

R1(config)#crypto ipsec transform-set TRANSFORMERS esp-3des esp-sha-hmac
R1(config)#crypto ipsec security-association lifetime seconds 28800
R2(config)#crypto ipsec transform-set TRANSFORMERS esp-3des esp-sha-hmac
R2(config)#crypto ipsec security-association lifetime seconds 28800

Configure a crypto map.

R1(config)#crypto map MYMAP 10 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
        and a valid access list have been configured.
R1(config-crypto-map)#match address 100
R1(config-crypto-map)#description to R2
R1(config-crypto-map)#set transform-set TRANSFORMERS
R1(config-crypto-map)#set peer 192.168.20.1
R1(config-crypto-map)#set security-association lifetime seconds 28800

R2(config)#crypto map MYMAP 10 ipsec-isakmp
 % NOTE: This new crypto map will remain disabled until a peer
         and a valid access list have been configured.
R2(config-crypto-map)#match address 100
R2(config-crypto-map)#description to R1
R2(config-crypto-map)#set transform-set TRANSFORMERS
R2(config-crypto-map)#set peer 192.168.10.1
R2(config-crypto-map)#set security-association lifetime seconds 28800

5. Apply the Crypto map to the outgoing interface.

R1(config)#int se1/1
R1(config-if)#crypto map MYMAP
R1(config-if)#
*Jul 11 13:05:47.007: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON

R2(config)#int se1/2
R2(config-if)#crypto map MYMAP
R2(config-if)#
*Jul 11 13:05:47.007: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON

6. Make sure you have a route towards the peer vpn router public ip. In our case lets create a default route.

R1(config)#ip route 0.0.0.0 0.0.0.0 192.168.10.10 name To_R2
R2(config)#ip route 0.0.0.0 0.0.0.0 192.168.20.20 name To_R1

7. Finally lets test the connection. The tunnel won't come up until there is interesting traffic passing through the tunnel. Any traffic that will hit the access-list we matched in the crypto-map will trigger the tunnel negotiation. In our case lets ping 2.2.2.2 from R1 sourcing from the Loopback interface 1.1.1.1. In the ISP router, I have configured a route for the 2 loopback addresses.

ISP(config)#ip route 2.2.2.2 255.255.255.255 192.168.20.1
ISP(config)#ip route 1.1.1.1 255.255.255.255 192.168.10.1

R1#ping 2.2.2.2 source 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!

To verify if the tunnel is up and running, lets use the "show crypto isakmp sa" to check Phase 1 status.

R1#sh cry isakmp sa
dst             src             state          conn-id slot status
192.168.20.1    192.168.10.1    QM_IDLE              1    0 ACTIVE

QM_IDLE means that the tunnel is up. If the state is not that, that means that there is a problem.

"Show crypto ipsec sa" displays Phase 2 information which includes the number of packets that used the tunnel and the source and destination IP. Thats it for the configuration. For more detailed information on the VPN negotiation process visit this link. Cheers