OTV is one of the many exciting new protocols we get to study in the CCNA Data Center. However, what the heck is it? What problems does it address? Let’s tackle that in this post.
Today, we often locate data centers a far distance from each other, and we might often need to make them look like they are the same structure from a Layer 2 perspective. For example, two virtualized services might expect to be able to find each other at Layer 2. In the past, solutions like EoMPLS (Ethernet over MPLS) and dark fiber were attempted. Unfortunately, these solutions present many issues of their own.
Enter the OTV solution. This technology does what we like to call MAC address routing. A control plane protocol exchanges MAC address reachability information between the data centers.
OTV does not require additional configuration to support multihoming and spanning tree protocol domain independence. OTV ensures that if there is an STP failure in one data center, it does not affect the other data center.
One of my favorite facets of OTV is the fact that the routing protocol in use in the control plane to make OTV function is IS-IS! This standards-based, OSPF competitor is making a real comeback. It was selected because it is a standard-based protocol, originally designed with the capability of carrying MAC address information in the TLV. Sadly, OTV does not get the credit in naming it deserves as most call the control plane protocol of OTV simply the OTV Protocol.
Interestingly, most deployments require no specific knowledge of IS-IS configuration (or even theory) since the routing protocol works its magic automatically as OTV is configured on your devices.
I will be back with other follow up posts on this technology including a look at terminology and configuration.
If you want to peek ahead and have some fun – check out the CBT Nugget below from yours truly!
Check out my very latest CCNA Data Center training (Late 2018) at CBT Nuggets: