netstat -ni - A lot of collisions...

[Jeremy Chadwick]

On Mon, Nov 06, 2006 at 11:31:57AM +0200, Anton - Valqk wrote:
> Well,
> the card is connected to a switch that is manageble and the port is set to
> 10Mbit Full duplex on purpose.
> 
> I'm not setting the port speed manual - is that a problem when the port is not 100mbit/fd?
> This is the ifconfig output:
> 
> fxp0: flags=18843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,POLLING> mtu 1500
>         options=48<VLAN_MTU,POLLING>
>         inet 112.15.128.88 netmask 0xffffff00 broadcast 112.15.128.255
>         inet6 fe80::208:c7ff:fe5b:54f2%fxp0 prefixlen 64 scopeid 0x2
>         ether 00:08:c7:5b:54:a5
>         media: Ethernet autoselect (10baseT/UTP)
>         status: active

I've never paid much attention to what ifconfig says, or what
managed switches say, as far as speed or duplex negotiation go.
Most vendors do not play well together.  I'll repeat that because
it needs repeating: most vendors do not play well together.
Example: anyone familiar with Cisco Catalysts knows of the
long-standing problem with auto-neg which ultimately requires
both ends of the connection be set to 100/full.

Try the following configurations:

1.  FreeBSD rc.conf -- media 10baseT/UTP media-opt full-duplex
    Switch -- forced 10/full
    Reboot FreeBSD box

2.  FreeBSD rc.conf -- media 10baseT/UTP media-opt full-duplex
    Switch -- auto-neg
    Reboot FreeBSD box

3.  FreeBSD rc.conf -- media 10baseT/UTP media-opt full-duplex
    Switch -- auto-neg
    Reboot FreeBSD box

Regarding the reboots: changing duplex/speed via ifconfig once
the driver has already done its initial auto-negotiation appears
to behave differently with some switches than on an actual
boot-up.  I have no present-day evidence to back this claim up,
but it's something I've seen historically with xl and fxp.

Now, the transfer test I've used in the past:

* Make a "small" file (dd if=/dev/urandom of=test.bin bs=64k
  count=256) on the FreeBSD box
* Make a similar file (identical or otherwise) on another box,
  one that runs an FTP server
* From the FreeBSD box, FTP to the FTP server
* Do an FTP "PUT" of test.bin
* Make note if the transfer was slow, or quick (1MByte/sec)
* Now do an FTP "GET" of the file you made on the FTP server
* Make note if the transfer was slow, or quick (1MByte/sec)

My guess is that one of the above tests will show very fast
throughput in one direction (ex. PUT), while the other direction
(ex. GET) will be incredibly slow (something like 100 bytes a
second, maybe less).  This is what I've seen in the past in
environments where a switch is set to auto-neg and the FreeBSD
box claims to auto-neg to 100/full correctly... but obviously
doesn't (re: see above: Cisco).

You can make note of collision counts if you want, too.  Any
slow transfers you see will probably show up as collisions, since
somewhere along the lines things got confused and chose half-duplex
(even if ifconfig or the switch doesn't show it).

If all of the above tests seem OK (good speed, etc. -- yet the
collisions continue to increase), I recommend checking the
obvious: Ethernet cable wiring.  You're going to have to get a
RJ45/EIA-568 cable tester and verify that all 8 wires are connected
and have good continuity.  You're not going to get 10/full with a
Ethernet cable that's wired with only 4 wires, AFAIK.

Finally: why exactly are you using 10/full?  What's the purpose?
Are you trying to limit the actual maximum network throughput while
ensuring you have full-duplex capability?  If so: look into using
pf with queueing (see pf.conf man page, section QUEUEING/ALTQ),
or if that's not an option, use ipfw with dummynet.  Make that
box use 100/full, then simply limit the actual network I/O to
10mbit.

For what it's worth: I've never seen a 10/full network that
worked.  It was either 100/full (switches), 100/half (hubs),
or 10/half (hubs).  There's some discussions (use Google)
about why 10/full is essentially a bastard child and should be
avoided.

-- 
| 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 |