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

[David Prall]

I haven't played with this, just some ideas.

How about if you use PBR to mark precedence to something. Then base the ip
nat inside source list on this precedence marking. You could then have two
nat settings to external interfaces. The default route would be gone based
on loss of the first connection, or removal via SAA Tracking. So now PBR
would set the next hop to the second interface. PBR would always be used on
the inside interface, to either follow the routing table based on
verify-availability, or to the second interface based on the first portion
not working. This can be done using the SAA tracking as well.

Now will it work, I have no clue.

David

--
David C Prall dcp at dcptech.com http://dcp.dcptech.com
  

> -----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 11:45 AM
> To: Chris Moore; cisco-nsp
> Subject: RE: [c-nsp] Simple NAT based IOS failover between providers
> 
> At 11:25 AM 9/26/2005, Chris Moore wrote:
> >Just as a "general architecture" comment:
> >
> >First, understand exactly what you are trying to do. For outgoing
> 
> Thanks. I do understand what I'm trying to do. Perhaps I 
> haven't expressed 
> myself clearly enough.
> 
> >traffic, it's really easy. You just have two default routes out two
> >public interface and tell them both to NAT. Use route metrics to
> >determine primary/secondary. That's what your $79 consumer router is
> >doing. Really simple.
> 
> However, it doesn't work like that with IOS. I need it to 
> fail over from 
> the primary to the secondary and simply changing the routes doesn't 
> accomplish that with IOS NAT in the test configs we have 
> used. The $79 
> consumer router actively monitors the primary link for end to end 
> connectivity and switches when connectivity is lost. This is 
> what I need 
> from the IOS based router as well.
> 
> >Incoming traffic is a different story. Sure - it's easy 
> enough to have
> >two NATing interfaces and just have two sets of NAT mappings. But how
> >does "the world" know to go to the other set of addresses? 
> You need DNS
> >for that. SO that means doing your own DNS or working with 
> someone who
> >will let you run scripts to do DNS updates. Then have a 
> script that goes
> >out and changes DNS when one of the links goes down. The script is
> >pretty simple - you should be able to find plenty of examples online.
> >Some ISPs and other companies (DynDNS.org comes to mind) 
> offer managed
> >functionality like this.
> 
> I don't need anything inbound. These are remote offices which 
> simply need 
> to be up 100% of the time.
> 
> -Robert
> 
> 
> 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/
>