Date: Fri, 19 Dec 2008 18:07:40 +0000 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Karrj <John.Karr@bt.com> Cc: freebsd-questions@freebsd.org Subject: Re: Netstat command output Message-ID: <494BE2EC.20407@infracaninophile.co.uk> In-Reply-To: <21094731.post@talk.nabble.com> References: <21094731.post@talk.nabble.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig380075DC9986FC35F77396EF
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Karrj wrote:
> Hello - Warning - I am new to FreeBSD. I am not sure this is the corre=
ct
> forum for this post - forgive me if it is not and please direct me to t=
he
> correct area. I have installed FreeBSD on a HP Proliant DL380 G3 server=
with
> (2) NICs. I have also installed Dummynet and NetSNMP as my ultimate goa=
l is
> to use this as a WAN emulator. I was doing some initial testing where t=
he
> FreeBSD box acts as a router between two subnets where an ftp client is=
on
> one subnet and an ftp server is on the other. I kick off an ftp get of =
a 9
> MB file and at the same time initiate a netstat -w1 -Ibge0 command on t=
he
> FreeBSD. The outputput of the command indicates a relatively small numb=
er of
> input errors (<10 per interval). The same command on the bge1 interface=
is
> all zeros. This is repeatable every time I perform the ftp get. I perfo=
rmed
> the same test without the FreeBSD box by having the client and server
> connected to the same subnet through the same switch ports and no error=
s
> according to the trace analysis - no retransmissions, etc shown in the
> trace. My questions are related to the meaning and interpretation of th=
e
> output of the netstat command and how to resolve the errors. 1) What is=
the
> meaning of input errors? Is it bad CRC at layer 2? What would be meant =
by
> output errors in the command? The interface cannot see the packets afte=
r
> they have been transmitted. I would like a technical explanation of the=
> output of this netstat command. 2) How to alleviate the errors? Is this=
a
> buffer issue? How to determine the NIC type?=20
> Any feedback would be most appreciated.
Hmm... well, to determine the NIC type, look at the interface name. In F=
reeBSD,
the i/f device depends on the chipset of the NIC. There are manual pages=
for
all of the available types: bge(4) in your case. If you need more detail=
, look
at the boot-time dmesg output -- ie /var/run/dmesg.boot -- or you can ext=
ract
PCI ID numbers etc. using 'pciconf -lv'. =20
If you're only seeing errors on the input side on bge0, that sounds like
a duplex mismatch to me. What's the output of 'ifconfig bge0'? If it
claims the connection is running at 100Mb/s half duplex then you've almos=
t
certainly got a mismatch between switch and server -- one is trying to au=
toneg,
and the other is wired to a fixed speed. Either set them both to autoneg=
, or
wire them both down. (100Mb half duplex is the default setting a NIC wil=
l
use when it fails to negotiate correctly with a switch.)
Same sort of effect /can/ be caused by a dodgy patch lead, but I assume
that's one of the first things you'ld have swapped out in trying to debug=
this.
To tell exactly what the errors are you're going to need some more sophis=
ticated
analysis tools than netstat(1). tcpdump(1) and/or wireshark (from ports)=
are
probably your best bet. If you don't want to put an X environment on you=
r
FreeBSD box, then use 'tcpdump -i bge0 -s 0 -w /some/filename' to capture=
the
packet flows, then copy the file to another machine where you have wiresh=
ark
running.
Note that some modern NICs with hardware checksum offloading can give fal=
se
checksum errors on locally generated traffic -- essentially tcpdump grabs=
a copy
of the outgoing packet before the NIC can calculate the checksum and inse=
rt it.
This will only affect programs like tcpdump(1). It won't cause the error =
counters
netstat(1) reports to be incremented. If you do see this sort of thing, =
then
you just need another machine you can do packet capture on to prove to yo=
urself
that the checksums are correct over the wire.
Cheers,
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
--------------enig380075DC9986FC35F77396EF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEUEAREIAAYFAklL4vYACgkQ8Mjk52CukIxqbACghrRlaIVk5GYC58JL/fToYKzz
7eMAmIdCJg/zr+1aVsVJYn9DQ16c+hA=
=kbZV
-----END PGP SIGNATURE-----
--------------enig380075DC9986FC35F77396EF--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?494BE2EC.20407>