In many DMVPNs, two or more spokes connect to the same LAN segment. This is illustrated in the diagram below:
In this example, spoke1 and spoke2 connect to the same LAN Subnet 2.2.2.0/24. In this Phase I version of DMVPN all traffic between the spokes travel via the hub (except where spoke 1 and spoke 2 are directly connected). Hub1 sees the route to 2.2.2.0/24 as two equally load balanced routes:
Hub1#show ip eigrp topology EIGRP-IPv4 VR(dmvpn) Topology Table for AS(100)/ID(1.1.1.1) Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status P 2.2.2.0/24, 2 successors, FD is 9836953600 via 192.168.1.2 (9836953600/13107200), Tunnel0 via 192.168.1.3 (9836953600/13107200), Tunnel0 <snip>
However spoke 3 sees the same route as a single path (via the hub). It is not aware of two paths between the hub and spokes 1 and 2, as seen below. Bear in mind that in order for the spoke to see this route, split-horizon will need to be disabled on the hub (the rule that any received route cannot be advertised out of the same interface)
Spoke3#show ip eigrp topology EIGRP-IPv4 VR(dmvpn) Topology Table for AS(100)/ID(3.3.3.3) Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status P 2.2.2.0/24, 1 successors, FD is 13113753600 via 192.168.1.1 (13113753600/9836953600), Tunnel0
If spoke 3 loses visibility of this route via 192.168.1.1 then this will cause it to query its neighbour for an alternative path. To avoid this the hub can be configured to advertise more than one path to the spoke. This is configured using the add-path command. This command is only supported in named-mode and is configured under the af-interface section. It was first introduced in IOS version 15.3(2)T
The Traceroute Blog 