Novell is now a part of Micro Focus

Understanding and Configuring SLP Directory Agents and Scopes

Articles and Tips: article

Charles Flood, Jr.
Support Engineer
Novell Worldwide Technical Support
cflood@novell.com

01 Apr 2000


NetWare 5's support for Pure IP introduced the use of Service Location Protocol (SLP) to dynamically discover services that are available on the network. This protocol specifies the use of various agents, including User Agents (UAs) for clients and Service Agents (SAs) for servers. A Directory Agent (DA) is an optional agent that acts as a repository for SLP service information that the SAs register and that the UAs query. On large networks, SLP services can be organized into searchable groups known as scopes. When clients send SLP requests to a DA, they can specify a scope for the DA to use to find the service they are looking for.

In implementing NetWare 5 in a Pure IP environment, customers have raised many questions regarding the setup of DAs and the use of scopes. This AppNote summarizes the theory behind how these technologies work, and then describes various SLP DA and scope implementation scenarios. The intent is to provide enough background information to help the typical customer properly implement DAs in any size environment.

Many of the mechanics on how to configure basic SLP components have been discussed in previous AppNotes. For more information, see:

  • "Migrating to Pure IP with NetWare 5" in the September 1998 issue of Novell AppNotes

  • "Dynamically Discovering Services on an IP Network with SLP" in the March 1999 issue of Novell AppNotes

For additional support information about NetWare 5, visit Novell's technical support Web site at:

http://support.novell.com

Overview of SLP, Directory Agents, and Scopes

SLP stands for Service Location Protocol. SLP version 1 (based on RFC 2165) was implemented for NetWare 5.0 and 5.1. SLP is used by a client or server on a network to find the IP address of another client or server on the network with which it needs to communicate.

One example of this is a client logging in to the network. In an IP network, the client needs to know the IP address of a server to which it can connect and perform Novell Directory Services (NDS) authentication. SLP is one of the ways that can be used to provide this IP address to the client.

Note: Besides SLP, a host (client) can use several other methods to find services on the network. These include a hosts file, DHCP (to assign a default NDS context, server, and tree), and DNS names.

Services in SLP 

The term "service" is used often when talking about SLP. In this context, services are applications running on a host (server or client) which other hosts on the network can access. Common examples of services include NDS, REMOTE.NLM, NDPS, and SCMD running on a NetWare 5 server. When a NetWare 5 server starts up, these services (applications) register themselves with SLP and make themselves available to the network.

From a high-level viewpoint, the information that SLP maintains about a service is simply the service name and the IP address of the host (normally a server) that is running this service.

Each service on the network has a unique URL (Uniform Resource Locator). This URL contains the details of the service such as the IP address of the server on which this service is running and the version of SLP that this server is running. The table below lists some of the common NetWare 5 URL names and what they represent.


Service URL
What It Represents

NDAP.Novell

An NDS partition in the tree

Bindery.Novell

NDS running on a particular server

SRS.Novell

Novell Distributed Print Services (NDPS))

Rconsole.Novell)

RCONSOLE running on a server

SapSrv.Novell

IPX services on a server

Displaying Available SLP Services.    To display the available services that a server can access, use the Display SLP Services command from the server console. The example below illustrates how to make a query for all Bindery.Novell services.

 

SLPDA:display slp services
 bindery.novell DISPLAY SLP SERVICES
  Usage: display slp services [
service type
/
scope
/
predicate query
]/
    Example 1: 'display slp services'
    Example 2: 'display slp services bindery.novell//(svcname-ws==abc*)/'
 Searching Network . . .
  service:bindery.novell:///SLPDA
  service:bindery.novell:///NW5DHCP
  service:bindery.novell:///NW5DNS
  service:bindery.novell:///NW5SLP
 Displayed 4 URL's.

Displaying SLP Attributes.    To see the attributes of one of these services, use the Display SLP Attributes command at the server console. For example, every NetWare 5 server registers a Bindery.Novell service. This service represents the fact that NDS is running on this server. To see the attributes of this service, enter the Display SLP Attributes command as shown below.

