OTV in a nutshell

OTV edge devices (7018s) have two interfaces:
1. Internal facing L2 that functions exactly like any traditional switch with (mac, i/f) mappings in the table.
2. Core facing "join-interface" which connects to the "overlay-network"

Each site has an AED (active edge device) that is responsible for advertising (mac, join-interface-IP) into the overlay-network. All this happens over an multicast control-group (say, 239.1.1.1) that all the AED's join (core-facing, therefore the need for ASM capable core, which we have and support). IS-IS is the underlying link-state protocol which allows the AEDs to advertise their local mac-addresses that they learn from the "internal-facing" L2 segments.

Packet forwarding proceed thusly:

1. If dst mac is local to site, traditional switching with (mac, i/f) path is taken.
2. if dst mac is remote, OTV encapsulates complete L2 header (w/ 802.1q tag but strips off preamble and FCS) into an IP/UDP packet with dst-IP being the remote-AED that advertised the mac. The source is local-AED join-interface IP, and UDP dest port is 8472.
3. Multicast traffic handling is more sophisticated with (DS, DG) where (S,G) is mapped to (DS, DG) and fired off into core network. DS = Delivery Source, DG = Delivery Group. S = Source, G = Group.

VM vMotion:

1. When a VM moves, the mac moves with it.
2. The AED at the new site detects the presence of a mac on the outside (mac, remote-AED-IP) AND now on the inside (mac, i/f)
3. This triggers the AED to advertise the mac into the overlay with metric 0
4. The original site, upon noting this advertisement immediately withdraws its own (mac, join-interface-IP) with a rapid IS-IS LSP on the control-plane.