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

[Ted Mittelstaedt]

>-----Original Message-----
>From: Vinny Abello [mailto:vinny at tellurian.com]
>Sent: Monday, September 26, 2005 11:53 PM
>To: Ted Mittelstaedt; Robert Boyle; cisco-nsp
>Subject: RE: [c-nsp] Simple NAT based IOS failover between providers
>
>
>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.
>

There are lots of things a Cisco router can do that there is no
posted configuration for.  That is why you have a service contract.

I've beaten Cisco TAC before on the need for posting configurations
for basic things, and they still aren't in the example areas.  Granted,
this is an EXTREMELY WEAK point of Cisco support.  But you don't
get service contracts with $79 Asian routers either.

For example, try to find a PIX config for support of Windows VPN
l2TP (microsoft) clients.  The PIX can do it, but Cisco does not tell
you how.  They have a partial config for Win 2K client support - but
the microsoft Win 2K VPN client is -different- than the Microsoft
Win 98 SE l2tp vpn client, and the Win XP l2tp vpn client and Ciscos
example config doesen't work.

Try to find a config for support of a Cisco client VPN into a IOS router
that already has a lan-2-lan VPN into it.  Once again, IOS can do it -
but this config is missing from the examples.  Lots of configs of
either the Cisco VPN client only into IOS or a lan2lan VPN into IOS - but
not both of them at once into IOS.

>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.
>

Except it doesen't work in the scenarios where both sides aren't
PPPoE and it doesen't work if one side loses connectivity further
upstream.  Which are the more common failure scenarios.

>>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...

Why would a provider that has both the primary and backup link to
a customer be exchanging routes outside his network to that customer?
Is it common for single-homed customers to accept a full BGP table
instead of a simple default route?

Unless that customer was their own AS and had a feed to a different
ISP which is not what I was advising in the scenario.

You are DOING yourself what I said you SHOULD be doing, with your
other customers, you explained this in your private AS bgp scenario.

You didn't read my post very carefully.

>>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.

I think your foolish.  You are basically assisting a customer of yours
who does not have their own AS (basically a customer that does not
use any significant amount of public address space) to use a competing
ISP as a backup, as I understand this correctly.  That gives your
competitor an excuse to come in each month and pitch to your
customer. (assuming your competitor has any minimum level of
competence at sales)  Your either going to have to spend the sales
dollars to
match this, or inevitably your customer is going to be stolen away by
your competitor.

If it was me and one of our customers came to us with this kind of
wacky proposal, I would tell them "good luck making it work, your
on your own"  In fact I have done so.  And as we expected, said
customer finally got tired of flirting with the other ISP when their
cobbled-together backup solution didn't work, and eventually
gave it up and did what we had been telling them to do for years -
which was give up their DSL line and get a T1 from us.  We also
replaced their $79 Asian router with a real Cisco as well.

As I have told people before, there's things you CAN do and there's
things you SHOULD do.  Ocassionally I see posts here from people
who want to construct technical solutions that are based on a rather
poor business foundation.  Yours is one of these.  Hopefully your
charging your customer a shitpile of money for building this house of
cards for them, because otherwise your just giving them a nice
baseball bat to hit you over the head with.

When your circuit to them just works, they will assume the backup
solution
is working correctly and you will not get credited for maintaining good
uptime.  When the backup solution fails during the one time that your
primary T1 to your customer gets hamstrung by the carrier, due to the
other ISP's incompetence, your going to get blamed.  Either way your
left holding the turd because you took responsibility for setting up the
house of cards to begin with.

Ted