Approach to Cisco OTV- Overlay Transport Virtualization in Datacenter DCI connectivity

Today I am going to talk about the one of the overlay protocol used in the traditional Cisco data center environment. This Overlay protocol is widely used where you are going to connect two different data center across the globe having core Cisco switching. The Overlay protocol which we are talking about it Cisco OTV. OTV stands for Overlay Transport Virtualization.

What is Cisco OTV- Overlay Transport Virtualization ?
Cisco OTV is an overlay protocol and used to simplifies extending Layer 2 applications across distributed data centers. We can implement Data Center Interconnect (DCI) between sites without altering or re-configuring your existing network design.

With OTV you can install virtual computing assets and clusters throughout physically spread data centers across the globe. OTV can provide you Transparent workload mobility, Business Resiliency and computing resources efficiency.

What king of traffic can be transmitted over Cisco OTV ?
OTV is an IP-based functionality that has been intended to deliver Layer 2 extension abilities over any transport structure Layer 2 based, Layer 3 based, IP switched, label switched. OTV offers an overlay that permits Layer 2 connectivity among independent Layer 2 domains while maintaining these domains autonomous and protective the fault-isolation, resiliency, and load-balancing profits of an IP-based interconnection.

Fig 1.1- Basic OTV connectivity between sites
Cisco OTV initiates the idea of MAC routing which capitals a control plane protocol is used to interchange MAC reachability data between network devices offering LAN extension capabilities. This is a important shift from Layer 2 switching that conventionally influences data plane learning, and it is acceptable by the requirement to threshold overflowing of Layer 2 traffic throughout the transport structure.

Cisco OTV also presents the impression of dynamic encapsulation for Layer 2 traffic that essential to be directed to faraway sites. Each Ethernet frame is separately encapsulated into an IP packet and transported throughout the transport network. This abolishes the requirement to inaugurate virtual circuits, called Pseudo wires, among the data center localities.

What are the components of the OTV overlay protocol ?
We have various components in the OTV overlay protocol and these components are
OTV Edge device
OTV internal interfaces
OTV Join interface
OTV Overlay Interface

What is OTV Edge device ?
The Cisco OTV edge device collects Layer 2 traffic for all VLANs that required to be extended to faraway sites and dynamically encapsulates the Ethernet frames into IP packets that are then sent across the transport infrastructure. In a traditional architecture of Cisco OTV, Cisco Nexus core 7000/7700 will be your OTV edge device but with the different VDC.

Can you explain the interfaces used in the Cisco OTV which are mentioned above ?
Yes, First of all we will discuss about the internal interface.

Fig 1.2- OTV interfaces and Edges
OTV internal Interface: To accomplish OTV functionality, the edge device must accept the Layer 2 traffic for all VLANs that required to be extended to far branch sites. The internal interfaces collects the layer 2 traffic from the core switch and configured as access or trunk interface. It do the basic functions of local switching, STP, Data plane learning and flooding

OTV Join Interface: As you might know that the connectivity between one data center to another is with the layer 3 IP domain and the traffic we collected from the Core switches is Layer 2 traffic which we have it on the OTV internal interface, now this traffic encapsulated and send it to the layer 3 domain of the data center. So OTV join interface will work as a source port for sending the traffic across the other sites.

It can also perform to discover the edge devices on the remote sites. It also form OTV adjacency with the other OTV edge devices belonging to the same VPN. It can also use for Send/receive MAC reachability information and Send/receive unicast and multicast traffic.

OTV Overlay Interface: This is the logical interface by which the traffic flows. It is a multi-access and multicast-capable interface that must be clearly described by the client and the complete OTV configuration is applied.

Every time the OTV edge device accepts a Layer 2 frame destined for a far ended data center site, the frame is logically dispatched to the Overlay interface. This initiates the edge device to accomplish the dynamic OTV encapsulation on the Layer 2 packet and direct it to the Join interface toward the routed domain.

Can you give some idea over the Cisco OTV Neighbor Discovery ?
Every OTV edge appliance transmit an IGMP information to join the exact ASM group used to bring control protocol exchanges. The edge devices join the group as hosts, leveraging the Join interface. This occurs without permitting PIM on this interface. The only obligation is to identify the ASM group to be used and associate it with a given Overlay interface.

Fig 1.3- OTV between Data centers
The OTV control protocol running on the one OTV edge appliance produces Hello packets that required to be directed to all other OTV edge devices. This is mandatory to interconnect its existence and to activate the formation of control plane adjacency.

The OTV Hello messages required to be directed throughout the logical overlay to spread all OTV remote appliances. For this to occur, the frames must be OTV-encapsulated, enhancing an exterior IP header. The source IP address in the exterior header is set to the IP address of the Join interface of the edge device, while the destination is the multicast address of the ASM group dedicated to transmit the control protocol. The follow-on multicast frame is then directed to the Join interface to the Layer 3 network domain.

Fig 1.4- Basic OTV Configuration
The multicast frames are transmitted through the transport and simulated to extend all the OTV edge appliances that tied that multicast group G. The accepting OTV edge devices decapsulate the packets. The Hellos are accepted to the control protocol process.