SLPDA:display slp attributes service:bindery.novell:///nw5slp
 DISPLAY SLP ATTRIBUTES
  Usage: display slp attributes 
url
 [
attribute select list
]
    Example 1: 'display slp attributes service:ndap.novell:///tree1.'
    Example 2: 'display slp attributes service:ndap.novell: svcname-ws,
  enabled-ws'
 Searching Network . . .

 (SCOPE=SCOPE1,SCOPE2),(svcname-ws=NW5SLP),
(svcaddr-ws=2-1-6-F000002020C0000000000000000,
2-1-6-10000002020C0000000000000000,
6-2-1000-667CDFB00000000000104510000,
2-2-17-0F000002020C0000000000000000,
2-2-17-10000002020C0000000000000000),
(svcid-ws=000B0004-0000-0000-C000-000000000046),
(version-ws=733-0),
(enabled-ws=TRUE),
(slp-version=v1.5.2)

In this example, the attributes of the Bindery.Novell service for the server NW5SLP are displayed. From this information you can extract the IP address of this server. In this example the server is configured with two IP addresses: 10000002 (hex) which is 16.0.0.2 and 0F000002 (hex) which is 15.0.0.2.

The following explains how to extract this information from the attributes of the Bindery.Novell service (this same information holds true for the Ndap.Novell service). Within the details of the bindery.novell service will be multiple entries with a format of x-x-x-xxxxxxxx. Each of these entries represents the service binding to UDP, TCP, or IPX. The first digit is the protocol family: 2 for TCP/UPD, 6 for IPX. The second digit is the socket type: 1 for socket stream (TCP), 2 for datagram (UDP and IPX). The third is the protocol: 6 for TCP, 17 for UDP, and 1000 for IPX. Last is the IP address, in hex, of the interface that is registered (or, in the case of IPX, an IPX network number).

From this we can see that 2-1-6-xxxxxxxx represents a TCP interface, 2-2-17-xxxxxxxx represents a UDP interface, and 6-2-1000-xxxxxxxx represents an IPX interface. You should find a "2-1-6-xxxxxxxx" entry and a "2-2-17- xxxxxxxx" entry for each TCP/IP address that is bound to a server.

SLP Agents 

SLP defines three agents that are used to register, maintain, and seek service information on a network:

  • Service Agent (SA). A Service Agent runs on every server that is running SLP. Applications on this server will register with the SLP SA and store this in local cache memory. The SA also listens for service requests. If a request is received that matches a service that is registered, the SA will respond to that request.

  • User Agent (UA). A User Agent makes requests for service information. A UA will most likely be a client that is looking for a service. However, a NetWare 5 server can also act as a UA. An example of a UA on a server is NDS. NDS makes requests for SLP service information when the server is brought up.

  • Directory Agent (DA). A Directory Agent stores and disseminates service information for the network. The DA uses NDS as the data store for this information. An SA registers its services with a DA and a UA will request service information from the DA. The SA registers its services for a specific period of time called the "Service Lifetime". If the SA does not re-register the service before this lifetime expires, the service is purged out.

By default, SLP uses multicasting to find an SA or a DA on a network. The multicast address that SAs listen for is 224.0.1.22; the multicast address that DAs listen for is 224.0.1.35. So, for example, when a UA is looking for a service, it will send a multicast request to the address 224.0.1.22. This multicast packet is sent to every network and router that has multicasting enabled. In this case, every SA that receives this packet will respond with service information if it has what the UA is asking for.

To discover a DA, a UA and SA will send a multicast packet to the address 224.0.1.35. Every DA that receives this packet will respond. Once the UA or SA locates a DA, it will send unicast packets directly to the DA.

Without a DA in the network, a UA and SA communicate as follows:

  1. A Service on a server (such as NDS) will register with the SA on this server.

  2. A UA (such as a client) will send a multicast request for the service type Bindery.Novell.

  3. The SA receives the SLP request and sends a unicast packet directly back to the UA, letting it know that the requested service is running on this server.

  4. The client will send a unicast request (in the form of an attribute request) to the SA for the details of the NDS service.

  5. The SA will send all the attributes (details) of the NDS service to the UA in another unicast packet.

