Summary - UTP5, switched ethernet.

From: Richard Read (
Date: Wed May 18 1994 - 23:45:37 CDT

Hello all,

        I apologise for the delay in sending out a summary, but here it is.

My Original message was :-


        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. ( Ed Strong ) (Phill St-Louis) (Jon Mellott) (Chris Ciolorito) (Monty B. Peffley) (1236 Joseph A. Mervini) (Mike Van Dyk) (Syed Khalid) (B.McCrone) (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!!cciolori Thu Apr 21 16:48:07 1994
Date: Thu, 21 Apr 1994 11:34:52 +0500
From: (Chris Ciolorito)
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!!


                  Ethernet Network Questions and Answers
           Summarized from UseNet group comp.dcom.lans.ethernet
                       Version 2.11 of 19 April 1992
    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 ( 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, 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 <>
            John Breeden <>
            TP Brisco <>
            Peter Desnoyers <>
            Daniel Huber <>
            Bob Jaques <>
            Paul Joslin <>
            Dave Kapalko <>
            Rich Lawrence <>
            Nick Hennenfent <>
            Ray Hunter <rhunter@esoc.BITNET>
            Mark Medici <>
            Dave Mitton <???>
            Rich Seifert <>
            Charles Spurgeon <>

         (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

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

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

        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
            10Base5 limited to 500 meters (1,640 ft) per unrepeated cable
            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

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

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

        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

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

        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

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

        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

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

        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 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 "") by Charles
        Spurgeon, available via anonymous FTP from 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

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
          (800) 678-IEEE

        You can also get order information via e-mail to

07.04Q: Where can I get EIA/TIA docs online?
     A: Nowhere. They must be ordered from:

          Global Engineering

        (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 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 in path pub/novell/DOCS as Ethernet.FAQ.

Fiber, from Raylan
We have 200 on our network and are very happy with it.

>From mucs!!ems Thu Apr 21 00:37:36 1994
From: (Ed Strong)
Date: Wed, 20 Apr 94 15:11:20 EDT
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!!phill2 Thu Apr 21 07:16:50 1994
Date: Wed, 20 Apr 94 23:22:53 PDT
From: Phill St-Louis <>
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.


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

>From mucs!!jon Thu Apr 21 11:26:17 1994
Date: Thu, 21 Apr 94 06:19:44 EDT
From: "Jon Mellott" <>
Subject: Re: UTP5, switched ethernet.
Content-Length: 1284

> From Thu Apr 21 06:01:18 1994
> Sender:
> Date: Wed, 20 Apr 94 09:13:12 BST
> From: (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

>From mucs!!russ Thu Apr 21 13:26:27 1994
Date: Thu, 21 Apr 94 07:42:11 EDT
From: (Russ Bebb - 452-0130)
Subject: Re: UTP5, switched ethernet.
Content-Length: 38

Rick, please summarize. Thanks, Russ

>From mucs!!cciolori Thu Apr 21 13:56:18 1994
Date: Thu, 21 Apr 1994 08:54:59 +0500
From: (Chris Ciolorito)
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

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 Ciolorito
CTA Inc. for FAA ACD-340
Atlantic City Int'l Airport
Atlantic City, NJ 08405

>From mucs!!peffley Thu Apr 21 14:28:20 1994
Date: Thu, 21 Apr 94 08:25:39 CDT
From: (Monty B. Peffley)
Subject: Re: UTP5, switched ethernet.
Content-Length: 1504


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

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

>From mucs!!peffley Thu Apr 21 15:48:17 1994
Date: Thu, 21 Apr 94 09:31:55 CDT
From: (Monty B. Peffley)
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:

2380 Bering Drive
San Jose, CA 95131-1121


Good luck, Monty Peffley

>From mucs!!voyager!!paul Thu Apr 21 15:48:40 1994
Date: Thu, 21 Apr 1994 08:42:18 +0500
From: (Paul McDonald)
Subject: Re: UTP5, switched ethernet
X-Sun-Charset: US-ASCII
Content-Length: 123


When you get some info on Switched Ethernet, please pass it along, we're
in a similar situation here.

>From mucs!!jamervi Thu Apr 21 16:17:16 1994
Date: Thu, 21 Apr 1994 08:54:24 +0700
From: (1236 Joseph A. Mervini)
Subject: Re: UTP5, switched ethernet.
X-Sun-Charset: US-ASCII
Content-Length: 576


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

>From mucs!!vandyk Thu Apr 21 16:17:22 1994
Subject: Re: UTP5, switched ethernet.
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


> 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
        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!!skhalid Thu Apr 21 16:48:01 1994
From: (Syed Khalid ~)
Subject: Re: UTP5, switched ethernet.
Date: Thu, 21 Apr 1994 08:30:07 -0700 (PDT)
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
> 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 ()
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 <> (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

>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

R. Kevin Oberman Lawrence Livermore National Laboratory
Internet: (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 Smith)
Newsgroups: comp.sys.sun.hardware,comp.dcom.lans.ethernet
Subject: Re: Token ring vs. Ethernet.
Date: 12 Nov 93 00:30:57 GMT (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 <>
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 (Lon Stowell) Newsgroups: comp.dcom.lans.ethernet Subject: Re: Token ring vs. Ethernet. Date: 12 Nov 93 00:57:31 GMT

In article <> (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 (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 <>, (Lee Parsons) writes: > In article <> 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 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

>From (Lindsay Cleveland) Newsgroups: comp.dcom.lans.ethernet Subject: Re: Ethernet vs. Token-Ring Date: 12 Nov 93 04:13:33 GMT

In article <> (Henry Spencer) writes: >In article <> 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 (U.S. Mail: PO Box 1149, Duluth GA 30136)

>From (Andy Smith) Newsgroups: comp.dcom.lans.ethernet Subject: Re: Ethernet Bible? Date: 18 Nov 1993 08:50:21 -0000 (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 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