Failover from SDSL to ADSL on a single Cisco 2801

Hi again

Really need to get this resolved by Monday so here are some more details.

We have a Cisco 2801 Router that currently routes a number of internal networks out via one interface onto an SDSL router and then onto the internet. It is configured to run NAT and there are a number of Static IP mappings between given external addresses (associated with the ADSL accounts) to specific servers on the internal networks.

We would like to set up a new ADSL line to act as a backup in the event of the SDSL failing. However any new ADSL account will obviously come with a new set of external IP addresses.

Is there anyway to configure the CISCO router to allow for some form of automatic failover that can also handle the new IP address without breaking the NAT translation tables?

Looking forward to hearing any suggestions and ideas.

If NAT configuration results in the same global address regardless of the active line, then it should be preserved during line switch-over. From you description it's not quite clear whether your SDSL and ADSL lines are terminated on the same 2801 router or is there some incumbent router on SDSL line or did you just mean provider-side SDSL access-server. Could you post an ASCII diagram of what the setup looks like?

Assume that your SDSL line isn't directly connected to 2801 but to some incumbent CPE, then how do you and and, not least important, - upstream router know that the line is down? Since your ethernet link will remain up you'll need either a routing protocol between you and provider, or static routing with object tracking.

If you use static mapping to a pool or single address rather than implicitly specifying an interface IP, then you should be fine. Besides, you could ask your provider to use the same /30 on both SDSL and ADSL links.

If it's really new addresses and you use interface address in the translation table implicitly, then I'm afraid your TCP/UDP sessions will break as new packets will arrive to the servers with new addresses. You need static NAT to the same address or range of addresses regardles of which link is operational.

Kind regards, iLya

This has been addressed in the past on this forum and on the cisco web site forum. The answer has not changed in the last two years. You actually have to deal with two independent issues, and even if you do, the results are imperfect.

1 - You need to be able to reliably detect failure of the SDSL line. Otherwise, the router has no way to recognize when to fail over to the ADSL line. It is not safe to assume that the SDSL line will always (or even usually) fail at the physical layer, and if you connect to an external SDSL modem via Ethernet, even that is irrelevant. Search for posts on "ping based routing" which can be built over Cisco's response time recorder (RTR) feature. 2 - You need to set up NAT so the NAT used depends on the interface used. You will find lots of recommendations to use Policy Maps for your NAT translations, usually from people who have read the docs but not actually tried to achieve what you are attempting. The problem is that the policy maps are ONLY applied while setting up a translation for a new connection, and once the translation is set up, the same translation is used regardless of the interface actually used. I have heard of four techniques to get around this limitation: 1) log into the router and clear the translation table (typically either manually or from a Linux box on the network), 2) do at least one of the NAT's outside the router so that the translation table is ignored for at least one of the two routes, 3) use the syslog programming feature available on some router models (such as 172x) to run a TCL program which checks for changes in outbound interface and clears the translation table as necessary, and 4) buy one of the multi-port LinkSys or other brand SOHO routers which ship with this capability built in.

A few comments on the alternatives:

1 - ping based routing works fine, but you need to be careful setting it up so that all failure modes are detected. There can also be problems detecting link recovery under some conditions (e.g., the RTR stops trying when a link goes down at the physical layer). 2 - sub option 1) requires an extra box, writing custom scripts, and keeping everything running. 2) requires an extra box, 3) is a real hack, I have demonstrated this working in a lab setup, but have not heard of anyone actually using it in production, 4) lots of horror stories about cheap routers which require routine rebooting to keep functioning, not to mention the pain of explaining to the boss why you recommended the higher priced Cisco gear.

Good luck and have fun!