Cedric Berger ([EMAIL PROTECTED]) wrote:Ok, I'm 99% convinced this has nothing to do with PF.
Here is the problem I think: 40MB of kernel memory for routing table entries...Whenever I notice a new IP address that needs my attention. Unfortunately
It might be PF table stuff..., not sure yet.
Do you reload your "ban" table very often?
this can often be several times in an evening.
[...]At the time I sent my last e-mail, the box had been up approximately two weeks, so I figured I'd upgrade CVS before rebooting it. I did that, and now my 3.5-beta -current box has been up 22 hours. "netstat -rn | wc" shows 79 lines. Here's the top section (before the IPv6 stuff, which I don't use, as far as I know).
=======================================================================
Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 209.142.155.254 UGS 470 4603644 1492 tun0
12.169.2.37 209.142.155.254 UGHD 0 4600038 1492 L tun0
24.57.88.139 209.142.155.254 UGHD 1 4603283 1492 L tun0
24.204.73.174 209.142.155.254 UGHD 0 4602201 1492 L tun0
62.34.2.173 209.142.155.254 UGHD 1 4575857 1492 L tun0
62.49.7.13 209.142.155.254 UGHD 1 4586241 1492 L tun0
62.174.241.107 209.142.155.254 UGHD 1 4595161 1492 L tun0
62.234.101.184 209.142.155.254 UGHD 1 4594391 1492 L tun0
If the routing table really does grow every time some spammer or P2PWe're looking at the problem, but there is very likely a bug related to PMTU here.
user connects to me from the Internet, and never gets pruned, then
this resembles a denial of service attack. :-/ But I have a hard time
believing I'd be the only person seeing such a problem.
You can probably workaround the problem by turning PMTU off with sysctl:
vm34c# grep mtu sysctl.conf #net.inet.ip.mtudisc=0 # 0=disable tcp mtu discovery
I don't know if that is possible for you, though. Cedric
