Cisco OTV (Part I)

OTV(Overlay Transport Virtualization) is a technology that provide layer2 extension capabilities between different data centers. In its most simplest form
OTV is a new DCI (Data Center Interconnect) technology that routes MAC-based information by encapsulating traffic in normal IP packets for transit.
Cisco has submitted the IETF draft but it is not finalized yet. draft-hasmit-otv-01

OTV Overview
Traditional L2VPN technologies, like EoMPLS and VPLS, rely heavily on tunnels. Rather than creating stateful tunnels, OTV encapsulates layer2 traffic
with an IP header and does not create any fixed tunnels.
OTV only requires IP connectivity between remote data center sites, which allows for the transport infrastructures to be layer2 based, layer3 based, or
even label switched. IP connectivity as the base requirement along some additional connectivity requirements that will be covered in this post.
OTV requires no changes to existing data centers to work, but it is currently only supported on the Nexus 7000 series switches with M1-Series linecards.
A big enhancement OTV brings to the DCI realm, is its control plane functionality of advertising MAC reachability information instead of relying on the
traditional data plane learning of MAC flooding. OTV refers to this concept as MAC routing, aka, MAC-in-IP routinig. The MAC-in-IP routing is done by
encapsulating an ethernet frame in an IP packet before forwarded across the transport IP network. The action of encapsulating the traffic between the
OTV devices, creates what is called an overlay between the data center sites. Think of an overlay as a logical multipoint bridged network between the
sites.
OTV is deployed on devices at the edge of the data center sites, called OTV Edge Devices. These Edge Devices perform typical layer-2 learning and
forwarding functions on their site facing interfaces (the Internal Interfaces) and perform IP-based virtualization functions on their core facing interface (the
Join Interface) for traffic that is destined via the logical bridge interface between DC sites (the Overlay Interface).
Each Edge Device must have an IP address which is significant in the core/provider network for reachability, but is not required to have any IGP
relationship with the core. This allows OTV to be inserted into any type of network in a much simpler fashion.

OTV Operation
Lets take a deeper look at how OTV works at the control plane.
As mentioned already OTV relies on the control plane to advertise MAC reachability information. The underlying routing-protocol used in the controlplane is IS-IS (Intermediate System to Intermediate System). IS-IS hellos and LSPs are encapsulated in the OTV IP multicast header. The OTV IS-IS
packets use a distinct Layer-2 multicast destination address. Therefore, OTV IS-IS packets do not conflict with IS-IS packets used for other technologies
The use of IS-IS is obvious to two reasons.
Firstly IS-IS does not use IP to carry routing information messages, it uses CLNS. Thus IS-IS is neutral regarding the type of network addresses for
which it can route traffic, making it ideal to route MAC reachability information.
Secondly through the use of TLVs. A TLV (Type, Length, Value) is an encoding format used to add optional information to data communication
protocols like IS-IS. This is how IS-IS could easily be extended to carry the new information fields
Do you need to understand IS-IS to understand OTV? Do you need to know how the engine of a car works in order to drive it? No, but its best to have at
least a base understanding how it all fits together.
Before any MAC reachability information can be exchanged, all OTV Edge Devices must become adjacent.

This is possible by using the specified OTV Control-Group across the transport infrastructure to exchange the control protocol messages and
advertise the MAC reachability information.

Additional documentation indicates that unicast transport support will be possible in future Cisco software releases (post NX-OS 5.1), by using
a concept known as an Adjacency Server. I will cover that later when relevant.

For now lets focus on using multicast in the transport infrastructure. All OTV Edge Devices should be configured to join a specific ASM (Any Source
Multicast) group where they simultaneously play the role of receiver and source. This is a multicast host functionality.