Your ability to support IP-Only and/or IPX-Only connectivity within your WAN relies entirely on how the clients and servers are configured during installation. In NetWare 6, you have three different protocol configuration options:

   IP-Only—Server A in Figure 6.1

FIGURE 6.1 NetWare 6 protocol configurations.

   IPX-Only—Server C in Figure 6.1

   IP and IPX together—Servers B, D, and E in Figure 6.1

The protocol configuration you choose determines the binding between protocol stacks and network adapters.

As mentioned, Figure 6.1 has three network configurations (IP, IPX, and Compatibility Mode) servicing four server configurations (IP-Only, IPX-Only, Dual Stack, and Compatibility Mode).

Now let’s take a closer look at each of these protocol configurations because you’ll probably come across each of them during your migration from an IPX to an IP network.

The strategy that you choose to migrate your existing network to IP-Only depends on a number of important criteria, such as the migration path that you’re using (IPX to IP, for example), the size of your network, your company’s Internet access requirements, and your users’ IPX compatibility needs.

Some small networks (with minimal legacy considerations) might consider an immediate rollover to the IP protocol. This is possible with a little planning and a good understanding of how to build an IP infrastructure. However, most large installations will require some time for the transition to an IP-Only network. NetWare 6 provides the tools that you can use to first clear the wire (that is, create IP-Only network traffic) and then clean the applications (replacing legacy IPX applications with versions that support IP).

The gradual phased transition from IPX to IP is made possible because of NetWare 6’s Compatibility Mode and migration agent features. In this section, we explore three basic approaches to a phased migration to IP (see Figure 6.2):

FIGURE 6.2 Three IP migration scenarios.

Let’s take a closer look at each of these three IP migration scenarios.

As you just learned, it’s crucial to maintain IP and IPX compatibility during migration to IP. Novell created the Compatibility Mode feature to facilitate migration to IP and maintain backward compatibility for IPX-based applications. This technology provides on-demand support for existing IPX applications, while maintaining full support for IP-based and NCP-based applications. Some IPX-dependent applications make legitimate NCP calls, whereas others use what are commonly called dirty hooks, or the practice of directly accessing the IPX stack itself without using NCP calls. Compatibility Mode also provides backbone support, which in turn facilitates connecting two disconnected IPX networks across an IP-Only backbone.

Compatibility Mode technology consists of two components working together: Compatibility Mode Server (the CMD NLM running on the server as SCMD.NLM) and Compatibility Mode Client (the CMD service running on the client). Furthermore, the CMD NLM can be run in one of three modes: CMD (providing backward compatibility for legacy IPX applications), Migration Agent (enabling IP and IPX segments or networks to be connected), and Backbone Support (enabling IPX segments to connect over an IP backbone).

In this section, we’ll discuss the following Compatibility Mode topics in greater depth:

Now let’s take a closer look at how we configure Compatibility Mode servers, clients, and migration agents.

Migration agents are Compatibility Mode servers that act as gateways between IP-Only segments and IPX segments. As you learned previously, a CMD server can become a migration agent simply by loading the SCMD module with the following switch (see Figure 6.1):

This option enables the migration agent capabilities of your Compatibility Mode server. But that’s not all. In addition to the /MA option, you’ll need to make sure that both IP and IPX are bound to the internal server NIC during installation (refer to Chapter 1, “NetWare 6 Installation,” for more information).

After you’ve activated the migration agent, you can test it by typing DISPLAY SERVERS on both your IP and IPX servers. On the IP servers, you should see a list of IPX-based services. Similarly, on your IPX servers, you should see a list of available CMD servers.

The DNS hierarchy organizes IP hosts into a logical upside-down tree— much like the file system directory structure (as shown in Figure 6.3). In Figure 6.3, the first three levels of the tree represent domains. The end leaves of the tree are individual host machines on the Internet. When you build an IP network, each resource must maintain a unique hostname. In theory, the DNS hierarchy follows the same architectural rules as another Novell logical tree: eDirectory. However, be careful not to confuse the functionality of these two trees. DNS is a distributed database for IP addressing of physical Internet resources, whereas eDirectory is an intranetwork solution for logically identifying distributed network resources.

