Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!ogicse!zephyr.ens.tek.com!tektronix!percy!nosun!techbook!kenh
From: kenh@techbook.com (Ken Haynes)
Newsgroups: comp.dcom.lans
Subject: Re: Novell: fear and loathing...
Summary: Don't worry
Keywords: novell ethernet
Message-ID: <1990Nov6.163420.29111@techbook.com>
Date: 6 Nov 90 16:34:20 GMT
References: <15581@cbmvax.commodore.com>
Organization: TECHbooks of Beaverton Oregon - Public Access Unix
Lines: 70

In article <15581@cbmvax.commodore.com> grr@cbmvax.commodore.com (George Robbins) writes:
>We've traditionally run an Engineering LAN based on TCP/IP and DECnet over
>a combination of thick and thin Ethernet and recently a T1 link.  Loading
>is a mixture of LAT and Telnet "terminal" connections, with X-window server/
>client stuff starting to take off and an ever growing NFS load.

 How much load do you currently have and how much additional load do you
 forsee?  Your Novell Dealer should be able to do a network load factor
 analysis to help in this area.  If he can't, e-mail me for the algorithms.

>
>I guess the real question is how the Novell protocols rate as good network
>neighbors and what kind of loading Novell clients represent to the network?

Novell protocols are a adaptation of Xerox XNS packet structure.  They call it
IPX/SPX.  They are different enough from DEC LAT to require a special program
to allow Novell workstations to talk to a VMS server (Netware is available for
VMS).  The protocols can and will coexist on the same wire as the LAT and
TCP/IP packets.  The only question is loading.  The physical topology is
irrelevant.  Ethernet protocol (packet structure, access method, etc. ) does
not change based upon the wire.  Thin can be mixed with UTP, and thick and
fiber, as long as the devices can pass the data within the prescribed timing
parameters. (in other words your net doesn't get too big)  If it does you need
to think of splitting the net.)
>
>I know that the Ethernet can be universal, but I'm interested in the pragmatic
>issues of maintaining adequate service levels in a mixed environment where
>administrative control might no longer completely in our hands.

To control the amount of finger pointing and reduce the amount of down time,
I would recommend you get a network diagnostic tool like the Network General
Sniffer or similar device that knows of LAT TCP/IP and IPX/SPX.  You will be
able to view loading and any offending workstations/servers that are taxing
your bandwidth.

>
>How should one approach the intermingling of the two networks?  I see several
>obvious alternatives:
>
>Can anyone suggest which approaches seem to work well, and which are an
>invitation to disaster?

It depends on the loading of the net.  Novell nets will generate more traffic
than terminal connections.  After all the workstations are doing their disk
I/O over the wire.  That doesn't mean the traffic is going to be enormous.
Disk I/O is hitorically bursty.  If you have CAD/CAM or heavy Database
access, you can expect higher traffic rates.  If you are doing word processing,
you can expect lower.  Splitting the net is always a good idea if you expect
high traffic rates.  It depends on the number of workstations, and the 
applications programs you expect to be running on each station.

>
>Finally, can anyone suggest some references which deal with Novell protocols
>and services at a reasonably sophisticated level?  So far, I haven't seen
>much beyond babytalk or Novell-centric administrator manuals.
>
>--

Novell produces an API reference for more technical discussion on the services
and functions available under Netware.  A local Novell product developer may
be able to help.


Hope this helps! Good luck.
Ken
-- 
******************************************************************************
Network Support Services:

UUCP: {nosun, sequent, tessi} kenh@techbook