It is difficult to know exactly what the problem is, especially since some information that would be helpful is hidden or omitted in the configs that you posted. But here are my observations, which might help to point toward at least some of the problem.
On the HQ router you have a static route to the remote router and a floating static for backup:
ip route 10.30.53.0 255.255.255.0 10.30.47.102
ip route 10.30.53.0 255.255.255.0 Async1 100
the floating static will be used only if the primary route is withdrawn from the routing table. That would generally be the case only if the interface of the next hop goes protocol down. Since you have hidden what interface would include 10.30.47.102 we have little way to know how failure would impact it. When you test and produce the failure, if you do show ip route on the HQ router is it using the normal route or is it using the floating static?
On the remote router you have a default route through Faste0/0. And you have another static route for the subnet of HQ using the Async:
ip route 10.30.40.0 255.255.248.0 Dialer1
However the prefix that you specify in the static route is exactly the same as the subnet on the FastEthernet interface. If the router has a static route for a prefix and the prefix exists as a connected route than the static route will not be used. In normal operation, on the remote router what is in the routing table when you do show ip route? And when you induce the failure what is in the routing table when you do show ip route?
If you answer the questions that I ask we may get closer to understanding what the problem is and what might be done to solve it.
The information in this post answers some questions and raises a new question.
If the central RTR continues to use the normal route during the failure then this is an indication that the interface does not change state to protocol down during the failure. This is not uncommon for Ethernet/FastEthernet/GigEthernet interfaces. Depending on the version of code you are running you might look into Object Tracking or IP SLA to determine reachability of the remote subnet and remove the normal route from the routing table. As it stands you have created a problem and the central RTR continues to send traffic over the normal route (which creates a black hole).
The interesting thing in the routing tables that you post is that in the first (normal) routing table that 10.30.40.0 is connected to FastEthernet and in the second routing table (during failure) it is connected on the Dialer interface. This shows that the FastEthernet interface did change state to protocol down. Which is quite different from the central RTR. Do we know why they react differently?
This is actually a pretty cool feature, i didn't even know it existed until I was looking for a solution to advertise a subnet (prefix in BGP talk), only if a certain condition existed. This is exactly what conditional advertisements does
j ai une question j ai achete un routeur cisco 887VA-k9 , je le configuré avec la configuration ci- dessous
si je le lier avec mon pc portable sur l un de ses ports directement ça marche toute est bien ( la connexion internet + m...
Attached policy provides CLI access to the Cisco 4G router over text messaging. Two files are in the attached .tar file:
2. PDF with instructions on how to load and use the .tcl file.