Novell Guidelines

The following standards are in place to help ease troubleshooting, to simplify name conflict resolution, and to help share information between the UIC and other UofI campuses after an agreement is reached between all of us. Non-compliant LANs are to be disallowed from participating in the backbone via IPX/SPX. TCP/IP connectivity will, of course, remain undisturbed.

While it is true that only LANs currently connected to the campus ADN-ii backbone need to comply with these standards, administrators of isolated LANs may wish to implement them as well for future connectivity.

In summary, the proposal encompasses standard naming schemes for NetWare servers, standardization of internal server and interface cable network numbers, and the implementation of a single NDS directory tree for NetWare 4.x systems. Each of these will be discussed in detail below.

All NetWare 2.x, 3.x, and 4.x servers should be named to indicate their campus and departmental affiliation. The campus is designated with the campus acronym, followed by the 4- to 5-letter college or departmental code. A list of these letter codes are available elsewhere in this document. The separator is an underscore.

For example, the University Library's Electronic Text server is named UIC_LIBR_ETEXT. Except for the first two components, the name is up to the individual department to choose, keeping in mind the constraints on length of names imposed by NetWare. In instances where a departmental letter code is NOT available, we propose the use of well-known abbreviations for such departments.

All servers should be uniquely identifiable by their internal network address as well. This is especially important, as the numbers must be unique within a given logical network (i.e., any physical network from which the server is visible via SLIST). Since this number is used in most of the packets to and from a server, it helps LAN and backbone troubleshooting by easily identifying traffic streams. This number should represent the IP subnet number on which the server resides, in the following manner:

• The server number should be composed of the middle two parts of the network IP subnet number, followed by two digits for the server number within that subnet, left padded with a zero if necessary. For example, the first server on the 128.248.172.xxx subnet has an address of 24817201 (248172 = middle two parts of the IP subnet, 01 is the first server) and, similarly, the second server is 24817202. This allows up to 99 servers per subnet without an address conflict. Please contact the ACCC Networks Group via e-mail to NETWORK@UIC.EDU to register your number or to get the next unused number before you start installing the server.

The middle two parts of the network IP subnet number should be used as the network number followed by a predetermined suffix indicating the frametype. This number is used to enable IPX routing on the backbone router interfaces servicing a particular subnet. Using the same suffix for each frametype will help in troubleshooting. See the examples below.

Frame Types: NetWare servers support 4 frame types normally.

Ethernet_802.3: This is the original frame type that Novell implemented. This frame type does not follow standards. Though it is named 802.3, it was implemented before the 802.3 IEEE committee formalized the standard. This is a pretty bad frame type to use as it looks like a 802.3 frame but is not really one. Vendors of network layers devices such as routers have had to write special code to handle these frame types. It is also a very heavily used frame type as Novell servers used to default to it. UIC's routers are by default setup to expect this frame type for all IPX/SPX packets. We recommend that any new networks NOT use this frame type, if it can be helped; Instead, use the Ethernet_II frame type for IPX/SPX and TCP/IP protocols. This frame is referred to as "Novell-Ether" by Cisco, our router vendor.

Ethernet_II: This is based on the original Ethernet frame type and is used by most non-NetWare systems. This frame type is mostly used for TCP/IP protocols. It is also sometimes referred to as Ethernet DIX; Cisco, our router vendor refers to it as Novell-ARPA. This is a standards based frame and is handled by routers with ease. This frame is excellent for use with IPX/SPX as well. You can choose to run multiple protocols on a single frame type in a NetWare system. A single frame type helps reduce traffic and CPU utilization on your NetWare server. For you to use this frame, you must ask the ACCC Networks group to change your IPX routing frame type on the campus backbone router to Novell_ARPA. Once that is done bind IPX to Ethernet_II frame type on your server and change the client NET.CFG to enable the Ethernet_II frame types and tell IPX to use Ethernet_II using "Protocol IPX 8137 Ethernet_II" in the NET.CFG files. Please note that existing circumstances may not allow the Networks group to comply with your request for a frame type change.

 Ethernet_802.2: This is a standards based frame type that is well suited for carrying IPX/SPX, SNA or NETBIOS protocols. This is the default frame type on NetWare 4.x systems. Since it is not supported by the backbone routers, you cannot use this frame type for IPX/SPX connectivity to the and backbone and beyond.

Ethernet_SNAP: This is a standards based frame type that is used almost exclusively to carry Appletalk and its sub protocols. If you plan to support Macintoshes on your NetWare server then you will need to enable this frame type in addition to any other frame types you plan to use for IPX/SPX and TCP/IP on the server.

