ASR 1000 OTV Unicast Adjacency Server

Configuration Example
Document ID: 117158
Contributed by Denny McLaughlin, Cisco TAC Engineer.
Apr 25, 2014

Contents
Introduction
Prerequisites
Requirements
Components Used
Configure
Network Diagram with Basic L2/L3 Connectivity
Basic L2/L3 Connectivity
OTV Unicast Adjacency Server Minimum Configuration
Verifiy
Network Diagram with OTV
Verification Commands and Expected Output
Common Problem
Troubleshoot
Packet Capture Creation on the Join Interface in Order to See OTV Hellos
Related Information

Introduction
This document describes how to configure the Overlay Transport Virtualization (OTV) Unicast Adjacency
Server on the Cisco Aggregation Services Router (ASR) 1000 platform. Since traditional OTV requires
multicast across the Internet Service Provider (ISP) cloud, the Unicast Adjacency Server allows you to
leverage the OTV feature without the requirement of muticast support and configuration.

OTV extends the Layer 2 (L2) topology across the physically different sites, which allows devices to
communicate at L2 across a Layer 3 (L3) provider. Devices in Site 1 believe they are on the same broadcast
domain as those in Site 2.

Prerequisites
Requirements
Cisco recommends that you have knowledge of these topics:

• Ethernet Virtual Connection (EVC) configuration

 • Basic L2 and L3 configuration on the ASR platform

Components Used
The information in this document is based on the ASR 1002 with Cisco IOS® Version
asr1000rp1−adventerprise.03.09.00.S.153−2.S.bin.

Your system must have these requirements in order to implement the OTV feature on the ASR 1000 and
Cisco Cloud Services Router (CSR) 1000V Platform:

• Cisco IOS−XE Version 3.9S or later

• Maximum Transmission Unit (MTU) of 1542 or higher

Note: OTV adds a 42−byte header with the Do Not Fragment (DF)−bit to all encapsulated packets. In
order to transport 1500−byte packets through the overlay, the transit network must support MTU of
1542 or higher. OTV does not support fragmentation. In order to allow for fragmentation accross
OTV, you must enable otv fragmentation join−interface <interface>.
• Unicast reachability between sites

The information in this document was created from the devices in a specific lab environment. All of the
devices used in this document started with a cleared (default) configuration. If your network is live, make sure
that you understand the potential impact of any command.

Configure
Network Diagram with Basic L2/L3 Connectivity

Basic L2/L3 Connectivity

Start with a base configuration. The internal interface on the ASR is configured for service instances for dot1q
traffic. The OTV join interface is the external WAN Layer 3 interface.
ASR−1
interface GigabitEthernet0/0/0
description OTV−WAN−Connection
mtu 9216
ip address 172.17.100.134 255.255.255.0
negotiation auto
cdp enable

ASR−2
interface GigabitEthernet0/0/0
description OTV−WAN−Connection
mtu 9216
ip address 172.16.64.84 255.255.255.0
negotiation auto
cdp enable

Since OTV adds a 42−byte header, you must verify that the ISP passes the minimum MTU size from
site−to−site. In order to accomplish this verification, send a packet size of 1514 with the DF−bit set. This
gives the ISP the payload required plus the do not fragment tag on the packet in order to simulate an OTV
packet. If you cannot ping without the DF−bit, then you have a routing problem. If you can ping without it,
but cannot ping with the DF−bit set, you have an MTU problem. Once successful, you are ready to add OTV
unicast mode to your site ASRs.

ASR−1#ping 172.17.100.134 size 1514 df−bit

Type escape sequence to abort.
Sending 5, 1514−byte ICMP Echos to 172.17.100.134, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round−trip min/avg/max = 1/1/2 ms

The internal interface is a L2 port configured with service instances for the L2 dot1q tagged packets. It builds
an internal site bridge domain. In this example, it is the untagged VLAN1. The internal site bridge domain is
used for the communication of multiple OTV devices at the same site. This allows them to communicate and
determine which device is the Authoritative Edge Device (AED) for which bridge domain.

The service instance must be configured into a bridge domain that uses the overlay.

