9 – Overlay Transport Virtualization (OTV)

Cisco has recently introduced a new feature called OTV that extends Layer 2 traffic between multiple sites over a Layer 3 network. The edge devices that interconnect data centers are known as OTV edge devices.

OTV dynamically encapsulates Layer 2 packets into an IP header for the traffic sent to the remote data centers. Routing Layer 2 traffic on top of a Layer 3 network is known as “MAC routing” transport. MAC Routing leverages the use of a control protocol to propagate MAC address reachability information, this is in contrast with the traditional data plane learning done in technologies like VPLS.

In the next example, MAC 1 sends a Layer 2 frame to destination MAC 2. On the MAC table of the OTV edge device (DC1), MAC 1 is a local address (Eth1), while the destination MAC 2 belongs to a remote location reachable via the IP address B (remote OTV Edge device).

The local OTV-ED encapsulates the Layer 2 frame using an IP header with as IP destination “IP B”. The remote OTV-ED removes the IP header and forwards the frames to its internal interface (Eth 5). Local Layer 2 traffic is treated like any classical Ethernet switch (i.e. MAC 2 <=> MAC 3 on DC2).


A control plane protocol is used to exchange MAC reachability information between network devices, extending the VLANs between the remote sites while the learning process inside the data center is performed as in any traditional Layer 2 switch. This mechanism of advertisement destined to the remote OTV edge device differs fundamentally from classical Layer 2 switches, which traditionally leverage the data plane learning mechanism based on L2 source MAC address discovery: if the destination address is unknown after a MAC lookup on the MAC table, the traffic is flooded everywhere.

With OTV, the process for learning MAC addresses is performed by advertising the local MAC tables to all remote OTV edge devices. Consequently, if a destination MAC address is not known, the packet destined to the remote data center is dropped.

This technical innovation has the advantage of removing the risk of broadcasting unknown Unicast addresses from one site to another. This technique is based on a routing protocol, and provides a very stable and efficient mechanism of MAC address learning and Layer 2 extension while maintaining the failure domain inside each data center.

While OTV natively maintains the STP and the failure domain within each local data center, it provides the ability to deploy multiple OTV edge switches in the same data center in active mode. This function is known as Multi-Homing.

OTV works across any type of transport (Fiber, TCP/IP, MPLS) extended between the remote sites with the reliability and effectiveness of the Layer 3 protocol.

In addition to these primary functions, which are essential for the cloud networking, OTV offers several very important innovations:

OTV connects two or more sites to form a single virtual data center (Distributed Virtual Data Center). No circuit states are required between the remote sites to establish the remote connection. Each site and each link are independent and maintain an active state. This is known as “Point to Cloud” service, which allows a data center to be securely attached or removed at any time without configuring the remote sites and without disturbing cloud services.


OTV offers a native multicast traffic optimization function between all remote sites. OTV is currently available on Cisco Nexus 7000 Series Switches and the Cisco ASR 1000 Series Aggregation Services Routers.

This entry was posted in DCI. Bookmark the permalink.

3 Responses to 9 – Overlay Transport Virtualization (OTV)

  1. pratheesh says:

    Thank you for the OTV details provided.

    Can you please throw some lights on DCI Encryption.

    Since MACSec is a Hop-by-Hop encryption technology, it may not be a choice for long distance DCI implementation (except EoMPLS).

    I guess the current best bet on layer 2 expansion is OTV. Will I be able to consider IPSec on the Core device to encrypt OTV traffic? If I am running routing protocol on the core device between the , I will require GRE also.

    will I be able to negotiate the MTU in the provider network?
    Is there any other better way of accomplishing encryption for the above described scenario?

    Thank you and appreciate your input.

    • Yves says:

      Hi Pratheesh,

      Both options are valid, and certainly more .. It’s just to choose the right solution with the right design 🙂

      MACSec: Since recently we do support a loopback address for the join interface, meaning that we can enable multiple physical interfaces on the ip side.
      What that means is that we can create a back to back design using direct fiber links (including DWDM), hence establishing a Layer 2 adjacency interconnecting the two pairs of OTV edge devices in HA fashion.
      The L2 adjacency is required between the two pairs of OTV ED due to 802.1AE MACsec link-level encryption. Theoretically this should be the easiest and efficient way to encrypt OTV traffic and due to the OTV concept, it should not be limited to 2 sites back-to-back, That said, I never tried and that would requite some testing and qualification to validate this.

      IPsec: Contrary to native layer 2 traffic (e.g. vPC) that would required to be routed into the IPSec tunnel and therefore breaking your layer 2 extension requirements, OTV is an overlay that runs over a IP network. Thus we can use IPSec in the core to encrypt OTV traffic. If MTU might be a concern with some SP (although today it’s rare), this is not specific to OTV, it’s like any encapsulated transport, same for example comes with VPLS over GRE (over IPSec).
      Note that you don’t require a GRE tunnel for OTV, just an pure IPSec encrypted tunnel. Also keep in mind that IPSec is a small-scale meshing design making that would become complex ops while you increase the number of site to interconnect.

      Other options that you can think of (never tested myself) are GETVPN (any-to-any connectivity,more efficient if you have many sites to interconnect) or DMVPN.

      A very interesting topic to be detailed for a next post

  2. pratheesh says:

    Thank you for the details shared.

    will update once I lock down the telco service and the design.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.