At this point, SLP's job is complete. The UA now has the information it needs (the IP address) for the server with which to perform NDS authentication via TCP/IP.

More About SLP Directory Agents 

An SLP Directory Agent (DA) is one of the three SLP agents. It is the only agent that is not required in a network, since a UA can still find an SA via multicast if a DA is not present in the network.

When a DA is present on the network, UAs and SAs make requests for services to the DA. The DA responds with an SLP URL. Unlike SAs, which store their service information in cache, DAs store their service information in cache and in NDS. The DA uses an NDS container called a "Scope Unit" to store individual objects that represent services that have been registered with the DA. Each service registration has its own NDS object. The Scope Unit container has an attribute called the "Scope Name". This Scope Name is used in the configuration of SAs and UAs to define what scopes they can use.

With a DA on the network, UAs and SAs communicate as follows:

  1. Each SA on the network will register its services with the DA.

  2. The DA will store this information in NDS and its local cache.

  3. A UA will contact the DA and ask for service information (for example, NDS).

  4. The DA will respond with a list of service names that match the type the UA has requested.

  5. The UA will choose one of these service names and ask the DA for the details (attributes) about this service.

  6. The DA will send to the UA the attributes which were requested.

Now the UA has the IP address of a server running NDS. The client will then contact that server directly. SLP is no longer needed until another service needs to be located.

More About SLP Scopes 

In SLP, a Scope is simply a container within NDS for SLP services that have been registered with a DA. The SLP Scope Unit container object is the actual storage container for SLP service information. Each Scope Unit container holds all the SLP Service objects for a specific scope. It is possible to replicate this container into other partitions within the tree or within federated trees.

As mentioned earlier, the Scope Unit has an attribute called the Scope Name. This Scope Name is used by the SA and UA to define what scopes they are to work with.

In Figure 1, an OU called SLP_SCOPE was created to hold all the SLP objects. There are two Scope Unit objects, called ScopeA and ScopeB. The Scope Unit objects are containers and hold the actual service URL objects. The configuration details of ScopeA are displayed in the sample screen.

Figure 1: Scope Units are containers that hold SLP service objects.

The SLP Scope Unit Configuration page shows the Scope Name, the service types that are currently registered, and the SLPDA server objects that are currently using this scope. Each Scope Unit has a unique Scope Name configured as one of its attributes. The actual Scope name that is used in the configuration of all servers and clients is Scope1.

Scoped vs. Unscoped.    There are two modes for setting up scopes: Scoped and Unscoped.

  1. An "Unscoped" scope is a general default scope. It is a grouping of all service URL information that is not tied to a particular scope. In SLP version 1, the default scope is called the "Unscoped scope". In SLP version 2, it will be called the "Default Scope".

  2. A "Scoped" Scope is a Scope Unit that has been defined with a specific Scope Name.

    Note: If your network requires more than one scope and you want to set up a default scope container, create a scope called "default scope". Do not use the Unscoped scope in this configuration. This will make the transition to SLP version 2 easier.

     

Registering a Service with a Specific Scope.    To configure a server to register its services with a specific Scope, modify the SLP Scope list via the Monitor utility. After loading MONITOR.NLM, select Server Parameters | Service Location Protocol. This list defines what Scopes this server is to register its services with. If the list is empty, all services will be registered with the Unscoped Scope (used as the default Scope when no Scope name is defined). Note that it is possible to enter multiple Scope names in this list to have the servers services registered into multiple Scopes.

Configuring an SA with the SLP.CFG File 

The SLP.CFG file is used only by the SLP SA running on that server. If you have SLPDA.NLM running on that server, it does not access the SLP.CFG file. This file has two purposes:

  1. To statically define the SLPDAs that this SA should contact

  2. To define any type of service scope filtering

Configuring SLPDA Addresses.    The SLP.CFG file uses a very specific syntax to configure the DA addresses. Every NetWare 5 server comes with a sample SLP.CFG file, which is shown below.

 

