Hi Berk,
I'm really intereted in this. I have a load of legacy tcp session
based load balancing with I'd love to migrate to an OpenBSD/pf based
solution. Do you have a patch with applies cleanly to 4.0 ?
/Pete
On 26. okt. 2006, at 22.16, Berk D. Demir wrote:
Pete Vickers wrote:
1) When using sticky-address in the rdr rules client-server
associations are added to the internal Sources table.
It is impossible to remove entries for a single backend from this
table. If a backend fails and is removed from the rdr destination
table this table will have to be flushed, making all clients
end up on
new backends, wich is unacceptable in many configurations.
If this table is not cleared then the rdr destination table is
not
inspected for client IP's found in the Sources table. These
clients
will still be sent to the failed and removed backend.
Preferably entries could be removed from this table based on
source-IP and backend-IP:backend-port, and maybe even the virtual
service IP:port or a pf rule number.
2) TCP sessions to a failed backend will continue to exist after the
backend is removed from the rdr destination table. As of today
these
sessions can be removed with pfctl by specifying the source and
destination IP addresses. Since different services can run on
differerent port numbers on the same machines it should be
possible to
specify a destination port number as well.
I guess that if a backend dies then the client is notified
about this
just as if it had been speaking directly to the backend, so it
might
not be necessary to clean out these sessions at all, and maybe
even
the tcpdrop tool will do the trick?
Anyway, main issue is with removing single sessions from the
internal Sources table (as it is called in pfctl(8)).
I've submitted a patch, adding a new ioctl to pf and an
implementation to clear src-track entries likewise states (-k
1.1.1.1 -k 2.3.5.0/23).
A patched build (smt. between 4.0 and -current) is running in many
DCs in my county right now.
pfctl.c changed after my submission. I have to fix the patches and
post here in case it helps.
It needs to get OKs from developers to get into the tree. Last
touch with a developer about this patch was with dhartmei on Jul 25.
(I'll post it tomorrow)
