From: harvey@indyvax.iupui.edu
Newsgroups: comp.dcom.lans.ethernet,comp.dcom.lans.misc,comp.protocols.novell
Subject: Re: 802.3 Non-Compliance (?)
Date: 3 Sep 92 01:57:49 GMT
Organization: Purdue University, Indianapolis

In article <1992Sep2.214854.28999@samba.oit.unc.edu>, shava@hermes.oit.unc.edu (Shava Nerad Averett) writes:
> In article <1992Aug28.194558.4752@iplmail.orl.mmc.com> more@tcc.orl.mmc.com () writes:
>>In this meeting (which unfortunately I wasn't in), the vendor made the statement
>>that Netware Servers violate the 802.3.
>
> This is the gods' own truth.  Netware 802.3 (euphemistically called "802.3
> raw" -- or "802.3 wrong" to some of us...;) has a frame type that looks
> like this:
>
> 	Preamble 	7 bytes
>    	SFD		1
> 	DestAddr	6
> 	SourceAddr	6
> 	Length		2
> 	Data		46-1500
> 	FCS		4
>
> Real 802.3, with 802.2, looks like this:
>
> 	Preamble        7 bytes
>         SFD             1
>         DestAddr        6
>         SourceAddr      6
>         Length          2
>         Data            46-1500
> 		DSAP	1st byte
> 		SSAP	2nd byte
> 		CONTROL 3rd, 4th (opt)
> 		Data and pad to minimum of 46...
>         FCS             4
>
> But the real problem is that Netware *always* sets the *length* field to
> all F's, meaning that if you are (from what I understand) running DECNet
> Phase V or OSI protocols which *believe* this field, you could end up
> with a lot of confusion, because the packet will not be the length adver-
> tised.

No.  The length field is filled in with the length OK.  The problem is that
where an Ethernet/802 controller expects to find the DSAP and SSAP fields
are the first two bytes of the IPX header.  This is the IPX checksum field.
Since IPX checksums are never enabled, this field is always FFFF hex, which
means "checksum disabled" to IPX.  In the 802.2 standard SAPs of this form
are reserved to the IEEE.  This is what drives some Ethernet/802 controllers
nuts.  As far as VMS goes there is no way to even tell the Ethernet/802
driver to receive these kinds of packets that I know of.

> This is the only shred of verity I can find in the vendor's statement.
> This has, however, nothing to do with collision detections and such.
> Generally that's all in hardware...

Yep...

>>His statement was that when a netware
>>server detects a collision, that rather than following the random backoff,
>>in the Ethernet world, the Netware server immediately attempts to retransmit
>>the collided packet(after sending the jam sequence). This vendor stated that
>>because of this, TCP/IP based systems running on the same ethernet as Novell
>>netware servers could experience some performance problems due to the
>>noncompliant nature of the netware server. He further stated that for this
>>reason, NASA has put a ban on Novell Netware at it's sites.
>>
> I don't know about NASA, but IPX and IP are the two major protocols on our
> campus, and they don't seem to have any difficulty at all living on the
> same wires.  Could NASA be playing with OSI?

No, I think the salesman just didn't know what he was talking about...
Some large nets put restrictions on what protocols allowed on the backbone.
Usually this is done simply to reduce routing overhead in the backbone routers.
Perhaps that is what NASA did.  Anyone from NASA here that knows?

> Note, that Netware *can* use Ethernet_II rather than Ethernet_802.3 in
> the configuration statement, and completely obviate even this argument.
> Or Ethernet_SNAP...

Yes.  IPX and many other protocols including IP co-exist just fine on our
network here at IUPUI.  Many of our subnets were around long before they were
connected to the backbone and have good reasons for staying with "raw 802.3"
(e.g. they are using "raw 802.3" boot ROMs).  All other subnets (including
the backbone) use Ethernet II.  Ethernet SNAP is not supported by our routers
(Cisco AGS+s) for IPX (yet).

IPX encapsulations, and getting IPX and IP to live together are frequent
topics of discussion in the comp.sys.novell newsgroup.

>[rest deleted]
--
James Harvey    IUPUI OIT Technical Support
harvey@iupui.edu  uucp: iugate!harvey  bitnet: harvey@indyvax
Newsgroups: comp.dcom.lans.ethernet