grr@cbmvax.commodore.com (George Robbins) (11/04/90)
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.
Now our MIS department has recently obtained approval of a plan to implement
"corporate" networking and E-mail services based on Novell software, and
twisted pair ethernet.
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?
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.
How should one approach the intermingling of the two networks? I see several
obvious alternatives:
1) Maintain two completely separate networks, with some kind of mail gateway
being the only common ground.
2) Use our existing bridge/router (Wellfleet) to provide traffic isolation
between the networks, but allow various systems on either side to talk to
each other.
3) Try to isolate the Novell traffic via the router, but permit connection of
Novell nodes in areas served only by our backbones or where the business
reporting areas overlap.
4) Allow indiscriminate attachment of Novell and other nodes, and hope that
departmental clustering and creative bridging will minimize handle loading.
Can anyone suggest which approaches seem to work well, and which are an
invitation to disaster?
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.
--
George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing: domain: grr@cbmvax.commodore.com
Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)haas%basset.utah.edu@cs.utah.edu (Walt Haas) (11/04/90)
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. > >Now our MIS department has recently obtained approval of a plan to implement >"corporate" networking and E-mail services based on Novell software, and >twisted pair ethernet. No big deal, we run Novell along with everything else on our campus network. I recommend that you require all Novell devices to have the ECONFIG option to give real Blue Book framing, otherwise you get a botched version of 802.3 framing. The routing protocol is pretty much straight RIP, which works out all right if there is only one path between two points (as our network is configured) but is likely to become stupid in the face of multiple paths between two machines. -- Walt Haas haas@ski.utah.edu
hedrick@athos.rutgers.edu (Charles Hedrick) (11/04/90)
We handle IP, DECnet, Appletalk, and Novell on our campuswide network, using cisco routers. For convenience in network administration, we tie the network numbers together. Novell needs a 32-bit network address. We use the IP network number. Some newer Novell machines need a separate network number of individual machines. We use the IP address of the machine for that. I don't know of any major misbehaviors that would affect other protocols. Novell uses a couple of routing protocols that behave more or less like RIP, and they use broadcasts in reasonably sensible ways. The only problem I've heard is that the default setup uses a packet format that looks like it is IEEE 802.2 (i.e. a length code instead of a packet type), but isn't. If a system that understands IEEE 802.2 sees the packet, it finds all ones where it would expect an NSAP. This is supposed to mean "all destinations". Some other protocol stacks apparently get confused. One solution is to run a utility called ECONFIG, which sets things up so that Novell uses its assigned Ethernet type code in the Ethernet header. This prevents other protocols from looking at its packets. I haven't seen this problem myself, though we use ECONFIG on most of our nets, so I guess I wouldn't expect to. I think doing corporate Email using a proprietary protocol such as Novell is a terrible idea. Novell is a neat way for PC's to talk to servers intended to deliver PC-specific services. But you'd like connectivity outside of your PC LAN to be done using TCP/IP, so that you can talk to other types of computer. If there's a gateway from Novell's mail to SMTP, then I guess I wouldn't object to using Novell's mail software, but I'd configure it so the corporate-wide mail is done using SMTP. Our Macs and IBM PC's use Appletalk and Novell respectively for PC services, but also have P.D. TCP/IP software for network-wide services. (We also have a site license for Multinet, so our DECnet machines also run TCP/IP.) For the IBM PC's, this means using packet drivers, so that Novell and something like NCSA Telnet can talk to the Ethernet card at the same time. I strongly recommend that you do something like this, so you don't build up islands of mutually non-communicating systems.
jbreeden@netcom.UUCP (John Breeden) (11/05/90)
In article <Nov.3.23.28.43.1990.9326@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes: >I don't know of any major misbehaviors that would affect other >protocols. Novell uses a couple of routing protocols that behave more >or less like RIP, and they use broadcasts in reasonably sensible ways. >The only problem I've heard is that the default setup uses a packet >format that looks like it is IEEE 802.2 (i.e. a length code instead of >a packet type), but isn't. If a system that understands IEEE 802.2 >sees the packet, it finds all ones where it would expect an NSAP. >This is supposed to mean "all destinations". Some other protocol >stacks apparently get confused. One solution is to run a utility I've seen Netware's quasi/semi/802.3 servers die with abend errors when confronted by other real 802.3 protocols (ISO/TP4) running on the same wire. The "problem" isn't just how other (non)Netware servers "behave" but how Netware servers themselves "behave". -- John Robert Breeden, netcom!jbreeden@apple.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."
kenh@techbook.com (Ken Haynes) (11/07/90)
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
bin@primate.wisc.edu (Brain in Neutral) (11/07/90)
From article <16197@netcom.UUCP>, by jbreeden@netcom.UUCP (John Breeden): > I've seen Netware's quasi/semi/802.3 servers die with abend errors when > confronted by other real 802.3 protocols (ISO/TP4) running on the same wire. > The "problem" isn't just how other (non)Netware servers "behave" but how > Netware servers themselves "behave". That might be an advantage: George can then point to the Novell servers and say what wretched network citizens they are, and kick MIS out the door. :-) -- Paul DuBois dubois@primate.wisc.edu "Was all of this because I wore a big man's hat?"
keith@ca.excelan.com (Keith Brown) (11/09/90)
In article <Nov.3.23.28.43.1990.9326@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes: >The only problem I've heard is that the default setup uses a packet >format that looks like it is IEEE 802.2 (i.e. a length code instead of >a packet type), but isn't. This is true of NetWare 286. I think the original reason we "forgot" to slap an 802.2 header into our 802.3 format IPX ethernet packets was that folks on the IEEE 802.2 committee were still bickering when we first started shipping network operating systems. Still, I should point out that as of NetWare 386 and the availability of our ODI based workstation software it is now possible to run your IPX communications using: 1) 802.3 packet format with no 802.2 sublayer (ala traditional NetWare 286) 2) Ethernet packet format (ECONFIG'd) 3) 802.2 over 802.3 packet format 4) Ethernet "SNAP" packet format (extended 802.2..... well, sort of!) The choice is yours. On the server, you make your choice by specifying the frame format you wish to use when you load the LAN adaptor driver. For example, you may "load ne2000 frame=ETHERNET_802.2" to use 802.2 over 802.3 packet format, and then bind IPX to this interface. At the client you specify the frame format in your NET.CFG file. Mine looks like this (a '#' indicates the line is commented out. To adjust my configuration I simply adjust the comment outs and reboot. Currently I'm set up to use Ethernet/Econfig'd encapsulation..... Link Support Buffers 16 1586 MemPool 4096 Link Driver EXOS205 Frame Ethernet_II # Frame Ethernet_802.2 # Frame Ethernet_802.3 # Frame Ethernet_SNAP Protocol IPX 8137 Ethernet_II # Protocol IPX E0 Ethernet_802.2 # Protocol IPX 0 Ethernet_802.3 # Protocol IPX 8137 Ethernet_SNAP INT #1 2 MEM #1 D0000 PORT 310 Protocol IPX Bind EXOS205 Both the DOS ODI drivers and the NetWare 386 server ODI drivers support multiple encapsulations through the same physical interface concurrently. This allows different protocols to use different encapsulation methodologies while sharing the same physical LAN adaptor. If you own a NetWare 386 server you should now be happy no matter how religous you are about protocol formats on the wire. That is unless you own a piece of hardware that we haven't quite got round to doing an ODI driver for yet. Don't panic, there coming...... Keith ---------------------------------------------------------------------------- Keith Brown Phone: (408) 473 8308 Novell San Jose Development Centre Fax: (408) 433 0775 San Jose, California 95131 Net: keith@novell.COM ----------------------------------------------------------------------------
donp@na.excelan.com (don provan) (11/10/90)
In article <3396@uakari.primate.wisc.edu> bin@primate.wisc.edu writes: >From article <16197@netcom.UUCP>, by jbreeden@netcom.UUCP (John Breeden): >> I've seen Netware's quasi/semi/802.3 servers die with abend errors when >> confronted by other real 802.3 protocols (ISO/TP4) running on the same wire. >> The "problem" isn't just how other (non)Netware servers "behave" but how >> Netware servers themselves "behave". > >That might be an advantage: George can then point to the Novell servers and >say what wretched network citizens they are, and kick MIS out the door. :-) It does sound like you should kick MIS a little, but because of their abilities, not because of the Novell servers. It doesn't take that much talent to ECONFIG older NetWare servers and clients to send standard Ethernet packets instead of "raw" 802.3. Newer software can be configured even more easily. Well, that's not really fair to the MIS folks. George's MIS people probably aren't reconfiguring their NetWare network to send ethernet packets because their many NetWare users would be inconvenienced a little by the switch over. Those users would probably be even more inconvenienced if MIS removed NetWare altogether. Why, yes, now that you ask, i do happen to work for Novell. :-) don provan donp@novell.com