This document provides instructions for setting up and configuring OTV (Overlay Transport Virtualization) in a lab environment to connect two data center sites. The key steps include: 1. Setting up the physical lab topology with two Nexus 7000 switches acting as OTV edge devices in each site, with dedicated VDCs for OTV. 2. Configuring OTV features and licenses on the edge devices, defining the site VLAN and extended VLANs, and configuring join interfaces to connect the devices. 3. Creating overlay interfaces on the edge devices and associating the control and data multicast groups. 4. Verifying the OTV configuration and checking for adjacencies between edge devices

1. OTV CONFIGURATION
DATA CENTER | WWW.NETPROTOCOLXPERT.IN

2. OTV LAB SETUP
• WE SETUP A MINI LAB USING TWO NEXUS 7000 SWITCHES, EACH WITH THE FOUR
VDCS, TWO NEXUS 5000 SWITCHES AND A 3750 CATALYST SWITCH.
WE EMULATED TWO DATA CENTER SITES, EACH WITH TWO CORE SWITCHES FOR
TYPICAL LAYER3 BREAKOUT, EACH WITH TWO SWITCHES DEDICATED FOR OTV AND
EACH WITH ONE ACCESS SWITCH TO TEST CONNECTIVITY. SITE1 INCLUDES
SWITCHES 11-14 (FOUR VDCS ON N7K-1) AND SWITCH 15 (N5K), WHEREAS SITE2
INCLUDES SWITCHES 21-24 (FOUR VDCS ON N7K-2) AND SWITCH 32 (3750).
• TO FOCUS ON OTV, WE REMOVED THE COMPLEXITY FROM THE TRANSPORT
NETWORK BY USING OTV ON DEDICATED VDCS (FOUR OF THEM FOR REDUNDANCY),
CONNECTED AS INLINE OTV APPLIANCES AND BY CONNECTING THE OTV JOIN
INTERFACES ON A SINGLE MULTI-ACCESS NETWORK.

4. • BEFORE CONFIGURING OTV, THE DECISION MUST BE MADE HOW OTV WILL BE
INTEGRATED PART OF THE DATA CENTER DESIGN.
• RECALL THE OTV/SVI CO-EXISTING LIMITATION. IF CORE SWITCHES ARE IN
PLACE, WHICH ARE NOT THE NEXUS 7000 SWITCHES, OTV MAY BE IMPLEMENTED
NATIVELY ON THE NEW NEXUS 7000 SWITCH/ES OR USING A VDCS. IF THE
NEXUS 7000 SWITCHES ARE PROVIDING THE CORE SWITCH FUNCTIONALITY,
THEN SEPARATE VDCS ARE REQUIRED FOR OTV.

5. OTV CONFIGURATION
• THE INTRA SITE CONNECTIVITY IS USING CISCO’S VPC TECHNOLOGY AS THE MLAG (MULTI-CHASSIS
LINK AGGREGATION) PROTOCOL. THE VPC CONFIGURATION IS NOT COVERED HERE. I WILL COVER
VPCS IN MORE DETAIL IN FUTURE POSTS. THE CONFIGURATION STEPS COVERED WILL FOCUS
SPECIFICALLY ON OTV.
STEP-1: OTV FEATURE
• ENABLE THE OTV FEATURE WITHIN THE SYSTEM VDC. OTV REQUIRES A LICENSE. THE
TRANSPORT_SERVICES_PKG LICENSE COULD BE PURCHASED AND LOADED. ALTERNATIVELY IF JUST
FOR TESTING OR POC, ENABLE THE GRACE PERIOD WHICH WILL ALLOW A 120 DAY DEMO/GRACE
PERIOD TO USE AND TEST OTV.
• N7K-11(CONFIG)# LICENSE GRACE-PERIOD
• N7K-11(CONFIG)# FEATURE OTV
• N7K-11 %LICMGR-2-LOG_LIC_NO_LIC: NO LICENSE(S) PRESENT FOR FEATURE
TRANSPORT_SERVICES_PKG.
• APPLICATION(S) SHUT DOWN IN 120 DAYS. TRANSPORT_SERVICES_PKG LICENSE NOT
INSTALLED.
• OTV FEATURE WILL BE SHUTDOWN AFTER GRACE PERIOD OF APPROXIMATELY 120 DAY(S)

