Overlay Transport Virtualization with VRF

Time for OTV interaction yet again. In my previous post I had mentioned about encrypting OTV traffic. This post we will look at how one can ensure OTV works with VRF's.

To discuss this, I am making use of the basic multicast OTV configurations as my base and tweaking ED1's config's to ensure OTV with VRF comes UP

Basic multicast OTV can be viewed by visiting: http://stayinginit.blogspot.in/2013/12/basic-multicast-otv.html

With OTV, we can have different join-interfaces for different 'interface overlay <num>' configurations [I am referring to sub-interfaces as join-interfaces and not physical interfaces]. This gives us an opportunity to even separate the join-interface routing domains using VRF.

Also, I would like to mention that this post will be in two parts -

1. Part-1: Basic OTV with VRF
2. Part-2: Encrypting VRF-aware OTV traffic [using crypto map]
1. This is particular interest to me since I made some learning in bringing up VRF aware crypto maps.

So, as always lets go straight to the topology and the configurations [if you want to know how to bring up OTV, kindly visit the link given above]:

Part-1 [OTV with VRF]:

Topology [same as seen in multicast OTV]:

To demonstrate how OTV works with VRF, I have made ED1 "OTV with VRF", but have kept both the CORE and ED2 untouched. So, the overall change to the base multicast OTV configuration will be only on ED1. 

By experience: I recommend bringing up basic OTV [multicast in this case] before trying out VRF just to ensure OTV is UP at the basic level. This way, if the OTV adjacency fails post VRF configuration we just need to verify very few configurations before rectifying the problem / raising an alarm.

ED1:

vrf definition vrf_14
 rd 14:14
 !
 address-family ipv4
  route-target export 14:14
  route-target import 14:14

 exit-address-family

ip multicast-routing vrf vrf_14 distributed

router ospf 14 vrf vrf_14

 router-id 14.14.14.1

interface GigabitEthernet0/0/1.14
 description "JOIN INTERFACE"
 encapsulation dot1Q 14
 vrf forwarding vrf_14
 ip address 10.1.14.2 255.255.255.0
 ip pim passive
 ip igmp version 3
 ip ospf 14 area 14

Some inputs:

1. The CORE router and the other ED's need not be aware of any VRF related configurations on the ED1
2. There is no specific VRF configuration that needs to be applied on the Overlay interface

Basic verification:

"show otv" -  the State and the AED Capability status should be UP and YES respectively [check done on ED1].

ED1#show otv 
Overlay Interface Overlay150
 VPN name                 : None
 VPN ID                   : 1
 State                    : UP
 AED Capable              : Yes
 IPv4 control group       : 232.1.14.1
 Mcast data group range(s): 232.14.1.0/24 
 Join interface(s)        : GigabitEthernet0/0/1.14
 Join IPv4 address        : 10.1.14.2
 Tunnel interface(s)      : Tunnel0
 Encapsulation format     : GRE/IPv4
 Site Bridge-Domain       : 150
 Capability               : Multicast-reachable
 Is Adjacency Server      : No
 Adj Server Configured    : No
 Prim/Sec Adj Svr(s)      : None


ED1#

The ping test between VM1 and VM2:

[root@vm-aries-cel ~]# ping 172.16.11.10 -c 10
PING 172.16.11.10 (172.16.11.10) 56(84) bytes of data.
64 bytes from 172.16.11.10: icmp_seq=0 ttl=64 time=1002 ms
64 bytes from 172.16.11.10: icmp_seq=1 ttl=64 time=2.62 ms
64 bytes from 172.16.11.10: icmp_seq=2 ttl=64 time=0.610 ms
64 bytes from 172.16.11.10: icmp_seq=3 ttl=64 time=0.612 ms
64 bytes from 172.16.11.10: icmp_seq=4 ttl=64 time=0.699 ms
64 bytes from 172.16.11.10: icmp_seq=5 ttl=64 time=0.586 ms
64 bytes from 172.16.11.10: icmp_seq=6 ttl=64 time=0.575 ms
64 bytes from 172.16.11.10: icmp_seq=7 ttl=64 time=0.606 ms
64 bytes from 172.16.11.10: icmp_seq=8 ttl=64 time=0.548 ms
64 bytes from 172.16.11.10: icmp_seq=9 ttl=64 time=0.661 ms

--- 172.16.11.10 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9000ms
rtt min/avg/max/mdev = 0.548/100.961/1002.085/300.375 ms, pipe 3

[root@vm-aries-cel ~]#

Accounting of packets over the overlay interface [this confirms that packet has taken the OTV to reach the far end]:

The capture below were taken after clearing the counters on both ED's

ED1#show interfaces overlay 150 accounting 
Overlay150 
                Protocol    Pkts In   Chars In   Pkts Out  Chars Out
                   Other          5        320          1         64
                      IP         10       1020         10       1020
                    CLNS          2       2828         12      10326

ED1#

ED2#show interfaces overlay 150 accounting

Overlay150 

                Protocol    Pkts In   Chars In   Pkts Out  Chars Out

                   Other          1         64          8        512

                      IP         10       1020         11       1267

                    CLNS         18      14780          4       5672

ED2#

Also, just for reference I have pasted the relevant configurations of all the three routers [ED1 / ED2 and CORE] below to give a better clarity of this demonstration.

ED1:

vrf definition vrf_14
 rd 14:14
 !
 address-family ipv4
  route-target export 14:14
  route-target import 14:14

 exit-address-family

ip multicast-routing vrf vrf_14 distributed

ip igmp snooping querier version 3

ip igmp snooping querier