ASR−1
interface GigabitEthernet0/0/1
no ip address
negotiation auto
cdp enable
service instance 1 ethernet
encapsulation untagged
bridge−domain 1
!
service instance 50 ethernet
encapsulation dot1q 100
bridge−domain 200
!
service instance 51 ethernet
encapsulation dot1q 101
bridge−domain 201

ASR−2
interface GigabitEthernet0/0/2
no ip address
negotiation auto
cdp enable
service instance 1 ethernet
encapsulation untagged
bridge−domain 1
 !
service instance 50 ethernet
encapsulation dot1q 100
bridge−domain 200
!
service instance 51 ethernet
encapsulation dot1q 101
bridge−domain 201

OTV Unicast Adjacency Server Minimum Configuration

This is a basic configuration that requires only a few commands in order to set up the adjacency server and
join / internal interfaces.

Configure the local site bridge domain, which is VLAN1 on the LAN in this example. The site identifier is
specific to each physical location.This example has two remote locations that are physically independent of
each other. Configure Site 1 and Site 2 accordingly.

ASR−1

Config t
otv site bridge−domain 1
otv site−identifier 0000.0000.0001

ASR−2

Config t
otv site bridge−domain 1
otv site−identifier 0000.0000.0002

Build the overlay for each side. Configure the overlay, apply the join interface, and add the adjacency server
configuration to each side. This example has ASR−1 as the adjacency server and ASR−2 as the client.

Note: Ensure that you only apply the otv adjacency−server unicast−only command on the ASR that is the
server. Do not apply it to the client side.

Add the two bridge domains that you want to extend. Notice that you do not extend the site bridge domain,
only the two VLANs that are needed. Build a separate service instance for the overlay interfaces to call bridge
domain 200 and 201. Apply the dot1q tags 100 and 101 respectively.

ASR−1

Config t
interface Overlay1
no ip address
otv join−interface GigabitEthernet0/0/0
otv use−adjacency−server 172.17.100.134 unicast−only
otv adjacency−server unicast−only
service instance 10 ethernet
encapsulation dot1q 100
bridge−domain 200
service instance 11 ethernet
encapsulation dot1q 101
bridge−domain 201

ASR−2

Config t
interface Overlay1
 no ip address
otv join−interface GigabitEthernet0/0/0
otv use−adjacency−server 172.17.100.134 unicast−only
service instance 10 ethernet
encapsulation dot1q 100
bridge−domain 200
service instance 11 ethernet
encapsulation dot1q 101
bridge−domain 201

Note: Do NOT extend the site VLAN on the overlay interface. This causes the two ASRs to have a conflict
because they believe that each remote side is in the same site.

At this stage, ASR−to−ASR OTV unicast−only adjacency is complete and up. The neighbors are found, and
the ASR should be AED−capable for the VLANs that needed to be extended

ASR−1#show otv
Overlay Interface Overlay1
VPN name : None
VPN ID : 1
State : UP
AED Capable : Yes
Join interface(s) : GigabitEthernet0/0/0
Join IPv4 address : 172.17.100.134
Tunnel interface(s) : Tunnel0
Encapsulation format : GRE/IPv4
Site Bridge−Domain : 1
Capability : Unicast−only
Is Adjacency Server : Yes
Adj Server Configured : Yes
Prim/Sec Adj Svr(s) :172.17.100.134
ASR−1#show otv isis neigh

Tag Overlay1:
System Id Type Interface IP Address State Holdtime Circuit Id
ASR−2 L1 Ov1 172.16.64.84 UP 25 ASR−1.01

ASR−2#show otv
Overlay Interface Overlay1
VPN name : None
VPN ID : 1
State : UP
AED Capable : Yes
Join interface(s) : GigabitEthernet0/0/0
Join IPv4 address : 172.16.64.84
Tunnel interface(s) : Tunnel0
Encapsulation format : GRE/IPv4
Site Bridge−Domain : 1
Capability : Unicast−only
Is Adjacency Server : No
Adj Server Configured : Yes
Prim/Sec Adj Svr(s) : 172.17.100.134
ASR−2#show otv isis neigh

Tag Overlay1:
System Id Type Interface IP Address State Holdtime Circuit Id
ASR−1 L1 Ov1 172.17.100.134 UP 8 ASR−1.01