6. STEP-2: VLANS
• IDENTIFY/CREATE THE VLANS THAT SHOULD BE EXTENDED BETWEEN THE SITES ACROSS THE
OVERLAY. MAKE SURE ALL THESE VLANS ARE ACTIVE.
• N7K-13(CONFIG)# VLAN 10-15
• N7K-13(CONFIG-VLAN)# NAME DATA-VLANS
STEP-3: OTV SITE VLAN
• BY DEFAULT VLAN 1 WILL BE USED. IT IS RECOMMENDED TO USE A DEDICATED VLAN. THE
ALLOCATED SITE VLAN MUST NOT BE EXTENDED ACROSS THE OVERLAY. AS A RESULT THE
SAME SITE VLAN COULD BE USED AT BOTH SITES. EVEN IF ONLY ONE OTV EDGE DEVICE, THE
SITE VLAN MUST STILL BE DEFINED. CREATE A NEW VLAN TO BE USED AS THE OTV SITE VLAN
AND DEFINE THIS VLAN AS THE OTV SITE VLAN.
• N7K-13(CONFIG-VLAN)# VLAN 55
• N7K-13(CONFIG-VLAN)# NAME OTV-SITE-VLAN
• N7K-13(CONFIG-VLAN)# EXIT
• N7K-13(CONFIG)# OTV SITE-VLAN 55

7. STEP-4: JOIN INTERFACES
• ONLY ONE JOIN INTERFACE CAN BE SPECIFIED PER OVERLAY ON EACH DEVICE. REFER
TO THE LIMITATIONS HERE. CONFIGURE AN IP ADDRESS ON EACH PHYSICAL
INTERFACE CONNECTED TO THE TRANSPORT NETWORK. ENABLE IGMP V3 (REQUIRED
TO JOIN THE SSM GROUPS). DO NOT ENABLE PIM ON THE JOIN INTERFACE. TEST IP
REACHABILITY BETWEEN THE JOIN INTERFACES.
• N7K-13(CONFIG)#INTERFACE ETHERNET2/9
• N7K-13(CONFIG-INT)#DESCRIPTION OTV-JOIN-INTERFACE
• N7K-13(CONFIG-INT)#NO SWITCHPORT
• N7K-13(CONFIG-INT)#MTU 9216
• N7K-13(CONFIG-INT)#IP ADDRESS 55.1.1.13/24
• N7K-13(CONFIG-INT)#IP IGMP VERSION 3
• N7K-13(CONFIG-INT)#NO SHUTDOWN

8. STEP-5: INTERNAL INTERFACES
• CONFIGURE THE LAYER2 INTERFACES, THAT FACES EACH SITE. THESE ARE THE
INTERFACES THAT WILL PARTICIPATE IN STP AND LEARNING THE MAC ADDRESSES
FROM THE LOCAL DATA CENTER. WE WOULD RECOMMENDED ALLOWING ONLY THE
RELEVANT VLANS ON THESE INTERFACES, I.E., THE VLANS TO BE EXTENDED AND THE
SITE VLAN. CONFIGURE ANY FURTHER STP CONFIGURATIONS IF REQUIRED.
• N7K-13(CONFIG)# INTERFACE ETHERNET2/10-11
• N7K-13(CONFIG-INT)#DESCRIPTION OTV-INTERNAL-INTERFACE
• N7K-13(CONFIG-INT)#MTU 9216
• N7K-13(CONFIG-INT)#SWITCHPORT
• N7K-13(CONFIG-INT)#SWITCHPORT MODE TRUNK
• N7K-13(CONFIG-INT)#SWITCHPORT TRUNK ALLOWED VLAN 10-15,55
• N7K-13(CONFIG-INT)#CHANNEL-GROUP 14 MODE ACTIVE
• N7K-13(CONFIG-INT)#NO SHUTDOWN