Please note that the backbone routers currently only support either Ethernet_802.3 (Novell-Ether) or Ethernet_II (Novell-ARPA) frame types on a given interface. If the interface you are on supports Ethernet_II then the first frame type you should specify on your server would be Ethernet_II. Whether an interface is setup for Ethernet_II or 802.3 type frames can be ascertained by contacting the ACCC Networks Group. We recommend that all new networks use the Ethernet_II frame type where possible, for both IPX/SPX and TCP/IP packets. Those with a need to support Appletalk will still need to use Ethernet_SNAP in addition.

 

Since each frame type that is enabled on a physical interface on the server must have a cable number specified as well, the following (|| is used to denote concatenation) guidelines should be followed to handle multiple frame types on each interface:

For example, a server on the 128.248.172.xxx subnet would have:

• Ethernet_802.3 248172F1
• Ethernet_II 248172F2
• Ethernet_802.2 248172F3
• Ethernet_Snap 248172F4
• Token-Ring 248172F5
• Token-Ring_Snap
  

Note: We have deliberately not covered token-ring systems here as the campus backbone is an Ethernet based one. Any existing token rings on campus are connected to the network via a bridge or a router. Token-ring is simple as it supports only two well defined standards based frame types:

 Token-Ring: Used to carry IPX/SPX and SNA protocols. This is the default for NetWare servers.

Token-Ring_SNAP: Used to carry TCP/IP and Appletalk protocols. If the token-ring is connected via a bridge to the ADN backbone, you must turn on source route bridging on the server and on the bridge to forward IPX/SPX and TCP/IP packets to and from the and backbone. In addition you must turn on source routing on each client workstation using the ROUTE.COM (DOS) or ROUTE.SYS (OS/2) modules. If the ring is connected using a router, you will most likely not need source routing. In either case, we urge you to contact NETWORK@UIC.EDU if you have a token-ring and require access to the ADN backbone.

With the advent of NDS in NetWare 4.1, it became possible to build a single logical NetWare network for an entire institution. However this requires a degree of co-operation and centralized planning not required previously. In essence, the NDS is a hierarchical, tree like structure whose branches are the various campuses and departments of the University of Illinois. Since UIC was one of the first in the University of Illinois system to implement NDS, it was felt that we should design the tree so as to be able to allow the other campuses to connect to this centralized tree as they move forward in their migration to NetWare 4.x. Keeping this in mind, it was felt by the design team that the best structure to model the tree after was the reporting hierarchies already existing in the system. This was modeled using the relationships between campuses, between colleges and departments in a campus, and where available, the relationships between departments and their constituent units. The root of the tree was named UNIVERSITY_OF_ILLINOIS (*) and three organizational units representing the UIC, UIUC and UIS campuses were created. A fourth unit called "Central Administration" was added when it was realized that we had a unit common to all campuses. The rest of this discussion centers around the design of the UIC and Central Administration units as only these are currently hosted on UIC systems.

It was found that departments report to colleges who in turn report to vice chancellors who in turn report to the chancellor. Since the tree design guidelines by Novell recommend that the depth of the tree be kept reasonably shallow (average of four levels), it was decided to map the Chancellors office to the same level as the Vice-chancellors, and map all the departments and colleges under the respective vice-chancellors. As a result, the following model was ultimately built. Please note that this diagram may not be current and is only provided to illustrate the broader designs of the tree. Not all containers shown here have active users, though most do.

This is by no means a complete tree of UIC, but only of those parts which have NetWare 4.x systems, and is a copy of what exists on 7.20.95.

Figure 1: NDS tree for the University of Illinois System