FIGURE 6.3 The upside-down DNS tree.

DNS naming operates similarly to fully distinguished naming in the eDirectory. In the IP world, an absolute (or fully qualified) DNS domain name is constructed by listing all domains on the path from the end device to the Root. Just like eDirectory, a period is used to delimit the labels in the domain name. For example, in Figure 6.3, the absolute domain name for the host SRV1 in NORAD is represented as: SRV1.NORAD.ACME.COM.

In this case, the interior nodes of the DNS tree (such as .COM and .ACME) do not represent network devices. Instead, they represent logical divisions of the DNS name space—analogous to logical containers in the Novell eDirectory tree.

As you can see in Figure 6.3, many of the top-level domains have already been established by the Internet governing body, InterNIC. These predefined domains help organize the vast Internet into functional zones, as shown in Table 6.1. Note: This is only a partial list.

TABLE 6.1 Predefined Domains at the Top of the DNS Tree

The DNS hierarchy can be further subdivided into partitions called zones. Zones begin at a specific domain and extend downward until they reach either a terminating host object or another zone. For example, the shaded area in Figure 6.4 represents the ACME.COM. zone. Furthermore, any private network (such as ACME.COM.) can implement its own domain names within the specific zone. Keep in mind that your zone must be sanctioned by the NIC to connect it to a public network such as the Internet.

FIGURE 6.4 The ACME.COM. DNS zone.

This completes our discussion of the logical DNS hierarchy. As you can see, the virtual DNS tree resembles our own logical eDirectory cloud, but with a strange twist: The DNS tree is upside-down! From an organizational naming perspective, it seems pretty straightforward. Now let’s learn how DNS servers and clients resolve each other’s identities using name services.

The second half of the DNS one-two punch is DNS Name Services. This is where the actual work is done. DNS Name Services actually maps user-friendly hostnames to IP addresses, and this helps computers throughout the Internet locate each other. As we mentioned earlier, DNS Name Services relies on a client/server architecture. In this model, clients (resolvers) query one or more servers for host address information. If the DNS server doesn’t have the information a client needs, it relays the request to another name server up or down the DNS hierarchy. As soon as it finds the answer it needs, the original DNS server relays it to the requesting client (resolver).

The names and IP addresses for all hosts in a DNS zone are maintained on a single server called the primary server. The information contained on the primary server is called the authoritative database for that zone. This database contains the following information:

In Figure 6.5, we’ve set up the SRV1.NORAD.ACME.COM. server as the primary DNS server for the NORAD.ACME.COM. zone. All updates to the DNS database for the zone are made on this server.

FIGURE 6.5 Using primary and secondary DNS servers.

Furthermore, DNS supports a backup naming server called a secondary server. Secondary DNS servers provide redundancy and load balancing for DNS naming within a zone. This backup periodically downloads a copy of the authoritative database from the primary server. It’s important to note that updates to the zone database are only made at the primary server and then distributed to the secondary server when it requests a copy. This process is known as zone transfer.

In Figure 6.5, we’ve configured SRV2.ACME.COM. as the secondary DNS server for the NORAD.ACME.COM. zone. As I’m sure you’ve noted, the secondary DNS server is located outside of its home zone. Although it’s a good idea to keep primary DNS servers inside the zone, you should distribute secondary DNS servers in geographically remote locations for fault tolerance purposes.

The process of DNS name resolution is actually quite similar to the way you might find a telephone number for someone who lives in a remote city. Let’s say, for example, you lived in NORAD and wanted to call someone in Tokyo. First, you would call your local operator to obtain the country code and the number for directory information in Japan. Then you would call directory information in Japan and get the local number for Tokyo. Then you would call Tokyo and query your friend by name. Let’s say you reside in the LABS division of NORAD within ACME. From your DNS client, you want to access a device in the QLABS.COM. zone. Here’s how your local DNS server would resolve the destination IP address (follow along in Figure 6.6):