9. STEP-6: OVERLAY INTERFACE
• CREATE THE LOGICAL OVERLAY INTERFACE. MULTIPLE OVERLAY INTERFACES CAN BE USED TO
ALLOW DIFFERENT VLANS TO USE DIFFERENT PATHS IN THE TRANSPORT NETWORK, BUT TWO
CONDITIONS ARE REQUIRED FOR THIS. THE OVERLAY NUMBER MUST MATCH BETWEEN SITES
AND A VLAN CAN ONLY BE ASSIGNED TO ONE OVERLAY. SHUTDOWN THE OVERLAY INTERFACE
BEFORE CONFIGURING IT. SPECIFY THE OTV CONTROL AND DATA MULTICAST GROUPS.
• N7K-13(CONFIG)#INTERFACE OVERLAY1
• N7K-13(CONFIG-IF-OVERLAY)#DESC OVERLAY-INTERFACE
• N7K-13(CONFIG-IF-OVERLAY)#SHUTDOWN
• N7K-13(CONFIG-IF-OVERLAY)#OTV JOIN-INTERFACE ETHERNET1/9
• N7K-13(CONFIG-IF-OVERLAY)#OTV CONTROL-GROUP 239.12.34.5
• N7K-13(CONFIG-IF-OVERLAY)#OTV DATA-GROUP 232.5.5.0/28
STEP-7: EXTENDED VLANS
• ADD THE VLANS TO BE TRANSPORTED ACROSS THE OVERLAY. NOTICE THE SITE VLAN IS NOT
EXTENDED.
• N7K-13(CONFIG)#INTERFACE OVERLAY1
• N7K-13(CONFIG-IF-OVERLAY)#OTV EXTEND-VLAN 10-15

10. STEP-8: MTU VALUES
• CONFIGURING THE MTU VALUES WITHIN THE DATA CENTER SITES IS LESS IMPORTANT, BUT IN
THE TRANSPORT NETWORK THE CORRECT VALUES ARE VITAL. RECALL THAT THE DF BIT IS SET
ON ALL OTV PACKETS LEAVING AN EDGE DEVICE.
• TRANSPORT-DEVICES(CONFIG)#INTERFACE E1/7
• TRANSPORT-DEVICES(CONFIG-IF-OVERLAY)#MTU 9216
STEP-9: UNSHUT THE OVERLAY INTERFACE
• IF THERE IS ONLY ONE OTV EDGE DEVICE PRESENT PER SITE, THIS STEP IS TRIVIAL. IF THERE
ARE TWO OTV EDGE DEVICES PER SITE FOR LOAD-SHARING PURPOSES, FOR THE SAKE OF
STABILITY, BRING ONE EDGE DEVICE UP IN EACH SITE, CONFIRM CONNECTIVITY IS WORKING
BEFORE BRINGING UP THE REDUNDANT OTV DEVICES.
• N7K-13(CONFIG)#INTERFACE OVERLAY1
• N7K-13(CONFIG-IF-OVERLAY)#NO SHUT
• !
• N7K-23(CONFIG)#INTERFACE OVERLAY1
• N7K-23(CONFIG-IF-OVERLAY)#NO SHUT

11. STEP-10: TEST CONNECTIVITY
• A SIMPLE PING FROM ONE SITE TO ANOTHER SHOULD BE SUFFICIENT. THIS HOWEVER CAN’T BE
DONE FROM THE OTV EDGE DEVICES, SINCE THEY HAVE NO LAYER3 INTERFACES FOR THE EXTENDED
VLANS. AT FIRST IT IS NORMAL FOR THE FIRST/SECOND ECHO REQUEST TO TIME OUT. THIS IS THE
TIME IT TAKES FOR THE IP ARP REQUEST PROCESS TO COMPLETE AND ALLOW OTV TO ADVERTISE
THE NEWLY LEARNED MAC ADDRESSES FROM BOTH SITES. SUBSEQUENT PINGS SHOULD BE FINE.
• N5K-15# PING 15.1.1.32
• PING 15.1.1.32 (15.1.1.32): 56 DATA BYTES
• REQUEST 0 TIMED OUT
• 64 BYTES FROM 15.1.1.32: ICMP_SEQ=1 TTL=58 TIME=11.367 MS
• 64 BYTES FROM 15.1.1.32: ICMP_SEQ=2 TTL=58 TIME=2.001 MS
• 64 BYTES FROM 15.1.1.32: ICMP_SEQ=3 TTL=58 TIME=3.213 MS
• 64 BYTES FROM 15.1.1.32: ICMP_SEQ=4 TTL=58 TIME=2.894 MS
• --- 15.1.1.32 PING STATISTICS ---
• 5 PACKETS TRANSMITTED, 4 PACKETS RECEIVED, 20.00% PACKET LOSS
• ROUND-TRIP MIN/AVG/MAX = 2.001/4.431/11.367 MS

