On 5/26/06 8:01 AM, "Jeff A. Earickson" <[EMAIL PROTECTED]> wrote:

> I think Peter was talking about version 4.x output of "ipfstat -s".
> Yours is version 3.x output, version 4.1.x output looks like so:
> 
> # ipfstat -s
> IP states added:
>        1999185 TCP
>        5877243 UDP
>        28912 ICMP
>        2026447415 hits
>        8408737 misses
>        0 maximum        <== What Peter mentioned, right?
>        0 no memory
>        1783 bkts in use
>        2621 active
>        5906064 expired
>        1996655 closed
> State logging enabled
> 
> State table bucket statistics:
>        1783 in use
>        31.08% bucket usage
>        0 minimal length
>        10 maximal length
>        1.470 average length
> 
> The differences are doubling confusing...  This topic does deserve
> an FAQ entry and maybe an EXAMPLE section in the ipfstat manpage.
> Thanks for your reply Peter.

I'd agree about the FAQ bit.  As I was learning this in the heat of a
production fire (lots of people not happy) I simple dropped keeping state
for our product connections.  It seemed to be a crude solution but a
solution.

I really wish I had more time to collect stats and tinker with buffer
settings.  In my config, the firewall is the only system that can see
universally what is happening and the state table used to be my divine
source for all goodness.

viper# uname -a
NetBSD viper 3.0_STABLE NetBSD 3.0_STABLE (PETER-GW) #19: Wed Mar  8
20:00:50 CST 2006  
[EMAIL 
PROTECTED]:/builds/netbsd-3/i386/obj/builds/netbsd-3/src/sys/arch/i386/com
pile/PETER-GW i386
viper# ipfstat -s
IP states added:
        4455303 TCP
        2700249 UDP
        21073 ICMP
        688690488 hits
        2407181353 misses
        217110 maximum
        0 no memory
        99022 max bucket
        217110 maximum
        0 no memory
        102 bkts in use
        105 active
        0 expired
        127888 closed
State logging enabled

State table bucket statistics:
        102 in use 
        1.78% bucket usage
        0 minimal length
        2 maximal length
        1.029 average length

viper# uptime
 8:50AM  up 74 days, 16:56, 2 users, load averages: 0.17, 0.14, 0.11
viper# 

I would have loved to associated each of the 217110 events to a log file
entry noting the subsequent packets for the session as blocked.  Management
advises me against experimenting with out products, sigh.

I probably can build a lab though and generate >6000 sessions but I'm
currently preoccupied with a few personal activities (aka remodeling the
home).

peter





Reply via email to