FIGURE 6.6 Resolving IP addresses using DNS.

As you can see, DNS is a powerful tool for helping users resolve complex IP addresses. Furthermore, the NetWare 6 DNS/DHCP implementation stores zone data within eDirectory and replicates it like other eDirectory data. Because of this, all NetWare servers can access DNS data from the eDirectory tree. This provides fault tolerance and load balancing for DNS data, and enables you to make changes to DNS zones from anywhere on the network.

Now let’s expand our DNS/DHCP journey into the realm of DHCP—the Dynamic Host Configuration Protocol.

As soon as you extend the eDirectory schema, three global DNS/DHCP objects are created automatically. It’s important to note that only one group object and one locator can exist in any given eDirectory tree. Subsequently, the DNS servers, DHCP servers, and DNS/DHCP console tools must have access to these objects. The following is a brief description of the three global DNS objects created automatically during eDirectory schema extension:

That completes our exploration of the three automatically created DNS/DHCP objects. In addition to these three, you can manually create eight other objects after you extend the schema. Let’s continue with a description of the three DNS eDirectory objects.

Three new DNS objects are available after you extend the eDirectory Schema. These objects help you centrally manage the relationship between DNS host naming and IP addressing. Later in this chapter, we’ll explore these objects in detail and learn how to create and configure them. For now, here’s a brief description:

To prevent slow network performance because of traffic over WAN links, be sure to place DNS objects in the same partition as the DNS server. Table 6.2 shows some options for DNS server and object placement.

TABLE 6.2 DNS Server and Object Placement

Now let’s complete our DNS/DHCP object lesson with the final five DHCP objects.

Five new DHCP objects are available after you extend the eDirectory Schema. These objects help you to centrally manage IP address assignments and subnet attributes. Later in this chapter, we’ll explore these objects in detail and learn how to create and configure them. For now, here’s a brief description:

Determine DHCP object placement along with DHCP server placement. To avoid traffic over WAN links, choose a primary server at each location. Table 6.3 shows some options for DHCP server and object placement.

TABLE 6.3 DHCP Server and Object Placement

That completes our conceptual journey through the virtual world of NetWare 6 DNS/DHCP Services. In this lesson, you’ve learned how DNS servers translate complex numerical addresses into humane hostnames and how DHCP assigns IP information to IP clients. Don’t underestimate the administrative power of these two Internet protocols.

Is that enough conceptual overview? Are you ready to get to work? I hope so. Theory is important, but now it’s time for action. Next, we’ll tackle DNS/DHCP configuration.

After you’ve mastered the DNS/DHCP architecture and extended the eDirectory schema, it’s time to build customized functionality into your new IP management objects. In this lesson, we’ll focus on IP object configuration from both the DNS and DHCP perspectives.

If you selected DNS/DHCP Services when you installed NetWare 6, the key program files for Novell DNS/DHCP Services were automatically copied to the SYS: volume on your server. These files include program NLMs (which are copied to SYS:SYSTEM) and the DNS/DHCP Management Console setup program (which is copied to SYS:PUBLICDNSDHCP).

After Novell DNS/DHCP Services has been integrated into the eDirectory tree, you’ll have two graphical tools available for managing your IP network:

Now for the fun part! In the next lesson, we’ll use iManager to configure DNS for name/address translation and DHCP for IP address allocation.

If you want a NetWare 6 server to obtain and update DNS data in the eDirectory tree, you must first create a corresponding DNS Server object. After you’ve create the server, it can be designated to service primary or secondary zones. A designated server is a NetWare 6 server that is assigned to obtain and update DNS data from a DNS Zone object. Novell DNS Services supports two different types of designated DNS servers:

To create a DNS Server object, follow these instructions (see Figure 6.9):

FIGURE 6.9 Creating a DNS server using iManager.

