Frequently Asked SLP Questions
Novell Cool Solutions: Feature
Digg This -
Posted: 22 Sep 2004
SLP (Service Location Protocol) is an IETF standards-track protocol that provides a framework to allow networking applications to discover the existence, location, and configuration of networked services in enterprise networks. You can learn more about SLP at: http://www.openslp.org/
Here are some Frequently Asked Questions (FAQs) about SLP. See also TID 10025313.
Q1: For a typical NT Novell 4.7 client workstation, how many SLP registrations will be performed (startup, shutdown, and on-going)?
A1: A typical 95/98/NT client will not perform any SLP Service registrations. SLP Registrations are performed by the Server Agent module for services such as bindery.novell (NDS Login server) or ndap.novell (NDS Replica server). A typical 95/98/NT Client will not have any services to advertise, though the Novell Client for Windows 95/98 and NT do ship with a fully functional SA. This is why each client will issue an IGMP packet to notify any routers that they are a member of the 126.96.36.199 multicast group. The clients are ensuring that they will be able to receive any SA SLP Service multicasts (assuming multicast is enabled across the router) in the event they have the requested service. If for some reason the client was registering SLP Services, they would default to re-registering them every 3 hours (SLP Service Default Lifetime), whereas a NW5 server defaults to re-registering them every hour.
Q2: For a typical NT Novell 4.7 client workstation, how many SLP queries will be performed (startup, shutdown, and on-going)?
A2: This depends on the SLP configuration/design. By default there is no assigned DA or Scope, and Dynamic Discovery is enabled. This means that there will be up to five multicast packets for the 188.8.131.52 DA Advertisement/Discovery address. If SLP finds a DA, then all requests from that point on will be unicast to the DA. If no DA is discovered/configured, then the SLP client goes into "SA mode" where all SLP Service and Attribute Requests are on the 184.108.40.206 multicast address (IGMP registered to by all SAs on the LAN).
Once a DA has been discovered or the SLP Client has reverted to SA mode, then every time a new SLP Service is requested an SLP Service Request packet is issued. (An example of an SLP Service request: if a login script tries to map a drive to MyFS1:SYS\PUBLIC, the client would hand the MyFS1 value to SLP to attempt to resolve within its configured scope). If there are successful replies, an SLP Attribute Request packet is issued to read the server's network addresses (IP or IPX).
So a typical SLP Service query using a DA will take only four packets for each DA the client discovers (sent to all DAs). In SA mode, it sends out one SLP Service Request packet, but there may be multiple replies followed by multiple SLP Service Attribute requests.
Once an SLP Service is discovered, it is cached for the amount of time specified in the SLP Cache Relies parameter. The next time SLP receives a request, it will check its cache before attempting to locate the service on the network.
Q3: For a typical NetWare 5.1 server, how many SLP registrations will be performed (startup, shutdown, and on-going)?
A3: A Novell 5.1 server will perform a registration for each service it needs to advertise. This is typically one for nwserver.novell and an ndap.novell for each replica the server holds (if there were 4 replicas on the server, there will be 4 different ndap.novell registrations). There are also other services such as srs.novell for the NDPS Broker (BROKER.NLM) or rconsole.novell for the Java Rconsole. So it depends on what is loaded on the server. Each of these services will default to having a lifetime of 1 hour (you can change this by using the SET SLP SA DEFAULT LIFETIME parameter on each server advertising services). The SA will reregister the service so it has a new one-hour lifetime within 128 seconds of when it is going to expire. For details on the algorithm used in service re-registration, see TID 2951567
Q4: For a typical NetWare 5.1 server, how many SLP queries will be performed (startup, shutdown, and on-going)?
A4: This again depends on how the server is configured for SLP and the environment the server is in. If there is no DA assigned or dynamically located, then the SLP traffic can be very high when NDS attempts to build replica ring information via SLP (i.e., when the server first boots). If a DA is assigned, the traffic is much lighter (the total number of packets depends on how many partitions and replicas of each partition are in the tree).
Q5: What is the average traffic of a successful SLP registration request or response?
A5: SLP Service registration occurs only when a DA is present and discovered by SAs on the network. If there is no DA, then SLP does not register services; each SA becomes its own island of information and only knows about services it holds and no one else's. If a DA is configured, the SLP registration is a two-packet exchange between the SA and DA (req/rply).
The DA will do an unsolicited advertisement using the 220.127.116.11 multicast address every three hours by default. This can be configured using the SET SLP DA HEART BEAT TIME parameter. When the DA advertises, it allows several SAs to discover it simultaneously. The SAs then register their services to it if they belong in the same scope.
Q6: What is the average traffic of a successful SLP query, and the average traffic of a failed SLP query?
A6: If the SA has discovered a DA, the SA will typically send two requests (with only two replies) to get service information. The first request is an SLP Service Req (is there a Service object that meets this criteria?). The second is an SLP Attribute Req (the right service object was found, now its details are needed). If multiple service objects match the search criteria, then there will be an SLP Attribute request/reply for each. If there are multiple DAs discovered by the SA, then this process is used against all of them simultaneously. (This is a good reason not to point your clients at more than two to three DAs).
For a failed SLP query, it depends on the application for a "fallback" method. When using a DA, SLP does not necessarily get creative about trying to find something that "sounds like" what was requested. The Novell client does perform some fallback methods for locating servers (i.e. find server X in this Scope, find server X in any Scope, or find NDS Tree X in this Scope, find NDS tree X in any Scope, etc.). However, this is used only when trying to locate a server/tree through our client. This will not control how other applications try to locate SLP services.
Q7: How much data is required in the NDS SLP database to store each registered name, attribute, etc.? Given that attributes are variable in size, suppose the data is based on the sizes of the typical attributes present for answers #1 and #3.
A7: The "NDS SLP database" is directly stored in Novell's NDS database. All SLP Services are NDS objects. The SLP DA will also maintain a cache/table of the objects in Scope Units it services, but will update this when it is notified of a change in an SLP object via NDS synchronization. The size of the object varies between services. Practically all Novell SLP objects are less than 1K in size (most significantly less). Other third-party SLP Services could be larger or smaller, depending on the typ and size of the attributes they hold.
Q8: Assuming no changes occur to a DA's database, how much traffic would be required to verify that two DA's are synchronized?
A8: DAs do not have some kind of special new synchronization method - they piggy-back on top of NDS synchronization. As long as both DAs have a replica of the Scope Unit object, then they monitor changes there and automatically apply them to the DA cache/table. Also, the SLP Service objects are designed to minimize NDS traffic. Typically only the Default Lifetime attribute is synched (SAs default to re-register every hour, but this could be increased). Even if the server goes down and de-registers the SLP Service, it does not delete the object but sets a flag on the SLP Service Object to mark it as invalid. The SLP DAs in the tree remove the entry from their cache/table, but it remains in NDS for the time being. The server would have to be down for 1-2 days before the object would be deleted from the tree during the nightly DA purge operation (only deleted if the timestamp on the Invalid flag is older than 24 hours).
Q9: To populate DA's at remote sites (over WAN links) with the same SLP database, would each site need to hold a replica of the container that contains the SLP database entries?
A9: It is recommended very strongly that each DA hold a replica of the Scope Units it services. Otherwise, by default all SLP entries will expire one hour after the Purge operation (the net effect is that the DA does not hold any services at all). There are ways to change the setting so this is not true, but we basically do not support using a DA without a replica of the Scope Units it is assigned to use.
Q10: Is the SLP DA database indexed so that the DA response time to a client SLP query is directly proportional to the number of entries?
A10: The SLP DA cache is indexed. According to the empirical data gathered from Sniffer/LANalyzer traces, the DA replies immediately to all requests, even in large SLP environments. Remember that most SLP DA cache/tables will typically hold less than 1000 entries. A simple indexed table design could quickly sort and search this information. Server response times to SLP queries is still subject to the load on the server and other factors.
Q11: What other documents can I read to better understand SLP and know how to effectively implement it?
A11: Check these out:
- SLP Terms and Configuration Reference
- Configuring a LAN/WAN Infrastructure for SLP
- Configuring SLP for a NetWare Server
- SLP Design and Implementation Guidelines
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com