12. OUTPUT AND VERIFICATION
• THE FIRST USEFUL COMMAND TO VERIFY THE STATE OF THE OVERLAY IS “SHOW
OTV“.
• N7K13# SH OTV
• OTV OVERLAY INFORMATION
• OVERLAY INTERFACE OVERLAY1
• VPN NAME : OVERLAY1
• VPN STATE : UP
• EXTENDED VLANS : 10-15 (TOTAL:6)
• CONTROL GROUP : 239.12.34.5
• DATA GROUP RANGE(S) : 232.5.5.0/28
• JOIN INTERFACE(S) : ETH1/9 (55.1.1.13)
• SITE VLAN : 55 (UP)

13. • THE NEXT COMMAND SHOWS THE ADJACENCIES FORMED BETWEEN ALL EDGE
DEVICES AND THE STATE.
• N7K13# SH OTV ADJACENCY
• OVERLAY ADJACENCY DATABASE
• OVERLAY-INTERFACE OVERLAY1 :
• HOSTNAME SYSTEM-ID DEST ADDR UP TIME STATE
• N7K14 0026.9812.2244 55.1.1.14 02:36:05 UP
• N7K23 0026.9810.91C3 55.1.1.23 02:41:40 UP
• N7K24 0026.9810.91C4 55.1.1.24 02:35:33 UP

14. • THE NEXT COMMAND IS VERY USEFUL. IT SHOWS THE AED FOR EACH VLAN. RECALL THAT THE
EDGE DEVICE WITH A LOWER SYSTEM-ID WILL BECOME AUTHORITATIVE FOR ALL THE EVEN
EXTENDED VLANS, WHEREAS THE EDGE DEVICE WITH HIGHER SYSTEM-ID WILL BE
AUTHORITATIVE THE ODD EXTENDED VLANS. N7K13 SYSTEM-ID WAS 0026.9812.2243 AND
N7K14 SYSTEM-ID WAS 0026.9812.2244.
• N7K14# SH OTV VLAN
• OTV EXTENDED VLANS AND EDGE DEVICE STATE INFORMATION (* - AED)
• VLAN AUTH. EDGE DEVICE VLAN STATE OVERLAY
• ---- ----------------------------------- ---------- -------
• 10 N7K13 INACTIVE(NON AED)OVERLAY1
• 11* N7K14 ACTIVE OVERLAY1
• 12 N7K13 INACTIVE(NON AED)OVERLAY1
• 13* N7K14 ACTIVE OVERLAY1
• 14 N7K13 INACTIVE(NON AED)OVERLAY1
• 15* N7K14 ACTIVE OVERLAY1

15. • TO SEE THE ARP-ND TABLE USE THE NEXT COMMAND:
• N7K14# SH OTV ARP-ND-CACHE
• OTV ARP/ND L3->L2 ADDRESS MAPPING CACHE
• OVERLAY INTERFACE OVERLAY1
• VLAN MAC ADDRESS LAYER-3 ADDRESS AGE EXPIRES IN
• 15 001A.A1FF.7D46 15.1.1.32 00:03:42 00:04:17

