Cisco OTV: Overlay Transport Virtualization Guide

OTV exists to solve a narrow but load-bearing requirement: keeping Layer 2 adjacency between two data centres over a Layer 3 transport, without stretching spanning tree between them. It does that by turning MAC addresses into routable information — MAC-in-IP encapsulation, an IS-IS control plane, and a per-VLAN authoritative edge device election that keeps the two sites from becoming one big broadcast domain. This article covers the components, a complete configuration, and how to verify the control plane actually came up.

The four pieces you configure

• Internal interface — the site-facing Layer 2 interface (access or trunk) that connects to the VLANs being extended.
• Join interface — the transport-facing Layer 3 interface. One per overlay, must be a physical interface, subinterface or port channel; it must be in the default VRF and requires IGMPv3.
• Overlay interface — the logical interface that encapsulates Layer 2 frames in IP. Not an IP interface itself; it borrows the join interface's address.
• Site VLAN and site identifier — how multiple edge devices in the same site discover each other and elect the AED (authoritative edge device) per VLAN.

Complete configuration on NX-OS

feature otv
!
otv site-vlan 10
otv site-identifier 256          ! must match on all edge devices in the site
!
! transport-facing join interface
interface Ethernet2/1
 no switchport
 ip address 192.0.2.1/24
 ip igmp version 3
 no shutdown
!
! VLANs to be extended must exist locally
vlan 5-10
!
interface Overlay1
 no shutdown
 otv join-interface Ethernet2/1
 otv control-group 239.1.1.1
 otv data-group 232.1.1.0/28
 otv extend-vlan 5-10

Every one of no shutdown, otv control-group, otv data-group and otv join-interface is required before the overlay comes up — if any is missing the interface stays down and the reason is not always obvious from show interface.

Two edge devices in one site, for AED load sharing

! Edge Device 2 - same site VLAN, same site identifier, different IP
interface Ethernet1/1
 no switchport
 ip address 192.0.2.16/24
 ip igmp version 3
interface Overlay2
 otv join-interface Ethernet1/1
 otv control-group 239.1.1.1
 otv data-group 232.1.1.0/28
 otv extend-vlan 5-10

Both devices join the same multicast control group but use the same data group as their site peer. OTV elects an AED per VLAN by hash, so VLAN 5 might be authoritative on edge 1 and VLAN 6 on edge 2 — that is the load-sharing mechanism, and it is why ACLs on the internal interface must permit both.

Verification

show otv overlay1
! Overlay Interface Overlay1
!  State             : UP
!  Fwd-capable       : Yes
!  Fwd-ready         : Yes
!  AED-Server        : Yes
!  IPv4 control group: 239.1.1.1
!  Mcast data group  : 232.1.1.0/28
!  Join interface(s) : Ethernet2/1
!  Encapsulation     : GRE/IPv4
!  Site Bridge-Domain: 10

show otv route
show otv arp-nd-cache           ! ARP/ND suppression table
show otv isis adjacency overlay1
show otv site                   ! local edge devices and AED state

Read Fwd-capable and Fwd-ready together: capable means this device is eligible to forward, ready means it is currently the forwarder for at least one VLAN. Both must be yes for traffic to move.

The rules that cause most outages

• MTU. OTV sets the DF bit on control and data packets, so the join interface and the entire IP core between sites must carry the largest frame OTV will encapsulate. Under-sized MTU means silent blackholing rather than fragmentation.
• IGMPv3 on the join interface. OTV edge devices act as multicast hosts. Without IGMPv3 the control group never joins and no adjacency forms.
• Site identifier mismatch. OTV brings all overlays down and logs an alarm when it detects a neighbouring edge device with a different site ID.
• STP is not extended. Each site runs its own spanning tree — that is a feature, not a limitation, but it means a loop inside one site can still hurt you.
• VLAN must exist before it is extended. Extending a VLAN that is not configured locally is accepted by the CLI and produces no forwarding.

OTV is the older sibling of modern EVPN-based DCI. If you are designing new, see VXLAN EVPN multisite border gateway design for the current approach, and Cisco FabricPath vs TRILL is the other legacy fabric technology worth understanding before a migration.

原文链接：https://cisco.com/c/en/us/td/docs/switches/datacenter/nexus7000/sw/otv/config/cisco_nexus7000_otv_qsg_config_guide_8x.pdf