This topic is to discuss the following lesson:
Hub router already store NBMA of Spoke 2 when it was establish tunnel interface, but why when Spoke 1 send request NBMA address of spoke 2 to hub then hub need to forward it to spoke 2? why don’t it reply back directly to spoke 1?
You are correct that the Hub router does know the NBMA of spoke 2, however, when an NBMA request is sent, it must always be answered by the owner of the specific address. In this example, Spoke 1 doesn’t have the 172.16.123.3 address in its NHRP cache. It sends out an NHRP resolution request. The resolution request is not sent to the Hub as its destination, but is sent to the hub as the the path to the destination , that is, via Tunnel 0.
The NHRP resolution must always be answered by the owner of the IP address in question. In this case, it must be answered by the device with the NBMA address of 184.108.40.206, which is Spoke 2. This is why the request is forwarded to Spoke 2 and Spoke 2 is expected to answer.
I hope this has been helpful!
I got this now, It mean Spoke 1 send use Hub as it path to send NHRP resolution request to spoke 2.
Thank you so much .
I shut down HUB after spoke already establish dynamic connection between them. and all spoke and HUB are running RIP to advertise their loopback. since i shut down the HUB and clear IP route on spoke i found that RIP is never recover. it lost all route to loopback of another spoke.
There is something I did not understand, general speaking, when we use RIP, do not the interfaces sending the routes to another device, announce themself are the next hop? (same way as with EIGRP) .
For DMVPN Phase 2 output
Spoke2#show ip route rip 220.127.116.11/32 is subnetted, 1 subnets R 18.104.22.168 [120/1] via 172.16.123.1, 00:00:01, Tunnel0 22.214.171.124/32 is subnetted, 1 subnets R 126.96.36.199 [120/2] via 172.16.123.2, 00:00:01, Tunnel0
Is showing 172.16.123.2 as the next hop indeed for 188.8.131.52 but metric is still 2, so does not that mean the traffic is still going through the hub??
This is an excellent observation. I went into the lab and found that the metric is indeed 2. Doing an initial traceroute from Spoke2 to Spoke1, I found that the hub was the first hop, and Spoke1 was the second hop. When I ran traceroute again, I found that Spoke1 was the first (and only) hop.
This is expected behaviour because with DMVPN phase 2, Spoke2 will check its NHRP cache, and sees that it doesn’t know the NBMA address for Spoke1. It will initially send the packet to the hub along with an NHRP resolution request. But after the first packet goes, Spoke2 will put the NBMA address for Spoke1 in its cache.
The second traceroute works directly, but RIP still measures the metric between spokes at 2, even though the traceroute confirms a single hop. This is the case even after RIP routes are refreshed. Without having found any documentation to confirm this, my feeling is that RIP views the fact that an NHRP lookup has to be requested from the hub as an additional hop even though the actual packets (other than the original one) don’t go through the hub.
I hope this has been helpful!
Hello Laz, thank you so much for the explanation!!