Slow Client Login in SLP environment with no DA configured

(Last modified: 23Jan2003)

This document (10026522) is provided subject to the disclaimer at the end of this document.

goal

Slow Client Login in SLP environment with DA configured

fact

Novell NetWare 5.1

Novell NetWare 5.0

Novell Client 4.7 for Windows NT/2000

Novell Client 4.6 SP2 for Windows NT

Novell Client 4.51 for Windows NT

Novell Client 4.5 for Windows NT

Novell Client 3.2 for Windows 95/98

Novell Client 3.1 SP1 for Windows 95/98

Novell Client 3.1 for Windows 95/98

Novell Client 3.02 for Windows 95/98

Novell Client 3.01 for Windows 95/98

Novell Client 3.0 for Windows 95/98

symptom

Slow Client login to NetWare 5 servers

5 to 30 minute login times

cause

The NetWare 5 version of Novell's NOS introduces the native support of the TCP/IP protocol for NCP (includes login functions). This support of TCP/IP also included the introduction of a new Name Space Provider (NSP), Service Location Protocol (SLP). The default installation of NetWare 5 will load the SLP Service Agent (SA) and User Agent (UA), but include no Directory Agent (DA) configuration. The NDS service was written to hand service name requests to Winsock, which defaults to locating service names in SLP. If no DA is configured/discovered for the server's UA/SA, then it will multicast to the 224.0.1.22 address to try to locate the requested service. There can be long timeouts periods while the UA/SA waits to ensure it has received all replies to it's multicast request. Also, the servers who contain the requested service may not be reachable via multicast (for example the target and source are across a router that is NOT configured to forward multicast--default state for most router vendors). Depending on the request, this may even return inaccurate information to the client, leading to further login delays.

The following example illustrates a common occurrence of this problem:

User's NDS Object = CN=joebob.OU=DeptA.OU=Division1.O=Company
Partition root for user = OU=DeptA.OU=Division1.O=Company
Servers that hold a replica of the OU=DeptA.OU=Division1.O=Company Partition = FS1, FS3, FS4

Servers will generate an SLP ndap.novell service for each replica they hold a Master or Read/Write replica of. So the FS1, FS3, and FS4 servers should have an SLP service of ndap.novell///DeptA.Division1.Company.Tree_Name, but FS2 will not have an SLP service for ndap.novell///DeptA.Division1.Company.Tree_Name.

If the joebob user connects to FS2 for his initial connection (prior to providing any user name or password), then he will send a Resolve Name request for joebob.DeptA.Division1.Company to FS2. The NDS service on FS2 will hand this to Winsock, who hands it to SLP. If no DA is configured, then FS2 will multicast to 224.0.1.22 for the ndap.novell///DeptA.Division1.Company.Tree_Name SLP service. If FS1, FS3, and FS4 are all across a router from FS2 that is NOT forwarding multicast, then FS2 will NOT receive a reply to this request. FS2 will then assume that the DeptA must not be the partition root and will then send a request for ndap.novell///Division1.Company.Tree_Name (the parent container). If the Division1 container is part of the partition that has a partition root at O=Company, then there will be no response for this either. FS2 will then assume that Division1 is also not the partition root and will then send a request for ndap.novell///Company.Tree_Name. Supposing that FS2 does a replica of this, then it will respond to itself (internally, not seen as a packet on the wire) and also wait to see if anyone else responds to this request.

At this point SLP hands back the address list (UDP, TCP, and IPX) to Winsock for FS2, who then hands it to NDS. NDS then sends back the address list to the User's workstation as a referral list. The User's workstation will then try to authenticate to FS2 as the user. This will fail since the server does not hold a real replica of the user object.

This is the extreme example of what can happen if no DA is configured. Typically the server's can multicast to find replica information, but the timeout for multicast is what causes the slow login.

fix

The only way to avoid this problem and maintain support for SLP is to implement an SLP Directory Agent. See the following TIDs for information about SLP, including SLP DA implementation guidelines:

What is SLP, Service Location Protocol
Frequently Asked Questions about SLP
SLP Terms and Configuration Reference
Configuring a LAN/WAN Infrastructure for SLP
Configuring SLP for a NetWare Client [no longer available]
Configuring SLP for a NetWare Server
SLP Design and Implementation Guidelines

document

Document Title:	Slow Client Login in SLP environment with no DA configured
Document ID:	10026522
Solution ID:	1.0.55165364.2534294
Creation Date:	09Feb2000
Modified Date:	23Jan2003
Novell Product Class:	NetWare

disclaimer

The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.