IPF 4.1.22

[Hauke Fath]

[Thread re-directed to tech-net list. Please post any replies there.]

4.1.20 is fscked, it goes to 'block all' mode in about a day here.
Not useable.

More information please.
What made it seem like "block all" mode?

From some point of time (reached within a few hours on a working day) all
incoming packets were blocked. In the end, the router itself was flooding
the local DNS servers with requests while at the same time blocking some of
the outgoing packets:

05:59:59.971309 wm0 @131:2 b 130.83.xx.yy,58501 ->
ns1.hrz.tu-darmstadt.de[130.83.22.63],domain PR udp len 20 72 OUT

where group 131 has

# ipfstat -on | grep 131
@2 block out log quick on wm0 all head 131
@1 pass out quick proto tcp from 130.83.xx.yy/32 to any flags S/FSRPAU keep
state keep frags group 131
@2 pass out quick proto udp from 130.83. xx.yy/32 to any keep state keep
frags group 131
@3 pass out quick proto icmp from 130.83. xx.yy/32 to any keep state keep
frags group 131
#

-- note that 131:2 is actually a _pass out_ rule.

Did it stop creating state or what..?

An ipfstat of 4.1.20 (netbsd-4 of May 10th) that I found in the conserver
logfile (uptime 2.5 d):

<snip>
# ipfstat
bad packets: in 0 out 0
IPv6 packets: in 0 out 0
input packets: blocked 567981 passed 97536223 nomatch 0 counted
70502091 short
output packets: blocked 483869756 passed 97529765 nomatch 0 counted
0 short 0
input packets logged: blocked 558599 passed 5547
output packets logged: blocked 483869747 passed 6783
packets logged: input 0 output 0
log failures: input 226145 output 434428672
fragment state(in): kept 1031757 lost 7250059 not fragmented 28334143
fragment state(out): kept 1030550 lost 7256536 not fragmented 28334143
packet state(in): kept 417373 lost 292339
packet state(out): kept 534714 lost 483853624
ICMP replies: 6998 TCP RSTs sent: 53956
Invalid source(in): 0
Result cache hits(in): 29371089 (out): 29016112
IN Pullups succeeded: 56847 failed: 0
OUT Pullups succeeded: 70438 failed: 0
Fastroute successes: 72771 failures: 0
TCP cksum fails(in): 0 (out): 0
IPF Ticks: 423313
Packet log flags set: (0)
none
#
</snip>

An ipfstat of the downgraded system (netbsd-4 of April 20th, uptime 2 d):

<snip>
# ipfstat
bad packets: in 0 out 0
IPv6 packets: in 3115 out 3423
input packets: blocked 117276 passed 159652988 nomatch 3115
counted 67336617 short 0
output packets: blocked 1066 passed 159686377 nomatch 3422 counted
0 short 0
input packets logged: blocked 104999 passed 3902
output packets logged: blocked 839 passed 4460
packets logged: input 0 output 0
log failures: input 7991 output 2509
fragment state(in): kept 725418 lost 4224213 not fragmented 24393974
fragment state(out): kept 723262 lost 4236167 not fragmented 24393974
packet state(in): kept 1222636 lost 19
packet state(out): kept 12535 lost 1032
ICMP replies: 4428 TCP RSTs sent: 40584
Invalid source(in): 0
Result cache hits(in): 21440267 (out): 21417706
IN Pullups succeeded: 4991 failed: 0
OUT Pullups succeeded: 8462 failed: 0
Fastroute successes: 40751 failures: 0
TCP cksum fails(in): 0 (out): 0
IPF Ticks: 339141
Packet log flags set: (0)
none
#
</snip>

The previous version is doing fine, apart from the general problems that
ipfilter versions on the netbsd-4 branch seem to have with stateful NFS
connections, both from Linux 2.6 and NetBSD machines.

The state problem seems to be traffic-related, though. Ipfilter 4.1.20
created no problems so far on my home NAT router, an SS10.

hauke


--
"It's never straight up and down" (DEVO)



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by Hauke Fath
From some point of time (reached within a few hours on a working day) all
incoming packets were blocked. In the end, the router itself was flooding
the local DNS servers with requests while at the same time blocking some of
ns1.hrz.tu-darmstadt.de[130.83.22.63],domain PR udp len 20 72 OUT
where group 131 has
# ipfstat -on | grep 131
@2 block out log quick on wm0 all head 131
@1 pass out quick proto tcp from 130.83.xx.yy/32 to any flags S/FSRPAU keep
state keep frags group 131
@2 pass out quick proto udp from 130.83. xx.yy/32 to any keep state keep
frags group 131
@3 pass out quick proto icmp from 130.83. xx.yy/32 to any keep state keep
frags group 131
#

...

What you really need to look at is "ipfstat -s" and see what it has
for the "maximum" counter. 4.1.22 does improve the situation when
it is time to clean out the state table and make room for new connections.

Darren

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Pavel Cahyna]

Post by Hauke Fath
[Thread re-directed to tech-net list. Please post any replies there.]

4.1.20 is fscked, it goes to 'block all' mode in about a day here.
Not useable.

More information please.
What made it seem like "block all" mode?

From some point of time (reached within a few hours on a working day) all
incoming packets were blocked. In the end, the router itself was flooding
the local DNS servers with requests while at the same time blocking some of

Does ipf 4.1.22 improve the situation?

Pavel

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hauke Fath]

Post by Pavel Cahyna

Post by Hauke Fath
From some point of time (reached within a few hours on a working day) all
incoming packets were blocked. In the end, the router itself was flooding
the local DNS servers with requests while at the same time blocking some of

Does ipf 4.1.22 improve the situation?

I haven't tried, and I won't, for some time, for fear of being roasted on
slow fire by a bunch of users who have long-running simulations killed. I
am in the process of slapping a few old machines together for a staging
setup, though.

hauke

--
"It's never straight up and down" (DEVO)



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de