You could, yes. In fact, you could write a script that does more than simply
ping the host, but attempts to create a connection itself on the destination
port, and then simply disconnects if it goes through. Then using the
success/fail return from that script, you modify the RR rules. It's not a
true high availability solution, but it's a lot closer to one than if you
simply blindly did RR.

----- Original Message ----- 
From: "Christian Nyegaard" <christian at nyegaard dot net>
To: "'Eric Shorkey'" <eshorkey at commonpointservices dot com>
Cc: <m0n0wall at lists dot m0n0 dot ch>
Sent: Saturday, May 29, 2004 4:00 AM
Subject: RE: [m0n0wall] Load Balancing Again...


> This is a bit over my head to be perfectly honest, but wouldn't it be
> Relativly simple to write a bash or perl or whatever suits your
bowlingball
> bag
> Script that'll ping hosts 192.168.1.30, .31, .32 etc and if one of them
> doesn't
> Reply as intended, modify the RR rule in the ruleset ?
>
> Seems to me this would help on the "what if one of the boxes goes down"
> scenario.
>
> As said in the beginning, this is over my head and out of my league but
I'm
> a huge
> Fan of people in my field suggesting things to me that may or may not be
> based on
> True knowledge or competence but simply something that seems like a
> worthwhile idea
> Or at least a suggestion.. :-]
>
> Mvh.,
> Christian Nyegaard mailto:christian at nyegaard dot net
>
>
> > -----Original Message-----
> > From: Eric Shorkey [mailto:eshorkey at commonpointservices dot com]
> > Sent: 29. mai 2004 04:25
> > To: David Rodgers
> > Cc: Mark Spieth; m0n0wall at lists dot m0n0 dot ch
> > Subject: Re: [m0n0wall] Load Balancing Again...
> >
> > Well, I'll have to give you this much. A very basic RR load
> > balancer is better than nothing at all. I would never use it,
> > and I don't believe that it is really worth the effort of
> > m0n0wall's primary developers to waste their time on it. But
> > there seems to be some measure of a demand for it. If they
> > do, great. If not, oh well. Either way it doesn't affect my
> > use of m0n0wall.
> >
> > You're probably quite right on the processing power of a
> > soekris. They are pretty weak compared to today's average
> > computer. But they have a very specific market they are
> > catering to. These little guys would be pretty good for a
> > load balancer though.
> > http://www.tigerdirect.com/applications/SearchTools/item-detai
> > ls.asp?EdpNo=146907&Sku=S452-1001
> > It's not a soekris, but I don't believe that any project
> > should limit itself just because a certain hardware platform
> > can't push the bits fast enough to keep up. And at $30, you
> > really can't complain.
> >
> > And actually, Alteons do a surprisingly good job at
> > performing image host redirection, you just have to know how
> > to configure them correctly. If you've had problems with
> > Alteons screwing this relatively basic task up, then whoever
> > configured it screwed it up.
> >
> > Round robin dns does do a pretty poor job of distributing connections.
> > Mainly because the result gets cached by some isp's name
> > servers and suddenly everyone from that isp is using the same
> > server. If it's a big isp, then one server is going to get
> > hit a lot more than the others. Performing rr on the
> > connection level as you're pushing for would, indeed, be a
> > large improvement over this. As I'm sure you've noticed by
> > now, I'm more inclined to use a high availability balancer,
> > but that doesn't necessarily mean that's the best way in any
> > given situation. I just prefer the high availability
> > balancers because you can always dumb down their actions do
> > that it performs as a simple rr balancer if the situation
> > calls for it.
> >
> > Thanks for the tip on Cacti. I checked it out and was thus
> > far very impressed. So far I've been using shell scripts to
> > snmp poll my systems, and it's a pain in the rear to add new
> > ones. Cacti should make life a lot easier in that respect.
> >
> > ----- Original Message -----
> > From: "David Rodgers" <david dot rodgers at kdsi dot net>
> > To: "Eric Shorkey" <eshorkey at commonpointservices dot com>
> > Cc: "Mark Spieth" <mspieth at neod dot net>; <m0n0wall at lists dot m0n0 dot ch>
> > Sent: Friday, May 28, 2004 9:26 PM
> > Subject: Re: [m0n0wall] Load Balancing Again...
> >
> >
> > > On Fri, 2004-05-28 at 19:35, Eric Shorkey wrote:
> > > > Seems like a nice idea, but I don't think you realize how
> > much work it
> > takes
> > > > to make a truly useful load balancer. You want more of a
> > proxy than a
> > simple
> > > > ipf rule. The reason being, load balancing is nice, but
> > load balancing
> > with
> > > > high availability is much more useful.
> > >
> > > Yes but load balancing with high availability isn't what is
> > being asked
> > > for. It would be nice but a simple rr load balancing is
> > much better than
> > > nothing.
> > >
> > > >  If one of your pop3 daemons dies and
> > > > is no longer accepting connections on port 110, then
> > you'd want your
> > load
> > > > balancer to notice this when a new guest tries to connect, and
> > automatically
> > > > try another server. Guests that are already connected are
> > out of luck.
> > (Too
> > > > bad, so sad.) But new SYNs shouldn't be allowed to come
> > back with an
> > RSET
> > > > unless all of the servers are down. To implement this,
> > you'll want a
> > more
> > > > sofisticated traffic proxy. Something that holds the
> > connection's hand
> > until
> > > > it finds a live host, and then it can fall back on the simple ipf
> > ruleset to
> > > > keep the packets going to the same host.
> > >
> > > Point taken ..... the problem (as so many people on the
> > list pointed out
> > > before) is a real proxy type load balancer might end up
> > taking much more
> > > cpu that the fastest soekris could provide.
> > >
> > > > Even then, this is still a pretty basic load balancer.
> > When you stop
> > talking
> > > > about pop3 and start talking about http, things gets
> > different. Real
> > > > different. For example, a lot of web providers like to have image
> > servers
> > > > separate from the script running servers, purely to keep
> > the load down
> > on
> > > > the busy scripting servers.
> > >
> > > This is definitely the exception rather than the rule.
> > >
> > > > This means you have to start examining the
> > > > application layer (ie truly proxying) to see what object
> > the browser is
> > > > trying to retrieve, and then redirect it to a server
> > within a server
> > group
> > > > that is responsible for serving that object.
> > >
> > > even most expensive load balancers like localdirector or an
> > alteon don't
> > > accomplish this well.
> > >
> > > >  I would really love to see a
> > > > m0n0wall style load balancer, but I believe that this is
> > a whole new
> > project
> > > > all together.
> > > > You'd be surprised how much of a beating load balancers take
> > > > when you bring http to the table. I don't think you could
> > really expect
> > a
> > > > system to perform both stateful packet inspection with
> > over 100 rules
> > AND be
> > > > an effective load balancer at the same time.
> > >
> > > Agreed that a full on load balancer is better as a seperate
> > device but
> > > even load asside a simple round robin inbound nat is THE
> > BEST solution
> > > for a load balancer built into a firewall because you would NOT want
> > > ports on your firewall open to the public with a daemon
> > listening even
> > > if it is just to establish a connection and be proxied.
> > >
> > > My interest in this service isn't to provide high
> > availability at all
> > > but to provide a simple solution to divide load across
> > multiple servers
> > > that would distribute connections better than rrdns
> > >
> > > > Oh, and since you use mrtg, I highly suggest looking into
> > rrdtool if you
> > > > haven't already done so. Same purpose as mrtg, but you
> > don't have to
> > babysit
> > > > the data store to prevent it from growing too large. I
> > use rrdtool here,
> > and
> > > > haven't looked back to mrtg yet.
> > >
> > > RRDTool rocks and there are many good front ends to it like cacti
> > > http://www.raxnet.net that make it a joy to work with. My
> > technicians
> > > can now add/delete/manage their own devices withought shell
> > access to
> > > any of my devices.
> > >
> > > David
> > > >
> > > > -Eric
> > > >
> > > > ----- Original Message ----- 
> > > > From: "David Rodgers" <david dot rodgers at kdsi dot net>
> > > > To: "Mark Spieth" <mspieth at neod dot net>
> > > > Cc: <m0n0wall at lists dot m0n0 dot ch>
> > > > Sent: Friday, May 28, 2004 7:47 PM
> > > > Subject: Re: [m0n0wall] Load Balancing Again...
> > > >
> > > >
> > > > > After my little incident last week it's pretty much a
> > no brainer that
> > I
> > > > > think this is a great idea as well. Especially if it's
> > that simple.
> > > > >
> > > > > David
> > > > >
> > > > >
> > > > > On Fri, 2004-05-28 at 17:23, Mark Spieth wrote:
> > > > > > The subject of load balancing inbound nat connections
> > to several
> > boxes..
> > > > > >
> > > > > >
> > > > > > eg. 1 external IP that round robins traffic to 2
> > internal hosts...
> > > > > >
> > > > > > Has been brought up quite a few times.. Now, I am a
> > openbsd and
> > linux
> > > > > > person, and my monowall development box is current;y
> > down so I had
> > no
> > > > > > way to look into this, However it seems to me that
> > freebsd (ipf)
> > allows
> > > > > > for the round-robin flag which allows you to setup 2
> > or more rules
> > to
> > > > > > round robin inbound connections to various machines..
> > See Below from
> > my
> > > > > > openbsd box
> > > > > >
> > > > > > rdr ng0 0.0.0.0/0 port 110 -> 192.168.2.29 port 110
> > tcp round-robin
> > > > > > rdr ng0 0.0.0.0/0 port 110 -> 192.168.2.30 port 110
> > tcp round-robin
> > > > > > rdr ng0 0.0.0.0/0 port 110 -> 192.168.2.31 port 110
> > tcp round-robin
> > > > > >
> > > > > >
> > > > > > This seems to balance things out fairly well. In may
> > case if you
> > look at
> > > > > > my mrtg stats on the site below for pop3 it does a
> > decient job of
> > > > > > balancing traffic between the servers.
> > > > > >
> > > > > > http://sm1.neod.net/
> > > > > >
> > > > > > Of course this does not take into consideration
> > individual server
> > load
> > > > > > of if the server is even up, But it should be an easy thing to
> > implement
> > > > > > into monowall.
> > > > > >
> > > > > > Just my .02
> > > > > >
> > > > > >
> > > > >
> > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> > > > > > For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> > > > > For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> > > > For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> > > >
> > > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> > For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>
>