This does work.. I had this tested as proof of concept. Basically, I monitored a given EIGRP propagated route, and forced a dial once that route disappeared.
I did run into an issue, in that in order to establish the dial tunnel, the router has to know how to get to it's destination.
In the case of ISP DHCP, you have a default route to the ISP, which routes traffic to your GRE tunnel endpoint correctly. In the case of PPPoE or Dial, you need to specify yourself, since you aren't passed a default route on connection.
The trick is, if you're running PPPoE as a primary, with Dial backup. You really require two static routes pointing to different interfaces. Failover works fine assuming you physically unplug the DSL interface, as the router will remove the primary static...leaving the static pointing to your Async interface.
If something on the backend DSL goes down however, your tunnel dies, but your physical interface stays up, the dynamic routes disappear, your spoke will dial the ISP, but will still have a valid default route pointing to your "unusable" DSL interface for all your traffic.
The only way I could figure around that routing problem was to put 2 internet facing interfaces on my hub router, and configure one to handle normal DSL tunnels, and a second to handle ISP backup tunnel traffic. This way you can manually add two host routes on your spokes, one pointing out E1 for your Tunnel1 endpoint, and the second pointing out Async1 for your Tunnel2 endpoint.
There is also a bug I ran into running 12.2(13)ZH code on the spokes, where it would drop the tunnel (say..on an IP release/renew from the ISP), and never renegotiate. The only partially stable release I've found thus far has been 12.3(4)T4.
interface Tunnel1
description GRE Tunnel to Head
bandwidth 640
ip address 10.x.x.x
ip mtu 1416
ip nhrp authentication xxxx
ip nhrp map 10.x.x.1 209.x.x.x.1
ip nhrp network-id 1000
ip nhrp holdtime 300
ip nhrp nhs 10.x.x.1
no ip route-cache
delay 1000
tunnel source Ethernet1
tunnel destination 209.x.x.1
tunnel key 1000
tunnel protection ipsec profile vpn
!
interface Tunnel2
description Dialup Tunnel
ip address 10.x.x.x
no ip redirects
ip mtu 1416
ip nhrp authentication Sigfr13d
ip nhrp map 10.x.x.x 209.x.x.x
ip nhrp network-id 1001
ip nhrp holdtime 300
ip nhrp nhs 10.x.x.x
delay 10000
tunnel source Async1
tunnel destination 209.x.x.x
tunnel key 1001
tunnel protection ipsec profile vpn
!
interface Async1
description DialWatch to ISP
bandwidth 56
ip address negotiated
encapsulation ppp
shutdown
dialer in-band
dialer string 555-5555
dialer redial interval 90 attempts 3
dialer watch-group 1
dialer-group 1
no peer default ip address
ppp authentication chap callin
ppp pap sent-username xxxx password 7 xxxxx
!
ip route 209.x.x.1 255.255.255.255 E1
ip route 209.x.x.2 255.255.255.255 Async1
Then rely on EIGRP to give your spokes the rest of the routes it requires, and avoid configuring a GWofLR route on it.
