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.
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.
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