Hi,
Bradley Dunn wrote:
The problem is both ISPs are small and have /24s from their providers. The
/24s would be filtered by many, leading to only partial connectivity in
the case of failure. (Partial connectivity is better than no connectivity,
I guess...)
What I would advocate here - though it is probably less feasible in
the North American context - is application level multihoming. For
mail, backup MX'es for inbound, and smarthosts for outbound. For
Web access, if the ISP operates a proxy cache for its customers, the
customers' actual IP address becomes irrelevant. There has been some
discussion in the Squid users' mailing list about this, and we
(the Squid contributors) are looking into means and ways of making
upstream switchover more transparent.
Granted, running caches in our part of the world (across the Pacific
from MAE-West) is a must for reasonable performance at reasonable
cost.
Cheers,
What I would advocate here - though it is probably less feasible in
the North American context - is application level multihoming. For
mail, backup MX'es for inbound, and smarthosts for outbound. For
Web access, if the ISP operates a proxy cache for its customers, the
customers' actual IP address becomes irrelevant. There has been some
discussion in the Squid users' mailing list about this, and we
(the Squid contributors) are looking into means and ways of making
upstream switchover more transparent.
And I would have the web servers addressed with overlays, using DNS to
switch between ISP addresses.
Another point; application level switching allows the routes to be
pre-established, leading to less delay, less route flapping, and better
maintenance.
Granted, running caches in our part of the world (across the Pacific
from MAE-West) is a must for reasonable performance at reasonable
cost.
Even with HTTP 1.1, caches and mirrors are good performance enhancements
because no one point is close to every other point on the Net.
--Kent