Ask the Expert: Deploying Cisco Overlay Transport Virtualization (OTV) in Data Center Networks

[ciscomoderator]

    

Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about how to plan, design, and implement Cisco Overlay Transport Virtualization (OTV) in your Data Center Network with Cisco experts Anees Mohamed Abdulla and Pranav Doshi.

Anees Mohamed Abdulla is a network consulting engineer for Cisco Advanced Services, where he has been delivering plan, design, and implementation services for enterprise-class data center networks with leading technologies such as vPC, FabricPath, and OTV. He has 10 years of experience in the enterprise data center networking area and has carried various roles within Cisco such as LAN switching content engineer and LAN switching TAC engineer. He holds a bachelor's degree in electronics and communications and has a CCIE certification 18764 in routing and switching. 

Pranav Doshi is a network consulting engineer for Cisco Advanced Services, where he has been delivering plan, design, and implementation services for enterprise-class data center networks with leading technologies such as vPC, FabricPath, and OTV. Pranav has experience in the enterprise data center networking area and has carried various roles within Cisco such as LAN switching TAC engineer and now network consulting engineer. He holds a bachelor's degree in electronics and communications and a master's degree in electrical engineering from the University of Southern California.

Remember to use the rating system to let Anees and Pranav know if you have received an adequate response.  

Because of the volume expected during this event, Anees and Pranav might not be able to answer each question. Remember that you can continue the conversation on the Data Center, sub-community forum shortly after the event. This event lasts through August 23, 2013. Visit this forum often to view responses to your questions and the questions of other Cisco Support Community members.

[Dennis Goh]

Hi gentleman,

With technologies like L2TP in Cisco routers, what are the advantages in using OTV considering that we have to pay for the OTV licenses? Thanks!

Regards,

Dennis Goh

[again.tl]

Hi,

What are the reasons of not using OTV for l2 extension? If we have the right platform, nexus 7000 or asr 1k today, is there any reason to use other l2 extension technology other than OTV?

Regards,

S/Y

[Mohamed Anees Mohammed Abdulla]

Hi Sophia,

  I don't see any reason to say why OTV is not the Layer 2 extension solution if you have the required hardware. The crictical component of Fault Isolation which is supported by OTV is a key element for its successful in the DCI domain.

OTV does require MTU size of the layer 3 interfaces between Data Centers to be increased to 42 bytes. And the same limitation is there for EoMPLS and VPLS as well. I don't see this would be a major issue for most of the customers.

Thanks,

Anees.

[again.tl]

Thanks Anees! So OTV is the prefered option if hardware meets requirement.

About MTU, other layer 2 extension supports fragmentation, but OTV doesn't. What is the solution if the transport doesn't support jumbo MTU?

Regards,

S/Y

[Pranav Doshi]

Hi Sophia,

There are two options.

Transport supports jumbo MTU : Deploy OTV with Nexus 7000 or ASR 1K

Transport does not support jumbo MTU : Deploy OTV with ASR 1K

Thanks,

Pranav

[again.tl]

Hi Pranav,

Can you elabrate bit more on that? Why should I use ASR 1K if transport does not support jumbo MTU? Does ASR1K support OTV fragmentation?

Regards,

S/Y

[Mohamed Anees Mohammed Abdulla]

Hi Sophia,

  It is nothing specific to OTV. ASR 1k can do packet fragmentation and reassembly. But in N7k, fragmentation occurs in software and we don't want that to happen in software due to performance issues. Hence in N7k when you run OTV we mark the OTV packets with DF bit set.

Thanks,

Anees.

[again.tl]

Thanks Anees! I thought there is DF bit set for OTV packet? Can you share the document that shows fragmentation is supported on ASR1K?

Regards,

S/Y

[Mohamed Anees Mohammed Abdulla]

http://www.cisco.com/en/US/docs/ios-xml/ios/wan/command/wan-m1.html#wp1501508090

[Mohamed Anees Mohammed Abdulla]

Hi Dennis,

    All those Layer 2 extension technologies require STP to be extended between Data Centers if you need to have multiple paths between Data Centers. OTV does not extend STP rather it has its own mechanism (AED election) to avoid loop when multiple paths are enabled. It means any STP control plane issue, we don't carry to the other Data Center.

    OTV natively suppresses Unknown Unicast Flooding across the OTV overlay. Unknown unicast flooding is a painful problem in layer 2 network and difficult to troubleshoot to identify the root cause if you don't have proper network monitoring tool.

   It has ARP optimization which eliminates flooding ARP packets across Data Center by responding locally with cached ARP messages. One of the common issues I have seen in Data Center is some server or device in the network sends continuous ARP packets which hits Control plane in the Aggregation layer which in turn causes network connectivity issue.

The above three points proves the Layer 2 domain isolation between data centers. If you have redundant Data Centers with Layer 2 extended without OTV, the above explained layer 2 issue which happens in one Data Center carries the same failure to the second data center which creates the question of what is the point of having two different Data Centers if we can not isolate the failure domain.

  OTV natively supports HSRP localization with few command lines. This is a very important requirement in building Active/Active Data Center.

Even though your question is related to L2TP, OTV deserves the comparison with VPLS and those comparison will also be applicable for L2TP. The below link explains in detail...

http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9402/white_paper_c11-574984.html

Thanks,

Anees.

[Fahad Wasi]

Hi Anees and Pravanv,

I have some questions about OTV,

Q.1 Is this a protocol?

Q.2 Is it only used in data centers?

Thanks

[Pranav Doshi]

Hi Fahad,

OTV is a LAN extension technology called, Overlay Transport Virtualization. OTV is an IP-based functionality that has been designed to provide Layer 2 extension capabilities over any transport infrastructure between Data Centres.

OTV provides an overlay that enables Layer 2 connectivity between separate Layer 2 domains while keeping these domains independent and preserving the fault-isolation, resiliency, and load-balancing benefits of an IP-based interconnection.

Please find a short video to OTV as a technology, its a 4-min video which will give you a good introduction to the OTV feature.

http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9402/prod_presentation_otv_intro.html

Also here is a more detailed white paper which goes through the introduction of OTV as a technology and its deployment scenarios:

http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/DCI/whitepaper/DCI_1.html

Thanks,

Pranav

[jerry.bonner]

Hello Gentlemen,

With OTV hardening in 5.2 and above, edge devices in the same site appear to be able to form overlay adjacencies with each other. This appears to be beneficial if the site adjacency fails for some reason. Typically edge devices are connected in a point to point fashion with another data center for DCI, however to form an overlay adjacency to an edge device within the same site seems to require a vpls or switched layer 2 transport between all devices in all data centers, otherwise how would an overlay adjacency form between two devices in the same site? Is OTV supported over VPLS? If so, are there any additional spanning tree concerns when doing so? Are there docs that cover this scenario?

Thank you!

[richbarb]

Hi Anees and Pravanv,

Is supported a OTV adjacency between N7K and ASR 1K?

Thanks.