After you’ve created a DNS Server object, you must assign it to a primary or secondary DNS zone. At that point, the server becomes a primary or secondary designated server. To create a DNS Zone object, click the Zone Management link in the navigation frame of iManager. Next, make sure Create Zone is selected, and choose OK. After you do this, you’ll be greeted with the Create DNS Zone dialog box (shown in Figure 6.10):

FIGURE 6.10 Creating a DNS zone using iManager.

RRs are eDirectory leaf objects that contain the IP-based host information maintained by DNS name servers. In short, these are the DNS database. Each DNS zone must contain several types of resource records for DNS to function properly. The most common resource record types are

To create a DNS Resource Record object, click on the Resource Record Management link in the navigation frame of iManager. Then make sure that the Create Resource Record box is marked, and click OK. At this point, you’ll be greeted with the Create Resource Record dialog box:

After you’ve created a Resource Record object, it will be placed in a corresponding RRSet container. The RRSet object is created automatically for each unique DNS zone. The resource record is designated Read Only, which means that you must delete the object and re-create it to make any modifications.

After you’ve created the DNS server and associated it with a new DNS zone, you must activate the DNS server. This is accomplished by typing the following command at the NetWare 6 server console:

The following parameters are supported by this command:

If you make any changes to your DNS Server object while NAMED.NLM is loaded, you’ll need to unload and reload the module for your changes to take effect. Finally, you should consider placing the NAMED statement in your DNS server’s AUTOEXEC.NCF file so that it loads automatically when the server is started.

When the DNS server is running, you must configure the workstations to use DNS for automatic name resolution. This is accomplished by customizing the TCP/IP Protocol property within Network Neighborhood on Windows 95/98 and Windows NT/2000/XP clients:

1.   Right-click the Network Neighborhood icon on a Windows 95/98 or Windows NT/2000/XP desktop. Next, select Properties from the pop-up menu that appears.

2.   The Network window should appear with the Configuration tab activated. If this is a Windows 95/98 workstation, highlight the TCP/IP Protocol and click Properties. If this is a Windows NT/2000/XP workstation, right-click the Local Area Connection and select Properties. Then select the TCP/IP protocol and select Properties.

3.   The TCP/IP Properties window will appear with seven tabs. When you click the DNS Configuration tab, you’ll be greeted with two radio buttons: Disable DNS and Enable DNS (shown in Figure 6.11).

FIGURE 6.11 The DNS Configuration tab in Windows Network Neighborhood.

4.   To configure Windows-based DNS, first click the Enable DNS radio button. Next, provide a host and domain name for this client and build a DNS server search order. Finally, in the DNS Server Search Order field, enter the IP address of your DNS server and then click Add.

5.   To close the Network Neighborhood window and save your new settings, simply click OK a few times and reboot the workstation.

All finished! Your NetWare 6 Novell clients are all ready to accept name resolution information from your new DNS server and, more importantly, your life as an IP administrator is getting much easier. Now let’s shift gears and install DHCP services for NetWare 6.

To create a DHCP Server object, follow these instructions (follow along with Figure 6.13):

FIGURE 6.13 Creating a DHCP Server using iManager.

When your DHCP Server object is alive, you must configure IP addresses for automatic, dynamic, and manual distribution. Let’s start with a Subnet container in which we can store our SAR and IP Address objects.

The DHCP Subnet object is a container that holds all the SAR and IP Address objects for a physical network segment. To create a DHCP Subnet object, click on the Subnet Management link in the navigation frame of iManager. Then check the Create Subnet box and click OK. Finally, you’re greeted with the Create Subnet dialog box (shown in Figure 6.14):

FIGURE 6.14 Creating a DHCP Subnet object using iManager.

In addition, Novell supports the configuration of multiple IP subnet addresses for a single physical network segment. This is accomplished by using the DHCP Subnet Pool object. First create multiple Subnet objects within a single eDirectory context. Then use iManager to create a Subnet Pool object and add multiple Subnet objects to the pool.