; This is a sample of the slp configuration file. ; Two types of
entries can be made: 1) DA entries, 2) SA Register Filters. ; ;
The DA entry allows static configuration of a know DA. This
would be used when the ; DA was out of multicast range and
DHCP was not being used to configure the DA. ; The static DA
configuration format is as follows 'DA <addr type<, <addr<'. ;
The first word must be <DA<. The addr type is the address type.
Currently, only ; IPV4 has been defined. IPV6 will be defined in
the future. The addr is ; the address specified. ; ; The following
is an example of a static DA. ; DA IPV4, 130.1.1.1 ; ; The SA
Register Filter would be used when the administrator wanted all
services ; of a specific service type being mapped to a single
scope. For example, ; the administrator wanted all <lpr<
printers being registered to scope <printer<. ; The format is as
follows: 'REGISTER TYPE <<type name<< to SCOPE <<scope 
name<<'. ; The parser will look for REGISTER, TYPE, and
SCOPE as keywords followed by quote on ; a single line.
Example: ; ; REGISTER TYPE <lpr< to SCOPE <eng< ; ; The last
line must contain a line feed and char return. A semi-colon
specifies a comment.<

As explained in this sample SLP.CFG file, you define a DA address by entering it as follows:

DA IPV4, xx.xx.xx.xx

where xx.xx.xx.xx is the IP address of a DA.

You can use a DNS name in place of the IP address; for example:

DA IPV4, da1.novell.com

The server will need a valid RESOLV.CFG file configured in the sys:\etc directory. The DNS resolver that SLP uses is part of the server Winsock code. You must have NetWare 5 SP3 or above for this to work. The RESOLV.CFG is configured in the same manner as when using it for PING.NLM or NETDB.NLM.

To activate changes to the DA address setting in SLP.CFG, you can use one of two SET commands: SET SLP RESET = ON or SET SLP DA DISCOVERY OPTIONS = 4. Either of these commands will cause the SA on the server to contact all the configured DAs and register all services.

Defining Scope Filtering.    The other function of the SLP.CFG file is to do scope filtering. By using scope filtering, it is possible to tell the SA to configure certain services into certain scopes.

As an example, suppose you wanted the bindery.novell service for a server to register with a scope called scope2. You would enter this into the SLP.CFG file as follows:

REGISTER TYPE "bindery.novell" to SCOPE "scope2"

All other services registered by this SA will be registered in the scopes defined in the scope list under Monitor | Server Parameters | SLP.

The overall scope filtering process can be summarized as follows:

  1. If there is scope filtering defined in the SLP.CFG file, those services configured will be registered with that particular scope. All other services will be registered with the scopes defined in the server scope list. The filtered services will only be registered in the scope configured in the SLP.CFG and not in the scopes defined in the server scope list.

  2. If there is no filtering defined in the SLP.CFG file, all services from that server will be registered in all the scopes defined in the scope list. If there is no scope list defined, the SA will attempt to register the services in the Unscoped scope.

To activate changes to the Scope Filtering section of SLP.CFG or to activate changes to the Scope list configured in Monitor | System Parameters | SLP, you will need to restart the server.

Setting Up a Directory Agent

There are two ways to set up an SLP DA object: automatic and manual. While this section describes both methods, it is recommended that you use the manual method to set up SLP Directory Agents. Using the manual method with "named" scopes will make the transition to SLP v2 much easier.

Automatic DA Setup 

The automatic method of setting up a Directory Agent is very simple. When you load SLPDA.NLM for the first time on a server and SLP has not been set up, you will be prompted to create a default configuration within NDS. If you select "Yes", the SLPDA will automatically create three types of objects in NDS:

  1. The DA object. This represents the DA and includes information about what server the DA is running on. It also has some configuration options and a list of Scope Units that this DA supports. The DA object has a parameter called "start purge hour" which tells the DA when to start its daily purge. Once" every 24 hours, the DA clears its cache and reads all service objects from NDS again.

  2. The "Unscoped scope" Scope Unit object. This is a container object that contains the actual service URLs in the form of service objects. The scope name will be "Unscoped"."

  3. Service objects. These are leaf objects that contain the actual service URL information.

Manual DA Setup 

