| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 881.1 | Ethernet-to-FDDI translation works | MUDDY::WATERS | | Wed Mar 03 1993 09:01 | 4 |
| I think it's safe to say that all modern FDDI-Ethernet bridges know
how to translate Ethernet frames (with type field) into FDDI frames
(802.2 LLC format) and back again. Certainly DEC's bridges and
bridge/routers do it.
|
| 881.2 | | KONING::KONING | Paul Koning, A-13683 | Wed Mar 03 1993 12:24 | 6 |
| Right.
Furthermore, Novell doesn't do 802.2 correctly, so when you have IPX it's
always best to tell it to use Ethernet format packets.
paul
|
| 881.3 | DECnis Routes IPX correctly, but note bridging ... | REOTN3::MARVIN::STRATFORD | | Thu Mar 04 1993 09:02 | 33 |
| The questions and answers are almost correct but don't explain the
complete picture.
The DECnis can Route OR Bridge IPX.
DECnis is a translating bridge between NI and FDDI, that is we do all
the necessary frame translation between Ethernet/802.3 and FDDI.
However, as Paul points out there are some problems which have to be
solved with a few protocols which do not properly adhere to 802.2
(Appletalk and IPX).
When DECnis is set up to Bridge IPX it will only bridge packets from the
NI in Ethernet frame format. If an IPX packet is sent on the NI in 802.3
(RAW) format then DECnis will not bridge forward it.
As Paul says "it is always best to ... use Ethernet format packets".
There is a workaround which the DECbridges perform to allow RAW 802.3
format IPX packets from NI to be translated to FDDI as though they were
Ethernet format packets. DECnis is unable to do this (for reasons
associated with the fact that we also have to be able to Route IPX).
When DECnis is set up as an IPX router, the IPX frames routed by the
DECnis and are issued on NI or FDDI in the appropriate formats (NI
defaults to Ethernet frame format but could be set to 802.3 !).
So, to answer .0, if you are Routing IPX it is not a problem. If you
want to Bridge IPX then you must make sure the IPX endstations
default to issuing Ethernet format frames.
Martin Stratford
|
| 881.4 | Further clarification on DECnis IPX bridging | REOTN3::MARVIN::STRATFORD | | Thu Mar 04 1993 11:13 | 30 |
| OK, my previous answer was still not clear ...
IPX frames can be sourced on the NI in a number of frame formats:
- Ethernet with protocol type of 81-37
- "RAW 802.3" which is a frame format which happens to have the
equivalent of DSAP=SSAP=FF
- SAP 802.3 with DSAP=SSAP=E0
- SNAP 802.3 with PId=00-00-00-81-37 (RFC1042)
As I said in the previous reply, routing works as the frames "terminate"
at the DECnis and get routed out on the relevant datalink with the
correct data link format.
Bridging is more involved:
- Ethernet format - is translated correctly (RFC1042) onto the
FDDI and off again to NI
- RAW 802.3 format - will be bridged by DECnis but treated as
though a SAP 802.3 frame. This means it will be bridged onto
FDDI and off on another NI correctly but will not be converted
to SNAP 802.3 while on the FDDI. (This is the switchable
workaround offered on the DECbridge)
- SAP 802.3 format - is bridged correctly
- SNAP 802.3 format - is not bridged
So, using Ethernet format is safe and works. SAP 802.3 format works, RAW
802.3 is bridged but does not terminate correctly at nodes on the FDDI,
SNAP 802.3 is not bridged.
Martin
|
| 881.5 | Bridging ETHERNET_SNAP | QUIVER::STEFANI | I've got a pocket full of Kryptonite | Sun Mar 07 1993 23:58 | 31 |
| Martin,
>> - SNAP 802.3 with PId=00-00-00-81-37 (RFC1042)
I have a question regarding your definition of ETHERNET_SNAP. The ODI
specification defines the difference between ETHERNET_802.2 and
ETHERNET_SNAP as, ETHERNET_SNAP has a DSAP, SSAP, and Control field of
AA-AA-03, and ETHERNET_802.2 does not. It does not mention that the
PID following the Control byte would be 00-00-00-81-37 exclusively.
Our FDDI-Ethernet bridges do, however, bridge ETHERNET_SNAP correctly
as per the rules for ETHERNET_802.2.
From Ethernet to FDDI - Since the SA is followed by a length field,
the FC is added and the length field is
removed.
From FDDI to Ethernet - Since the header is *NOT* SNAP-SAP
(AA-AA-03-00-00-00) the FC is removed and a
length field is inserted.
Translating ETHERNET_SNAP correctly is important for protocols like
Appletalk II which require a SNAP header, but use a non-zero OUI field
(08-00-07). It is important that the DECnis do the translation to
allow FDDI_SNAP servers to communicate with ETHERNET_SNAP clients when
needed.
- Larry Stefani
Novell Server Driver Development
DEFEA Project Engineering
|
| 881.6 | DECNIS conforms to standards including 802.1h | REOTN3::MARVIN::STRATFORD | | Mon Mar 08 1993 12:27 | 12 |
| Stefani,
The DECNIS correctly performs translation between FDDI and Ethernet in
conformance with the standards.
The previous replies address one exception (IPX) to the standards and
how the DECNIS currently handles those (IPX) packets.
Specifically for Appletalk-II we implement 802.1h and hence operate
correctly in bridged Appletalk networks.
Martin Stratford
|
| 881.7 | | QUIVER::STEFANI | I've got a pocket full of Kryptonite | Mon Mar 08 1993 12:48 | 11 |
| Martin,
Call me Larry, "Stefani" is my last name. :-) I'm not too up on
what the different standards are as far as packet translation goes, I
just wanted to make note of that exception for ETHERNET_SNAP. In the
driver documentation that currently ships with our EISA FDDI
controller, we list supported connections and ETHERNET_SNAP is not
among them. The next driver release will reflect these exceptions.
Regards,
Larry
|
| 881.8 | Deciding to use 802 or Enet V2 frame formats | FERGIE::QUINLESS | Martin Quinless Digital Services London UK | Mon Apr 26 1993 12:58 | 50 |
| Hi
This is a related question and is probably best placed here rather than
create another topic...
I would be grateful if someone could confirm that my understanding of
translating 802 format packets and Ethernet V2 packets is correct. In a
mixed Ethernet and FDDI environment my understanding is as follows.
Packets destined to FDDI station from Etherent station via translating
bridge are translated as follows:
if the packet is Ethernet V2 it gets converted to an 802 SNAP
FDDI packet which can then be accepted by the FDDI station
if the packet is 802 format it passes onto the ring unchanged for
delivery to the FDDI station
Packets destined from FDDI to EThernet work in reverse
if the packet is an 802 SNAP FDDI packet it gets translated to
EThernet V2 format and is then transmitted to the Ethernet station
if the packet is a "proper 802 frame" it gets transmitted onto the
Ethernet in 802 format to the ethernet station
I want this clarified because the issue on whether two stations will
talk to each other is a planning/configuration issue rather than
something which is "taken care of" by the adapters and translating
bridges.
So what ever protocols one is using DECnet, TCP/IP IPX etc - you must
decide whether you use 802 or Ethernet V2 frame formats. It seems that
this could easy arise in a pure EThernet environment so it is not
unique to FDDI.
I guess if an 802 Ethernet frame arrived from an FDDI station and it
only understood Ethernet V2 at the transport level (DECnet IPX etc)
then it would cause an error to be generated and the task (file copy
etc) would fail.
As I said clarification would be appreciated. If anyone is interested
this started from a customer asking what happens if an FDDI station
generates an 802 frame and sends it to an EThernet station which can
only understand Ethernet V2 frame formats.
Thanks in advance.
Martin Q
|
| 881.9 | | QUIVER::STEFANI | Elvis is my psychic advisor | Mon Apr 26 1993 14:51 | 51 |
| Martin,
>> if the packet is Ethernet V2 it gets converted to an 802 SNAP
>> FDDI packet which can then be accepted by the FDDI station
Yes. An FC field is added before the destination address and a SNAP-SAP
(AA-AA-03-00-00-00) header is added after the source address.
>> if the packet is 802 format it passes onto the ring unchanged for
>> delivery to the FDDI station
Yes, but not entirely "unchanged". An FC field is added before the
destination address and the Ethernet packet length field (the two bytes
after the source address) is removed as part of the Ethernet-FDDI
translation.
>> if the packet is an 802 SNAP FDDI packet it gets translated to
>> EThernet V2 format and is then transmitted to the Ethernet station
Going the other way, the FC field and the SNAP-SAP header are removed
and padding is added for frames smaller than min size Ethernet frames.
>> if the packet is a "proper 802 frame" it gets transmitted onto the
>> Ethernet in 802 format to the ethernet station
FC field is removed, a two byte length field is added after the source
address, and any padding that is necessary is added.
>> I guess if an 802 Ethernet frame arrived from an FDDI station and it
>> only understood Ethernet V2 at the transport level (DECnet IPX etc)
>> then it would cause an error to be generated and the task (file copy
>> etc) would fail.
Well, it depends on how it's handled, but in my driver, if a packet
comes in for a frame type that isn't loaded, I drop the frame and bump
a counter. So, the packet is never presented to the protocol stack.
>> As I said clarification would be appreciated. If anyone is interested
>> this started from a customer asking what happens if an FDDI station
>> generates an 802 frame and sends it to an EThernet station which can
>> only understand Ethernet V2 frame formats.
Good question, I appreciate the interest (sell more FDDI adapters!). I
tried to connect a client talking ETHERNET_802.2 to an FDDI server
talking FDDI_SNAP, and I was able to connect!!! Reason: There was
another server on the network that talked both ETHERNET_802.2 and
ETHERNET_II. NetWare 3.11 has built-in IPX routing that will route
frames between different formats/media. Neat, huh?
- Larry
|
| 881.10 | Its clearer now | FERGIE::QUINLESS | Martin Quinless Digital Services London UK | Tue Apr 27 1993 04:41 | 9 |
| Larry
Thanks for the reply. Its just another area where bridge and routing
functions get slightly blurred with FDDI. As I suspected it all depends
on the driver at the receiving station. If it only handles one type of
frame format then it is up to the network designer to ensure that this
is what it will receive!
Martin
|