[c-nsp] Need some advice on ISP failover for an enterprise

[Vincent C Jones]

Given that the majority of your failures will be in the "last mile," if
you do not have physical link diversity, adding a second link will
typically only provide a small improvement in availability. Beyond that,
your key concerns are complexity, cost and future growth.

If you pick option 3 and you need to tunnel for security purposes, think
through how you plan to deal with the reduced MTU of the tunnel.
Depending on your server requirements, the cleanest approach is often to
just reduce the MTU used by the server to match the tunnel, even though
it is smaller than what you could use under normal circumstances. Also
keep track of traffic so that when the backup link is put to use, you
don't discover the hard way that traffic has grown to the point where it
won't fit!

Good luck and have fun!
-- 
Vincent C. Jones
Networking Unlimited, Inc.
Phone: +1 201 568-7810
V.Jones at NetworkingUnlimited.com


On Fri, 2010-01-08 at 14:25 +0530, Andrew Gabriel wrote:
> Hi,
> 
> We have servers at two of our large locations in a single country that need
> to be reached from the Internet. Both locations each have a single 45 M ISP
> link, and also have internal connectivity with each other through multiple
> private links. The private WAN connecting the two locations has plenty of
> bandwidth and the latency is less than 40 ms between the two sites.
> 
> We have our own registered ASN and public IP ranges. We have multi-homed ISP
> links at several other locations but not at these two locations. Also, both
> locations are partly ready for multi-homing in that they already use our own
> IP range and run BGP to the provider using our ASN.
> 
> We have been asked to implement failover, for both the locations. The
> options we are considering are:
> 
>    1. Traditional multi-homing  by adding a second ISP at each location.
>    2. Buying a leased line to connect the CER at both locations and letting
>    the incoming traffic for either location transit over that line to provide
>    failover when one site's ISP goes down. This link would terminate on the
>    'dirty' side of our firewall and not have anything to do with the internal
>    WAN.
>    3. Setting up a VPN-type tunnel between the ISP routers at both sites
>    that would be routed over our internal WAN. This is similar to option 2 but
>    doesn't involve any extra cost.
> 
> Obviously we would prefer option 1 as it is simplest and safest to set up,
> and we already have experience with that type of setup, however we have been
> asked to look at cheaper options due to budget constaints, hence wanted some
> advice on the other options, do you think they could work well, any
> potential issues we should look out for, or should we even be considering
> them?
> 
> Regards,
> Andrew Gabriel.
> Network Engineer,
> Enterprise Data Services.
> +91 44 42 22 88 75 (Direct)
> +91 98 41 41 40 19 (Mobile)
> www.sanmina-sci.com
> Sanmina-SCI India Pvt. Ltd.
> A51, 2nd Avenue, Anna Nagar,
> Chennai - 600 102, INDIA.
> 
> CONFIDENTIALITY
> This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited.  If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
> ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING.  Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any other person or entity.
> _______________________________________________
> 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/