Path: utzoo!mnetor!uunet!husc6!bu-cs!kwe
From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
Newsgroups: comp.dcom.lans
Subject: Re: Ethernet repeater loosing packets
Message-ID: <20091@bu-cs.BU.EDU>
Date: 22 Feb 88 17:36:15 GMT
References: <657@sater.cs.vu.nl>
Reply-To: kwe@buit13.bu.edu (Kent England)
Followup-To: comp.dcom.lans
Organization: Boston Univ. Information Tech. Dept.
Lines: 32
Summary: It's probably a cable fault

In article <657@sater.cs.vu.nl> sater@cs.vu.nl (Hans van Staveren) writes:
>We have a collection of thin Ethernet segments connected by
>BICC Isolan Multiport repeaters. [...]
>
>We have a suspicion that our repeaters can't cope with this.
>Looking at the various segments with etherfind, an ethernet monitoring
>program supplied by Sun, we saw packets on the originating segment,
>that didn't arrive on the destination segment.
>
	A repeater has no buffering or processing to slow it up.  The
repeater can't be the source of your problems.
	However, a repeater also cannot isolate individual segments
from faults and jabbering transceivers, etc.
	I suspect that you have excess collisions due to problems with
the installation of your thin Ethernet.
	Etherfind/tcpdump will not find these problems.
	You need a LAN analyzer or a TDR to start.  I recommend
putting an analyzer on the troublesome segments to measure the
collision rate.  Once you know you have problems, TDR the segment and
investigate the reflections.  I recommend an analog TDR, not a digital
meter. 
	I suspect you have loose connectors or an unterminated segment
or damaged cable.
	These problems don't necessarily evidence themselves until you
strain the network, which your new server is probably doing.

	I bet you daisy-chained the thin cable through the walls and
ceilings to save money, right?  I've regretted ever doing that.
Tracking down these kinds of problems is much harder.  I hope you have
keys for all those people on their winter vacations this week  :-)

	Kent England, Boston University