In my previous post here, I discussed the concepts of OTV, so if you are not familiar with OTV concepts perhaps go read that post first. In this post I intend to dive a little deeper into OTV configuration and verification.
The assumption is that IP connectivity is in place, within the Data Centre and between Data Centres.
One of the first configuration steps is to define the OTV site VLAN and OTV site identifier.
As mentioned, the local OTV edge devices need to communicate as part of the AED election process. The requirement for this AED election is that the devices participating are connected via a local VLAN. Note: This site VLAN must NOT be stretched over the OTV link but rather trunked between the OTV edge devices. Thus on each of the OTV edge devices a VLAN needs to be configured such as:
otv site-vlan 999
This can be the same in each site, but must not be extended over the Overlay interface. This enables the OTV edge devices to discover each other and determine their roles on a per VLAN basis as the nominated OTV edge device which later in this post you will see that even VLANs are active on one OTV edge whilst odd VLANs are active on the other OTV edge, shown via the ‘show otv vlan’ command.
OTV uses the site identifier to identify the OTV edge devices which exists in a specific site (where a site is a single geographic data centre) which can form an adjacency with another site. Thus in a site with dual AED’s, the site identifier needs to match, however should be unique per site. Thus in one site the identifier may be 0x001 on both OTV edge devices, whilst in the other site it may be 0x002. Thus the following example shows a site identifier:
otv site-identifier 0x001
At a high level the overlay interface configuration would look like the following where port-channel1 is defined as the join interface, which as per the previous post is the L3 physical link or port-channel which is used to route upstream towards the DCI / Core. Whilst the Overlay interface is the logical OTV tunnel interface which performs the encapsulation and where the OTV configuration is done.
interface Overlay1
description Overlay Network
otv join-interface port-channel1
otv extend-vlan 100, 205
otv use-adjacency-server 172.16.50.1 unicast-only
no shutdown
The Join interface is the L3 interface on the OTV edge device connecting to the DCI or Core (IP transport network). This interface is used as the source of OTV encapsulation and assigned to the logical ‘Overlay’ interface.
interface port-channel1
description OTV/GRE uplink to Core / DCI
mtu 9216
ip address 172.16.50.1/30
The Internal interface is a L2 interface, typically configured as a trunk or access port, which takes part in STP and learns MAC addresses per normal. This is typically the interface that connects the device performing L3 gateway / SVI functionality to the OTV edge device.
interface port-channel10
description To L3 Router VDC
switchport
switchport mode trunk
switchport trunk allowed vlan 100,205
spanning-tree port type normal
mtu 9216
vpc 10
As mentioned, the local OTV edge devices need to communicate as part of the AED election process and is a local VLAN to these devices and NOT stretched over the OTV link but rather trunked between the OTV edge devices. This enables the OTV edge devices to discover each other and determine their roles on a per VLAN basis as the AED.
Once the configuration is in place all of the OTV edge devices need to form an adjacency. This allows the OTV edge devices to learn and distribute the list of neighbors which it can replicate the control packets to. Thus every OTV edge device which joins the OTV domain needs to join by registering with the Adjacency Server whilst the other OTV edge devices are discovered dynamically through the Adjacency Server and thus all are aware of each other and can update when OTV devices join or leave.
To check the OTV Adjacency use the command “show otv adjacency”
Hostname System-ID Dest Addr Up Time State
otv-site1-2 4055.3905.64c1 172.16.50.2 2w1d UP
otv-site2-2 4055.3905.b6c1 172.16.50.50 2w1d UP
otv-site2-1 4055.3905.c641 172.15.50.46 2w1d UP
Also the command “show otv overlay 1″ also provides good information including the Adjacency Server details.
#show otv overlay 1
OTV Overlay Information
Site Identifier 0000.0000.0100
Overlay interface Overlay1
VPN name : Overlay1
VPN state : UP
Extended vlans : 100 205 (Total:2)
Join interface(s) : Po1 (172.16.50.1)
Site vlan : 999 (up)
AED-Capable : Yes
Capability : Unicast-Only
Is Adjacency Server : Yes
Adjacency Server(s) : 172.16.50.1
To confirm which VLANs have been stretched over the Overlay interface and identify which OTV edge device they is their active AED, the command “show otv vlan” can be used.
#show otv vlan
OTV Extended VLANs and Edge Device State Information (* - AED)
Legend:
(NA) - Non AED, (VD) - Vlan Disabled, (OD) - Overlay Down
(DH) - Delete Holddown, (HW) - HW: State Down
(NFC) - Not Forward Capable
VLAN Auth. Edge Device Vlan State Overlay
---- ----------------------------------- ---------------------- -------
100* otv-site-1 active Overlay1
205 otv-site-2 inactive(NA) Overlay1
As can be seen above, on this OTV edge device, VLAN 100 is the active AED, meaning this device is responsible for encapsulating the VLAN traffic and sending it to the other site. VLAN 205 is also stretched across the OTV but this devices neighbor is the active AED for that odd VLAN.
The command “show otv route” can be utilised to see where a specific MAC address is learnt from. In the following example the MAC address for the host in VLAN100 is learnt over the OTV link, whilst the MAC address for the host in VLAN205 is learnt from the downstream gateway device local to this site.
#show otv route
OTV Unicast MAC Routing Table For Overlay1
VLAN MAC-Address Metric Uptime Owner Next-hop(s)
---- -------------- ------ -------- --------- -----------
100 0050.568d.16d7 42 1w5d overlay otv-site-1
205 0050.568d.5b2d 1 1w5d site port-channel10
On the gateway router where the SVI’s exist it is always a good idea to check that the MAC address is being learnt locally and that the HSRP/VRRP status is what you expect to see. In this example no FHRP (HSRP/VRRP) filtering is done thus the traffic to/from the end hosts is always routed via the same gateway in the same site. There is issue with this approach as it can cause traffic to trombone across the OTV link adding latency and providing a less than optimal path, but that is a post for another time.
#show hsrp brief
*:IPv6 group #:group belongs to a bundle
P indicates configured to preempt.
|
Interface Grp Prio P State Active addr Standby addr Group addr
Vlan100 1 120 P Active local 172.24.24.2 172.24.24.1 (conf)
And also to check that whichever is the primary gateway device can see the appropriate MAC addresses being learnt:
#show ip arp vrf VPN-GW-1 | incl Vlan100
172.24.24.10 00:07:22 0050.568d.16d7 Vlan100
172.24.24.11 00:00:26 0050.568d.43db Vlan100
Note; whilst the MTU in this example has been set to 9216 as this is supported by the IP transport which OTV runs over the gateway SVI’s should be set lower to allow for the OTV overhead added by the OTV edge devices.
Just for completeness the configuration of the SVI gateway for VLAN100 is as follows:
interface Vlan100
description : Gateway_Test_OTV-SPAN
no shutdown
mtu 9000
vrf member VPN-GW-1
ip address 172.24.24.0/24
ip unreachables
hsrp version 2
hsrp 1
preempt
priority 120
ip 172.24.24.1