[ previous ] [ next ] [ threads ]
 
 From:  "Mitch \(WebCob\)" <mitch at webcob dot com>
 To:  "Chris Dionissopoulos" <dionch at freemail dot gr>, m0n0wall at lists dot m0n0 dot ch
 Subject:  RE: [m0n0wall] Load Balance & Failover Support in m0n0wall
 Date:  Sat, 17 Apr 2004 14:18:35 -0700
> -----Original Message-----
> From: Chris Dionissopoulos [mailto:dionch at freemail dot gr]
> Subject: [m0n0wall] Load Balance & Failover Support in m0n0wall
>
> I think it would be easy to patch a freebsd 4.x with
> this  carp.diff (http://pf4freebsd.love2party.net/DF_carp.diff)
> to enable CARP support.
>

So try it and let us know ;-) - they say "Might work on 4.x" - which
certainly isn't the same as does work... and there could be other issues to
get pf to work assuming the port works on a 4.x box

A LOT of people on the list seem to have expressed an interest in failover -
the old freeBSD way is not stateful (i.e. kills off all active connections
during the failover) whereas this system (pf & carp) maintains that state
information for "enterprise" class failover... nice - but give it a shot and
let everyone know if the patches work...

> Secondly we have to wait for ipfilter-4 to
> implement a new tool for syncronizing states (nat+filter)
> between firewalls, just because "ipfs" is useless for such
> a work (it just dumps all states while locking the firewall),
> or we can fork monowall-1.0 to a new develompent tree
> based on freebsd5.x  and pf in replacement of ipfilter.
>
> what do you think ?
>

My understanding is that there are issues with the 5.x series (reliability,
etc.) that prevent Manuel from moving that way. When those issues are
resolved, it might be easier - rather than back-porting the pf & carp to 4.x
assuming it's possible... then there is also the issue of replacing ipfilter
with pf - they do the same job - roughly - right?

Might be a good idea to pose Manuel the question (in case he's not reading
the thread) and ask about the relative pros and cons of doing so...
Depending on how different the two systems are, it might just be a minor
change in the rule generation code to support an alternate packet filter.
Personally I don't like branching - I like everyone swimming in the same
direction in the core code... there WAS a recent addition for "plug in"
support, which could provide an easy way to develop a carp config
maintenance page without hacking the core mono code repeatedly until it is
adopted (assuming it is)...

Manuel? What do you think?

Thanks.

m/