|The SLP Standard|
SLP is a mature TCP/IP standard, identified in RFC2165.
In a previous article (
Migrating from IPX to IP in NetWare 5.1
), I looked at some of the challenges that face those implementing NetWare 5.1 with TCP/IP. In this article, we will look at another of these factors: the Service Location Protocol (SLP).
From SAP to SLP
On IPX-based NetWare networks, clients and servers use the Service Advertisement Protocol (SAP) to locate network services. SAP provides a simple way of locating devices on the network with minimum intervention from administrators. Every 60 seconds, each server announces its availability to the other servers on the network. In addition to these server-to-server communications, clients use SAP to locate network services. Easy though it may be to configure, SAP’s communications are based around broadcasts, which is its one major failing.
The main function of SLP is to let clients locate an NDS server that can perform authentication. Once the client is authenticated, location of services normally becomes a function of the NDS rather than SLP.
In a small network, SAP’s broadcasted announcements are not too much of a problem; but in larger networks, they can represent a large chunk of network traffic. Although Novell made a number of efforts to improve SAP, the company never managed to reduce the SAP broadcasts by any great extent; so, when TCP/IP became the default protocol for NetWare networks, the opportunity to drop SAP altogether presented itself. In place of SAP, Novell elected to use SLP as a means to identify and locate network services.
It would be unfair to suggest that SLP is a complex system, but it does have more considerations than SAP. To understand how SLP provides service locations, we must first look at the three software components that make the process happen:
- User Agent (UA)Loaded on every server and workstation on the network. When the workstation or server wants to locate a service on the network, the UA will, depending on the SLP configuration, query the Service Agents or Directory Agents on the network for information about the location and availability of a given service.
- Service Agents (SA)Loaded only on those devices that provide a service to the network. The services that are provided by a computer are registered with the SA so that when it is queried by UAs, it can respond with the correct information.
- Directory Agents (DA)In a custom SLP configuration, used to centralize the information that is normally provided by the SAs. Rather than clients querying SAs individually for a list of available services, DAs can respond to clients with a complete list of network resources and thereby reduce the amount of traffic generated by requests for services. Clients can then use the information provided by the DA to communicate with the server providing the service.
The SLP Process
With SLP, rather than using broadcasts to make requests to servers, clients use multicasts, instead. When a client wishes to locate a service, it sends its request to a multicast address on which all the SAs on the network are listening. If a server can satisfy the request from the client, it replies to the client using a direct unicast. Although the multicast traffic is only marginally better than the broadcast traffic produced by SAP, the periodic announcements of services is not needed, thereby preventing the “60-second buzz” of SAP networks. Even so, in larger internetworks, these multicasts can still cause problems. This is where Directory Agent SLP components start earning their money.
DAs function by providing a centralized resource for the collection of service information. When DAs are used, SAs register their services with DAs, and UAs query the DAs directly for service information.
Having DAs on the network affects how SAs function. If an SA discovers a DA, it immediately sends all of its registered services directly to the DA. SAs can discover whether a DA exists through a process called active discovery. To perform active discovery, SAs send multicast transmissions to the IP address 184.108.40.206. Servers acting as DAs respond to these discovery packets and initiate the registration of services.
UAs also have the ability to automatically recognize the existence of a DA, providing the ability for network administrators to make a DA-centered environment with minimal configuration. Any NetWare 5.x server can act as a DA by loading SLPDA.NLM.
An alternative to the active discovery process is to manually configure the SAs and UAs with the address of the DA. For servers, this configuration information can be provided through the use of a text file called SLP.CFG or via Dynamic Host Configuration Protocol (DHCP). Likewise, for workstations, the location of the DA can be supplied manually through the Novell client properties, or automatically through the use of DHCP.
No matter how the presence of the DA is detected, one rule remains: If SAs and UAs know that a DA exists on the network, both agents have to use the DA for service registration and resolution.
Scope This Out
If you crave even more control of your SLP-related traffic, SLP also provides the ability to use scopes to group network resources into logical units. By creating scopes on your network, traffic can be even more controlled, because agents will only communicate with other agents (be they SA, UA, or DA) that are in the same scope as themselves.
|SLP and NDS|
When DAs are used, SLP objects and records are stored in the NDS. This process allows SLP-related information to be replicated between servers as part of the standard NDS replication process.
For example, imagine that you have a Wide Area Network (WAN) with two sites. By creating a scope for each site, you can prevent SLP traffic from being propagated across the wide area link. All of the resources on site A are configured to be within Scope A, and all the resources on site B in Scope B. To make sure that resources in another scope are still available to the whole network, you can either take advantage of Novell Directory Services (NDS) partitioning and replication or manually configure DAs with the information necessary to exchange data with other DAs. Another, less practical, solution is to configure each client PC with the IP address of DAs on both sites.
By now, you may well be asking yourself whether you should create DAs and configure a custom SLP environment on your NetWare network. Well, according to Novell, you should use DAs if your network includes more than 25 NetWare servers, or if you have a WAN. In reality, the amount of configuration required means that implementing DAs is a simple task. If you are looking for ways to streamline the traffic on your NetWare network, using DAs is a simple way of reducing unnecessary network traffic. //
Drew Bird (MCT, MCNI) is a freelance instructor and technical writer. He has been working in the IT industry for 12 years and currently lives in Kelowna, BC., Canada. You can e-mail Drew at [email protected].