20 Feb
2019
20 Feb
'19
11:13 a.m.
re: Cisco and IBM protocols
If you're really interested, all of this is exhaustively documented
under the umbrella of Cisco's "IBM Feature Set". There's a *lot* here
under the hood, but the last time I looked (admittedly, a while) a
number of folks had web sites that documented the correct incantations
for Hercules and common hardware.
You can bridge between TR (and FDDI) and ethernet on a Cisco,
generally for non-routable protocols (e.g. NetBIOS); see:
'translational bridging'. If you're trying to get these protocols
across an intermediary 'alien' network (like the corp FDDI backbone,
or the Internet), there are things like DLSw.
If you're trying to get TCP/IP from TR to ethernet and vice versa,
routing generally works better/is simpler (IME), but Cisco has all
sorts of bizarre encapsulation/translation features for different use
cases should you need them.
You can also make the router look like an SNA concentrator (PU?).
KJ
20 Feb
20 Feb
11:23 a.m.
On Feb 20, 2019, at 2:13 PM, Ken Seefried via cctalk
<cctalk at classiccmp.org> wrote:
...
You can bridge between TR (and FDDI) and ethernet on a Cisco,
generally for non-routable protocols (e.g. NetBIOS); see:
'translational bridging'. If you're trying to get these protocols
across an intermediary 'alien' network (like the corp FDDI backbone,
or the Internet), there are things like DLSw.
Please note that among LANs, there is Token Ring (802.5) and there is everything else.
FDDI is like Ethernet and like 802.4. Token Ring is the oddball because (a) it
doesn't have proper multicast addresses, and (b) for some reason IBM invented
source-routed bridging and tied that to Token Ring.
FDDI is in no way at all like Token Ring. The only thing the two have in common is
"token" and "ring". The MAC protocol is utterly different; the
closest relative is 802.4 Token Bus. And as far as addressing is concerned, FDDI is like
802.4 and Ethernet, with real multicast and general use of normal transparent bridges.
The only complication with FDDI (and 802.4, if you could find it) is that it only has
802.2 frames, not classic-Ethernet (with 16 bit protocol types). So an FDDI to Ethernet
bridge has to translate Ethernet frames to an 802.2 based encapsulation. That is done by
converting them to SNAP frames, as described in RFC 1042. Bridges like the DECbridge 500
and DECbridge 900 will do that; I assume Cisco does likewise.
FDDI didn't live all that long because 100 Mb Ethernet replaced it, but while it was
out there it made a fine backbone for Ethernet-based LANs.
paul
1:09 p.m.
On Wed, Feb 20, 2019 at 2:23 PM Paul Koning <paulkoning at comcast.net> wrote:
I didn't say TR was like FDDI. I said you could bridge FDDI to
Ethernet using translation bridging.
On Feb 20, 2019, at 2:13 PM, Ken Seefried via
cctalk <cctalk at classiccmp.org> wrote:
...
You can bridge between TR (and FDDI) and ethernet on a Cisco,
generally for non-routable protocols (e.g. NetBIOS); see:
'translational bridging'. If you're trying to get these protocols
across an intermediary 'alien' network (like the corp FDDI backbone,
or the Internet), there are things like DLSw.
Please note that among LANs, there is Token Ring (802.5) and there is everything else.
FDDI is like Ethernet and like 802.4. Token Ring is the oddball because (a) it
doesn't have proper multicast addresses, and (b) for some reason IBM invented
source-routed bridging and tied that to Token Ring.
FDDI is in no way at all like Token Ring. The only thing the two have in common is
"token" and "ring". The MAC protocol is utterly different; the
closest relative is 802.4 Token Bus. And as far as addressing is concerned, FDDI is like
802.4 and Ethernet, with real multicast and general use of normal transparent bridges.
8:26 p.m.
On 2/20/19 12:13 PM, Ken Seefried via cctalk wrote:
re: Cisco and IBM protocols
If you're really interested, all of this is exhaustively documented
under the umbrella of Cisco's "IBM Feature Set".
Thank you Ken. That's the type of information I'm wanting to figure out.
There's a *lot* here under the hood, but the last
time I looked
(admittedly, a while) a number of folks had web sites that documented
the correct incantations for Hercules and common hardware.
You can bridge between TR (and FDDI) and ethernet on a Cisco, generally
for non-routable protocols (e.g. NetBIOS); see: 'translational bridging'.
That meshes with what I think I've managed to figure out.
Both SNA and NetBIOS use 802.2 LLC frames with SNAP headers. Token Ring
and Ethernet are able to carry that without any problem. Hence why they
can be relatively bridged bridged without extensively modifying the frames.
If you're trying to get these protocols across an
intermediary 'alien'
network (like the corp FDDI backbone, or the Internet), there are things
like DLSw.
I learned that while reading this week. Now I want to see if DLSw can
be used to connect two Windows machines using NetBIOS across an
intermediary 'alien' network running TCP/IP. }:-)
If you're trying to get TCP/IP from TR to ethernet
and vice versa,
routing generally works better/is simpler (IME),
ACK Bridging between TCP/IP on 802.2 LLC frames with SNAP on Token Ring
to Ethernet II frames on Ethernet is not nearly as simple. Especially
when routing inherently handles it. Even Proxy ARP is a form of routing.
but Cisco has all sorts of bizarre
encapsulation/translation features
for different use cases should you need them.
*nod*
I'm sure I'll find more information than is healthy for me to learn.
You can also make the router look like an SNA
concentrator (PU?).
~whimper~ I don't need to think about that.
I'd love to get a pair of mainframe (VMs?) running in a (non-Parallel)
sysplex between a couple of Hercules instances. The idea of using a
router as an SNA PU is ? intriguing.
--
Grant. . . .
unix || die
8:31 p.m.
On 2/20/19 12:23 PM, Paul Koning via cctalk wrote:
Please note that among LANs, there is Token Ring
(802.5) and there is
everything else.
I think it really depends on how you look at them.
From a frame formatting point of view, Ethernet is the odd ball when
looking at how TCP/IP is carried.
Everything other than Ethernet (802.3) uses 802.2 or a medium specific
varient of 802.2. Then there's Ethernet which predominantly uses either
Ethernet II for TCP/IP or 802.3 (a.k.a. "Raw") Ethernet frames for IPX.
FDDI is like Ethernet and like 802.4. Token Ring is
the oddball because
(a) it doesn't have proper multicast addresses, and (b) for some reason
IBM invented source-routed bridging and tied that to Token Ring.
Does it actually need a broadcast address like Ethernet when the ring
passes through all the stations? Or is that functionally comparable to
a multicast?
FDDI is in no way at all like Token Ring. The only
thing the two have
in common is "token" and "ring". The MAC protocol is utterly
different;
the closest relative is 802.4 Token Bus. And as far as addressing is
concerned, FDDI is like 802.4 and Ethernet, with real multicast and
general use of normal transparent bridges.
The only complication with FDDI (and 802.4, if you could find it)
is that it only has 802.2 frames, not classic-Ethernet (with 16 bit
protocol types). So an FDDI to Ethernet bridge has to translate Ethernet
frames to an 802.2 based encapsulation. That is done by converting them
to SNAP frames, as described in RFC 1042.
Intriguing.
$ReadingList++
Bridges like the DECbridge 500 and DECbridge 900 will
do that; I assume
Cisco does likewise.
FDDI didn't live all that long because 100 Mb Ethernet replaced it, but
while it was out there it made a fine backbone for Ethernet-based LANs.
:-)
--
Grant. . . .
unix || die
21 Feb
21 Feb
6:43 a.m.
On Feb 20, 2019, at 11:31 PM, Grant Taylor via cctalk
<cctalk at classiccmp.org> wrote:
On 2/20/19 12:23 PM, Paul Koning via cctalk wrote:
"raw 802.3" is a bug, caused by a programmer not understanding how the specs
work.
The mapping from Ethernet to 802.2 SNAP is trivial, but yes, you do need that mapping.
Please note that among LANs, there is Token Ring
(802.5) and there is everything else.
I think it really depends on how you look at them.
From a frame formatting point of view, Ethernet is the odd ball when looking at how
TCP/IP is carried.
Everything other than Ethernet (802.3) uses 802.2 or a medium specific varient of 802.2.
Then there's Ethernet which predominantly uses either Ethernet II for TCP/IP or 802.3
(a.k.a. "Raw") Ethernet frames for IPX. FDDI is like
Ethernet and like 802.4. Token Ring is the oddball because (a) it doesn't have proper
multicast addresses, and (b) for some reason IBM invented source-routed bridging and tied
that to Token Ring.
Does it actually need a broadcast address like Ethernet when the ring passes through all
the stations? Or is that functionally comparable to a multicast? > FDDI is in no way at all like Token Ring. The
only thing the two have in common is "token" and "ring". The MAC
protocol is utterly different; the closest relative is 802.4 Token Bus.
One example of this is the behavior under high load. At one time, token ring marketeers
claimed it was better because it wouldn't "collapse" under load "like
Ethernet". That is actually false, but in any event, 802.5 worst case latency is
incredibly large for large rings. 802.4 and FDDI with their "timed token
protocol" have far lower worst case latency.
paul
22 Feb
22 Feb
3:21 p.m.
On 02/21/2019 07:43 AM, Paul Koning via cctalk wrote:
"raw 802.3" is a bug, caused by a programmer
not understanding how the
specs work.
I thought people started using 802.3 /before/ the 802.2 specification
was finished. Thus it's hard to follow what doesn't exit. Or at least
that's what I've read multiple places.
The mapping from Ethernet to 802.2 SNAP is trivial,
but yes, you do need
that mapping.
I'm still pontificating how trivial the mapping between Ethernet II and
802.2 SNAP is. I guess as long as you translate the Ethernet Frame Type
to the SNAP Protocol ID (and vice versa) and the Ethernet frame payload
would fit in the upper layer data area, things would be okay. There
might be some payloads that would fit in an Ethernet II frame that
wouldn't fit in an 802.2 SNAP frame on Ethernet. Fortunately Token Ring
had bigger MTUs.
You would probably only be going between Ethernet II and 802.2 SNAP if
you were going from Ethernet (802.3) to a different 802 network. Which
means that other things on that non-Ethernet 802 network would already
understand the same protocol(s) in 802.2 SNAP frames.
The idea of using a mixture of Ethernet II and 802.2 SNAP on an Ethernet
seems odd. (en0 vs et0 interfaces in AIX come to mind.)
Broadcast is just a special case of multicast. My
point was that 802.5,
at least as IBM thinks of it, doesn't have proper multicast addresses
(low bit set plus 47 bits to say what the address is). Instead, it
has "functional addresses" which have a fixed beginning plus one of
32 bits that is set. So instead of 2^47 possible values, you have 32.
Interesting.
Thank you for explaining it.
I don't know why this was done. Perhaps their
chip designers thought
hash or CAM address matching was too hard?
?\_(?)_/?
So if you have a protocol that uses multicast, like
DECnet, you have to
translate the real multicast address to the corresponding "functional"
address in an Ethernet-802.5 bridge. And you have to make up a functional
address, since the address space of 32 values is too small to have
globally assigned multicast addresses as you do with other LANs.
Was one functional address used in lieu of the broadcast? Meaning that
all stations would receive it, look at it, and decide if they needed to
act on it or not. Much like traditional 10Base5 / 10Base2 / hubs?
The ring passes through all stations of a LAN segment,
just as the
Ethernet bus (in the original version) passes through all stations of
the segment.
I think there's a minutia difference. I don't know if it's germane or not.
To me, Ethernet (10Base5 / 10Base2 / Hubs) are functionally a broadcast
that every station hears without any action on other stations behalf.
Conversely, Token Ring each frame is actively passed station to station
by each station. It's also my understanding that the station will not
pass the frame on to the next station in the ring if the incoming frame
was destined to the local station. Thus, not all stations would
necessarily hear every frame like they would on Ethernet.
The point of multicast is that it recognized by
multiple stations,
not just one. But multicast matters to bridges because they have to
forward it differently than individual addresses: individual is forwarded
according to the address database entry if there is one, while multicast
is not learned and always flooded along the spanning tree.
ACK
One example of this is the behavior under high load.
At one time, token
ring marketeers claimed it was better because it wouldn't "collapse"
under load "like Ethernet". That is actually false, but in any event,
Please elaborate on why it's false.
I've heard of stations locking up and breaking the ring. But I suspect
that you're talking about something else.
802.5 worst case latency is incredibly large for large
rings.
Ya, I can see that.
802.4 and FDDI with their "timed token
protocol" have far lower worst
case latency.
I effectively don't know anything about 802.4 or FDDI.
--
Grant. . . .
unix || die
5:15 p.m.
On Feb 22, 2019, at 6:21 PM, Grant Taylor via cctalk
<cctalk at classiccmp.org> wrote:
On 02/21/2019 07:43 AM, Paul Koning via cctalk wrote:
...
SNAP as a way of encoding bridged Ethernet II frames applies only to non-Ethernet LANs,
all of which have larger MTU.
The mapping from Ethernet to 802.2 SNAP is
trivial, but yes, you do need that mapping.
I'm still pontificating how trivial the mapping between Ethernet II and 802.2 SNAP
is. I guess as long as you translate the Ethernet Frame Type to the SNAP Protocol ID (and
vice versa) and the Ethernet frame payload would fit in the upper layer data area, things
would be okay. There might be some payloads that would fit in an Ethernet II frame that
wouldn't fit in an 802.2 SNAP frame on Ethernet. Fortunately Token Ring had bigger
MTUs.
You would probably only be going between Ethernet II and 802.2 SNAP if you were going
from Ethernet (802.3) to a different 802 network. Which means that other things on that
non-Ethernet 802 network would already understand the same protocol(s) in 802.2 SNAP
frames. The idea of using a mixture of Ethernet II and 802.2
SNAP on an Ethernet seems odd. (en0 vs et0 interfaces in AIX come to mind.)
SNAP covers more than encoding bridged Ethernet II. It was intended as a way to carry
protocols in 802 format for which you couldn't get a SSAP/DSAP code point (such as
private protocols). DEC did this in various places, it's perfectly straightforward.
Perhaps some implementations make it hard to support both simultaneously, but there is no
technical reason to make such a mistake.
Broadcast is just a special case of multicast.
...
Was one functional address used in lieu of the broadcast? Meaning that all
stations would receive it, look at it, and decide if they needed to act on it or not.
Much like traditional 10Base5 / 10Base2 / hubs? The ring
passes through all stations of a LAN segment, just as the Ethernet bus (in the original
version) passes through all stations of the segment.
I think there's a minutia difference. I don't know if it's germane or not.
To me, Ethernet (10Base5 / 10Base2 / Hubs) are functionally a broadcast that every
station hears without any action on other stations behalf. Conversely, Token Ring each
frame is actively passed station to station by each station. It's also my
understanding that the station will not pass the frame on to the next station in the ring
if the incoming frame was destined to the local station. Thus, not all stations would
necessarily hear every frame like they would on Ethernet. ...
The claim of collapse under load -- meaning throughput goes down beyond a certain load
level -- is valid for ALOHA and similar networks, but not on Ethernet because it uses
carrier sense and collision detect. Under overload it runs at close to full utilization.
One example of this is the behavior under high
load. At one time, token ring marketeers claimed it was better because it wouldn't
"collapse" under load "like Ethernet". That is actually false, but in
any event,
Please elaborate on why it's false. 802.5 worst
case latency is incredibly large for large rings.
Ya, I can see that.
802.4 and FDDI with their "timed token
protocol" have far lower worst case latency.
I effectively don't know anything about 802.4 or FDDI.
23 Feb
23 Feb
12:01 a.m.
On 2/22/19 6:15 PM, Paul Koning via cctalk wrote:
SNAP as a way of encoding bridged Ethernet II frames
applies only to
non-Ethernet LANs, all of which have larger MTU.
Nope. I'm quite sure that NetBIOS used SNAP on Ethernet.
I'm betting that 3174's Ethernet interfaces also used DLC / LLC2 via SNAP.
IPX could run over SNAP on Ethernet if you wanted to.
SNAP covers more than encoding bridged Ethernet II.
It was intended
as a way to carry protocols in 802 format for which you couldn't get
a SSAP/DSAP code point (such as private protocols). DEC did this in
various places, it's perfectly straightforward.
*nod*
Perhaps some implementations make it hard to support
both simultaneously,
but there is no technical reason to make such a mistake.
I feel like putting TCP/IP in SNAP on Ethernet is a mistake in that most
OSs will not know how to work with TCP in a SNAP frame as they will be
expecting Ethernet II frames.
I don't know that there's a technical reason per say. I do think that
there is a market reason.
The pretense that broadcast is different from
multicast is just a
confusion. The description says that it is used for traffic that every
station wants to get. If you take that literally, no protocol should
use broadcast, because there isn't any protocol that every station on
every LAN wants to see. For example, ARP should have used multicast
for the same reason DECnet does: it is traffic that is interesting to
stations which speak that protocol, and only to those stations.
Flip things on their head. I think it's that the sender wants every
receiving station to see.
I think that's right. For 802.5, that is.
ACK
In FDDI the frames are "stripped" by the
sending station, which allows
things like network monitors in promiscuous mode to work just like
on Ethernet
Intriguing.
The claim of collapse under load -- meaning throughput
goes down beyond
a certain load level -- is valid for ALOHA and similar networks, but
not on Ethernet because it uses carrier sense and collision detect.
Under overload it runs at close to full utilization.
Okay. So you weren't saying that Token Ring had problems as much as you
were saying that Ethernet can work at close to capacity.
I remember seeing references to Ethernet would start to have problems
with increasing backouts as the number of stations wanting to transmit
at the same time would grow.
Though that may be that the average throughput of a given station may go
down while the network segment itself is closer to saturation.
I'm trying to reconstruct what exactly the
difference is, but I never
knew 802.5 well and my FDDI brain cells are all from around 1986...
Fair.
--
Grant. . . .
unix || die
24 Feb
24 Feb
8:51 a.m.
On Feb 23, 2019, at 3:01 AM, Grant Taylor via cctalk
<cctalk at classiccmp.org> wrote:
On 2/22/19 6:15 PM, Paul Koning via cctalk wrote:
Yes, but that's not what I was trying to say, apparently not very clearly.
There is a translation of Ethernet 2 frames into SNAP (by using an OUI of 00-00-00 or
00-00-F8 followed by the Ethentype). Those particular SNAP values are meant to be used
only on LANs different from Ethernet, and bridges connecting those to Ethernet would look
for those SNAP values and convert to the corresponding Ethernet 2 format.
SNAP as a way of encoding bridged Ethernet II
frames applies only to non-Ethernet LANs, all of which have larger MTU.
Nope. I'm quite sure that NetBIOS used SNAP on Ethernet.
I'm betting that 3174's Ethernet interfaces also used DLC / LLC2 via SNAP.
IPX could run over SNAP on Ethernet if you wanted to. SNAP covers
more than encoding bridged Ethernet II. It was intended as a way to carry protocols in
802 format for which you couldn't get a SSAP/DSAP code point (such as private
protocols). DEC did this in various places, it's perfectly straightforward.
*nod*
Perhaps some implementations make it hard to
support both simultaneously, but there is no technical reason to make such a mistake.
I feel like putting TCP/IP in SNAP on Ethernet is a mistake in that most OSs will not
know how to work with TCP in a SNAP frame as they will be expecting Ethernet II frames.
I don't know that there's a technical reason per say. I do think that there is a
market reason. The pretense
that broadcast is different from multicast is just a confusion. The description says that
it is used for traffic that every station wants to get. If you take that literally, no
protocol should use broadcast, because there isn't any protocol that every station on
every LAN wants to see. For example, ARP should have used multicast for the same reason
DECnet does: it is traffic that is interesting to stations which speak that protocol, and
only to those stations.
Flip things on their head. I think it's that the sender wants every receiving
station to see. I think
that's right. For 802.5, that is.
ACK
In FDDI the frames are "stripped" by
the sending station, which allows things like network monitors in promiscuous mode to work
just like on Ethernet
Intriguing.
The claim of collapse under load -- meaning
throughput goes down beyond a certain load level -- is valid for ALOHA and similar
networks, but not on Ethernet because it uses carrier sense and collision detect. Under
overload it runs at close to full utilization.
Okay. So you weren't saying that Token Ring had problems as much as you were saying
that Ethernet can work at close to capacity.
I remember seeing references to Ethernet would start to have problems with increasing
backouts as the number of stations wanting to transmit at the same time would grow.
Though that may be that the average throughput of a given station may go down while the
network segment itself is closer to saturation.
1910
days inactive
1914
days old
10 comments
4 participants
participants (4)
-
cctalk＠gtaylor.tnetconsulting.net -
paulkoning＠comcast.net -
seefriek＠gmail.com -
wdonzelli＠gmail.com