After you’ve created the DHCP server and subnet, you must prepare the IP addresses for assignment. This can be accomplished using either of the following two DHCP objects:

After you create the DHCP server and configure its IP information via Subnet, SAR, and IP Address objects, you must activate the DHCP server. This is accomplished by typing the following command at the NetWare 6 server console prompt:

When DHCPSRVR.NLM is loaded, it reads IP address configuration data from eDirectory and loads the information into the server’s cache. Also, you should consider placing the DHCPSRVR statement in your DHCP server’s AUTOEXEC.NCF file so that it loads automatically when the server is started. Now the server is ready to hand out IP addresses to DNS/DHCP clients. The clients will not be ready to request the IP address information, however, until they have been properly configured.

When the DHCP server is running, you must configure the DHCP workstations to automatically accept IP configuration information. This is accomplished by customizing the TCP/IP Protocol property within Network Neighborhood on Windows 95/98 clients:

1.   Right-click the Network Neighborhood icon on a Windows 95/98 desktop. Then click Properties in the pop-up menu that appears.

2.   The Network window should appear, with the Configuration tab activated. Highlight the TCP/IP protocol and click Properties.

3.   A TCP/IP Properties window will appear with seven tabs (shown in Figure 6.15). When you click the IP Address tab, you’ll be greeted with two radio buttons that enable you to specify whether the client will obtain an IP address automatically or specify an IP address

FIGURE 6.15 The TCP/IP Properties screen in Windows Network Neighborhood.

4.   To configure a Windows 95/98 workstation for automatic address assignment, mark the Obtain an IP Address Automatically radio button. If the workstation previously had an IP address that was configured manually, you’ll be asked whether you want to enable DHCP at this point. If so, click Yes.

5.   To close the Network Neighborhood window and save your new settings, simply click OK a few times and reboot the workstation. All finished! Now your NetWare 6 Novell clients are ready to surf the Web and, more importantly, your DHCP server will be handing out IP addresses automatically.

We’re almost finished, but no plan would be complete without some polish. Let’s take a look at a feature that could make your life as a network administrator so much easier: Dynamic DNS (DDNS).

Perform the following tasks at the WHITE-SRV1 server console:

Perform the following tasks at your administrative workstation:

Perform the following tasks at your administrative workstation:

Perform the following tasks at your administrative workstation:

When an IP packet arrives into the NAT router from a host on a private network, it replaces the private IP address with a public IP address. The NAT router then forwards the packet to the public network. This also works in reverse. That is, packets coming into the NAT router from the public network have the public address replaced with a private IP address, and the packet is forwarded to the private network.

Because of its address translation role, NAT must reside between the public and private network boards. Each of these boards must have a private IP address assigned to it. Any addresses assigned to the public board must be your registered, public addresses.

NAT uses port numbers to track each private network host for which it has translated an IP packet. NAT tracks each private network host so that public hosts can respond to packets from private hosts. When the public host’s response goes back to the private host, the public host is aware of only the public IP address that NAT put into the packet.

NAT can be configured to operate in one of three modes:

To configure NAT on a NetWare 6 server, you must use the INETCFG console utility. First, enable the LAN drivers on the public and private networks and bind the TCP/IP protocol to each. Next, select a NAT mode on the NetWare 6 server that is acting as a NAT router. In INETCFG, select Bindings and choose the LAN driver binding of your public network board. Next, select Configure TCP/IP Bind Options. Then, select Expert TCP/IP Bind Options and choose Network Address Translation. Finally, change the status to the desired NAT mode and reinitialize the system for the changes to take effect.

To troubleshoot NAT, check the following configurations:

Next, we’ll extend the new IP network into the realm of service advertisement. Hold on tight—SLPv2 will knock your socks off.