Verifiy
Use this section in order to confirm that your configuration works properly.
Network Diagram with OTV

Verification Commands and Expected Output

This output shows that VLANs 100 and 101 are extended. The ASR is the AED, and the internal interface and
service instance that maps the VLANs are seen in the output.

ASR−1#show otv vlan

Key: SI − Service Instance

Overlay 1 VLAN Configuration Information

Inst VLAN Bridge−Domain Auth Site Interface(s)
0 100 200 yes Gi0/0/1:SI50
0 101 201 yes Gi0/0/1:SI51
Total VLAN(s): 2
Total Authoritative VLAN(s): 2

ASR−2#show otv vlan

Key: SI − Service Instance

Overlay 1 VLAN Configuration Information

Inst VLAN Bridge−Domain Auth Site Interface(s)
0 100 200 yes Gi0/0/2:SI50
0 101 201 yes Gi0/0/2:SI51
Total VLAN(s): 2
Total Authoritative VLAN(s): 2

In order to validate that the VLANs are extended, perform a site−to−site ping. Host 192.168.100.2 is located
at Site 1, and Host 192.168.100.3 is located at Site 2. The first few pings are expected to fail as you build ARP
locally and across OTV to the other side.

LAN−SW1#ping 192.168.100.3
Type escape sequence to abort.
Sending 5, 100−byte ICMP Echos to 192.168.100.3, timeout is 2 seconds:
...!!
Success rate is 40 percent (2/5), round−trip min/avg/max = 1/5/10 ms
LAN−SW1#ping 192.168.100.3
Type escape sequence to abort.
Sending 5, 100−byte ICMP Echos to 192.168.100.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round−trip min/avg/max = 1/4/10 ms

LAN−SW1#ping 192.168.100.3 size 1500 df−bit

Type escape sequence to abort.
Sending 5, 1500−byte ICMP Echos to 192.168.100.3, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round−trip min/avg/max = 1/4/10 ms

In order to ensure that the MAC table and OTV routing tables are built properly with the local device and that
you learn the MAC address of the remote device, use the show otv route command.

LAN−SW1#show int vlan 100

Vlan100 is up, line protocol is up
Hardware is Ethernet SVI, address is 0c27.24cf.abd1 (bia 0c27.24cf.abd1)
Internet address is 192.168.100.2/24

LAN−SW2#show int vlan 100

Vlan100 is up, line protocol is up
Hardware is Ethernet SVI, address is b4e9.b0d3.6a51 (bia b4e9.b0d3.6a51)
Internet address is 192.168.100.3/24

ASR−1#show otv route vlan 100

Codes: BD − Bridge−Domain, AD − Admin−Distance,

SI − Service Instance, * − Backup Route

OTV Unicast MAC Routing Table for Overlay1

Inst VLAN BD MAC Address AD Owner Next Hops(s)

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
0 100 200 0c27.24cf.abaf 40 BD Eng Gi0/0/1:SI50
0 100 200 0c27.24cf.abd1 40 BD Eng Gi0/0/1:SI50 <−−− Local mac is
pointing to the physical interface
0 100 200 b4e9.b0d3.6a04 50 ISIS ASR−2
0 100 200 b4e9.b0d3.6a51 50 ISIS ASR−2 <−−− Remote
mac is pointing across OTV to ASR−2

4 unicast routes displayed in Overlay1

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
4 Total Unicast Routes Displayed

ASR−2#show otv route vlan 100

Codes: BD − Bridge−Domain, AD − Admin−Distance,

SI − Service Instance, * − Backup Route

OTV Unicast MAC Routing Table for Overlay1

Inst VLAN BD MAC Address AD Owner Next Hops(s)

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
0 100 200 0c27.24cf.abaf 50 ISIS ASR−1
0 100 200 0c27.24cf.abd1 50 ISIS ASR−1 <−−− Remote
mac is pointing across OTV to ASR−1
 0 100 200 b4e9.b0d3.6a04 40 BD Eng Gi0/0/2:SI50
0 100 200 b4e9.b0d3.6a51 40 BD Eng Gi0/0/2:SI50 <−−− Local mac is
pointing to the physical interface

