Scratching head on dual-ISP solution

mikearama

Okay techies... hit me with your best.

Here's the background:
We have two isp pipes... a 10Mb for users/email, and a 30Mb for E-Biz.
On the 30Mb we host our own servers... toyota.ca and lexus.ca, and their microsites.
Our provider has twice in the last 30 days let our connection drop, both times during business hours, and both times for in excess of 2 hours.

I've been asked to investigate adding a backup isp.

I understand the concept of adding a second isp, and since my bsci studies are still fresh, expect to have to implement BGP.

My questions revolve around, not getting out to the internet, but ensuring that our e-business gets back up quickly and is available. This means getting the second link up quickly, but then also getting dns resolution changed to point at the ip's provided by the second isp.

Anyone in a similar situation? Cause the questions don't end there...

Let's assume that the public IP's the Bell has given us are in the 10.10.10.0 range, and the new ISP throws us 20.20.20.0. Our content switches and Pix's all map services to the long-existing 10.10.10.0 range. Our service fails, and somehow, amazingly, dns flips to the backup ip's in a timely fashion. Now you enter toyota.ca in your browser, and the result is an ip of 20.20.20.50, which sends you down the path of the backup isp to the backup link on the border router. The router gets the traffic, and pushes you on to the content switch, which knows nothing about the 20.0.0.0 network, as it's configured for the Bell IP's.

Do those of you in the same situation create static nat's, mapping the backup isp's IPs to the primary IPs? Is there another option?

I appreciate any inputs and/or links.
Mike

cisco_trooper

Your two ISPs will have to cooperate with each other to some extent. You will keep your existing IP space. Both ISP should be willing to create a BGP peering relationship with you, but the 2nd ISP will have to be willing to accept your advertisement of your current IP space which is obviously not going to be IP space that they own...

tech-airman

mikearama,

mikearama wrote:

Okay techies... hit me with your best.

Here's the background:
We have two isp pipes... a 10Mb for users/email, and a 30Mb for E-Biz.
On the 30Mb we host our own servers... toyota.ca and lexus.ca, and their microsites.
Our provider has twice in the last 30 days let our connection drop, both times during business hours, and both times for in excess of 2 hours.

What is the Terms of Service between you and your service provider? Are two connection drops within 30 days in compliance or violation of the Terms of Service with the Service Provider?

mikearama wrote:

I've been asked to investigate adding a backup isp.

Literally, are there any backup ISP options with a different Central Office than your current service provider?

mikearama wrote:

I understand the concept of adding a second isp, and since my bsci studies are still fresh, expect to have to implement BGP.

My questions revolve around, not getting out to the internet, but ensuring that our e-business gets back up quickly and is available. This means getting the second link up quickly, but then also getting dns resolution changed to point at the ip's provided by the second isp.

Anyone in a similar situation? Cause the questions don't end there...

Let's assume that the public IP's the Bell has given us are in the 10.10.10.0 range, and the new ISP throws us 20.20.20.0. Our content switches and Pix's all map services to the long-existing 10.10.10.0 range. Our service fails, and somehow, amazingly, dns flips to the backup ip's in a timely fashion. Now you enter toyota.ca in your browser, and the result is an ip of 20.20.20.50, which sends you down the path of the backup isp to the backup link on the border router. The router gets the traffic, and pushes you on to the content switch, which knows nothing about the 20.0.0.0 network, as it's configured for the Bell IP's.

Do those of you in the same situation create static nat's, mapping the backup isp's IPs to the primary IPs? Is there another option?

I appreciate any inputs and/or links.
Mike

cisco_trooper

tech-airman wrote:

Literally, are there any backup ISP options with a different Central Office than your current service provider?

+1

mikearama

Oh yeah, I assure you, the business is going after compensation. Incidentally, it was the same line card in the same router at a distribution centre somewhere in Toronto... both times.

So, you mean a different CO, but still with Bell? or did I misread that?

rossonieri#1

hi mike,

So, you mean a different CO, but still with Bell? or did I misread that?

ya .. its more like different POP (point of presence) from the same provider.

The router gets the traffic, and pushes you on to the content switch, which knows nothing about the 20.0.0.0 network, as it's configured for the Bell IP's.

which content switches? cisco - nortel - juniper - other? perhaps i can give you a little help.

hmm .. i'm not too clear about your network topology : but does your edge router perform a full routing or NATd one? this could make a huge differences of troubleshooting method. Does those 2 routers directly connected to your content switches? or do your route them first to another L3 devices?

i think your problem pretty much on network design side that was not build or not ready to take a multi-homing situation - no offense. i think VRRP and or another 1 HOP (or 1 additional subnet/gateway between your content switch and your 2 gateways will do the job).

Do those of you in the same situation create static nat's, mapping the backup isp's IPs to the primary IPs? Is there another option?

do you mean like creating overlapping NAT? its possible - but it will take a very hard work - not to mention wasting your IPs and modifying your firewall (if applicable).

just my opinion,

cheers

astorrs

Another thing to consider in Ontario, Canada is that no matter who the provider is, Bell will most likely own the last mile and so you're not going to be getting a fully redundant connection. Definitely something to ask any other vendor you're talking with.