will@cica.indiana.edu (William Sadler) (03/27/91)
In <1991Mar27.141423.25863@qut.edu.au> lynam@qut.edu.au writes: > I was wondering if there is any real reason to change to the 8137 type >of packets on a fileserver? I don't need too, to use NSCA Telnet, >because the -n option on packet drivers, lets me see ordinary fileservers. We used to require 8137 on our campus network, but that was because the routers (Cisco) in each building were only capable of bridging IPX. A ROM upgrade now allows routing of IPX so that 802.3 packets are transferred to 8137 on the backbone and then transferred back to 802.3 if another router wants to see them (unless, of course, it is using 8137). So, as far as I know, the answer to your question is that it doesn't make a difference. > Someone told me that if an ordinary Novell server is attached to a >heavily used backbone with heaps of different types of protocols, that the >server can mistake certain types of packets and as a result can hang. >Is this true? All I really want is to know, is if the above info is true. I haven't heard that, though I have heard that certain devices that look for 802.3 packets sometimes take longer to connect on 8137 networks. Packet timeouts may be higher as well due to the increased traffic. Will -- *************************************************************************** * _______________\|/_ Will Sadler will@cica.indiana.edu * * Laser 44888 /|\ sadler@iubacs.bitnet * ***************************************************************************
jbreeden@netcom.COM (John Breeden) (03/31/91)
In article <1991Mar27.141423.25863@qut.edu.au> lynam@qut.edu.au writes: >Gidday, > I was wondering if there is any real reason to change to the 8137 type >of packets on a fileserver? I don't need too, to use NSCA Telnet, >because the -n option on packet drivers, lets me see ordinary fileservers. > Someone told me that if an ordinary Novell server is attached to a >heavily used backbone with heaps of different types of protocols, that the >server can mistake certain types of packets and as a result can hang. >Is this true? All I really want is to know, is if the above info is true. If you are running Netware 2.15 and sharing a wire that is running *real* ieee traffic (CLNS/TP4 in my case), then the Netware server will die with an abend error. When you make ipx talk DIX - the problem goes away. IEEE CLNS/TP4 is the only protocol that I've seen Netware 2.15 choke on, and I've only seen 2.15 servers die (never had 3.X to test). So I'd guess that if you're NOT running *real* ieee on the same wire - you're safe. -- John Robert Breeden, jbreeden@netcom.com, apple!netcom!jbreeden, ATTMAIL:!jbreeden ------------------------------------------------------------------- "The nice thing about standards is that you have so many to choose from. If you don't like any of them, you just wait for next year's model."
jrd@cc.usu.edu (04/02/91)
In article <1991Mar31.005452.10463@netcom.COM>, jbreeden@netcom.COM (John Breeden) writes: > In article <1991Mar27.141423.25863@qut.edu.au> lynam@qut.edu.au writes: >>Gidday, >> I was wondering if there is any real reason to change to the 8137 type >>of packets on a fileserver? I don't need too, to use NSCA Telnet, >>because the -n option on packet drivers, lets me see ordinary fileservers. >> Someone told me that if an ordinary Novell server is attached to a >>heavily used backbone with heaps of different types of protocols, that the >>server can mistake certain types of packets and as a result can hang. >>Is this true? All I really want is to know, is if the above info is true. > > If you are running Netware 2.15 and sharing a wire that is running *real* > ieee traffic (CLNS/TP4 in my case), then the Netware server will die with > an abend error. > > When you make ipx talk DIX - the problem goes away. > > IEEE CLNS/TP4 is the only protocol that I've seen Netware 2.15 choke on, and > I've only seen 2.15 servers die (never had 3.X to test). > > So I'd guess that if you're NOT running *real* ieee on the same wire - you're > safe. > -- > John Robert Breeden, > jbreeden@netcom.com, apple!netcom!jbreeden, ATTMAIL:!jbreeden > ------------------------------------------------------------------- > "The nice thing about standards is that you have so many to choose > from. If you don't like any of them, you just wait for next year's > model." I second this. My observations and conclusions a couple years ago were very similar, and the NW 286 crashes were real enough and often when the server was on the campus backbone. Changing to TYPE 8137 stopped the crashes, and so today the campus standard is no Novell flavored 802.3 on the backbone. I can't say if NW 3.x systems suffer the same problem because all of ours are set to Ethernet_II (TYPE'd stuff). Joe D.
sph@logitek.co.uk (Stephen Hope) (04/02/91)
jbreeden@netcom.COM (John Breeden) writes: >In article <1991Mar27.141423.25863@qut.edu.au> lynam@qut.edu.au writes: >>Gidday, >> I was wondering if there is any real reason to change to the 8137 type >>of packets on a fileserver? I don't need too, to use NSCA Telnet, >>because the -n option on packet drivers, lets me see ordinary fileservers. >> Someone told me that if an ordinary Novell server is attached to a >>heavily used backbone with heaps of different types of protocols, that the >>server can mistake certain types of packets and as a result can hang. >>Is this true? All I really want is to know, is if the above info is true. >If you are running Netware 2.15 and sharing a wire that is running *real* >ieee traffic (CLNS/TP4 in my case), then the Netware server will die with >an abend error. >When you make ipx talk DIX - the problem goes away. >IEEE CLNS/TP4 is the only protocol that I've seen Netware 2.15 choke on, and >I've only seen 2.15 servers die (never had 3.X to test). >So I'd guess that if you're NOT running *real* ieee on the same wire - you're >safe. >-- > John Robert Breeden, John, Most of the ieee based protocols seem to use multicasts, and so will coexist with Netware - I have seen ICL OSLAN on the same cable, as well as ieee 802.1D Spanning Tree traffic and OSI based bridge management (Retix). However, I have a feeling that some of the cheaper LAN card designs treat all multicasts as broadcasts, so the problem may also depend on the LAN card and driver. Stephen Hope > jbreeden@netcom.com, apple!netcom!jbreeden, ATTMAIL:!jbreeden > ------------------------------------------------------------------- > "The nice thing about standards is that you have so many to choose > from. If you don't like any of them, you just wait for next year's > model."