Skip site navigation (1)Skip section navigation (2)
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>