Hello all,
I apologise for the delay in sending out a summary, but here it is.
My Original message was :-
{
Hello,
I hope that somebody out there can help me.
I am currently trying to find a structured cabling solution for our network.
We have 72 Sun Workstations currently connected via thin ethernet. We are
experiencing many network down periods due to poor connections etc. and we
can lose the whole network when this happens.
In order to avoid these problems, we have decided to change over to
UTP5. We have had a few company's in to talk to us and get quotes ready, I
don't want to have to choose on price competitiveness alone and would like to
hear any info regarding UTP5 and the problems/advantages with it.
Also, with the advent of ATM, vendors are offering SWITCHED ETHERNET
hubs. Does anyone have performance related figures which compare switched
and non switched hubs preferably with first hand experiance.
All information is glady received.
}
Many thanks to all who repsonded.
amy.hollander@amp.com
ems@ccrl.nj.nec.com ( Ed Strong )
phill2@hivnet.ubc.ca (Phill St-Louis)
jon@alpha.ee.ufl.edu (Jon Mellott)
cciolori@tatca.tc.faa.gov (Chris Ciolorito)
peffley@endurance.nrlssc.navy.mil (Monty B. Peffley)
jamervi@sandia.gov (1236 Joseph A. Mervini)
vandyk@roses.rockwell.com (Mike Van Dyk)
skhalid@gomez.intel.com (Syed Khalid)
B.T.Mccrone@dl.ac.uk (B.McCrone)
jdd@db.toronto.edu (John DiMarco)
In general the response was that the technology is pretty much of a muchness
so no preference for a particular hub was given. I had no repsonses about
SWITCHED Ethernet performance.
We are now proceeding with the installation process and have narrowed it down
to the following hardware vendors :
Cray Communications ( Cray Hubs )
Castleton Communications ( Hughes Hubs )
Logical Networks ( 3 Com hubs )
Intergraph ( HP Hubs )
&
OSC ( 3 Com Hubs )
The final decision will be made in the next 2 weeks.
Everyone is quoting the end of the year for ATM availability and
some are offering the Dedicated (Switched) Ethernet solution as an
interim solution.
If anyone would like more information about this subject please mail
me and I will answer as well as I can.
The following are the responses I received.
----- Begin Included Message -----
>From mucs!tatca.tc.faa.gov!cciolori Thu Apr 21 16:48:07 1994
Date: Thu, 21 Apr 1994 11:34:52 +0500
From: cciolori@tatca.tc.faa.gov (Chris Ciolorito)
To: rick@fmlrnd.co.uk
Subject: Re: UTP5, switched ethernet.
Content-Length: 80065
One Ethernet FAQ coming right up!
I hope it helps!
It is rather big, so I hope your mailer will accept it. If not I'll
break it up and re-send. Have fun!!
Chris...
Ethernet Network Questions and Answers
Summarized from UseNet group comp.dcom.lans.ethernet
Version 2.11 of 19 April 1992
Sections:
01: Introduction, contributors, how to contribute to the FAQ and
network etiquette.
02: General information about Ethernet and standards.
03: Ethernet Cabling Information.
04: Ethernet Devices and Components.
05: Errors and Related Terms.
06: Testing and Troubleshooting.
07: Additional Information.
01.01Q: What is this document?
A: This is the official FAQ (Frequently Asked Questions) listing for
UseNet newsgroup comp.dcom.lans.ethernet. It is intended to be a
reference to the most commonly asked questions and basic informa-
tion about Ethernet.
01.02Q: How is this document made available?
A: This FAQ is posted monthly to newsgroup comp.dcom.lans.ethernet,
comp.answers and news.answers on UseNet. You can also retrieve
this file via anonymous FTP from dorm.rutgers.edu (128.6.18.15) in
path pub/novell/DOCS as file Ethernet.FAQ (this is a UNIX machine,
note proper character case).
01.03Q: Who maintains this list?
A: This list is currently maintained by Mark Medici. My preferred
mail address is medici@gandalf.rutgers.edu, and I would greatly
appreciate it if you could use a Subject: line that starts
"Ethernet FAQ".
01.04Q: Where does all this information come from?
A: The questions and answers are mostly summarized from the UseNet
newsgroup comp.dcom.lans.ethernet, many of which are derived from
various IEEE, ISO and EIA/TIA documents. Specifically, the
following persons have contributed to this FAQ. Their knowledge
and experiences are gratefully acknowledged.
Doug Barr <barr@spot.colorado.edu>
John Breeden <johnbr@master.cna.tek.com>
TP Brisco <brisco@rutgers.edu>
Peter Desnoyers <peterd@merlin.dev.cdx.mot.com>
Daniel Huber <danielh@hpber199.swiss.hp.com>
Bob Jaques <jaques@drbob.corp.sgi.com>
Paul Joslin <pjoslin@mbvlab.wpafb.af.mil>
Dave Kapalko <medik@attme.att.com>
Rich Lawrence <rich@grebyn.com>
Nick Hennenfent <nicholas@cton.com>
Ray Hunter <rhunter@esoc.BITNET>
Mark Medici <medici@gandalf.rutgers.edu>
Dave Mitton <???@dec.com?>
Rich Seifert <seifert@netcom.com>
Charles Spurgeon <C.Spurgeon@utexas.edu>
(Note: If you have contributed something to this FAQ but your name
is not listed above, please take no offense. There was
some loss of information in this file a while back. Just
mail the current FAQ maintainer your preferred named and
mail address, and which section(s) you contributed).
01.05Q: How can I submit new contributions or corrections to the FAQ?
A: New contributions, suggestions and corrections should be mailed to
the current FAQ maintainer, who is listed in Q&A 01.03 above.
However, you should note that if you are submitting a correction
you must provide both the old and suggested new text -- messages
to the effect of "this is wrong, fix it" will be ignored.
01.06Q: Are there any restrictions on the distribution of this FAQ?
A: You may freely distribute this document for non-commercial
purposes as long as the contents remain unchanged (including
credits) and you do not gain any direct profits from the
distribution.
01.07Q: Are there any guidelines regarding postings on this newsgroup?
A: The standard UseNet guidelines apply to this newsgroup. Explaining
these guidelines in detail requires a FAQ of its own. If you are
not familiar with standard network etiquette, you should review the
documents posted regularly in the newsgroup news.announce.newuser.
01.08Q: Are the vendors and/or models of equipment listed in this FAQ the
only or best suited for the application described?
A: Not necessarily. This document does not attempt to rate equipment
from different manufacturers, and does not endorse nor specifically
support any one vendor's product over another. Any references to a
specific vendor or product is implicitly used as an example of all
like devices.
02.01Q: What is Ethernet?
A: Ethernet is a type of network cabling and signalling specifications
(OSI Model layers 1 [physical] and 2 [data link]) originally
developed by Xerox in the late 1970. In 1980, Digital Equipment
Corp. (DEC), Intel and Xerox (the origin of the term DIX, as in
DEC/Intel/Xerox) began joint promotion of this baseband, CSMA/CD
computer communications network over coaxial cabling, and published
the "Blue Book Standard" for Ethernet Version 1. This standard was
later enhanced, and in 1985 Ethernet II was released.
The IEEE's (Institute of Electrical and Electronics Engineers')
Project 802 then (after considerable debate) used Ethernet Version
2 as the basis for the 802.3 CSMA/CD network standard. The IEEE
802.3 standard is generally interchangeable with Ethernet II, with
the greatest difference being the construction of the network
packet header.
A complete description of all Ethernet specifications is far out-
side the scope of this document. If this area interests you, you
are encouraged to obtain (hopefully legally) copies of the IEEE
802.3 documents, and perhaps the ISO 8802-3 documents as well.
02.03Q: What is an 802.3 network?
A: That's IEEE-ish for Ethernet, but with a few small differences.
The physical layer specifications are identical (though DIX
Ethernet never specified standards for UTP and Fiber-Optic media)
and the MAC sublayer are somewhat different. See "What is Ether-
net for more info.
02.02Q: What is CSMA/CD?
A: CSMA/CD is the media access control mechanism used by Ethernet and
802.3 networks; in other words, it determines how a packet of data
is placed on the wire. CSMA/CD stands for "Carrier Sense Multiple
Access, with Collision Detection". Before an Ethernet device puts
a packet "on the wire", it listens to find if another device is
already transmitting. Once the device finds the wire is clear, it
starts sending the packet while also listening to hear if another
device started sending at the same time (which is called a
collision). Refer to the Q&A on collisions for more info about
this phenomena.
02.03Q: What is a baseband network?
A: A baseband network is one that provides a single channel for
communciations accross the physical medium (e.g., cable), so only
one device can transmit at a time. Devices on a baseband network,
such as Ethernet, are permitted to use all the available bandwidth
for transmission, and the signals they transmit do not need to be
multiplexed onto a carrier frequency. An analogy is a single phone
line such as you usually have to your house: Only one person can
talk at a time--if more than one person wants to talk everyone has
to take turns.
02.04Q: Ok, so what is a broadband network?
A: Simplisticly, it is the opposite of a baseband network. With
broadband, the physical cabling is virtually divided into several
different channels, each with its own unique carrier frequency,
using a technique called "frequency division modulation". These
different frequencies are multiplexed onto the network cabling in
such a way to allow multiple simultaneous "conversations" to take
place. The effect is similar to having several virtual networks
traversing a single piece of wire. Network devices "tuned" to one
frequency can't hear the "signal" on other frequencies, and
visa-versa. Cable-TV is an example of a broadband network:
multiple conversations (channels) are transmitted simultaneously
over a single cable; you pick which one you want to listen to by
selecting one of the frequencies being broadcast.
02.05Q: What is an OSI Model?
A: The Open Systems Interconnect (OSI) reference model is the ISO
(International Standards Organization) structure for the "ideal"
network architecture. This Model outlines seven areas, or layers,
for the network. These layers are (from highest to lowest):
7.) Applications: Where the user applications software lies.
Such issues as file access and transfer, virtual terminal
emulation, interprocess communication and the like are
handled here.
6.) Presentation: Differences in data representation are dealt
with at this level. For example, UNIX-style line endings (CR
only) might be converted to MS-DOS style (CRLF), or EBCIDIC
to ASCII character sets.
5.) Session: Communications between applications across a net-
work is controlled at the session layer. Testing for
out-of-sequence packets and handling two-way communication
are handled here.
4.) Transport: Makes sure the lower three layers are doing their
job correctly, and provides a transparent, logical data
stream between the end user and the network service s/he is
using. This is the lower layer that provides local user
services.
3.) Network: This layer makes certain that a packet sent from one
device to another actually gets there in a reasonable period
of time. Routing and flow control are performed here. This
is the lowest layer of the OSI model that can remain ignorant
of the physical network.
2.) Data Link: This layer deals with getting data packets on and
off the wire, error detection and correction and
retransmission. This layer is generally broken into two
sub-layers: The LLC (Logical Link Control) on the upper half,
which does the error checking, and the MAC (Medium Access
Control) on the lower half, which deals with getting the data
on and off the wire.
1.) Physical: The nuts and bolts layer. Here is where the cable,
connector and signaling specifications are defined.
02.06Q: What does an ethernet packet look like?
A. See the information below, as described in the National databook.
The ethernet packet preamble is normally generated by the chipset.
Software is responsible for the destiantion address, source
address, type, and data. The chips normally will append the frame
check sequence.
+------------+
| | Preamble -
| 62 bits | A series of alternating 1's and 0's used by the
| | ethernet receiver to acquire bit synchronization.
| | This is generated by the chip.
+------------+
| | Start Of Frame Delimiter -
| 2 bits | Two consecutive 1 bits used to acquire byte
| | alignment. This is generated by the chip.
+------------+
+------------+
| | Destination Ethernet Address -
| 6 bytes | Address of the intended receiver.
| | The broadcast address is all 1's.
+------------+
| | Source Ethernet Address -
| 6 bytes | The unique ethernet address of the sending
| | station.
+------------+
| | Length or Type field -
| 2 bytes | For IEEE 802.3 this is the number of bytes of
| | data. For Ethernet I&II this is the type of
| | packet. Types codes are > 1500 to allow both to
| | coexist. The type code for IP packets is 0x800.
+------------+
| 46 bytes | Data -
| to | Short packets must be padded to 46 bytes.
| 1500 bytes |
+------------+
+------------+
| | Frame Check Sequence -
| 4 bytes | The FCS is a 32 bit CRC calculated using
| | the AUTODIN II polynomial.
| | This field is normally generated by the chip.
+------------+
The shortest packet is: 6 + 6 + 2 + 46 = 60 bytes
The longest packet is: 6 + 6 + 2 + 1500 = 1514 bytes
02.07Q: What is the difference between an Ethernet frame and a IEEE802.3
frame? Why are there two types? Why is there a difference?
A: Ethernet was invented at Xerox Palo Alto Research Center and later
became an international standard. IEEE handled making it a
standard; and their specifications are slightly different from the
original Xerox ones. Hence, two different types. 802.3 uses the
802.2 LLC to distinguish among multiple clients, and has a "LENGTH"
field where Ethernet has a 2-byte "TYPE" field to distinguish among
multiple client protocols.
TCP/IP and DECnet (and others) use Ethernet_II framing, which is
that which Xerox/PARC originated.
02.08Q: What is SNAP
A: An extension that allows vendors to create their own ethernet sub-types.
Sub-Network Access Protocol, an extention to the original 802.2
data link level format. (SNAP is described in IEEE 802-1990) The
802.2 data link format replaced the Ethernet Protocol Type concept
with two 8 bit fields; Source SAP, and Destination SAP.
Unfortunately that causes problems with migration of protocols, and
the lack of SAP space that is available. So one SAP as allocated
for this scheme which greatly expands the available protocol space.
When using the SNAP SAP the first 5 bytes of data are used as a
protocol ID. The first 3 bytes should be a value allocated to you
as a vendor id, the same as you get for Source address values. The
is called the OUI (Organizationally Unique ID) The second 2 bytes
is a protocol type.
Note that this is 802.2 and applies across all 802 LAN media types.
For translation bridging, there is a convention, if you set the OUI
to zero, you are representing a mapped Ethernet frame. So that a
bridge will translate such a frame back into Ethernet format, and
not into an 802.3 frame format.
802.2 SNAP frame:
+-------+------+------+------+-------+------+------+
| MAC | DSAP | SSAP | UI | OUI | Type | data |
| Header| 0xAA | 0xAA | 0x03 | 3bytes|2bytes| |
+-------+------+------+------+-------+------+------+
This will appear the same on all 802 compliant LAN media. On
802.3, there will be a Length field between the SA and the DSAP but
not on 802.5 or FDDI.
02.09Q: Where can I find out which Protocols use which Ethernet type
numbers?
A: Look at IETF RFC-1340 - Assigned Numbers RFC.
02.10Q: What is a MAC address?
A: It is the unique hexadecimal serial number assigned to each Ether-
net network device to identify it on the network. With Ethernet
devices (as with most other network types), this address is
permanently set at the time of manufacturer, though it can usually
be changed through software (though this is generally a Very Bad
Thing to do).
02.11Q: Why has the MAC address to be unique?
A: Each card has a unique MAC address, so that it will be able to
exclusively grab packets off the wire meant for it. If MAC
addresses are not unique, there is no way to distinguish between
two stations. Devices on the network watch network traffic and
look for their own MAC address in each packet to determine whether
they should decode it or not. Special circumstances exist for
broadcasting to every device.
02.12Q: Is there a special numbering scheme for MAC addresses?
A: The MAC addresses are exactly 6 bytes in length, and are usually
written in hexadecimal as 12:34:56:78:90:AB (the colons may be
omitted, but generally make the address more readable). Each
manufacturer of Ethernet devices applies for a certain range of MAC
addresses they can use. The first three bytes of the address
determine the manufacturer. RFC-1340 (available via FTP) lists
some of the manufacturer-assigned MAC addresses. A more up-to-date
listing of vendor MAC address assignments is available on
ftp.lcs.mit.edu in pub/map/Ethernet-codes.
02.13Q: What is a preamble ?
A: A seven octet field of alternating one and zero binary bits sent
prior to each frame to allow the PLS circuitry to reach its steady
state synchronization with received frame timing. (802.3 standard,
page 24,42).
02.14Q: What is a Start Frame Delimiter (SFD)?
A: A binary sequence of '10101011' immediately following the preamble
and indicating the beginning of a frame. (802.3 standard, page
24).
02.15Q: What means CRC?
A: Cyclical Redundancy Check - A method of detecting errors in a
message by performing a mathematical calculation on the bits in the
message and then sending the results of the calculation along with
the message. The receiving work-station performs the same
calculation on the message data as it receives it and then checks
the results against those transmitted at the end of the message.
If the results don't match, the receiving end asks the sending end
to send again.
02.13Q: What is a broadcast address?
A: The unique address that identifies a packet as appropriate to all
receiveing stations. In 802.3 any address in which the second byte
is an odd number. (1,3,...F).
02.14Q: What exactly means 10Base5, 10BaseT, 10Base2, 10Broad36, etc.
A: These are the IEEE names for the different physical types of
Ethernet. The "10" stands for signalling speed: 10MHz. "Base"
means Baseband, "broad" means broadband. Initially, the last
section as intended to indicate the maximum length of an unrepeated
cable segment in hundreds of meters. This convention was modified
with the introduction of 10BaseT, where the T means twisted pair,
and 10BaseF where the F means fiber (see the following Q&A for
specifics). This actually comes from the IEEE committee number for
that media.
In actual practice:
10Base2 Is 10MHz Ethernet running over thin, 50 Ohm baseband
coaxial cable. 10Base2 is also commonly referred to
as thin-Ethernet or Cheapernet.
10Base5 Is 10MHz Ethernet running over standard (thick) 50
Ohm baseband coaxial cabling.
10BaseF Is 10MHz Ethernet running over fiber-optic cabling.
10BaseT Is 10MHz Ethernet running over unshielded, twisted-
pair cabling.
10Broad36 Is 10MHz Ethernet running through a broadband cable.
02.15Q: What means FOIRL?
A: Fiber Optic Inter Repeater Link. A "IEEE 802 standard" worked out
between many vendors some time ago for carrying Ethernet signals
across long distances via fiber optic cable. It has since been
adapted to other applications besides connecting segments via
repeaters (you can get FOIRL cards for PCs). It has been
superseded by the larger 10BaseF standard.
02.16Q: What is LattisNet?
A: LattisNet is a pre-10BaseT quasi-standard for running Ethernet over
twisted-pair cabling. It was developed by Synoptics, and several
other vendors made compatible equipment for a while. LattisNet is
not compatible with 10BaseT, but you can have LattisNet hubs and
10BaseT hubs in the same hub chassis or connected to the same
network backbone. The primary difference is that 10BaseT synchron-
izes the signals at the sending end, while LattisNet syncrhonizes
at the receiving end.
02.17Q: What is StarLAN-10?
A: StarLAN-10 is AT&T's variety of Ethernet over twisted-pair cabling.
Older StarLAN-10 is not 100% 10BaseT compliant, as it does not
provide link integrity to the AUI. However, many 10BaseT
interfaces can be configured to work with StarLAN-10 hubs,
alongside StarLAN-10 NICs. Beware, though, that the original
StarLAN-10 is NOT in any way compatible with 10BaseT, and worse,
there seems to be no way to tell other than trying it to see what
happens.
The current StarLAN products supported by AT&T/NCR are fully 802.3
compliant. This includes the SmartHUB model E, SmartHUB model B,
SmartHUB XE, and the other fiber and wire SmartHUB models.
03.01Q: What is coax?
A: Coaxial cable (coax) is a metallic electrical cable used for RF
(radio frequency) and certain data communications transmission.
The cable is constructed with a single solid or stranded center
conductor that is surrounded by the dielectric layer, an insulating
material of constant thickness and high resistance. A conducting
layer of aluminum foil, metallic braid or a combination of the two
encompass the dielectric and act as both a shield against
interference (to or from the center conductor) and as the return
ground for the cable. Finally, an overall insulating layer forms
the outer jacket of the cable. Coaxial cable is generally
superior in high-frequency applications such as networking.
However, for shorter distances (up to 100 meters), UTP or STP cable
is generally just as reliable when using differential modulation
techniques (such as with 10BaseT).
There are three types of RG-58 cable, as far as I can tell. There
are probably other subtle differences, but for 10BASE2, impedance
and velocity of propagation are the important ones. The table
below summarizes:
Cable Impedance Velocity
---------- ---------- --------------
RG-58A/U 50 ohms .66 or .78
RG-58C/U 50 ohms .66
RG-58/U 53.5 ohms .66 or .695
End of part I.
>From barr@spot.Colorado.EDU (BARR DOUG)
Subject: FAQ, Part 2
Date: Mon, 1 Nov 1993 22:50:10 GMT
Begin Part II
03.02Q: What is UTP, STP?
A: Twisted pair cables. UTP is for UNshielded, twisted pair, while
STP is for SHIELDED, twisted pair. UTP is what's typically
installed by phone companies (though this is often not of high
enough quality for high- speed network use) and is what 10BaseT
Ethernet runs over. UTP is graded according to its data carrying
ability (e.g., Level 3, Level 4, Level 5). 10BaseT Ethernet
requires at least Level 3 cable. Many sites now install only
Level-5 UTP, even though level 4 is more than sufficient for
10BaseT, because of the greater likelihood that emerging high-speed
standards will require cable with better bandwidth capabilities.
STP is typically used for Token-Ring networks, where it is commonly
referred to IBM Type 1 (or 2, 3, 6, 8, etc); however there are
several manufacturers of Ethernet equipment and interfaces that
support Ethernet over STP. Nevertheless, Ethernet over STP is not
officially defined in any standards. While there is a good level
of interoperability with Ethernet over STP, (Lattisnet, developed
by Synoptics, is the recognized de facto standard in this area),
one should consider the long-term availability and cost of this
non-standard scheme before planning new networks around it.
03.03Q: Are there any restrictions on how Ethernet is cabled?
A: Yes, there are many, and they vary according to the media used.
First of all, there are distance limitations:
10Base2 limited to 185 meters (607 ft) per unrepeated cable
segment.
10Base5 limited to 500 meters (1,640 ft) per unrepeated cable
segment.
10BaseF depends on the signaling technology and medium used
but can go up to 2KM.
10BaseT generally accepted to have a maximum run of 100-150M,
but is really based on signal loss in Db's (11.5db
maximum loss source to destination).
10Broad36 limited to 3,600 meters (almost 2.25 miles).
Then there are limitations on the number of repeaters and cable
segments allowed between any two stations on the network. There
are two different ways of looking at the same rules:
1. The Ethernet way:
A remote repeater pair (with an intermediate point-to-point
link) is counted as a single repeater (IEEE calls it two
repeaters). You cannot put any stations on the point to point
link (by definition!), and there can be two repeaters in the
path between any pair of stations. This seems simpler to me
than the IEEE terminology, and is equivalent.
2. The IEEE way:
There may be no more than five (5) repeated segments, nor more
than four (4) repeaters between any two Ethernet stations; and
of the five cable segments, only three (3) may be populated.
This is referred to as the "5-4-3" rule (5 segments, 4
repeaters, 3 populated segments).
It can really get messy when you start cascading through 10BaseT
hubs, which are repeaters unto themselves. Just try to remember,
that any possible path between two network devices on an
unbridged/unrouted network cannot pass through more than 4
repeaters or hubs, nor more than 3 populated cable segments.
Finally, 10Base2 is limited to a maximum of 30 network devices per
unrepeated network segment with a minimum distance of 0.5m (1.5ft)
between T-connectors. 10Base5 is limited to a maximum of 100
network devices per unrepeated segment, with a minimum distance of
2.5m (8.2ft) between taps/T's (usually indicated by a marker
stamped on the cable itself every 2.5m). 10BaseT and 10BaseF are
star-wired, so there is no minimum distance requirement between
devices, since devices cannot be connected serially. You can
install up to the Ethernet maximum of 1024 stations per network
with both 10BaseT and 10BaseF.
03.04Q: Can I mix 10Base2 and 10Base5 cabling on a single segment?
A: It is not "legal", but the network police will not read you your
rights and drag you away. Ideally, you should use a repeater (or
bridge, router, etc...) between the different cabling types.
However, in reality, it will work fine, as long as none of the
other network parameters (lengths, numbers of stations, repeaters,
etc) are near the limit of the specification.
03.05Q: What about wireless Ethernets? Are there any?
A: Yes, and no. Many vendors offer equipment for Ethernet across a
variety of unbounded, or wireless, connections using lasers,
microwaves, and spread-spectrum radio transmissions. However, none
of these methods are organized by any standards body, so it is
unlikely to find equipment from any two different manufacturers
that work together.
03.06Q: When should I choose 10BaseT, when 10Base2 (or others)?
A: The specific environment and application must be considered when
selecting your media type. However, there are some general
rules-of-thumb that you can consider:
Avoid using copper between buildings. The electrical disturbances
caused by lightning, as well as naturally occurring differences in
ground potential over distance, can very quickly and easily cause
considerable damage to equipment and people. The use of
fiber-optic cabling between buildings eliminates network cabling as
a safety risk. There are also various wireless media available for
inter-building links, such as laser, spread-spectrum RF and
microwave. However, wireless media is much more expensive and less
reliable than fiber-optic, and should only be considered when it is
impossible to get right-of-way for fiber-optic cable.
10Base2 (thin Ethernet or Cheapernet) is the least expensive way to
cable an Ethernet network. However, the price difference between
10Base2 and 10BaseT (Ethernet over UTP) is rapidly diminishing.
Still, for small, budget-conscious installations, 10Base2 is the
most economical topology. The disadvantages of 10Base2 is that any
break in the cable or poor connection will bring the entire network
down, and you need repeaters if you have more than 30 devices
connected to the network or the cable length exceeds 185 meters
(607 feet).
10Base5 is generally used as a low-cost alternative to fiber-optic
media for use as a backbone segment within a single building. It's
extended length (500m or 1640ft), higher attached device count
(100) and better noise resistance make 10Base5 well suited for use
as a network trunk for one or more floors in a building. However,
the high cost of connecting each device (in addition to the
interface, you also need an external transceiver, or MAU, and an
AUI cable) makes 10Base5 too expensive for most LAN installations,
and like 10Base2, a single break or bad connection in the cable can
bring the entire network down.
10BaseT is the most flexible topology for LANs, and is generally
the best choice for most network installations. 10BaseT hubs, or
multi-hub concentrators, are typically installed in a central
location to the user community, and inexpensive UTP cabling is run
to each network device (which may be 100m, or 330ft, from the hub).
The signalling technology is very reliable, even in somewhat noisy
environments, and 10BaseT hubs will usually detect many network
error conditions and automatically shut-down the offending port(s)
without affecting the rest of the network (unless, of course, the
offending port was your server, shared printer, or router to the
rest of the world). While the hardware is more expensive than
10Base2, the cabling is cheaper and requires less skill to install,
making 10BaseT installation costs only slightly higher than
10Base2. The flexibility and reliability more than offset the
marginally higher price.
10BaseF, and its predecessor, FOIRL, are the only recommended
topologies for inter-building links. However, they need not be
limited to this role. 10BaseF can also be run to the desktop,
though the cost is prohibitively high in all but the most
specialized environments (generally, extremely noisy manufacturing
facilities, or very security-conscious installations). More
commonly, FOIRL (and now, 10BaseF) is used inside buildings to form
backbone networks and to connect wiring closets together.
03.07Q: What are the advantages/disadvantages of a star like cabling?
A: Old style Ethernet bus wiring (ie, taking the cable from one
machine to the next, and then to the next, etc) is prone to cable
failure and quickly consumes allowed distances due to aesthetic
wiring needs. If the wiring connection is broken at any point, the
entire network (segment) fails - and the much greater number of
connections increases the probability of a failure or break. On the
other hand, it's pretty easy to do for a layman and may involve
less actual wiring for small segments.
Star wiring eliminates the single point of failure of a common
wire. A central hub has many connections that radiate out to
hosts, if one of these hosts connections fails it usually doesn't
affect the others. Obviously, however, the hub becomes a central
point of failure itself, but studies show a quality hub is less
likely to fail before a heavily used strand of coax.
There are a bunch of other reasons hubs are desirable, but this is
the biggie.
03.08Q: Is there an official "standard" punch down scheme for 10BaseT?
A: Get a copy of EIA/TIA-568, it covers all of that sort of stuff:
horizontal, vertical, connectors, patch cords, cross-connects, etc.
03.09Q: Is it safe to run Unshield Twisted Pair next to power cable?
A: According to EIA/TIA-569, the standard wiring practices for running
data cabling and companion to the above referenced EIA/TIA-568, you
should not run data cable parallel to power cables. However, in
reality, this should not be a problem with networks such as
10BaseT. 10BaseT uses differential signalling to pick the data
signals off the wire. Since any interference from nearby power
lines will usually affect all pairs equally, anything that is not
canceled-out by the twists in the UTP should be ignored by the
receiving network interface.
03.10Q: Can I make a cable to connect the AUI ports of two devices directly
to each other?
A: Yes and no. You can make the equivalent of a null modem cable by
connecting a two-pair, twisted pair cable connecting pins 3/10 at
each end to pins 5/12 (respectively) at the other. This connects
transmit-to receive (null modem). However, this will probably NOT
work with "standard" software because:
- There is no collision detect. If a collision occurs neither
device will back-off or and retry.
- There is no loopback (stations will not hear their own
transmissions which may cause diagnostics failures).
- There is no heartbeat (SQE test) provided, which may cause
diagnostic failure.
If you want to use standard software, buy some transceivers. An AUI
null-modem will work for a laboratory, test environment under
certain conditions.
03.11Q: Can I connect the 10BaseT interface of two devices directly
together, without using a hub?
A: Yes, but not more than 2 devices, and you also need a special
jumper cable between the two 10BaseT ports:
RJ45 pin RJ45 pin
======== ========
1 <--[TX+]--------[RX+]--> 3
2 <--[TX-]--------[RX-]--> 6
3 <--[RX+]--------[TX+]--> 1
6 <--[RX-]--------[TX-]--> 2
03.12Q: Does my Ethernet coax have to be grounded? How?
A: Yes and no. The 10Base2 spec says the coax MAY be grounded at one
and only one point, while the 10Base5 spec says the coax SHALL be
grounded at one and only one point.
Grounding your coax is generally a good idea; it allows static
electricity to bleed off and, supposedly, makes for a safer
installation. Further, many local electrical codes will require
your network cabling to be grounded at some point. However, I have
personally seen many Ethernet networks work with absolutely NO
ground on the segment, and even a few unreliable segments become
reliable when the one and only ground was removed. I'm not saying
you should not ground your networks -- you should absolutely
install cabling according to your electrical codes.
On the other hand, if you do ground your cable, make sure you do so
only at one point. Multiple grounds on an Ethernet segment will
not only cause network errors, but also risk damage to equipment
and injury to people.
If you have a repeater on one end of the segment, this will usually
automatically ground that end of the segment (you may want to check
the repeater documentation and configuration to assure this is the
case -- most repeaters can be set-up to NOT ground). If you don't
have a repeater, you can get terminating resistors with ground
straps attached.
04.01Q: What is a "segment"?
A: A piece of network wire bounded by bridges, routers, repeaters or
terminators.
04.02Q: What is a "subnet"?
A: Another overloaded term. It can mean, depending on the usage, a
segment, a set of machines grouped together by a specific protocol
feature (note that these machines do not have to be on the same
segment, but they could be) or a big nylon thing used to capture
enemy subs.
04.03Q: What is a fan-out? Is this device still used?
A: Fanout (a.k.a. transceiver multiplexor, a.k.a. multiport trans-
ceiver, a.k.a. DELNI) allows multiple stations to connect to a
single transceiver or transceiver-like device. They are still
widely used.
04.04Q: What means "AUI"?
A: Attachment Unit Interface, an IEEE term for the connection between
a controller and the transceiver.
04.05Q: What is a transceiver?
A: A transceiver allows a station to transmit and receive to/from the
common medium. In addition, Ethernet transceivers detect collisions
on the medium and provide electrical isolation between stations.
10Base2 and 10Base5 transceivers attach directly to the common bus
media, though the former usually use an internal transceiver
built-onto the controller circuitry with a "T" connector to access
the cable, while the latter use a separate, external transceiver
and an AUI (or transceiver) cable to connect to the controller.
10BaseF, 10BaseT and FOIRL also usually use internal transceivers.
Having said that, there also also external transceivers for
10Base2, 10BaseF, 10BaseT and FOIRL that can connect externally to
the controller's AUI port, either directly or via an AUI cable.
04.06Q: What means "MAU"?
A: Medium Access Unit, an IEEE term for a transceiver. MAU is also
commonly [mis]used to describe a Token-Ring Multi-Station Access
Unit (MSAU). Refer to HUB for an explanation of MSAU.
04.07Q: What exactly does a repeater?
A: A repeater acts on a purely electrical level to connect to
segments. All it does is amplify and reshape (and, depending on the
type, possibly retime) the analog waveform to extend network
segment distances. It does not know anything about addresses or
forwarding, thus it cannot be used to reduce traffic as a bridge
can in the example above.
04.08Q: What is a "hub"?
A: A hub is a common wiring point for star-topology networks, and is a
common synonym for concentrator (though the latter generally has
additional features or capabilities). Arcnet, 10BaseT Ethernet and
10BaseF Ethernet and many proprietary network topologies use hubs
to connect multiple cable runs in a star-wired network topology
into a single network. Token-Ring MSAUs (Multi-Station Access
Units) can also be considered a type of hub, but don't let a
token-ring bigot hear that. Hubs have multiple ports to attach
the different cable runs. Some hubs (such as 10BaseT and active
Arcnet) include electronics to regenerate and retime the signal
between each hub port. Others (such as 10BaseF or passive Arcnet)
simply act as signal splitters, similar to the multi-tap cable-TV
splitters you might use on your home antenna coax (of course,
10BaseF uses mirrors to split the signals between cables). Token-
Ring MSAUs use relays (mechanical or electronic) to reroute the
network signals to each active device in series, while all other
hubs redistribute received signals out all ports simultaneously,
just as a 10Base2 multi-port repeater would.
04.09Q: What exactly does a bridge?
A: A bridge will connect to distinct segments (usually referring to a
physical length of wire) and transmit traffic between them. This
allows you to extend the maximum size of the network while still
not breaking the maximum wire length, attached device count, or
number of repeaters for a network segment.
04.10Q: What does a "learning bridge"?
A: A learning bridge monitors MAC (OSI layer 2) addresses on both
sides of its connection and attempts to learn which addresses are
on which side. It can then decide when it receives a packet
whether it should cross the bridge or stay local (some packets may
not need to cross the bridge because the source and destination
addresses are both on one side). If the bridge receives a packet
that it doesn't know the addresses of, it will forward it by
default.
04.11Q: What is a remote bridge?
A: A bridge as described above that has an Ethernet interface on one
side and a serial interface on the other. It would connect to a
similar device on the other side of the serial line. Most commonly
used in WAN links where it is impossible or impractical to install
network cables. A high-speed modem (or T1 DSU/CSU's, X.25 PAD's,
etc) and intervening telephone lines or public data network would
be used to connect the two remote bridges together.
04.13Q: Is there a maximum number of bridges allowed on a network?
A: Per IEEE 802.1 (d), the maximum number of concatenated brides in a
bridged LAN is 7. This number is rather arbitrary, however, and is
based on simulations of application performance with expected
bridge delays.
In addition, the number assumes that all bridges are LOCAL (no
remote WAN connections), and that the default Hold Time of 1 second
is in place (this is the time after which a bridge will discard a
frame it is holding). This prevents extra-late frame delivery.
(i.e, a frame should never be delivered more than ~7 seconds after
is it sent).
I personally (Rich Seifert) find this to be much too long an
allowance. My "rule of thumb" for bridged LANs is to limit the
number of hops to 4, with not more than one of these being a WAN
linked remote bridge.
04.13Q: What exactly does a router?
A: Routers work much like bridges, but they pay attention to the upper
network layer protocols (OSI layer 3) rather than physical layer
(OSI layer 1) protocols. A router will decide whether to forward a
packet by looking at the protocol level addresses (for instance,
TCP/IP addresses) rather than the MAC address. Because routers
work at layer 3 of the OSI stack, it is possible for them to
transfer packets between different media types (i.e., leased lines,
Ethernet, token ring, X.25, Frame Relay and FDDI). Many routers
can also function as bridges.
04.14Q: So should I use a router or a bridge?
A: There is no absolute answer to this. Your network layout, type and
amount of hosts and traffic, and other issues (both technical and
non-technical) must be considered. Routing would always be
preferable to bridging except that routers are slower and usually
more expensive (due to the amount of processing required to look
inside the physical packet and determine which interface that
packet needs to get sent out), and that many applications use
non-routable protocols (i.e., NetBIOS, DEC LAT, etc.).
Rules of thumb:
Bridges are usually good choices for small networks with few, if
any, slow redundant links between destinations. Further, bridges
may be your _only_ choice for certain protocols, unless you have
the means to encapsulate (tunnel) the unroutable protocol inside
a routable protocol.
Routers are usually much better choices for larger networks,
particularly where you want to have a relatively clean WAN
backbone. Routers are better at protecting against protocol
errors (such as broadcast storms) and bandwidth utilization.
Since routers look deeper inside the data packet, they can also
make forwarding decisions based on the upper-layer protocols.
Occasionally, a combination of the two devices are the best way to
go. Bridges can be used to segment small networks that are
geographicly close to each other, between each other and the router
to the rest of the WAN.
04.15Q: Are there problems mixing Bridging & routing?
A: Only if you plan on having bridged links in parallel with routed
links. You need to be very careful about running bridges providing
links in parallel to a router. Bridges may forward broadcast
requests which will confuse the router there are lots of protocols
you may not think of filtering (e.g. ARP, Apple ARP over 802.3
etc. etc.). Also, DECnet routers have the same MAC address on all
ports. This will probably cause the bridge to think it is seeing
an Ethernet loop.
04.16Q: Who makes the fastest/easiest/most advanced bridges or routers?
A: The IETF runs bench marks on a wide selection of bridges and
routers. The results (and much of the testing itself) is handled
at Harvard University by Scott Bradner. [ed: anyone have the ftp
site address and path/filename for the benchmarks?]
04.17Q: What is a Kalpana EtherSwitch? Are there other devices like it?
A: A device that works sort of like a multisegment bridge, but with a
complicated internal bus that allows full crosspoint switching. A
Kalpana or other such switch is exactly equivalent to a fully
connected mess of simple bridges among the Ethernets. A 12-port
Kalpana or similar switch is obviously rather easier to use and
cheaper than the equivalent mesh of 132 simple bridges. However,
the EtherSwitch does not use the Spanning Tree Algorithm and,
therefore, cannot be used in situations where a bridging loop might
occur.
There are competing devices from other manufacturers, including
some that do implement the Spanning Tree Algorithm. For example,
Alantec has a multi-port bridge/router supporting 12 segments with
full spanning tree and snmp and it runs at about ethernet speeds.
04.18Q: What is a driver?
A: Typically the software that allows an Ethernet card in a computer
to decode packets and send them to the operating system and encode
data from the operating system for transmission by the Ethernet
card through the network. By handling the nitty-gritty hardware
interface chores, it provides a device-independent interface to the
upper layer protocols, thereby making them more universal and
[allegedly] easier to develop and use. There are many other
meanings to this word, but this is probably what you are looking
for.
04.19Q: What is NDIS, packet driver, ODI.?
A: NDIS is a Microsoft/3com puppy that allows "stacking" of multiple
protocols for a single underlying driver. Essentially it allows a
single Ethernet card in a PC (it's not limited to Ethernet) to
speak many different network "languages", and usually at the same
time.
A packet driver is another method of allowing multiple protocols to
access the network interface at the same time. Developed and
supported by FTP Software Inc, Clarkson University, BYU and, more
recently, Crynwr Software, the packet driver spec (PDS) is used to
provide a device independent interface to various TCP/IP
applications, and often in combination with concurrent Novell
access (IPX/SPX).
ODI is Novell and Apple's equivalent of NDIS. There are
differences between the two specs, but not so much as to warrant
description in this text.
The next logical question is "which one should I use?" There is no
simple or obvious answer, except that you should use the one most
commonly required by your software.
05.01Q: What means SQE? What is it for?
A: SQE is the IEEE term for a collision. (Signal Quality Error)
05.02Q: What means SQE Test? What means heartbeat? What are they for?
A: SQE Test (a.k.a. heartbeat) is a means of detecting a transceiver's
inability to detect collisions. Without SQE Test, it is not
possible to determine if your collision detector is operating
properly. SQE Test is implemented by generating a test signal on
the collision pair from the transceiver (or its equivalent)
following every transmission on the network. It does not generate
any signal on the common medium.
The problem with SQE Test is that it is not part of the Ethernet
Version 1.0 specification. Therefore, Version 1.0 equipment may
not function with transceiver that generates the SQE Test signal.
Additionally, IEEE 802.3 specifications state that IEEE 802.3
compliant repeaters must not be attached to transceivers that
generate heartbeat. (This has to do with a jam signal that
prevents redundant collisions from occurring on the network).
Therefore, you must usually turn-off SQE Test (heartbeat) between
the transceiver and an 802.3 repeater.
05.03Q: What means "IPG"?
A: The InterPacket Gap (more properly referred to as the InterFrame
Gap, or IFG) is an enforced quiet time of 9.6 us between
transmitted Ethernet frames.
05.04Q: What means "promiscuous mode"?
A: Promiscuous mode is a condition where the network interface con-
troller will pass all frames, regardless of destination address, up
to the higher level network layers. Normally the network
controller will only pass up frames that have that device's
destination address. However, when put in promiscuous mode, all
frames are passed on up the network stack regardless of destination
address. Promiscuous mode is usually used by network monitoring
tools and transparent bridges (and, frequently, by network crackers
trying to snatch passwords, or other data they're normally not able
to see, off the wire).
05.05Q: What is a runt?
A: A packet that is below the minimum size for a given protocol. With
Ethernet, a runt is a frame shorter than the minimum legal length
of 60 bytes (at Data Link).
05.06Q: What causes a runt?
A: Runt packets are most likely the result of a collision, a faulty
device on the network, or software gone awry.
05.07Q: What is a jabber?
A: A blanket term for a device that is behaving improperly in terms of
electrical signalling on a network. In Ethernet this is Very Bad,
because Ethernet uses electrical signal levels to determine whether
the network is available for transmission. A jabbering device can
cause the entire network to halt because all other devices think it
is busy.
05.08Q: What causes a jabber?
A: Typically a bad network interface card in a machine on the network.
In bizarre circumstances outside interference might cause it.
These are very hard problems to trace with layman tools.
05.09Q: What is a collision?
A: A condition where two devices detect that the network is idle and
end up trying to send packets at exactly the same time. (within 1
round-trip delay) Since only one device can transmit at a time,
both devices must back off and attempt to retransmit again.
The retransmission algorithm requires each device to wait a random
amount of time, so the two are very likely to retry at different
times, and thus the second one will sense that the network is busy
and wait until the packet is finished. If the two devices retry at
the same time (or almost the same time) they will collide again,
and the process repeats until either the packet finally makes it
onto the network without collisions, or 16 consecutive collision
occur and the packet is aborted.
05.10Q: What causes a collision?
A: See above. Ethernet is a CSMA/CD (Carrier Sense Multiple Access/
Collision Detect) system. It is possible to not sense carrier from
a previous device and attempt to transmit anyway, or to have two
devices attempt to transmit at the same time; in either case a
collision results. Ethernet is particularly susceptible to
performance loss from such problems when people ignore the "rules"
for wiring Ethernet.
05.11Q: How many collisions are too many?
A: This depends on your application and protocol. In many cases,
collision rates of 50% will not cause a large decrease in perceived
throughput. If your network is slowing down and you notice the
percentage of collisions is on the high side, you may want try
segmenting your network with either a bridge or router to see if
performance improves.
05.12Q: How do I reduce the number of collisions?
A: Disconnect devices from the network. Seriously, you need to cut-
down on the number of devices on the network segment to affect the
collision rate. This is usually accomplished by splitting the
segment into two pieces and putting a bridge or router in between
them.
05.13Q: What is a late collision?
A: A late collision occurs when two devices transmit at the same time,
but due to cabling errors (most commonly, excessive network segment
length or repeaters between devices) neither detects a collision.
The reason this happens is because the time to propagate the signal
from one end of the network to another is longer than the time to
put the entire packet on the network, so the two devices that cause
the late collision never see that the other's sending until after
it puts the entire packet on the network. Late collisions are
detected by the transmitter after the first "slot time" of 64 byte
times. They are only detected during transmissions of packets
longer than 64 bytes. It's detection is exactly the same as for a
normal collision; it just happens "too late."
Typical causes of late collisions are segment cable lengths in
excess of the maximum permitted for the cable type, faulty
connectors or improper cabling, excessive numbers of repeaters
between network devices, and defective Ethernet transceivers or
controllers.
Another bad thing about late collisions is that they occur for
small packets also, but cannot be detected by the transmitter. A
network suffering a measurable rate of late collisions (on large
packets) is also suffering lost small packets. The higher
protocols do not cope well with such losses. Well, they cope, but
at much reduced speed. A 1% packet loss is enough to reduce the
speed of NFS by 90% with the default retransmission timers. That's
a 10X amplification of the problem.
Finally, Ethernet controllers do not retransmit packets lost to
late collisions.
05.14Q: What is a jam?
A: When a workstation receives a collision, and it is transmitting, it
puts out a jam so all other stations will see the collision also.
When a repeater detects a collision on one port, it puts out a jam
on all other ports, causing a collision to occur on those lines
that are transmitting, and causing any non-transmitting stations to
wait to transmit.
05.15Q: What is a broadcast storm?
A: An overloaded term that describes an overloaded protocol. :-).
Basically it describes a condition where devices on the network are
generating traffic that by its nature causes the generation of even
more traffic. The inevitable result is a huge degradation of
performance or complete loss of the network as the devices continue
to generate more and more traffic. This can be related to the
physical transmission or to very high level protocols.
05.16Q: How do I recognize a broadcast storm?
A: That depends on what level it is occurring. Basically you have to
be aware of the potential for it beforehand and be looking for it,
because in a true broadcast storm you will probably be unable to
access the network. This can change dramatically for a higher
level protocol. NFS contention can result in a dramatic DROP in
Ethernet traffic, yet no one will have access to resources.
05.17Q: How can I prevent a broadcast storm?
A: Avoid protocols that are prone to it. Route when it is practical.
05.18Q: What is an Alignment Error ?
A: A received frame that does not contain an integer number of octets
and contains a frame check sequence validation error. A frame in
which the number of bits received is not an integer multiple of 8
and has a FCS (Frame Check Sequence) error. (802.3 standard, page
41)
05.19Q: What is *high* traffic on an Ethernet? 5%? 20%? 90%?
A: High traffic is when things start slowing down to the point they
are no longer acceptable. There is not set percentage point, in
other words. Xerox used to use a formula based on packet size over
time, or something, but the issue has been significantly muddied by
the plethora of protocols available and how they react to wire
usage. I usually start paying attention over 40-50%, *or when
things slow down*.
06.01Q: How can I test an Ethernet?
A: This depends on what level you want to test. The most basic test
(a.k.a., "the fire test") is to connect a pair of devices to the
network and see if they can communicate with each other. If you
want to test the electrical integrity of the wire (i.e., will it
carry a signal properly), a TDR or cable scanner that incorporates
TDR and other functions, would be the most comprehensive tool
(though a great deal cab be determined with a simple ohmmeter). If
you need to test the performance or troubleshoot protocol
transmission problems, you will need special and usually very
expensive software, usually coupled with custom hardware, to
capture, optionally filter, and analyze the network packets.
06.02Q: Is there a troubleshooting guide for Ethernet?
A: Yes, many. I suggest you check your local technical bookstore.
(Recommendations from the list would be appreciated!)
There are also some common sense steps you can take. [Volunteer
needed to fill this section out -- I think it's important but I'm a
little short on time at the moment to do it myself -mm]
06.03Q: What is a "TDR"?
A: A Time-Domain Reflectometer is a tool used to detect cable faults.
This device operates by sending a brief signal pulse down the cable
and looking for its reflection to bounce back. By analyzing the
reflected pulse, it is possible to make judgments about the quality
of the cable segment. More advanced units can not only detect and
identify the nature of the problem, but give a reasonably accurate
indication of the problem's location (distance from the point of
the test). There is also a device known as an OTDR, which is an
Optical Time-Domain Reflectometer for fiber-optic cables.
06.04Q: What means "BERT"?
A: Bit Error Rate Tester. This equipment is used to analyze the
amount and types of errors that occur on a cable segment.
06.05Q: What (free) tools are there to monitor/decode/etc an Ethernet?
A: There are many built into most Unix systems. For example, the ping
command can be used to determine if a given host is alive, and will
also tell you the round trip transmission time. ifconfig will tell
you the status of the network interfaces. netstat will summarize
statistics for network usage. spray will allow you to generate
network traffic directed at a particular host. Use "man
command-name" to learn more about a unix command. Using "man -k
network" may also provide leads to the tools provided by your unix
vendor.
Many more public domain tools are available for unix systems.
These include:
traffic: allows systems to graphically display network load
tcpdump: collect statistics and display individual packets
etherfind: ????
nfswatch: summarize/display traffic, particularly nfs packets
traceroute: determine the route between two hosts
Some cards for the PC come with utilities. There are several free
ones available, including ping (Clarkson University and others),
The Beholder (packet capture and display) and others.
07.01Q: Are there any other sources of information about Ethernet?
A: There are a LOT of information sources. Try to get the BIG-LAN
FAQ. One known anonymous FTP location is icarus.cns.syr.edu in
/information/big-lan. The big-lan.faq file is a kind of superset
to this ethernet faq. Another excelleny document is the network
reading list, "net-read.txt" (or "net-read.ps") by Charles
Spurgeon, available via anonymous FTP from ftp.utexas.edu. Cisco
Systems has a useful document: DOC-GLOSS part number 78-0888-01.
07.02Q: What books are good about Ethernet LAN's?
A: The IEEE 802.3 documents are considered the definitative source for
information on Ethernet. However, these may not be suitable for
all levels of users. Surprisingly, there are few good books
specifically dealing with Ethernet LANs, but here are a few that
you might find useful:
Local Area Networks, An introduction to the technology
by John E. McNamara, published by Digital Press, 1985
165 pps. with index and glossary, $29.00
ISBN 0-932376-79-7, Digital Press part number EY-00051-DP.
Network Troubleshooting Guide
by Digital Equipment Corporation, August 1990
Approx. 278 pps. with index and glossary, $95.00
Digital Press part number EK-339AB-GD-002.
These books and others are recommended in the network reading list,
net-read.txt, from ftp.utexas.edu.
07.03Q: Where can I get IEEE802.x docs online?
A: Nowhere. IEEE documents must be ordered from the IEEE themselves.
You can contact them at:
Institute of Electrical and Electronic Engineers
445 Hoes Lane
P.O. Box 1331
Piscataway, NJ 08855-1331
U.S.A.
(800) 678-IEEE
You can also get order information via e-mail to askieee@ieee.org.
07.04Q: Where can I get EIA/TIA docs online?
A: Nowhere. They must be ordered from:
Global Engineering
800-854-7179
(I am still trying to contact this vendor for more details.)
07.05Q: Where can I find the specifications of Ethernet equipment?
A: From the manufacturer of the product [hopefully!]. In the IEEE
802.3 documents for standard devices.
07.06Q: Where can I find IETF (Internet Engineering Task Force) documents?
A: These are available for anonymous FTP from a number of sites. One
known location is athos.rutgers.edu in /ietf. Drafts are also on
athos in /internet-drafts.
07.07Q: Where can I get the current version of this document?
A: Check in newsgroups comp.dcom.lans.ethernet, comp.answers and
news.answers. It is also available via anonymous ftp from
dorm.rutgers.edu in path pub/novell/DOCS as Ethernet.FAQ.
Fiber, from Raylan
415-813-0400
We have 200 on our network and are very happy with it.
>From mucs!ccrl.nj.nec.com!ems Thu Apr 21 00:37:36 1994
From: ems@ccrl.nj.nec.com (Ed Strong)
Date: Wed, 20 Apr 94 15:11:20 EDT
To: rick@fmlrnd.co.uk
Subject: Re: UTP5, switched ethernet.
Content-Length: 513
We have many more than 72 workstation using thin ethernet, with few
problems. UTP5 doesn't necessary improve your "poor connections" compared
to thinnet, so if that is supposed to be the main selling point, don't buy it.
(You may still want to buy because UTP5 is the future, just don't oversell
the reliability.)
Your message didn't say what sort of hub you are using, and how many
nodes you have per thinnet run. Making the runs too long, with too many
nodes pre run can break your thinnet badly.
Ed Strong
>From mucs!hivnet.ubc.ca!phill2 Thu Apr 21 07:16:50 1994
Date: Wed, 20 Apr 94 23:22:53 PDT
From: Phill St-Louis <phill2@hivnet.ubc.ca>
To: rick@fmlrnd.co.uk
Subject: Re: UTP5, switched ethernet.
Content-Length: 272
We have used twisted pair 10-BASE T for 4 years now and have experienced
few problems. The wire that we used when we first started was level 4.
SInce you are using level 5, you will be able to switch to 100 Mbs
solutions using the same wiring if you ever need to.
Phill
>From mucs!anna.e-technik.Uni-Dortmund.DE!wm Thu Apr 21 09:17:01 1994
Date: Thu, 21 Apr 94 10:03:37 +0200
From: wm@anna.e-technik.Uni-Dortmund.DE (Uwe Weimer)
To: rick@fmlrnd.co.uk
Subject: Re: UTP5, switched ethernet.
Content-Length: 504
Dear Rick,
we have a similar problem. Can you please forward the answers to me.
Thank you very mutch.
Uwe
-------------------------------------------------------------------------------
Uwe Weimer
University of Dortmund, LS Nachrichtentechnik
________ D-44221 Dortmund, F.R. Germany
U N I D O //// Phone +49 231 755 3195, FAX +49 231 755 3196
///////// wm@anna.e-technik.uni-dortmund.de
________/////////
\_\#\_\_\///////
\_\_\_\_\/////
\_\_\_\_\///
\_\_\_\_\/
>From mucs!alpha.ee.ufl.edu!jon Thu Apr 21 11:26:17 1994
Date: Thu, 21 Apr 94 06:19:44 EDT
From: "Jon Mellott" <jon@alpha.ee.ufl.edu>
To: rick@fmlrnd.co.uk
Subject: Re: UTP5, switched ethernet.
Content-Length: 1284
> From sun-managers-relay@cis.ufl.edu Thu Apr 21 06:01:18 1994
> Sender: sun-managers-relay@ra.mcs.anl.gov
> Date: Wed, 20 Apr 94 09:13:12 BST
> From: rick@fmlrnd.co.uk (Richard Read)
> Hello,
>
> I hope that somebody out there can help me.
>
> [...]
> Also, with the advent of ATM, vendors are offering SWITCHED ETHERNET
> hubs. Does anyone have performance related figures which compare switched
> and non switched hubs preferably with first hand experiance.
>
Actually, ATM has nothing to do with switched ethernet hubs. PCWeek had a
roundup of switched ethernet hubs a couple of weeks ago which you might
find useful. Personally, I'd consider hubs with FDDI, ATM, or Fast Ethernet
ports -- any of these can be a real win for a server connection since in
a switched ethernet environment a server could easily need much more than
the 10 Mbps Ethernet provides.
Alternatively you might consider getting Sun's quad Ethernet Sbus card.
A couple of these in your server(s) could nicely segment your network
for a lot less than Ethernet switches cost. Of course the performance
wouldn't be as good, but it'd be a lot better than a unsegmented
network architecture.
Jon Mellott
High Speed Digital Architecture Laboratory
University of Florida
(jon@alpha.ee.ufl.edu)
>From mucs!prin.ebasco.com!russ Thu Apr 21 13:26:27 1994
Date: Thu, 21 Apr 94 07:42:11 EDT
From: russ@prin.ebasco.com (Russ Bebb - 452-0130)
To: rick@fmlrnd.co.uk
Subject: Re: UTP5, switched ethernet.
Content-Length: 38
Rick, please summarize. Thanks, Russ
>From mucs!tatca.tc.faa.gov!cciolori Thu Apr 21 13:56:18 1994
Date: Thu, 21 Apr 1994 08:54:59 +0500
From: cciolori@tatca.tc.faa.gov (Chris Ciolorito)
To: rick@fmlrnd.co.uk
Subject: Re: UTP5, switched ethernet.
Content-Length: 1397
--> In order to avoid these problems, we have decided to change over to
-->UTP5. We have had a few company's in to talk to us and get quotes ready, I
-->don't want to have to choose on price competitiveness alone and would like to
-->hear any info regarding UTP5 and the problems/advantages with it.
-->
We currently are running UTP5 here for out twisted pair network and have
had no problems. The biggest gripe I have ever heard is that since the
cable is not shielded it is possible to have magnetic/electrical interference
mess up the signal and cause problems. My take on this theory: Baloney! In order
for that to happen you would somehow have to effect one pair alone...but not the
other three(Or one strand in a pair but not the other). This is REAL unlikely
since the pairs are twisted around each other for the entire length of the
cable.
Anyway, I really like the topology a lot. It is flexable and easy to work with
and has gotten pretty cheap lately. We actually bought the tools to make the
cable ourselves, and it's a snap!
There is an Ethernet FAQ around that I could send you if you are interested.
It has A LOT of info. on Ethernet and is generally very informative.
Chris...
--------------------------------------------------------------
Chris Ciolorito
CTA Inc. for FAA ACD-340
Atlantic City Int'l Airport
Atlantic City, NJ 08405
e-mail: cciolori@tatca.tc.faa.gov
>From mucs!endurance.nrlssc.navy.mil!peffley Thu Apr 21 14:28:20 1994
Date: Thu, 21 Apr 94 08:25:39 CDT
From: peffley@endurance.nrlssc.navy.mil (Monty B. Peffley)
To: rick@fmlrnd.co.uk
Subject: Re: UTP5, switched ethernet.
Cc: peffley@endurance.nrlssc.navy.mil
Content-Length: 1504
Rick,
We have installed category 5 UTP from a hub room to our offices.
We run Ethernet and FDDI on it (not simultaneously!).
The heart of the operation is an Alantec PowerHub, with 12 Ethernet
segment ports, and one FDDI port. The Alantec bridges between
those ports.
Since we have approximately 80 nodes, counting 55 Suns, a couple SGIs,
various Macs, PCs, printers, etc. these nodes are split into
12 groups and apportioned to one of the 12 Ethernet segments.
18 nodes are equipped with FDDI single-attach UTP interfaces,
and connect to an FDDI hub (hub and interfaces from Optical Data
Systems).
The UTP all runs to a patch panel in the hub room. Those nodes
sharing a physical Ethernet segment are "collected" by patching
them to a LANTronix 8-port UTP repeater, and the repeater
connected to the Alantec port. Although this arrangement does not
result in the ultimate in neatness in the hub room (a few extra
boxes and wires), it does give important flexibility in grouping
hosts on physical subnets.
The Alantec, which we operate in bridging mode, although it can
also route, allows us to treat all these nodes, Ethernet and FDDI,
as one logical subnet.
The UTP (AT&T's "High 5" category 5) has worked very well for Ethernet
and for our FDDI nodes. We were told (guaranteed?) that it will also
support ATM, and 100 Mbps Ethernet - haven't tried those though.
Hope this helps some.
Monty Peffley
Naval Research Lab
Stennis Space Center, MS 39529 peffley@nrlssc.navy.mil
>From mucs!endurance.nrlssc.navy.mil!peffley Thu Apr 21 15:48:17 1994
Date: Thu, 21 Apr 94 09:31:55 CDT
From: peffley@endurance.nrlssc.navy.mil (Monty B. Peffley)
To: rick@fmlrnd.co.uk
Subject: Re: UTP5, switched ethernet.
Content-Length: 262
Alantec's home office phone is: 408-955-9000
Customer service 800 # is: 800-252-6832
Customer service email: tech-support@alantec.com
Alantec
2380 Bering Drive
San Jose, CA 95131-1121
..............................
Good luck, Monty Peffley
>From mucs!uu5.psi.com!voyager!cwc.com!paul Thu Apr 21 15:48:40 1994
Date: Thu, 21 Apr 1994 08:42:18 +0500
From: paul@cwc.com (Paul McDonald)
To: r.read@fmlrnd.co.uk
Subject: Re: UTP5, switched ethernet
X-Sun-Charset: US-ASCII
Content-Length: 123
Rick,
When you get some info on Switched Ethernet, please pass it along, we're
in a similar situation here.
>From mucs!sandia.gov!jamervi Thu Apr 21 16:17:16 1994
Date: Thu, 21 Apr 1994 08:54:24 +0700
From: jamervi@sandia.gov (1236 Joseph A. Mervini)
To: rick@fmlrnd.co.uk
Subject: Re: UTP5, switched ethernet.
X-Sun-Charset: US-ASCII
Content-Length: 576
Rick,
Thin-net sucks...you run into problems with line lengths,etc. We use synoptics hubs for all our twp connections and it runs beautifully. So far we haven't gotten into atm but it is coming....
>From the standpoint of switching to an intelligent hub configuration, I would suggest synoptics. The reason I say this is a) we use it and b) synoptics (the company) works very closely with Sun in the development of their product.
Joe Mervini
Sandia National Labs Div. 1236
P.O. Box 5800
Albuquerque, NM 87185-1192
505-845-7253 Fax 505-845-7890
email: jamervi@sandia.gov
>From mucs!roses.rockwell.com!vandyk Thu Apr 21 16:17:22 1994
From: vandyk@roses.rockwell.com
Subject: Re: UTP5, switched ethernet.
To: rick@fmlrnd.co.uk
Date: Thu, 21 Apr 94 8:11:57 PDT
X-Hpvue$Revision: 1.8 $
Mime-Version: 1.0
Content-Type: Message/rfc822
X-Vue-Mime-Level: 4
Mailer: Elm [revision: 70.85]
Content-Length: 3421
content-type:text/plain;charset=us-ascii
mime-version:1.0
>
> I am currently trying to find a structured cabling solution for our network.
> We have 72 Sun Workstations currently connected via thin ethernet. We are
> experiencing many network down periods due to poor connections etc. and we
> can lose the whole network when this happens.
>
Thin Ethernet is notoriously unreliable in most environments
due to the stress that invariably occurs at connectors.
> In order to avoid these problems, we have decided to change over to
> UTP5. We have had a few company's in to talk to us and get quotes ready, I
> don't want to have to choose on price competitiveness alone and would like to
> hear any info regarding UTP5 and the problems/advantages with it.
The incremental cost with UTP5 compared to what we have (UTP3)
is nominal. Go with UTP5 to prepare for eventual ATM and 100
Mbps Ethernet migration. I wasn't in a position to make the
UTP3/5 decision here, but I sure wish we had grade 5.
With grade 3, we have a pretty hard limit at 100 meters for
Ethernet nodes. Even at grade 3, our cable plant is a joy
compared to our old hybrid of thick, thin, and repeaters.
We have not had any appreciable amount of "failures", although
a couple of the faceplates were dead-on-arrival after installation.
We are in a building that has about 2000 faceplates.
>
> Also, with the advent of ATM, vendors are offering SWITCHED ETHERNET
> hubs. Does anyone have performance related figures which compare switched
> and non switched hubs preferably with first hand experiance.
The introduction of switched hubs predated ATM. We are running
about 64 Ethernet segments from our FDDI backbone, most of them
switched segments from Synernetics LANplex 5xxx. (Synernetics
has been bought by 3com and is now a division thereof.)
We have verified throughput of 8-9 Mbits/second on segments under
somewhat artificial conditions - i.e., put a single fast machine
on a segment and copy large files from large servers on other
segments to that machine.
With your number of nodes (and you don't mention the class of machines
so I'll assume some mixture of SPARC 1,2, and 10) you probably want
a heirarchy of concentrators and switching hubs.
We built a heirarchical network out of FIBERMUX concentrators
(not a recommendation for FIBERMUX from me) and the Synernetics.
"Servers" in our environment get a dedicated/switched Ethernet
segment directly onto the FDDI backbone. "Clients" share a
switched segment with 10-20 other machines. The IP topology
is flat - i.e., we do no subnet routing internally with about
300 machines on our ring. We use a router to exit our ring
and go to the world. We have a mixture of Sun, HP, VAX, PC
devices.
There are two families of products from Synernetics:
The 5000 series uses FDDI technology as a backplane,
so works well if total throughput on the network is
100 Mbps sustained.
The 6000 series uses ATM-like technology, and is
supposed to offer Ethernet and FDDI switching as well
as ATM interfaces.
We did some evaluation of switching/bridging hubs a couple years
ago when we bought and found that testing in your own environment
is absolutely critical. Try before you buy, or risk investing in
a solution that is unreliable at high traffic loads.
Mike Van Dyk
I speak for absolutely nobody besides myself.
>From mucs!gomez.intel.com!skhalid Thu Apr 21 16:48:01 1994
From: skhalid@gomez.intel.com (Syed Khalid ~)
Subject: Re: UTP5, switched ethernet.
To: rick@fmlrnd.co.uk
Date: Thu, 21 Apr 1994 08:30:07 -0700 (PDT)
Cc: syedk@netcom.com
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1729
>
> Hello,
>
> I hope that somebody out there can help me.
>
> I am currently trying to find a structured cabling solution for our network.
> We have 72 Sun Workstations currently connected via thin ethernet. We are
> experiencing many network down periods due to poor connections etc. and we
> can lose the whole network when this happens.
>
> In order to avoid these problems, we have decided to change over to
> UTP5. We have had a few company's in to talk to us and get quotes ready, I
> don't want to have to choose on price competitiveness alone and would like to
> hear any info regarding UTP5 and the problems/advantages with it.
>
> Also, with the advent of ATM, vendors are offering SWITCHED ETHERNET
> hubs. Does anyone have performance related figures which compare switched
> and non switched hubs preferably with first hand experiance.
>
> All information is glady received.
>
>
> Rick Read
> Senior Systems Administrator E-Mail r.read@fmlrnd.co.uk
> Fujitsu Microelectronics Ltd Fax No 061-230-6276
> Vaughan St Tel 061-230-6262
> Manchester
> M12 5DU
> England
>
Hi Rick,
You might want to look at the March '94 issue of "Data Communications"
magazine which has an article comparing some of the leading Switched Ethernet
Hubs. Definitely UTP5 is the way to go. Almost all new sites here (in the US)
are going UTP5 which offers better reliability and flexibility. Also with
10BaseT hubs you get better network management such as icons showing you
which ports are active and which are not. You can lock out ports or they
lock themselves out in event of high error rates.
I'd be interested in hearing about the resposes you get.
Good luck!
Syed Khalid
>From oberman@ptavv.llnl.gov ()
Newsgroups: comp.sys.sun.hardware,comp.dcom.lans.ethernet
Subject: Re: Token ring vs. Ethernet.
Date: 12 Nov 93 00:14:42 GMT
In Article <1993Nov11.211519.8673@exlog.com>
lparsons@exlog.com (Lee Parsons) writes:
>I had a Professor once who clearly felt that Token Ring was a technical win.
>
>His argument was that:
>
>1) TR provided better bandwidth utilization
> (TR starts where ethernet peaks)
Partly true.
>2) TR is more reliable in a environment where real work is to be done
> because each node is guaranteed a slice of the network in a predictable
> time frame.
Guess he has his own definition of "real work", but this is only theoretically
true. Token rings are a management pain. Ever hear of lost tokens? Ethernets
are quite reliable and sales in the millions of attachments imply that it must
be working for someone doing real work.
If he meant "real-time" work, that has a nugget of truth. But the spectrum of
real time operations for which TR is acceptable when Ethernet is not is pretty
small.
>3) TR is better because the performance decrease as you add a node is
> linear where in ethernet it is exponential.
This is NOT true. He needs to look at his math. TR is linear and Ethernet is
worse, but it's nowhere near exponential. (I'm assuming he does not mean an
exponent of <2, but even then the curve is not truely exponential.)
>4) The only reason people use ethernet is price and with the IBM
> patent challenges the price of TR would come down to ethernet levels.
Must have been an IBM share holder. TR is simply more complex. It is unlikely
that TR will ever be as cheap as Ethernet, patents or not. It might also be
noted that even IBM seems to be starting to jump on the Ethernet bandwagon.
It's amazing what a few billion in losses can do.
>I didn't entirly agree with him but you don't argue with the guy
>giving out the grade.
>
>If ethernet can only push the wire to < 50% utilization before
>collisions start to eat your lunch but, TR can operate effectively
>long after 50%, doesn't that way heavily in TR's favor?
And when did you stop beating your wife?
If I could only push Ethernet to 50% you might have something, but I see
Ethernet routinely running at 70% utilization with good performance. There are
some excellent papers, one in particular that I can't find right now, that
analyze real, not theoretical Ethernets and debunk a great number of the pro-TR
arguments.
R. Kevin Oberman Lawrence Livermore National Laboratory
Internet: koberman@llnl.gov (510) 422-6955
Disclaimer: Being a know-it-all isn't easy. It's especially tough when you
don't know that much. But I'll keep trying. (Both)
>From roy@mchip00.med.nyu.edu (Roy Smith)
Newsgroups: comp.sys.sun.hardware,comp.dcom.lans.ethernet
Subject: Re: Token ring vs. Ethernet.
Date: 12 Nov 93 00:30:57 GMT
lparsons@exlog.com (Lee Parsons) writes:
> If ethernet can only push the wire to < 50% utilization before
> collisions start to eat your lunch but, TR can operate effectively
> long after 50%, doesn't that way heavily in TR's favor?
>
> What was he leaving out?
Let's assume you can install a 10 Mbps ethernet for 1/3 the price of
a 16 Mbps token ring. Let's further entertain your suggestion that you can
only get 50% utilization (i.e 5 Mbps) out of the ethernet, or roughly 1/3
the effective bandwidth of the 16 Mbps token ring. No problem, since you've
only paid 1/3 as much for the ethernet as for the token ring, you can afford
to put in 3 of them for the same price.
I will gladly admit that any or all of the numbers used in the
example above could be wrong, but the gist is the same. Whatever technical
advantages token ring might possibly have (assuming it really does have
any), in the real world, it's just plain so much more expensive than
ethernet that it's hard to see how it makes sense to put it in.
-- Roy Smith <roy@nyu.edu> Hippocrates Project, Department of Microbiology, Coles 202 NYU School of Medicine, 550 First Avenue, New York, NY 10016 "This never happened to Bart Simpson.">From lstowell@pyrnova.mis.pyramid.com (Lon Stowell) Newsgroups: comp.dcom.lans.ethernet Subject: Re: Token ring vs. Ethernet. Date: 12 Nov 93 00:57:31 GMT
In article <1993Nov11.211519.8673@exlog.com> lparsons@exlog.com (Lee Parsons) writes: > >I had a Professor once who clearly felt that Token Ring was a technical win. "Felt" being the appropriate term.
> >His argument was that: > >1) TR provided better bandwidth utilization > (TR starts where ethernet peaks)
380 Kbyte is faster than 900-1100 Mbyte?
As far as 16 Mbps token ring, I don't know of a lot of implementations that can drive it at 90+% utilization. > >2) TR is more reliable in a environment where real work is to be done > because each node is guaranteed a slice of the network in a predictable > time frame.
True in theory. There is even a priority scheme at the MAC level. Problem is lack of implementing products.
> >3) TR is better because the performance decrease as you add a node is > linear where in ethernet it is exponential. > Only if you believe the TI/IBM literature.
>4) The only reason people use ethernet is price and with the IBM > patent challenges the price of TR would come down to ethernet levels. >
Odd, the patent challenge was filed by Madge.
> >I didn't entirly agree with him but you don't argue with the guy >giving out the grade. > good point.
>If ethernet can only push the wire to < 50% utilization before >collisions start to eat your lunch but, TR can operate effectively >long after 50%, doesn't that way heavily in TR's favor? > The SGI boxes regularly drive much faster than that.
It IS true that if you overload an ethernet, the aggregate thruput tends to go to 500 or less....but 700-900 is not that uncommon. >What was he leaving out? > Practical experience.
Odd. He left out the mission-critical and security advantages of Token Ring entirely...about the only area where it still has a slight advantage over even 10BaseT ethernet.
>From rolfkap@glum.engin.umich.edu (Rolf Thomas Kappe) Newsgroups: comp.sys.sun.hardware,comp.dcom.lans.ethernet Subject: Re: Token ring vs. Ethernet. Date: 11 Nov 93 23:17:11 GMT
In article <1993Nov11.211519.8673@exlog.com>, lparsons@exlog.com (Lee Parsons) writes: > In article <2bqt5cINN87q@faatcrl.faa.gov> cciolori@tatca.tc.faa.gov writes: > >Hmm? I don't seem to be getting any response to this > >question, so I'll ask it again: > > > >What are the pros/cons of using Ethernet vs Token Ring? > >If I were designing a network, what would make me choose > >one over the other? > > I had a Professor once who clearly felt that Token Ring was a technical win. > > His argument was that: > > 1) TR provided better bandwidth utilization > (TR starts where ethernet peaks) > > 2) TR is more reliable in a environment where real work is to be done > because each node is guaranteed a slice of the network in a predictable > time frame. > > 3) TR is better because the performance decrease as you add a node is > linear where in ethernet it is exponential. > > 4) The only reason people use ethernet is price and with the IBM > patent challenges the price of TR would come down to ethernet levels. > > > I didn't entirly agree with him but you don't argue with the guy > giving out the grade. > > If ethernet can only push the wire to < 50% utilization before > collisions start to eat your lunch but, TR can operate effectively > long after 50%, doesn't that way heavily in TR's favor? > > What was he leaving out? > > -- > Regards, > > Lee E. Parsons Baker Hughes Inteq, Inc > Oracle Database Administrator lparsons@exlog.com Ever try to make an IBM token ring cable? It's a real pain. Fills up cable trays in a hurry as well. Not very cheap to run long distances, because you have so many more wires than ethernet. If you have a fairly large size network you will be spending a lot more on cabling and installation time, which an IBM patent challege won't make any cheaper. But the TR technology is better for sure, which is why it is used in FDDI / Pro-Net, etc.
--Rolf ------------------------------------------------- Rolf Kappe Computer Aided Engineering Network, U of M College of Engineering rolfkap@engin.umich.edu
>From lindsay@dscatl.atl.ga.us (Lindsay Cleveland) Newsgroups: comp.dcom.lans.ethernet Subject: Re: Ethernet vs. Token-Ring Date: 12 Nov 93 04:13:33 GMT
In article <CG8ItK.6FM@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In article <2blp69INNrs1@faatcrl.faa.gov> cciolori@tatca.tc.faa.gov writes: >>What are the pros/cons of having a LAN on an Ethernet >>based network as opposed to Token-Ring? If you were >>designing a network, what items would make you choose >>one over the other? > >I can't imagine what would make me choose Token Ring, unless it were part >of a network operation that already had a lot of TR gear in use. Ethernet >is cheaper and support for it is far more widespread. There are no really >compelling technical advantages to either side. > >The bottom line, really, is that in this speed range -- 10 plus-or-minus >a few Mbps -- Ethernet is the world standard and Token Ring is an also-ran. >The Ethernet market is so much bigger that prices are much lower and a much >greater range and variety of hardware is available. One would not use TR >without some very special reason.
For the past past two years I have worked with a product that we run over either Token-Ring or Ethernet, depending upon what the customer requests and/or already has in place. For the most part, there is no difference in overall performance on these LAN's since they ususally have less than 10 nodes.
But we have had problems! Occasionally customers ask for something "other than our supported line", such as a network printer to be used for both TCP/IP and Novell IPX support. They already had the printer (no network interface) and wanted us to "hook it up". No problem, you say...just get a little Lantronix 'print server' box and let it handle everything. But a quick call to Lantronix reveals they only have an Ethernet version and no immediate plans for a Token-ring version.
Or you might like to use the "nifty-keen" Telebit Netblazer-P (modem and router and network interface all in a nice reasonably-priced modem-sized box) to provide a dial-up link to the home office. Well, it is a very new product and is currently being delivered in an Ethernet version, but a Token-ring version is not currently available (and may never be offered).
There are more examples, but I think you get the drift. A manufacturer has to balance the size of the expected market against the cost of developing a product. The decision usually runs: "Let's get an Ethernet version out first and see if we can recover our development costs. Afterward we might come up with a Token-ring version if there seems to be enough demand, and if we have people to spare for the project, and if we aren't in the middle of developing another new product that needs our attention, and ..."
Cheers, Lindsay
Lindsay Cleveland Digital Systems Co, Inc, Atlanta GA gatech!dscatl!lindsay (404) 497-1902 lindsay@dscatl.atl.ga.us (U.S. Mail: PO Box 1149, Duluth GA 30136)
>From asmith@acorn.co.uk (Andy Smith) Newsgroups: comp.dcom.lans.ethernet Subject: Re: Ethernet Bible? Date: 18 Nov 1993 08:50:21 -0000
amym@oakhill.sps.mot.com (Amy Moseley Rupp) writes:
>For C it could be K&R, for UNIX maybe the Bach book... are there any >classic Ethernet primers? Of course there are the IEEE specs, but
For Ethernet its Computer Networks by Tanambaun, published by Prentice Hall, For the TCP/IP protocols and Internet its Internetworking with TCP/IP by Comer, published by Prentice Hall. This one now comes as 3 volumes, but unless you are programming, you only really need the first one.
>Amy Moseley Rupp Finally mum-mum-mum to Elizabeth AnneMarie,
Andy Smith Systems and Networks specialist
----- End Included Message -----
Rick Read Senior Systems Administrator E-Mail r.read@fmlrnd.co.uk Fujitsu Microelectronics Ltd Fax No 061-230-6276 Vaughan St Tel 061-230-6262 Manchester M12 5DU England
----- End Included Message -----
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:01 CDT