OTV Best Practices - NetCraftsmen https://netcraftsmen.

com/otv-best-practices/

07 // 23 // 12

OTV BEST PRACTICES

Author
PETER WELCHER
Architect, Operations Technical Advisor

(/team/peter-welcher)

OTV Best Practices have come to the forefront lately. Various sites are starting to implement OTV.
The ones I’m aware of to date are aware they are taking a minor risk (immature technology). They
have chosen to go ahead anyway because they are migrating to new data centers and OTV is
potentially very helpful in doing so. You don’t need to be doing live VMotion for the bene�t to be seen.
Even if you are moving physical servers, OTV can be helpful. So if you’re going to be doing OTV,
doing it the best way is obviously the way to go. This blog assumes you know how OTV works, and
focuses on best practices (Cisco’s, mine, lessons learned).

REMIND ME ABOUT OTV

For those who somehow missed all the Cisco press and my prior blogs: OTV is a way to transport
Layer 2 between data centers over any (su�ciently high speed) Layer 3 IP network. I consider it the
best of the Data Center Interconnect (DCI) approaches Cisco provides. OTV includes technology to
reduce WAN ARP broadcast tra�c, isolate STP instances to each data center, etc. That does not
make it perfect: any DCI technique necessarily allows BUM (Broadcast, Unknown Unicast, Multicast)
tra�c to slosh between sites — it has to, or various protocols and applications would break. OTV
reduces broadcast tra�c by doing ARP caching and �ltering. Apparently further tools to �lter
broadcast or BUM tra�c may appear in future releases, but are not yet available.

See the OTV Technology Introduction and Deployment Considerations (http://www.cisco.com/en/US

1 από 7 12/3/2021, 11:42 μ.μ.

OTV Best Practices - NetCraftsmen https://netcraftsmen.com/otv-best-practices/

/docs/solutions/Enterprise/Data_Center/DCI/whitepaper/DCI_1.html) document, at
http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/DCI/whitepaper/DCI_1.html
(http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/DCI/whitepaper/DCI_1.html). It
contains lots of good design and other information. I intend to summarize main points from it and from
my brain, to give you somewhat of a checklist you can use. Being a consultant, of course I also highly
recommend professional design advice and review!

THE HIDDEN OTV BEST PRACTICES

I’m going to start with the part that isn’t in the above document, i.e. “hidden” OTV best practices.

From recent experience, there is one best practice you will want to incorporate in your action plan,
one that is hinted at but not really spelled out in the above document. With any Data Center
Interconnect technique, you really should implement the various functions that limit broadcast tra�c
and mitigate its consequences: tra�c storm control, hardware rate limiting, and CoPP (Control Plane
Policing).

See also my blog about Tra�c Storm Control (https://netcraftsmen.com/understanding-cisco-tra�c-

storm-control/) and Augustine Traore’s blog (https://netcraftsmen.com/resource/protecting-a-cisco-
catalyst-6500-switch-against-layer-2-loops/) �tting that into a set of techniques to mitigate STP loop
impact. The latter comes complete with graphs showing the bene�t on a Cisco 6500 with Sup720.

By the way, you really also should implement all the other STP loop defenses that everyone knows
about but nobody deploys (at least not until burned): BPDU guard, Root Guard, Loop Guard, and
UDLD or Bridge Assurance. If you don’t have a STP loop in the �rst place, then you won’t need tra�c
storm control, hardware

MAINSTREAM OTV BEST PRACTICES

Note that VLAN SVI’s cannot co-exist on the same router or VDC as OTV transport of those
VLANs. The solution is to either do OTV in another router (Nexus 7K or ASR 1000), or do
“OTV-on-a-stick”. The latter is where you use a trunk for L2 and L3 connectivity from core
router (or other router) to an OTV device or VDC. Or use two links, one at L3 and one at L2. L3
usually ends up on the L3 WAN or site core. L2 may end up there or at the distribution layer —
however high in the hierarchical design your server VLANs extend.

(I feel the lack of a diagram here … see the Cisco document above for many diagrams.)

Con�gure the site ID. It can’t hurt. And it’s now mandatory (per TFM). As to why, see the next
item.

If you have two OTV devices at a site, make sure they can route to each other. OTV now
requires both site VLAN heartbeat and OTV-side adjacency to operate. I prefer to have a fairly
direct connection for this, i.e. if the L3 side of the OTV device or VDC connects to your site or
WAN core, then make sure the two WAN cores are connected to each other at L3. Routing via
a site L2 core and crosslink puts a lot of devices, links, and some routing in between the OTV

2 από 7 12/3/2021, 11:42 μ.μ.