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

DSCP is preserved as it is across the tunnel.
Failure Isolation
One of the main requirements of every LAN extension solution is to provide Layer 2
connectivity between remote sites without giving up the advantages of resiliency, stability,
scalability, and so on obtained by interconnecting sites through a routed transport
infrastructure.
OTV achieves this goal by providing four main functions: Spanning Tree Protocol (STP)
isolation, Unknown Unicast traffic suppression, broadcast policy control, and ARP
optimization.
STP Isolation
By default, STP Bridge BPDU are not sent across the OTV overlay network. Because you
do not need to send BPDUs, this allows each data center to have its own spanning tree root
for each VLAN extended between data centers. This also allows each data center to
compute its spanning tree locally and independent of the other data centers. In addition to
spanning tree control-plane information not being sent across the overlay, the follow traffic
is also not sent across the overlay:
• Unknown unicast floods
• CDP
• LACP
• IGMP
• VTP
Unknown Unicast Handling with OTV
OTV uses a control-plane protocol to advertise MAC address reachability information
between the OTV edge devices. The MAC address reachability for remote MAC addresses
is a mapping of MAC address destinations to IP address next hop that are reachable across
the IP network. With the implementation of a control-plane protocol, the OTV Edge Device
behaves like a router instead of a Layer 2 bridge, much like how you learn Layer 3 prefixes
with routing protocols.
If an OTV Edge Device receives a frame where the destination MAC is an unknown unicast,
the Layer 2 traffic is flooded out the OTV internal interfaces only and not the OTV overlay
interface. The reason the traffic is flooded out the OTV internal interfaces is that the OTV
internal interfaces behave like regular Ethernet interfaces. There is also an assumption that
there are not any silent or unidirectional devices attached to the network.
For specific applications that require the flooding of Layer 2 traffic, unknown unicast mode,
a workaround is to statically configure the cluster Virtual MAC on the remote data center
OTV Edge Device:
Click here to view code image
Site-B-*OTV-ED*(config)# mac address-table static _Cluster