This topic is to discuss the following lesson:
Nice article, Rene!
I am sure you are gonna create another article about ““dirty” tricks like AS override, allow AS in or remove private AS.” since CCIE is all about details and details and more details.
I did, you can take a look here:
Am I correct in noting that for iBGP Route-Reflector in a DMVPN env the next hop attribute changes to the spokes but in a normal non dmvpn route reflector env the next hop attribute DOES NOT change.
In both environments, the iBGP route-reflector should not change the next hop attribute, and the reason in both cases is the same. By having the RR change the next hop, the RR would necessarily be putting itself in the data plane. In most cases, it is preferable to have the RR act only in the control plane so the most efficient path can be taken.
The tricky part about BGP in a DMVPN environment is accounting for knowledge of the next hops by all BGP clients. As you know, in BGP, if an advertised route has an inaccessible next hop, BGP will not install the route in the RIB. The example in this Network Lesson was pretty simple since all spokes and the hub had outside addresses all in the same subnet. This will almost never be the case, which means you will likely need to advertise these next hops via an IGP via the DMVPN tunnel. This will allow each BGP client to know how to reach the advertised next hop.
quick question concerning the ebgp configuration, i can see that in the routing table the next hop is not passing through the hub. however i can see that the AS path still mention the hub …even if the next hop is not the hub.
is it the normal behavior ?
That is correct yes. eBGP doesn’t change the next hop address.
If you wanted to use eBGP with different AS’s on the Spokes couldn’t you just advertise a default route from the Hub to the Spokes with ‘default-originate’ instead of advertising every prefix from every spoke (say there were hundreds of spokes)? I wouldn’t of thought this would be considered a ‘dirty trick’.
This is a viable solution as well. Of course if you have tens or hundreds of prefixes, the default route would be preferable. If you have the ability, lab it up and let us know your results!
I hope this has been helpful!
It actually does work, this is how we use it at work
I thought the next hop addresses are the tunnel addresses, not the NBMA addresses?
Spoke2#show ip route bgp 184.108.40.206/32 is subnetted, 1 subnets B 220.127.116.11 [200/0] via 172.16.123.1, 00:00:13 18.104.22.168/32 is subnetted, 1 subnets B 22.214.171.124 [200/0] via 172.16.123.2, 00:00:13
Then the router uses NHRP to “resolve” the tunnel addresses to NBMA addresses.
And for George’s default route solution, wouldn’t a default route force the data plane traffic via the Hub, rather than spoke to spoke direct communication?
The next hop addresses are indeed the tunnel addresses, which are then resolved with NHRP.
If you use DMVPN phase 3, all you need is that default route on your spokes. The hub uses NHRP redirects to spokes. The spokes will then do an NHRP resolution for each others address, and you’ll have direct spoke-to-spoke traffic.