otv site bridge-domain 150
otv site-identifier 0000.0000.0002    ! the site-identifier

interface GigabitEthernet0/0/0
 description "ACCESS / INTERNAL INTERFACE"
 no shutdown
 negotiation auto
 service instance 14 ethernet
  encapsulation dot1q 14
  bridge-domain 14
 !
 service instance 150 ethernet
  encapsulation dot1q 150
  bridge-domain 150

interface GigabitEthernet0/0/1
 no ip address
 no shutdown
 negotiation auto

router ospf 14 vrf vrf_14

 router-id 14.14.14.1

interface GigabitEthernet0/0/1.14
 description "JOIN INTERFACE"
 encapsulation dot1Q 14
 vrf forwarding vrf_14
 ip address 10.1.14.2 255.255.255.0
 ip pim passive
 ip igmp version 3
 ip ospf 14 area 14

interface Overlay150

 no ip address

 no shutdown                               ! added by me

 otv control-group 232.1.14.1

 otv data-group 232.14.1.0/24

 otv join-interface GigabitEthernet0/0/1.14

 service instance 14 ethernet

  encapsulation dot1q 14

  bridge-domain 14

CORE:

ip multicast-routing distributed

router ospf 14
 router-id 14.14.14.2

interface Loopback14

 ip address 14.14.14.14 255.255.255.255

 ip ospf 14 area 14

ip pim rp-address 14.14.14.14

interface GigabitEthernet0/0/1
 no ip address
 no shutdown
 negotiation auto

interface GigabitEthernet0/0/1.14

 description "CORE INTERFACE CONNECTED TO ED1"

 encapsulation dot1Q 14

 ip address 10.1.14.1 255.255.255.0

 ip pim sparse-mode

 ip igmp version 3

 ip ospf 14 area 14

interface GigabitEthernet0/0/0
 no ip address
 no shutdown
 negotiation auto

interface GigabitEthernet0/0/0.14

 description "CORE INTERFACE CONNECTED TO ED2"

 encapsulation dot1Q 14

 ip address 10.2.14.1 255.255.255.0

 ip pim sparse-mode

 ip igmp version 3

 ip ospf 14 area 14

ED2:

ip multicast-routing distributed

ip igmp snooping querier version 3

ip igmp snooping querier

otv site bridge-domain 151

otv site-identifier 0000.0000.0003

interface GigabitEthernet0/0/1
 description "ACCESS / INTERNAL INTERFACE"
 no shutdown
 negotiation auto
 service instance 14 ethernet
  encapsulation dot1q 14
  bridge-domain 14
 !
 service instance 151 ethernet
  encapsulation dot1q 151
  bridge-domain 151   

interface GigabitEthernet0/0/0
 no ip address
 no shutdown
 negotiation auto

router ospf 14
 router-id 14.14.14.3

interface GigabitEthernet0/0/0.14

 description "JOIN INTERFACE"

 encapsulation dot1Q 14

 ip address 10.2.14.2 255.255.255.0

 ip pim passive

 ip igmp version 3

 ip ospf 14 area 14

interface Overlay150

 no ip address

 no shutdown                               ! added by me

 otv control-group 232.1.14.1

 otv data-group 232.14.1.0/24

 otv join-interface GigabitEthernet0/0/0.14

 service instance 14 ethernet

  encapsulation dot1q 14

  bridge-domain 14

From the above I believe one can easily make out the there isn't much change to the base OTV setup configurations apart from ensuring we configure VRF correctly. 

This is one of the main reasons [at least I feel so] why OTV is being looked at keenly. Almost all features which we plan to use with OTV sits perfectly along side OTV [yes I know, logical interfaces are yet to come in, but I am sure it will too :-)]

This ends Part-1 of this post.

Part-2 [OTV with VRF and crypto-map]

Let us take this a set further and introduce crypto-maps to our existing VRF configuration.

ED1 and ED2 will have the below configurations related to crypto-map's:

ED1:

crypto isakmp policy 14
 hash md5
 authentication pre-share
 group 5

crypto keyring otv_ring vrf vrf_14 

  pre-shared-key address 10.2.14.2 key cisco123

crypto isakmp profile otv_isakmp

   keyring otv_ring

   match identity address 10.2.14.2 255.255.255.255 vrf_14

crypto ipsec transform-set ed1_ts esp-aes esp-sha-hmac

ip access-list extended ed1_acl
 permit gre host 10.1.14.2 host 10.2.14.2

crypto map ed1_map 14 ipsec-isakmp
 set peer 10.2.14.2
 set transform-set ed1_ts
 set isakmp-profile otv_isakmp match address ed1_acl

interface GigabitEthernet0/0/1.14
 crypto map ed1_map

ED2:

crypto isakmp policy 14
 hash md5
 authentication pre-share
 group 5

crypto isakmp key cisco123 address 10.1.14.2

crypto ipsec transform-set ed2_ts esp-aes esp-sha-hmac

ip access-list extended ed2_acl
 permit gre host 10.2.14.2 host 10.1.14.2

crypto map ed2_map 14 ipsec-isakmp
 set peer 10.1.14.2
 set transform-set ed2_ts
 match address ed2_acl

interface GigabitEthernet0/0/0.14
 crypto map ed2_map

As seen above, crypto-map usage has some additional configurations related to VRF which is quiet important to note, since, not many may be aware of how to bring up VRF-aware crypto-maps.

Once the above is configured, you can re-send a ping from VM1 to VM2 and vice-versa. Using the "show crypto session detail" to verify if the packets are getting encrypted / decrypted.

NOTE: All the above tests were done using the recently released XE-3.11 image

Hope you found this post informative.