Screen-friendly page
Printer-friendly pageNetWare/IPX on UIUCnet
This page contains IPX routing guidelines for the Urbana-Champaign campus.
Note that IPX will no longer be routed over the main UIUCnet network core after May 16, 2004.
For more info: http://www.cites.illinois.edu/news/2003/appletalk-ipx.html
Note:
This document was originally written in 1994 by G. David Frye. Some of the discussion of protocols and "current" machines reflects its age. For example, modern IPX networking can run over TCP/IP. However, the discussion of how to name machines on an IPX network for UIUCnet use remains in effect. --CITES Documentation
Abstract:
NetWare is a networking scheme primarily for Windows personal computers. The underlying protocol for NetWare, IPX, is an officially supported protocol on the UIUCnet backbone. Interested departments can request access to backbone IPX. CITES has defined requirements for participation that relate to network numbering, server naming, and packet encapsulation. Appendices describe network numbering details and security issues and compare IPX to AppleTalk.
Table of contents:
What does the NetWare "world" look like?
Tell me about IPX and Ethernet framing.
How do we get campus-wide NetWare on our building network?
What are the requirements that NetWare server administrators must adhere to?
Why should we not enable campuswide NetWare on our LAN?
Where do I get answers to more questions?
Appendix A: IPX Network Numbers
CITES supports IPX, the protocol suite used by Novell NetWare, as an official protocol of UIUCnet, the campus backbone. Interested departments can request access to backbone IPX.
This document describes NetWare, the IPX protocol, campus-wide IPX standards, and requirements for participation. It is intended for use by network administrators, so the level of discussion is mildly technical. However, some portions of it may be useful to others. The appendices cover advanced technical topics that will be of more interest to an experienced network or server administrator.
NetWare is a Network Operating System (or NOS) primarily for Windows personal computers. In the NetWare scheme of things, there are servers that run on dedicated PCs, and there are clients (e.g., user workstations) that access those servers via some kind of network. The kinds of services that a server can provide include disk storage, print spooling, electronic mail, application sharing, and more.
In addition to supporting Windows, NetWare servers can also provide services based on other protocols. For example, the "NetWare for Macintosh" add-on product delivers true AppleTalk service to Mac clients; and, a number of TCP/IP options are available, including FTP and NFS.
NetWare is a product of the Novell Corporation. The University of Illinois participates in Novell's Education program and as a "Technology Transfer Partner." As a TTP, we have access to a broad spectrum of NetWare expertise, including universities who are active in NetWare development. Under the Education Licensing Agreement, we are entitled to discounts on NetWare products and software maintenance fees. CITES oversees the program for UIUC and resells NetWare to interested departments.
At the CITES microcomputer sites, NetWare is a critical component in providing uniform service to student users, effective tools for site management, and flexibility for faculty interested in offering PC-based educational materials. Many other departments use NetWare as the foundation for providing network services to faculty and staff.
As use of campus-wide NetWare grows, CITES and other departments will likely offer specific NetWare-based services to the campus at large. Watch for announcements in campus network-related mailing lists.
IPX (Internetwork Packet eXchange) is the network protocol used by NetWare. It is a specific method for organizing, addressing, and transferring data across a network. NetWare uses IPX in the same way that Telnet uses the TCP/IP protocol and Appleshare uses Appletalk.
Until recently, IPX could only be used on individual local area networks (LANs). It could not be transmitted across the campus backbone; thus, NetWare users on one LAN could not directly access NetWare services on another LAN. There was a "trick" of sorts one could do: servers could open "IP tunnels" to each other - talk across a TCP/IP backbone by encapsulating IPX messages in IP packets. A properly-defined tunnel is transparent to the NetWare user.
As interest in NetWare grew, so also did the number of IP tunnels. Tunnels are tricky to set up, difficult to debug, add additional overhead to servers and LANs, and require the presence (and expense) of a server on a LAN when it might otherwise not be needed.
All of those tunnel-related problems are important, but the last one is critical. Without backbone routing of IPX, it would not be practical to create centrally-located NetWare services that could be used by client workstations all around the campus.
What does the NetWare "world" look like?
From a network point of view, a NetWare internetwork is made up of individual networks (a server's internal process net, a LAN, or a segment of the backbone) connected together by IPX routers. Each node has a unique address comprised of a 32-bit IPX net number and a 48-bit station number (typically the ethernet address). Care must be exercised to insure that no two networks have the same net number.
A NetWare service is described by a service number (e.g., 0047 = print queue) and a unique name, plus the IPX node address where the service can be found.
From a user's viewpoint, a NetWare internetwork has a "flat" topology. Every workstation can see every server, and vice versa. When a client performs a task that requires selecting a server, all known servers are presented in an alphabetized list. There is no equivalent to the Appletalk "zone." About the best we can do is add some structure to the server name to make the server's location or ownership more apparent.
In order to use a service offered by a server, a client must be attached to that server - have logged in by presenting a name and (optionally) a password. This includes printing: a NetWare printer is connected to a queue on some NetWare server, and a client must be attached to the server in order to determine whether or not it may put a print job in that queue.
It is possible, practical, and sometimes necessary to be attached to several servers at once. There are tools available in Windows to automate the process of logging in and mapping NetWare services to the workstation's environment.
Tell me about IPX and Ethernet framing.
Funny you should ask. IPX packets that are transmitted on an Ethernet can be encoded, or framed, in several different ways. The oldest method, called "802.3" by Novell, is the frame type used by default for NetWare servers up through version 3.11. Subsequent versions (3.12 and 4.x) use "802.2" by default. A third frame type is called "Ethernet II" and is the type that corresponds most closely to the method used by TCP/IP.
This turns out to be important for a couple of reasons. First, the campus backbone routers can only understand "802.3" and "Ethernet II" IPX frames. Furthermore, a specific router interface can only be configured to understand one of those types at a time. Thus, all NetWare servers and clients on a single LAN should be configured to use the same frame type. The saving grace is that a NetWare server can be set up to understand multiple frame types and act as a frame type converter. Like IP tunneling, this adds additional load to the server and the LAN.
Second, Novell's use of "802.3" framing does not in fact conform to the official IEEE 802.3 standard. It is possible that there will be other (non-NetWare) devices on a LAN that will improperly interpret such packets.
CITES recommends that all NetWare servers use the "Ethernet II" frame type.
How do we get campus-wide NetWare on our building network?
It's not difficult to get access to campus-wide NetWare. However, there is a per-router cost associated with enabling it, which CITES pays, so a network administrator must formally request that it be turned on. The process goes like this:
1. The building network administrator requests IPX access from CITES. (The followup takes time, and non-trivial requests will be processed in order of receipt. Contact admin-help@uiuc.edu to get on the list.)
2. CITES assigns appropriate IPX network numbers.
3. CITES checks the network for pre-existing NetWare services and verifies compliance with requirements for net numbering, framing method, server naming, and server security.
4. The building router is enabled for IPX.
What are the requirements that NetWare server administrators must adhere to?
From the preceding discussion it should be clear that some standards need to be defined for participation in campuswide NetWare. The requirements are as follows:
1. All IPX network numbers should be assigned according to the campus standard, described in Appendix A.
2. All servers on a LAN should support one common framing method, either "Ethernet II" (strongly preferred) or "802.3".
3. All servers should be named with a common prefix that identifies the owning department. General server name would be of the format "DEPT-SERVERNAME" (e.g., "CITES-RESOURCE"). It is strongly recommended that the prefix be the same as the department's IP domain name (i.e., system.domain.uiuc.edu).
4. No IP tunnels may exist to non-conforming servers or networks. It is strongly recommended that tunnels not be used at all. No tunnels may be established to locations outside of UIUCnet without prior approval from CITES.
The requirements are all intended to make NetWare work well on a large backbone like UIUCnet. They must of course be met in order to get access initially, but continuing adherence is also important. CITES reserves the right to turn off IPX on a particular building interface if there are unresolved problems with network numbering, framing, server naming, or tunneling. CITES Network Engineering is the final authority on any issues relating to IPX standards.
There could conceivably be problems meeting these requirements on LANs that are shared by several independent groups. CITES does not have a solution for this. It's important that there be a single network administrator for a LAN, that said person be adequately trained, and that departments who share LANs have procedures in place for dealing with conflicts.
Why should we not enable campuswide NetWare on our LAN?
If you're not currently using NetWare locally, enabling backbone IPX is pretty simple. But if you're already managing your own NetWare servers, fulfilling the above requirements will take some time and effort on your part. And you'll need to think about security (described in Appendix B) and workstation configuration (drive mappings, etc.). So you probably need a good reason for enabling IPX, such as the need to connect to departmental users on remote LANs, or the desire to access new campus-wide services as they become available. If you decide you want to do this, CITES will do everything in its power to make the transition as painless as possible, but you ultimately have to do the real work.
Where do I get answers to more questions?
Contact the Network Administrator Support group (NAS) at admin-help@uiuc.edu. Their website is located at http://opcenter.cites.uiuc.edu/nas/.
Appendix A: IPX Network Numbers
In NetWare's IPX protocol, a "network" is a logical channel shared by nodes that are capable of communicating directly with each other. That is, A can send a message to B without relying on an intervening device C to pass data from A to B and vice versa. In such cases, A and B are said to be on the same network.
If, however, A and B can only communicate with each other with the help of intervening device C, then A and B are said to be on different (or separate) networks and device C is called a router.
NetWare calls things "networks" that we might not necessarily consider as such. For example, all of the processes running on a single server are connected to the server's "internal IPX network." On a specific LAN, all users of the "Ethernet II" frame type comprise a logical IPX network. All users of the "802.3" frame type, on the same physical LAN, are considered to be nodes on a different IPX network. NetWare servers can be configured to understand multiple frame types, and to be connected to multiple networks. Thus, every server is effectively also an IPX router.
Each IPX network is identified by a unique 32-bit number. Care must be exercised to insure that no two networks have the same number. The numbers are represented in server configuration files as 8-digit hexidecimal values.
As it happens, UIUC already has a unique network numbering scheme in place to support the Internet Protocol (IP). Every LAN on campus has a distinct range of IP addresses. The IP address happens also to be a 32-bit number. The standard that has been established for IPX network numbering maps the IP address into the IPX address, with special conventions for the different framing methods.
Rule 1: Every NetWare server should have a unique IP address assigned by the LAN's network administrator, even if the server does not currently provide TCP/IP services. (Many do, and you might want to reserve the number for the future.)
Rule 2: The server's "IPX internal net" is the same as its IP address.
Rule 3: The LAN's "Ethernet II" IPX net is the same as the LAN's subnet base IP address.
Rule 4: The LAN's "802.3" IPX net, if needed, is the same as the LAN's router IP address (typically subnet+1).
Rule 5: The LAN's "802.2" IPX net, if needed, is the same as the LAN's IP broadcast address.
Rule 6: Any NetWare-only subnets (i.e., LANs connected to a NetWare server but not to the campus backbone) should be assigned some other unused or "safe" address in the building LAN's range of IP addresses.
Example. Given the following LAN:
From the above, we know that:
A new NetWare server is purchased. The LAN's network administrator assigns it to:
This results in the following IPX network addresses:
A NetWare administrator configuring a server would use the above information to specify these lines in AUTOEXEC.NCF:
If other frame types were needed, the same LAN driver could be loaded multiple times with the framing methods specified:
If a second NetWare server is purchased and installed on the same LAN, the only network number specified differently in its configuration is the IPX internal net.
For more information about IP subnet addresses, please refer to the "Appletalk at UIUC" document, Appendix C.
Appendix B: NetWare Security Issues
Every file server administrator should be concerned about security. This is just as true of NetWare servers as it is of any other kind of shared network device, including personal workstations. Servers may contain information that shouldn't be accessible to the general public. Student or financial data must be protected from tampering. Users must be cautious about passwords and private data such as email.
When a department requests that its LAN have access to campuswide NetWare, the potential for security breaches increases significantly. Its servers are now accessible to all users on UIUCnet, at all locations where backbone IPX is enabled.
File server security is the individual department's responsibility. CITES cannot make any guarantees with respect to file server integrity. However, there are some obvious areas of server management that have security implications, and this appendix covers them briefly. Before IPX is enabled for a requesting department, CITES will make an effort, with the department's help, to identify obvious security problems.
The areas discussed here are covered in excruciating detail in the NetWare documentation. Refer to the System Administration and Concepts manuals for more information. Novell also provides a utility called SECURITY that can be run from a workstation to test a server for potential security problems.
- Physical access to the server. A NetWare server runs on a
dedicated PC. It cannot be used by "ordinary users" for typical PC tasks,
because the normal operating system (DOS) has been replaced by the server
software. The PC monitor acts as a system "console" that can be used
to stop and start the server and change its configuration. The floppy
drive can be used to load new or replacement software packages.
Unlike all other use of NetWare, the console does not by default require any kind of login. Any person who can type on the keyboard can potentially affect server operation. There are tools available to make this more difficult, including the SECURE CONSOLE command and the "lock console" option in MONITOR. Such features can be defeated by someone who can reboot the server PC and restart the server without invoking the normal startup commands. The only known way to prevent this is to require a BIOS startup password, and that can presumably also be defeated by someone who can manipulate the PC hardware.
No mechanism we know of will completely protect a server from attack. The best solution is to place the server in a secure location, one that cannot be easily accessed by unauthorized students or employees.
- Login Security. No area of system security has received more
scrutiny than user identity. In NetWare, user logins can be restricted
by password, by location (node address), and/or by time of day. But
most login breaches occur as the simple result of the user's password
being discovered, either because it was a poor choice or because it
was written down somewhere. NetWare allows the system administrator
to require passwords to be at least a certain number of characters,
and/or to expire after a certain number of days. See the manuals for
more details.
NetWare creates a default "guest" account with no password. Guest has few privileges, but note that any valid login can acquire a complete list of server accounts and use that list to attempt to discover (by trial and error) non-passworded accounts or obvious password choices. Guest can also create files in any user's MAIL directory, including a login script file if one doesn't already exist. Only enable the guest account if you need it, and make sure that every user has a login script file even if it's empty.
- Data access privileges. NetWare implements a complex set of file and directory access privileges. The Concepts manual describes data security in detail. It's a good idea for administrators to test access privileges after making changes, particularly for changes to volume root directories and large subdirectories.
Appendix C: IPX vs. AppleTalk
In many ways, the AppleTalk and IPX protocols are similar to each other. Each provide the mechanisms for delivering data from one node to another and for keeping track of networks, routes, and services. From a management point of view, though, there are some differences which should be understood by network administrators and users who work in both "worlds."
- Servers and clients. In the Apple scheme of things, every
workstation connected to the network is capable of acting as both a
server and a client. For example, a user's Macintosh can import a directory
on a server and at the same time export portions of its own data to
other users. The number of potential AppleTalk servers is as large as
the total population of Macintoshes.
The advantage of an integrated workstation is flexibility and ease of use. Every Macintosh owner can potentially offer services to other users.
In Novell NetWare, a server is a standalone computer that sits in a corner somewhere, and user PCs are its clients. NetWare servers tend to use fast, expensive hardware with redundancy and backup facilities. An individual department may only have one or two servers. The total population of NetWare servers at UIUC may some day be in the 150-200 range.
The advantage of a standalone server is that it can be optimized for the service function. Much of the "horsepower" (and very large amounts of memory) can be dedicated to doing network I/O, caching disk data, spooling data to printers, and so forth.
It's worth noting that, in recent years, the two philosophical "worlds" have merged closer to one another. Apple now produces "workgroup servers" which include software optimized for server performance. Novell sells "Personal NetWare" which allows user PC's to share disks and other resources among small groups without requiring a dedicated server. NetWare servers can run an add-on product called "NetWare for Macintosh" that provides AppleTalk services to Macintosh clients. And Macintosh users will soon be able to install networking software that uses IPX as the underlying protocol. It's a complex world out there and your ultimate choice of networking method will depend on both your needs and your preferences.
- AppleTalk Zones. AppleTalk requires a Macintosh computer to
be registered in a particular zone. A zone is a logical grouping of
systems and services. It can be network-independent, allowing a given
group of users (such as a UIUC department) to be spread out over several
LAN's or buildings.
A Macintosh user selects services in the Chooser, by first picking a service type (AppleShare, LaserWriter, etc) then indicating a Zone. WIthin the zone, all devices that offer the service will be listed in a table from which a particular item can be chosen.
This structure is manageable at UIUC largely because the zone names are well chosen. They tend to be based on college, department, or building. If the zone list contained unidentifiable things like "my zone" or "Vulcan world", we might have a problem.
As noted in the main text of this document, the NetWare topology is "flat". All servers appear to all users. It's as though there were only one zone. This sounds like a potentially fatal flaw, but from the above discussion we know that the total number of servers will be relatively small, and server names are required to include a prefix that indicates ownership (e.g., department identifier).
- Service polling vs. service tables. In protocol structure,
there are basically two ways for a client to discover available services,
polling the network or acquiring a list of known servers. AppleTalk
does the former, IPX the latter.
In the zone discussion above, the Macintosh user selected a service and a zone. At that time, a request is periodically (every few seconds) broadcast of the form, "all services of type X in zone Y, please respond with your name and network address." AppleTalk routers insure that the request is forwarded to all networks on which that zone is registered. Every server must individually respond.
The disadvantage of this method is that it can work unpredictably in a large network setting. The request must be propagated to all networks. Each server much respond, and may not do so immediately if it is busy. The user sees a response list that changes as new servers check in. The amount of network traffic generated by the operation could be significant, especially if the user watches the response for a while without making a selection.
IPX defines something called a SAP table. [SAP is network jargon for "Service Access Point", a fancy name for a service's identifier.] Each entry in a SAP table contains a service name, service type, and node address. NetWare servers and IPX routers each maintain a SAP table and periodically (once a minute, typically) broadcast information about the SAP's they provide to the local network. Theoretically, the SAP table provides an up-to-the-minute description of the whole network. A NetWare client broadcasts a request (on the local network only) for "all services of type X" and receives an almost-instantaneous reply.
The disadvantage of SAP tables is that the table contains every service on every LAN, and thus can become very large (1-2 thousand entries) for a large network like UIUCnet. The periodic SAP broadcasts cost a certain amount of bandwidth, probably not significant on the main backbone but potentially devastating on a slow-speed link to some outlying building. And changes to the table take some time, minutes perhaps, to propagate to all routers and servers.