With NetWare 5.x and soon to be NetWare 6 running SLP to assist in the advertisement of available network services, it becomes more and more important to keep Service Location Protocol (SLP) running as smoothly as possible. In this Daily Drill Down, I will walk you through some basic steps you can periodically perform to get a quick idea of whether or not things are working like they should be.

What’s SLP?

SLP is the protocol that NetWare 5.x uses to advertise services when you run in TCP/IP on NetWare. For more information about how to implement SLP on NetWare 5.1, see the Daily Drill Down “Implementing SLP on NetWare 5.1.” The suggestions provided in this Daily Drill Down will apply whether you are running an unscoped or scoped SLP configuration.

Checking the health of NDS
NDS must be in good shape in order for SLP to work correctly, because SLP is an integral part of NDS. So, before you can make sure SLP is running optimally, you must first know how well NDS is running.

The first step is to load DSREPAIR.NLM on the server that is serving as the directory agent (DA) for your network. Run the Time Synchronization option from the main DSREPAIR menu. When the View DSREPAIR.LOG screen appears, make sure that each of the servers listed has a Y in the Time Is In Sync column. If any servers aren’t synchronized time-wise, correct this immediately before proceeding. If the times appear to be in sync, that is a good indication that all is working well with NDS.

Next, look in the +/- column. This column shows how current the partition replicas are. Being off a minute or so isn’t much to be worried about. If you are 15 minutes or more out of sync, you need to identify the cause of the problem and resolve it. For more information about how to check the health of NDS, see the Daily Drill Down “Checking the health of NDS.”

Checking the health of SLP
The two main portions of SLP to check are the DAs and Server Agents (SAs). You’ll need to see that the DAs are running and that the SAs can see the DAs. To do so, at the server that is the DA, type set slp reset = on at the server’s console prompt and press [Enter]. The server should return a message that tells you the SLP reset is complete. If you don’t see such a message, you should make sure the SLPDA.NLM is loaded on the server by using the modules command at the server’s console prompt.

Now that we have checked to see that the DA is running, you will next need to make sure the SAs see the DAs. Type display slpda at the console screen. You should see a message that indicates which scope the SA is in and whether that scope is active. If it isn’t active, there is a serious problem that needs to be quickly corrected. If you started with this step first, you should first ping the IP address of the DA server to make sure the SA server can see the DA. If it can, verify that the DA server has SLPDA loaded. Once you have verified that the SA can see the DA, type display slp services at the server console on each SA and DA on your network.

If you have a discrepancy between servers where a server can’t see all of the available SLP services on the network, you can use the set slp reset = on command at the console prompt of the server that isn’t reporting all of the services that the other servers are showing. You’ll see several lines appear on the console screen when you execute this command. There are two lines in particular that you need to watch. The first line will show what DA that this server knows about. If you see this line, you’ll know that either the slp.cfg file has been read or that the information has been read from NDS. The next line should show the same IP address but with the text activated DA. If you don’t see this line, the SA on which you are running the command is having a problem contacting the DA.

When you review the information displayed as a result of the display slp services command, you will see several lines that start with the following words:

  • BINDERY—This line will list each server on which the bindery server is running.
  • SRS—Each server that has NetWare Distributed Print Services (NDPS) loaded on it will display this line.
  • NDAP—This line appears on each server that is running NDS.
  • SMDR—This line appears on servers that have TSANDS, TSA500, and SMDR loaded.
  • SAPSRV—When a server has IPX CMD (compatibility mode driver) loaded, you’ll see this line.

Another step to take when checking the SLP’s health is to start NetWare Administrator at your administrative workstation and look at the SLP SCOPE NDS object. Expand the object and observe the SLP object listed there. This should be the same list that is displayed on each of the servers when you ran the display slp services command. Depending on what type of documentation you keep on your network, this would be another good thing to either print out or write down so that you have something to compare it against when you are troubleshooting a problem.

A real-life troubleshooting example
They say that experience is the best teacher. Nothing will teach you how to troubleshoot an SLP problem better than actually having a problem yourself. In my case, I had been running SLP at my company for several months and thought I had a basic understanding of how to troubleshoot SLP problems. Wrong!

I walked in one day and was told to implement a Veritas backup system. Everything went fine until I tried to back up the Novell servers. The Veritas agents on the Novell servers worked well when I was using IPX but didn’t work at all with the servers that ran only IP. I could start the backup process or try to browse drives/directories on the server, and the process would hang. I went through the steps I have outlined above and started seeing something that was disturbing: One of the Novell servers was showing the public TCP/IP address instead of the private TCP/IP address that I gave it when I originally configured TCP/IP.

I verified that SLPDA was showing up as loaded on the DA on the network and that the scope that was configured in NDS was showing up as active on all the SAs on the network. I was also able to ping each server from the other servers on the network. This proved that the communications path between the servers was good.

At this point, I tried deleting the SLP records under the scope object that were reporting the wrong address and then ran the set slp reset = on command on the server that had been advertising the wrong information. I found that I had to wait a minute or so to allow time for the information to show up on the DISPLAY SLP SERVICES list and under the SLP SCOPE object, as well. I had tried everything else that made sense and nothing seemed to work, so I took the extreme step of deleting all SLP configuration information from the network and rebuilding the configuration from scratch. The problem showed up again.

At this point, I put a call in to Novell Support. This problem proved to be a head-scratcher for them, as well. The first thing we thought was that something in the file that INETCFG.NLM creates was causing the problem, so we deleted everything in INTECFG and started over, but the problem reappeared.

After spending over an hour reviewing everything and trying several suggestions, the problem got escalated to second-level support. What we finally came up with was to delete the SERVCFG.000, SERVCFG.TMP, and SERVCFG.NBK files from the C:\nwserver directory on the server. These files store the server parameters configured in Monitor.NLM’s Server Parameters option. To delete these files, I had to down the server and exit into DOS. NetWare automatically re-creates these files when you restart SERVER.EXE.

After bringing the server back up, I had to run the set slp reset = on command. The problem resolved itself within a few minutes. Needless to say, I wrote down the steps I took to resolve the problem so if it cropped up again, I could more easily fix it.

A periodic check of NDS will go a long way in avoiding potential problems in SLP. You should also document which servers will be the DAs and which ones will be the SAs and keep this list in a folder with the documentation for your network. It will come in handy if you ever encounter a problem. Remember that with SLP failures, as with most things, experience can sometimes be the best teacher: Document the steps you take to correct a problem, as they may come in handy later.