Re: PF load balance problem

2006-06-01 Thread Alexey E. Suslikov
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

2006-06-01 Thread Diego Linke
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

2006-06-01 Thread Alexey E. Suslikov
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

2006-06-01 Thread Diego Linke
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

2006-06-01 Thread Diego Linke
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

2006-06-01 Thread Diego Linke
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

2006-06-01 Thread Diego Linke
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

2006-06-01 Thread Diego Linke
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



Re: PF load balance problem

2006-05-31 Thread Diego Linke
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