4 unicast routes displayed in Overlay1

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
4 Total Unicast Routes Displayed

Common Problem
The When OTV Does Not Form error message in the output indicates that the ASR is not AED−capable. This
means that the ASR does not forward the VLANs across OTV. There are several possible causes for this, but
the most common is that the ASRs do not have connectivity between sites. Check for L3 connectivity and
possible blocked traffic to UDP Port 8472, which is reserved for OTV. Another possible cause of this
condition is when the internal site bridge domain is not configured. This creates a condition where the ASR
cannot become the AED, because it is not certain if it is the only ASR on the site.

ASR−1#show otv
Overlay Interface Overlay1
VPN name : None
VPN ID : 1
State : UP
AED Capable : No, overlay DIS not elected <−−− Local OTV site cannot
see the remote neighbor
Join interface(s) : GigabitEthernet0/0/0
Join IPv4 address : 172.17.100.134
Tunnel interface(s) : Tunnel0
Encapsulation format : GRE/IPv4
Site Bridge−Domain : 1
Capability : Unicast−only
Is Adjacency Server : Yes
Adj Server Configured : Yes
Prim/Sec Adj Svr(s) : 172.17.100.134

ASR−2#show otv
Overlay Interface Overlay1
VPN name : None
VPN ID : 1
State : UP
AED Capable : No, overlay DIS not elected <−−− Local OTV site cannot
see the remote neighbor
Join interface(s) : GigabitEthernet0/0/0
Join IPv4 address :172.16.64.84
Tunnel interface(s) : Tunnel0
Encapsulation format : GRE/IPv4
Site Bridge−Domain : 1
Capability : Unicast−only
Is Adjacency Server : No
Adj Server Configured : Yes
Prim/Sec Adj Svr(s) : 172.17.100.134

Troubleshoot
This section provides information you can use in order to troubleshoot your configuration.

Packet Capture Creation on the Join Interface in Order to See OTV Hellos
You can use the onboard packet capture device on the ASR in order to help troubleshoot possible problems.
In order to create an Access Control List (ACL) to minimize impact and oversaturated captures, enter:

ip access−list extended CAPTURE

permit udp host 172.17.100.134 host 172.16.64.84 eq 8472
permit udp host 172.16.64.84 host 172.17.100.134 eq 8472

In order to set up the capture to sniff the join interface in both directions on both ASRs, enter:

monitor capture 1 buffer circular access−list CAPTURE interface g0/0/0 both

In order to start the capture, enter:

monitor capture 1 start

*Nov 14 15:21:37.746: %BUFCAP−6−ENABLE: Capture Point 1 enabled.

<wait a few min>

monitor capture 1 stop

*Nov 14 15:22:03.213: %BUFCAP−6−DISABLE: Capture Point 1 disabled.

show mon cap 1 buffer brief

The buffer output shows that the hellos in the capture egress and ingress from the neighbor and locally. When
enabled on both ASRs and captured bidirectionally, you see the same packets leave on one side and enter the
other in the capture.

The first two packets in ASR−1 were not caught in ASR−2, so you must offset the capture by three seconds in
order to compensate for the time and the two extra packets that lead the ASR−1 output.

