However, in a dual cloud DMVPN configuration where the two hub routers are connected back to back, it still doesn't work.
Following your adviced also for the dual cloud DMVPN, I tried several combinations, none of which gave optimal routing results.
Routes for spoke2 get announced over hub2 to hub1, instead of going directly through the tunnel; either that, or routes from spoke1 to the net behind the hub routers go through the DMVPN instead of the non-shared direct link.
you say "Tracing this, it looks like even the tunnel has "ip no next-hop-self eigrp x" on the hub, it is advertising to spoke1 its own metric instead of the AD the hub gets from spoke2.
What would be the best to avoid this, and make the hub advertise the AD from spoke2 to spoke1?"
I don't think you can make this for the way that EIGRP works: it cannot advertise the received metric to somebody else.It advertise as its own AD its best metric to the route. (DV behaviour)
However, you can play with several tools to manipulate metric on different tunnel and physical interfaces
interface BW and delay, 'distribute-listâ¦',
In this way you can have control what hub is preferred to reach a specific subnet or you can build a hierarchy of hubs.
However, for dual Hub dual DMVPN clouds be aware that there is a restriction:
Spoke-spoke dynamic tunnels can be setup only within same DMVPN
So if spoke1 and spoke2 haven't a common hub they cannot build a direct spoke-to-spoke tunnel.
When you say:
"Besides the DMVPN, the hub router and spoke1 have a direct serial link. Now, when spoke1 tries to connect to spoke2, it goes through that direct serial link through the hub."
DMVPN builds a virtual backbone over a real network. So serial interface can be part of the real physical backbone and used to carry tunnel packets to and from spoke1 and hub.
But in the physical backbone you need to use a different routing protocol (at least a different process) with the only objective to make the public addresses reachable and NHRP mapping of virtual backbone ip addresses to the real ip addresses possible.
You shouldn't mix the two networks this could break the security level provided by the ipsec+mGRE overheads.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...