At its most fundamental level, SLP is an electronic GPS for network services. So, how does it work? Services on the network register themselves with an SLP agent running on a NetWare server. When a client needs to locate a particular service on the network, it queries the SLP agent, which, in turn, provides the client with the address of the service. Furthermore, in NetWare 6, SLP works with eDirectory to help bring together the IP infrastructure services, such as eDirectory trees, DNS servers, NetWare servers, and various network protocol gateways. This enables clients to discover services by querying a central database rather than the whole network.

In this SLP overview, we begin by exploring the family of name service providers supported by NetWare 6. Then we focus on SLP as the preferred provider and dive into more detail regarding its architecture. Finally, we discover directory agents, user agents, and server agents, and learn how they communicate with each other to provide network services to NetWare 6 clients.

NetWare 6 Name Service Providers

SLP isn’t the only name service provider supported by NetWare 6. In fact, five different providers deliver name resolution services to Novell clients. The following is a brief description of SLP’s name service provider family:

   eDirectory—This is the patriarch of name resolution. As the central database of all network services, eDirectory provides a list of corresponding servers that host network-wide applications, protocols, and services. In addition, eDirectory can resolve fully qualified server names if the server resides in the eDirectory tree. Unfortunately, eDirectory cannot behave as an independent service provider. In fact, eDirectory itself is a service; it must be discovered by another name service provider before it can be used to resolve network names.

   Domain Name System (DNS)—As you learned earlier in this chapter, DNS resolves fully qualified eDirectory server names to their corresponding IP addresses. Unlike eDirectory, DNS can act independently of any other name service provider—provided that the client is configured with the IP address of the DNS server. Unfortunately, DNS cannot dynamically discover services that are started or stopped on the network. You must manually add and remove service names to IP address mappings as services are added or removed. This shortcoming makes DNS a bad choice as the primary name service provider.

   NWHOST—NWHOST is the NetWare host file that lists service names and associated IP addresses. It is elegant in its simplicity. Unfortunately, host file service providing is not a viable strategy for medium- or large-size networks. Imagine how unwieldy the NWHOST file would become on a Novell network with 10,000 clients.

   Dynamic Host Configuration Protocol (DHCP)—DHCP is a very simple name service provider that allows preconfigured clients to initially establish connections and set various client parameters (such as preferred tree and preferred context). Like DNS, DHCP isn’t powerful enough to be your primary service provider.

   Service Location Protocol (SLP)—This brings us to the final and most powerful name service provider supported by NetWare 6. SLP combines the following strengths of the other four service providers: central management through eDirectory integration, fully qualified IP address mapping, and the ability to push centralized configurations to network clients. And to make things even better, SLP provides dynamic discovery of network services so that you don’t have to configure it once it is running. For all of these reasons, SLP is the preferred method of network service discovery.

NetWare 6 uses SLPv2. As you learned earlier, SLPv2 offers numerous enhancements over the SLPv1 version used in previous releases of NetWare.

Table 6.4 is a short list of the network services autodiscovered by SLPv2. In summary, SLPv2 provides two primary benefits to NetWare 6 networks: management and fault tolerance. SLPv2 centralizes network management by autoregistering changes in network architecture whenever a workstation or protocol is reconfigured. In addition, SLPv2 enhances fault tolerance because it enables clients to find services regardless of whether they’re running on primary or secondary servers.

TABLE 6.4 Services Discovered by SLPv2 in NetWare 6

SLPv2 Communications

SLP is basically a communication protocol in which DAs, UAs, and SAs communicate with each other to identify and locate available services on the network. However, the method of communication between these SLP agents differs dramatically with small or large networks. Let’s take a quick look at how SLPv2 communicates at both ends of the network spectrum.

Small Network: SLPv2 Communication Without a Directory Agent

A small network with fewer than 25 servers gains negligible advantage from an SLP DA. In this scenario, all SLP communication can be handled by the SAs and UAs with local segment IP multicast. Without a central DA, NetWare 6 services register themselves with the SA running on their host server. Therefore, the SA knows about the services and can respond to specific client’s requests.

Following is a step-by-step description of how SLPv2 communication operates in a small network (follow along in Figure 6.16):

