nx.os.and.cisco.nexus.switching.2nd.edition.1587143046

MAC_ vlan vlan-name
interface OTV-internal-interface
This enables the OTV Edge Device in the remote site to advertise the Cluster MAC to the
OTV edge devices in the primary data center, enabling communication. This results in the
unknown unicast MAC not being unknown anymore.
Broadcast Traffic Handling with OTV
Layer 2 broadcast traffic is sent across the overlay network. With Multicast-enabled
transport, the broadcast frames are sent to all remote OTV Edge Devices to the same ASM
multicast group in the transport already configured for the OTV control-plane adjacency.
For unicast-only transport infrastructure deployments, head-end replication performed on
the OTV device in the site originating the broadcast would ensure traffic delivery to all the
remote OTV Edge Devices part of the unicast-only list.
Multihoming with OTV
Deploying devices in pairs for high availability is always preferred in data center networks.
Because you do not send any spanning tree BPDU control-plane information across the OTV
overlay network, you must have a method to support multihoming in which there are two (or
more) OTV Edge Devices that provide LAN extension services to a given site to prevent an
end-to-end data-plane loop.
To support multihoming, an AED is elected on a per-VLAN basis. A site-vlan is created for
the AED communication; each AED gets an ordinal value. The ordinal value is either “0” or
“1”; the AED that has an ordinal value of “0” is the AED for all the even VLANs extended
across OTV, and the AED that has the ordinal value of “1” is the AED for all the off VLANs
extended across OTV. The AED is responsible for sending and receiving Unicast, Multicast,
and broadcast traffic if an AED that is nonauthoritative for a given VLAN that receives
Unicast, Multicast, and broadcast traffic drops the traffic. The OTV Edge Device is the
mechanism that enables multihoming and prevents the end-to-end loop between multiple
data centers on a per VLAN basis. For the site-vlan, it is recommended to carry the site
VLAN on the same interfaces as the extended VLANs; this ensures that if the site-vlan goes
down, so will the extended-vlans. Another deployment recommendation is for the site-vlan
to use the same VLAN as the site-vlan on all OTV Edge Devices between data centers;
remember do not extend the site-vlan across an OTV.
Note
As of today, with the latest NX-OS releases supporting OTV (5.2.5, 6.0.4, and 6.1.1),
you cannot change to AED odd-and-even AED load-balancing.
Starting with NX-OS release 5.2.1 and later, a second adjacency is added in addition to the
site-vlan adjacency. The second adjacency is the overlay adjacency; this adjacency is
established over the OTV Layer 3 join interfaces. The overlay adjacency is required to
configure and deploy OTV; all OTVE Devices in the same data center must be configured