a very strange netstat output and problem when using transparent proxy

[MQ]

2006/11/7, Marat N.Afanasyev <amarat at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at 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?