|
On Fri, 7 Jul 2006, Roberto Nibali wrote:
Are you talking about a setup as described for example in chapter 19 of
this:
http://www116.nortelnetworks.com/docs/bvdoc/alteon/appl_switch/315394-J.00.pdf
looking this up now...
I can't follow the link. I'll have to dig through the site to try and find
it.
Try this one:
http://tinyurl.com/e54yy
I'm reading it now, with the basic approach it looks like it's doing the job,
but since they are load balancing servers as well as firewalls it is looking
very ugly in it's configuration. With this as your introduction to the concept
it's no wonder you find it to be a hack and unreliable.
the four-subnet approach is what I'm talking about, but with the addition of an
additional load balancer on the fourth subnet to do the server load balancing,
so everything else can pretend that there is only a single server.
the whole business with setting the outbound routes is a mess, they use the
free-metric option as an advanced thing, but if I'm reading it right a
four-subnet free-metric config is the simplest of the ones they show (at least
to configure) and probably the most reliable as well.
thanks for sending me this link, it's convinced me to stay well away from the
nortel load balancers (they were questionable in terms of capacity to begin
with)
I am trying to find an option that doesn't have the firewall being a
single point of failure. yes, if these were linux firewalls I could use
heartbeat (linux-ha) to provide failover, but that can't load balance,
and it doesn't work if I use commercial firewalls instead of linux
If you buy a commercial firewall, you will most probably have some sort of
built-in failover.
there are a couple huge advantages of not useing the built-in failover for
commercial firewalls
1. with external boxes you can have firewalls of different types that you
failover/load balance between (avoiding vendor lock-in and you have a much
easier time dealing with major upgrades of a single vendors firewalls)
I don't understand the term "vendor lock-in". The way I sometimes deal with
major upgrades in business critical environments is to have a pilot/test
network setup up as equal to the existing as possible. Then either retransmit
some captured traffic for point-testing or using port-mirroring to test the
upgrade. The upgrade process itself can easily be tested in such a setup.
This works perfect with Raptor/Axent firewalls or Checkpoint or our firewall.
at high bandwidth levels it's really hard to test things properly in a lab. As
such there's a huge sigh of relif when you can put in one of the new ones but
have things configured so that if something goes wrong it fails over to the old
one. this is hard enough to do with a single vendor useing their HA solution (it
frequently breaks across major version upgrades, just when you need it the most)
but people still fall into the 'well, it's just an upgrade of the existing
product, that's less risky then changing to another vendor's product'. with
external load boxes this doesn't matter and you can do major changes with very
little risk (since anything that goes wrong will just put you back where you
started)
Thanks for the interesting discussion and sorry for wasting your time without
giving you a workable solution,
it's never a waste of time to explain the problem in more detail, I attempted to
simplify things that apparently caused more confusion when the intent was to
avoid introducing distractions.
David Lang
|
