Cisco Logo


Data Center and Cloud

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):

 

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 90 days. Please visit the Cisco Blogs hub page for the latest content.

20 Comments.


  1. 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.

       0 likes

  2. 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?

       0 likes

  3. 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

       0 likes

  4. 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

       0 likes

  5. 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”

       0 likes

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

       0 likes

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

       0 likes

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

       0 likes

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

       0 likes

  10. 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?

       0 likes

  11. Michael Gaughan

    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.

       0 likes

  12. 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?

       0 likes

  13. Is there any distance limitations on OTV?

       0 likes

  14. 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!!

       0 likes

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

       0 likes

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

       0 likes

  17. 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…

       0 likes

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

       0 likes

  19. 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???

    Thanks.

       0 likes

  20. 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?

       0 likes

  1. Return to Countries/Regions
  2. Return to Home
  1. All Data Center and Cloud
  2. All Security
  3. Return to Home