Hello Octavio,
a)
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…',
'offset-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.
b)
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.
Hope to help
Giuseppe
