OTV problem between my 2 sites

[Mika J]

Hello,

I'm trying to use OTV to extend my vlan 101

C3850West Gi1/1/2 <-> Gi0/0/1 ASRWest Gi0/0/0.900 <-> ISP <-> Gi0/0/0.900 ASREast Gi0/0/1 <-> Gi2/0/24 C3850East

On both C3850 I created an interface vlan101

West

----

interface Vlan101
ip address 10.216.101.2 255.255.255.0
!

interface GigabitEthernet1/1/2
description ASRWest_Gi0/0/1_OTV
switchport trunk native vlan 999
switchport trunk allowed vlan 101
switchport mode trunk

!

East

----

interface Vlan101
ip address 10.216.101.1 255.255.255.0

interface GigabitEthernet2/0/24
description NET-RTSUR002_Gi0/0/1
switchport trunk native vlan 999
switchport trunk allowed vlan 101
switchport mode trunk

They are connected to ASR routers

West

----

interface GigabitEthernet0/0/1
description C3850West_Gi1/1/2_OTV_Internal
no ip address
carrier-delay msec 0
negotiation auto
cdp enable

service instance 101 ethernet
description ---- OTV ----
encapsulation dot1q 101
mac access-group otv_filter_fhrp in
bridge-domain 101
storm-control broadcast cir 1000000

!

interface GigabitEthernet0/0/0.900
description To_ISP
encapsulation dot1Q 900
vrf forwarding ISP
ip address 10.216.2.1 255.255.255.248
ip pim passive
ip igmp version 3

!

otv site bridge-domain 101
!
otv fragmentation join-interface GigabitEthernet0/0/0.900
otv site-identifier 0000.0000.0002
otv isis Site
log-adjacency-changes

!

interface Overlay1
no ip address
otv join-interface GigabitEthernet0/0/0.900
otv vpn-name OTV-1
no otv suppress arp-nd
otv use-adjacency-server 10.213.2.1 unicast-only
otv adjacency-server unicast-only
service instance 101 ethernet
encapsulation dot1q 101
bridge-domain 101
!

East

----

interface GigabitEthernet0/0/1
description C3850East_Gi2/1/24_OTV_Internal
no ip address
carrier-delay msec 0
negotiation auto
cdp enable
service instance 101 ethernet
description ---- OTV ----
encapsulation dot1q 101
mac access-group otv_filter_fhrp in
bridge-domain 101
storm-control broadcast cir 1000000
!

interface GigabitEthernet0/0/0.900
description To_ISP
encapsulation dot1Q 900
vrf forwarding ISP
ip address 10.213.2.1 255.255.255.248
ip pim passive
ip igmp version 3

!

otv site bridge-domain 101
!
otv fragmentation join-interface GigabitEthernet0/0/0.900
otv site-identifier 0000.0000.0001
otv isis Site
log-adjacency-changes
!

interface Overlay1
no ip address
otv join-interface GigabitEthernet0/0/0.900
otv vpn-name OTV-1
no otv suppress arp-nd
otv adjacency-server unicast-only
service instance 101 ethernet
encapsulation dot1q 101
bridge-domain 101
!

==============================

Now, the adjacency seems ok

#show otv adjacency
Overlay Adjacency Database for overlay 1
Hostname System-ID Dest Addr Site-ID Up Time State
ASREast 7070.8b39.9b00 10.213.2.1 0000.0000.0001 00:34:37 UP

MAC address from C3850East is learnt

ASREast#show otv route vlan 101

OTV Unicast MAC Routing Table for Overlay1

Inst VLAN BD MAC Address AD Owner Next Hops(s)
----------------------------------------------------------
0 101 101 50f7.227c.d441 40 BD Eng Gi0/0/1:SI101

ASRWest#show otv route vlan 101

OTV Unicast MAC Routing Table for Overlay1

Inst VLAN BD MAC Address AD Owner Next Hops(s)
----------------------------------------------------------
0 101 101 50f7.227c.d441 50 ISIS ASREast

C3850West# show ip arp vlan 101
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.216.101.2 - 50f7.2297.56c1 ARPA Vlan101
Internet 10.216.101.1 26 50f7.227c.d441 ARPA Vlan101

PROBLEM

Mac address from C3850West is not learnt on ASRWest, ASREast and C3850East. I have no idea why.

So my OTV seems all ok except one side is not learning and sending the Mac on the OTV tunnel.

Does anyone has an idea ?

[Georg Pauwen · Accepted solution]

Hello,

the first thing that looks 'suspicious' is obviously the MAC access-list. What does the access list allow, and what happens if you remove it ?

Also, try and enable ARP caching on both overlay edge devices by configuring:

-->  otv suppress arp-nd

[Mika J]

Hello,

Thank you very much for your quick answer.

I reenabled "no otv suppress arp-nd" after my tests.

The action that solved the problem was "no mac access-group otv_filter_fhrp in"

So as you said the problem was the access-group which I didn't suspect

mac access-list extended otv_filter_fhrp
 deny   0000.0c07.ac00 0000.0000.00ff host 0000.0000.0000
 deny   0000.0c9f.f000 0000.0000.0fff host 0000.0000.0000
 deny   0007.b400.0000 0000.0000.00ff host 0000.0000.0000
 deny   0000.5e00.0100 0000.0000.00ff host 0000.0000.0000
 permit host 0000.0000.0000 host 0000.0000.0000

Thank you