ASR−1#show mon cap 1 buff bri

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
# size timestamp source destination protocol
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
0 1464 0.000000 172.17.100.134 −> 172.16.64.84 UDP * not in
ASR−2 cap
1 150 0.284034 172.17.100.134 −> 172.16.64.84 UDP * not in
ASR−2 cap
2 1464 3.123047 172.17.100.134 −> 172.16.64.84 UDP
3 1464 6.000992 172.17.100.134 −> 172.16.64.84 UDP
4 110 6.140044 172.17.100.134 −> 172.16.64.84 UDP
5 1464 6.507029 172.16.64.84 −> 172.17.100.134 UDP
6 1464 8.595022 172.17.100.134 −> 172.16.64.84 UDP
7 150 9.946994 172.17.100.134 −> 172.16.64.84 UDP
8 1464 11.472027 172.17.100.134 −> 172.16.64.84 UDP
9 110 14.600012 172.17.100.134 −> 172.16.64.84 UDP
10 1464 14.679018 172.17.100.134 −> 172.16.64.84 UDP
11 1464 15.696015 172.16.64.84 −> 172.17.100.134 UDP
12 1464 17.795009 172.17.100.134 −> 172.16.64.84 UDP
13 150 18.903997 172.17.100.134 −> 172.16.64.84 UDP
14 1464 21.017989 172.17.100.134 −> 172.16.64.84 UDP
15 110 23.151045 172.17.100.134 −> 172.16.64.84 UDP
16 1464 24.296026 172.17.100.134 −> 172.16.64.84 UDP
17 1464 25.355029 172.16.64.84 −> 172.17.100.134 UDP
18 1464 27.053998 172.17.100.134 −> 172.16.64.84 UDP
19 150 27.632023 172.17.100.134 −> 172.16.64.84 UDP
20 1464 30.064999 172.17.100.134 −> 172.16.64.84 UDP
21 110 32.358035 172.17.100.134 −> 172.16.64.84 UDP
22 1464 32.737013 172.17.100.134 −> 172.16.64.84 UDP
23 1464 32.866004 172.16.64.84 −> 172.17.100.134 UDP
24 1464 35.338032 172.17.100.134 −> 172.16.64.84 UDP
25 150 35.709015 172.17.100.134 −> 172.16.64.84 UDP
 26 1464 38.054990 172.17.100.134 −> 172.16.64.84 UDP
27 110 40.121048 172.17.100.134 −> 172.16.64.84 UDP
28 1464 41.194042 172.17.100.134 −> 172.16.64.84 UDP
29 1464 42.196041 172.16.64.84 −> 172.17.100.134 UDP

ASR−2#show mon cap 1 buff bri

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
# size timestamp source destination protocol
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
0 1464 0.000000 172.17.100.134 −> 172.16.64.84 UDP
1 1464 2.878952 172.17.100.134 −> 172.16.64.84 UDP
2 110 3.018004 172.17.100.134 −> 172.16.64.84 UDP
3 1464 3.383982 172.16.64.84 −> 172.17.100.134 UDP
4 1464 5.471975 172.17.100.134 −> 172.16.64.84 UDP
5 150 6.824954 172.17.100.134 −> 172.16.64.84 UDP
6 1464 8.349988 172.17.100.134 −> 172.16.64.84 UDP
7 110 11.476980 172.17.100.134 −> 172.16.64.84 UDP
8 1464 11.555971 172.17.100.134 −> 172.16.64.84 UDP
9 1464 12.572968 172.16.64.84 −> 172.17.100.134 UDP
10 1464 14.672969 172.17.100.134 −> 172.16.64.84 UDP
11 150 15.780965 172.17.100.134 −> 172.16.64.84 UDP
12 1464 17.895965 172.17.100.134 −> 172.16.64.84 UDP
13 110 20.027998 172.17.100.134 −> 172.16.64.84 UDP
14 1464 21.174002 172.17.100.134 −> 172.16.64.84 UDP
15 1464 22.231998 172.16.64.84 −> 172.17.100.134 UDP
16 1464 23.930951 172.17.100.134 −> 172.16.64.84 UDP
17 150 24.508976 172.17.100.134 −> 172.16.64.84 UDP
18 1464 26.942959 172.17.100.134 −> 172.16.64.84 UDP
19 110 29.235995 172.17.100.134 −> 172.16.64.84 UDP
20 1464 29.614973 172.17.100.134 −> 172.16.64.84 UDP
21 1464 29.743964 172.16.64.84 −> 172.17.100.134 UDP
22 1464 32.215992 172.17.100.134 −> 172.16.64.84 UDP
23 150 32.585968 172.17.100.134 −> 172.16.64.84 UDP
24 1464 34.931958 172.17.100.134 −> 172.16.64.84 UDP
25 110 36.999008 172.17.100.134 −> 172.16.64.84 UDP
26 1464 38.072002 172.17.100.134 −> 172.16.64.84 UDP
27 1464 39.072994 172.16.64.84 −> 172.17.100.134 UDP

Related Information
• ASR OTV Configuration Guide
• Technical Support & Documentation − Cisco Systems

Updated: Apr 25, 2014 Document ID: 117158