Tomasz,
Ok, the information you gave is REALLY helpful. I don't have near as many
nat or filter rules and we do have similar traffic patterns. I'll try
compiling without LARGE_NAT defined and see how it functions. I'll admit
that I may have 'over-sized' the configuration, but I figured it would be
easier to scale back then it would be to scale up.
I did run into a problem when I set FIVE_DAYS to 4 hours. DNS queries were
timing out and I thought that it might have been related to the state
tables. I rebooted the box and DNS worked again, so I dropped the
net.inet.ipf.fr_tcpidletimeout to 7200, as well as several other
net.inet.ipf settings. I haven't had the problem since.
Here is some output from the commands that I have been using to monitor my
box.
#ipnat -s
mapped in 148113831 out 131595787
added 9421197 expired 9416724
no memory 0 bad nat 7045
inuse 4473
rules 261
wilds 0
#ifpstat
IPv6 packets: in 0 out 0
input packets: blocked 5974413 passed 559087610 nomatch 0 counted 0
short 0
output packets: blocked 613 passed 279566564 nomatch 0 counted 0
short 0
input packets logged: blocked 3663591 passed 10052086
output packets logged: blocked 613 passed 300
packets logged: input 0 output 0
log failures: input 548071 output 37
fragment state(in): kept 0 lost 0
fragment state(out): kept 0 lost 0
packet state(in): kept 10051188 lost 878
packet state(out): kept 300 lost 0
ICMP replies: 0 TCP RSTs sent: 5527
Invalid source(in): 0
Result cache hits(in): 66829 (out): 321
IN Pullups succeeded: 0 failed: 0
OUT Pullups succeeded: 0 failed: 0
Fastroute successes: 5527 failures: 0
TCP cksum fails(in): 0 (out): 0
Packet log flags set: (0)
none
#ipfstat -s
IP states added:
9357303 TCP
608702 UDP
87641 ICMP
1650046913 hits
16035798 misses
150 maximum
0 no memory
2605 bkts in use
3042 active
696326 expired
9354278 closed
#netstat -m
204/432/32768 mbufs in use (current/peak/max):
203 mbufs allocated to data
1 mbufs allocated to packet headers
201/374/8192 mbuf clusters in use (current/peak/max)
856 Kbytes allocated to network (3% of mb_map in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
This is after 5 days of uptime. Would you be willing to share the output
from your box? Just to fill in some gaps, I'm running version 3.4.31 on a
PIII, 256 MB RAM, 100MB FD internal/external connections using FreeBSD 4.5.
Our connection to the 'Net is 6MB. Right now only ipf is running on the
box.
-jwb
-----Original Message-----
From: Tomasz Baranowski [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 13, 2003 7:57 PM
To: [EMAIL PROTECTED]
Subject: Re: IPNAT Age vs. IPFILTER Age
James,
I think LARGE_NAT is for *really* large NAT. The comment in ip_nat.h
says about "thousands of networks". Maybe you don't need it? My network
is comparable to yours (800+ users for now). My setup is quite
complicated: I have almost 2000 rdr/map rules, over 4000 filter rules, I
use DUMMYNET for bandwidth limiting and IPFIREWALL_FORWARD for
source-based routing (I know mixing ipfw with ipfilter is not
recommended, but it works for me), I run oidentd server with NAT
support, and I log every outgoing connection. The users run mostly p2p
and chat software and games, and all this works without LARGE_NAT. I
only increased NAT and state tables, and decreased FIVE_DAYS to 4 hours.
Greetings,
Tomasz
--------------r-e-k-l-a-m-a-----------------
Tanie bilety lotnicze!
http://samoloty.onet.pl