1.   The Novell client running on a workstation makes a request through the client’s UA for eDirectory authentication.

2.   The client’s UA sends a multicast request on the network.

3.   All SAs within the UA’s network segment receive the multicast.

4.   Each SA that knows the location of the authentication service responds directly to the UA client with the IP address of the service. This communication is accomplished through a unicast because it is directed at a single client.

5.   Each SA that is unaware of the location of the authentication service ignores the multicast and goes about its business.

FIGURE 6.16 SLPv2 communications without a directory agent.

Large Networks: SLPv2 Communications with a Directory Agent

In a large network, SLP requires DAs to provide scaling and remote connectivity support. If the network is architected to be a rather flat system, a single DA might be sufficient. Unlike the smaller networks, there is little IP multicast in this architecture. Furthermore, DHCP can be used to configure each client UA with the IP address of the directory agent. This way DA information can be stored in eDirectory and replicated throughout the global network.

Following is the flow of SLPv2 communications with a directory agent (follow along with Figure 6.17):

1.   A Novell client requests eDirectory authentication services through the workstation’s UA.

2.   The UA sends a unicast request directly to the DA that has been configured in its SLP settings.

3.   Because all SAs send service location information to the DA, the DA responds to the UA with the IP address of the authentication service through a unicast.

FIGURE 6.17 SLPv2 communications with a directory agent.

In this section, we discovered a lot about name service providers, SLPv2 architecture, and communications with and without directory agents. Now we’ll venture off the easy path into a much more sophisticated configuration lesson. Next, you’ll learn how to configure SLPv2 DAs, SAs, and UAs with NetWare 6’s new and exciting Web management tool—iManager. And while you’re at it, don’t forget our new NetWare 6 motto: “iManage, therefore I am.”

Although SLPv2 employs a sophisticated and complex architecture, its configuration in NetWare 6 is quite simple. Before we get into the nuts and bolts of actually configuring SLPv2, however, let’s look at some design considerations.

SLP Client Configuration

The goal of SLP client configuration is to point each of your client’s UAs to the appropriate DA for service requests. This step is trivial (and unnecessary) if you have only one DA on the network because all clients point at the default DA. However, if you have enabled multiple DAs on the network, you must tell each client where to go for network services.

You can configure Novell clients for SLP in one of two ways:

   SLP static client configuration—Within the Novell Client Properties dialog box of Windows 95/98/2000/XP

   SLP dynamic client configuration—By using DHCP Services

SLP Static Client Configuration

The Novell Client Properties dialog box within Windows 95/98/2000/XP includes a Service Location tab for manually configuring SLP client data. Follow along with Figure 6.18 as we manually configure these three options:

   Scope List—Scopes in this field force the UA to communicate only with DAs and SAs within the same scope.

   Static—If you check the Static box within the Scope List frame (shown in Figure 6.18), the UA only uses scope names in the scope list. If this box isn’t marked, the UA uses statically configured scopes and any scopes it discovers on its own.

   Directory Agent List—This option enables you to precisely identify the Directory Agent IP address or DNS name you want the client UA to use.

FIGURE 6.18 SLP static client configuration with Novell Client Properties.

SLP Dynamic Client Configuration

As you learned earlier, DHCP enables us to pass a variety of TCP/IP client configuration data to each network workstation. In this case, we can use it to deliver SLP parameters. Follow along with Figure 6.19 as we use DHCP to dynamically pass SLP configurations to Novell clients:

1.   Activate the DNS/DHCP Management Console from your administrative workstation and select the DHCP Services tab.

2.   Next, select a Subnet object and choose the Other DHCP Options tab.

3.   Create a DA option containing the IP address of this client’s DA and the name of its Scope object. Click OK to save the changes and to exit DNS/DHCP Management Console.

4.   Unload and reload DHCPSRVR.NLM at the server console to enable the new changes.

FIGURE 6.19 SLP dynamic client configuration with DHCP.

After you’ve completed the SLP client configuration, there’s only one component left: the SLP server.