🚀 go-pugleaf

In article <1992Oct26.143025.164889@dstos3.dsto.gov.au>, bennett@dstos3.dsto.gov.au writes:
>From: bennett@dstos3.dsto.gov.au
>Newsgroups: comp.protocols.ibm
>Subject: What is an 8209 - really ?
>Date: 26 Oct 92 14:30:25 CST
>
>Strictly speaking 'bridge' is a misnomer, but I'm not sure what exactly it 
>is.  Could someone please enlighten me with a brief description of the 8209, 
>particularly with regard to LAN addresses.
>
>John Bennett                                E-mail: bennett@dstos3.dsto.gov.au

	The IBM 8209 behaves is two different modes. But first let me
describe the hardware. 
	The base unit is "powered" by two 10 Mhz 8086's and has a Token Ring
interface, and a "slot" to insert an option module.  There are three options
that have been made.  The original Ethernet, an Enhanced Ethernet, and a
Token Ring interface.  The option modules have a small DIP switch on them
and the bridge can also be controlled by a PC program attached to either LAN.

	If you insert the Token Ring option, the 8209 is a basic Source Routing
Bridge, pure and simple.

	If you insert one of the Ethernet modules, the 8209 becomes what
is best called a Translating SR-ST Bridge.  It does two major things
and a lot of minor things.

	1) It does Source Routing on the Token Ring side, Spanning Tree
transparent (802.1d) bridging on the Ethernet side.  Neither bridging domain
is integrated however, and remain ignorant of each other.  Both bridges
assign a virtual LAN number to the other domain.
The ST bridge listens for source addresses on the Ethernet and will forward
frames into the Token Ring. The SR side will forward frames onto the Ethernet
(stripping the RIF) if the RIF calls out the Ethernet "ring" number.
Multicasts and SR Explorers get the obvious (and not so) special treatments.
[I don't have time to explain it all, and it's not all documented]
Basically, it strips and inserts source routes for packets transitioning
the bridge.

	2) It does 802.2 to Ethernet frame format conversions.
Packets coming from the Ethernet are changed into 802.2 UI frames useing
the SNAP SAP, and a three byte zero OUI field.  There is an option to
recognized an older IBM encapsulated LLC format (ptype 80-D5) by DSAP.
SNAP frames coming from the TR to the Ethernet face a choice, do they get
put back into Ethernet frame format or 802.3 format?

There are two modes and DIP switches to control them.  One mode says
translate all frames into one or the other (controlled by the other switch).
Note that setting to Ethernet will trash frames that are SNAP with non-zero 
OUI.
The other mode is "Auto-Detect" which will remember the _first_ frame type
seen from the station on the Ethernet side, and translate into that format.
Note that this means, that an Ethernet station that can speak multiple
frame formats (Ethernet and 802.3) will confuse the 8209 and a coin-flip 
says that it will acquire the wrong format.  It's clear that it's designers
did not conceive of this possibility.

In Auto-Detect mode, a multicast frame doesn't have a destination address
to look up the format, so the 8209 sends the packet TWICE, once in each
format.

	Other things that the 8209 does is compensate for some known
protocol differences between the medias.
	- It can recognize ARP messages and fix the media type and bit order
of addresses in the frame as it forwards it.
	- With the Enhanced Ethernet (EE) option it can translate 32 MAC
addresses into another address as it forwards the frame.  This mapping 
is bidirectional, but cannot be tied to a specific protocol type.


	well.. there are some more features, and characteristics, etc.
Getting it's performance is a matter of reading the marketing literature.
Note that I am not an unbiased source of information.

	The 8209 was designed to support simple networks with only
IBM SNA, NETBIOS transport, or TCP/IP on them.  Other protocol stacks
and implementations may not work well with the simple assumptions of this
bridge.

	Dave Mitton
	Token Ring Program
	Digital Equipment Corp.