Re: Multihoming an end user
Eric Cunnningham wrote:
My understanding was that if the addresses weren't specifically
allocated to us straight from ARIN, we couldn't truly multihome.
Otherwise our second ISP would try to route to our first ISP's
addresses through that first ISP rather then direct through their link
to us. If we apply for an ASN, can we associate our first ISP's /29
(or /24 if need be) to our ASN? Does our primary ISP need to release
it to us or be multihomed themselves?
Once this is all said and done, is BGP4 on zebra the way to go or is
there something better?
Thanks for your help Pete!
Problem is, getting address space from ARIN doesn't tell the rest of the
world how to route traffic to you. You would be able to work out how
your two ISPs can route to you, but how would you tell everyone else to
route that traffic to them in the first place? Looking at it the other
way, what is it about a "direct from ARIN" block that makes a network
A block from ARIN may appear to be more portable, since it's not carved
out of a larger block, that's irrelevant to your situation, though.
I've been asked variations of your question before, and my answer was
that there are two solutions (humor, not sarcasm intended):
1) Get in your car, drive to every ISP in the world, knock on their
front door and ask permission to log into their edge routers to add
static routes to your network. Some of them may be reluctant to allow
you to do this. You'll also use a lot of gas. Plus you'll have to repeat
the process if you ever change anything, or if any of your links goes down.
2) Run a dynamic routing protocol that allows you to exchange
information with the rest of the world. Right now BGP4 is your only real
option that I know of.
In general, my opinion is that if your Internet connection involves the
terms "cable modem" or DSL, you don't want to be considering
multihoming. If your concern was that you are able to simply access the
Internet (rather than ensure availability of your web server from the
outside world) you may be able to make a NAT solution work nicely with
two external links, though. That does seem to be your main concern here.
Also, consider that adding the complexity of a dynamic routing protocol
(an exterior one, at that!) in many situations will make your network
less reliable, not more, since you've added more equipment requirements,
and more chances for human error to take down your network.
If you are seriously considering the need for multihoming, I'd suggest
grabbing a good book on BGP. I found one from Cisco that was very
informative (but understandably biased to Cisco equipment). That will
provide a good overall picture of how the process would work. Even if
you aren't the one who'd be handling the router config, it's worth
getting at least a high level view.
For your situation, I'd consider something like having the Linux router
run NAT for inside addresses while a process monitors your primary
Internet link. If the link goes down, have the router automatically
switch to using IPs from the secondary link for the public side of the NAT.
This wouldn't help with your Watchguard, though. If your primary link
went down, clients would have to change how they connected. One
possibility would be if you controlled your own DNS (and if the clients
connected by name instead of IP), you could have the same script that
monitors your Internet connection take care of changing the DNS entry to
point to a secondary IP on the Watchguard (from the secondary ISP's IP
Still some issues remain, like changing the default route on the