We are having a strange intermittent problem on a natting firewall that's been loyally serving us for years, and the current theory is that our recent major connection upgrade (to 16/7 mbit, from about 7/1) plus the switch to voip phones, is periodically bogging down the machine, which is a little long in the tooth - a pIII-500. Symptom: seemingly randomly, up to a few times a day, the network connection just chokes for about 30 seconds. Pings and DNS still work ok, but http traffic and seemingly anything else TCP just stops. Wait a few seconds, and it starts again, processing the pending requests (i.e. the web page you were waiting for suddenly loads, without hitting refresh again) but playing havoc with voip phone calls. The behaviour seems to correlate with the network being busy, but generally the machine can handle throughput saturation with no problem, and does so regularly. My friend suggested a stress-test: making a vpn (pptp) to his network, and seeing if that makes the nat firewall box act up. Sure enough - make the connection, and start copying a file (at a very low throughput like 50 kB/s) and load the network a little bit, and it freezes. And when the vpn connection is active, even without doing anything, stuff starts getting weird - the machine sometimes stops accepting incoming connections on port 22, and logmein.com sessions in progress will fail. But through all of this the machine shows no load, and the tc in place (wondershaper, modified slightly to prioritize traffic to and from the remote voip server - I can post the script and tc output if it would be useful) show no unusual amounts of packet droppage - which makes sense, since the issue isn't a bandwidth overload. How can I get stats on the "health" or load or anything of the tcp/ip stack? Am I even barking up the right tree here? Any and all suggestions would be appreciated. Cheers, Ari -- Ari Heitner Director of Technology www.NCSY.ca - www.TorahHigh.org w: 905.761.6279 x223 m: 647.202.1998 -- To unsubscribe from this list: send the line "unsubscribe lartc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html