First, sorry for my delay in responding...

Second, there are a couple of different concepts being miked together
here....Here are all my collected thoughts...

HIGH AVAILABILITY OF THE GATEWAY

High Availability (vrrp, etc.) would provide for failover amoung two or more
monowall boxes. This would allow one box to take over function for another
box, transparent to the internal network (well mostly transparent - there
would be a short (3 second?) outtage as the new live box arp's take over the
IP address, and the changes propogate to the switches, etc.

To figure out if this would increase or decrease failures, you would have to
know if there was a possibility for a race condition which could CAUSE a
failure when none was occuring. Supposedly the software takes care of that,
so this sort of setup shouldn't be worse. I'd hazard a guess though that
ISP's fail a lot more than appliances like the soekris, so personally I'd
put this lower on the list than Load Balancing or other forms of multiple
upstream provider support.

LOAD BALANCING

Load Balancing has nothing to do with vrrp as far as I know... the loadd as
described seems to be intended for INBOUND load balancing, not outbound.
Would be nice if it could be configured in reverse - my lack of
understanding is how we make a particular path choice STICK for packets that
have to be nat'ed to multiple outbound connections...

I had in the past attempted to configure a bastardized form of load
balancing by configuring two pools of internal users, and routing one pool
through one nat to one external interface while running the second set
through a second interface... not true load balancing, but does have the
advantage of avoiding problems with multiple connections form a single
internal host appearing to come from multiple public addresses (from the
point of view of the remote webserver).

Pool members could be adjusted manually, or eventually dynamically - by
service, or even by remote IP being contacted... Fail over (below) could be
used to combine the pools incase of an upstream failure.

PING TESTS AND FAIL OVER

As for a ping test controlling a default route, I do this now - simple C or
perl script - ping the live gateway, and if it fails, set the default route
to the backup gateway - through an alternate interface... this would be
upstream connection failover, but again doesn't provide for load
balancing... This is the easy one. Certainly willing to trade code and notes
on this with someone - I wrote in PERL, ported to PHP at one point, but
really wanted it in C (but although I occasionally hack on other's C, I am
not a C programmer)...

BGP

BGP is quite simply NOT available to many users. Getting it requires that
you have your own portable address space, or that you have two feeds from
the same carrier (which is hardly redundant), though if agregating your
bandwidth is the goal it has some merit.

BGP also requires more advanced knowlege, and many carriers won't play ball
unless you can demonstrate (through diplomas or courses or real experience)
that you know what you are doing. By misconfiguring you can broadcast bad
routes and screw things up - if their own security is not tight enough the
errors you make can effect more people than you.

STATEFUL FAILOVER

This is trickier - this requires both routers to be aware of instantaneous
connection state of all sockets and datagrams in progress so that the change
over of a router does not impact the connection state of any sessions in
progress - In my humble opinion - COME ON - who needs this - if you really
need this, then spend the money for the big stuff - 99% of real world users
would just be happy if they could get around isp connection failures or
better still ISP routing problems...

Stateful failover has most value when you are connecting to multiple
upstream providers in a BGP scenario anyways - if you are just plugging into
a switch and back to a single ISP, your switch becomes your single point of
failure, so not sure if that helps.



Conclusions:

fvrrpd seems useful for failover between the routers (though not stateful).

ping test and route changes can provide multiple upstream provider failover

grouping rules to choose upstream route based on internal IP or destination
network or service (combined in case of failure) can provide limited load
balancing

But, I hate working on stuff that doesn't have support of the project
maintainer... Manuel - what are your thoughts?

Do you think these things would be good add-ons to monowall? Could they
become part of the package?

Thanks for reading - appreciate corrections and feedback of course ;-)

m/





> -----Original Message-----
> From: Adam Nellemann [mailto:adam at nellemann dot nu]
> Sent: Sunday, February 15, 2004 10:44 AM
> To: m0n0wall at lists dot m0n0 dot ch
> Subject: Re: [m0n0wall] LoadBalancing revisited
>
>
> Hi,
>
> Just spamming... :)
>
> Chad R. Larson wrote:
>
> > the box against the additional complexity.  And remember, if
> you have two
> > firewall boxes, you have twice the chance of a failure.
>
> While I'm no statestician, I'm rather sure that is not true, at least
> strictly speaking!
>
> In this context, "failure" would be both boxes failing
> "simultaneously" (ie. second failure occuring before first one is
> fixed), this is MUCH less likely than a single box failing (at least
> if you aren't too lazy with repairs!)
>
> But then there is, of course, the issue of the watchdog hardware or
> software failing, adding further complexity to the MTBF calculations?
>
> Personally however, I feel that your argument about complexity holds.
> A box like a Soekris running m0n0wall should be quite stable in
> itself. Still, some people need 100% uptime...
>
> Adam.
>
> P.S. I'm not an expert in these matters, but wouldn't the (least
> complex) way of achieving failsafe connectivity be by using two
> m0n0walls on two independent WAN connections, and then configuring the
> hosts with both of them as gateways. While this probably wouldn't
> load-balance, I speculate that it would allow traffic to continue
> through either gateway, should one stop working? (Or perhaps a small
> script could do some ping-testing and switch gateway to the "backup"
> m0n0wall, in case of failure?)
>
>
>
> ---------------------------------------------------------------------
> 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
>
>