The manual way of setting up a SLP Directory Agent involves manually creating the SLPDA object and the Scope container within NWAdmin. The steps are as follows:

  1. In NWAdmin, create an OU container to hold the Scope Unit objects. This is recommended for sites with multiple DA's and where the Scopes will need to be replicated for failover support.

  2. In this new OU, create an SLP Scope Unit. Provide a name for the Scope Unit and the name of the scope itself. (The actual Scope Name is an attribute of the Scope Unit. The Scope Name is what you will configure into each server's scope list.) The default entry here is UNSCOPED.

  3. Select an OU in which to create the SLP Directory Agent. Create the SLP DA object and select additional properties. Select a Host Server for this SLP DA. This is the NCP server that will run the SLPDA.NLM. Select the SLP Scope Button and select a scope for the SLP DA to service.

  4. Load SLPDA.NLM on the server. The SLP DA will send out an SLP DA Advertisement to the SA multicast address of 224.0.1.22. Each SLP SA on the network that receives this multicast will reply by sending an SLP Service Registration unicast packet to the SLPDA. The SLPDA will then send an SLP Acknowledge unicast packet to the SA. The SLPDA will also create a Service object within the Scope for each service. You can see these Service objects in NWAdmin.

    Note: The one multicast packet sent by the SLPDA when loading is the only multicast addressed packet sent in this scenario.

     

Removing the DA Configuration 

If for some reason you would like to remove the SLP DA configuration, follow these steps:

  1. Unload SLPDA.NLM.

  2. View the details of the NCP server object that is running the SLPDA and select the SLP Directory Agent button. Select the clear button. (If SLPDA.NLM is still running, you will not be able to clear this.)

  3. Delete the SLP Directory Agent object.

  4. Under the container where the Scope exists, expand the Scope OU and delete each of the Service objects, then delete the Scope itself. (If more than one SLPDA is using this scope, you will not be able to do this. You will need to delete all the SLP Directory Agent objects or at least remove this scope from their configuration.)

Determining Whether You Need SLP Directory Agents

There are two main reasons for installing SLP Directory Agents.

  1. You will need to install at least on DA if you do not allow multicasting between segments which have clients and servers needing to communicate.

  2. It is a good idea to use a DA if you have a section of you network where multicasting is allowed and there are over 25 servers or a large number of clients (in the thousands).

How Many Directory Agents Do You Need? 

In general, it is a good idea to limit the number of SLP DAs you have in your network. The factors to consider in determining how many DAs to install are:

  1. NDS replication traffic

  2. The number and placement of NetWare servers and clients

  3. Your WAN topology

  4. Your administration policy

NDS Replication Traffic.    To understand how NDS replication traffic is affected by the number of DAs in your network, let's briefly review how an SLP DA functions. Each server (SA) on the network will discover a number of DAs either through multicast discovery, static configuration (via entries in the SLP.CFG file), or DHCP. The SA will register its services with each known DA. The DA will then create Service objects in NDS under the Scope Unit container and also add these services to its local cache.

Under normal circumstances, a DA will hold a replica of the partition in which the Scope Unit exists. In the case where you have more than one DA servicing the same scope, the other DAs will find out about these new service registrations through NDS replication.

The RFC on SLP (RFC 2165) does not define precisely how DAs should communicate with each other. Novell has chosen to accomplish this communication by using NDS. When the SLPDA receives a service registration from an SA, it makes a call to NDS and creates the Service object in the local scope partition. NDS will replicate those changes to all other servers in the replica ring. When the NDS replication event is complete, the other servers running SLPDA.NLM--and which service the scope this object was created in--will read these new services from their local partition and add them to their cache.

It is recommended that each DA hold a copy of the NDS partition that contains the scopes that each DA supports. The reason for this is so the DA will always hold current service information. It is possible for a DA to function properly without a partition replica on the local server. However, be aware that when you load SLPDA.NLM on that server, it will contact NDS and load all services contained in each scope that the DA supports into cache memory on the local server. The only other time this DA will load all services from the scope is during the nightly 24-hour purge process the DA goes through. In other words, any new services on the network (or removed services) will not be learned by this DA until you unload and reload SLPDA.NLM, or when the nightly purge occurs.

By now you should be able to see why NDS replication is a big factor when determining how many DAs to install. To further clarify, say you have three DAs and they all hold a copy of the partition that contains the Scope Unit container. Suppose also that you have 20 servers on your network. How much wire traffic would occur?

By default, the service lifetime of each SLP service is 60 minutes. This means that once every hour, each server must reregister its services with at least one DA. Each time this occurs, there will be about 15 to 20 SLP unicast packets between each of the SAs and the DA, as each server will usually need to update four or five services. The NDS synchronization traffic will then occur as each SA updates its services lifetime and this is written to NDS. In this example, that would amount to at least 20 replica updates every hour. The ability of your network to handle these 20 replica updates depends on how close the DAs are to each other and the available bandwidth of your WAN links.

As another example, say you want 10 DAs to all service the same scope so that every client and server on the network will be able to see every other client and server. To accomplish this, you install a replica of the Scope partition on each DA. Now suppose you have 100 servers on your network. Each of these 100 SAs will need to register with at least one DA every hour. You will have well over 100 replica updates occurring between these 10 DAs every hour. For most customers, this amount of NDS synchronization traffic is not acceptable.

There are two easy solutions for minimizing NDS traffic due to SLP updates:

  1. Keep the number of DAs to a minimum.

  2. Increase the service registration life time on each SA.

The service registration life time is configured as the SA Default Lifetime, which can be anywhere between 129 and 65,535 seconds. You could increase this from the default of 3600 seconds to just over 18 hours. In the first example above, if you changed the service lifetime to 12 hours, you would only have 20 replica updates every 12 hours instead of 20 every hour.

The thing to keep in mind when extending the lifetime is that if a server goes down, it will still be registered with SLP until the lifetime expires. In most cases this is not really an issue. If clients or servers attempt to contact a server that does not respond, they will eventually give up and attempt to contact another server.

Placement of DAs.    The placement of DAs is another important factor to consider. To discuss the options, let's look at how some of Novell's larger customers have handled this issue.

One customer has a central site in the United States and over 400 offices around the world, with at least one server at each site. They chose to install two DAs right next to each other at the central office: one as the main production DA and the other as a backup. Each client and server goes to these central DAs for service registration and information.

Before you dismiss this DA placement scheme altogether, you need to consider how much SLP traffic you would actually see in this type of scenario. When a client comes up and contacts the DA, it is given an IP address of a server to log in to (this is the main function of SLP). Once this is done, you will not see any more SLP traffic from that client unless the client needs to browse the network. The same holds true for a server. Once it loads and gets the SLP service information it is looking for, it will not usually need to contact SLP again except for service registration updates. Since the DAs are both on the same network segment, NDS replication is not a problem. By the way, these DAs were installed on dedicated, high-end Pentium machines to be able to handle requests from many clients and servers.

Another customer with three central sites and many branch sites implemented a variation on this DA placement scheme. They installed a DA at each of the three central sites, and then configured all other servers to contact at least one of these DAs according to which one was closest.

You can install a DA at each branch site if you want. The obvious argument for doing this is to maintain service information in the event that the local WAN link goes down. If the WAN link is down and the local DA (which does not have a replica of the NDS partition) goes down and is brought back up, the DA will not be able to load because it cannot access the remote NDS partition. However, if you put a DA at each branch site, you will have to limit the number of DAs that hold a replica of the scopes (to reduce NDS synchronization traffic over the WAN link). This would mean most of the DAs would not hold replicas and you would not have current SLP data around your network.

There is a way to handle this situation without putting a DA at each branch office. That is to enable multicasting at each local site and block it at the WAN link. Before you totally reject this idea, let's look at the advantages of enabling multicasting. First of all, if the WAN link goes down, you only need the ability for the local clients to contact the local servers. Enabling the multicast address of 224.0.1.22 (the SA multicast address) is an easy solution. When your local clients or servers realize the DA is not available, they will switch to multicasting. Even then, the client will usually only send out one multicast packet. Each SA that responds will do so with a unicast packet. The client will then unicast to the server of its choice and get the local service data it is looking for.

One very large customer chose to do something unique with multicasting. They enabled multicasting on their entire network, but they changed the time to live (TTL) of each multicast packet to 1. (This is configured in MONITOR | Server Parameters | SLP as the SLP Multicast Radius. The default is 32.) The result for this customer is that each multicast packet from a client or server will only cross one router. This was done as part of a backup plan in the event the DAs were not available. The downside to this is that each server and client must be manually configured.

As you can see, there is no standard answer to the question about how many DAs to install in your network. The information provided should be enough to give you a basic idea. Remember, changing the SLPDA configuration is not hard to do. If you set something up and find it is not working well, you can easily add or remove DAs. This process can be made easier by using DNS names instead of IP addresses in the SLP.CFG file of each SA.

How Many SLP Scopes Do You Need?

For most small to medium size customers, one Scope in the network should be sufficient. Having one Scope is the easiest configuration to deploy and maintain. Configuring all SAs and DAs to support one scope is the simplest way to allow all clients to be able to browse the network and see all available servers. When a UA makes a request to a DA, the DA will have knowledge of all servers in the network.

Of course, having one scope is not practical for large networks. If any of the following apply, you may want to investigate implementing multiple scopes:

  1. You have over 400 total servers in your network.

  2. The network is spread across multiple countries.

  3. You are currently using heavy IPX filtering to hide certain sections of the network.

For networks that have over 400 servers or that cross large geographic boundaries, it is not always required that every client be able to browse and see every server in the network. In these cases, multiple scopes can be configured.

For example, consider a network that has a large site in New York and another large site in Dallas, Texas. Suppose they choose to use one scope. There would be at least one DA at each site, and each DA would service this one scope and would hold a copy of the scope partition. As SAs register and update the DAs, the NDS Service objects in the Scope would be constantly updated. Each service update means that the NDS Scope partition must do a replica update between New York and Dallas. Although there are ways to limit the amount of NDS traffic (such as increasing the service lifetime as discussed previously), this is not acceptable for most customers.

One possible solution would be to use multiple Scopes. Figure 2 shows an example of a network that is using three Scopes: one for New York, one for Dallas, and one common Scope.

Figure 2: Example of a three-scope network.

With this configuration, all servers in New York would register with the New York Scope and all servers in Dallas would register with the Dallas Scope. For servers that need to be available to all clients in the network, they will have those specific servers register with their local Scope and the common Scope. Each DA would be configured to support the local Scope and the common Scope. That way, users in New York can go to their local DA and find services for all local servers and the few common servers from Dallas.

The 64KB Limitation Issue 

Another reason to use multiple scopes is the 64KB issue with SLP and service information. When a UA requests information about a specific service from a DA, it will send an SLP Service Type request asking for all services of the same type (such as bindery.novell). The DA will respond with a UDP reply packet. If there are so many bindery.novell services registered in SLP that they do not all fit within this one UDP packet, the DA sets an overflow bit. The UA will then open a TCP connection with the DA and ask for all the bindery.novell services again.

The limitation is that a total of 64KB of data is all the DA can send to the client via a TCP connection. If there is more than 64KB of a certain service type, the list will be cut short. The reason for this is, in SLP version 1.0, the "length field" in the SLP response packet header is only 16 bits, allowing for up to 64KB of service data.

Note: In SLP version 2, the length field has been changed to 24 bits, thus allowing for up to 16MB of response data. Novell is planning to implement SLP version 2 sometime in late 2000.

 

Below is a list of how many of the common service types will fit into a 64KB response packet.


Service
Number per Response Packet

NDAP.Novell

Around 1200, depending on how long the partition names are

Bindery.Novell

700 - 1100, depending on how long the server names are

MGW.Novell

Around 1200

SapSrv.Novell

No more than 540

As discussed earlier, there is a configuration option called Scope Filtering. This allows certain services on a server to register with specific scopes. The use for this would be to hide certain services from various parts of the network (similar to IPX filtering). As an example, it is possible to register the bindery.novell service of a server to one scope and have all other services register to another scope. A more common use for Scope Filtering is to filter what scopes the Sapsrv.novell service is registered into. This service represents IPX services (via the compatibility mode gateway) that are running on a particular NetWare 5 server. (IPX services on NetWare 4.11 servers do not register with SLP.)

For a large network, implementing multiple scopes and Scope Filtering can become very complicated depending on the network design and needs. Also, it quickly grows beyond the ability of this document to address. It is recommended that Novell Consulting be engaged to assist and direct this effort. If scoping is done properly, the network will function smoothly. If done incorrectly, NDS performance issues may arise.

A Practical Example of DA Implementation

As a simple but practical example of what we have covered in this AppNote, consider the network shown in Figure 3. A NetWare 5 server is located at the corporate site A, and another one is located on the other side of a WAN link at site B. A client at remote site B uses SLP to get services from the server at site B. But how can this client discover services on the other side of the WAN link on server A?

Figure 3: A simple example of DA implementation.

There are four ways to accomplish this.

  1. Enable the routing of multicast packets across the WAN link. The client can use active discovery of services to find what it needs. This is not normally acceptable. It may be a good idea to allow the routing of just the SLPDA multicast address of 224.0.1.35 and keep closed the SLP SA multicast address of 224.0.1.22. In this configuration, only requests to find the SLP DA at site A would be passed.

  2. Use one SLPDA at site A only and configure the clients at site B with the IP address of the SLPDA using DHCP. It is possible to use a NetWare 5 DHCP server at site B to just provide SLP configuration and not addresses. When the NetWare 5 client comes up, it sends a DHCPINFORM packet requesting options 78 and 79 (SLPDA configuration). The NetWare 5 DHCP server can be set up to just provide this information.

  3. Use a DA at site A only and statically configure the clients at site B with the address of the DA. This configuration is found under the Service Location tab on the NetWare Client 32 Properties. This choice can be time consuming to implement.

  4. Configure a DA to run at site A and site B and have the DAs service the same scope. The clients at site B can be configured with the IP addresses of both SLP DAs. This allows for redundancy in the event one of the DAs is not available.

Q&A on Configuring SLP Directory Agents and Scopes

The table below lists answers to commonly-asked questions regarding SLP Directory Agents and scopes.


Question
Answer

When do I need to configure an SLP Directory Agent?

When you have servers and clients that are separated by a router that does nor forward multicast packets.or If you have over 25 servers in the same multicast radius.

How many services can one SLP DA handle?

Each customer's site will be able handle different amounts and types of SLP traffic into and out of the DA. In general, one scope and one DA should be able to handle the service registrations of 300 to 400 servers. Beyond this, you will want to configure multiple scopes and DAs. Depending on how many clients will needto access the DA and scope, it may be advisable to implement multiple DAs/scopes before reaching the 300-400 level.

What can I do to have Directory Agent failover support?

This is simply done by installing two DAs at the site that requires failover. Have both of these DAs service the same scope and point each server and client to these 2 DAs. All servers would have their SLP.CFG file configured with both DA addresses. All clients would be configured with both DA addresses using DHCP orstatic configuration.

Is it good advice to dedicate a machine to service as a central DA which holds all services?

This depends on how you administer your network. Some customers, even those with very large networks, have success with centralized administration. This may not be the best method for customers that prefer distributed administration, but it is still an option. A central DA is easier to administer, but the servers andclients must rely on the communication links to stay up in order to get SLP information.

What scopes will a client use if it does not have any scope names configured?

If a client is not configured with any scopes (either through DHCP or static configuration), it will default to the scopes that are supported by the DAs that it contacts. It is not required to configure each client with an SLP scope name. All it really needs is one or more DAs to contact.

What methods are available to configure a NetWare 5 client with the address of a DA?

There are three methods:· DHCP, by using options 78 and 79.· Multicast dynamic discovery using the multicast address 224.0.1.35.· Static configuration under Client 32 properties and the Service Location tab.

Is SLP information carried in UDP or TCP packets?

SLP information is carried in standard UDP or TCP packets and use port 427. UDP is the default.

Conclusion

This AppNote has discussed the theory behind SLP, DAs, and scopes, along with how to configure SLP DAs and scopes. Readers should now have enough information on how SLP and SLP DAs function to assist in determining the best configuration for their specific network and needs.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates