bge Ierr rate increase from 5.3R -> 6.1R

[Jeremy Chadwick]

On Wed, Jan 24, 2007 at 03:25:37PM +0100, Robin Gruyters wrote:
> Should this not be visible on the switch as well?!?
>
> Here some output from the interface on the server and from the switch 
> (Cisco)
> 
> [development interface]
> bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         options=1b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING>
>         ether 00:12:79:94:ed:12
>         media: Ethernet autoselect (100baseTX <full-duplex>)
>         status: active
> [/development interface]
> 
> [switch]
> FastEthernet0/3 is up, line protocol is up (connected)
>   Hardware is Fast Ethernet, address is 000e.84d0.de03 (bia 000e.84d0.de03)
>   Description: development
>   MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
>      reliability 255/255, txload 1/255, rxload 1/255
>   Encapsulation ARPA, loopback not set
>   Keepalive set (10 sec)
>   Full-duplex, 100Mb/s
>   input flow-control is off, output flow-control is off
>   ARP type: ARPA, ARP Timeout 04:00:00
>   Last input never, output 00:00:02, output hang never
>   Last clearing of "show interface" counters never
>   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
>   Queueing strategy: fifo
>   Output queue: 0/40 (size/max)
>   5 minute input rate 179000 bits/sec, 28 packets/sec
>   5 minute output rate 56000 bits/sec, 24 packets/sec
>      22823978 packets input, 4067576147 bytes, 0 no buffer
>      Received 13138 broadcasts (0 multicast)
>      0 runts, 0 giants, 0 throttles
>      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
>      0 watchdog, 12929 multicast, 0 pause input
>      0 input packets with dribble condition detected
>      15673035 packets output, 3975127029 bytes, 0 underruns
>      0 output errors, 0 collisions, 1 interface resets
>      0 babbles, 0 late collision, 0 deferred
>      0 lost carrier, 0 no carrier, 0 PAUSE output
>      0 output buffer failures, 0 output buffers swapped out
> [/switch]

You've got a Cisco involved, so I doubt it.  :-)  I've seen
many times in the past where one end of the link shows errors
while the other end (in my experiences, Cisco Catalysts) shows
none.

When dealing with Cisco<->othervendor, I've never seen auto-neg
work properly.  One has to always hard set the speed and duplex
on both sides for it to work.

For example: I lease space in two co-location facilities, from
different providers.  Both providers use Cisco switches (different
models), while we use HP ProCurves.  In both facilities, we saw
input errors on our ProCurve, while the providers saw absolutely
no errors.  Both sides were set to auto.  The instant I had the
providers set 100/full on their Ciscos and I set 100/FD on our
ProCurves, the error counts completely disappeared.

Set your Cisco configuration to use 100/full, and edit the
ifconfig_bge0 line in rc.conf on your FreeBSD box to have "media
100baseTX mediaopt full-duplex", then reboot the FreeBSD box.
If the problem continues, there may be faulty cabling, but
usually errors on one direction are a sign of duplex mismatch.
If after replacing the cabling the issue continues, then there's
a chance the bge(4) driver may be obtaining statistics wrong for
the particular chip revision being used (this is hearsay on my
part; I'm just guessing...)

-- 
| Jeremy Chadwick                                 jdc at parodius.com |
| Parodius Networking                        http://www.parodius.com/ |
| UNIX Systems Administrator                   Mountain View, CA, USA |
| Making life hard for others since 1977.               PGP: 4BD6C0CB |