OTV has the
following configuration guidelines and limitations:
-
When the OTV VDC and the MPLS VDC share the same instance of the M2 forwarding engine (FE), there is a chance for traffic
blackholing. The blackholing is because of the MPLS label in MPLS VDC overlap with the MPLS label, which is used to encode
the OTV extended VLAN ID (OTV MPLS label = VLAN ID + 32) in the OTV VDC.
This traffic blackholing problem can be avoided by the following methods:
-
You need to allocate the interfaces on the same M2 FE in such a way that the interfaces are not shared between multiple VDCs
that utilize the MPLS.
For N7K-M224XP-23L (24-port 10GE): ports 1 to 12 are served by FE 0, and ports 13 to 24 are served by FE 1.
For N7K-M206FQ-23L (6-port 10/40GE): ports 1 to 3 are served by FE 0, and ports 4 to 6 are served by FE 1.
-
If the same
device serves as the default gateway in a VLAN interface and the OTV edge
device for the VLANs being extended, configure OTV on a device (VDC or switch)
that is separate from the VLAN interfaces (SVIs).
-
The site VLAN must not be extended into the OTV. This configuration is not supported and this helps to avoid unexpected results.
-
When possible,
we recommend that you use a separate nondefault VDC for OTV to allow for better
manageability and maintenance.
-
An overlay
interface will only be in an up state if the overlay interface configuration is
complete and enabled (no shutdown). The join interface has to be in an up
state.
-
Configure the
join interface and all Layer 3 interfaces that face the IP core between the OTV
edge devices with the highest maximum transmission unit (MTU) size supported by
the IP core. OTV sets the Don't Fragment (DF) bit in the IP header for all OTV
control and data packets so the core cannot fragment these packets.
-
Only one join
interface can be specified per overlay. You can decide to use one of the
following methods:
-
Configure a
single join interface, which is shared across multiple overlays.
-
Configure a
different join interface for each overlay, which increases the OTV reliability.
For a higher
resiliency, you can use a port channel, but it is not mandatory. There are no
requirements for 1 Gigabit Ethernet versus 10 Gigabit Ethernet or dedicated
versus shared mode.
-
If your network
includes a Cisco Nexus 1000V switch, ensure that switch is running 4.0(4)SV1(3)
or later releases. Otherwise, disable Address Resolution Protocol (ARP) and
Neighbor Discovery (ND) suppression for OTV.
-
The transport
network must support PIM sparse mode (ASM) or PIM-Bidir multicast traffic.
-
OTV is
compatible with a transport network configured only for IPv4. IPv6 is not
supported.
-
Do not enable
PIM on the join interface.
-
ERSPAN ACLs are
not supported for use with OTV.
-
Ensure the site
identifier is configured and is the same for all edge devices on a site. OTV
brings down all overlays when a mismatched site identifier is detected from a
neighbor edge device and generates a system message.
-
Any upgrade from
an image that is earlier than Cisco NX-OS Release 5.2(1) to an image that is
Cisco NX-OS Release 5.2(1) or later in an OTV network is disruptive. A software
image upgrade from Cisco NX-OS Release 5.2(1) or later to Cisco NX-OS Release
6.0(1) is not disruptive.
-
Any upgrade from
an image that is earlier than Cisco NX-OS Release 6.2(2) to an image that is
Cisco NX-OS Release 6.2(2) or later in an OTV network is disruptive. When you
upgrade from any previous release, the OTV overlay needs to be shut down for
ISSU to operate.
-
You must
upgrade all edge devices in the site and configure the site identifier on all
edge devices in the site before traffic is restored. An edge device with an
older Cisco NX-OS release in the same site can cause traffic loops. You should
upgrade all edge devices in the site during the same upgrade window. You do not
need to upgrade edge devices in other sites because OTV interoperates between
sites with different Cisco NX-OS versions.
-
Beginning with
Cisco NX-OS Release 6.2, OTV supports the coexistence of F1 or F2e Series
modules with M1 or M2 Series modules in the same VDC.
-
For OTV fast
convergence, remote unicast MAC addresses are installed in the OTV Routing
Information Base (ORIB), even on non-AED VLANs.
-
For OTV fast
convergence, even non-AED OTV devices create a delivery source, delivery group
(DS,DG) mapping for local multicast sources and send a join request to remote
sources if local receivers are available. As a result, there are two remote
data groups instead of one for a particular VLAN, source, group (V,S,G) entry.
-
One primary IP
address and no more than three secondary IP addresses are supported for OTV
tunnel depolarization.
-
F3 Series
modules do not support the VLAN translation and traffic depolarization features
in Cisco NX-OS Release 6.2(6).
-
F3 Series
modules support the OTV traffic depolarization feature in Cisco NX-OS Release
6.2(8).
-
F2 Series
modules in a specific VDC do not support OTV. F2e modules work only as internal
interfaces in an OTV VDC.
-
F3 Series
modules in an OTV VDC should not have the VLAN mode configured as Fabricpath.
-
F3 Series
modules do not support data-group configurations for subnets larger than /27,
in Cisco NX-OS Releases 6.2(14) / 7.2(x) and earlier. Starting from Release
6.2(16) / 7.3(0), the largest subnet mask supported is /24.
-
NXOS does not
support using FEX ports for OTV site or core facing interfaces.
-
Beginning with
Cisco NX-OS Release 7.3(0)DX(1), M3 Series modules are supported.
-
The OTV VLAN
mapping feature is not supported on the Cisco M3 Series and F3 Series modules,
as explained in this chapter (using the
otv vlan
mapping command). In order to have VLAN translation on OTV
devices using F3 or M3 line cards, you should use per-port VLAN translation on
the OTV edge device internal interface (L2 trunk port), as described in the
Configuring OTV VLAN Mapping
using VLAN Translation on a Trunk Port document.