Re: PF load balance problem
On Wednesday 31 May 2006 19:03, Diego Linke wrote: Alexey, A network prefix length of 0 can be used as a wildcard. To kill all states with the target ``host2'': # pfctl -k 0.0.0.0/0 -k host2 so why don't you kill all states to dead pool member right after removing it from the lb table? This is not work! The problem is that this command to erase the STATES, however the SOURCE keeps. previously, you have referred to this quote from pfctl.conf(5)) Additionally, the sticky-address option can be specified to help ensure that multiple connections from the same source are mapped to the same redirection address. This option can be used with the random and round- robin pool options. Note that by default these associations are de- stroyed as soon as there are no longer states which refer to them; in or- der to make the mappings last beyond the lifetime of the states, increase the global options with set timeout source-track See STATEFUL TRACKING OPTIONS for more ways to control the source tracking. so I think you broke pfctl -k by explicitly specifying src.track. why do you need src.track?
Re: PF load balance problem
Hi Alexey, so I think you broke pfctl -k by explicitly specifying src.track. why do you need src.track? I have many customers who have applications that they do not share session, and I need src.track to keep more time the same customer in the same serving of what the time of expiration of state. This is very common in load balances, of layer3. Thanks! -- Diego Linke Public Key: http://www.gamk.com.br/gamk.asc
Re: PF load balance problem
On Thursday 01 June 2006 14:15, Diego Linke wrote: Hi Alexey, so I think you broke pfctl -k by explicitly specifying src.track. why do you need src.track? I have many customers who have applications that they do not share session, and I need src.track to keep more time the same customer in the same serving of what the time of expiration of state. This is very common in load balances, of layer3. Thanks! have you tried source-hash option instead of source tracking?
Re: PF load balance problem
Alexey, have you tried source-hash option instead of source tracking? The option source-hash, would not function therefore goes to have problem the same Source expirations. -- Diego Linke Public Key: http://www.gamk.com.br/gamk.asc
Re: PF load balance problem
Alexey, is here do not share session means originate each session from different IP address? Not! The problem is when I erase a server of mine load I balance and it continues sending connection in this server. -- Diego Linke Public Key: http://www.gamk.com.br/gamk.asc
Re: PF load balance problem
Alexey, ok :) assume you have 5 session from given client which originated from one client's IP. assume you specified sticky-address so all 5 session gets redirected to one of lb. correct? it's ok!! when this one of lb is dead, all sessions from given client are dead. so why do you need src.track longer than connections' states exist? Then I need to guarantee that exactly a XXX time after finishes state to exist it the same client continues being redirected for same serving. This because the customer can effect login in the system, to be a time without making nothing (time sucifiente for state to be extinguished) and later reusing the system. PS: This happens with some applications of my customers. Thanks! -- Diego Linke Public Key: http://www.gamk.com.br/gamk.asc
Re: PF load balance problem
Alexey, $ sudo pfctl -sa | grep tcp.established tcp.established 86400s I work with firewalls with high traffic and have that to work with parameters well more aggressive of timeouts. -- Diego Linke Public Key: http://www.gamk.com.br/gamk.asc
Re: PF load balance problem
Alexey, pf is VERY fast on stateful filtering (while searching states). memory is the bottleneck (if number of states is high) but it is VERY easy to deal nowadays: 2x512Mb of DDR RAM costs less than $100. or maybe firewall's CPU is slow?... post dmesg if permitted... -k kills states which you busted manually by src.track. i think you should try less complicated setup without src.track. In this case to keep in the same serving I will have that to leave the values of very great tcp.closing and tcp.closed, keeping in firewall states unnecessary. Thanks!! -- Diego Linke Public Key: http://www.gamk.com.br/gamk.asc
PF load balance problem
Hello Everybody.
I have a small, yet relevant question regarding PF's load balancing
features. Today I run PF with load balacing in substitution for Layer 3
load balancer switches, in two type of scenarios, the very first where
applications share sessions and the other, where sessions are not shared.
My problem is...
Here is my enviroment
Basically the example enviroment is one server with PF and three Web
Servers which do not share their sessions:
table lb { 10.0.0.1, 10.0.0.2, 10.0.0.3 }
rdr on xl0 inet proto tcp from any to IP_PUBLICO port 80 - { lb }
round-robin sticky-address
pass in quick log on xl0 proto tcp from any to lb port 80 flags S/SA
modulate state (src.track 1800)
stick-address option makes PF always redirect a connection to a
server, it creates a entry in the Source table (source-track, which
can be seen with pfctl -vs Source) and while this entry stills alive
it forwards every other request from the same IP address to this same
Web Server. By default, the entry is alive on Source untill the last
state is still alive.
To raise this value we need to set new limit to src.track (set timeout
src.track), I did this through the rule which allows the connection, as
you can see in the mentioned rule.
To make it short, PF will load balance connections among the servers on
lb table, and keep the same server to the same cliente up to 1800
seconds (30 minutes) after the last state was excluded.
My problem starts to happen now:
Everything above mentioned works perfectly, the issue starts when we
have to delete one IP from the load balance table. For example, if
10.0.0.2 server is down, I need to take it out of the balancing table:
pfctl -t lb -T del 10.0.0.2
In this case, technically load balancing will be kept only among the IPs
10.0.0.1 and 10.0.0.3, which are the only ones that still exists in the
lb table. But the problem is, even when the just deleted 10.0.0.2
server is not on lb anymore, clients requests/states which were in
Source before and that pointed 10.0.0.2, will still there, and
therefore redirections to 10.0.0.2 will continue to happen until
src.track expires (30 minutes in the mentioned situation), or when I do
pfctl -F Source. But if I do the second approach, I will flush all my
references and sessions for this and all other source-tracks data in my
firewall.
Possible solutions I see:
The only solution I found was to change PF source code, where we could:
1) Create something similar to pfctl -k used for states, but Source
version of it.
In this case, to delete a server, we would do
pfctl -t lb -T del 10.0.0.2
pfctl -new -flag 10.0.0.2
2) Make sticky-address verify if the IP address is still in the load
balacing options (in this case, if it is on lb table still). This
second approach would (maybe) suffer from performance issues, since we
are adding a new check before stick-address handles the request.
Anyone has any better option?
Does any hacker have available time to do this?
Thank you a lot.
--
Diego Linke
Public Key: http://www.gamk.com.br/gamk.asc
PF load balance problem
Everything above mentioned works perfectly, the issue starts when we have to delete one IP from the load balance table. For example, if 10.0.0.2 server is down, I need to take it out of the balancing table: pfctl -t lb -T del 10.0.0.2 In this case, technically load balancing will be kept only among the IPs 10.0.0.1 and 10.0.0.3, which are the only ones that still exists in the lb table. But the problem is, even when the just deleted 10.0.0.2 server is not on lb anymore, clients requests/states which were in Source before and that pointed 10.0.0.2, will still there, and therefore redirections to 10.0.0.2 will continue to happen until src.track expires (30 minutes in the mentioned situation), or when I do pfctl -F Source. But if I do the second approach, I will flush all my references and sessions for this and all other source-tracks data in my firewall. from pfctl(8): A network prefix length of 0 can be used as a wildcard. To kill all states with the target ``host2'': # pfctl -k 0.0.0.0/0 -k host2 so why don't you kill all states to dead pool member right after removing it from the lb table?
Re: PF load balance problem
Alexey, A network prefix length of 0 can be used as a wildcard. To kill all states with the target ``host2'': # pfctl -k 0.0.0.0/0 -k host2 so why don't you kill all states to dead pool member right after removing it from the lb table? This is not work! The problem is that this command to erase the STATES, however the SOURCE keeps. Thanks -- Diego Linke Public Key: http://www.gamk.com.br/gamk.asc
