Hello again Nipun
OK, so here’s what I got from Rene as well.
eBGP next hop is not changed if the BGP next hop in the BGP table belongs to the same IP subnet as the eBGP neighbor to which the update is sent.
This is a type of next hop optimization, and it makes sense, because it ensures that the shortest path is used, and no unnecessary intermediate ASes are added to the AS_PATH. This is also what happens in the DMVPN Phase 1 BGP topology we are looking at. Because the next hop of Spoke2 is on the same subnet as the next hop of the Hub, the Hub chooses to advertise the next hop address as that of Spoke2 rather than its own, when advertising Spoke2’s routes to Spoke1. Specificlly, this is called a third party next hop.
Now in DMVPN Phase 1, spoke to spoke communication is not possible, so the next hop of Spoke2 should be unreachable from Spoke1 right? Well, that’s where NHRP comes in, and makes the spokes believe they can communicate directly with each other, but using the next hop resolution mechanism of NHRP, the actual traffic indeed travels via the hub.
This is further described in section 5.1.3 of RFC 4271.
I hope this has been helpful!
Laz