DMVPN Phase 3 OSPF Routing

Hello Laz,

I wish I had EVE-NG or VIRL to test it out as I too think its some sort of shortcoming within GNS3. Thanks for trying to help me.

1 Like

HI,
I’ve replicated the same topology (ospf broadcast)lab on GNS3.

I’ve received this output from R2-Spoke after the first ping/trace to the other spoke,

R2-Spoke#traceroute 3.3.3.3
Type escape sequence to abort.
Tracing the route to 3.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
  1 172.16.123.1 7 msec 10 msec 5 msec
  2 172.16.123.3 8 msec
*Apr  8 08:34:23.885: %NHRP-3-PAKREPLY: Receive Resolution Reply packet with error - insufficient resources(5) *  4 msec
R2-Spoke#

Direct ping between spokes work correctly anyway, but how can I investigate what kind of resources are referred to the syslog error message?

R2-Spoke#show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
        N - NATed, L - Local, X - No Socket
        T1 - Route Installed, T2 - Nexthop-override
        C - CTS Capable
        # Ent --> Number of NHRP entries with same NBMA peer
        NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
        UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface: Tunnel0, IPv4 NHRP Details 
Type:Spoke, NHRP Peers:2, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 192.168.123.1      172.16.123.1    UP 15:28:08     S
     1 192.168.123.3      172.16.123.3    UP 00:11:30   DT1

R2-Spoke#
R2-Spoke#traceroute 3.3.3.3
Type escape sequence to abort.
Tracing the route to 3.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
  1 172.16.123.3 7 msec *  6 msec
R2-Spoke#
R2-Spoke#

Thanks

Hello Giovanni

It looks like you found a Cisco IOS bug. This is described in the following Cisco Community post here:

The above link includes a workaround to resolve the issue. The links to the bug reports in the post are no longer valid, but you can find one of them here:

https://quickview.cloudapps.cisco.com/quickview/bug/CSCsu28997

As you have also found out, this doesn’t affect the communication between the spokes.

I hope this has been helpful!

Laz