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

Robert Boyle robert at tellurian.com
Wed Sep 28 19:01:11 EDT 2005


At 10:27 AM 9/28/2005, Ted Mittelstaedt wrote:
>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.

True, however, the people we spoke to at the TAC said this couldn't be 
done. I didn't believe them and Rodney has shown all of us a working 
config. This is a great thing and it would be nice if it made its way to 
the cookbook one of these days.

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

You didn't read ours very carefully. :) These are customers in outlying 
areas which we can't serve with a second connection any other way. (They 
are outside our DSL footprint, they can only get cable, they are in an 
independent telco area, etc.) They are in really remote locations such as 
rural Montana or rural Oregon. I am not going to drop an ATM T1 or DS3 with 
Pa's phone company to serve one customer - that's assuming they can get DSL 
and that Pa's phone company even allows independent ISPs to use their network.

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

Please don't assume you understand our business model or our customers' 
motivations. You clearly don't from your message. We provide an end-to-end 
hosted solution for our clients which must be up 24x365. The secondary 
connection is for our piece of mind. We get the bill and we are the 
customer of record with the phone company, cable company, other ISP, etc. 
We also monitor BOTH connections 24x7 from our NOC. This is one of our 
methods of meeting our strong application level SLA commitments. I 
understand that this could be seen as a hack in certain circumstances. In 
our situation, it actually will work well as a pretty elegant solution 
which will give them (relatively speaking) seamless fail-over should our T1 
to their location fail. We are providing a means to connect reliably to our 
services. The connection itself is not our product, it is the method of 
obtaining the product. If this config were for our Internet access clients, 
I would agree with you completely, however, it is not so I don't. I do 
appreciate you trying to convince us that we were trying to do something 
which is not in our best interest, but I asked a technical question and 
thought I explained why we needed this particular configuration without 
going into too much irrelevant detail. I know the "right" way to provide 
reliable Internet access via our network to our clients, I needed to know 
how to provide reliable Internet access to our clients via any connection 
available. Rodney answered and now we can meet our business objectives for 
a subset of our clients. Thanks again Rodney! :) I will drop this thread 
now unless someone else has an improvement or suggestion to make Rodney's 
example config even better.

-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



More information about the cisco-nsp mailing list