Hello, I can't see the reason why apart from - limitation and best practice - to separate instances for processes i.e. 'routing' 'otv encap/decap & trunk carrying vlans', it kind of makes sense I guess.
Which explains why there are 3 interfaces involved - INSIDE(L2), OVERLAY and OUSIDE - Join (L3)
Some extracts that might help:
The current Cisco N7K OTV implementation requires separation between SVI routing and OTV encapsulation for VLAN(s). In addition, the Join interface can only be defined as a physical interface (or subinterface) or as a logical one (i.e. Layer 3 port channel or Layer 3 port channel subinterface).
To meet these constraints:
- an OTV VDC dedicated to perform the OTV functionality
- a Distr VDC used to provide SVI routing support.
Guidelines and Limitations for OTV
OTV has the following configuration guidelines and limitations:
- 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).
- 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.
- Do not configure OTV on an F-series module.
- 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 5.2(1) to an image that is Cisco NX-OS 5.2(1) or later in an OTV network is disruptive. A software image upgrade from Cisco NX-OS 5.2(1) or later to Cisco NX-OS 6.0(1) is not disruptive.
- 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 as OTV interoperates between sites with different Cisco NX-OS versions.
I currently use OTV with ASR1000's and I am unable to create vlan's on it anyway so by default I'm following this practice. Not entirely sure about the 7K's and if you are able to do this or if its restricted as a limitation from the word go!
Hope this helps
Please rate useful posts and remember to mark any solved questions as answered. Thank you.
Please rate useful posts & remember to mark any solved questions as answered. Thank you.
