[c-nsp] Simple NAT based IOS failover between providers

Tue Sep 27 02:52:45 EDT 2005

At 01:57 AM 9/27/2005, Ted Mittelstaedt wrote:

>Do you even understand how those cheap Asian routers do this?
>
>I will tell you.  They are dependent on running PPPoE to both
>providers.  If the PPPoE session drops to 1 provider they assume
>that leg is down.
>
>What your missing though is that this kind of link state tells you
>NOTHING about real connectivity.
>
>Suppose your primary provider loses HIS connectivity to the rest of
>the world.

The above points are all understood. The point was these devices can 
do what you state above rather easily yet a similar configuration for 
a Cisco router isn't commonplace to achieve this.

The primary thing we were looking for was the solution Rodney 
provided by using route-maps to NAT outgoing traffic out the proper 
interface should the default route change.

>If you did your redundancy with BGP like a real ISP does, then you
>would instantly see this and would stop routing through him.

We are a real ISP and do use BGP whenever possible. :) It's how we 
setup redundant connections for the vast majority of our customer 
base. As Robert stated, this is done where we can provide both 
connections (primary and backup) and use a private AS to announce the 
address space of the loopback interface which is typically the 
NAT/VPN endpoint source. We announce a default to the primary and 
secondary connections. The CPE pads incoming and outgoing routes 
(default and the loopback interface respectively) on the backup 
connection by adding a MED of some value. All customer routes are of 
course tagged no-export in these scenarios.

>But if all your looking at is link state to your provider then your link
>to your provider could be up but his to the rest of the Internet be down,
>and your $79 router isn't going to switch over.
>
>The very best way to handle redundancy is to find a provider that
>is multihomed to your POP, and then setup a primary and backup link to
>him.  Then run a routing protocol like OSPF or some such to him.
>I've done this with customers before using RIP, it's a bit tricky but
>it does work, unlike your kludge your wanting to do.  And yes we
>are multihomed into the POP that I do this out of.

OSPF/RIP for exchanging routes from outside your network? Yuck... I 
don't find that flexible enough. The only way we would consider doing 
something like that is peering via BGP to a neighbor and having them 
tag our routes in some way and only advertise them back to us over 
our peering connection. We had considered that but the opportunity to 
peer isn't presently there. I really don't want to get involved with 
whacky tunneling solutions either for peering. We were looking at 
L2TP for transporting the backup connections to us so they can 
terminate on our network as well, but that is up to provider B and 
also adds some additional headaches of MTU issues.

>Naturally your provider could have a power failure or some such
>that takes him out.  But if he's a good provider he will have redundancy
>within his own network that will prevent this from happening, and you
>will have a direct line to his engineers in case it does.

They would be the secondary connection, in which case it's not as 
critical if their connectivity goes down.

>Getting 2 different cut-rate providers and trying to do redundancy to
>them is not as good as finding 1 good provider and doing redundancy to
>him.

We are good provider #1. We are working with someone we hope is good 
provider #2 to get a good solution in place that won't require this. 
:) What was asked in this email was a solution that would hopefully 
work with us and any other provider regardless of their cooperation 
or if good provider #2 proves to be dumb provider.

>Ted

Thanks for your comments, Ted. :)

> >-----Original Message-----
> >From: cisco-nsp-bounces at puck.nether.net
> >[mailto:cisco-nsp-bounces at puck.nether.net]On Behalf Of Robert Boyle
> >Sent: Monday, September 26, 2005 8:02 AM
> >To: cisco-nsp
> >Subject: [c-nsp] Simple NAT based IOS failover between providers
> >
> >
> >
> >Hello,
> >
> >We opened a ticket with the TAC and were told this was not possible. I
> >don't believe it. Many $79 generic Asian routers sold at office supply
> >stores can do this out of the box so I have to believe that
> >Cisco with 10+
> >years of IOS development and a $1500 router can do something
> >this simple.
> >Situation details below:
> >
> >Router with two "outside" interfaces - Both Ethernet in the
> >cheap routers
> >or WIC-1DSU-T1 and WIC-1ADSL in our Cisco example
> >Router has one "inside" Ethernet interface which runs NAT with IPSEC
> >passthrough.
> >
> >The first outside interface is connected to ISP A (us in this case)
> >The other outside interface is connected to ISP B (the local
> >telco or cable
> >company in this case)
> >
> >The router is configured so ISP A is the primary Internet link
> >and it pings
> >the far side of the WAN connection to determine if the link is
> >up. When the
> >primary link is up, all traffic is NAT mapped and sourced from
> >the primary
> >WAN IP. If the ping fails, the router changes the NAT mappings
> >to use the
> >second link with ISP B and all packets after that point are
> >sourced from
> >the second WAN interface IP address. Fail back can be automatic after a
> >timer expires or a manual process such as a reboot. I don't really care
> >either way, but I do need the failover from ISP A to ISP B to
> >be automatic
> >based on interface state, ping, or some other reliable method.
> >I have seen
> >some documentation for IOS which enables changing routes based
> >on a ping
> >response, but how do I change the NAT mappings as well? A working real
> >config or a pointer to a cookbook example would be great! We
> >have Cisco PIX
> >boxes doing IPSEC behind these 1721s and 28xx routers at these
> >sites and
> >timers set to 1 minute on the PIXes so they will reconnect
> >within a minute
> >if the primary link fails. I believe that there HAS to be a way
> >to make a
> >Cisco IOS router do something that a $79 consumer router can
> >do! Thanks in
> >advance for any assistance!
> >
> >-Robert
> >
> >Before anyone suggests another method such as BGP, that won't work. We
> >can't provide the secondary link to these locations since they
> >are isolated
> >small offices in independent telephone territories or cable is the only
> >option as ISP B (and ISP B doesn't speak BGP.) Thanks!
> >
> >
> >
> >Tellurian Networks - The Ultimate Internet Connection
> >http://www.tellurian.com | 888-TELLURIAN | 973-300-9211
> >"Well done is better than well said." - Benjamin Franklin
> >
> >_______________________________________________
> >cisco-nsp mailing list  cisco-nsp at puck.nether.net
> >https://puck.nether.net/mailman/listinfo/cisco-nsp
> >archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> >--
> >No virus found in this incoming message.
> >Checked by AVG Anti-Virus.
> >Version: 7.0.344 / Virus Database: 267.11.6/111 - Release Date:
> >9/23/2005
> >
>
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/

Vinny Abello
Network Engineer
Server Management
vinny at tellurian.com
(973)300-9211 x 125
(973)940-6125 (Direct)
PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0  E935 5325 FBCB 0100 977A

Tellurian Networks - The Ultimate Internet Connection
http://www.tellurian.com (888)TELLURIAN

"Courage is resistance to fear, mastery of fear - not absence of 
fear" -- Mark Twain