NHRP-5-NO_ROUTE: Not installing NHO

[paul amaral]

Hi, recently i was running IOS c1900-universalk9-mz.SPA.155-3.M5 and was getting the following in the logs, this was after enabling phase 3 DMVPN on 20 routers and two hubs. Redirect on hubs and nhrp cache on nodes.

Dec 19 10:23:56.599 EST: %NHRP-3-CACHE_FAILURE: Failed to cache Resolution Reply packet - insufficient resources(5)

I couldnt find anything on this and not sure how to resolve this so i moved to another IOS version. I  moved to the god star image, 157-3.M3 and now im getting, 

Dec 19 10:01:27 EST: %NHRP-5-NO_ROUTE: Not installing NHO for 10.213.104.0/24 due to the presence of
an authoritatively learnt nexthop 10.2.2.18 on Tunnel0

I'm assuming this means that other non authoritative nodes are sending route hints for the network above but the route is already installed and pointing to the router that is authoritative for that subnet ? It seems that this is more of a cosmetic bug than anything else but im not sure. I have searched and found nothing in regards to this issue. 

Anyone know what i can do to fix this issue? can it be fixed or should i just use a log discriminator to remove it from the logs. Its so annoying to see this over and over on the logs.  

thank you, Paul

[Georg Pauwen]

Hello Paul,

I found the bug below, not sure if this applies to your setup. Known fixed releases are:

Everest-16.4.1
Denali-16.3.2
16.4.1
16.4(0.49)
16.3.2
16.1(2.210)
15.7(2.0e)M
15.6(2.18)S2.7
15.6(2)SP3
15.6(2)S3
15.6(1.30)SP2
15.6(1)S4.2
15.6(1)S4
15.6(1)S3.29
15.5(3)S3.8
15.5(3)M4
15.5(3)M3.1

DMVPN: NHRP route-watch does not delete NHO route after route change
CSCuy32325
Description
Symptom:
-When configuring DMVPN Phase 3, if a NHO route is installed in the RIB, it should be removed via NHRP route-watch if the parent route is learned out an interface other than the tunnel where the NHO destination is reachable
-Currently, this behavior does not occur properly
-If an NHO is installed and the route changes, route-watch detects the route change, the new route is installed out the second, non-tunnel interface, but the NHO is retained in the RIB

Conditions:
-DMVPN Phase 3 configuration
-Build spoke to spoke tunnels using NHO rather than H routes
-Learn the same prefix out a different interface, such as a physical interface or different tunnel interface

Workaround:
-Summarize spoke networks on Hub so H routes are utilized rather than NHO
-Manually clear NHO ("clear ip nhrp shortcut") when the routes change