Below is the output on 4.1.28. In this case my statemax is 7000 and you
are right, it was at the default before and it's dumping the active
states when it hits the defined maximum. What is TCP State 10? Is that
TIME_WAIT? My tests in 4.1.28 now eventually have the states clearing
but only after 4 minutes. Maybe before I wasn't patient enough and it's
possible the only trials where I let it go for a long time where with
older versions. If it is just in TIME_WAIT, then is that time setable?
The host is set to only keep it in TIME_WAIT for 60 seconds. Even so,
is there a way to make the (limit X) option in ipf.conf only count
against connections in the ESTABLISHED state or just not include
TIME_WAIT? Otherwise, it's still not really counting X concurrent
connections as much as X connections per TIME_WAIT period? In my case,
we would be getting a lot of connections in quick succession, but I want
to limit the number of connections being made at simultaneously. That
make sense? Thanks for your help.
dr2 ~> ipfstat -s
IP states added:
9002 TCP
1 UDP
0 ICMP
90570 hits
9007 misses
0 bucket full
0 maximum rule references
1 maximum
0 no memory
4690 bkts in use
7000 active
1 expired
2002 closed
State logging enabled
State table bucket statistics:
4690 in use
67% hash efficiency
46.86% bucket usage
0 minimal length
7 maximal length
1.493 average length
TCP Entries per state
0 1 2 3 4 5 6 7 8 9 10 11
0 0 0 0 1 0 0 0 0 0 6999 0
Darren Reed wrote:
Jeff Durand wrote:
...
dr2 ~/ipf> ipfstat -s
IP states added:
...
3 maximum
..
dr2 ~/ipf> ipfstat -s
IP states added:
...
4 maximum
...
The default maximum is only 4013, and your tests show "3924" is
reached....
The only way the above counter gets bumped is when it reaches the maximum
number of entries allowed in the table. What do you think you've
defined the
table maximum to be?
btw, can you please include the output from 4.1.28? It has some extra
information
that I'm curious about...
Thanks,
Darren