Overlay Transport Virtualization (OTV)
Overlay transportation introduces the concept of “MAC routing,” which means a control plane protocol is used to exchange MAC reachability information between network devices providing LAN extension functionality. This is a significant shift from Layer 2 switching that traditionally leverages data plane learning, and it is justified by the need to limit flooding of Layer 2 traffic across the transport infrastructure. As outlined in this chapter, Layer 2 communication between sites resembles routing more than switching. If the destination MAC address information is unknown, traffic is dropped (not flooded), preventing the waste of precious bandwidth across the WAN.
OTV also introduces the concept of the dynamic encapsulation for Layer 2 flows that need to be sent to remote locations. Each Ethernet frame is individually encapsulated into an IP packet and delivered across the transport network. This eliminates the need to establish virtual circuits, called pseudowires, between the data center locations. Immediate advantages include improved flexibility when adding or removing sites to the overlay, more optimal bandwidth utilization across the WAN (specifically when the transport infrastructure is multicast enabled), and independence from the transport characteristics (Layer 1, Layer 2, or Layer 3).
OTV provides a native built-in multihoming capability with automatic detection. Two or more devices can be leveraged in each data center to provide LAN extension functionality without running the risk of creating an end-to-end loop that would jeopardize the overall stability of the design. This is achieved by leveraging the same control plane protocol used for the exchange of MAC address information, without the need of extending the Spanning Tree Protocol (STP) across the overlay.
OTV Terminology
To understand how OTV works in an existing IP transport environment, let’s discuss the OTV interfaces and terms shown in Figure 3-1.
)
Figure 3-1 OTV Interfaces and Terms
Edge device (ED): This device connects the site to the (WAN/MAN) core and is responsible for performing all the OTV functions.
An edge device receives Layer 2 traffic for all VLANs that need to be extended to remote locations and dynamically encapsulates the Ethernet frames into IP packets that are then sent across the OTV transport infrastructure.
For resiliency, two OTV edge devices can be deployed on each site to provide redundancy.
Internal interfaces: These are the L2 interfaces (usually 802.1q trunks) of the ED that face the site.
Internal interfaces are regular access or trunk ports.
Trunk configuration will extend more than one VLAN across the overlay. There is no need to apply OTV-specific configuration to these interfaces.
Typical Layer 2 functions (like local switching, spanning tree operation, data plane learning, and flooding) are performed on the internal interfaces.
Join interface: This is the L3 interface of the ED that faces the core. The join interface is used by the edge device for different purposes:
“Join” the overlay network and discover the other remote OTV edge devices.
Form OTV adjacencies with the other OTV edge devices belonging to the same VPN.
Send/receive MAC reachability information.
Send/receive unicast and multicast traffic.
Overlay interface: This is a logical multiaccess multicast-capable interface. It encapsulates Layer 2 frames in IP unicast or multicast headers.
Every time the OTV edge device receives a Layer 2 frame destined for a remote data center site, the frame is logically forwarded to the overlay interface. This instructs the edge device to perform the dynamic OTV encapsulation on the Layer 2 packet and send it to the join interface toward the routed domain.
OTV Control Plane Function
The principle of OTV is to build a control plane between the OTV edge devices to advertise MAC address reachability information instead of using data plane learning. However, before MAC reachability information can be exchanged, all OTV edge devices must become “adjacent” to each other from an OTV perspective.
Edge devices can be made adjacent in two ways, depending on the nature of the transport network interconnecting the various sites:
If the transport is multicast enabled, a specific multicast group can be used to exchange the control protocol messages between the OTV edge devices.
If the transport is not multicast enabled, an alternative deployment model is where one (or more) OTV edge device can be configured as an adjacency server to which all other edge devices register; this server communicates to them the list of devices belonging to a given overlay.
Multicast-Enabled Transport Infrastructure
If transport supports multicast, all OTV edge devices can be configured to join a specific any-source multicast (ASM) group where they simultaneously play the role of receiver and source. If the transport is owned by a service provider, the user will have to negotiate the use of this ASM group with the service provider.
Two important considerations for the OTV control plane protocol are as follows:
This protocol runs as an “overlay” control plane between OTV edge devices, which means there is no dependency with the routing protocol (IGP or BGP) used in the Layer 3 domain or in the transport infrastructure.
The OTV control plane is transparently enabled in the background after creating the OTV overlay interface and does not require explicit configuration. Tuning parameters, like timers, for the OTV protocol is allowed, but this is expected to be more of a corner case than a common requirement.
From a security perspective, it is possible to leverage the IS-IS HMAC-MD5 authentication feature to add an HMAC-MD5 digest to each OTV control protocol message. The digest allows authentication at the IS-IS protocol level, which prevents unauthorized routing messages from being injected into the network routing domain. At the same time, only authenticated devices will be allowed to successfully exchange OTV control protocol messages between them and hence to become part of the same overlay network.
The same control plane communication is also used to withdraw MAC reachability information. For example, if a specific network entity is disconnected from the network, or stops communicating, the corresponding MAC entry would eventually be removed from the CAM table of the OTV edge device. This occurs by default after 30 minutes on the OTV edge device. The removal of the MAC entry triggers an OTV protocol update so that all remote edge devices delete the same MAC entry from their respective tables.
Unicast-Only Transport Infrastructure (Adjacency-Server Mode)
OTV can be deployed with unicast-only transport. As previously described, a multicast-enabled transport infrastructure lets a single OTV update or Hello packet reach all other OTV devices by virtue of leveraging a specific multicast control group address.
The OTV control plane over a unicast-only transport works exactly the same way as OTV with multicast mode. The only difference is that each OTV device would need to create multiple copies of each control plane packet and unicast them to each remote OTV device part of the same logical overlay. Because of this head-end replication behavior, leveraging a multicast-enabled transport remains the recommended way of deploying OTV in cases where several DC sites are involved. At the same time, the operational simplification brought about by the unicast-only model (removing the need for multicast deployment) can make this deployment option very appealing in scenarios where LAN extension connectivity is required only between a few (two to three) DC sites.
To be able to communicate with all the remote OTV devices, each OTV node needs to know a list of neighbors to replicate the control packets to. Rather than statically configuring the list of all neighbors in each OTV node, a simple dynamic means is used to provide this information. This is achieved by designating one (or more) OTV edge device to perform a specific role, named the adjacency server. Every OTV device wishing to join a specific OTV logical overlay needs to first “register” with the adjacency server (by sending OTV Hello messages to it). All other OTV neighbor addresses are discovered dynamically through the adjacency server. Consequently, when the OTV service needs to be extended to a new DC site, only the OTV edge devices for the new site need to be configured with the adjacency server addresses. No other sites need additional configuration. Figure 3-2 shows the differences between multicast-enabled transport and unicast-only transport.
)
Figure 3-2 OTV Control Plane
OTV Data Plane Function
After the control plane adjacencies established between the OTV edge devices and MAC address reachability information are exchanged, traffic can start flowing across the overlay. Similar to any L2 Switch, data plane traffic can be
Unicast traffic
Multicast traffic
Broadcast traffic
Unicast Traffic over OTV
In a Layer 2 switch, if PC1 is trying to communicate with PC2 and both belong to the same VLAN, the switch will perform Layer 2 MAC address lookup and forward the traffic to the destination local port. In OTV, an edge device will perform Layer 2 lookup, and the destination will be the remote edge IP address (as shown in Figure 3-3). The OTV edge will encapsulate the Layer 2 frames over Layer 3 and transport it to the OTV remote edge, as shown using the following steps:
)
Figure 3-3 OTV Unicast Data Plane
Step 1. PC1 starts sending traffic to PC2.
Step 2. When traffic reaches the aggregation layer device (an OTV edge device), a usual Layer 2 lookup is performed to determine how to reach PC2.
Step 3. The MAC table points to a remote OTV edge IP address (in a local switch, MAC points to a local interface).
Step 4. The OTV edge device encapsulates the original Layer 2 frame. The source IP of the outer header is the IP address of its join interface, whereas the destination IP is the IP address of the join interface of the remote edge device. The OTV-encapsulated frame (a regular unicast IP packet) is carried across the transport infrastructure and delivered to the remote OTV edge device.
Step 5. The remote OTV edge device decapsulates the packet, exposing the original Layer 2 frame.
Step 6. The edge device performs another Layer 2 lookup on the original Ethernet frame and discovers that it is reachable through a physical interface, which means it is a MAC address local to the site.
Step 7. The frame is delivered to the MAC destination.
Given that Ethernet frames are carried across the transport infrastructure after being OTV encapsulated, some considerations around MTU are necessary. In the first implementation, the OTV encapsulation increases the overall MTU size of 42 bytes. This is a result of the operation of the edge device that removes the CRC and the 802.1Q fields from the original Layer 2 frame and adds an OTV Shim (containing the VLAN and Overlay ID information also) and an external IP header.
All OTV control and data plane packets originate from an OTV edge device with the Don’t Fragment (DF) bit set. In a Layer 2 domain, the assumption is that all intermediate LAN segments support at least the configured interface MTU size of the host. This means that mechanisms like Path MTU Discovery (PMTUD) are not an option in this case.
Also, fragmentation and reassembly capabilities are not available on Nexus platforms. Consequently, Cisco recommends increasing the MTU size of all the physical interfaces along the path between the source and destination endpoints to account for introducing the extra 42 bytes by OTV.
Multicast Traffic over OTV
In certain scenarios, there may be a requirement to establish Layer 2 multicast communication between remote sites. This is the case when a multicast source sending traffic to a specific group is deployed in a given VLAN 10 in site A, whereas multicast receivers belonging to the same VLAN 10 are placed in remote sites B to site N and need to receive traffic for that same group.
Similarly to what is done for the OTV control plane, you need to distinguish the two scenarios where the transport infrastructure is multicast enabled, or not, for the data plane.
For multicast-enabled transport, the Layer 2 multicast traffic must flow across the OTV overlay, and to avoid suboptimal head-end replication, a specific mechanism is required to ensure that multicast capabilities of the transport infrastructure can be leveraged.
The idea is to use a set of source-specific multicast (SSM) groups in the transport to carry these Layer 2 multicast streams. These groups are independent from the ASM group previously introduced to transport the OTV control protocol between sites.
For a unicast-only transporter, when multicast capabilities are not available in the transport infrastructure, Layer 2 multicast traffic can be sent across the OTV overlay by leveraging head-end replication from the OTV device deployed in the DC site where the multicast source is located. However, a specific mechanism based on IGMP snooping is still available to ensure Layer 2 multicast packets are sent only to remote DC sites where active receivers interested in that flow are connected.
Broadcast Traffic over OTV
It is important to highlight that a mechanism is required so that Layer 2 broadcast traffic can be delivered between sites across the OTV overlay. Failure isolation will detail how to limit the amount of broadcast traffic across the transport infrastructure, but some protocols, like Address Resolution Protocol (ARP), would always mandate the delivery of broadcast packets.
In the current OTV software release, when a multicast-enabled transport infrastructure is available, the current NX-OS software release broadcast frames are sent to all remote OTV edge devices by leveraging the same ASM multicast group in the transport already used for the OTV control protocol. Layer 2 broadcast traffic will then be handled exactly the same way as the OTV Hello messages shown in Figure 3-2.
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 that are part of the unicast-only list.
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, ARP optimization, and broadcast policy control.
STP Isolation
OTV, by default, does not transmit STP bridge protocol data units (BPDUs) across the overlay, as shown in Figure 3-4. This native function does not require the use of an explicit configuration, such as BPDU filtering, and so on. Every site can then become an independent STP domain; STP root configuration, parameters, and the STP protocol flavor can be decided on a per-site basis.
)
Figure 3-4 STP Isolation
STP isolation fundamentally limits the fate of sharing between data center sites: an STP problem in the control plane of a given site would not produce any effect on the remote data centers.
Limiting the extension of STP across the transport infrastructure potentially creates undetected end-to-end loops that would occur when at least two OTV edge devices are deployed in each site, inviting a common best practice to increase resiliency of the overall solution. Multihoming details how OTV prevents the creation of end-to-end loops without sending STP frames across the OTV overlay.
Unknown Unicast Handling
The OTV control protocol will advertise MAC address reachability information between the OTV edge devices and mapping MAC address destinations to IP next hops. The consequence is that the OTV edge device starts behaving like a router instead of a Layer 2 bridge, because it forwards Layer 2 traffic across the overlay if it has previously received information on how to reach that remote MAC destination. Figure 3-5 shows this behavior.
)
Figure 3-5 Unknown Unicast Traffic
When the OTV edge device receives a frame destined to PC3, it performs the usual Layer 2 lookup in the MAC table. Because it does not have information for the MAC of PC3, Layer 2 traffic is flooded out the internal interfaces, since they behave as regular Ethernet interfaces, but not via the overlay.
The assumption is that there are no silent or unidirectional devices in the network, so sooner or later the local OTV edge device will learn an address and communicate it to the remaining edge devices through the OTV protocol. To support specific applications, like Microsoft Network Load Balancing Services (NLBS), which require the flooding of Layer 2 traffic to functions, a configuration knob is provided to enable selective flooding. Individual MAC addresses can be statically defined so that Layer 2 traffic destined to them can be flooded across the overlay, or it can be broadcast to all remote OTV edge devices instead of being dropped. The expectation is that this configuration would be required in very specific corner cases so that the default behavior of dropping unknown unicast would be the usual operation model.
ARP Optimization
Another function that reduces the amount of traffic sent across the transport infrastructure is ARP optimization. ARP optimization will reduce the amount of broadcast traffic between sites.
IP ARP is a Layer 2 broadcast frame used to determine the MAC address of the host with a particular IP address. ARP requests are sent across the OTV overlay to all remote sites, with the hope that they will reach the host with that particular IP. The intended host will respond to the originating host’s ARP request using an ARP reply, which will pass via the original OTV edge device that forwarded the ARP request. That OTV edge device will record the ARP reply. OTV edge devices are capable of snooping ARP reply traffic and caching the contained mapping information in a local data table called ARP ND (Neighbor-Discovery). Any subsequent ARP broadcast requests that have a match in the ARP ND will be served from there and will not be sent across the overlay. Figure 3-6 shows an ARP optimization example.
)
Figure 3-6 OTV ARP Optimization
One caveat to be aware of is the relationship between the MAC aging timer and the ARP cache timer. The ARP cache timer should always be lower than the MAC aging timer; otherwise, traffic might be black-holed, which means incoming or outgoing traffic is silently discarded or dropped. Using the default NX-OS values, and provided the default gateway resides on a Nexus, this should never be an issue with the default set values.
The Nexus defaults for these timers are
OTV ARP aging timer: 480 seconds / 8 minutes
MAC aging timer: 1800 seconds / 30 minutes
Broadcast Policy Control
In addition to the previously described ARP optimization, OTV will provide additional functionality, such as broadcast suppression, broadcast white listing, and so on, to reduce the amount of overall Layer 2 broadcast traffic sent across the overlay. Details will be provided upon future functional availability.
Multihoming OTV
One important function is multihoming where two (or more) OTV edge devices provide LAN extension services to a given site. As mentioned, this redundant node deployment, combined with the fact that STP BPDUs are not sent across the OTV overlay, may lead to the creation of an end-to-end loop, as shown in Figure 3-7.
)
Figure 3-7 Creation of an End-to-End STP Loop
The concept of an Authoritative edge device (AED) is introduced to avoid the situation depicted in Figure 3-8. The AED has two main tasks:
)
Figure 3-8 Establishment of Internal Peering
Forwarding Layer 2 traffic (unicast, multicast, and broadcast) between the site and the overlay (and vice versa)
Advertising MAC reachability information to the remote edge devices
The AED role is negotiated, on a per-VLAN basis, between all the OTV edge devices belonging to the same site (that is, characterized by the same site identifier, or site ID). OTV uses the site adjacencies as input to determine Authoritative edge devices for the VLANS being extended from the site.
The site VLAN should be carried on multiple Layer 2 paths internal to a given site, to increase the resiliency of this internal adjacency (including vPC connections eventually established with other edge switches). However, the mechanism of electing an Authoritative edge device solely based on the communication established on the site VLAN may create situations (resulting from connectivity issues or misconfiguration) where OTV edge devices belonging to the same site can fail to detect one another and thereby end up in an “active/active” mode (for the same data VLAN). This could ultimately result in the creation of a loop scenario.
To address this concern, each OTV device maintains dual adjacencies with other OTV edge devices belonging to the same DC site. OTV edge devices continue to use the site VLAN for discovering and establishing adjacency with other OTV edge devices in a site. This adjacency is called site adjacency.
In addition to the site adjacency, OTV devices also maintain a second adjacency, called overlay adjacency, established via the join interfaces across the Layer 3 network domain. To enable this new functionality, it is now mandatory to configure each OTV device with a site-identifier value. All edge devices that are in the same site must be configured with the same site identifier. This site identifier is advertised in IS-IS hello packets sent over both the overlay as well as on the site VLAN. The combination of the site identifier and the IS-IS system ID is used to identify a neighbor edge device in the same site.
The dual-site adjacency state (and not simply the site adjacency established on the site VLAN) is now used to determine the Authoritative edge device role for each extended data VLAN. All the OTV edge devices can now proactively inform their neighbors in a local site about their capability to become Authoritative edge devices and their forwarding readiness. In other words, if something happens on an OTV device that prevents it from performing its LAN extension functionalities, it can now inform its neighbor about this and let itself be excluded from the AED election process.
An explicit AED capability notification allows the neighbor edge devices to get a fast and reliable indication of failures and to determine AED status accordingly in the consequent AED election, rather than solely depending on the adjacency creation and teardown. The forwarding readiness may change due to local failures, such as the site VLAN or the extended VLANs going down or the join interface going down, or it may be intentional, such as when the edge device is starting up and/or initializing. Hence, the OTV adjacencies may be up, but the OTV device may not be ready to forward traffic. The edge device also triggers a local AED election when its forwarding readiness changes. As a result of its AED capability going down, it will no longer be AED for its VLANs.
The AED capability change received from a neighboring edge device in the same site influences the AED assignment and hence will trigger an AED election. If a neighbor indicates that it is not AED capable, it will not be considered as active in the site. An explicit AED capability down notification received over either the site or the overlay adjacency will bring the neighbor’s dual-site adjacency state down into an inactive state, and the resulting AED election will not assign any VLANs to that neighbor.
The dual-site adjacencies are used to negotiate the Authoritative edge device role. A deterministic algorithm is implemented to split the AED role for odd and even VLANs between two OTV edge devices, as shown in Figure 3-9. More specifically, the edge device identified by a lower system ID will become authoritative for all the even extended VLANs, whereas the device with a higher system ID will “own” the odd extended VLANs.
)
Figure 3-9 OTV AED VLAN Split
FHRP Isolation
One of the important capabilities introduced by OTV is to filter First Hop Redundancy Protocol (FHRP—HSRP, VRRP, and so on) messages across the logical overlay. This is required to allow for the existence of the same default gateway in different locations and optimize the outbound traffic flows (server-to-client direction). Figure 3-10 highlights the root of the problem.
)
Figure 3-10 Suboptimal Outbound Routing
Given that the same VLAN/IP subnet is available in different sites, the free exchange of FHRP messages across the OTV connection would lead to the election of a single default gateway. This would force traffic to follow a suboptimal path to reach the default gateway (in the site where it is deployed) each time it is required to be routed outside the subnet and the server is located in a different site.
Figure 3-11 shows the deployment of independent default gateways in each data center site, to optimize and localize routing of outbound traffic flows.
)
Figure 3-11 FHRP Isolation with OTV
It is critical that you enable the filtering of FHRP messages across the overlay because it allows the use of the same FHRP configuration in different sites. The end result is that the same default gateway is available and characterized by the same virtual IP and virtual MAC addresses in each data center. This means that the outbound traffic will be able to follow the optimal and shortest path, always leveraging the local default gateway.
It is important to stress how this outbound path optimization functionality should be deployed in conjunction with an equivalent one optimizing inbound traffic flows to avoid asymmetric traffic behavior (this would be highly undesirable, especially in deployments leveraging stateful services across data centers).
OTV Configurations and Verifications
Table 3-2 lists OTV default parameters. You can alter these parameters as necessary to optimize protocol functionality.
Table 3-2 OTV Default Settings
Parameters |
Default |
OTV feature |
Disabled |
Advertised VLANs |
None |
ARP and ND suppression |
Enabled |
Graceful restart |
Enabled |
Site VLAN |
1 |
Site identifier |
0x0 |
IS-IS overlay hello interval |
20 seconds (Cisco NX-OS Release 6.2 or later) 4 seconds (Cisco NX-OS Release 5.2 through Cisco NX-OS Release 6.1) |
IS-IS overlay hello multiplier |
3 |
IS-IS site hello interval |
3 seconds (Cisco NX-OS Release 6.2 or later) 1 second (Cisco NX-OS releases prior to 6.2) |
IS-IS site hello multiplier |
20 (Cisco NX-OS Release 6.2 or later) 10 (Cisco NX-OS releases prior to 6.2) |
IS-IS CSNP interval |
10 seconds |
IS-IS LSP interval |
33 milliseconds |
Overlay route tracking |
Disabled |
Site BFD |
Disabled |
Table 3-3 covers the NX-OS feature license required for OTV. For more information, visit the Cisco NX-OS Licensing Guide.
Table 3-3 Feature-Based Licenses for Cisco NX-OS OTV
Platform |
Feature License |
Feature Name |
Cisco Nexus 7000 Series |
Transport Services Package LAN_TRANSPORT_SERVICES_PKG |
Overlay Transport Virtualization (OTV) |
OTV has the following configuration recommendations 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 (Nexus 7000 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 Nexus 7000 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.
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.
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.
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.
Tables 3-4 through 3-7 show some of the most-used OTV configuration commands with their purpose. For full commands, refer to the Nexus Interface Configuration Guide links provided in the “References” section at the end of the chapter.
Table 3-4 OTV Global-Level Commands
Command |
Purpose |
Feature otv |
Enables OTV for the device. |
interface overlay interface |
Creates an OTV overlay interface and enters interface configuration mode. |
otv-isis default |
Enters OTV router configuration mode. |
Table 3-5 OTV Interface-Level Commands
Command |
Purpose |
description [dstring] |
(Optional) Configures a description for the overlay network. The dstring is any case-sensitive, alphanumeric string up to 80 characters. |
otv join-interface interface |
Joins the OTV overlay interface with a physical Layer 3 interface. You must configure an IP address on the physical interface. You can specify only one join interface per overlay. You can decide to use one of the following methods:
|
otv extend-vlan vlan-range |
Extends a range of VLANs over this overlay interface and enables OTV advertisements for these VLANs. The vlan-range is from 1 to 3967 and from 4048 to 4093. |
otv extend-vlan {add | remove } vlan-range |
Displays the VLAN information for the overlay network. |
otv site-vlan vlan-id |
Configures a VLAN that all local edge devices communicate on. You must configure this VLAN ID to match on all local edge devices. We recommend that you use the same VLAN ID across all sites. The range is from 1 to 3967, and from 4048 to 4093. The default is 1. |
otv site-identifier id |
Configures the site identifier. You should configure this same site identifier on all local OTV edge devices. The site identifier should be unique across different sites. The range is from 0x1 to 0xffffffff. The default is 0x0. The format is either hexadecimal or MAC address format. |
otv adjacency-server unicast-only |
(Optional) Configures the local edge device to act as an adjacency server. NOTE: If the two overlay interface numbers do not match between the two OTV sites configured to use unicast adjacency servers, the OTV adjacencies will not form, and OTV will not come up until the overlay interface numbers are changed to match. |
otv use-adjacency-server primary-ip-address [secondary-ip-address] unicast-only |
(Optional) Configures the local edge device to use a remote adjacency server. The IP address format is in dotted-decimal notation. The secondary-ip-address argument is the IP address of the backup adjacency server if you have configured a backup adjacency server. |
otv control-group mcast-address |
Configures the multicast group address used by the OTV control plane for this OTV overlay network. The multicast group address is an IPv4 address in dotted decimal notation. |
otv data-group mcast-range1 [mcast-range2...] |
Configures one or more ranges of local IPv4 multicast group prefixes used for multicast data traffic. Use SSM multicast groups 232.0.0.0/8. The multicast group address is an IPv4 address in dotted-decimal notation. A subnet mask is used to indicate ranges of addresses. You can define up to eight data-group ranges. |
otv site-vlan vlan-id |
Configures a VLAN that all local edge devices communicate on. You must configure this VLAN ID on all local edge devices. The range is from 1 to 3967 and from 4048 to 4093. The default is 1. |
Table 3-6 OTV Router-Level Commands
Command |
Purpose |
otv isis csnp-interval seconds |
(Optional) Specifies the interval between CSNP PDUs on an interface. The seconds range is from 1 to 65,535. The default is 10 seconds. |
otv isis hello-interval seconds |
(Optional) Specifies the interval between hello PDUs on an interface. The seconds range is from 1 to 65,535. The default is 10 seconds. |
otv isis hello-multiplier multiplier |
(Optional) Specifies the multiplier that is used to calculate the interval within which hello PDUs must be received to keep the OTV adjacency up. The multiplier range is from 3 to 1000. The default is 3. |
otv isis metric metric |
(Optional) Configures the OTV metric on an interface. The metric range is from 1 to 16,777,215. |
otv isis priority dis-priority |
(Optional) Configures the OTV priority for DIS election on the interface. The priority range is from 1 to 127. The default is 64. |
Table 3-7 OTV Global-Level Verification Commands
Command |
Purpose |
show running-configuration otv [all ] |
Displays the running configuration for OTV. |
show otv overlay [interface] |
Displays information about overlay interfaces. |
show otv adjacency [detail] |
Displays information about the adjacencies on the overlay network. |
show otv [overlay interface] [vlan [vlan-range] [authoritative | detail ]] |
Displays information about VLANs that are associated with an overlay interface. |
show otv isis site [database | statistics ] |
Displays the BFD configuration state on both local and neighboring edge devices. |
show otv site [all] |
Displays information about the local site. |
show otv [route [interface [neighbor-address ip-address]] [vlan vlan-range] [mac-address]] |
Displays information about the OTV routes. |
show otv mroute vlan vlan-id startup |
Displays the OTV multicast route information for a specific VLAN from the OTV Routing Information Base (ORIB). |
show forwarding distribution otv multicast route vlan vlan-id |
Displays Forwarding Information Base (FIB) OTV multicast route information for a specific VLAN. |
show otv vlan-mapping [overlay interface-number] |
Displays VLAN translation mappings from a local site to a remote site. |
show mac address-table |
Displays information about MAC addresses. |
Figure 3-12 shows the OTV network topology with configurations.
)
Figure 3-12 OTV Network Topology and Configurations
Example 3-1 shows switch one at the West site (SW9621-W1) with OTV information, neighbor adjacency, IS-IS underlay protocol, and multicast routing.
Example 3-1 SW9621-W1 OTV Results
SW9621-W1# show otv
OTV Overlay Information
Site Identifier 0000.0000.0001
Encapsulation-Format ip - gre
Overlay interface Overlay1
VPN name : Overlay1
VPN state : UP
Extended vlans : 20 30 40 (Total:3)
Control group : 239.5.5.5
Data group range(s) : 232.5.5.0/32
Broadcast group : 239.5.5.5
Join interface(s) : Eth2/1 (10.10.10.1)
Site vlan : 10 (up)
AED-Capable : yes
Capability : Multicast-Reachable
SW9621-W1# show otv adjacency
Overlay Adjacency database
Overlay-Interface Overlay1 :
Hostname System-ID Dest Addr Up Time State
SW9621-E2 fa16.3e31.f889 10.10.10.12 00:41:40 UP
SW9621-E1 fa16.3ec3.1f96 10.10.10.11 00:45:20 UP
SW9621-W2 fa16.3ed2.730a 10.10.10.2 00:55:39 UP
SW9621-S1 fa16.3ef4.5189 10.10.10.21 01:00:58 UP
SW9621-W1# show otv isis
ISIS process : default
Encap-Type for Multicast mode: GRE
VPN: Overlay1
fwd ready state FALSE
System ID : fa16.3e56.e725 IS-Type : L1
Version Number: 3
Interoperability Flag: 0
SAP : 439 Queue Handle : 15
Maximum LSP MTU: 1392
Graceful Restart enabled. State: Inactive
Last graceful restart status : none
Metric-style : advertise(wide), accept(narrow, wide)
Area address(es) :
00
Process is up and running
VPN ID: 132
Incremental update routes during SPF run
Stale routes during non-graceful controlled restart
Interfaces supported by OTV-IS-IS :
Overlay1
Level 1
Authentication type and keychain haven't been configured
Authentication check is specified
Address family IPv4 unicast :
Number of interface : 1
Adjacency check disabled
Distance : 115
tib-id : 0
Address family IPv6 unicast :
Number of interface : 1
Adjacency check disabled
Distance : 115
tib-id : 0
Address family MAC unicast :
Number of interface : 1
Adjacency check disabled
Distance : 115
tib-id : 0
L1 Next SPF: Inactive
AED Server Info:
Capability: 1
Priority: 0
AED Server Elected Value: fa16.3e56.e725
AED State: 0
AED Elected Operational: 4
Backup AED Server Info:
Backup AED Server Elected Value: fa16.3ed2.730a
Backup AED State: 0
Backup AED Elected Operational: 3
SW9621-W1# show ip mroute
IP Multicast Routing Table for VRF "default"
(*, 239.5.5.5/32), uptime: 01:28:26, otv ip
Incoming interface: Ethernet2/1, RPF nbr: 10.10.10.1
Outgoing interface list: (count: 1)
Overlay1, uptime: 01:28:26, otv
Example 3-2 shows switch two at at West site (SW9621-W2) with OTV information.
Example 3-2 SW9621-W2 OTV Results
SW9621-W2# show otv OTV Overlay Information Site Identifier 0000.0000.0001 Encapsulation-Format ip - gre Overlay interface Overlay1 VPN name : Overlay1 VPN state : UP Extended vlans : 20 30 40 (Total:3) Control group : 239.5.5.5 Data group range(s) : 232.5.5.0/32 Broadcast group : 239.5.5.5 Join interface(s) : Eth2/1 (10.10.10.2) Site vlan : 10 (up) AED-Capable : yes Capability : Multicast-Reachable
Example 3-3 shows switch one at the East site (SW9621-E1) with OTV information. Be sure to pay attention to the AED status, which is shown as down, because there is no VLAN active at SW9621-E1.
Example 3-3 SW9621-E1 OTV Results
SW9621-E1# show otv OTV Overlay Information Site Identifier 0000.0000.0002 Encapsulation-Format ip - gre Overlay interface Overlay1 VPN name : Overlay1 VPN state : UP Extended vlans : 20 30 (Total:2) Control group : 239.5.5.5 Data group range(s) : 232.5.5.0/32 Broadcast group : 239.5.5.5 Join interface(s) : Eth2/1 (10.10.10.11) Site vlan : 10 (up) AED-Capable : No (No extended vlan operationally up) <- no active VLAN Capability : Multicast-Reachable
Example 3-4 shows switch two at the East site (SW9621-E2) with OTV information.
Example 3-4 SW9621-E2 OTV Results
SW9621-E2# show otv OTV Overlay Information Site Identifier 0000.0000.0002 Encapsulation-Format ip - gre Overlay interface Overlay1 VPN name : Overlay1 VPN state : UP Extended vlans : 20 30 (Total:2) Control group : 239.5.5.5 Data group range(s) : 232.5.5.0/32 Broadcast group : 239.5.5.5 Join interface(s) : Eth2/3 (10.10.10.12) Site vlan : 10 (up) AED-Capable : Yes Capability : Multicast-Reachable
Example 3-5 shows switch one at the South site (SW9621-S1) with OTV information. Again, be sure to pay attention to the VLAN site and the AED; both are shown as down, because there is a single OTV node at the South site.
Example 3-5 SW9621-S1 OTV Results
SW9621-S1# show otv OTV Overlay Information Site Identifier 0000.0000.0003 Encapsulation-Format ip - gre Overlay interface Overlay1 VPN name : Overlay1 VPN state : UP Extended vlans : 20 40 (Total:2) Control group : 239.5.5.5 Data group range(s) : 232.5.5.0/32 Broadcast group : 239.5.5.5 Join interface(s) : Eth2/1 (10.10.10.21) Site vlan : 10 (down) AED-Capable : No (Site-VLAN is Down) Capability : Multicast-Reachable
Example 3-6 shows connectivity results across the OTV network.
Example 3-6 Connectivity Verifications from Devices Behind the Switches
VLAN30-W1# ping 30.0.0.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 30.0.0.2, timeout is 2 seconds: ..!!! Success rate is 60 percent (3/5), round-trip min/avg/max = 1/20/40 ms VLAN30-W2# Router# ping 30.0.0.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 30.0.0.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms VLAN40-W1# Router# ping 40.0.0.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 40.0.0.2, timeout is 2 seconds: ..!!! Success rate is 60 percent (3/5), round-trip min/avg/max = 3/20/40 ms VLAN40-W2# Router# ping 40.0.0.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 40.0.0.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/3 ms