[Root]
 Central Administration
      VPBF         (Vice president business & Finance)
         OBFA      (Office of Business and Financial Affairs)
            OBAB   (Student financial services)
   UIUC            (Intended merge point for Urbana tree)
   UIS             (Intended merge point for Springfield tree)
   UIC             (UIC tree)
      CHNC         (Chancellors Office)
         PAFF      (Public affairs, Chicago)
         GCPG      (Great Cities Program)
      VCAA         (Vice Chancellor for Academic Affairs)
         SPH       (School of Public Health)
            ADAA
            ADA
            ADSA
            CHS
            EOHS
            HPA
            DEAN
            EPI_BIO
         LIBR                        (Library)
            LIBE                     (Main Library East)
               Electronic_Text       (Electronic text project)
                  CD_ROM_MACHINES
            LIBW                     (Library west - Health
Sciences)
         COM                         (College of Medicine)
            Chicago                  (College of Medicine -
Chicago Campus)
               MCAA
               MCGN
               MCCC
               MCAS
               MCFA
               MCDE
               MCFP
               MCME
               MCNS
               MCNE
               MCOB
               MCOP
               MCOR
               MCOT
               MCPT
               UROL
               MCPD
               MCPM
               MCPS
               MCRD
               MCSR
            Peoria           (College of medicine - Peoria
campus)
            Rockford         (College of medicine - Rockford
campus)
            Urbana           (College of medicine - Urbana
campus)
               MUBA
               MUMI
               MUFP
               MUIM
               MUOB
               MUPT
               MUPD
               MUPH
               MUPS
               MUSR
         READ                (Dept. of Resource Allocation)
            OSAA             (Office of Space Analysis and
Allocation)
      VCHS                   (Vice chancellor - Health services)
         VCUH                (Assoc. vice chancellor, Univ.
health service)
         MKDG                (Hospital marketing)
         UIH                 (UIH Hospital & Clinics)
            UHOB             (UIH - OB/Gyne dept)
      VCRE                   (Vice chancellor Research)
         ORS
         GC
         IPO
         ADM
         OPRR
         FINANCE
         POOL
      VCAD                   (Vice chancellor - Administration)
         AVCA                (Assoc. vice chancellor)
            ADSS
            BCAS
            CRM0             (Campus risk mgmt. office)
            ENVH             (Environmental and safety office)
            PSVC
            PUBL             (Publication services)
            UPOL             (University Police)
            CAPE
            TELE             (Telecom)
         VCAHR               (Vice chancellor - Admin & Human
resources)
      VCSA                   (Vice chancellor - student affairs)
         AVCSA               (Assoc. vice chancellor)
            SACP
            SAFA
            OMBU             (ombudspersons office)
         CAS                 (Campus Auxiliary services)
            HULL             (Hull house)
            CSHS
            PAVI             (Pavilion)
            CU               (Campus Unions)
               CHIU          (West side - Illini Union)
               CHCC          (East side - Circle Center)
         DESA                (Dean of Student Affairs)
            SASC
            SAFS
            SAVA
         PRAP
      COMP                   (ACCC Computer Center)
         Small Systems
         Network Applications
         Printers
         Electronic Lecture Centers
         Network Operations
         Client Interface Software
         Basic Systems
         Academic Data Network
         Administration
         Labs
            BSBB001
            SEL2054
            BSB4133
            LIB1444
            GRC105
            SEL2249
            SEL2249F
            SEL2263
            SEL2265
            SRC2027
            SEO224
            SRH205
            GRC179
            BSB4005
            BSB4061
            BSB4075C
            BSB4075E
            BSB4140B
            GRCLL55
            SEL2052
            SEL2267
            B1LC
            E1LC
      CUED                   (College of Urban Economic
development)
      PHARM                  (College of Pharmacy)
         OCEPS
      LAS                    (College of Liberal arts & sciences)
         ENGL                (English department)
            SCAILAB          (SCAILAB project)
               ADD110
               ADD104
               ADD107
               ADD113
         MSCS                (Math, Stats & Comp Sci Dept.)
         LASA                (LAS - Administration)
         CHEM                (Chemistry Dept.)
      SOCW                   (College of Social Work)
         MATEC               (MATEC Project)
      CBA                    (College of Business administration)
         LAB_USERS
                  

 To get a broader idea as to how the reporting structures of the university are arranged, please take a look at the printed UIC Staff Directory. It contains a fairly accurate representation of the reporting hierarchies.

If you plan to bring a NetWare 4.1 server online and expect to be connected to the UIC ADN backbone, the following must be observed:

