carp and dead daemon

[Emmanuel Dreyfus]

Hello

CARP is nice for load ballancing firewalls, but for servers, there is a
small concern: if a daemon dies, the machine still answers ARP on the
shared address, but it will refuse service requests.

Is there an efficient way to automatically shutdown carp interfaces when
a daemon dies or a TCP port quits the LISTEN state? I mean without
polling the service. It seems kqueue can give the info, but is there a
tool for using it?

[matthew sporleder]

Post by Emmanuel Dreyfus
Hello
CARP is nice for load ballancing firewalls, but for servers, there is a
small concern: if a daemon dies, the machine still answers ARP on the
shared address, but it will refuse service requests.
Is there an efficient way to automatically shutdown carp interfaces when
a daemon dies or a TCP port quits the LISTEN state? I mean without
polling the service. It seems kqueue can give the info, but is there a
tool for using it?

Have you considered using something like pen (pkgsrc /net/pen) for
your services instead?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Emmanuel Dreyfus]

Post by matthew sporleder
Have you considered using something like pen (pkgsrc /net/pen) for
your services instead?

If the service is SMTP, then having the real sender IP (and not pen load
balancer's one) is important for spam filtering,

And how does that cope with SSL?

[matthew sporleder]

Post by Emmanuel Dreyfus

Post by matthew sporleder
Have you considered using something like pen (pkgsrc /net/pen) for
your services instead?

If the service is SMTP, then having the real sender IP (and not pen load
balancer's one) is important for spam filtering,

This is a common problem with load balancers and proxies (I've used
many in front-of web apps where we had to insert custom X-Forward
headers and other hacks -- I'm not sure if pen can do this), but I
thought most spam filters used smtp headers? I don't run any of my
own email servers, though.

Post by Emmanuel Dreyfus
And how does that cope with SSL?

I don't think it tries to read into the protocols at all. HTTPS is
enabled with host1:443 host2:443, so it should just pass it along.

I should also point out that you're really just trading one
application for another since pen could fail and CARP wouldn't notice.
I would love to see port-level monitoring/kernel-module load
balancing built into NetBSD. :)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Emmanuel Dreyfus]

Post by matthew sporleder
This is a common problem with load balancers and proxies (I've used
many in front-of web apps where we had to insert custom X-Forward
headers and other hacks -- I'm not sure if pen can do this), but I
thought most spam filters used smtp headers? I don't run any of my
own email servers, though.

greylisting happens before you get the headers.

Post by matthew sporleder
I should also point out that you're really just trading one
application for another since pen could fail and CARP wouldn't notice.

pen itself can be ballanced using carp. Their web site give example
using vrrp on Linux.

Post by matthew sporleder
I would love to see port-level monitoring/kernel-module load
balancing built into NetBSD. :)

I wonder if kqueue is not already able to do give the information.

[Thor Lancelot Simon]

Post by matthew sporleder

Post by Emmanuel Dreyfus

Post by matthew sporleder
Have you considered using something like pen (pkgsrc /net/pen) for
your services instead?

If the service is SMTP, then having the real sender IP (and not pen load
balancer's one) is important for spam filtering,

This is a common problem with load balancers and proxies

Only ones which suck. Load balancers which don't suck can proxy connections
at the application layer _without_ changing the source IP address seen by
the ultimate server.

(Disclosure: I work for one of the several load balancer vendors whose
products do not suck, at least not this way.)

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de