Often I get questions on SLP, what it exactly does and how to implement it.
To answer the first question. SLP stands for ' Service Location Protocol '.
What it does is already in it's name: It's a service running on one or more systems, that hands out a list of services to your clients specifying what services can be found on your network - instantly, without the need to have the clients ' go out and look '.
It can loosely be compared to DNS, which also helps to centrally resolve. With DNS you can resolve system names and certain services (the mail MX for example) to ip addresses and visa versa.
SLP on the other hand, is specific to making it easy for your networked clients to find out where a service is running they are looking for (e.g. location of printer services, timeserver, authentication sources like eDirectory, etc). The service list is built up dynamically and has more detail.
Comparing DNS and SLP also leads stating that having both DNS and SLP setup correctly (especially in in your Novell/mixed environments) will greatly benefit your network connectivity!
As an example, one very noticeable effect SLP has when not setup correctly & you are trying to login to an eDirectory using the Novell Client:
If the network your client is on is split up into multiple subnets and the server you are trying to login to, is on one of the other subnets.. There is a very big chance you'll get a time-out trying to log in. The cause being due to the server (actually the eDirectory service) not being found by the client. Entering the ip address instead of the server name is a quick workaround but also shows resolving is lacking.
The solution to better resolving:
When running multiple servers (read: more then two) in your network, especially if the network is split up into segments, it's good practice to setup one or more SLP Directory Agents (slpda) for each LAN.
This Directory agent will collect all the services it finds and put them in a central list. This central list can then be handed out to the clients making the available services known directly to them. This will speed up browsing and searching as also avoid connection errors due to time-outs.
SLPDA : Netware vs Linux
SLP on Netware has one benefit over the current Linux implementation: It uses the eDirectory to cache it's SLP listing information.
The advantage here is that you can safely restart the SLP daemon without loosing the gathered services list (the eDirectory is read when the daemon is started), which makes it a great service to setup as cluster resource.
With the Linux implementation (openSLP) there is no writing and reading to the eDirectory. The SLP DA will flush it's cache when stopped.
Although the SLP DA will start re-collecting it's service list as soon as it's started, it will take some time (generally 10 to 20 minutes) before all services will be listed.
I'm hoping that in time an eDirectory option will get in the openSLP code as was also done with DHCP.
Implementing SLP DA's in OES / OES2 & SLES:
The above change in the Linux openSLP makes implementing your SLP DA a tad different.
Where with Netware it was recommended to only setup one DA for each site, with Linux it's recommend to set up two (independent) SLP DA's per site.
This way, when one of the servers needs to be restated or becomes unavailable, you'll have the second one to keep handing out your SLP listings.
There is a good article by Peter J on setting up your DA over at Coolsolutions : AppNote: Configuring an OpenSLP DA on OES or SUSE Linux Enterprise Servers
Although it was written for OES1, it's still valid for OES2.
When setting up two openSLP DA's, make sure to add both SLP DA's to your clients configuration as also let each DA talk to the other.
Hope you find it useful & if you have any questions/suggestions or other, I'm game ;)
Cheers,
Willem
