NetWare 5.1 Advanced Administration

Chapter 3: Building a TCP/IP Network Using NetWare 5.1

Objectives:

This chapter discusses installing the NDS objects and the services needed by a network that uses TCP/IP. The objectives important to this chapter are on page 3-1:

1. Configure a DHCP Server
2. Create a Private Network with NAT
3. Configure a DNS Server
4. Configure Dynamic DNS
5. Configure SLP

 Concepts:

Introduction

With the implementation of NetWare 5, Novell supported and now recommends that we use the TCP/IP suite of protocols. The TCP/IP suite is often referred simply as IP. Electronic business practices now require IP compatibility.

Configure a DHCP Server

NetWare 4.x (and earlier versions) used IPX as the native protocol suite. An advantage to this was that workstations were automatically assigned addresses by the network, and the administrator did not have to intervene.

In an IP network, each device needs a unique IP address. Assignment of these addresses takes some planning. First, there are two major approaches:

• Static assignment - someone has to manually configure the address on each device. Unless your network is small, this is very painful.
• Dynamic assignment - a server on the network can assign an address to workstations as they are signed on. You will still want to manually configure addresses on servers, printers, routers, and other network devices.

Dynamic Host Configuration Protocol (DHCP) service allows us to dynamically assign IP addresses to hosts on an IP network. You need to understand that, as far as IP is concerned, "host" means any device on the network. Three methods for assigning addresses are listed on page 3-3:

• Automatic Allocation: DHCP assigns a permanent IP address to a host.
• Dynamic Allocation: An IP address is assigned to a host for a limited period of time (or until the host relinquishes the address). Also called address leasing.
• Manual Allocation: This method requires that you assign the address. DHCP simply delivers the address to the host.

A new feature of this course outlines the process used to obtain an IP address from a server:

1. First a workstation broadcasts a DHCPDISCOVER message.
2. One or more DHCP servers respond with a DHCPOFFER message, including an available network address.
3. The workstation receives one or more DHCPOFFER messages from one or more DHCP servers. It chooses one server to accept. The workstation broadcasts a DHCPREQUEST message that identifies the server it has selected.
4. The DHCP servers listen for the DHCPREQUEST broadcast from the workstation. Servers that were not selected use this message as notification that their offer is declined. The server selected in the DHCPREQUEST message responds with a DHCPACK message containing the address and configuration parameters for the
   client.

Know this sequence: Discover, Offer, Request, Acknowledgment.

