home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / dcom / lans / ethernet / 1808 < prev    next >
Encoding:
Internet Message Format  |  1992-09-02  |  4.4 KB
  1. Xref: sparky comp.dcom.lans.ethernet:1808 comp.dcom.lans.misc:712
  2. Path: sparky!uunet!gatech!rutgers!news.cs.indiana.edu!ethome.et.iupui.edu!indyvax.iupui.edu!harvey
  3. From: harvey@indyvax.iupui.edu
  4. Newsgroups: comp.dcom.lans.ethernet,comp.dcom.lans.misc,comp.protocols.novell
  5. Subject: Re: 802.3 Non-Compliance (?)
  6. Message-ID: <1992Sep2.205749.1@indyvax.iupui.edu>
  7. Date: 3 Sep 92 01:57:49 GMT
  8. References: <1992Aug28.194558.4752@iplmail.orl.mmc.com> <1992Sep2.214854.28999@samba.oit.unc.edu>
  9. Sender: usenet@ethome.et.iupui.edu (USENET News System)
  10. Organization: Purdue University, Indianapolis
  11. Lines: 88
  12.  
  13. In article <1992Sep2.214854.28999@samba.oit.unc.edu>, shava@hermes.oit.unc.edu (Shava Nerad Averett) writes:
  14. > In article <1992Aug28.194558.4752@iplmail.orl.mmc.com> more@tcc.orl.mmc.com () writes:
  15. >>In this meeting (which unfortunately I wasn't in), the vendor made the statement
  16. >>that Netware Servers violate the 802.3.
  17. >
  18. > This is the gods' own truth.  Netware 802.3 (euphemistically called "802.3
  19. > raw" -- or "802.3 wrong" to some of us...;) has a frame type that looks
  20. > like this:
  21. >
  22. >     Preamble     7 bytes
  23. >        SFD        1
  24. >     DestAddr    6
  25. >     SourceAddr    6
  26. >     Length        2
  27. >     Data        46-1500
  28. >     FCS        4
  29. >
  30. > Real 802.3, with 802.2, looks like this:
  31. >
  32. >     Preamble        7 bytes
  33. >         SFD             1
  34. >         DestAddr        6
  35. >         SourceAddr      6
  36. >         Length          2
  37. >         Data            46-1500
  38. >         DSAP    1st byte
  39. >         SSAP    2nd byte
  40. >         CONTROL 3rd, 4th (opt)
  41. >         Data and pad to minimum of 46...
  42. >         FCS             4
  43. >
  44. > But the real problem is that Netware *always* sets the *length* field to
  45. > all F's, meaning that if you are (from what I understand) running DECNet
  46. > Phase V or OSI protocols which *believe* this field, you could end up
  47. > with a lot of confusion, because the packet will not be the length adver-
  48. > tised.
  49.  
  50. No.  The length field is filled in with the length OK.  The problem is that
  51. where an Ethernet/802 controller expects to find the DSAP and SSAP fields
  52. are the first two bytes of the IPX header.  This is the IPX checksum field.
  53. Since IPX checksums are never enabled, this field is always FFFF hex, which
  54. means "checksum disabled" to IPX.  In the 802.2 standard SAPs of this form
  55. are reserved to the IEEE.  This is what drives some Ethernet/802 controllers
  56. nuts.  As far as VMS goes there is no way to even tell the Ethernet/802
  57. driver to receive these kinds of packets that I know of.
  58.  
  59. > This is the only shred of verity I can find in the vendor's statement.
  60. > This has, however, nothing to do with collision detections and such.
  61. > Generally that's all in hardware...
  62.  
  63. Yep...
  64.  
  65. >>His statement was that when a netware
  66. >>server detects a collision, that rather than following the random backoff,
  67. >>in the Ethernet world, the Netware server immediately attempts to retransmit
  68. >>the collided packet(after sending the jam sequence). This vendor stated that
  69. >>because of this, TCP/IP based systems running on the same ethernet as Novell
  70. >>netware servers could experience some performance problems due to the
  71. >>noncompliant nature of the netware server. He further stated that for this
  72. >>reason, NASA has put a ban on Novell Netware at it's sites.
  73. >>
  74. > I don't know about NASA, but IPX and IP are the two major protocols on our
  75. > campus, and they don't seem to have any difficulty at all living on the
  76. > same wires.  Could NASA be playing with OSI?
  77.  
  78. No, I think the salesman just didn't know what he was talking about...
  79. Some large nets put restrictions on what protocols allowed on the backbone.
  80. Usually this is done simply to reduce routing overhead in the backbone routers.
  81. Perhaps that is what NASA did.  Anyone from NASA here that knows?
  82.  
  83. > Note, that Netware *can* use Ethernet_II rather than Ethernet_802.3 in
  84. > the configuration statement, and completely obviate even this argument.
  85. > Or Ethernet_SNAP...
  86.  
  87. Yes.  IPX and many other protocols including IP co-exist just fine on our
  88. network here at IUPUI.  Many of our subnets were around long before they were
  89. connected to the backbone and have good reasons for staying with "raw 802.3"
  90. (e.g. they are using "raw 802.3" boot ROMs).  All other subnets (including
  91. the backbone) use Ethernet II.  Ethernet SNAP is not supported by our routers
  92. (Cisco AGS+s) for IPX (yet).
  93.  
  94. IPX encapsulations, and getting IPX and IP to live together are frequent
  95. topics of discussion in the comp.sys.novell newsgroup.
  96.  
  97. >[rest deleted]
  98. --
  99. James Harvey    IUPUI OIT Technical Support
  100. harvey@iupui.edu  uucp: iugate!harvey  bitnet: harvey@indyvax
  101.