Static routes, ISDN & different remote IP addresses

Question

Scenario:
My client has 4 sites situated around an ISP MPLS cloud. All 4 CE routers connect to ISP PE equipment via different access circuits (See attached diagram).
The central site has Cisco 2800 router with 10M LES circuit into MPLS cloud (FastEthernet i/f) and ISDN BRI i/f for incoming calls from 3 remote sites.
The 3 remote sites are Cisco 1800 routers all with ISDN dial-out i/f’s and 1 site has numbered X21 serial link into MPLS cloud, whilst other 2 sites have IP unnumbered DSL circuits.
Problem:
1. Routing on the 4 routers is by static routes only, as ISP does not permit routing protocol.
2. Central router does not know if the remote DSL & X21 circuits have gone down, as they are all access circuits into MPLS cloud.
3. Central router (2800) needs floating static routes to change so that packets route via ISDN when remote sites dial in, but these are proving problematic to configure, as both the ISDN and FastEther i/f’s show as “up” on the 2800 under normal operation. So the routes stay as the higher weighted route all the time, regardless of whether the remote has dialled in or not.
The remote routers (3) can dial in fine when their Serial or ATM interfaces go down (using backup command on i/f’s). I have tried using floating static routes on the central router using 10.1.0.0/29 addresses assigned to the 4 ISDN interfaces, but the floating static remains up all the time, as the interface on the central router stays up all the time (as expected). The ISDN static route therefore stays in the routing table all the time, even when there is no ISDN call into the central site. The config on the central router is as follows:
interface BRI0/1/0
ip address 10.1.0.1 255.255.255.248
encapsulation ppp
isdn switch-type basic-net3
ppp authentication chap
ip route 172.16.2.0 255.255.255.0 10.1.0.2
ip route 172.16.2.0 255.255.255.0 10.0.0.1 200
ip route 172.16.3.0 255.255.255.0 10.1.0.3
ip route 172.16.3.0 255.255.255.0 10.0.0.1 200
ip route 172.16.4.0 255.255.255.0 10.1.0.4
ip route 172.16.4.0 255.255.255.0 10.0.0.1 200
The only way I think I can get around this problem in a simple manner is to have floating static routes with higher weights assigned to completely different IP addresses than the local ISDN interface. In the past I have seen that async modems dialing into a PRI circuit appear as directly connected in the routing table of an AS5300 (and work), even though they may be different network addresses than the PRI Dialer i/f address. An example of the static routes on the central router would be as follows:
ip route 172.16.2.0 255.255.255.0 2.2.2.2 (Route to site 1 only when ISDN backup is invoked)
ip route 172.16.2.0 255.255.255.0 10.0.0.1 200 (Route to site 1 under normal conditions, i.e when remote has NOT dialled central via ISDN)
ip route 172.16.3.0 255.255.255.0 3.3.3.3 (Route to site 2 only when ISDN backup is invoked)
ip route 172.16.3.0 255.255.255.0 10.0.0.1 200 (Route to site 2 under normal conditions, i.e when remote has NOT dialled central via ISDN)
ip route 172.16.4.0 255.255.255.0 4.4.4.4 (Route to site 3 only when ISDN backup is invoked)
ip route 172.16.4.0 255.255.255.0 10.0.0.1 200 (Route to site 3 under normal conditions, i.e when remote has NOT dialled central via ISDN)
Questions:
1. Has anyone experienced this type of problem across multiple access circuits?
2. Has anyone tried to implement different IP addresses at the remote ends of an ISDN network? (See diagram below) I want to try /32 addresses on the 4 routers, e.g 1.1.1.1, 2.2.2.2, 3.3.3.3 and 4.4.4.4. (Don’t have time to lab test this solution)
3. Can anyone suggest a simple solution?

Answer 1

What you want is object tracking, which will resolve this problem.
This technology sets up an object that pings a remote address. You use a route map to force the ping out of the interface that appears to remain up, in this case the MPLS main interface.
When a link fails somewhere, the object no longer gets a response and transitions to the down state.
You can use a static route that tracks the object to become active, this will be used to activate your local ISDN.
This was described in Packet Magazine 2ndQ 2004, here:
http://www.cisco.com/web/about/ac123/ac114/downloads/packet/packet/apr04/pdfs/apr04.pdf
Read the article about Static and Policy Routing Enhancements, its excellent and should help you out.
Another way would be to build a GRE based VPN over the existing MPLS network, have you considerd that?
Andy