1. Only a single tree is allowed in the UIC system. i.e your server must participate in the existing tree. If you intend to have your own tree, you may be denied IPX/SPX access to the campus backbone, as otherwise this will affect all other NetWare 4.x users on campus. You will continue to have TCP/IP access however. If you are not connected to the backbone with IPX/SPX currently but plan to do so in the future, we request that you obtain IPX/SPX access *before* setting up your first 4.x system so that it can be integrated into the tree from the start. If you currently have a 4.0x system on an isolated network, then we recommend that you migrate the server to NetWare 4.11 at a minimum, apply all necessary patches and contact the Small Systems Group via E-Mail at LAN@UIC.EDU, so that we can assist you in merging into the UIC tree.
2. The container and where your server will be placed, will be created by the Small Systems Group of the Academic Computing and Communications Center. The container will be named in accordance with the departmental alphabetic code, assigned by the Central Administration. In the unlikely instance where such codes for a dept. doesn't exist, the ACCC Small Systems group reserves the right to assign a temporary name for the container, until a permanent one can be found from Central Administration. Note that this pertains to the top level container of your department only; any containers below this one can be named to whatever specifications your dept. wishes to follow. Once the container is created and an appropriate dept. admin ID created and assigned for that container and below, you can then change the pswd on the dept. admin ID and use it to manage your container and below. You will also need this admin ID when you setup your NetWare server. To obtain the container and admin ID, you must send a request via E-mail to LAN@UIC.EDU at least 2 business days prior to your server setup. The container name, context, dept. admin ID and pswd will be communicated to you via E-mail. To facilitate a faster turn-around, we request that you include the name of your department and its reporting relations to upper levels in as much detail as possible. Please note that sometimes it is possible that we may need to rely on other units to obtain departmental codes or reporting information, and this may cause us to delay setting up the container for you in 2 business days. In either event, we will update you on the status within 2 business days.
3. We urge that all user objects in your department be named the same as the Netid of the person. This will facilitate the automatic updating of a persons information in the NDS from the PH system (Online phone book) in the future. The Netid of a person is unique among all registered netids on the UIC campus and in addition can be used to access other ACCC systems such as Tigger, Icarus. The Netid will also be able to access other participating systems.
4. We request that you subscribe to and participate in the UIC-wide Novell administrators forum UICNOVEL@UIC.EDU. You can request to be subscribed to this group by sending e-mail to LAN@UIC.EDU. This forum carries patch availability reports, notes of general interest as well as announcements relating to the IPX/SPX routing on the backbones (router outages etc.), and in addition draft copies of any proposed changes to the NetWare standards for UIC.
5. Sometimes, it is necessary for ACCC or Novell to repair the tree and this may involve Novell or ACCC requiring access to your part of tree. We have had to request console access to departmental file servers for the duration of a repair session, in cases where Novell determined that tree corruption centered around a specific server. We ask that you view this as a tradeoff of providing seamless UIC-wide access, and, normally, a very infrequent occurrence. We will strive to notify you in advance of any such repair sessions.
6. Since the tree is maintained as a distributed resource, every 4.1x server is a host for certain parts of the tree. This means that parts of the tree that others see may be physically located on your file-server. This level of distributed computing requires that all the participating servers run common and compatible codes with respect to their peers. This is particularly true of the modules that implement directory services itself. In almost all cases, Novell recommends that servers run the same code levels. When necessary, we will request on the UICNOVEL list that all 4.x administrators update their servers to specific code levels to fix specific problems occurring in the tree. We ask that you comply as expeditiously as possible to these requests so as to maintain the security and integrity of the tree. In cases of extreme urgency, the Small Systems group reserves the right to attempt to update the modules on your server, or failing that to temporarily remove IPX/SPX routing from your subnet, so as to fix specific problems being caused by the old code in your server. When we request that you update code on your server, we will usually either provide FTP name and paths where the files are located, or we will provide the files themselves on publicly read/only area on one of our servers.
7. Since the tree is a truly distributed resource and is hosted by all NetWare 4.x servers co-operatively, it is necessary to setup partitions on the tree, such that each dept with their own file server is in a partition of its own. These partitions then need to be duplicated as replicas onto other file servers as a means of backup, in case the main server hosting the partition goes offline. The Small Systems group reserves the right to assign and form the partitions and decide where to place the replicas. Novell recommends no more than two replicas for a dept level partition. If a dept has two or more servers the replicas will be distributed among them and if necessary onto one other external server. If a dept has only one server, we will distribute its replica onto 2 other external file servers. Please note that just as your partition may need to replicated onto another department's server, you may need to host other department replicas on your own server as well. This takes up negligible disk space on the file server's SYS: volume. Once you have finished setting up your server, please inform the Small Systems group via E-mail to LAN@UIC.EDU to setup the replicas appropriately.
8. As more and more software products are written to take advantage of NDS, we find that more and more of them require changes to the schema (basic structure) of the tree, to accommodate specific requirements of the product. Since modifying the schema requires root access to the tree, only the Small Systems group will make the actual change. Please send us E-mail via LAN@UIC.EDU if you have a software product that requires a schema change or root access. Most such software products provide a module called schema.exe (or similar) that modifies the schema. If it does, simply provide us the module, and we will make the appropriate changes to the tree. Other software products require root access to the tree for installation, as their schema modification routines are built into the install program. In cases like this, please send a note to LAN@UIC.EDU with at least 2 business days notice so as to arrange for Small systems personnel to be present at the time of installation, so as to provide access to the root of the tree. We reserve the right to reject any such modifications, if we believe the security or the integrity of the tree will be compromised. If you have any questions, please participate in the UICNOVEL LISTSERV group or send an E-mail to LAN@UIC.EDU if you need specific information.

Thank you for your cooperation. If you have any questions, please send an e-mail to LAN@UIC.EDU