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
Hello, everyone!
I am a little confused about the structure and contents of the NHRP Resolution message. Here’s one as its sent from one of the spokes to the hub after receiving the redirect.
Could someone please tell me, what exactly the Destination Protocol Address is supposed to represent? In Phase 2, we’d see here the tunnel IP address of the destination spoke the local spoke needs the NBMA of.
However, in Phase 3, the IP address in this field will be of the destination network that we want to reach? (Note: I’ve issued a ping from this local spoke to 192.168.100.1).
And then in the Resolution Reply, the destination spoke replies with a bunch of information, including the prefix length of that network?
So could someone explain to me, what exactly is the Destination Protocol Address field supposed to represent here?
It just feels a little confusing. I can also see that the NHRP Mandatory Part is kept unchanged during the resolution process?
I hope someone can provide some clearance on this. Thank you!
David
Hello David
According to RFC 2332 which defines NHRP, the Destination Protocol Address (DPA) is:
…the protocol address of the station toward which a “request” packet is sent.
In other words, if you send a ping to 192.168.100.1 (the destination of the ICMP echo request) this is the address that appears in the field of the DPA. It is not the next hop address of the spoke, nor is it the tunneled address, but the destination of the actual transaction, whatever that may be. This is the case regardless of what phase DMVPN you use.
Concerning the prefix length, the same RFC says the following:
This field is message specific. See the relevant message sections below. In general, however, this fields is used to indicate that the information carried in an NHRP message pertains to an equivalence class of internetwork layer addresses rather than just a single internetwork layer address specified. All internetwork layer addresses that match the first "Prefix Length" bit positions for the specific internetwork layer address are included in the equivalence class. If this field is set to 0x00 then this field MUST be ignored and no equivalence information is assumed (note that 0x00 is thus equivalent to 0xFF).
This essentially means that the NHRP message pertains not only to the specific DPA, but also to the subnet to which that DPA belongs. The size of the subnet is indicated by the prefix length.
I hope this has been helpful!
Laz