Vpn – Cisco PBR with DMVPN and Dual ISP

I have a DMVPN hub with 2 ISPs. I have two tunnels setup between the spokes, one for each ISP. I would like to dedicate one of the ISP links to voice traffic and failover. I'm having trouble achieving both. In my current config, voice travels where I want it, but I can't get failover working. The limitation seems to be because there's no verify-availability when using set interface under the route-map and the tunnel interface doesn't go down when connectivity is lost. Is there another way to accomplish what I'm looking for?

Here's the relevent config sections:

track 89 ip sla 89 reachability
!
track 245 ip sla 245 reachability

interface Tunnel0
 ip address 10.10.255.1 255.255.255.192
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 tunnel source GigabitEthernet0/1.245
 tunnel mode gre multipoint
 tunnel key 0
 tunnel route-via GigabitEthernet0/1.245 mandatory
 tunnel protection ipsec profile IPSec-Profile1
!
interface Tunnel1
 ip address 10.10.255.65 255.255.255.192
 ip nhrp map multicast dynamic
 ip nhrp network-id 2
 tunnel source GigabitEthernet0/1.89
 tunnel mode gre multipoint
 tunnel key 64
 tunnel route-via GigabitEthernet0/1.89 mandatory
 tunnel protection ipsec profile IPSec-Profile2

ip route 0.0.0.0 0.0.0.0 1.1.1.1 200 track 89
ip route 0.0.0.0 0.0.0.0 2.2.2.2 200 track 245

ip access-list extended VoIP
 permit ip any any dscp ef

ip sla 89
 icmp-echo 1.1.1.1 source-interface GigabitEthernet0/1.89
ip sla schedule 89 life forever start-time now
ip sla 245
 icmp-echo 2.2.2.2 source-interface GigabitEthernet0/1.245
ip sla schedule 245 life forever start-time now

route-map policyRouting permit 10
 match ip address VoIP
 set interface Tunnel1

UPDATE: Looks like the behavior changed in IOS. In older versions, if no corresponding routes in the routing table are found matching the set interface in the route map, the policy will reject the packet and proceed with normal forwarding. On new versions, it policy routes the packet to the next hop IP found in the routing table, but through the interface specified in the route-map. In my case, this results in the packet being routed through tunnel 1 to tunnel 0's IP. This causes it to fail.

Debug from the spoke – older IOS:

    *Jun  3 16:39:18.279: IP: route map policyRouting, item 10, permit
    *Jun  3 16:39:18.279: IP: s=10.10.17.2 (FastEthernet0/0), d=10.1.4.2 (Tunnel0), len 1228, policy rejected -- normal forwarding
    *Jun  3 16:39:18.279: IP: s=10.10.17.2 (FastEthernet0/0), d=10.1.4.2, len 1228, policy match
    *Jun  3 16:39:18.279: IP: route map policyRouting, item 10, permit
    *Jun  3 16:39:18.279: IP: s=10.10.17.2 (FastEthernet0/0), d=10.1.4.2 (Tunnel0), len 1228, policy rejected -- normal forwarding
    *Jun  3 16:39:18.279: IP: s=10.10.17.2 (FastEthernet0/0), d=10.1.4.2, len 1228, policy match
    *Jun  3 16:39:18.279: IP: route map policyRouting, item 10, permit
    *Jun  3 16:39:18.279: IP: s=10.10.17.2 (FastEthernet0/0), d=10.1.4.2 (Tunnel0), len 1228, policy rejected -- normal forwarding

Debug from the spoke – newer IOS:

    *Jun  3 16:10:15.807: IP: route map policyRouting, item 10, permit
    *Jun  3 16:10:15.807: IP: s=10.10.17.2 (FastEthernet0/0), d=10.1.4.2 (Tunnel1), len 1228, policy routed
    *Jun  3 16:10:15.807: IP: FastEthernet0/0 to Tunnel1 10.10.255.1
    *Jun  3 16:10:15.807: IP: s=10.10.17.2 (FastEthernet0/0), d=10.1.4.2, len 1228, policy match
    *Jun  3 16:10:15.807: IP: route map policyRouting, item 10, permit
    *Jun  3 16:10:15.807: IP: s=10.10.17.2 (FastEthernet0/0), d=10.1.4.2 (Tunnel1), len 1228, policy routed
    *Jun  3 16:10:15.807: IP: FastEthernet0/0 to Tunnel1 10.10.255.1
    *Jun  3 16:10:15.807: IP: s=10.10.17.2 (FastEthernet0/0), d=10.1.4.2, len 1228, policy match
    *Jun  3 16:10:15.807: IP: route map policyRouting, item 10, permit
    *Jun  3 16:10:15.807: IP: s=10.10.17.2 (FastEthernet0/0), d=10.1.4.2 (Tunnel1), len 1228, policy routed