Cisco OTV : Quick overview

 

When facing a multiple virtualized datacenter challenge, one easily would pick a layer2 backbone between datacenters because of Virtual Machines able to vMotion to another datacenter. Layer2 has not been developed to be scalable between datacenters however. One must realize that all Layer2 errors ocurring in on datacenter can easily spread over the Layer2 link towards all you DRP datacenters… This blogpost is about OTV, an answer to datacenter scalability while still having Layer2 connectivity between end devices.

 

Important OTV Features

Scalability

• Extends Layer 2 LANs over any network that supports IP
• Designed to scale across multiple data centers

Simplicity

• Supports transparent deployment over existing network without redesign
• Requires minimal configuration commands (as few as four)
• Provides single-touch site configuration for adding new data centers

Resiliency

• Preserves existing Layer 3 failure boundaries
• Provides automated multihoming
• Includes built-in loop prevention

Efficiency

• Optimizes available bandwidth, by using equal-cost multipathing and optimal multicast replication

 

So how does OTV work ? It will create a custom Layer2 network on top of you existing Layer3 network by encapsulation all Layer2 packets destined for another datacenter in Layer3 packets. Broadcasts, boot storms, spanning-tree loops will all be contained in one datacenter as these packets will be filtered or not forwarded at all. When your backbone consists of an MPLS network, you can achieve any-to-any Layer2 datacenter connectivity without any of the risks or downsides… pretty neat!

 

 

The requirements for OTV are pretty simple : you need a Nexus 7000 series with a M2 line card. The F1 and F2 line cards do not support the OTV feature. If your Nexus 7000 acts as the default gateway with VLAN SVI’s you will have to create a separate OTV VDC as SVI’s and OTV are not compatible.

 

You should also have a clear isolation model for your FHRP protocols. In a traditional Layer2 extension, you would have an FHRP active-standby scenario over multiple datacenters. This is still possible with OTV, however this might lead to inefficient use of bandwidth and latency. If you decide to have an active FHRP in each datacenter, you will need to manually isolate the FHRP to one datacenter.

 

I’m unsure where to place OTV in a solution perspective. It seems it’s more like a enterprise solution as it supports only 256 vlan’s at the moment. However with the VDC capability of the Nexus 7000 it’s possible to create up to 8 VDC’s per Nexus switch creating the opportunity to sent up to 2048 vlan’s over 8 different OTV networks. The design of such a solution seems a bit cumbersome to me.

 

Another limitation is the amount of OTV devices in one site, which is limited to 2, and total OTV sites in total, which is limited to 6.

 

If your a service provider and thinking about OTV as your datacenter interconnect protocol, think about your vlan strategy before deploying virtual environments and DRP datacenters.