Re: High Speed Firewalls

[Mike Barkett <mbarkett () digex net>]

On Fri, 3 Mar 2000, Bennett Todd wrote:

BT>Date: Fri, 3 Mar 2000 17:54:05 -0500
BT>From: Bennett Todd <bet () rahul net>
BT>To: "Woeltje, Donald" <dwoeltje () sebh org>
BT>Cc: 'Rick Murphy' <rmurphy () mitretek org>,
BT>     "'firewall-wizards () nfr net'" <firewall-wizards () nfr net>
BT>Subject: Re: High Speed Firewalls
BT>
BT>As far as I know, the Cisco LocalDirector remains unique among load
BT>balancers in the basic way it works.
BT>
BT>It dispatches incoming requests to servers in the farm, and keeps
BT>a notepad to make the assignments "sticky"; so far they're all the
BT>same. But LocalDirector keeps track of how quickly each server in
BT>the farm responds to a request, and always assigns the next new
BT>connection to the server who responded fastest. This allows it to
BT>automatically drop failed boxes out of the pool, and re-introduce
BT>them when they're brought back (HA failover); again, all the
BT>load balancers should be able to do that. But LocalDirector also

Sorry, in my opinion, this "feature" is a bug, when put into practice.  
Imagine the scenario in which a web server has failed, and a 404 error
comes up for the main page.  This server will be much quicker to respond
than the full e-commerce/img/java-encrusted blicki.  LD starts sending
more and more requests to the failed server, and you've got a bad
situation on your hands.  I have seen it happen in extremely high-volume
e-commerce environments and it's not pretty.

Hopefully Cisco has fixed or will fix this problem, but even if they did,
the LD would not be the superior product.  You can set the Alteons to
expect a certain string of HTML code, and regularly monitor that type
connection at layer 4.  Now, that doesn't entirely make up for Alteon's
lackluster NAT support, but that type of monitoring is where Cisco wants
to be with their product.

-MAB