Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

Troubleshooting OTV Adjacency

OTV adjacency is formed across the layer 3 multicast clouds by exchanging L1 ISIS Hello packets.

Sample Topology

OTV Topology.JPG

1. Verify IGMP V3 Join

After the OTV configuration completed, enabling the join interface sends any source IGMP v3 join on that interface.

interface Ethernet1/31

  description [OTV-JOIN-INTERFACE]

  vrf member OTV

  ip address 10.10.15.6/30

  ip router eigrp 10

  ip igmp version 3

SITE1-OED1(config-if)# int eth 1/31

SITE1-OED1(config-if)# no shut

SITE1-AGG1%OTV# show ip mroute

IP Multicast Routing Table for VRF "OTV"

(*, 239.1.1.1/32), uptime: 0.283775, igmp pim

  Incoming interface: Ethernet1/5, RPF nbr: 10.10.15.1 <<Interface facing Multicast RP

  Outgoing interface list: (count: 1)

    Ethernet1/9, uptime: 0.283711, igmp <<< Interface connecting to OTV VDC SITE1-OED1

2. Verify ISIS Hello Packets

When you enable the OTV overlay interface, the switch will generate a L1 ISIS hello packet with the source IP address as the OTV join interface and the destination IP address as the OTV control-group.

SITE1-AGG1%OTV# show ip mroute

IP Multicast Routing Table for VRF "OTV"

(*, 239.1.1.1/32), uptime: 00:16:00, igmp pim ip

  Incoming interface: Ethernet1/5, RPF nbr: 10.10.15.1

  Outgoing interface list: (count: 1)

    Ethernet1/9, uptime: 00:16:00, igmp

(10.10.15.6/32, 239.1.1.1/32), uptime: 00:00:19, ip mrib pim

<<< S,G entry represents Multicast packet received from 10.10.15.6

  Incoming interface: Ethernet1/9, RPF nbr: 10.10.15.6

  Outgoing interface list: (count: 1)

    Ethernet1/9, uptime: 00:00:19, mrib, (RPF)

3. Verify Multicast Transport

After all the four OTV edge devices are configured and enabled, the multicast transport network should show all the sources

SITE1-AGG1%OTV# show ip mroute

IP Multicast Routing Table for VRF "OTV"

(*, 239.1.1.1/32), uptime: 00:23:13, igmp pim ip

  Incoming interface: Ethernet1/5, RPF nbr: 10.10.15.1

  Outgoing interface list: (count: 1)

    Ethernet1/9, uptime: 00:23:13, igmp

(10.10.15.6/32, 239.1.1.1/32), uptime: 00:07:33, ip mrib pim <<< SITE1-OED1

  Incoming interface: Ethernet1/9, RPF nbr: 10.10.15.6

  Outgoing interface list: (count: 2)

    Ethernet1/5, uptime: 00:05:44, pim

    Ethernet1/9, uptime: 00:07:33, mrib, (RPF)

(10.10.16.6/32, 239.1.1.1/32), uptime: 00:04:48, ip mrib pim <<< SITE1-OED2

  Incoming interface: Ethernet1/5, RPF nbr: 10.10.15.1

  Outgoing interface list: (count: 1)

    Ethernet1/9, uptime: 00:04:48, mrib

(10.10.17.6/32, 239.1.1.1/32), uptime: 00:04:21, ip mrib pim <<< SITE2-OED1

  Incoming interface: Ethernet1/5, RPF nbr: 10.10.15.1

  Outgoing interface list: (count: 1)

    Ethernet1/9, uptime: 00:04:21, mrib

(10.10.18.6/32, 239.1.1.1/32), uptime: 00:03:46, ip mrib pim <<< SITE2-OED2

  Incoming interface: Ethernet1/5, RPF nbr: 10.10.15.1

  Outgoing interface list: (count: 1)

    Ethernet1/9, uptime: 00:03:46, mrib

You can also monitor the OTV control packets statistics as below.

SITE1-AGG1%OTV# show ip mroute summary

IP Multicast Routing Table for VRF "OTV"

Total number of routes: 6

Total number of (*,G) routes: 1

Total number of (S,G) routes: 4

Total number of (*,G-prefix) routes: 1

Group count: 1, rough average sources per group: 4.0

Group: 239.1.1.1/32, Source count: 4

Source          packets      bytes           aps   pps       bit-rate     oifs

(*,G)           7            10106           1443  0         0.000   bps  1

10.10.15.6      73           86674           1187  0         1349.600 bps 2

10.10.16.6      96           76987           801   0         1429.600 bps 1

10.10.17.6      103          81610           792   0         1416.267 bps 1

10.10.18.6      155          144435         931   0         4092.800 bps 1

4. Verify OTV ISIS Adjacency

You can verify the Adjacency using the below command:

SITE1-OED1# show otv adjacency detail

Overlay Adjacency database

Overlay-Interface Overlay1  :

Hostname                         System-ID      Dest Addr       Up Time   State

SITE1-OED2                       0024.986f.bac4 10.10.16.6      00:05:31  UP

HW-St: Up Peer-ID: 3

SITE2-OED1                       0026.51ce.0f43 10.10.17.6      00:46:29  UP

HW-St: Up Peer-ID: 2

SITE2-OED2                       0026.51ce.0f44 10.10.18.6      00:46:29  UP

HW-St: Up Peer-ID: 1

5. Troubleshoot OTV ISIS Adjacency

If there is any issue in establishing OTV ISIS adjacency, you can look at the ISIS adjacency log as below:

SITE1-OED1#  show otv isis internal event-history adjacency

ISIS default process

adjacency Events for ISIS process

2011 May 21 08:54:53.773678 isis_otv default [10371]: (Overlay1) : LAN adj L1

