Hi List,
i found a workaround for my sticky problem:
increasing the value for
timeout interval
from 10 to 36000 sec.
Now the src.track entries for my route to rules will live til the interval of
10 h. The normal state-table would explode with a interval of 10h, so i clean
it with a cron-job. I use
pfctl -s state -vv | grep -A3 -e "FIN_WAIT_2" -e "TIME_WAIT:TIME_WAIT" \
-e "CLOSING" -e "CLOSED" -e "NO_TRAFFIC:SINGLE" -e "SINGLE:NO_TRAFFIC" \
-e "^all icmp .*0:0$" -e "^all udp.*:53.*MULTIPLE:SINGLE$" \
-e "^all ipv6-icmp.*0:0$"
to find the relevant states. Do you think this is ok ? states missing or some
states to much ?
If anybody knows a better solution than this dirty thing above please post it.
Martin
> Sorry, i forgot to mention my version 5.4
>
> Hello,
>
> i try to set up a load balancing machine for internal use. We have 2
> webservers serving a web-app. This application depends on sticky clients,
> because it is using sessions w/o session replication. I try to set up a dsr
> environment, which is working perfectly at first glance.
>
> I set the
>
> set timeout src.track 3600
>
> in my pf.conf, but the source tracking entries in pf only shows with:
>
> 10.66.66.2 route-to 10.243.10.4 ( states 0, connections 0, rate 0.0/0s )
> age 00:00:01, expires in 00:00:00, 0 pkts, 0 bytes, rule 0
>
> It expires with the next "timeout interval" which is 10s (default).
>
> This ends in a stickyness of my clients only while their tcp-connection is
> alive + (max 10s).
>
> Is there a way to increase this by relayd.conf or by setting magic timeouts
> in pf.conf?
>
> my pf.conf:
>
> set limit states 100000
> set skip on lo
> set timeout src.track 3600
> anchor "relayd/*"
> pass in
> pass out
>
> my relayd.conf:
>
> table <web> { 10.243.10.4 10.243.11.4 }
> redirect nagios {
> listen on 10.244.2.199 port 80
> sticky-address
> session timeout 3600
> route to <web> mode least-states check tcp interface vlan243
> }
>
> This is a loadbalancing only set up. So we do not need the security of pf in
> this case. We also need the dsr, because the routing from the server to the
> client is asynchronous or in some cases the clients are on the same local
> network like the balanced servers.
>
> Greets
>
> Martin