16. • THE FOLLOWING COMMAND SHOWS WHY THE OTV IS CALLED MAC-IN-IP ROUTING:
• TO REACH THE FIRST MAC ADDRESS, THE NEXT-HOP IS AN INTERFACE LOCAL
WITHIN THE SITE. TO REACH THE LAST MAC ADDRESS THE NEXT-HOP IN VIA THE
OVERLAY AS ADVERTISED BY SWITCH 24.
• N7K14# SH OTV ROUTE
• OTV UNICAST MAC ROUTING TABLE FOR OVERLAY1
• VLAN MAC-ADDRESS METRIC UPTIME OWNER NEXT-HOP(S)
• ---- -------------- ------ -------- --------- -----------
• 15 000D.ECFE.077C 1 01:38:57 SITE PORT-CHANNEL14
• 15 0011.0000.0015 1 02:35:07 SITE PORT-CHANNEL14
• 15 0012.0000.0015 1 00:12:15 SITE PORT-CHANNEL14
• 15 001A.A1FF.7D46 42 01:44:44 OVERLAY N7K24
• 15 0021.0000.0015 42 01:45:12 OVERLAY N7K24
• 15 0022.0000.0015 42 00:12:16 OVERLAY N7K24

17. • THERE ARE MORE COMMANDS WITH USEFUL INFORMATION, BUT I’M NOT GOING
TO SHOW ALL EXAMPLES HERE. SOME OTHER COMMANDS I FOUND USEFUL:
• #SH OTV SITE
• #SH OTV INTERNAL OVERLAY
• #SH OTV INTERNAL ADJACENCY
• #SH TUNNEL INTERNAL IMPLICIT OTV DETAIL

18. FHRP ISOLATION
• I CONFIGURED HSRP FOR VLAN-10 IN BOTH SITE-1 (BETWEEN SWITCH 11 AND 12) AND SITE-2
(BETWEEN SWITCH 21 AND 22). BECAUSE IT IS A CONTIGUOUS SUBNET ALL HOSTS IN VLAN-10
HAS THEIR GATEWAY SET TO 10.1.1.1, WHICH IS THE SAME VIRTUAL GATEWAY IP ADDRESS IN
BOTH SITES. NOW IDEALLY TRAFFIC FROM SITE-1 SHOULD EXIT VIA SWITCH 11 AND TRAFFIC
FROM SITE-2 SHOULD EXIT VIA SWITCH 21 SINCE BOTH OF THESE SWITCHES WHERE SETUP
WITH A HSRP PRIORITY OF 105. BUT THIS IS NOT WHAT HAPPENS BY DEFAULT. HAVE A LOOK
AT THE OUTPUT BELOW:

19. • ON SWITCH 11, THE ACTIVE HSRP DEVICE FOR VLAN-10 IS SWITCH 21. THIS WOULD
BE THE SAME ON SWITCH 12 AND 22. WHY WOULD THIS BE? SINCE BOTH SWITCH 11
AND 21 HAVE THEIR HSRP PRIORITIES SET TO 105, THE ROUTER WITH THE HIGHER
INTERFACE IP ADDRESS WILL BE ELECTED AS THE ACTIVE HSRP DEVICE. IN THIS CASE
SWITCH 21. THIS MEANS THAT ALL TRAFFIC TOWARDS THE GATEWAY OF 10.1.1.1
WILL BE FORWARD TO SITE-2. THIS IS THE PROBLEM THAT WE WILL NOW CORRECT.
THE NEXT OUTPUT SHOWS THE TRAFFIC FROM SITE-1 IS DESTINED VIA THE OVERLAY

20. • FHRP ISOLATION IS THE ACT OF FILTERING HSRP, VRRP OR GLBP TRAFFIC FROM
GOING ACROSS THE OVERLAY, AND THEREBY FORCING LOCALIZED FHRP
ELECTIONS. THERE ARE TWO PARTS TO FILTER.
• THE ELECTION PROCESS SHOULD BE CONTAINED WITHIN EACH SITE TO ELECT A
LOCAL ACTIVE DEVICES.
• THE VIRTUAL MAC ADDRESSES WILL STILL BE ADVERTISED, WHICH WOULD
CAUSE CONSTANT MAC MOVE MOVES. I.E., LOCAL SITE, REMOTE SITE, LOCAL
SITE, ETC.

