![[Networking PCs Cover Image]](/catalog/covers/netpc.s.gif)
Sometimes the task of administering NetWare networks does not get the respect it deserves. NetWare has been so tightly linked to the DOS marketplace that some people believe that knowledge and skill with DOS provides all the necessary knowledge and skill to run a NetWare network. Don't believe it! NetWare is a full network operating system. It requires no more or less network administration skill than any other server-based network.
This chapter focuses on integrating NetWare into a TCP/IP network. This is a complex topic because there are many alternative ways to accomplish this task. For a full treatment of these alternatives see Novell's Guide to Integrating UNIX and NetWare Networks, by James E. Gaskin, Novell Press, 1994.
To sharpen our focus, we assume that TCP/IP is your primary
enterprise network technology and that you only use NetWare as a LAN
technology at some locations within the enterprise. We focus on adding
a NetWare LAN to an existing TCP/IP network in such a way that users on
the LAN can access the enterprise network services provided by TCP/IP.
We examine three ways to do this: Novell's IP gateway software, IP
tunneling, and NetWare/IP. The three techniques represent increasing
levels of integrating between NetWare and TCP/IP. When a Novell server
is used as an IP gateway, Novell protocols and TCP/IP share the same
Ethernet, but are not integrated at any higher level. In IP tunneling,
the TCP/IP network becomes the transport network for Novell packets by
encapsulating them inside IP datagrams. NetWare/IP takes this a step
further by making TCP/IP the native transport protocol of the Novell
protocol stack. Before we get into the details of these different
solutions, we need to know more about the NetWare protocols.
Novell has built a successful company selling NetWare to people
who want to build PC LANs. However, NetWare can do more. It can be
used to build an internet of NetWare networks because it has some of
the internetworking features that we are familiar with in TCP/IP. A
close look at the NetWare protocol suite reveals a rich, complex
protocol structure.
A comparison of Novell protocols and TCP/IP usually begins with
Novell's Internet Packet Exchange (IPX) protocol and its
Sequenced Packet Exchange (SPX) protocol--and for good reason.
These protocols are very similar in function to Internet Protocol
(IP) and Transmission Control Protocol (TCP).
Source Connection ID Destination Connection ID Sequence Number Acknowledgement Number
As of Novell release 3.11, SPX does not provide support for sliding
window acknowledgements.
Footnote:
How sliding windows are used by TCP/IP is explained in Chapter 1 of
TCP/IP Network Administration.
Each packet must be acknowledged before the next packet is sent. This
creates performance problems when NetWare is used over low-speed
lines, but it is not generally a problem for LANs operating at
Ethernet speeds, and it makes SPX simple enough to run in the most
primitive PCs. As the quality of the PC hardware installed at the
user's desktop continues to improve, it is likely that Novell will favor
protocol functionality over simplicity and that we will see sliding
windows and other advanced features included in the next version of
SPX.
IPX defines a hierarchical address structure that, within reason, is
independent of the underlying physical network. This independent
structure allows NetWare to
route packets between networks and to pass packets over dissimilar
physical networks. These are both features IPX shares with IP.
A Novell address is ten bytes long. The first four bytes identify the
network and the remaining six bytes identify the host on that network.
The host address is simply the physical layer address.d
Footnote:
The physical layer address is usually called the MAC (Media Access
Control) layer address.
It is 6 bytes long to accommodate a full 48-bit Ethernet address.
The four-byte network address is an arbitrary value assigned by the
network administrator. Take care to ensure that each network has a
unique address. Routing cannot work if there are duplicate network
addresses, though the addresses only need to be unique among the
networks that can actually communicate with each other. Assigning
unique addresses is not a problem when NetWare is used for isolated PC
LANs. If you have one isolated network, you can choose any address you
want. If you have an isolated enterprise network comprised of ten
NetWare LANs, only the ten network addresses need to be coordinated.
However, global NetWare communications require global network address
coordination.
Novell maintains an address registry to provide the necessary
coordination. Every organization that has been assigned an official IP
address by the InterNIC has a registered Novell network address.
Novell reserves an official IPX network address for every official IP
network address. Our imaginary nut packing company has the network
address 128.66; therefore, its reserved Novell address is 00804200. The
illustration in Figure 11-2 shows how Novell derived this address.
Figure 11-2 shows that the four-byte IP address is shifted to the right 8 bits
to become the four-byte IPX network address. The first byte of an IPX
address created in this way is always zero. Shifting the four-byte IP
address into the lower three bytes of the IPX network address is not a
problem. The network portion of an IP address is never longer than
three bytes, which is the case with a class C address. Class A
addresses and class B addresses have network portions that are only one
and two bytes long, respectively. The host portion of the IP address
can be discarded because the IPX address provides a separate six-byte
field for identifying the host. Following this simple guideline, the IP
address 128.66.12.1 produces the IPX network address 00804212.
Don't confuse the IPX network address with the internal network
number. The IPX network address is the same for every system on
an IPX subnet. The internal network number must be different on
every NetWare server. The internal network is a logical network that
exists inside of the server and is used by the server to route packets
to the physical networks. All servers running NetWare version 3.0 or
higher require that a unique internal network number be provided during
the initial installation. An easy way to ensure uniqueness is to use
the system's IP address as its internal network number. No two systems
have the same IP address, so the number won't conflict with any other
server, and it won't conflict with the IPX network address because that
address uses only three bytes of the IP address. Using the example
above, a server with the IP address 128.66.12.1 should be assigned an
IPX network address of 00804212 and an internal network number of
80421201.
IPX routes packets based on the network portion of the destination
address. The network address is used in a table lookup to determine
how a datagram is routed. The routing table points to the "next-hop"
on the path to the remote network. IPX does
not know the end-to-end path that a datagram will take. It counts on
the router at the next-hop to know how to forward the datagram on
toward its destination. Sound familiar? It should. It is very
similar to the way IP handles routes.
The protocol used to distribute routes among servers and routers is
the familiar Routing Information Protocol
(RIP).d
Footnote:
The TCP/IP version of RIP is covered in detail in Chapter 7 of
TCP/IP Network Administration.
RIP works in much the same way on a Novell network as it does on a
TCP/IP network. Routers, which can be thought of as NetWare servers
that connect to more than one network, periodically broadcast routes to
the networks to which they are attached. This information is used by
other routers to update their routing tables and is, in turn, passed on
by them to still other routers. Thus the routing information is
disseminated router by router throughout the Novell network.
Footnote:
NetWare Lite is a peer-to-peer network similar to the NetBIOS
networks. However, traditional Novell networks
are strict client/server networks.
Workstations need to know what servers are available and what services
they offer. The Service Advertising Protocol (SAP) provides this
information.
Servers and routers maintain a database of information called the
bindery, which contains information about all of the servers on
the network. Periodic SAP broadcasts are used to distribute this
information to other servers and routers on the local network. As
routers broadcast this information over each of the networks they
are connected to, the information eventually is distributed throughout
the entire network.
A client queries its server for bindery information using a SAP service
query. The server responds to the client's specific request with a SAP
service response. SAP combines broadcasts and directed unicasts to
cover the full range of needs for server information. Broadcasts
distribute a global picture of all of the services on the network to
every server. The clients then query their local servers and get
information about any service on the network. The client doesn't need
to know about all of the remote servers because its local server does.
In a large internet, the overhead of broadcast protocols like RIP and
SAP can be significant. Both of these protocols broadcast complete
updates. For RIP, the update is a full routing table; for SAP, it is a
complete set of bindery information. Complete updates can generate
a substantial amount
of data.
Novell realizes this is a potential problem and is developing a version
of the OSI Intermediate System to Intermediate System (IS-IS)
routing protocol specifically for NetWare. The NetWare version of the
protocol is called NetWare Link Services Protocol (NLSP). NLSP
carries both routing and service advertising information. It still
uses periodic broadcasts to distribute the data, but it only sends
changes, not complete databases, which dramatically reduces network
overhead.
IPX, SPX, RIP, and even SAP are all low-level support protocols. They
provide the addressing, routing, and transport services that are
necessary for the operation of a Novell network. They do not provide
direct user services or the applications interface required by user
programs. These services are provided by the NetWare Core
Protocol and the Workstation Shell.
NCP provides the file and print services that make NetWare so useful,
but it is not limited to file and print services. NCP handles
connection services, accounting services, bindery services, directory
services, job queue services, and several other things.d
Footnote:
A list of NCP service requests is contained in Novell's Guide to
NetWare LAN Analysis, by Laura Chappell, Novell Press, 1993.
NCP is literally the core of NetWare. It is the protocol that clients
use to request services and that the server uses to reply to those
requests.
NCP is a request-response protocol.
Each request elicits
a response, thus simplifying the protocol implementation, and in
particular the implementation of error recovery. An NCP client simply
times out and reissues a request if it does not receive a response.
Using this simple error recovery technique, NCP can run directly over
IPX without requiring the reliability of SPX.
Requiring a request and a response to exchange data is
inefficient in some circumstances. It is particularly inefficient if reading
a large file requires an exchange of packets for each
block. Novell addresses this performance issue with
burst mode transfers.
Burst mode is an NCP Request Type that is designed to make
reading files more efficient. A single burst-mode NCP request can
retrieve up to 64K bytes of data. The actual amount of data transferred
is based on the packet size negotiated by the two systems and the
number of burst-mode packet buffers configured on the client.d
Footnote:
The number of burst-mode packet buffers is defined by the pb
buffers = n statement in the client's NET.CFG file. The
maximum value for n is 10.
Transfers of 8K bytes at a time are easily achieved by systems on an
Ethernet.
NCP is implemented in the Workstation Shell--also called the
NetWare Shell. The shell is the TSR named NETx.COM, which
intercepts DOS software interrupts 21h, 24h, and 17h. It examines the
application's request and decides if it should be processed locally by
DOS or processed remotely by the NetWare server. The shell converts
requests that are bound for the server into NCP messages and passes
them to IPX for delivery.
Most applications talk to the Novell network through the shell, but not
all. Some Novell applications interface directly to SPX;
others interface directly to IPX. Novell even provides a NetBIOS
emulator so that NetBIOS applications can run over the Novell network.
Figure 11-3 shows these various interfaces.
The variety of application interfaces provides developers with a great
deal of flexibility, but they also complicate things. It is not as
simple to run NCP over TCP/IP as it is to run NetBIOS over TCP/IP. The
fact that some applications bypass NCP and go directly to SPX or IPX
means that it isn't simple to replace SPX and IPX with TCP and IP.
Novell has made several attempts to address NetWare and TCP/IP
integration, which is why there are so many different ways to handle
it. We begin our discussion of Novell integration techniques with
their TCP/IP subsystem.
Footnote:
Novell began this practice with NetWare 3.11. If your users are
using an earlier version of NetWare, they should upgrade before connecting to
your TCP/IP internet.
The software, usually called the TCP/IP
subsystem, is not a full suite of TCP/IP protocols. It doesn't turn
a Novell server into an NFS server, an FTP server, a Telnet login host,
or any of the other things you might expect on a TCP/IP server. Instead
it provides transport services and applications interfaces for
other separately priced products that do provide those services.
The TCP/IP subsystem provides:
Only slightly more effort is required to configure the clients so that
they can interact with both the Novell server and the TCP/IP hosts that
share the network. Using ODI, NDIS, or packet drivers, it is
possible for a single network interface to support more than one
protocol stack.
With an ODI driver in place, the client can send an NCP message with
one packet and an IP datagram with the next.
Figure 11-4 shows a client sending NetWare and TCP/IP packets out of
the same network interface. However, even with two protocol stacks in
the client, the logical separation between NetWare and TCP/IP still
exists. The client cannot interact with the Novell server using TCP/IP
or with the TCP/IP host using NetWare. Novell's introduction of the
ODI driver was an important first step in integrating PC clients into
multi-protocol environments, but it is not a complete solution.
The coexistence of TCP/IP and NetWare on a single network does not
require the installation of TCP/IP software in the server. In Figure
11-4, the Novell server speaks pure NetWare; only the clients speak
both NetWare and TCP/IP. This level of integration has been available
ever since the introduction of the NDIS, ODI, and packet drivers. The
server does not need the TCP/IP subsystem unless it runs optional
TCP/IP services or acts as a gateway to a TCP/IP network.
In the topology shown in Figure 11-5, NetWare traffic stays on the
Novell subnet, and the Novell gateway passes IP traffic to the TCP/IP
internet. Clients located on the Novell subnet communicate through the
server to hosts located on the TCP/IP network. The clients must run
both a NetWare and a TCP/IP protocol stack to use both Novell and
TCP/IP services, but it is possible for a pure TCP/IP client located
behind the Novell router to successfully communicate with remote TCP/IP
hosts without running NetWare at all.
The SYS:SYSTEM\\AUTOEXEC.NCF file that is created during the initial
installation contains the basic Novell server configuration.
Edit the file and then add
FRAME=ETHERNET_II to the LOAD lan_driver statement
Footnote:
The LOAD lan_driver statement is explained in great
detail in the Novell NetWare Version 3.11 System Administration
manual.
as in this example:
The specific configuration parameters differ between network
adapter boards, but most of the parameters are the same configuration
values, such as I/O Port (PORT) and IRQ interrupt (INT).
The few Novell-specific
parameters are easily explained. We know what the FRAME parameter is
for because we just added it. The NAME parameter is a logical name that is
used within the configuration to refer to this interface. We use the
name later in the configuration to bind TCP/IP to the interface. NAME
is an arbitrary string of up to 17 characters; in the example we use
NUTS-NET as the interface name. Any string you think is
descriptive will do.
None of these parameters is specific to the TCP/IP subsystem except for
the FRAME parameter. All of the other values are already in the
configuration file from the initial installation of NetWare. We are
only adding the correct framing to make the interface compatible with
our TCP/IP Ethernet.
The second installation step is to load the TCP/IP module. A NetWare
program is called a NetWare Loadable Module (NLM). The TCP/IP
module is ITCPIP.NLM. It is loaded using the LOAD command, which
can be as simple as LOAD TCPIP.
This works in most cases, but it is not exactly what we want.
The
default configuration of the TCP/IP module runs the RIP routing
protocol and collects SNMP information for local processing, which are
both things we want to do. It does not, however, forward IP packets,
which we must do to use the server as an IP router. To
get the functions we want, enter the following command:
The TRAP option is used to direct SNMP information to the SNMP
monitoring station. Enter the address of your network monitoring
station in the form TRAP=ip-address, e.g., TRAP=128.66.3.7.d
Footnote:
All IP addresses in the Novell configuration file must be in
dotted decimal notation.
If no value is entered, the system assumes that SNMP information is
processed locally on the Novell server and viewed using the TCP/IP
Console (TCPCON) program. See NetWare v3.11 TCP/IP Transport
Supervisor's Guide for information on TCPCON.
The RIP parameter enables (RIP=YES) or disables (RIP=NO)
the RIP routing protocol. If no RIP parameter is entered, the protocol
is enabled by default. When RIP is enabled, the server listens to
routing updates, and when RIP is enabled and FORWARD=YES, the
server also sends out routing updates.
The Novell server normally learns all of its routing information
through RIP, but it is possible to add information to the
routing table manually even when RIP is running. This is usually done to add a
temporary default route that is used during startup or
information about a router that does not send out RIP updates. The
IPCONFIG NLM is used to add the routes. IPCONFIG has no command-line
options. To execute it, place a LOAD IPCONFIG in the
AUTOEXEC.NCF file.
When IPCONFIG is executed it reads the SYS:ETC\\GATEWAYS file and
installs any routes that are defined there in the routing table.
The format of this file is familiar to every UNIX system administrator
because it is the same as the /etc/gateways file that is read by
the UNIX routed command.d
Footnote:
Static routes, routed, and /etc/gateways are covered in
Chapter 7 of
TCP/IP Network Administration.
The SYS:ETC\\GATEWAYS file is typically used to define a temporary
default route. A sample default route is shown below:
The last step in installing the TCP/IP subsystem is binding TCP/IP to
the network interface. Novell's BIND command performs many of the same
functions that the ifconfig command performs on a UNIX system.
It defines most of the TCP/IP configuration
parameters. A sample command shows this:
The default configuration enables the Address Resolution Protocol
(ARP). ARP=NO disables ARP. Never disable ARP; it is needed to
map IP addresses to physical network addresses.
METRIC is used to prefer one interface over another. The higher the
METRIC number, the higher the "cost" of an interface, and therefore the
less it is preferred. This parameter is only useful if the server has
two interfaces that can reach the same destination, and there is
something about one of the interfaces (higher speed, lower usage
charges, etc.) that makes it "better" than the other interface.
A third obscure parameter is POISON, which enables poison reverse
processing for RIP updates. Poison reverse is a rarely used feature
that can increase routing stability and eliminate loops in complex IP
internets. Don't build complex IP internets out of Novell servers and
don't use POISON. While these three parameters, ARP, METRIC, and
POISON, can be ignored, there are two other BIND parameters that are
sometimes used. They are:
GATE DEFROUTE
This discussion of the various options and commands may make TCP/IP
configuration appear more complex than it is, but a typical configuration
is very simple. On most systems, the AUTOEXEC.NCF file contains the
following commands for the TCP/IP subsystem:
HOSTS NETWORKS SERVICES PROTOCOLS
All of these files have the exact same syntax and purpose as their UNIX
counterparts, which are covered in detail in TCP/IP Network
Administration. These files are also the same as the ones that
Novell uses with its LAN Workplace DOS software.
Most of these files can be ignored because they come
preconfigured with all the values you need. The HOSTS file is the only
one that you are likely to modify. HOSTS file modifications are
generally limited to adding the address of the local host and the
addresses of a few other frequently used hosts. The file can be
modified with any standard text editor.
IP tunneling is implemented in the IPTUNNEL driver that is provided as
part of the Novell TCP/IP subsystem. IPTUNNEL is a network driver that
functions just like an Ethernet driver. The difference is that it
passes packets to a TCP/IP network instead of to an Ethernet. It is
installed and used like any other driver. The steps to install IP
Tunneling are:
Next, IPX is bound to the interface of the BILLING network, which is a
pure NetWare network. The next BIND command connects TCP/IP to the
interface with the backbone network. None of this directly relates to IP
tunneling, but it is all necessary preliminary configuration.
Finally, we load the IPTUNNEL driver and bind IPX to it. Binding IPX
to the IPTUNNEL driver confuses some administrators, because they think they
should bind TCP/IP to the driver. If you remember that you want to
send IPX datagrams out over this interface, the reason for binding IPX
to the IP tunnel becomes quite clear.
The BIND command also assigns a Novell network number to the TCP/IP
network. From the point of view of the Novell servers, the TCP/IP
network is a Novell network in the same way that a local Ethernet
is a Novell network. For that reason, the TCP/IP network needs a Novell
network number. All servers that attach to the TCP/IP network must use
the same number. As discussed earlier, it is easier to keep the
network numbers straight if you base them on the TCP/IP address. In
our example the TCP/IP backbone is subnet 128.66.1.0. Based on the IP
network number-to-Novell network number mapping described earlier, the
decimal numbers 128, 66, and 1 are converted to hexadecimal and stored
in the lower three bytes of the Novell address. Therefore, the Novell
network number we use is 00804201.
The only configuration command that we haven't seen before is LOAD
IPTUNNEL. This command has several command-line
options:
PEER=IP-address .5
You may list up to 10 peers; each peer is listed on a separate IPTUNNEL
command. The sample configuration shows three Novell servers connected
to the TCP/IP network. One, of course, is the local system. The
remaining two servers are this system's peers, so we have two
IPTUNNEL commands.
CHKSUM=YES|NO LOCAL=IP-address PORT=port-number SHOW=YES|NO
The PEER option is the most commonly used. Identify every Novell server
and router in the group with a PEER command. In the sample,
there are three Novell servers. Each one is configured
with two PEER statement--one for each of the other servers.
The LOCAL parameter is also useful, though it is not required. The
system will assign a default IP address to the LOCAL parameter, and
everything will run fine. However, it is better to be explicit. It
gives you more control, and it is easier to troubleshoot when the
configuration is clearly defined in the configuration file.
The overhead of tunneling makes it a poor choice for some
applications. It can connect a client to a remote server, but it
should only be used to do that in limited cases. If a client depends
on the remote server for daily file and print services, the overhead of
tunneling is an unacceptable burden. A better use of tunneling is to
interconnect servers in such a way that clients get the bulk of their
services from a local server and only tunnel to the remote server for
occasional, specialized services.
IP tunneling is most often used to reach a remote location that cannot
be reached directly by IPX. TCP/IP is a popular WAN technolog; it
runs over a wider variety of physical networks than any other
protocol. In a TCP/IP enterprise network, tunneling may be the only
way to get from here to there. Tunneling can even be used to reach a
site on the other side of the world through the global Internet.
IP tunneling is functionally similar to the NetBIOS over TCP/IP service.
It works well but has its problems.
As we have pointed out, it adds overhead. In addition, its solution for
NetWare's dependence on broadcasts does not
scale well: the maximum number of peers is ten, and the number of peers
cannot simply be increased because a packet must be sent to each peer
every time a broadcast is sent. Updating a large number of peers would
overwhelm a server. But Novell saw these problems and developed another
solution--NetWare/IP.
To operate, a Novell network must disseminate server information and
routing information. On a LAN, the SAP and RIP information is
distributed via broadcasts, but as we noted
earlier, networks that depend on broadcasts cannot work
over a large TCP/IP internet. Tunneling solves the problem of
broadcast dependence by defining a list of peer servers to which
broadcast information is directly addressed. That solution, however,
does not scale well, so Novell limits the list of peers to ten
entries. NetWare/IP overcomes the scaling and distribution
problem by
creating a new central server specifically
designed to gather and distribute RIP and SAP information. The new
server is called the Domain SAP/RIP Service (DSS) server.
DSS is a simple and elegant solution. All RIP and SAP information is
collected by the central server. Clients then query the central DSS
server for that information. Packets are sent directly to and received
directly from the DSS server. Broadcasts are not necessary.
The DSS system requires very little configuration. The system
administrator does not enter server and routing information into the
DSS server because its databases are automatically configured by the
other systems on the network. Here's how:
To operate successfully, DSS depends on all of the servers knowing which
system is the DSS server. NetWare/IP advertises the DSS server using
features that exist in the standard TCP/IP domain name service.
The DSS domain is created as a subdomain of an existing DNS domain.
For example, our imaginary company has the domains nuts.com,
sales.nuts.com and plant.nuts.com. It is possible to
create DSS domains within any of these existing DNS domain. Imagine
that the marketing department wants to create a DSS domain within
sales.nuts.com. Furthermore, they have decided to call the DSS
domain netip.sales.nuts.com. To create the new domain, the
domain administrator adds the following entries to the
sales.nuts.com zone file:
Each DSS client is configured with a NetWare/IP domain name. In our
example all of the clients are given the DSS domain name of
netip.sales.nuts.com. The DSS domain name does not replace the
DNS domain name. All of these clients are also given a DNS domain
name; in our example it would be sales.nuts.com. The DNS domain
name is used in queries for the normal hostname information that DNS
is always used for on a TCP/IP network. The DSS domain name is only
used to locate the DSS servers. Once the servers are located, DSS
queries are sent directly to the DSS servers and DNS is not involved.
A NetWare/IP server can act as a DNS master server and as a DSS master
server, but it is not a good idea to put all of these tasks on one
system. Doing it all in one system is only suitable for very small
networks. On a larger network the workload of DNS and DSS can
interfere with the file and print services that are the real work of a
Novell server. If possible, offload DNS and DSS to other systems.
When adding NetWare/IP to an existing TCP/IP network you already have
access to operational DNS servers. Create the DSS subdomain on the
existing primary DNS server and use the existing servers to provide DNS
service to the NetWare/IP systems. If you have a large number of
NetWare/IP clients you may also want to purchase an extra PC to act
exclusively as a DSS server.
NetWare/IP depends on the TCP/IP subsystem for transport services.
The first step in installing NetWare/IP is to install the NetWare
server and the TCP/IP subsystem as outlined earlier in this chapter.
Next run the INSTALL program to load NetWare/IP from the
installation diskette. After the software is loaded, it is configured
using the UNICON utility.d
Footnote:
The UNICON utility is covered in detail in Novell's NetWare/IP
Administrator's Guide.
UNICON is a "universal console" utility that is used to configure a
number of different Novell products. It presents menus that the system
administrator uses to set various configuration values. DOS and UNIX
people who like the directness of command line input may be frustrated
working through the menus. However, the configuration procedure is very
similar to those used to configure Windows products, and most people
find it simple to work with and easy to understand. The
configuration menus cover a lot of different things. Only a few of
these are absolutely necessary to get a NetWare/IP server up and
running.
Enter LOAD UNICON at the console to start the UNICON utility.
Select Configure Server Profile from the main menu. The
configuration template is shown in Figure 11-9. The window shown in
the Figure contains most of the configuration values that are required
by TCP/IP. The values in this template are the ones we have come to
know so well, and they require very little explanation. There are two
small points that need clarification. People sometimes confuse DSS
with DNS. The Domain field on this template is the DNS domain.
The DSS domain is defined on another template.
The other item that needs explanation is the Synchronization
Interval, which is a Novell specific parameter. RIP and SAP
databases are normally updated every 60 seconds. This value can be
increased to reduce the amount of network traffic generated by the RIP
and SAP protocols. However, increasing the interval allows this
server's database to be out of synch with neighboring servers and
routers for an increased period of time. The default value is adequate
and does not usually require modification.
Use the arrow keys to select a field that you want to change and enter
the new value. When finished with a template press the escape key (Esc)
and select Yes when prompted to save your changes. This returns
you to the main menu.
To define the DSS domain for this server select Manage Services
from the main menu. This displays a menu that offers selections for
DNS Server, Hosts, and NetWare/IP. Ignore the first
two entries. DNS is already running on other servers on the TCP/IP
network. Running another DNS server on the Novell server is just a
waste of the Novell server's resources. Furthermore, you don't need to
configure anything about DNS in this menu because the values required
by the resolver, the domain name, and the list of name servers are
defined in the Configure Server Profile template. Select
NetWare/IP from this menu and Configure NetWare/IP Server
from the next menu that appears. This causes the window shown in
Figure 11-10 to appear.
Enter the DSS domain name in the NetWare/IP Domain field of this
template. In Figure 11-10 the DSS name is netip.sales.nuts.com.,
which is the domain name that our system uses to locate its DSS
server. If your system has more than one network interface, you will
also see the Preferred IP Address field. Figure 11-10 shows this
field because the sample Novell server is the IP gateway between the
Novell network and the TCP/IP backbone. The address should be the IP
address of the interface that attaches to the network that this system
share with its DSS server. In the example the shared network is the
TCP/IP backbone.
That's it! For an average server all you need to do is configure the
basic TCP/IP parameters, and the DSS domain name. Configuring the DSS
servers requires some additional effort.
First make sure that the DSS domain is properly delegated in the
primary DNS name server, and that the NetWare, TCP/IP and NetWare/IP
software is properly installed and configured on the local server.
Then start the UNICON utility. Select Manage Services from the
main menu and NetWare/IP from the Manage Services menu.
The NetWare/IP Server Administration menu shown in Figure 11-11
appears. To configure the primary DSS server, select Configure
Primary DSS from this menu.
The Primary DSS Configuration template is shown in Figure 11-12.
The NetWare/IP Domain field contains the name of the DSS domain,
netip.sales.nuts.com. The Primary DSS Host
Name field contains the DNS domain name of the local host.
(Remember the local host is the primary DSS server.)
11-12, the local host is money.sales.nuts.com.
The IPX Network Number field is the external IPX network used by
DSS. This should be a unique IPX network number that is not used by
any server as an internal number or by any IPX subnet as an external
number. In our example we choose an unused IP host address and
coverted it to an IPX address.
Selecting the last field in the template brings up a list of
configurable parameters. These are:
UDP Port Number for NetWare/IP Service SAP/RIP Database Synchronization Interval Maximum UDP Retransmissions UDP Checksum
Completing this template is all that is necessary to set up the primary
DSS server. The secondary servers are just as easy to configure and
are also set up through the NetWare/IP Server Administration
menu. On secondary servers, select the Configure
Secondary DSS menu item. The template shown in Figure 11-13
appears.
The Secondary DSS Configuration template, shown in Figure 11-13,
contains two fields: the NetWare/IP Domain field and the
Primary DSS Hosts field. Enter the DSS domain name in the first
field. It is netip.sales.nuts.com. in Figure 11-13. In the next
field, enter the DNS domain name of the primary DSS server. In the
Figure it is money.sales.nuts.com. The only time it is
necessary to enter the name of the primary server directly into the
NetWare/IP configuration is when you configure a secondary server. All
other systems locate the master servers via DNS. However, nothing in
the DNS database identifies which DSS server is primary and which
servers are secondary. They are all master servers and are all
expected to have valid information. There is no way that the secondary
servers can determine who is primary simply by querying the DNS
database. The name of the primary server must be defined directly in
the secondary servers configuration.
That's it. DSS configuration, like the configuration of any NetWare/IP
server, is actually quite simple.
Novell's NetWare is the leading PC LAN protocol. Novell networks are
strict client/server networks. The server provides the clients with
file and print services, routes packets, and handles most of the
network configuration. The client/server protocol that provides these
services is the NetWare Core Protocol (NCP).
The transport protocols that carry the NCP messages, Sequenced
Packet Exchange (SPX) and Internet Packet Exchange (IPX), are
based on the Xerox Network System (XNS) protocols. SPX, like
TCP, provides reliable, sequenced packet delivery. IPX, like IP, is a
connectionless datagram protocol. IPX defines the ten-byte Novell
address structure. The first four address bytes identify the network
and the remaining six bytes identify the host.
Despite some similarities, NetWare and TCP/IP are different and
incompatible protocols. Special effort is required to integrate Novell
networks into a TCP/IP internet. Novell offers several ways to do
this. Two of these are: Novell's TCP/IP subsystem and NetWare/IP.
The TCP/IP subsystem provides the Novell server with TCP/IP transport
services that coexist with the NetWare protocols. The subsystem allows
the server to run TCP/IP services for TCP/IP clients, to act as an IP
router, and to tunnel IPX packets through a TCP/IP network. IP
tunneling works by enclosing the IPX datagrams inside of IP datagrams.
The encapsulated IPX datagrams pass untouched through the TCP/IP
network using the IP protocol as a delivery service.
NetWare/IP replaces the Novell transport protocols with the UDP and IP
protocols from the TCP/IP protocol suite. NetWare/IP allows NCP to run
directly over TCP/IP. This is more efficient then IP tunneling.
NetWare/IP has other advantages that allow it to be used to construct
larger "NetWare over TCP/IP" networks than are possible with IP
tunneling.
Regardless of the integration technique used, Novell services are only
available to Novell clients. Only clients that run NCP can use NCP
services. TCP/IP is only an alternate transport protocol for Novell
clients and servers.
NetWare Protocols
NetWare is a LAN technology that is optimized for PCs. NetWare networks
are server-based, with the bulk of the network knowledge and the
configuration burden handled by the server. The client portion of NetWare
is simple enough to run on a primitive PC, so NetWare is suitable for a
very broad market.
Sequenced Packet Exchange
Like TCP, SPX provides reliable, sequenced packet delivery. (It's good
to mention this first so that people don't panic when IPX is described
as unreliable!) SPX is a connection-oriented protocol that creates a
virtual circuit between the sending and the receiving systems. It
provides packet sequencing information to ensure that packets arrive in
order, and it requires acknowledgement of the packets received to
guarantee that all packets are delivered. It does these things by
adding 12 bytes of information to the basic 30-byte IPX header. Among
other things, the added information includes:
The sender uses this two-byte field to identify the virtual circuit
connection. The sender assigns a unique value to the circuit for the
life of the connection.
This two-byte field contains the virtual circuit identifier assigned by
the remote system. When a system replies to an SPX packet, it uses the
Source Connection ID from the received packet as the
Destination Packet ID of the packet it sends. There is one
exception to this: when the connection is initially established, the
system that originates the connection cannot know what value the remote
system will use as a connection ID. In this case, the sender uses FFFF
as the Destination Connection ID for the very first packet and
then uses the value received from the remote system for all subsequent
packets.
SPX packets are numbered sequentially; this two-byte field holds the
sequence number. Each time a new packet is sent the Sequence
Number is incremented. The field is not incremented if a packet has
to be resent. The receiving station uses this field to check that it
is receiving packets in the proper order and that it has received all
packets.
This two-byte field contains the sequence number of the next
packet the receiving station expects. It is used in the
acknowledgement packet. When the station that has been sending out
data receives an acknowledgement, it checks this value to make sure that
the system receiving data expects the packet it plans to send next. If
the system sending data detects an error in the Acknowledgement
Number, it assumes that data has been lost and retransmits the
last unacknowledged packet.
IPX Addressing and Routing
Like IP, IPX is an unreliable, connectionless datagram protocol. Each
datagram travels the network independent of any other. IPX makes a
"best effort" to deliver data, but it cannot guarantee delivery because
it does not include error detection or correction. IPX depends on the
underlying network or the upper layer protocols to provide reliable
delivery.
Service Advertising Protocol
The importance of distributing routes throughout the network is
obvious; without routes we wouldn't know how to get from point A to
point B. On a Novell network it is also important to disseminate
information about servers. Everything on a Novell network centers on
the servers.d
NetWare Core Protocol
Most of the protocols discussed so far are derived from the Xerox
Network System (XNS) protocols and are almost identical to the
originals. But NetWare is much more than a reimplementation of
XNS for PCs. The real functionality of NetWare
lies above these low-level protocols in the NetWare Core Protocol
(NCP).
TCP/IP Transport Services
Novell includes TCP/IP in the standard NetWare package.
This list of services doesn't cover everything you might want, but it
does provide some tools for integrating Novell networks into a TCP/IP
environment. It is possible to use the transport services to host
TCP/IP services, such as NFS and LPD, on a NetWare server to support
UNIX workstation clients. That approach is suitable if you have a
large Novell network and very few UNIX workstations. Novell's Guide
to Integrating UNIX and NetWare Networks deals with this approach.
We, on the other hand, assume that you have a large TCP/IP network with
a few Novell servers. In our environment, the Novell server's ability
to act as an IP router and to tunnel IPX packets through a TCP/IP
network are more important for integrating NetWare and TCP/IP. We
discuss how these two features are used to deal with the following
types of networks:
A NetWare internet overlayed on top of a TCP/IP internet
NetWare and TCP/IP can coexist on the same physical network without
problems. It is possible for a Novell server and its clients to operate
on the same Ethernet with a group of TCP/IP hosts without either group
interfering with, or even noticing, the other. In this case, two
logical networks, one NetWare and one TCP/IP, exist on the same
physical Ethernet network.
Novell's IP Gateway
A Novell network can be connected to a TCP/IP internet through its
server. The server can act as an IP router because Novell's TCP/IP
subsystem supports IP packet forwarding and IP routing protocols.
Figure 11-5 shows this topology.
Configuring the Gateway
The TCP/IP subsystem is not part of the default Novell server
installation; it is an option. As such, you need to take a few steps
to add it to the server:
LOAD NE2000 PORT=300 INT=3 FRAME=ETHERNET_II NAME=NUTS-NET
The LOAD command is followed by the name of the ODI driver,
NE2000 in the example, and a variable group of configuration
parameters. Several drivers, such as NE2000, NE3200, 3C503, etc., are
included with the Novell software. Others are obtained directly from
the network adapter manufacturers.
LOAD TCPIP FORWARD=YES
The TCPIP command line has three options: FORWARD, TRAP, and RIP.
FORWARD=YES is used when the Novell server acts as an IP router.
FORWARD=NO, which is the default, is used when the Novell server
has only one network interface. It prevents the server from forwarding
IP packets and thus from acting as a router. In that case, the server
relies on an external router to forward packets to other networks.
net 0.0.0.0 gateway 128.66.12.3 active
NetWare uses the default route when no specific route to a destination
is found in the routing table. The keyword net is followed by
the address of the destination network. 0.0.0.0 is a special address
used for the default route. The keyword
gateway indicates that the following address is
the gateway used to reach the
destination; in this example it is 128.66.12.3. The keyword
active permits RIP to modify this route based on the information
received in the RIP updates. Therefore if RIP receives a default route
in an update, it uses it to replace this temporary route. If the
keyword passive is used, it prevents RIP from updating this
route. Avoid using a passive default route; it defeats the purpose of
dynamic routing and makes troubleshooting more difficult.
BIND IP TO NUTS-NET ADDR=128.66.12.1 MASK=255.255.255.0 BCAST=128.66.12.255
The command binds TCP/IP to the network interface identified earlier in
the configuration as NUTS-NET. The sample command-line parameters are
the IP address (ADDR), subnet mask (MASK), and broadcast address (BCAST)
that we are so familiar with. Other less frequently used configuration
parameters can be entered on the BIND command line as well. Two of these are
the same seldom-used parameters found on the ifconfig command
line: ARP and METRIC.
This parameter defines a static default route. It should only be used
if RIP is disabled (RIP=NO) on this interface. Use a default
static route only when there is only one path to the outside world. Don't
use one when the local network has multiple routers.
This parameter tells the Novell server to advertise itself as the
default gateway. It is used only if FORWARD is set to YES,
and then only if the Novell server is the local subnet's sole path to
the outside world. If DEFROUTE=YES, the server advertises itself
as the default route in RIP updates. If DEFROUTE=NO, the server
sends out "normal" RIP updates that include only specific routing
information.
LOAD 3C509 FRAME=ETHERNET_II NAME=SALES-NET
LOAD TCPIP TRAP=128.66.7.3
BIND IP TO SALES-NET ADDR=128.66.7.1 MASK=255.255.255.0 BCAST=128.66.7.255
These entries contain all of the basic configuration information we
have come to expect with a TCP/IP installation. The one thing
missing is the list of domain name servers. The reason is that the
TCP/IP subsystem does
not use DNS; it relies on local database files for that type of
information.
TCP/IP Database Files
Novell's TCP/IP subsystem uses the same database files as a UNIX
system. They are even located in the same directory--the ETC
directory--though the UNIX path is /etc and the Novell path is
SYS:\\ETC. The database files are:
This file maps hostnames to IP addresses.
This file maps network names to network numbers.
This file maps network services to port numbers.
This file map transport protocols to protocol numbers.
IP Tunneling
One of the advantages of NetWare is that, like TCP/IP, it is a logical
network that runs over a variety of physical networks. The physical
network merely provides the delivery service for the Novell packets. This
makes it possible to run NetWare over a TCP/IP network by replacing the driver
for the physical network with a driver for a TCP/IP network; thus
the TCP/IP network provides the delivery service. This is called
IP tunneling or IPX/IP tunneling
because the Novell packets "tunnel" through the TCP/IP network without
interacting with it. A tunnel is a means to get from one place to
another, nothing more.
A section of the AUTOEXEC.NCF file for the server named ACCTS in Figure 11-6
shows the three IP tunneling installation steps:
FILE SERVER NAME ACCTS
IPX INTERNAL NET 80420105
LOAD NE2000 PORT=300 INT=3 NAME=BILLING
LOAD 3C509 FRAME=ETHERNET_II NAME=BACKBONE
LOAD TCPIP
BIND IPX TO BILLING NET=00804280
BIND IP TO BACKBONE ADDR=128.66.1.5 MASK=255.255.255.0 BCAST=128.66.1.255
LOAD IPTUNNEL LOCAL=128.66.1.5 PEER=128.66.1.8
LOAD IPTUNNEL LOCAL=128.66.1.5 PEER=128.66.1.14
BIND IPX TO IPTUNNEL NET=00804201
The ACCTS server connects the BILLING subnet to the company TCP/IP
network. The first line of the file loads the driver for the local
Ethernet, the second line loads the Ethernet driver for the company's
enterprise network, and the third line loads the TCP/IP software. So
far this is exactly the type of configuration we saw in the previous
section.
The PEER parameter specifies the address of a remote IPX router or
server with which this system communicates. A Novell network depends
on broadcasts to distribute RIP and SAP information. However,
broadcasts cannot be used over a large IP internet; most IP routers do
not forward broadcasts, and some physical network technologies do not
support them. Therefore a Novell network running over TCP/IP
must have some way to distribute SAP and RIP information that does not
depend on broadcasts. That is where the PEER parameter comes in.
Every time IPX sends out a broadcast packet it also addresses a packet
containing the same information to every server identified as a PEER.
In IP tunneling, NetWare packets are encapsulated inside of UDP
datagrams. This parameter turns on the UDP checksum so that the system
can detect if the UDP packet becomes corrupted. The default is
CHKSUM=YES. CHKSUM=NO disables UDP checksums. Unless you have
an old system on your network that cannot properly handle checksums,
let this value default to YES.
The LOCAL parameter associates the IPTUNNEL with a specific network
interface. If the LOCAL parameter is not used, the IPTUNNEL is
associated with the first network interface to which TCP/IP was bound.
The PORT parameter assigns a UDP port number to be used for IP
tunneling. UDP port 213 is officially assigned for tunneling IPX
datagrams. The PORT parameter is used only if you don't want to use
the officially assigned port. Of course, changing the port prevents
the tunnel from working unless all of the computers using that tunnel
use the same non-standard port number.
The SHOW parameter is used to view the current configuration of the
IPTUNNEL. Enter LOAD IPTUNNEL SHOW=YES to see the current
configuration.
The Limitations of Tunneling
Tunneling works through encapsulation. The Novell packets are
enclosed inside of IP datagrams. As far as the TCP/IP network is
concerned, the NetWare packets are just "data," and as far as the Novell
network is concerned, the TCP/IP network is just a delivery service.
Figure 11-7 illustrates encapsulation and shows how tunneling
adds overhead. The IPX datagram is encapsulated in a UDP packet and in
an IP datagram. Then the whole thing is encapsulated in the frame of
some physical network for delivery. The additional layers of
encapsulation require processing at both ends.
NetWare/IP
The last Novell TCP/IP integration product that we discuss is
NetWare/IP. NetWare/IP replaces IPX with UDP and IP, which permits NCP
to run directly over IP. It is functionally similar to tunneling in
that it allows Novell networks, clients, and servers to communicate
over a TCP/IP network, but with two big advantages:
Overhead is reduced because there are fewer layers of encapsulation.
A packet passed through an IP tunnel has
all of the Novell layers plus all of the TCP/IP layers. Tunneling
adds the lower layers of TCP/IP to the lower layers of NetWare,
while NetWare/IP replaces the lower Novell layers with the lower
layers of TCP/IP. Fewer layers, less encapsulation, less processing.
Figure 11-8 shows the layers of encapsulation in NetWare/IP. Compare
this to the layers shown in Figure 11-7, and you'll easily see that
there is less protocol overhead.
Servers and routers that require RIP or SAP information query the DSS
server directly. There is no need for internet-wide broadcasts.
The advantage of the NetWare/IP DSS server over the list of
peers used by IP tunneling is obvious. Ten servers update the DSS
server with ten packets. Ten servers each updating the other
nine servers that are their peers send out a total of 90 packets.
Defining a DSS Domain
DSS shares some of the concepts of DNS. It has primary and secondary
servers, and the Novell systems that share a DSS server are grouped
together in a "domain." The unique thing about a DNS domain created to
support DSS is that it only contains nameserver (NS) records that
identify the primary and secondary DSS servers. It does not contain
any other entries because its only purpose is to identify the DSS
servers to their clients.
netip.sales.nuts.com. IN NS cash.sales.nuts.com.
IN NS money.sales.nuts.com.
IN NS dollars.sales.nuts.com.
These entries create a subdomain called netip within the
sales.nuts.com domain and define the master servers for this
new domain as cash, money and dollars. Normally the
master servers in a DNS domain maintain database files of host
information for the systems in the domain. Not in this case. There
are no host entries for the netip domain. In fact, none of these
servers are even required to run DNS. They are DSS servers. This new
domain is only used by DSS clients to find out who their servers are.
Configuring DSS
Configuring the DSS master servers is surprisingly easy to do. The DSS
database information comes from the Novell servers that gather it on
their local networks and forward it to the DSS server. Therefore you
don't need to provide it. All you have to do is tell the system that
it is a master DSS server. Do that through the UNICON utility.
This parameter assigns the port numbers that are used by the DSS
service. The defaults are 43981 and 43982. Don't change it. The only
reason for changing this value is if it conflicts with some other
application already installed in your network.
This parameter controls how often NetWare/IP servers query the DSS
server for updates. The default is 5 minutes. This value generally
does not need to be changed. Possible values range from 1 minute to 60
minutes.
This parameter specifies how many times a DSS packet is re-sent if it
is unacknowledged. The default is 3, which is usually adequate for any
local area network. If the network includes poor-quality wide area
network links and it appears that remote servers are not receiving
proper updates, increase this value. This value can range from 1 to 48
retries.
This parameter enables (YES) or disables (NO) UDP checksums. The
default is NO. If your network includes some poor quality connections,
enabling checksums may increase the system's ability to detect errors.