You may not be aware that the process above has a flaw. Note that the Discover and Request messages are broadcast messages. Do you know that, normally, routers do not forward broadcasts? (Memorize that, if you don't.) This means that there would need to be a DHCP server on each network you administer, and each segment separated by routers. That could be a lot of DHCP servers. There is a solution, however.

A relay agent is software that runs on a NetWare server. If a DHCP request is made and there is no DHCP server handy, the relay agent forwards the request to a DHCP server that resides on a remote network. The relay agent also forwards the response back to the workstation. Novell's relay agent is called BOOTPFWD.NLM.

To install and configure DNS/DHCP, you must

• extend the schema of the Tree,
• install the Snap-Ins to NetWare Administrator, and
• configure settings through another utility, DNS/DHCP Management Console.

The DNS/DHCP Management Console is a Java utility run from a workstation. It can be run from NetWare Administrator or as a standalone. The workstation you use must have 48 MB of RAM (64 MB is recommended).

Several new DNS and DHCP objects are possible in NDS once the schema is extended to include them. Three objects are created automatically when the schema is extended:

• DNSDHCP-GROUP group object - This is actually an avenue for access to information about any DNS or DHCP object that will be created in the Tree. Only one such Group object is allowed in a Tree, and all DNS and DHCP objects created become trustees of it, so they can use it to learn information about other objects that are made members of it. Servers that are made DNS or DHCP servers are automatically members of this Group.
• DNS-DHCP locator object - This object contains global defaults, DHCP options,and lists of all DHCP and DNS servers, subnets, and zones in the NDS tree. Only one is allowed in a Tree and it is not configurable, so it does not appear in the Management Console.
• RootServerInfo zone object - This object points to root servers on the Internet. Root servers are servers that maintain listings of assignments in Internet domains (like .COM, .EDU and .NET). It is necessary to refer to root servers for URLs that are not handled by DNS servers on your network.

Below is a list of five more DHCP objects that are available (can be created) once the schema is extended. On the right is a list of four more Domain Name Service (DNS) objects that are available once the schema has been extended. Do not confuse these possible objects with the three default objects above.

Five Possible DHCP Objects	Four Possible DNS Objects
DHCP Server Object Subnet Object Subnet Address Range Object IP Address Object Subnet Pool Object	DNS Name Server Object DNS Zone Object Resource Record Set Object Resource Record Object

These objects are not defined at this point in the text, just named.

The book explains that Novell's version of DHCP service is integrated with NDS, and that it works well this way for these reasons:

• DHCP objects are backed up when you back up NDS
• DHCP service has redundancy in NDS, since NDS is stored in multiple replicas
• NDS works well across multiple networks, and its version of DHCP does as well

A possible problem with multiple DHCP servers is discussed. Since the information about available addresses is stored in NDS, all of your DHCP servers will know about the same available addresses. What if one server tries to assign an address already assigned by another server? (Remember, changes in NDS have to propagate between servers. This takes some finite amount of time.) It is possible that neither addressable device would continue to function. This can be avoided if you enable "ping ahead", telling servers to ping an address before they offer it. If it responds, the server marks it in the database, and goes to the next one. The actual property to turn on for the DHCP server is called "Ping Enabled".

It may be a bit early to mention it, but the book tells us in this section that the program to run DHCP service on a Novell server is DHCPSRVR.NLM.

The next topic is a discussion of the steps for installing DNS/DHCP support. You should be aware that the files needed to do so are put in two directories when NetWare 5.1 is installed: SYS:SYSTEM and SYS:PUBLIC\DNSDHCP.

Part One: Extend the Schema

There are three ways to extend the NDS Schema:

• Install Novell DNS/DHCP Services during the initial NetWare installation.
• Install Novell DNS/DHCP Services by running the NetWare installation program from the NetWare GUI, and choosing to install DNS/DHCP services.
• Run DNIPINST.NLM. This should not be necessary, but remember it as a possible method. You may be asked questions relating to any or all of these methods on your certification test. This is a manual method. It requires you to log in to the server again, and specify what context you want the required objects created in.

Part Two: Install the Management Console and the Snap-Ins

The DNS/DHCP Management Console is run from a workstation. You will need to have installed the latest NetWare client on a workstation, otherwise that workstation cannot run the DNS/DHCP Management Console.

On a workstation that has the proper client, log in to the server and run the SYS:\PUBLIC\DNSDHCP\SETUP.EXE program. (Test question warning: this step does not extend the schema, it installs the Management Console.) Note that the exercise requires you to save the Snap-Ins to the server directory that the NetWare Administrator program is in. It is recommended that you use the one in SYS:PUBLIC\WIN32. Once you have done this, reboot the workstation for the changes to take effect. You will get an icon on the desktop to run the Management Console.

Part Three: Configuring and Starting Services

Begin by running the Management Console, either as a standalone or from NetWare Administrator. If running the program as a standalone, the executable you want is DNSDHCP.EXE. You may need to specify which of several Trees you are configuring services for.

You will note, from the appearance of the startup screen that Management Console is a Java application, and that it does not resemble NetWare Administrator. It is closer to ConsoleOne. The main screen has two tabs: DNS Service and DHCP Service. You will want to be careful to select the correct tab before trying to configure or manage a service. Certain commands and buttons on the tool bar are specific to each tab.

There are three panels: the left panel shows a tree view of resources, the bottom panel shows the servers that exist (either DNS or DHCP), and the right panel shows details about objects selected from one of the other two panels.

The next topic is creating and configuring DHCP servers. You can create a DHCP server in four kinds of containers. This ordering gives you a better mnemonic than the book's order- COOL:

• a Country
• an Organization
• an Organizational Unit
• a Locality - I don't think we have discussed this kind of container. Think of it as a "group of containers", perhaps a parent container for several containers in one city or geographic region. I could create a Locality called Greater Detroit, for example, that could contain other containers for Detroit, Southfield, Romulus, Ann Arbor, and other nearby communities.

The chapter shows a procedure for creating a DHCP server.

1. Click the DHCP tab
2. Click the Create button (it looks like a cube)
3. Choose DHCP server, then browse for the Novell server that will run the DHCPSRVR.NLM program.

Note that you have to use an actual NetWare server, and that the icon for the DHCP server will have a red or pink diagonal line through it until it is running DHCP service on the network. The act of designating the server in Management Console does not load the NLM, so the service is not running yet. (Don't load it yet.)

Next, the Management Console is used to create a DHCP Subnet object. It can only be created in the same four kinds of containers that can hold a DHCP server. It has several purposes. One is to specify the network address used on your network. Another is to hold the information needed to assign addresses to hosts on your network. Yet another purpose is to hold all the information that will allow you to use subnets on your network. Why use subnets? I have seen subnets used as an economy measure. One IP network license can be subnetted, or subdivided, to create several logical networks, which can then be used at several sites.

Critical properties of the Subnet Object:

• Subnet Name - must be unique in the Tree
• NDS Context - the NDS container you create the Subnet object in
• Subnet Address - must be unique in the Tree, it is the address of the sub-network. If you are not subdividing your network address, this number will be your network address.
• Subnet Mask - the actual subnet mask to be used. If you have a class A license, the mask is 255.0.0.0; class B is 255.255.0.0; class C is 255.255.255.0. If you are subnetting, look over the chapter on subnetting in the Networking Technologies class. (Ironically, I am teaching that class this term, but we won't cover that chapter for a few weeks.)
• Default DHCP Server - there should only be one DHCP server on a LAN segment. This does not have to be filled in when creating the Subnet object.

Next, you create a Subnet Address Range (SAR) object , which holds information about the range of addresses that can be used on a particular subnet. To create one, first select a Subnet Object that it will associate with, then follow the steps in the text. (Note that the Subnet object is a sort of container: Subnet Address Range and IP Address objects are created in the Subnet object.) The Subnet Address Range object can be configured to exclude certain addresses from assignment, simply by changing the starting and ending address values of its range.

The fourth available DHCP object is an IP Address object, which is used to assign a specific address, or to exclude a specific address from assignment. Some addresses in your effective range will need to be excluded because they are assigned to printers and servers. You may not be able to exclude these by changing the range of the SAR without losing other addresses, so this method exists. Two addresses that are normally excluded on your network are addresses ending in 0 and 255. In a class C environment, for example, an address of the form x.y.z.0 is the address of the network itself, while x.y.z.255 is a broadcast address for that network.

The last DHCP object is the Subnet Pool Object, which can only be created in a COOL container, as above. This object allows you to use several subnets on one physical network.

Having created all the above objects, we are now ready to start the DHCP server we created at the beginning. DHCP service is started by loading DHCPSRVR.NLM on the server in question. After DHCP service is running on the network, workstations can be configured to take advantage of it. If there are problems with the DHCP server, you may wish to unload the NLM, then load it again in debug mode with the command

  DHCPSRVR -D3

Configuring a workstation to use DHCP service is rather simple. On a Windows workstation:

1. Right-click Network Neighborhood
2. Choose Properties
3. Choose Protocols
4. Double-click TCP/IP protocol
5. If you get nothing, log back in to the workstation as an administrator of the workstation. (Mainly an NT problem.) If you get the properties screen for TCP/IP, select Obtain an IP address automatically.
6. Save your work and reboot.

Create a Private Network with NAT

The next topic in the chapter is Network Address Translation (NAT). NAT is a service that is used when you are running private addresses on your network, but either want your users to be able to reach the Internet or want people outside your network to reach some of your resources.

To understand this, you need to know that all IP addresses in the world were meant to be unique. These are called registered or public addresses. This scheme would allow any IP addressed machine to contact any other (in theory) because the address would identify the network and the host uniquely. At a certain point, however, the world began to run out of addresses. (It was also believed that there would be networks that would have no need to contact other networks. Yeah, right...)

So the Internet Assigned Numbers Authority (IANA) has designated some address ranges as private or unregistered addresses. They are also called nonroutable addresses:

• 10.0.0.0 – 10.255.255.255 (This is a class A address range.)
• 172.16.0.0 – 172.31.255.255 (This is a class B address range.)
• 192.168.0.0 – 192.168.255.255 (This is a class C address range.)

Within any organization, addresses in these ranges may be used without registering the addresses with IANA. Each address you use within your network must still be unique in your network. The problem is that there is no guarantee whatsoever that any address I use in my organization is not already in use in your organization, which makes direct networking between our networks unreliable, if not impossible.

This is where NAT comes in. NAT service runs on a router. The router has to know about your network's private addressing scheme. It also has to be given at least one public address to use for incoming or outgoing traffic. (More on the actual number required in a minute.)

NAT serves several purposes. It can allow traffic in to specific devices, it can allow traffic out from specific devices, and it effectively hides your actual addresses from the outside world, so it acts as a firewall for your organization.

Two NAT limitations should be considered. NAT does not support applications that embed an IP address in the data portion of the TCP/IP packet, except for FTP. Also, multicast and broadcast packets are not translated.

NAT can be configured to run in three modes:

• Dynamic Only - this mode allows users in your network to reach out to other networks. It requires only one registered IP address. Users sharing that address are dynamically assigned a port number (from a pool of 5000) to identify their traffic. This mode does not allow outside users to initiate connections to your network.
• Static Only - this mode allows mapping of registered addresses to private addresses inside your network. This way, outside users can reach resources inside your network. Addresses are kept in a table on the router, and only addresses mapped in the table can be reached from the outside. This mode does not allow average users on your network to initiate connections with resources outside the network, only those with mapped public addresses.
• Dynamic and Static - This mode allows both kinds of connections. Hosts who do not provide resources to other networks can use the dynamic assignment of ports on the primary public address for reaching outside the network. The NAT server will also watch for traffic to secondary public addresses. Hosts providing resources to the world (such as web servers) have their private addresses mapped to these secondary public addresses in the NAT server's routing table. This use of multiple addresses bound to the same NAT interface is called multihoming.

Configuring NAT on a NetWare 5.1 server:

1. Load INETCFG on the server.
2. Enable the LAN drivers on the public and private networks and bind
   TCP/IP to each.
3. Select a NAT mode to enable public network access from your private
   network.
   1. In INETCFG, select Bindings.
      
   2. Select the TCP/IP binding for your public network board.
      
   3. Select Expert TCP/IP Bind Options.
      
   4. Select Network Address Translation.
      
   5. Change the status to the desired NAT mode: dynamic, static, or both.
   6. Escape, save changes, and reboot.
   7. Configure client workstations with the new default gateway

Troubleshooting NAT

• Can you ping the private interface in the NAT router from a workstation? If not, check hardware and cables, IP stacks on the workstation, and default router on the workstation.
• Can you ping the NAT public interface from a workstation? If not, make sure the NAT router is the default gateway, and that IP routing is enabled.
• Can you ping remote servers from a workstation? If not, make sure the NAT router knows where the other network is, or that it knows a way out of your network.

Configure a DNS Server

In order for your computer to connect to another computer on the Internet, your computer has to know the IP address to send information to. No one could possibly remember all the addresses that they connect to on an IP network, much less on the Internet, so DNS is needed.

DNS stands for Domain Name Service. DNS is a distributed database system, which means that many servers each hold part of the DNS system. What the system does is provide translation from Domain Names (names of web sites, for instance) to IP addresses. If I tell you to check out the information at server 192.233.80.5 this week, will you remember that address? Thanks to DNS, you don't have to remember the numbers. Its URL (Uniform Resource Locator) name is www.novell.com. You can enter either the address or the name in the address line of a browser. Either will take you to the same web site.

Back to the distributed idea. The Internet is divided into Domains. Baker College, for example, has been assigned a subdomain (called Baker) in the EDU domain, which is for schools. EDU is a top-level domain. A domain name is limited to 255 characters, and each label in it (the parts separated by dots) is limited to 63 characters.

Your book wants you to be familiar with several top-level domains:

Most countries have two letter domain names. Some, like Germany, are not intuitive until you remember what the country is called in the language spoken there.

You need to know that DNS is divided into zones of different types. Each zone can have several DNS servers, and the servers can be of two types. Several important terms are defined here, having to do with traditional DNS service:

• master name server (primary name server) - the authoritative repository of DNS information
• Berkeley Internet Name Domain (BIND) - a file format for holding DNS information
• replica name server (secondary name server) - a local or backup server for the master name server
• zone transfer - a request from a replica name server to the master name server to get updated information

A private network can apply for permission to connect to the Internet (for example, to place your business web server on it). You should make application to the appropriate authority designated by IANA (Internet Assigned Number Authority). Note that the text refers you to make application to Network Solutions, InterNIC Registration Services. Their web site is at www.internic.net (Test question warning: not .com!)

NetWare uses NDS to store DNS information on DNS servers. There are still two types: primary and secondary DNS servers. There are three kinds of DNS zones in NDS, and all must be configured as a primary or secondary zone:

• Standard DNS Zone - for name to address conversion
• IN-ADDR.ARPA Zone - for address to name conversion
• IP6.INT Zone - for conversion to IP version 6

Another type of server is the designated server. This is simply the master name server, if it is servicing a primary zone, or the secondary server if it is servicing a secondary zone.

Main tasks of a Primary Zone server:

• Querying NDS to resolve names - turning names into addresses
• Adding and deleting Resource Records - these are the records that make the DNS database work
• Updating the zone serial number - the serial number is like a version number. Each change in the database increments the serial number, so secondary servers know to request a zone transfer. A zone transfer is when a secondary server requests a copy of the primary name server's information.

Secondary Zone server. If your company connects to an Internet Service Provider (ISP), you may set up a secondary server at your company to do zone transfers from the master name server that belongs to the ISP.

The text discusses the RootServerInfo Zone object, explaining its purpose. If DNS servers on your network do not have information about a domain name, the request is forwarded to actual root servers (authoritative domain servers). The RootServerInfo Zone object points to such servers.

Page 3-57 shows the steps to create a DNS server. In DNS/DHCP Management Console, you click the DNS tab, click Create, choose DNS server, browse to the server that will run the service, and specify its host and domain names. Note that several servers are allowed per domain, since there can be primaries and secondaries.

The same page describes configuring a DNS Zone object. This is a resource object, in that it contains resource record sets and resource records. It is compared to a Start of Authority (SOA) object in a standard DNS system, meaning that it represents the highest level of information in a domain. Note that you can create three kinds of zone objects:

• Standard DNS zone - resolves names to addresses
• IN-ADDR.ARPA zone - resolves addresses to names
• IP6.INT zone - resolves IP version 6 addresses. The IP addresses you are used to are IP version 4, which are composed of 4 numbers (32 bits) like 204.24.176.78, each of which is saved in one byte. An IP version 6 address will contain 16 bytes (128 bits).

A server must be assigned to the DNS Zone object. If you have already created an NDS object for it, you can pick the server from a drop-down list. If not, specify its host name and its domain.

Resource records and resource record sets are finally explained at the end of this section. A resource record is an object that contains the data for a DNS resource. A resource record set is simply a group of similar resource record objects. Common types of resource records are listed:

• A - this type of record maps machine names to IP addresses.
• CNAME  - maps alias names to DNS names. (CNAME stands for canonical name.)
• MX - Mail eXchange records. They map SMTP mail addresses to domain names.
• NS - Name Server records. They map domain names to hostnames.
• PTR - Pointer records. They map IP addresses to machine names within an IN-ADDR.ARPA zone.

The name of the NLM that starts the DNS server is NAMED.NLM. This makes no mnemonic sense, so memorize it.

The book explains that you can configure a workstation to use your DNS server through its TCP/IP protocol properties settings. You specify a name for your workstation, specify that it belongs to your domain, and list the IP address of your DNS server.

Configure Dynamic DNS

Dynamic DNS (DDNS) is recommended if you are providing both DNS and DHCP services on your network. DDNS provides communication between DNS and DHCP, so that your DNS service knows about IP assignments made by your DHCP service. The text argues that host names and IP addresses are really the same information, so linking the two services makes sense. In DNS, this is represented by A records and PTR records, which are simply inverses of each other.

The key to setting up DDNS in NetWare is the Subnet Address Range object. It has a setting called Always Update, under DNS Update. Turn this on, and specify a Zone object for it to update. When addresses are leased from the DHCP server, it will update the DDNS server.

Configure SLP

The last objective in this chapter concerns SLP, Service Location Protocol, which replaces SAP, Service Advertising Protocol.

SAP was the protocol used in IPX networks to make sure that clients and servers knew about each other. Novell felt that SAP used too much bandwidth on a network to work well in the IP environment, so SLP was chosen to replace it.

To understand the following you will need to understand four kinds of network transmissions:

Transmission Type	Characteristics
Broadcast	Sent to all hosts on a network
Unicast	Sent to one host on a network
Multicast	Sent to a group of hosts on a network. For SLP the multicast address is 224.0.1.22. (No, it does not matter what your network address is. This is a class D address. See Net Tech.)
Anycast	Sent to a group, but it is only received and acted upon by the nearest active host of the group

SLP uses three kinds of software agents:

• User Agent (UA) - this agent runs on every client and server. It sends queries to the other two kinds of agents to learn about available services on the network.
• Service Agent (SA) - every server runs an SA. The SA maintains a list of currently available services on that server. The SA watches for queries from UAs and responds to them. This is more efficient than SAP because UAs generally send multicast requests, not broadcast requests.
• Directory Agent (DA) - DAs are created in large networks to maintain listings of available services in multiple SAs. DAs can receive unicast traffic, reducing the bandwidth usage found in multicast traffic.

Small network scenario: UAs send multicast requests for services. SAs on servers that have the requested service available send unicast responses to the UAs. Several servers may respond. The more hosts sending multicast request, the more bandwidth will be consumed.

Large network scenario: UAs are configured to send unicast requests to a DA. The DA checks the information from SAs that have registered with it, and sends a unicast response to the UA. Note that the use of unicast transmissions and the collection of information in the DA cause this scenario to be much more efficient for large networks.

A number of SLP objects are created on servers if SLP is run on them.

SLP Object	Notes
BINDERY.NOVELL	Holds the server's name and network address.
NDAP.NOVELL	Holds information about the NDS partition. This can only be created on a server that holds a partition replica, and only one of these objects is created in any partition.
RCONSOLE.NOVELL	The IP-based RCONSOLE program.
MGW.NOVELL	Novell migration agent.
CMD.NOVELL	Novell IPX compatibility mode server.
SAPSRV.NOVELL	IPX SAP information stored in SLP by IPX compatibility mode servers.
SRS.NOVELL	NDPS Service Registry Service.

The text also refers to the above objects as SLP services.

Clients will connect to servers providing services. They will learn of the services through SLP and will request connection based on the name of the server. Some server on the system will have to provide name service to the client, translating the name of the requested server to an IP address. A client can obtain name service five ways:

• NDS - NDS can resolve common names if the objects are in the current context, and can resolve distinguished names anywhere in the Tree
• DNS - DNS can resolve fully qualified domain names (host.subdomain.domain), and can resolve simple host names if they are in the current DNS zone.
• SLP - provides dynamic discovery of new services (and services no longer available).
• NWHOST - this is a text file that may be placed on each workstation under c:\novell\client32. The book also calls the file NWHOSTS
• DHCP - this service can tell a client what server and Tree to use, so it fits this list.

The book uses logging in as an illustration of SLP service. When you start a workstation on a network, you cannot perform a login until you connect with a server. Under SLP rules, your workstation will first look for an NWHOST file that would list a server. If none is found, the workstation's UA sends a multicast request for login service. SAs respond, and the UA chooses one based on a priority system:

• Servers on the same IP subnet are preferred first.
• If no server on the same subnet replied, servers on the same IP network are preferred
• If no server on the same IP network replied, any server that replied will be used.

If a system uses DAs, then unicast requests flow through them instead of multicasting to SAs.

In a SAP environment, services are registered via SAP broadcasts. SAP providers rebroadcast their services once a minute. SAP clients assume that information they have about service providers is no good after one minute.

In an SLP environment, services are registered and unregistered dynamically, so the listings can be relied upon longer. SLP services are assigned a value called Time To Live (TTL). This amount of time can vary, but the default is one hour. Typically, SAs register services with DAs, unregister when shutting down, and renew registration at TTL intervals.

SLP services can be grouped by scopes. A scope is like a container: it allows you to organize what clients will be able to get services from what servers. There is a default scope created called UNSCOPED, and all services are registered with it unless some other scope has been created and is specified for a service. DAs and SAs can be assigned to multiple scopes.

A question that should be on your mind at this point is "how large does a network have to be to need DAs?" There are two diagnostic questions to ask yourself. If you answer either question with a "yes", you should use DAs:

• Do you have more than 25 NetWare 5.x servers? If you do, use DAs.
• Do you have a WAN link? If you do, use DAs.

Specific strategies: consider the answers to both questions.

• If you answer "no" to both questions, you have a small network. Use SAs on each server.
• If you have more than 25 servers, but no WAN, you have a medium network. Use SAs on all servers, and one or more DAs on selected servers.
• If you answer "yes" to both questions, you have a large network. Use SAs on all servers, DAs on several servers, and group the SAs and DAs with scopes. Use the scopes to limit SLP traffic to each side of the WAN.

If you have users on both sides of a WAN link who need services from each location, you can try three options:

• When a DA is created an Organizational Unit is created in the container that holds the DA's server object. An SLP scope object is placed in the container. You can create a new NDS partition, starting at this container, and replicate the partition on the other side of the WAN link. This will give your users access to all the resources listed in the scope.
• DAs are configured with settings in a file called SLPDA.CFG (each DA has one). You can configure DAs to share information with other DAs. Doing this will cause a bit more WAN traffic than the previous option.
• You can configure UAs at each site to seek services from DAs on each side of the WAN. This will cause the most WAN traffic, because the UAs will send unicast messages across the WAN.

To use a server as a DA, you must load SLPDA.NLM on that server. When you do so, you create four NDS objects:

• SLP_SCOPE Organizational Unit Object - created in the same context as the server object for this server. The objects below are created in this OU.
• SLP Directory Agent Object - use this object to associate the DA with the server and selected scopes.
• SLP Scope Unit Object - This is a container that you use to define the scope of the DA. It is called UNSCOPED, by default.
• SLP Service Objects - these objects stand for the services offered through this DA. They may be services on this server, or on servers that are registered with the DA. Service objects have a new naming convention: service:service_type.[name_authority]://address_spec
  The word "service" is required.
  "service_type" describes the service, such as bindery or ndap.
  "name_authority" tells where it came from. All examples in this class say novell.
  "://address_spec" will the the name or IP address of the server providing the service.

By default, a server's DS object will be called servername_SLPDA. The main SLP organizational unit will be called SLP_SCOPE. The actual scope object will be called UNSCOPED, and the DA will configured to it. These objects can be managed with NetWare Administrator or ConsoleOne.

Several settings are given in the text for the various NDS objects listed above. Brief explanations are given. You should go over these settings to be familiar with them. A list of SET parameters that can be entered on the server console are given as well. Below are some examples:

SLP SA DEFAULT LIFETIME	Sets the Time to Live value in seconds. Default value is 3600. Values can range from 0 to 65535.
SLP BROADCAST	Can be set ON or OFF. Default is OFF, which means multicasts will be used.
SLP TCP	Can be set ON or OFF. Default is OFF, which means that UDP packets will be used. UDP packets are quicker, TCP packets are more reliable.
SLP DA DISCOVERY=x	0=Disable all DA discovery 1=Use Dynamic discovery 2=Use DHCP discovery 3=Use options 1 and 2 together 4=Use static discovery (reads the SLP.CFG file) 5=Use options 1 and 4 together 6=Use Options 2 and 4 together 7=Use Options 1, 2, and 4 together

Similar to the last setting above, you can configure the SLP client to use either static or DHCP discovery of resources. To do so:

1. Open the Network Neighborhood on a workstation.
2. Access the NetWare Client.
3. Choose Properties
4. Choose Service Location.
5. On this page, you can specify Scope and DA information.
   1. If you list one or more scopes, you will have access only to SAs and DAs that use those scopes. If you list no scopes, you will have access only to SAa and DAa that also are not configured for scopes.
   2. If you check the Static box under Scope, the UA will only use the scope names that appear in the Scope List. If it is not marked, the UA will use the statically configured scopes along with any scopes it discovers dynamically.
   3. If you want to eliminate the multicast traffic caused by active discovery, enter the IP address or DNS name of the servers hosting the DA or DAs you want the client UA to use. Then mark Static and unmark Active Discovery.