I'm trying to backup a T1 connection with a DSL interface. I already found that the DSL is training fine, but because the DSL is provided by a different provider, I am wondering how I can use NAT to map the same inside IPs on the backup interface.
For example:
Say I have the T1 which normally would have the global IPs 10.1.1.5 -
10.1.1.10 NATed to inside IPs of 192.168.1.1-254. When the backup comes up, I now have a global address range of 20.1.1.5 - 20.1.1.10. Is there a way I can NAT this new outside address range to my internal IP without much hassle?
I am using the backup command on the T1 interface to jump to the DSL interface BTW.
If the router is doing all the NAT's, you will run into a nasty limitation in Cisco NAT (NAT route maps are only evaluated when setting up a NAT) that makes the approach unworkable unless you do some fancy TCL programming using a bleeding edge IOS release.
The easy way to get this to work is to set it up so that only one of the two outside interfaces is "outside" from the viewpoint of NAT (for example, by using a separate firewall).
I just thought there was some way of having a backup NAT table in case of a primary link failure. I could've sworn I heard of something like that. In my case, I literally need the secondary NAT to kick in only when the Serial Link fails, and the DSL interface is then taken off standby. This particular building decided that they would use a regular DSL to backup their T1 ( I wasn't working there at the time). Then they discovered that the DSL link wasn't working, and they wanted me to fix it. From the looks of it, their DSL backup never worked, so I have no idea what their last network guy did...
I would guess that a DSL interface on the router itself would be useless in this case then... They could've just used a second ethernet port and mark that as another inside NAT interface, while having a backup route point to that second gateway incase of a failure.
In that case, using the backup command would also be redundant right? The DSL link could just be left up and used if one route goes down.
This is a common requirement that is unnecessarily difficult to achieve. It is tricky, because it is very easy to implement it in a way which makes it look like it works, but fails when reality sets in...
The challenge is getting all the pieces to work together. Let's look at what you need to do to get the job done.
(1) detect when the primary link is down,
(2) route outbound traffic out the secondary link when the primary is determined to be down,
(3) use NAT translations appropriate for the secondary link for all traffic out the secondary link.
So far, so good, and this is probably what their last network guy did by using a floating static route for the secondary and route maps to drive the NAT. What makes the job challenging are the remaining steps...
(4) detect when the secondary link is down, even when not in use, so it can be repaired before it is needed for backup.
(5) return operation to normal when the primary link returns to service.
Without step (4), when the time comes that the backup link is actually required to restore service, it will be discovered that the link is no longer functional and you will be down until one of your links can be repaired. One big oops.
Step (5) is where NAT becomes problematic. Cisco only applies the NAT route map when setting up a needed translation. Once the translation is defined, it will continue to be used for all traffic passing between inside and outside interfaces until either the translation times out from a lack of use or the translation entry is cleared from the active translation table. This is not obvious when your primary fails, because Cisco will clear all translation table entries using the IP address of a serial link when the serial link fails (note that if your NAT does not use an IP address defined on the serial link, all bets are off). But when the serial link returns to operation, there is no equivalent clearing of the NAT table entries set up based on the Ethernet link (which is still functional, just not used for outbound traffic any more).
This is ignoring the unavoidable disruption of all active connections (whether TCP or UDP based) even if the NATs are automatically migrated from one link to the other, simply because your address will change from the viewpoint of the remote system and all connections will need to be reestablished. With most applications, this means start over from the beginning, although with some, such as web browsers, a simple refresh may be sufficient to reconnect and continue on.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.