As your NetWare network grows, minimizing network traffic will become one of your major objectives. One way to accomplish this is to remove IPX from your servers. If you remove IPX, you’ll need to provide a way for the NetWare servers to “advertise” the services hosted by the servers, as well as services hosted elsewhere that the servers are aware of.
In the IPX world, this process is known as SAPing (short for Service Advertising Protocol). Unfortunately, because of the nature of IPX, this process can become rather chatty. The equivalent form of SAP in the IP world is known as Service Location Protocol (SLP). In this Daily Feature, I’ll walk you through the process of installing and configuring SLP.
Becoming familiar with the SLP terminology
When implementing SLP, you’ll work with the SLP Directory Agent (DA) and the SLP Scope Unit. When clients or other servers request information on services, the DA provides that information. The SLP Scope Unit contains the registered service entries. You’ll see two kinds of Scope Units:
- Unscoped Unit—Contains information on all known services on your network.
- Scoped Unit—Contains a limited amount of information about the services available on a portion of the network.
Before you implement SLP, you have to decide how to deploy the DAs within your organization. As a general rule, you need one DA for each physical location. You can have more than that, depending on the level of fault tolerance you want to provide. If you have more than one DA, a server can be down and SLP services for a particular scope will still be available. Depending on what type of overlap you need to have between the DA scopes and your clients, configuring your clients to know about more than one DA could help minimize the calls to your help desk.
You can set up SLP on a server either automatically or manually. The automatic method is as simple as typing load slpda at your server’s console prompt. What the manual doesn’t make clear is that this works only on the first server in a particular context. When you load SLPDA.NLM the first time, it will find the server is not configured for SLP. SLPDA will then prompt you to create a default configuration.
If you choose Yes, several things will happen. First, SLPDA will create an SLP DA object in the NDS tree named after the server on which you’re loading SLPDA. SLPDA will also create a container for the SLP scope objects and place an unscoped NDS object in that container. After the initial modification of NDS, SLPDA loads and remains resident until you restart your server or unload the NLM. Although the SLP service is now loaded on the server, remember to place the load slpda command in the server’s AUTOEXEC.NCF file so the NLM will load after the server restarts.
The manual method involves going into NWAdmin and creating the SLP DA and scope NDS objects. Associate the scope object with the SLP DA that will service or provide information about the services covered by the scope in question. After creating the SLP objects, load SLPDA.NLM at the server console screen. Remember to place the same load line in the server’s AUTOEXEC.NCF file so that it will automatically load the next time the server is started.
Bringing a new server into the tree
Bringing a new server into an existing NetWare tree is normally not that big of a deal, but when you’re running SLP, you’ll need to take a couple of extra steps. This is because the SLP communications process uses multicasting to communicate between servers. Since this type of communication typically won’t cross a router, we need to handle things a little differently. For our example, we’ll use a new server that will be at least one or two router hops away.
When you first bring up the new server, you’ll need to install it into a temporary tree. In order for this server to see the SLP server at the other end of the connection, all the NLMs that a NetWare 5.1 server normally uses should be installed. Because the server is new, not all of the needed NLMs will be loaded initially.
By default, a NetWare 5.1 server uses the RIP 1 routing protocol on TCP/IP. With RIP 1, the server may not be able to learn routes needed to reach the server at the other end of the connection. By allowing the server to come up, you can change the IP routing protocol from RIP 1 to RIP 2.
Next, you must edit the SLP.CFG file (which you’ll find in the server’s SYS:ETC directory). Add this line:
DA IPV4, xx.xx.xx.xx
with xx.xx.xx.xx representing the IP address of the DA you have at the other end of the connection.
After you’ve saved the file, type
set slp reset = on
at the server’s console prompt and press [Enter]. The next few lines that appear on the screen should indicate that NDS has found the DA and is now communicating with it. To confirm that the command was successful, open DSMerge. There, you should be able to choose the name of the NDS tree at the other end of the connection.
At this point, you can use NWConfig to remove NDS from the server. After the process has completed, you can select the option for installing Directory Services on this tree. Select the option for installing into an existing tree; this option should list the same NDS tree name you saw in DSMerge.
After the server reinstalls NDS and has inserted itself into the new tree, you should partition NDS to put this server in its own partition. You should also create a DA on this server so that the server can access local resources without having to cross the WAN connection.
Let’s face it: Sometimes things just break for no reason. To get an idea of what things currently look like SLP-wise, go to the server console screen. The first command you should try is
display SLP DA
After you press [Enter], you’ll see a listing of all known SLP DAs. Ping each one to verify that connectivity exists between them.
The next step is to make sure the SLP DAs have the appropriate attributes, such as the ability to advertise the services each server offers. To do so, type
display SLP attributes
at the server console and press [Enter]. A listing will appear that includes each service the DA knows about. Run this command from each server to ensure that the SLP cache on every server has the same information as all other servers in the network.
Sometimes you need to see all of the communications going on between SLP servers. You can do this by having SLP redirect to a text file the messages that normally appear on the server screen. To do so, type
slp open slp.log
and press [Enter]. To make sure you have the most information to work with, type
set slp debug = 124
and press [Enter]. Once you think you’ve captured enough information, type
and press [Enter].
If the log doesn’t provide the information you need, your next option is to dump the DA cache to the debug screen. To do so, type
at the server console prompt and press [Enter]. Then, issue the debug and slp open slp.log commands. The contents of the cache will show you what the server hears from the other DAs it knows about.
To make sure SLP is working on all the interfaces (that is, network cards), you can unload SLPTCP.NLM and then reload it. When the module reloads, you’ll see a list of the interfaces that SLP binds to. By default, SLP should bind to all the network interfaces that TCP/IP has been configured for.
As you can see, implementing SLP is pretty simple. The most complicated decision you’ll make is how best to implement it for your particular network. The best advice is to proceed slowly and keep good documentation, which will be a big help when you’re troubleshooting.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.