Date: Wed, 8 Nov 2006 10:28:52 +0000 From: MQ <antinvidia@gmail.com> To: "Marat N.Afanasyev" <amarat@ksu.ru> Cc: freebsd-net@freebsd.org Subject: Re: a very strange netstat output and problem when using transparent proxy Message-ID: <be0088ce0611080228l4a9ba091gde28aef330975ff7@mail.gmail.com> In-Reply-To: <4550F348.8040509@ksu.ru> References: <200611072019.kA7KJsAm073276@lurza.secnetix.de> <4550F348.8040509@ksu.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
2006/11/7, Marat N.Afanasyev <amarat@ksu.ru>: > > Oliver Fromme wrote: > > Marat N.Afanasyev wrote: > > > bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > > > > Ok, I also have a machine with bge(4) NIC within reach. > > I've had a look at it for similar symptoms (see below). > > > > > bge0 1500 <Link#1> 00:50:45:5f:4f:78 2341018 799 3062828 > > > 0 0 > > > > 799 is not good, but I wouldn't call it "huge amount of > > ierrs". Is that a typical number, or was that output > > taken before the problem (network freeze) appears? > > more typical is the following: > > % netstat -I bge0 -w 60 > input (bge0) output > packets errs bytes packets errs bytes colls > 151993 241 111011660 172436 0 120848541 0 > 169867 388 118858096 192997 0 135783627 0 > 130524 407 91213775 145884 0 110857756 0 > 327168 1637 214730921 397193 0 275486626 0 > 385627 1027 254274520 471177 0 333456526 0 > 300184 720 198432049 367100 0 271325679 0 > 261095 5525 166910652 324112 0 251708900 0 > 278257 11998 176453071 349975 0 268865328 0 > 314383 8617 203347024 393589 0 301819857 0 > 195408 11647 129989509 246718 0 195720356 0 > 7163 23787 6087244 13165 0 7694485 0 > 2485 24786 1743165 6571 0 4015170 0 > 2202 26175 1117627 6225 0 3992217 0 > > and oops. none of two interfaces can any more process any incoming > packet. ping drops increase to 99% > > > > > > % uptime > > > 7:34PM up 40 mins, 3 users, load averages: 0.14, 0.16, 0.08 > > > > Ok, 799 ierrs after 40 minuted uptime is definitely not > > good. :-) > > > > > Real IP address. I've already switched forward off and make squid > listen > > > on 80 instead. Problem persists. > > > > OK, so it's a NIC problem, not IPFW-related. > > > > Here's output from my machine with bge(4) NIC: > > > > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > > bge0 1500 <Link#1> 00:16:35:... 7808595 35 3451475 0 0 > > > > Uptime is 8 days, the machine is only moderately loaded, > > but gets quite some amount of NFS traffic (as a client). > > OS is FreeBSD 6.2-PRELELEASE as of October 19th. > > as I said before, this problem persists on all my machines with 5704. > > > Whie 35 ierrs in 8 days isn't much, I think it still > > indicates a problem somewhere. It should really be 0. > > (I haven't experienced any freezes or other problems, > > though.) > > > > Maybe you should ask on the -stable mailing list for > > others with bge(4) NICs to check. It looks like a bug > > in the driver. > > > > Oh by the way, do you have polling enabled? Try to > > switch in on (if disabled) or off (if enabled) and check > > whether it improves the situation for you. > > > > Best regards > > Oliver > > > polling cannot be "safely" turned on smp, without eating a lot of cpu to > interrupt processing. So, I run away from polling. > > -- > SY, Marat > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > Maybe bge(4) has some problems with it. At least I have found that on my laptop and servers, the bge_tick() is time-consuming sometimes, and may result lost_polls increasing abnormally. So I won't enable device polling before the problem is addressed and fixed. To your problem, I'm not sure whether fwd rule was used properly. Perhaps divert may help?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?be0088ce0611080228l4a9ba091gde28aef330975ff7>