21. • POINT NUMBER 1 IS ACCOMPLISHED USING A VLAN ACL ON THE OTV EDGE DEVICES TO FILTER
THE RESPECTIVE TRAFFIC DEPENDING ON WHICH FHRP PROTOCOL USED. THE EXAMPLE BELOW
SHOW HOW TO FILTER ALL OF THEM:
• IP ACCESS-LIST HSRPV1-IP
• 10 PERMIT UDP ANY 224.0.0.2/32 EQ 1985
• !
• IP ACCESS-LIST HSRPV2-IP
• 10 PERMIT UDP ANY 224.0.0.102/32 EQ 1985
• !
• IP ACCESS-LIST VRRP-IP
• 10 PERMIT UDP ANY 224.0.0.18/32
• 20 PERMIT 112 ANY ANY
• !
• IP ACCESS-LIST GLBP-IP
• 10 PERMIT UDP ANY 224.0.0.102/32 EQ 3222
• !
• IP ACCESS-LIST ALL-IPS
• 10 PERMIT IP ANY ANY
• !

22. • VLAN ACCESS-MAP FHRP-FILTER 10
• MATCH IP ADDRESS HSRPV1-IP
• ACTION DROP
• VLAN ACCESS-MAP FHRP-FILTER 20
• MATCH IP ADDRESS HSRPV2-IP
• ACTION DROP
• VLAN ACCESS-MAP FHRP-FILTER 30
• MATCH IP ADDRESS VRRP-IP
• ACTION DROP
• VLAN ACCESS-MAP FHRP-FILTER 40
• MATCH IP ADDRESS GLBP-IP
• ACTION DROP
• VLAN ACCESS-MAP FHRP-FILTER 50
• MATCH IP ADDRESS ALL-IPS
• ACTION FORWARD
• !
• VLAN FILTER FHRP-FILTER VLAN-LIST 10-15

23. • TO PREVENT THE VIRTUAL MAC ADDRESSES FROM CAUSING MAC MOVES AND ALLOW FOR A CLEANER DESIGN, AN OTV ROUTE-
MAP MUST BE CONFIGURED. THIS ROUTE-MAP MUST MATCH THE VIRTUAL MAC OF THE FHRP PROTOCOL USED. FOR EXAMPLE
HSRP V1 USES THE VIRTUAL MAC: 0000.0C07.ACXX WHERE THE LAST BYTE (XX) IS THE HSRP GROUP NUMBER IN HEX. SIMILAR
FORMATS APPLY FOR VRRP AND GLBP. THE CONFIGURATION BELOW SHOWS HOW TO FILTER ALL FHRP PROTOCOLS AND SHOULD
BE APPLIED ON ALL OTV EDGE DEVICES.
• !! FILTERS HSRPV1 MAC ADDRESSES
• MAC-LIST OTV-FHRP-MAC SEQ 10 DENY 0000.0C07.AC00 FFFF.FFFF.FF00
• !
• !! FILTERS HSRPV2 MAC ADDRESSES
• MAC-LIST OTV-FHRP-MAC SEQ 11 DENY 0000.0C9F.F000 FFFF.FFFF.FF00
• !
• !! FILTERS VRRP MAC ADDRESSES
• MAC-LIST OTV-FHRP-MAC SEQ 12 DENY 0000.5E00.0100 FFFF.FFFF.FF00
• !
• !! FILTERS GLBP MAC ADDRESSES
• MAC-LIST OTV-FHRP-MAC SEQ 13 DENY 0007.B400.0000 FFFF.FF00.0000
• MAC-LIST OTV-FHRP-MAC SEQ 20 PERMIT 0000.0000.0000 0000.0000.0000
• !
• ROUTE-MAP OTV-FHRP-FILTER PERMIT 10
• MATCH MAC-LIST OTV-FHRP-MAC
• !
• OTV-ISIS DEFAULT
• VPN OVERLAY1
• REDISTRIBUTE FILTER ROUTE-MAP OTV-FHRP-FILTER

24. ONCE THE FILTERS IS APPLIED, HAVE A LOOK AT THE SAME
OUTPUT AS PREVIOUSLY ON BOTH THE INTENDED FHRP
BREAKOUT DEVICES.