SITE2-OED1 over Overlay1 - UP

2011 May 21 08:54:53.773662 isis_otv default [10371]: [10376]: Sent OTV add adja

cency for overlay:Overlay1, addr: 10.10.17.6

2011 May 21 08:54:53.653906 isis_otv default [10371]: (Overlay1) : Set adjacency

SITE2-OED1 over Overlay1 IPv4 address to 10.10.17.6

2011 May 21 08:54:53.653827 isis_otv default [10371]: (Overlay1) : LAN adj L1

SITE2-OED1 over Overlay1 - INIT (New)

2011 May 21 08:54:53.653799 isis_otv default [10371]: [10376]: Initialize adj fo

r L1 MT-0 for iib Overlay1

You can clear the log as below:

SITE1-OED1# clear otv isis event-history

6. Verify OTV overlay interface

Verify Overlay interface is up.

SITE1-OED1# show otv

OTV Overlay Information

Overlay interface Overlay1

VPN name            : Overlay1

VPN state           : UP

Extended vlans      : 100-200 (Total:101)

Control group       : 239.1.1.1

Data group range(s) : 232.1.1.0/26

Join interface(s)   : Eth1/31 (10.10.15.6)

Site vlan           : 95 (up)                <<< Site VLAN should be Up

Site VLAN should be in spanning tree forwarding on at least one port in the OTV VDC. If not, the data will not be forwarded across the OTV even though the OTV overlay is up and adjacency is forwarded with other peers.

7. Verify Tunnel Creation

After the OTV adjacency is setup, OTV process creates implicit tunnels for each discovered peer. These tunnels will be used to forward the data across OTV to the respective site.

show otv internal event-history debug

2011 May 21 10:10:58.428388 otv [10358]: [10361]: otv_tunnel_gre_add Tunnel (10.

10.15.6, 10.10.17.6) does not exist, creating NEW

2011 May 21 10:10:58.426206 otv [10358]: [10361]: Received ISIS add adjacency me

ssage for (Overlay1, 10.10.17.6) , sid 0026.51ce.0f43

Tunnel process in the NX-OS creates these tunnels based on the request from OTV process. You can verify the implicit tunnels as below:

SITE1-OED1# show tunnel internal implicit otv brief

-------------------------------------------------------------------------------

Interface                Status     IP Address        Encap type       MTU

-------------------------------------------------------------------------------

Tunnel16424              up         --                GRE/IP           9178

Tunnel16425              up         --                GRE/IP           9178

SITE1-OED1# show tunnel internal implicit otv detail

Tunnel16424 is up

    MTU 9178 bytes, BW 9 Kbit

    Transport protocol is in VRF "OTV"

    Tunnel protocol/transport GRE/IP

    Tunnel source 10.10.15.6, destination 10.10.18.6

    Last clearing of "show interface" counters never

    Tx

    0 packets output, 1 minute output rate 0 packets/sec

    Rx

    0 packets input, 1 minute input rate 0 packets/sec

Tunnel16425 is up

    MTU 9178 bytes, BW 9 Kbit

    Transport protocol is in VRF "OTV"

    Tunnel protocol/transport GRE/IP

    Tunnel source 10.10.15.6, destination 10.10.17.6

    Last clearing of "show interface" counters never

    Tx

    0 packets output, 1 minute output rate 0 packets/sec

    Rx

    0 packets input, 1 minute input rate 0 packets/sec

The below command will shows the mapping between OTV adjacency and implicit tunnel.

SITE1-OED1# show otv internal adjacency

Overlay Adjacency database

Overlay-Interface Overlay1  :

System-ID        Dest Addr        Adj-State TM_State  Up Time   Adj-State inAS

0024.986f.bac4   10.10.16.6       default   default   00:05:59  UP        UP

HW-St: Up  Curr-Peer-St: Up,  New-Peer_St: Default Peer-ID: 3 N Tunnel16426

0026.51ce.0f43   10.10.17.6       default   default   00:46:57  UP        UP

HW-St: Up  Curr-Peer-St: Up,  New-Peer_St: Default Peer-ID: 2 N Tunnel16425

0026.51ce.0f44   10.10.18.6       default   default   00:46:58  UP        UP

HW-St: Up  Curr-Peer-St: Up,  New-Peer_St: Default Peer-ID: 1 N Tunnel16424

SITE1-OED1#

Version history
Revision #:
1 of 1
Last update:
‎05-22-2011 12:51 AM
 
Labels (1)
Comments
New Member

very thanks for the tips!

New Member

Thanks for the info however this does not help me to troubleshoot an issue i am seeing. :-)

For instance i have 4 nexus 7000 each having an agg VDC and a OTV VDC when all is good each OTV VDC sees 3 adjacencies. However after trying a failover (shutting down a nexus 7000) when that 7000 comes back up 1 out of 3 tries it only gets 2 adjacencies this happens random across all 4 7000s when I shut one down. It's only after i shut/ no shut the overlay interface do i get all 3 adjacencies. The multicast RPs are 2 of the nexus 7000s using msdp. It is extremely frustrating because if the wrong adjacency doesn't come up its a black hole for traffic 100% failure of OTV traffic for the vlans handled by that AED. I plan on calling a tac case in tomorrow I will let you know of the outcome.

New Member

Hi Daniel,

i had the same issue during the implemantation of OTV inside the DC. Do you have contacted the TAC ? Have you got some news about? Is it a BUG ?

Thanks

New Member

Hi Daniel,

i  had the same issue during the implemantation of OTV inside the DC. Do  you have contacted the TAC ? Have you got some news about? Is it a BUG ?

Thanks

New Member

Has this issue been resolved? If so, what was the solution?