Overlay Transport Virtulisation (OTV) is currently a feature on the Nexus 7000 product (M1 modules) range that provides DCI (Data Center Interconnect). It allows multiple data centers to be linked together and extends L2 Ethernet across them. OTV is different to EoMPLS & VPLS as a LAN extension technologies. It is easier to configure and manage. The M1 OTV hardware support is currently on the following cards along with the TRS license;

  • N7K-M132XP-12(L)
  • N7K-M148GT-11(L)
  • N7K-M148GS-11(L)
  • N7K-M108X2-12L

It looks like in the future F1 cards will be able to be used for ‘internal interfaces’. OTV could be classed as a MAC addressing routing scheme and encapsulates Ethernet frames in IP packets. It facilitates;

  • Long distance vmotion
  • Distributed clusters
  • Applications require L2 connectivity between servers

OTV is a overlay solution therefore can use existing network topologies and no effect on those designs. OTV automatically syncs with all other sites in the domain. Resiliency features enabled by default;

  • Multi-path
  • Multi-homing
  • Loop prevention
  • Suppress flooding of unknown L2 traffic

OTV not dependant on spanning tree therefore spanning tree packets are suppressed (BPDUs not forwarded). Features like this ensure that broadcast storms/bridging loops in a single site dont effect the whole environment and are contained within a single site. OTV can be used to extent L2 networks over L3 for both intra- and inter- DC applications. It can be thought as MAC address routing. Its easy to add new DC sites, just configure the new node and no need to touch the existing sites. Scalability – it doesn’t create nailed up tunnels therefore the only state maintained is that of a MAC routing table. ARP traffic is only forwarded in a controlled mannor. Broadcast can be forwarded based on specific policies.

OTV Terminology

  • Edge Device
  • Internal Interface
  • Join Interface
  • Overlay Interface

How it works

  • On multicast enabled transport infrastructure OTV edge devices join a specific Any Source Multicast (ASM) group. This group simultaneously plays role of receiver and source. 
  • OTV control and data plan packets originate from edge devices with the DF bit set.
  • OTV adds an extra 42 bytes
  • In Multicast enabled environment the data plane uses SSM group (L2 multicast)
  • When Multicast not enabled in the trasport infrastructure head-end replication form the OTV device
  • Unknown unicast handling; - L2 traffic is only flooded out of internal interface
  • not out the overlay interface
  • assumed that all devices talk out therefore MAC will be learnt by OTV that way
  • Selective flooding is possible to support services like Microsoft NLB
  • ARP optimisation- the OTV edge snoops and caches the ARP responce
  • initial ARP is normal and sent to sites