-----BEGIN PGP SIGNED MESSAGE-----

there are also dynameic DNS servers (global Dispatch from resonate, 3DNS
from F5 Labs, Global Director from Cisco) that monitor what sites are up
and what sites are down and provide a DNS server that gives different
answers in different cases (combined with a low TTL value). This does
generate a lot of DNS traffic, but DNS is a lot smaller then the web
traffic.

David Lang

 On Tue, 25 Jul 2000, Webmaster wrote:

> Date: Tue, 25 Jul 2000 14:23:04 -0500
> From: Webmaster <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: Another option to Round Robin?
> 
> To All so far,
> From all the preliminary inputs, it looks like we'll end up fielding some
> of-the-shelf solution that will monitor and redirect the packets.  But I'm
> still open for suggestions.
> Michae Sorbera
> 
> 
> 
> ----- Original Message -----
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, July 25, 2000 2:01 PM
> Subject: Re: Another option to Round Robin?
> 
> 
> >
> >
> > On 07/25/2000 at 16:36:25 ZE2, "Volker Tanger"
> > <[EMAIL PROTECTED]> wrote:
> > > Assumptions:
> > >     MainWeb Server        1.1.1.1
> > >     BackupWeb Server    2.2.2.2  (plus secondary IP address 1.1.1.1)
> > >
> > > Following options - plus a bunch of even more weird:
> > >
> > > 1.) ISP-sided routing.
> > >     This will have to be implemented on your ISPs side and the routes
> > > properly
> > > distributed. You will
> > >     have automagic failover wether the server or the link goes down.
> > >         route 1.1.1.1  (via main site)  metric=1
> > >         route 1.1.1.1  2.2.2.2  metric=5
> > >
> > > 2.) Load-Balancer  (I)
> > >     You place a load balancer in front of the main web server. If the
> > main
> > > web
> > > server goes down,
> > >     it sends ICMP-redirects, redirecting the packets to the Backup Web
> > > Server.
> > > This won't help
> > >     if the link goes down.
> > >
> > > 3.) Load-Balancer  (II)
> > >     You place a load balancer in front of the main web server. If the
> > main
> > > web server goes down,
> > >     it re-sends the packet with IP loose source routing via 2.2.2.2 back
> > >     to the uplink router.
> > >     This won't help if the link goes down.
> > >
> > > 4.) VPN / Tunneling
> > >     If you don not have access to ISP sided routing, then create
> > > aVPN/tunnel
> > > between the two routers
> > >     in front of the web servers. You set the following routes on the
> > > routers:
> > >         Main site router:
> > >             route 1.1.1.1  connected  metric=1
> > >             route 1.1.1.1  (via VPN to backup site)  metric=5
> > >
> > >         Backup site router:
> > >             route 1.1.1.1  2.2.2.2  metric=1
> > >
> > >     But this won't help if the link goes down.
> >
> > Some clever and new (at least to me) ideas here, but I question whether
> any
> > of options 1-3 would work in the real world (I have no idea about option
> > 4).
> >
> > Option 1 can only work if the redirector (the router with the secondary
> > route to the backup address) is adjacent to the backup machine or if all
> > routers on the path to the backup have routes pointing to the correct next
> > hop (not to the target backup address - that's not the way routing works).
> >
> > Option 2, ICMP redirects.  No way.  First, a redirect means take another
> > route, it doesn't mean go to another destination.  Second, the redirect
> > must be sent all the way back to the originator (the client), but ICMP
> will
> > not reach many clients as it is filtered by many sites.  Third, sending a
> > redirect still requires you to forward the packet to the correct
> > destination.
> >
> > Option 3 - loose source routing is not obeyed in many parts of the
> > Internet.  It may even be filtered by some.
> >
> > So, please let us know which of these you have successfully implemented.
> >
> > Tony Rall
> >
> >
> > -
> > [To unsubscribe, send mail to [EMAIL PROTECTED] with
> > "unsubscribe firewalls" in the body of the message.]
> 
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
> 

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.2

iQEVAwUBOX3zyT7msCGEppcbAQGGVAf/fj0DBLmDiOvoYaoQeFZbKjJTNsMuwdjV
JbpxZFxUnv7sZXGDAk5HlfdOrfXZ0ITJHhYPbAjyIlXwfBzz7QESvZ0jsxrknSDE
b/JY7W3VcgTXoZqFW/aUbZwmp/z0IHfPyQG604vDJwOJ/oanLSlERN7ioO9n+vCA
6gIRP8yg7UDHBP0LZhzVGGZjjzlma/S6bT7qNQsEjt2HbZbj+zxOb2Opd77nQGk2
Yrvq8pMkH6ZFBfbfpGc8q3ITyhyONlixnwUqXcsjb4QuG1xdj1FedLYPi57QW9dK
vSr3I5iBYAi1ZBpEABFgZT2Ji9YfMdItKFxgXvSiJqt0MgkvrvqGMw==
=yQYG
-----END PGP SIGNATURE-----
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]

Reply via email to