Cisco Blogs

Under the Covers with OTV

February 9, 2010 - 20 Comments

So, lets take a closer at OTV and how it works.  As a reminder, OTV is an NX-OS feature that allows us to extend Ethernet LANs between data centers. One of the nice things about OTV is that it is transport agnostic–the connectivity between data centers can be L2 based, L3 based, IP switched or label switch–pretty much anything that can transport IP.


OTV works by creating an OTV control plane through authenticated links between the Nexus 7000 switches at each of your data centers (called edge nodes in OTV parlance).  You can then “route” your LAN traffic by encapsulating it and routing it through this IP infrastructure.  Routing of the traffic is determined by associating a MAC address with a next-hop IP address.  The process is fully dynamic, so there is no need to establish and manage tunnels and virtual wires.  This approach certainly simplifies management and administration over existing approaches, but it also allows you to take full advantage of your IP core such as optimal routing and features such as load balancing, multicast traffic replication, and fast failover.




The tables themselves are built transparently in the background, once OTV is configured, by proactively advertising MAC reachability. If the IP core supports multicast, the edge device advertises the address along with some extended attributes in a single updated that reaches all neighbors. The additional information, including VLAN ID, site ID, and associated IP addresses makes OTV a significantly smarter solution that other approaches, giving it the ability to support loop-free multi-homing, load balancing, First Hop Resiliency Protocol and ARP containment without generating increased complexity, processing overhead or the need for ancillary protocols. If the core does not support multicast, OTV can run with a “adjacency server mode” where one of the edge nodes is responsible for collecting and disseminating reachabilty information via unicast traffic.  In either case, OTV’s approach is an improvement over other approaches that that require explicit configuration of each connection of depend upon flooding information.


As noted above, the extra information OTV uses makes is a much more intelligent connectivity solution.  For example, OTV provides improved L2 fault isolation between locations: Spanning Tree BDPU are not forwarded into the core and neither are unknown unicasts. Cross site ARP traffic is reduced via proxy ARP capabilities in the edge nodes and broadcast traffic in general can be controlled via rate limiting and white lists.


So, what does all this technical goodness net you (yes, pun intended):


  • One-touch add/drop of sites without reconfiguration of other sites (point-to-cloud model)
  • Embedded intelligence obviates need for ancillary protocols such as VPLS
  • Dynamic design avoids the exponential complexity of virtual wires and the overhead and risk of flooding
  • When multihoming sites, OTV supports multiple active links on multiple edge (up to 16 per site) devices while avoiding loops for effective use of bandwidth and increased resiliency. OTV also supports both vPC and TRILL in this scenario as well as any multipathing offered by the underlying IP transport
  • OTV leverages IP multicast capabilities for optimal traffic replication and avoids head-end replication overhead
  • Fast failover based on an interior gateway protocol running between edge nodes, equal cost multipath and bidirectional forwarding detection extensions
  • Consolidation traffic from multiple VLANs over one overlay with support for over 4,000 VLAN IDs in a single 802.1Q domain
  • Ridiculously simple configuration

That’s it for now–if you have questions, post them in the comments–next post, I’ll look at some use cases for OTV.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. Hi Omar,

    How can we deploy OTV between 2 sites that are DC and DR? Currently, there are MPLS and dark fiber links between the sites for L3 and L2 links.

    I am trying to understand how I can deploy the Nexus 7000 (currently not in the network) for OTV?

  2. Hi Omar, I have two dark fibers, and I want to connect one Nexus in each data center,(P2P) my question is, is there any problems regarding the multicast requeriments in this scenario?.

    Other thing, May I use the same dark fibers for the OTV, that is the join interfaces, and to route traffic between the two data centers at the same time???


  3. Would you think that windows authentication would have any issues over the OTV? Any special considerations with mtu changes..

  4. Can OTV be implemented on an SVI? We have a gigabit Ethernet circuit with under 5ms ping times, but they require a layer 2 interface with an svi associated for routing…

  5. Hi,Can OTV support more than one VPN (customers)between any two Nexus boxes? If so how are the customers isolated?Thx

  6. Hi Omar,When is OTV being lauched ? or has it launched already ?RegardsAR

  7. Thanks Omar-How is it that we can implement the Jumbo frames and not affect the non jumbo traffic? Additionally, I read that the other switching platforms will also support the OTV, including the 6500 series specifically. What do you suppose is the time horizon for this addition to the feature set?Thanks!!

  8. Is there any distance limitations on OTV?

  9. Has anybody worked with OTV and firewalls between the layer 3 networks? We need to comply with PCI requirements but also want to use OTV to connect us to a second/DR data center. Any insight would be appreciated.Thanks!!!Mike.

  10. How can fragmentation not occur? A 1518 byte frame won’t fit in another. What am I missing? bilgisayar servisi

  11. I want to know how a device in one data centre will come to know about the mac address of other device in another centre?

  12. I would like to know how the ARP table is maintained on both the Nexus 7000? For a given IP address of some host at remote site, how Nexus 7000 gets the mac address?

  13. No OTV RFC yet–still working on pulling things together to get ready to submit a proposal.Omar

  14. not sure but is there any RFC released yet by Cisco or any other vendor on OTV?Cheers-Push Bhatkoti

  15. How can fragmentation not occur? A 1518 byte frame won’t fit in another. What am I missing?

  16. So, since OTV doesn’t fragment (which is reasonable), it sounds like for this to be useful with regular old 1500 byte IP MTU traffic, one needs to ensure that the IP network between the OTV edges supports jumbos.I’m assuming that the recommended and preferred solution is to enable jumbos between data centers.Where that isn’t possible, especially in the short term, is there something like an ip tcp adjust-mss”” option with it, or is this something we’d have to address on the end hosts?How many bytes does the OTV wrapper add?Thanks, David”

  17. Mike:OTV will work with firewalls; however, since the traffic is encapsulated, the firewall will only be able to apply policy against the outer header, which may mirror some of the info that is in the encapsulated header, such as VLAN ID or QoS marking. However, many of the things a firewall is probably interested in are hidden from the firewall. The trick is to deploy your firewall outside of the OTV edges, not between them.Omar

  18. Fabian:Thanks for your comment. I think enterprises will be please, but I also think service providers will find a lot to like about OTV and their ability to deliver servers.As to your question, OTV does not fragment frames. Forwarding is done in hardware and traffic is never directed to the CPU, relieving the CPU from any risk of overload.Omar

  19. Omar, how is OTV supported through appliances that like to do things to IP traffic like firewalls, VPN’s, and the like? Has Cisco done any testing with firewalls, what the next protocol in the IP header?

  20. Hi Omar,Very nice feature for Enterprises.Until now I was using GRE with Bridging but had some trouble with frame fragmentation (CPU overloaded have to go to Nexus).Will I get the same issue with OTV?Thanks, Fabian.