|
Introduction
This document was written to provide Network Administrators some basic guidelines on how to deploy SLP in their environment. Every corporate environment is different and often the design that works well in one environment may not work well in another. This document is intended to teach what factors to research and take into account when desiging and implementing SLP in an environment.
Most people find it easier to remember names of servers and services instead of their addresses. For this reason Name Resolution protocols were created that allow people to type in the name of a server/service and have it "resolve" the name to the address. The computer actually then communicates to the address of the server/service. SLP is another IP based Name Resolution protocol similar in function to DNS, but is more flexible in that it also has the ability to search based upon information other than server/service names (such as service type, or any other field the SLP service holds).
Novell has based its implementation of Service Location Protocol on the published RFC 2165 standard. Novell's SLP allows clients and servers to locate a server/service's address based upon a name or other search criteria.
SLP Scoping
Determining whether to configure multiple Scopes for your SLP environment is one of the first decisions that Administrators must make. If your company is using SLP version 2.0 or above (NetWare 6/6.5), then you would almost always use a single Scope to store services for your environment. Using a single SLP Scope is the strong recommendation of Novell Support. The reason for this is that eDirectory will use SLP to lookup the IP addresses of server names in their replica ring. If they cannot resolve the server name to an IP address, it will cause replica sync issues. All servers which hold a replica of a specific eDirectory partition must also have their ndap.novell and bindery.novell SLP Services registered to a common SLP Scope.
The only reason you may even want to consider using multiple scopes is if you want to prevent users in one region from being able to browse the network and see the servers in another region. Even if a user can see a server on a network browse list, they will only be allowed to open the file system or other resources on the server if they have been given rights, so preventing them from being able to see the server(s) on a browse list is a questionable improvement to security. If your company is using SLP version 1.0 (NetWare 5.1 or NetWare 5.0) ND you have more than 500 NCP servers in your NDS Tree or expect to have more than 500 NCP Servers in your NDS Tree before upgrading to SLP v2.0, then you must use multiple scoping to prevent a limitation of the SLP v1.0 RFC (See TID 10024584 for more details on this limitation). However, this limitation is NOT present in SLP v2.0, so it is recommended to use NetWare 6.0/6.5 for your SLPDAs.
An NCP Server can be a NetWare Server (with or without a replica), any operating system running eDirectory (i.e. NT, Windows 2000, Linux, Solaris, etc...), or any other future product that creates an NCP Server object in the tree and/or begins registering SLP Services (i.e. network attached storage device).
The exact number of NCP Servers required to encounter the 64K limit problem varies depending on the combined length of each SLP service and its attributes. Once the aggregate of the services of a particular type (i.e. all of the ndap.novell services in the Scope) is greater than 64Kb, then you may begin to have problems with being able to see the complete list of services when querying or browsing the SLP service network.
If you have less than 500 NCP Servers in your NDS Tree and do not anticipate that changing before upgrading to SLP v2.0, it is suggested you store all of your services in a single named Scope. Here are some benefits of using a named scope:
1. SLP v2.0 will not support the UNSCOPED Scope and using a named scope now will save you headaches upgrading to SLP v2.0 later on.
2. You can not have a DA service both the UNSCOPED Scope and a Named Scope at the same time. However, a DA can service multiple Named Scopes at the same time.
3. You can not exclusively control the UNSCOPED Scope in an environment where different departments/companies wish to maintain separate SLP DA Scope databases.
Here are some reasons that you may NOT want to use a named scope:
1. Configuring SLP with UNSCOPED is simpler. You simply load SLPDA on the chosen server, and accept the default configuration. You would then add references to the SLP.CFG file of every other server in the tree to point to the IP address of the DA and issue a SET SLP RESET=ON on each server.
2. If you choose a named scope, you have to modify the scope list on each server, which requires a cold boot.
Novell recommends a Named Scope for any new SLP deployments. If your environment currently has an UNSCOPED scope, you will want to plan migrating to a Named Scope in the future to avoid problems as you move to SLP v2.0. As you are planning on migrating from an UNSCOPED Scope to a Named Scope, review TID 10059981 for the required steps.
NOTE: Be aware that when you change the SET SCOPE LIST parameter, you must reboot the server for the changes to take effect (the dependency list for SLP is too great to safely consider trying to unload each dependent NLM and reload it).
General Scoping Suggestions:
Case 1: Single Corporate Scope (SLP v2.0 or SLP v1.0 with less than 500 NCP Servers)
Use a single Global Scope. Use a naming convention that incorporates the company name such as NOV-SLP-GLOBAL or [my short company name]SLP-GLOBAL. Avoid special characters, such as / , . ! @ # $ % ^ & * ( ) = + _
Case 2: Multi Corporate Scope (Over 500 NCP Servers)
Divide the NCP Servers into logical "Regional" groupings that are each less than 500 NCP Servers (allow for any anticipated growth here).
Create a Regional Scope that will hold ALL SLP Service entries for NCP Servers in that logical "Regional" grouping (but not the SLP Service entries for NCP Servers in other Regions). Use a naming convention that incorporates the company name and region such as NOVSLP-AMER (Americas - North and South).
Create a Global Scope that will hold all ndap.novell and bindery.novell entries. The reason why it is recommended to just store these two SLP services is to support NDS replica synchronization. For any given NDS Partition, the SLP Scope must hold the ndap.novell and bindery.novell SLP Service entry for each NCP Server that holds an NDS replica of the NDS Partition, otherwise there may be synchronization errors or severe slowness when an NCP Server attempts to locate another NCP Server that is in the same replica ring. Use a naming convention that incorporates the company name such as NOVSLP-GLOBAL..
SLP Directory Agent (DA) quantity/server placement
It is recommended that every environment implement Directory Agents to replace the inefficient SA Multicasting method for discovering SLP Services. The only potential exceptions would be environments that have both less than 5 NCP Servers and do not have any routers between User Workstations and Servers (entire environment is on one switched segment). In these rare cases, using SA Multicasting is roughly as efficient as DA Unicasting.
DAs should be placed on the sites where the highest population of users and other NCP Servers are. It is NOT necessary or recommended to place a DA at every site. The Network Administrator must balance the WAN link traffic savings of SLP traffic with the WAN link traffic costs of synchronizing an NDS replica of the SLP Scope Unit on a Local NCP Server at the remote site. Depending on server resources, a typical dedicated DA server can serve between 2,000 to 25,000 users. In some environments it will make sense to take a resource-rich, lightly-loaded NDS replica server and make it a DA server. In other environments where the sheer amount of users and servers generate many more SLP requests, it will be best to dedicate an NCP Server to serve SLP DA requests.
NOTE:
SLP requests do NOT make NCP connections to the SLP DA server, since they use port 427 instead of port 524. So a Network Administrator does not need to be concerned with ensuring the DA server has a license for each user who will be querying it for SLP information (however if you are mapping a drive to the DA server or other operation, you will still need a licensed connection for this).
It is recommended that the number of DAs servicing an SLP Scope should at least be 2 to provide fault tolerance. If you have enough users and/or infrastucture reasons, you should have approximately one additional DA for each 10,000 - 20,000 users that query that SLP Scope. If you have a large environment, you should run the SLP DA service on a dedicated server. A good quick litmus test is whether you are running dedicated NDS replica servers. If you are, then you should consider also running dedicated SLP DA servers.
Example 1 (Large Corporation):
400 NCP Servers
100,000 users - 50,000 at the NY site, 30,000 at the CA site, 15,000 at the FL site, and 5000 other scattered in small branch offices
T3 or faster links between main sites and 128K/T1 for smaller branch offices
Suggested DA Placement:
3 Dedicated DAs in NY
2 Dedicated DAs in CA
1 Dedicated DA in FL
Example 2 (Smaller Company):
30 NCP Servers (20 at KS, 10 at MO)
800 users - 400 at the KS main site, 150 at MO site, 250 at scattered small branch offices (typically 5-10 users at each site using a 56K or faster connection to connect to the main sites)
Suggested DA Placement:
1 DA in KS
1 DA in MO
In this example the DAs do not need to be dedicated since the number or users/servers they are servicing is not that great. However, administrators should ensure that they have adequate resources for the tasks they perform (check processor utilization, free cache buffers, concurrent disk write/reads, and other statistics during peak network use times like morning logins to see if the server has sufficient resources to handle the load placed on it). The Network administor may also choose to add a second non-dedicated DA in KS to ensure there are 3 replicas of the SLP Scope unit (or just may add a replica to a NDS replica server that is not running the SLPDA service), but is not required by the number of users who will be accessing the DA service.
The actual number of DAs may vary depending on the server resources (memory, CPU, LAN card speed/type, infrastructure speed to server, etc..) and what other services it is offering that consume resources. In these examples and throughout this document, it is assumed that the NetWare Servers are using NDS 8.x or higher. If your environment is using NDS 7.x, you should consider upgrading to NDS 8.x to take advantage of the greatly improved scalability and performance.
NOTE:
If an NCP Server is running SLPDA.NLM, it MUST hold a replica of the Scope Unit partitions it services. Novell does not support an SLP implementation where a server running SLPDA does not hold real writeable replicas (R/W or M) of any Scope Units the DA is configured to serve.
.
SLP Modes
SLP can be configured to use one or both of the following modes to communicate:
Multicast
This is the way any new NetWare 5.x and 6.x is configured to work. If there is no Directory Agent (DA) "discovered" over DHCP, the SYS:ETC\SLP.CFG file, or a multicast to 224.0.1.35, then all queries for SLP services go to the multicast address 224.0.1.22. The requested service must be able to "see" the multicast to answer. There is no collaboration between Servers about who hosts what services, each is an island of information in the sense they only know what services they host. In large environments, this becomes especially inefficient since routers may need to forward this multicast between any client and server subnet on the network and can cause multicast storms.
Directory Agent
This is the preferred method to configure NetWare 5.x, 6.x and eDirectory servers to work. One or more servers are strategically designated as Directory Agent servers. Other servers in the environment are configured to register their services to these DA servers, who then can become a repository of service information for either the entire network or a portion of the network (depending on factors such as Scopes serviced and which servers are configured to register to them). Clients and servers can then query the DAs with a unicast request (as opposed to multicast) and receive answers back quickly (instead of waiting for timeout settings to be exceeded with multicast requests).
NDS Location of SLP Objects
SLP only creates 3 types of objects in NDS; the DA Server, SLP Scope Unit, and SLP Service objects.
DA Server Object
It is suggested that the DA Server object be created in one of 2 locations:
1. The same partition as the SLP Scope Unit (discussed later). This method does ensure that the DA Server has a replica of its own DA Server object, but this object is only read during the initialization of SLPDA.NLM (and possibly during the daily Purge operation) and so this does not provide any measurable reduction in server utilization or bandwidth usage.
2. The same context as its corresponding NCP Server object. There is a 1:1 relationship/assignment between a DA Server object and an NCP Server object, so keeping them together can ease administration.
SLP Scope Unit Object
This NDS object is a container that holds all of the SLP Service registrations. When a DA receives a new registration from Server/Service it will create an NDS SLP Service object in the SLP Scope Unit it was configured to use (depending on the Scope that the service registered in). In either the Single Scope or Multi-Scoped scenario, it is recommended that the Scope Unit be partitioned off from the rest of the tree (a separate partition boundary). It is suggested that it be placed just below the highest common parent container that the NCP Server NDS objects share (often just below the O=[company name] container). Since the Scope Unit container partition may be held by servers dedicated to SLP Service queries (i.e. ALL servers running SLPDA that service that scope), partitioning it off from the rest of the tree prevents synchronization of other non-SLP object changes (since these servers often do not participate in other NDS partitions). It also prevents SLP Service object synchronization from affecting other partitions that hold non-SLP objects.
Example Tree:
O=Novell
OU=AMERICAS
OU=UT
...200 NCP Server objects...
OU=CA
...75 NCP Server objects...
OU=LA
...75 NCP Server objects...
OU=EUROPE
OU=PAC
...50 NCP Server objects...
OU=GER
...100 NCP Server objects...
OU=FRA
...50 NCP Server objects...
Given this example, a good design would be to create three Scopes (one Global and two Regional) and their corresponding Scope Unit container object in NDS as listed below:
O=Novell
OU=NOVSLP-GLOBAL-SU
...Global Scope SLP Services...
OU=AMERICAS
OU=NOVSLP-AMER-SU
...Americas Regional Scope SLP Services...
OU=EUROPE
OU=NOVSLP-EURO-SU
...EUROPE Regional Scope SLP Services...
SLP Service Object
These can only be created in SLP Scope Unit containers. The adminstrator can only control where these are created based upon what DAs and Scopes the Server/Services are configured to register to. If a DA receives a valid registration for a Scope it supports, it will create an NDS SLP Service object for it in the associated SLP Scope Unit. An SLP Service may also be created in multiple Scope Units if either Server/Service registers it to multiple DAs and Scopes or if a single DA receives a registration instructing it to place it in multiple Scopes (i.e. bindery.novell would exist in both a Global and Regional Scope if using the Multi-Scope model).
NOTE: Newer versions of SLP can use an option to not store SLP Service information in NDS (only kept in DA cache). If this option were enabled, then SLP Service objects would not be created after a Server/Service successfully registers with a DA.
.
Server Configuration
Suggested SET Parameter Tuning
A complete list of possible SLP SET parameters is available in TID10027163. This document will only list the settings that Novell suggests setting differently from their default values. All settings listed below should be made to EVERY NCP Server capable of making SLP Service queries or registrations, not just to the servers running SLPDA.NLM.
SET NCP over UDP = ON
While setting this off would reduce the size of SLP Service entries (since it must list any IPX, SPX, UDP, or TCP addresses that the server running the service may be contacted on), there have been too many reported side effects in customer environments who set this to OFF.
Reported Side Effect 1: This setting will cause a problem connecting to a server via IP with clients older than 3.21 (WIN 95/98) or 4.71 (WinNT). Make sure that al the clients connecting to the server have been updated.
Reported Side Effect 2: This setting can also cause a problem with Timesync IF some servers have it ON and some have it OFF. If all NetWare 5.x servers are set to OFF, Timesync will communicate just fine. See TID 10060412 for details on this).
Reported Side Effect 3: Can cause Catalog Services to fail to locate NDS replica servers and cause a 35323 error. Catalog Services only requests NDS Replica server referrals for the UDP or IPX transport (NOT TCP). See Solution NOVL52452 for details on this issue.
Customers who still wish to set this to OFF, should carefully test this before implementing in their Production environment.
SET SLP CACHE TIMEOUT = 1800
The default for this 120 seconds. Increasing this to 1800 seconds (30 minutes) will greatly improve the chance that an NDS replica server will not need to go back to the DA for information during user logins or other common name-to-address operations. Increasing this value does also increase the time that the server will think an NCP Server offering that SLP Service is available when it it may actually be down. For example, if a NetWare Server experienced an unrecoverable abend, it could still be cached by other NetWare Servers for up to the Service Lifetime + the Cache Timeout period, causing users to be referred to the downed server during login when it is really unavailable.
SET SLP ENABLE UA MULTICAST = ON/OFF
This is a parameter Adminstrators must evaluate for themselves. Disabling it can reduce some Multicast packets from the network, but will make the environment completely dependent on the DA servers being available at all times. If they become unavailable, the NetWare Servers with this option set to OFF, will not be able to locate services via SLP (though they will be able to still find services through the IPX Name Spaces, if it is available). If IPX is loaded and bound on all servers, it is best to set it to OFF. If IPX is not loaded it is most likely best to set this to ON.
SET SLP REGISTER NWSERVER = OFF
This parameter instructs the Server to register an nwserver.novell SLP Service type for this NetWare Server. This SLP Service was designed to list any service that might potentially be available and eliminate the need for a separate service entry (and NDS object) for every service the server offers. For example, the rconsole.novell, bindery.novell, srs,novell, rms.novell, and other 3rd party services would all be detectable from this single SLP Service. However, while the service does list unique information for each Service as it registers for a UDP/TCP port (and other types of resources that indicate the service is "listening" for requests), no applications have been rewritten to take advantage of this at the time of the initial writing of this document. Because of this, it is suggested that this setting be disabled until applications begin utilizing this setting, in order to reduce the size of the DA database.
SET SLP SCOPE LIST = Scope1,Scope2,Scope3
This parameter needs to contain the Scope names that this server should register ALL of its services to. If using a Single Scope method, this would be the SLPNOV-GLOBAL scope. If using the Mult-Scope method, this could be SLPNOV-AMER scope. For the Multi-Scope method, you do NOT list the SLPNOV-GLOBAL in the SLP SCOPE LIST since you are not registering ALL services to the SLPNOV-GLOBAL Scope. You must use a REGISTER TYPE command to force selected SLP Service to the SLPNOV-GLOBAL Scope.
SET SLP DA DISCOVERY OPTIONS = 15
This parameter controls how the Server Agents (SA) and User Agents (UA) are allowed to locate/discover DAs on the network. This value is a binary value and with a value of 13 has the following bits turned on/off:
Dec Binary
---- ---------
1 = 0001 = ENABLED - Dynamic Discovery via multicast address 224.0.1.35
2 = 0010 = DISABLED - Dynamic Discovery via DHCP Inform packet for DHCP Options 78 and 79 (DA server address and Scope)
4 = 0100 = ENABLED - Static discovery using the SYS:ETC\SLP.CFG file; will look for DA IPV4 lines
8 = 1000 = ENABLED - Disable of multicast dynamic discovery of DAs as long as at least one statically discovered DA or DHCP discovered DA is "up"
NOTE: Initially it was recommended that DHCP discovery be disabled due to a problem where not all non-Novell DHCP Servers properly format a reply to a DHCP Inform request for DHCP Options 78 and 79. In some cases, when it is improperly formatted, it can cause a NetWare server to abend as it attempt to process that information. However, Novell has added robustness to the SLPDA.NLM so that it will not abend on bad data in the DHCP Option 78/79 reply. Customers should apply an SLPDA.NLM dated 10 Dec 2001 or newer (version 1.07e) to get this fixed SLPDA.NLM.
All customer environments that Novell has investigated received the recommendation to enable the Static Discovery method (4) and use DA IPV4 entries in the SLP.CFG file. It is suggested that the option for DHCP discovery (2) be enabled in environments where the administrator has good control of the DHCP servers attached to the network (rogue DHCP servers could have the NetWare servers registering their SLP Services with an invalid DA server). It is also suggested to leave Multicast Dynamic Discovery method on (1) with the option to disable it when a statically discovered DA is available/up (8). This prevents the NetWare Server from multicasting via 224.0.1.35 so long as the DA servers listed in the SLP.CFG are available and allows the NetWare Server to multicast to try to find an available DA if the DAs listed in the SLP.CFG ever go down or otherwise become unavailable. In environments where administrators have disabled multicasting across all routers (LAN and WAN) AND the DA servers are always in separate multicast domains from the NetWare Servers, then enabling multicast dynamic discovery will accomplish nothing and can remain disabled (set to just 4 or 6 to allow only Static SLP.CFG DA addresses and possibly the DHCP discovered addresses).
SLP.CFG Parameters
The SLP.CFG file is located in the SYS:ETC directory of each NetWare server. It contains the DA and REGISTER TYPE commands for the server. Every server running the SLP.NLM and SLPTCP.NLM should have an SLP.CFG file to define the Static DAs and any REGISTER TYPE commands, NOT just the servers running SLPDA.NLM.
It is in the SLP.CFG a Network Administrator can define the Static Directory Agents that SLP Server Agent (SA) will register it's services with. This can be done with either an IP address (IP v.4) or with a DNS name (must have a newer version of SLP for this to work correctly). While DNS names will work, in order to remove dependencies on another name space and for better performance Novell recommends using IP addresses whenever possible.
Example:
DA IPV4, 123.123.123.123
DA IPV4, SLPDA1.Region.Company.Com
The REGISTER TYPE commands is how SLP can "filter" SLP Services between different Scopes. The SET SCOPE LIST parameter is used to define where ALL SLP Services should be registered to, the REGISTER TYPE command is used to set the Exceptions to the SET SCOPE LIST rule. If an SLP Service is filtered to a different Scope than what is contained in the SET SCOPE LIST command using the REGISTER TYPE command, it will no longer register to any scope, except the one(s) defined in the REGISTER TYPE command. The most common use of the REGISTER TYPE command is when the Multi-Scope method is being used to register the ndap.novell and bindery.novell services into both the Regional and Global Scopes.
Example:
SET SLP SCOPE LIST = NOVSLP-EURO
REGISTER TYPE "ndap.novell" to SCOPE "NOVSLP-EURO,NOVSLP-GLOBAL"
REGISTER TYPE "bindery.novell" to SCOP "NOVSLP-EURO,NOVSLP-GLOBAL"
If the above SET and REGISTER TYPE commands were set at the appropriate places (SET at the Console Prompt, REGISTER TYPE in the SLP.CFG), then the Server Agent would register the ndap.novell and bindery.novell services to both the NOVSLP-EURO and NOVSLP-GLOBAL Scopes (via any DAs discovered to service these Scopes). Any other SLP Services that this server offered would only be registered in the NOVSLP-EURO Scope (i.e. rconsole.novell or srs.novell). This is because all services not controlled by a REGISTER TYPE command will be registered in Scopes listed in the SET SCOPE LIST setting..
Infrastructure Configuration
SLP Ports
The SLP Service will use TCP and UDP port 427. So Network Administrators must enable this port across any router/firewall where SLP will be used to either query a DA or register a service. In addition to these ports, SLP may also use two multicast addresses (224.0.1.22 for SA queries, and 224.0.1.35 for DA queries), depending on how the NCP Servers and user workstations have been configured. Network Administrators may choose to enable these multicast address on some or all of their routers. See the "Multicast Domain" section below for more information on this
DHCP Options
SLP uses DHCP option 78 and 79 to provide a list of DAs and Scopes that clients and servers should use. Administrators that already use DHCP to assign IP addresses to user workstations should also configure each subnet with the 2 closest DAs to the users and any Scopes they should be querying for.
NOTE: The NetWare Server will also generate a DHCPINFORM request packet just as a Novell Client will to "discover" the DA Servers and Scopes available. However, the NetWare Server is looking for a specific format for the DA Address (option 78) that the DHCP server must use and Novell DHCP Server application is one of the few DHCP Servers that can reply with the correct format.
Multicast Domain
SLP Uses multicasts as part of the attempt to dynamically discover either a DA or a SA for a specific service. Multicasts are not the same as broadcasts, they CAN cross routers if the router has been configured to allow it. Many companies have enabled multicast across intra-site routers (routers that only connect subnets that are at the same physical site and have fast bandwidth connectivity between them) and then disable multicast across inter-site routers (routers that connect different sites and have slower bandwidth connectivity between them). In some cases a single site must split the infrastructure up into different Multicast Domains to prevent too many multicast from overloading the network (i.e. a company having 50,000 user workstations at a single site, should not leave multicast enabled across all intra-site routers or there will be LAN overload if they all start multicasting at once). Both the NCP Servers and Novell Clients can be configured to not use Multicast except when they can no longer contact any of their discovered DAs. Under these circumstances it would be desirable to keep multicast enabled across selected routers to ensure that it would be a viable fall-back method in the event that something should happen to the NCP servers running the DA service (or the connectivity between the user workstation and DA server).
Client Configuration
This document does assume that the client has either been installed with support for the IP Protocol ("IP and IPX" or "IP Only" during a custom install). The default is to install with IP and IPX support.
Scope List
This configures the static scopes that this machine will either query for services in or register services in (most user workstations do not register SLP services). Some administrators will set this key to their scope name, especially if they are using a Single Scope model. Other administrators choose to leave this empty and rely on DHCP to push the supported Scope list down. If administrators have a Multi-Scoped environment and have users that roam between Regional Scopes, it would be best to leave this empty and rely on DHCP (so that the workstation will be set with the correct Regional/Global Scope for the local subnet they are currently on). Otherwise it is a judgement call by the administrator, though having ZENworks to deploy this setting makes it much more appealing to set it to correct Global/Regional Scope. If a Static Scope is set, it is preferred above any dynamically discovered Scopes (DHCP or multicast discovered).
Static checkbox by Scope List
Most administrator will want to leave this unchecked (default) to allow Scopes discovered via DHCP and Multicast to be queried. Otherwise, the Client User Agent will only query DAs for the Scopes entered in the Scope List.
Directory Agent List
Same concept as the Scope List. This is a list of either IP addresses or DNS names for NCP Servers running the SLP DA Service (SLPDA.NLM on NetWare servers). It is suggested that every client workstation be informed of the 2 closest DAs via either this Static entry, DHCP, or Multicasting. As with the Scope List, some administrators choose to set this statically, while other choose to rely on DHCP to inform the client of the DA servers it should communicate with.
Static checkbox by Directory Agent List
Most administrators will want to leave this unchecked (default) to allow the SLP User Agent to query DAs discovered by dynamic methods (DHCP or Multicast to 224.0.1.35). If this option is checked, you MUST put an IP or DNS name(s) in that points to valid and working DA servers, otherwise the SLP Name Space Resolver will be unable to resolve SLP names to IP addresses.
SLP Cache Replies
It is suggested that this be raised from the default of 1 minute to 15 minutes to accomodate even the longest of user logins along with any post-login execution of NAL objects.
All the other settings should remain at their defaults for the majority of customer environments. Review TID 10014466 for a complete list of Client settings and their implications to SLP behavior.
Recommended documents on SLP
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
Configuring SLP for a NetWare Server
SLP Design and Implementation Guidelines
|
