Configuring SLP with a Scoped Directory Agent
Articles and Tips: tip
01 Jan 2003
Taken from Technical Information Document #10059981
SLP (Service Location Protocol) does for IP what SAP (Service Advertising Protocol) does for IPX. SLP, in the default configuration, uses multicasts to discover IP services on the network. This works very well in non-routed environments. If the system contains a router that blocks these multicasts, or with a very large routed environment, SLP needs to be configured to use unicasts instead of multicasts. This requires the use of an SLP Directory Agent (DA).
The DA acts as a directory of IP services on a network. As a server's IP services become available, the server contacts the DA and informs it of the existence of these new services. When the services are halted, the server again notifies the DA. Whenever a server or workstation wants to find a service, it asks the DA for the information.
SLP is intended for use with NetWare versions 5.0 and higher. There is no need to configure lower versions of NetWare when these instructions are followed.
Configuring SLP to Use Unicasts
Here are the steps to configure SLP to use unicasts:
Select a server to act as a Directory Agent. This server needs to have NetWare version 5.0 or higher. All of the other servers and all of the workstations will need to contact it, so choose one in a central location if possible. The server must have a master or read/write replica of the containers that will hold the Directory Agent Object and the Scope object. More than one DA per scope can be configured for fault tolerance (see note below).
Decide on a scope name to use. The scope name can be anything, but remember that it may have to be typed on a lot of workstations, so keep it simple. Many people name it after their organization. Use a different scope name for each tree. While it is acceptable to have multiple scopes in a single tree, it is usually not recommended, and that type of configuration is beyond the scope of this document.
Choose or make a container in NDS that will hold the DA's database. This is usually the container in which the server resides. In any case, make sure that the DA has a master or read/write replica of the container. It is best if this container is not replicated across WAN links because it will be updated often. This container may be a separate partition.
If SLPDA.NLM is loaded on any server, unload it. Make sure that no server, including the DA server, has a line in the AUTOEXEC.NCF file that loads SLPDA.NLM.
Search the directory tree for objects of types "SLP Directory Agent" and "SLP Scope Unit." Delete any of these objects that exist. This will clear out any previous attempts at setting up Directory Agents. Delete the contents of the Scope units before deleting the units themselves. If these objects can't be deleted, verify that the SLPDA.NLM is not running on any server and try again. If they still cannot be deleted, use the ConsoleOne utility instead of NWAdmin for this step.
Create an "SLP Scope Unit" in the container designated in Step 3. This object can be named anything, but it is recommended that it is the same name that as the Scope. Go to the details of the new object and enter the scope name in the "Scope name" field.
Create an "SLP Directory Agent" in the same container. Again, it can be named anything. The recommended name is "FS1_SLPDA," where "FS1" is the name of the server hosting the DA service. Go to the details of the new object and select the server that is acting as the DA in the "Host server" field. Then add the previously created scope unit to the "Serviced scope units" list.
Load MONITOR.NLM on each server in the tree. Enter the "Server Parameters" menu. Enter the "Service Location Protocol" submenu. Enter the scope name in the "SLP Scope List" field. When entering the scope name, use only the common name and not the fully qualified domain name (FQDN). For example, if the scope is named FRED, then just type FRED in the scope list. This change requires restarting the server before it will take effect. If the server can't be restarted right away, then don't load MONITOR.NLM until you can restart server or the change may be lost. If this step is not completed for every server in the tree, the servers will not register their IP services with the DA and they will not communicate properly over IP with one another. Also, clients will have problems getting services from any server not registered with the DA using the proper scope.
Edit the SYS:\ETC\SLP.CFG file on the DA server and make sure that there is nothing in the file besides comments.
Edit the SYS:\ETC\SLP.CFG file on all of the other servers (not the DA server) and add a line:
DA IPV4, XX.XX.XX.XX
where XX.XX.XX.XX is the IP address of the DA). Make sure that there are no other lines in this file except for comments. It might be convenient to edit this file on one server and then copy it to the others. If this step is not completed properly, the servers may not be able to communicate with each other.
Do not continue beyond this point until all of the servers have been restarted after making the change described in Step 8.
Add a line to the AUTOEXEC.NCF file on the DA server that loads SLPDA.NLM. This line can go at the end of the file.
Load SLPDA.NLM on the DA server.
At the DA server's console, type:
SET SLP RESET = ON
At the DA server's console, type:
You should see a line that starts with
SLP LOOPBACK ADDRESS : ACTIVE :
followed by the scope name should be displayed. (There should be no other lines unless the system is configured with more than one DA.)
At the console of all of the other servers, type:
SET SLP RESET = ON
Then at the consoles of the other servers, type:
You should see a line that starts with "XX.XX.XX.XX : ACTIVE :" (where XX.XX.XX.XX is the IP address of the DA server) followed by the scope name.
At any server console, type:
DISPLAY SLP SERVICES BINDERY.NOVELL
One URL for every SLP configured NetWare 5.x server should be displayed. This will show how many servers are registering with the DA. If all the servers show up then the servers are all communicating via SLP.
Configure the workstations, either manually (through Novell client properties on the "Service Location" tab) or by using NetWare DHCP (options 78 and 79), with the scope name and the IP address of the DA. If you are doing this via DHCP, set 'mandatory' if the desired effect is to have DHCP actually override any local settings.
Finally, unload DHCPSRVR and load it again for the DHCP Server to hand out this information. The workstations need to be restarted in order to make the change effective. The workstations may not be able to communicate with the servers without restarting.
When to Use Multiple DAs
Multiple DAs can be configured, but in most cases you should not. Multiple DAs are used primarily for redundancy and in some special cases they can be strategically placed to provide a performance enhancement. However these instances have proven to be rare. Make sure that the DAs meet the following requirements:
DAs should be in the same physical location (not crossing a WAN link) when possible, but in some cases placing a DA across the WAN is acceptable and will work just fine. (Keep in mind that NDS replication and communication services can be affected significantly).
DAs must have both master or read/write replicas of the partition that contains the Scope Unit. (Once again, there have been instances where both servers did not have a replica and still functioned, but this is not the norm and is not recommended by Novell).
It is recommended to partition off the Scope Unit itself, and only give the DA servers replicas of this partition. It is also recommended to limit the number of DAs to between two and four, depending on the size of the network and DA placement.
The configuration process for a scope with two DAs is basically the same as it is for the scope of one. You should create only one SLP Scope Unit, but create two SLP Directory Agent objects and configure both of them to use the same SLP Scope Unit. All of the workstations should have the IP addresses of both DAs added to their Directory Agent list. All non-DA servers should have two lines added to their SLP.CFG file (one for each DA).
It is recommended that the DA servers have each other's IP address in their SLP.CFG files. (For example, Server A will have server B's IP address in its file, and server B will have server A's IP address in its file, but neither DA server will have its own IP address in its own SLP.CFG file.) If a DA server has its own IP address in its SLP.CFG file, the DA won't work correctly.
* Originally published in Novell AppNotes
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.