What is OTV?
In the simplest of answers it is a LAN extension solution much like VPLS [but way simpler to understand configuration-wise at least, no offenses meant for those who love VPLS]
OTV is the acronym for Overlay Transport Virtualization. Actually this should be called Cisco OTV.
It does a MAC-in-IP routing, using the 'control-plane' to send out the MAC updates. Also, this being an encapsulation technique will definitely add an overhead [42-byte to be precise]
Why OTV?
With already existing solutions available, if we are thinking OTV will not make it to the big leagues, I guess that would be a wrong statement to make. The beauty of OTV is that it is an overlay of the transport. So, for OTV the transport between two LAN's does not matter. Infact, all OTV expects is IP connectivity between the two LAN data centers [DC's].
However, the real selling point for me is the simplification in configuring OTV. Its very easy compared to its peer solutions.
All it really takes to bring up basic OTV is understanding some of the terminologies. So, without further yawn boring talk lets just go into OTV terminologies, post which, we can have a look at the topology and simple ping test from VM1 in DC1 to another VM2 in DC2.
All it really takes to bring up basic OTV is understanding some of the terminologies. So, without further yawn boring talk lets just go into OTV terminologies, post which, we can have a look at the topology and simple ping test from VM1 in DC1 to another VM2 in DC2.
Terminologies
Edge-Device aka ED:
The device which is capable of performing OTV functionality [currently only Nexus and ASR1K / CSR1KV can act as edge-devices]
Overlay Interface:
A logical interface, onto which we place relevant overlay configurations
Access / Internal Interface:
A L2 interface which is attached to the DC
Join-Interface:
The L3 interface which is attached to the core [the IP address assigned to this interface should be reachable from the other DC]
Site:
Each ED has a site-identifier, which has to be unique. In case of a multi-homed setup, this value is the same between the ED's placed in the same DC
I believe the terminologies mentioned above are enough for the time being to ensure we go right into the topology and configuration details.
OTV Topology and Configuration
Before I start it would be best to mention here that OTV can be brought up via two modes, using multicast [for which we would need a multicast-core] another is unicast [for which we just need IP connectivity]
Since, I did mention OTV just needs IP connectivity I will stick to Unicast mode for now. In the subsequent posts we will see more details related to 'OTV using the multicast-core' and Multi-homing and also with LISP / VXLAN.
My basic topology:
Here, ED1 and ED2 are two edge-devices capable of performing OTV functionality.
VM1 and VM2 are in the same subnet [172.16.11.0/24] and belong to the same VLAN [VLAN 14]. VM1: 172.16.11.20 / VM2: 172.16.11.10.
VM1 [MAC]: 000C.295E.EA91
VM2 [MAC]: 000C.2980.1494
VM1 [MAC]: 000C.295E.EA91
VM2 [MAC]: 000C.2980.1494
Important note that these VM's are connected via a vswitch [internal ESXi switch] to our ED1 and ED2 respectively
Configuration on the routers [based on the assumption that the routers are in factory defaults, one has to add only the below configurations to bring up unicast-core OTV using a setup which is as above]:
ED1:
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
router-id 14.14.14.1
interface GigabitEthernet0/0/1.14
description "JOIN INTERFACE"
encapsulation dot1Q 14
ip address 10.1.14.2 255.255.255.0
ip ospf 14 area 14
interface Overlay150
no ip address
no shutdown
otv join-interface GigabitEthernet0/0/1.14
otv adjacency-server unicast-only
service instance 14 ethernet
encapsulation dot1q 14
bridge-domain 14
CORE:
router ospf 14
router-id 14.14.14.2
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 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 ospf 14 area 14
ED2:
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 ospf 14 area 14
interface Overlay150
no ip address
no shutdown
otv join-interface GigabitEthernet0/0/0.14
otv use-adjacency-server 10.1.14.2 unicast-only
service instance 14 ethernet
encapsulation dot1q 14
bridge-domain 14
With the above configuration we should note the following:
1. ED1 is acting as the OTV adjacency server [the one which will send the MAC addresses to other ED's]
2. Join-Interfaces can be sub-interfaces, but not Loopback interfaces [at least not now]
3. VM configuration not shown as they are end hosts which just need same subnet IP addresses configured on them
1. "show otv" either on ED1 / ED2 [I have executed the command on ED2]:
ED2#show otv
Overlay Interface Overlay150
VPN name : None
VPN ID : 1
State : UP
AED Capable : Yes
Join interface(s) : GigabitEthernet0/0/0.14
Join IPv4 address : 10.2.14.2
Tunnel interface(s) : Tunnel0
Encapsulation format : GRE/IPv4
Site Bridge-Domain : 151
Capability : Unicast-only
Is Adjacency Server : No
Adj Server Configured : Yes
Prim/Sec Adj Svr(s) : 10.1.14.2
ED2#
Two things to look out for from the above output is:
1. State
2. AED Capable status
Only if the State is UP and AED Capable status is Yes, we can confirm that OTV is ready to perform L2 extension
We will see what is the use of AED [Authoritative Edge Device] when we look into multi-homing.
The test - Ping from VM1 to 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=1001 ms
64 bytes from 172.16.11.10: icmp_seq=1 ttl=64 time=2.69 ms
64 bytes from 172.16.11.10: icmp_seq=2 ttl=64 time=0.608 ms
64 bytes from 172.16.11.10: icmp_seq=3 ttl=64 time=0.679 ms
64 bytes from 172.16.11.10: icmp_seq=4 ttl=64 time=0.736 ms
64 bytes from 172.16.11.10: icmp_seq=5 ttl=64 time=0.633 ms
64 bytes from 172.16.11.10: icmp_seq=6 ttl=64 time=0.681 ms
64 bytes from 172.16.11.10: icmp_seq=7 ttl=64 time=0.576 ms
64 bytes from 172.16.11.10: icmp_seq=8 ttl=64 time=0.577 ms
64 bytes from 172.16.11.10: icmp_seq=9 ttl=64 time=0.637 ms
--- 172.16.11.10 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9000ms
rtt min/avg/max/mdev = 0.576/100.963/1001.815/300.284 ms, pipe 3
[root@vm-aries-cel ~]#
ED1:
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
router-id 14.14.14.1
interface GigabitEthernet0/0/1.14
description "JOIN INTERFACE"
encapsulation dot1Q 14
ip address 10.1.14.2 255.255.255.0
ip ospf 14 area 14
interface Overlay150
no ip address
no shutdown
otv join-interface GigabitEthernet0/0/1.14
otv adjacency-server unicast-only
service instance 14 ethernet
encapsulation dot1q 14
bridge-domain 14
CORE:
router ospf 14
router-id 14.14.14.2
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 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 ospf 14 area 14
ED2:
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 ospf 14 area 14
interface Overlay150
no ip address
no shutdown
otv join-interface GigabitEthernet0/0/0.14
otv use-adjacency-server 10.1.14.2 unicast-only
service instance 14 ethernet
encapsulation dot1q 14
bridge-domain 14
With the above configuration we should note the following:
1. ED1 is acting as the OTV adjacency server [the one which will send the MAC addresses to other ED's]
2. Join-Interfaces can be sub-interfaces, but not Loopback interfaces [at least not now]
3. VM configuration not shown as they are end hosts which just need same subnet IP addresses configured on them
Simple verification:
1. "show otv" either on ED1 / ED2 [I have executed the command on ED2]:
ED2#show otv
Overlay Interface Overlay150
VPN name : None
VPN ID : 1
State : UP
AED Capable : Yes
Join interface(s) : GigabitEthernet0/0/0.14
Join IPv4 address : 10.2.14.2
Tunnel interface(s) : Tunnel0
Encapsulation format : GRE/IPv4
Site Bridge-Domain : 151
Capability : Unicast-only
Is Adjacency Server : No
Adj Server Configured : Yes
Prim/Sec Adj Svr(s) : 10.1.14.2
ED2#
1. State
2. AED Capable status
Only if the State is UP and AED Capable status is Yes, we can confirm that OTV is ready to perform L2 extension
We will see what is the use of AED [Authoritative Edge Device] when we look into multi-homing.
The test - Ping from VM1 to 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=1001 ms
64 bytes from 172.16.11.10: icmp_seq=1 ttl=64 time=2.69 ms
64 bytes from 172.16.11.10: icmp_seq=2 ttl=64 time=0.608 ms
64 bytes from 172.16.11.10: icmp_seq=3 ttl=64 time=0.679 ms
64 bytes from 172.16.11.10: icmp_seq=4 ttl=64 time=0.736 ms
64 bytes from 172.16.11.10: icmp_seq=5 ttl=64 time=0.633 ms
64 bytes from 172.16.11.10: icmp_seq=6 ttl=64 time=0.681 ms
64 bytes from 172.16.11.10: icmp_seq=7 ttl=64 time=0.576 ms
64 bytes from 172.16.11.10: icmp_seq=8 ttl=64 time=0.577 ms
64 bytes from 172.16.11.10: icmp_seq=9 ttl=64 time=0.637 ms
--- 172.16.11.10 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9000ms
rtt min/avg/max/mdev = 0.576/100.963/1001.815/300.284 ms, pipe 3
[root@vm-aries-cel ~]#
Now, lets have look at the entries on the ED2 router:
ED2#show otv isis rib mac
Tag Overlay150:
MAC local rib for Overlay150 (Total 1)
L2 Topology ID Mac Address
14 000C.295E.EA91
[50/1] via 10.1.14.2(Overlay150), LSP[2/5]
ED2#
This output highlights the MAC address(es) which were learned from other ED's[ED1 in our case]
ED2#show otv isis rib redistribution mac
Tag Overlay150:
MAC redistribution local rib for Overlay150 (Total 3)
L2 Topology ID Mac Address
14 000C.297E.8CD5
State: Up/Best/Advertised Metric: 1
14 000C.2980.1494
State: Up/Best/Advertised Metric: 1
14 0050.56BF.4129
State: Up/Best/Advertised Metric: 1
ED2#
This output highlights the MAC addresses ED2 will send to other ED's [ED1 in our case]
Also, worth noting is the ARP capture:
ED2#show otv arp-nd-cache
Overlay150 ARP/ND L3->L2 Address Mapping Cache
BD MAC Layer-3 Address Age (HH:MM:SS) Local/Remote
14 000c.295e.ea91 172.16.11.20 00:00:07 Remote
ED2#
This is the table which will be used to supress the ARP requests to the same host.
Finally, the show otv route
ED2#show otv route
Codes: BD - Bridge-Domain, AD - Admin-Distance,
SI - Service Instance, * - Backup Route
OTV Unicast MAC Routing Table for Overlay150
Inst VLAN BD MAC Address AD Owner Next Hops(s)
----------------------------------------------------------
0 14 14 000c.295e.ea91 50 ISIS ED1
0 14 14 000c.297e.8cd5 40 BD Eng Gi0/0/1:SI14
0 14 14 000c.2980.1494 40 BD Eng Gi0/0/1:SI14
0 14 14 0050.56bf.4129 40 BD Eng Gi0/0/1:SI14
4 unicast routes displayed in Overlay150
----------------------------------------------------------
4 Total Unicast Routes Displayed
ED2#
Here we see that the address "000c.295e.ea91" is mapped to ED1.
Also, I would like to mention here, the ISIS you see in the output is not something which I configured. This is the control-plane MAC address transporter for OTV.
Whenever we configure OTV, ISIS starts up in the back end. To just give some inputs here, MAC addresses placed in the TLV [data option] field of the ISIS and hence ISIS never complains about carrying these MAC addresses across.
But do you need to learn ISIS for OTV, well, its much like asking should I know cooking to eat?? No, but anything is good to know :-)
As observed, the setup is quite easy to bring up and this will be the base on which we will bring multi-homing.
OTV has a built in features like ARP supression, MAC mobility and FHRP [which we can again see when we use OTV + HSRP]
This post was just the basic OTV and probably in the near future I will try to cover more related to the features mentioned above.
NOTE: All the above tests were done using the recently released XE-3.11 release
Hope you found this post informative.
No comments:
Post a Comment