BGP - eBGP next hop optimization
Consider the following DMVPN Phase 1 topology where BGP is being used to advertise routes, and the hub and spoke routers are each in a different AS.
Remember that Phase 1 does not allow spoke to spoke communication. Therefore, when Spoke 1 advertises the 2.2.2.2/32 network, the Hub will receive that advertisement. The Hub, in turn, will advertise that network to Spoke 2. Spoke 2 will receive that and install it in its routing table.
Now we know that an eBGP router will always use its own IP address as the next hop address when advertising a route. Therefore, we expect that Spoke 2 will have the Hub as the next hop for the 2.2.2.2/32 network. Take a look at the routing table of Spoke 2:
Spoke2#show ip route bgp 1.0.0.0/32 is subnetted, 1 subnets B 1.1.1.1 [20/0] via 172.16.123.1, 00:38:34 2.0.0.0/32 is subnetted, 1 subnets B 2.2.2.2 [20/0] via 172.16.123.2, 00:38:34
We see a next hop of 172.16.123.2 which is Spoke 1. Why?
Because eBGP will not change the next hop to itself 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 that ensures that the shortest path is used, and no unnecessary intermediate ASes are added to the AS_PATH. Because the next hop of Spoke 1 is on the same subnet as the next hop of the Hub, the Hub chooses to advertise the next hop address as that of Spoke 1 rather than its own, when advertising Spoke 1’s routes to Spoke 2.
This optimization is called third party next hop and is described in BGP's RFC 4271.
https://forum.networklessons.com/t/dmvpn-phase-1-bgp-routing/1305/59?u=lagapides
https://networklessons.com/cisco/ccie-routing-switching/dmvpn-phase-1-bgp-routing