[geeks] Seeking network direction.

[der Mouse]

> I'm trying to understand somethings about how ethernet works.  [...]

Well, I'm hardly an authority, but perhaps I can help with some of your
questions.

> I was talking to someone with a weird problem.  His device would talk
> to his PC when connected via cross-over.  When both were plugged into
> a Cisco 2900 switch, communications between the devices would work,
> but the show-mac-addresses (or whatever the specific command is
> because I'm not a cisco guy) wouldn't show the device's MAC,

That sounds to me like a Cisco bug - or, perhaps, a device that's using
a multicast MAC and a Cisco that would rather flood all multicasts and
thus doesn't learn multicast MACs.  Was the first octet of the device's
MAC odd?  The low bit is the multicast bit.  Or it could be an
autonegotiation failure.

> When plugged into a Cisco 3550, a connection was shown, but no
> communications happened between any other PC and the device.

That argues for the "Cisco bug" theory, but I'm mostly speculating in a
vacuum here.  It also might be that autonegotiation failure.

> I know that ARP used to map IP addresses to MAC addresses (data link
> layer addresses), and I know that MAC addresses are to uniquely
> identify devices on an ethernet network and I know about ethernet
> frame sizes, but I know nothing else about ethernet and how devices
> negotiate.  Is this what the spanning tree protocol does?

No, spanning tree is layered above Ethernet.

Modern "Ethernet" is a bit of a bastardization of the original.
Ethernet was originally a piece of co-ax cable over which carrier was
sent (10base5, and other, older, now even more forgotten variants such
as a 3Mbit version).  Then the co-ax was thinned down and the
transceiver was moved into the machine (10base2, "thinnet",
"cheapernet", but basically the same thing - you could even stick a
passive adapter between thicknet co-ax and thinnet co-ax to paste the
two together, since the carriers and encodings were the same).

This used CSMA/CD - Carrier Sense, Multiple Access / Collision Detect.
Each station's carrier is received by all other stations' hardware, and
if two stations try to start talking at the same time, they notice
they're receiving more than their own carrier and randomly back off and
retry (this is a "collision").  MAC addresses were understood by the
hardware enough to tell whether to bother the host with each packet.
(Note the destination MAC is the first data in an Ethernet frame, right
after channel seizure.)

Then came 10baseT, twisted pair, which is the same physical layer as
today's Ethernet (except for cable quality - 10baseT doesn't require
cable specs as precise as CatV's).  This is a point-to-point
technology, not a bus technology; 10baseT hubs are basically signal
repeaters to provide the bus effect.  Then things got interesting with
100baseTX and MAC-learning (and speed-adapting) switches...

...and that's where spanning tree became important.  Once the physical
layer became point-to-point instead of a bus, switches (which are
basically the Ethernet-layer analog to what are usually called
"routers" at the IP layer) arose.  This then raised the possibility of
topology loops.  (A loop with hubs and real bus media is possible but
substantially less likely to occur accidentally.)  Since it's
reasonable to want the physical redundancy that a non-tree topology
provides, rather than just saying "don't do that", someone invented
spanning tree.  Spanning tree is a protocol designed to detect non-tree
topologies and deliberately down links to convert them into trees for
operational purposes - with ongoing monitoring so that if a link in use
goes dead, a redundant link (if present) will soon be brought back into
operation to take over.  Except for how addresses are assigned
(randomly) and routes created (learned by snooping), spanning tree loop
detection is very much like loop detection in IP-layer routing
protocols.

Autonegotiation, which I mentioned above, is a completely separate and
even lower-layer thing.  With the advent of 100baseTX, people wanted to
build devices which could plug into either 10baseT or 100baseTX on the
same port.  This required speed auto-sensing.  And, with the switch
from a bus technology to a point-to-point technology, someone noticed
there was no longer any need to echo carrier back to the host; data
could in principle be sent in both directions at once.  This is
full-duplex, leading to four possibilities (10 vs 100, cross product
with full-duplex vs half-duplex).  So someone invented protocols via
which devices could negotiate which speed and duplex settings to use.
There were some rough edges; even today people still run into
autonegotiation failures, especially with older gear, and that's one of
the possible problems leading to the failures you saw.  These days
there's also GigE, a fifth possibility to autonegotiate (just one, not
two, more - GigE is always full-duplex).

There's also auto-X.  For 10baseT, one pair is used for data in one
direction, another for data in the other (the other two pairs commonly
wired up are not used for anything).  100baseTX is the same in this
regard; it just uses different carrier frequencies and suchlike.  In
each case, though, one pair is data one way and the other, the other.
However, rather than designing it sensibly, always using (say) the 1/2
pair for transmit and the 3/6 pair for receive, we have the mess of hub
interface and host interface and the question of whether you need a
straight-through or crossover cable.  (This is basically the same
mistake serial lines made.  You'd think people would learn....)  Auto-X
is a technology which resolves this mess, figuring out which pair to
use for which direction.

> Also, what is the relationship between AUI, AAUI, MII, and the phy
> chip on a embedded design that seems to say it speaks MII?

I'm not very sure.  AUI is the interface between a host and a
transceiver.  Originally this was for thicknet, but people came out
with 10base2 and 10baseT transceivers.

AAUI is an Apple mutant AUI.  I _think_ it's electrically AUI but on a
totally mechanically different connector.

MII and phy chips I don't really understand.

> Also, I seem to recall once setting up a box with a lot of 15 pin
> connectors on it.  I believe a AUI adapter went on one of these to
> connect this box to a Cat5 switch, while the other 15 pin connectors
> were connected via 15 pin cables directly to an Onyx, a Sun 4/330,
> and a few IPC/IPX machines.  What was that thing?

An AUI multiport repeater.  That DA15 is the original (well, as far as
the mass market goes) AUI connector.  The box is basically a multi-way
signal repeater, presenting N transceiver interfaces to the hosts and
one host interface to the real transceiver.  (Some such boxes can be
run without any real transceiver, too, for small networks.)

> I think it was referred to as a thicknet hub.

A common but, strictly, somewhat inaccurate term.  To the extent it was
truly a hub, it was actually an AUI hub; whether the real transceiver,
if any, spoke thicknet, thinnet, twisted pair, or something else, was
completely outside its purview.  But, while thinnet and twisted-pair
could use AUI-interface transceivers but didn't have to, thicknet
always did, and so in people's minds thicknet and AUI got tied
together.

And I'm not sure it's really accurate to call it even an AUI hub.  A
hub would normally be at the centre of the network, and AUI multiport
repeaters weren't that (well, except when run without real
transceivers); they were just concentrators.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse at rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B