The following sections provide information and tasks for configuring SLP agents and processes.Configuring SLP Properties Modifying DA Advertising and Discovery Frequency Accommodating Different Network Media, Topologies, or Configurations Modifying Timeouts on SLP Discovery Requests Deploying Scopes Deploying DAs SLP and Multihoming SLP configuration properties control network interactions, SLP agent characteristics, status, and logging. In most situations, the default configuration of these properties requires no modification. However, you can use the procedures in this chapter when the network medium or topology changes and to achieve the following goals:Compensate for network latencies Reduce congestion on the network Add agents or reassign IP addresses Activate SLP logging You can edit the SLP configuration file, /etc/inet/slp.conf, to perform operations such as those shown in the following table.Operation Description Specify whether slpd should act as a DA server. SA server is the default. Set the net.slpisDA property to True. Set timing for DA multicast messages. Set the net.slp.DAHeartBeat property to control how often a DA multicasts an unsolicited DA advertisement. Enable DA logging to monitor network traffic. Set the net.slp.traceDATraffic property to True. The /etc/inet/slp.conf file defines and activates all SLP activity each time you restart the SLP daemon. The configuration file consists of the following elements: Configuration properties Comment lines and notations All of the basic SLP properties, such as net.slp.isDA and net.slp.DAHeartBeat, are named in the following format.net.slp.<keyword>SLP behavior is defined by the value of a property or a combination of properties in the slp.conf file. Properties are structured as key-value pairs in the SLP configuration file. As shown in the following example, a key-value pair consists of a property name and an associated setting.<property name>=<value>The key for each property is the property name. The value sets the numeric (distance or time), true/false state, or string value parameters for the property. Property values consist of one of the following data types:True/False setting (Boolean) Integers List of integers Strings List of strings If the value defined is not allowed, the default value for that property name is used. In addition, an error message is logged using syslog. You can add comments to the slp.conf file that describe the nature and function of the line. Comment lines are optional in the file, but can be useful for administration. Settings in the configuration file are case insensitive. For more information, refer to: Guttman, Erik, James Kempf, and Charles Perkins, “Service Templates and service: scheme,” RFC 2609 from the Internet Engineering Task Force (IETF). [http://www.ietf.org/rfc/rfc2609.txt] Use this procedure to change the property settings in your SLP configuration file. SLP– enabled client or service software also can alter the SLP configuration by using the SLP API. This API is documented in “An API for Service Location,” RFC 2614 from the Internet Engineering Task Force (IETF). [http://www.ietf.org/rfc/rfc2614.txt] &rolestepA;Stop slpd and all SLP activity on the host.# svcadm disable network/slp Back up the default /etc/inet/slp.conf file before you change the configuration settings. Edit the property settings in the /etc/inet/slp.conf file as necessary. Refer to Configuration Properties for general information about the SLP property settings. See the sections that follow this procedure for examples of different scenarios in which you might change the slp.conf properties. See slp.conf4. Save your changes and close the file. Restart slpd to activate your changes.# svcadm enable network/slpThe SLP daemon obtains information from the configuration file when you stop or start slpd. You can change the SA server default to enable slpd to operate as a DA server by setting the net.slp.isDA property to True in the slpd.conf file.net.slp.isDA=TrueIn each area, various properties control different aspects of the configuration. The following sections describe different scenarios in which you might change the default property settings that are used in SLP configuration. In situations such as the following, you can modify properties that control the timing of DA advertisements and discovery requests.When you want the SA or UA to obtain DA configuration information statically from the net.slp.DAAddresses property in the slp.conf file, you can disable DA discovery. When the network is subject to recurrent partitioning, you can change the frequency of passive advertisements and active discovery. If UA and SA clients access DAs on the other side of a dial-up connection, you can decrease the DA heartbeat frequency and the active discovery interval to reduce the number of times a dial-up line is activated. If network congestion is high, you can limit multicasting. The procedures in this section explain how to modify the following properties.Property Description net.slp.passiveDADetection Boolean that specifies whether slpd listens for unsolicited DA advertisements net.slp.DAActiveDiscoveryInterval Value that specifies how often slpd performs active DA discovery for a new DA net.slp.DAHeartBeat Value that specifies how often a DA multicasts an unsolicited DA advertisement Sometimes you might need to limit UAs and SAs to obtaining DA addresses from the static configuration information in the slp.conf file. In the next procedure, you can modify two properties that cause slpd to obtain DA information exclusively from the net.slp.DAAddresses property. Use the following procedure to change the net.slp.passiveDADetection and the net.slp.DAActiveDiscoveryInterval properties.Use this procedure only on hosts that execute UAs and SAs which are restricted to static configurations. &rolestepA;Stop slpd and all SLP activity on the host.# svcadm disable network/slp Back up the default /etc/inet/slp.conf file before you change the configuration settings. Set the net.slp.passiveDADetection property to False in the slp.conf file to disable passive discovery. This setting causes slpd to ignore unsolicited DA advertisements.net.slp.passiveDADetection=False Set the net.slp.DAActiveDiscoveryInterval to -1 to disable initial and periodic active discovery.net.slp.DAActiveDiscoveryInterval=-1 Save your changes and close the file. Restart slpd to activate your changes.# svcadm enable network/slp If the UAs or SAs are separated from the DA by a dial-up network, you can configure DA discovery to reduce or eliminate the number of discovery requests and DA advertisements. Dial-up networks usually incur a charge when activated. Minimizing extraneous calls can reduce the cost of using the dial-up network.You can disable DA discovery completely with the method that is described in Limiting UAs and SAs to Statically Configured DAs. You can use the following procedure to reduce unsolicited DA advertisements and active discovery by increasing the DA heartbeat period and the active discovery interval. &rolestepA;Stop slpd and all SLP activity on the host.# svcadm disable network/slp Back up the default /etc/inet/slp.conf file before you change the configuration settings. Increase the net.slp.DAHeartbeat property in the slpd.conf file.net.slp.DAHeartbeat=valuevalueA 32-bit integer that sets the number of seconds for the passive DA advertisement heartbeatDefault Value=10800 seconds (3 hours)Range of Values=2000–259200000 seconds For example, you can set the DA heartbeat to approximately 18 hours on a host that is executing a DA:net.slp.DAHeartbeat=65535 Increase the net.slp.DAActiveDiscoveryInterval property in the slpd.conf file:net.slp.DAActiveDiscoveryInterval valuevalueA 32–bit integer that sets the number of seconds for DA active discovery queriesDefault Value=900 seconds (15 minutes)Range of Values=300–10800 seconds For example, you can set the DA active discovery interval to 18 hours on a host that is executing a UA and an SA:net.slp.DAActiveDiscoveryInterval=65535 Save your changes and close the file. Restart slpd to activate your changes.# svcadm enable network/slp SAs are required to register with all DAs that support their scopes. A DA can appear after slpd has performed active discovery. If the DA supports slpd scopes, the SLP daemon registers all advertisements on its host with the DA.One way slpd discovers DAs is by the initial unsolicited advertisement a DA sends when it boots. The SLP daemon uses the periodic unsolicited advertisement (the heartbeat) to determine whether a DA is still active. If the heartbeat fails to appear, the daemon removes the DAs the daemon uses and those the daemon offers to UAs.Finally, when a DA undergoes a controlled shutdown, it transmits a special DA advertisement that informs listening SA services that it will be out of service. The SLP daemon also uses this advertisement to remove inactive DAs from the cache.If your network is subject to frequent partitions and SAs are long-lived, slpd can remove cached DAs during the partitioning if heartbeat advertisements are not received. By decreasing the heartbeat time, you can decrease the delay before a deactivated DA is restored to the cache after the partition is repaired. Use the following procedure to change the net.slp.DAHeartBeat property to decrease the DA heartbeat period.If DA discovery is completely disabled, the net.slp.DAAddresses property must be set in slp.conf on the hosts that are executing UAs and SAs so that they access the correct DA. &rolestepA;Stop slpd and all SLP activity on the host.# svcadm disable network/slp Back up the default /etc/inet/slp.conf file before you change the configuration settings. Decrease the net.slp.DAHeartBeat value to 1 hour (3600 seconds). By default, the DA heartbeat period is set to 3 hours (10800 seconds). net.slp.DAHeartBeat=3600 Save your changes and close the file. Restart slpd to activate your changes.# svcadm enable network/slp If network congestion is high, you can limit the amount of multicast activity. If DAs have not already been deployed in the network, deploying DAs can drastically reduce the amount of SLP-related multicast.However, even after DAs are deployed, multicast is still necessary for DA discovery. You can reduce the amount of multicast necessary for DA discovery by using the method that is described in How to Configure DA Discovery for Dial-up Networks. You can completely eliminate multicast for DA discovery by using the method that is described in Limiting UAs and SAs to Statically Configured DAs. This section describes possible scenarios in which you can change the following properties to tune SLP performance.Property Description net.slp.DAAttributes The minimum refresh interval that a DA accepts for advertisements. net.slp.multicastTTL The time-to-live value that is specified for multicast packets. net.slp.MTU The byte size set for network packets. The size includes IP and TCP or UDP headers. net.slp.isBroadcastOnly The Boolean that is set to indicate if broadcast should be used for DA and non-DA-based service discovery. SAs periodically need to refresh their service advertisements before lifetimes expire. If a DA is handling an extremely heavy load from many UAs and SAs, frequent refreshes can cause the DA to become overloaded. If the DA becomes overloaded, UA requests start to time out and are then dropped. UA request timeouts have many possible causes. Before you assume that DA overload is the problem, use a snoop trace to check the lifetimes of service advertisements that are registered with a service registration. If the lifetimes are short and reregistrations are occurring often, the timeouts are probably the result of frequent reregistrations.A service registration is a reregistration if the FRESH flag is not set. See Chapter 11, SLP (Reference) for more information on service registration messages. Use the following procedure to increase the minimum refresh interval for SAs to reduce reregistrations. &rolestepA;Stop slpd and all SLP activity on the host.# svcadm disable network/slp Back up the default /etc/inet/slp.conf file before you change the configuration settings. Increase the value of the min-refresh-interval attribute of the net.slp.DAAttributes property.The default minimum reregistration period is zero. The zero default allows SAs to reregister at any point. In the following example, the interval is increased to 3600 seconds (one hour).net.slp.DAAttributes(min-refresh-interval=3600) Save your changes and close the file. Restart slpd to activate your changes.# svcadm enable network/slp The multicast time–to-live property (net.slp.multicastTTL) determines the range over which a multicast packet is propagated on your intranet. The multicast TTL is configured by setting the net.slp.multicastTTL property to an integer between 1 and 255. The default value of the multicast TTL is 255, which means, theoretically, that the packet routing is unrestricted. However, a TTL of 255 causes a multicast packet to penetrate the intranet to the border routers on the edge of your administrative domain. Correct configuration of multicast on border routers is required to prevent multicast packets from leaking into the Internet's multicast backbone, or to your ISP.Multicast TTL scoping is similar to standard IP TTL, with the exception that a TTL comparison is made. Each interface on a router that is multicast enabled is assigned a TTL value. When a multicast packet arrives, the router compares the TTL of the packet with the TTL of the interface. If the TTL of the packet is greater than or equal to the TTL of the interface, the packet TTL is reduced by one, as with the standard IP TTL. If the TTL becomes zero, the packet is discarded. When you use TTL scoping for SLP multicasting, your routers must be properly configured to limit packets to a particular subsection of your intranet. Use the following procedure to reset the net.slp.multicastTTL property. &rolestepA;Stop slpd and all SLP activity on the host.# svcadm disable network/slp Back up the default /etc/inet/slp.conf file before you change the configuration settings. Change the net.slp.multicastTTL property in the slpd.conf file:net.slp.multicastTTL=valuevalueA positive integer less than or equal to 255 that defines the multicast TTL You can reduce the range of multicast propagation by reducing the TTL value. If the TTL value is 1, then the packet is restricted to the subnet. If the value is 32, the packet is restricted to the site. Unfortunately, the term site is not defined by RFC 1075, where multicast TTLs are discussed. Values above 32 refer to theoretical routing on the Internet and should not be used. Values below 32 can be used to restrict multicast to a set of accessible subnets, if the routers are properly configured with TTLs. Save your changes and close the file. Restart slpd to activate your changes.# svcadm enable network/slp The default packet size for SLP is 1400 bytes. The size should be sufficient for most local area networks. For wireless networks or wide area networks, you can reduce the packet size to avoid message fragmentation and reduce network traffic. For local area networks that have larger packets, increasing the packet size can improve performance. You can determine whether the packet size needs to be reduced by checking the minimum packet size for your network. If the network medium has a smaller packet size, you can reduce the net.slp.MTU value accordingly.You can increase the packet size if your network medium has larger packets. However, unless the service advertisements from SAs or queries from UAs frequently overflow the default packet size, you should not have to change the net.slp.MTU value. You can use snoop to determine whether UA requests often overflow the default packet size and roll over to use TCP rather than UDP. The net.slp.MTU property measures the complete IP packet size, including the link layer header, the IP header, the UDP or TCP header, and the SLP message. Use the following procedure to change the default packet size by adjusting the net.slp.MTU property. &rolestepA;Stop slpd and all SLP activity on the host.# svcadm disable network/slp Back up the default /etc/inet/slp.conf file before you change the configuration settings. Change the net.slp.MTU property in the slpd.conf file:net.slp.MTU=valuevalueA 16–bit integer that specifies the network packet size, in bytesDefault Value=1400Range of Values=128–8192 Save your changes and close the file. Restart slpd to activate your changes.# svcadm enable network/slp SLP is designed to use multicast for service discovery in the absence of DAs and for DA discovery. If your network does not deploy multicast routing, you can configure SLP to use broadcast by setting the net.slp.isBroadcastOnly property to True.Unlike multicast, broadcast packets do not propagate across subnets by default. For this reason, service discovery without DAs in a non-multicast network works only on a single subnet. In addition, special considerations are required when deploying DAs and scopes on networks in which broadcast is used. A DA on a multihomed host can bridge service discovery between multiple subnets with multicast disabled. See DA Placement and Scope Name Assignment for more information on deploying DAs on multihomed hosts. Use the following procedure to change net.slp.isBroadcastOnly property to True. &rolestepA;Stop slpd and all SLP activity on the host.# svcadm disable network/slp Back up the default /etc/inet/slp.conf file before you change the configuration settings. Change the net.slp.isBroadcastOnly property in the slpd.conf file to True:net.slp.isBroadcastOnly=True Save your changes and close the file. Restart slpd to activate your changes.# svcadm enable network/slp Two situations might require that you change the timeouts for SLP discovery requests:If the SLP agents are separated by multiple subnets, dial-up lines, or other WANs, the network latency can be high enough that the default timeouts are insufficient for a request or registration to be completed. Conversely, if your network is low latency, you can improve performance by decreasing the timeouts. If the network is subject to heavy traffic or a high collision rates, the maximum period that SAs and UAs need to wait before sending a message might be insufficient to assure collision-free transactions. High network latency can cause UAs and SAs to time out before a response returns for requests and registrations. Latency can be a problem if a UA is separated from an SA, or if both a UA and an SA are separated from a DA;either by multiple subnets, a dial-up line, or a WAN. You can determine if latency is a problem by checking whether SLP requests are failing because of timeouts on UA and SA requests and registrations. You can also use the ping command to measure the actual latency.The following table lists configuration properties that control timeouts. You can use the procedures in this section to modify these properties.Property Description net.slp.multicastTimeoutsnet.slp.DADiscoveryTimeoutsnet.slp.datagramTimeouts The properties that control timeouts for repeated multicast and unicast UDP message transmissions before the transmission is abandoned. net.slp.multicastMaximumWait The property that controls the maximum amount of time a multicast message is transmitted before it is abandoned. net.slp.datagramTimeouts The upper bound of a DA timeout that is specified by the sum of values that are listed for this property. A UDP datagram is repeatedly sent to a DA until a response is received or the time-out bound is reached. If frequent timeouts are occurring during multicast service discovery or DA discovery, increase the net.slp.multicastMaximumWait property from the default value of 15000 milliseconds (15 seconds). Increasing the maximum wait period allows more time for requests on high latency networks to be completed. After you change the net.slp.multicastMaximumWait, you should also modify the net.slp.multicastTimeouts and net.slp.DADiscoveryTimeouts. The sum of the timeout values for these properties equals the net.slp.multicastMaximumWait value. Use the following procedure to change the SLP properties that control timeouts. &rolestepA;Stop slpd and all SLP activity on the host.# svcadm disable network/slp Back up the default /etc/inet/slp.conf file before you change the configuration settings. Change the net.slp.multicastMaximumWait property in the slpd.conf file:net.slp.multicastMaximumWait=valuevalueA 32–bit integer that lists the sum of the values that are set for net.slp.multicastTimeouts and net.slp.DADiscoveryTimeoutsDefault Value=15000 milliseconds (15 seconds)Range of Values=1000 to 60000 milliseconds For example, if you determine that multicast requests require 20 seconds (20000 milliseconds), you would adjust the values that are listed for net.slp.multicastTimeouts and the net.slp.DADiscoveryTimeouts properties to equal 20000 milliseconds.net.slp.multicastMaximumWait=20000 net.slp.multicastTimeouts=2000,5000,6000,7000 net.slp.DADiscoveryTimeouts=3000,3000,6000,8000 If necessary, change the net.slp.datagramTimeouts property in the slpd.conf file:net.slp.datagramTimeouts=valuevalueA list of 32–bit integers that specify timeouts, in milliseconds, to implement unicast datagram transmission to DAsDefault=3000,3000,3000 For example, you can increase the datagram timeout to 20000 milliseconds to avoid frequent timeouts.net.slp.datagramTimeouts=2000,5000,6000,7000In high-performance networks, you can reduce the time-out bound for multicast and unicast UDP datagram transmission. When you reduce the time-out bound, you decrease latency that is required to satisfy SLP requests. Save your changes and close the file. Restart slpd to activate your changes.# svcadm enable network/slp In networks with heavy traffic or a high collision rate, communication with a DA might be affected. When collision rates are high, the sending agent must retransmit the UDP datagram. You can determine if retransmission is occurring by using snoop to monitor traffic on a network of hosts that are running slpd as an SA server and a host that is running slpd as a DA. If multiple service registration messages for the same service appear in the snoop trace from the host that is running slpd as an SA server, you might have notice collisions.Collisions can be particularly troubling at boot time. When a DA first starts, it sends unsolicited advertisements and the SAs respond with registrations. SLP requires the SAs to wait for a random amount of time after receiving a DA advertisement before responding. The random-wait bound is uniformly distributed with a maximum value that is controlled by the net.slp.randomWaitBound. The default random-wait bound is 1000 milliseconds (1 second). Use the following procedure to change the net.slp.RandomWaitBound property in the slp.conf file. &rolestepA;Stop slpd and all SLP activity on the host.# svcadm disable network/slp Back up the default /etc/inet/slp.conf file before you change the configuration settings. Change the net.slp.RandomWaitBound property in the slpd.conf file:net.slp.RandomWaitBound=valuevalueThe upper bound for calculating the random-wait time before attempting to contact a DADefault Value=1000 milliseconds (1 second)Range of Values=1000 to 3000 milliseconds For example, you can lengthen the maximum wait to 2000 milliseconds (2 seconds).net.slp.randomWaitBound=2000When you lengthen the random-wait bound, a longer delay in registration occurs. SAs can complete registrations with newly discovered DAs more slowly to avoid collisions and timeouts. If necessary, change the net.slp.datagramTimeouts property in the slpd.conf file:net.slp.datgramTimeouts=valuevalueA list of 32–bit integers that specify timeouts, in milliseconds, to implement unicast datagram transmission to DAsDefault=3000,3000,3000 For example, you can increase the datagram timeout to 20000 milliseconds to avoid frequent timeouts.net.slp.datagramTimeouts=2000,5000,6000,7000In high-performance networks, you can reduce the time-out bound for multicast and unicast UDP datagram transmission. This setting reduces the amount of latency in satisfying SLP requests. Save your changes and close the file. Restart slpd to activate your changes.# svcadm enable network/slp With scopes, you can provision services that depend on the logical, physical, and administrative groupings of users. You can use scopes to administer access to service advertisements.Use the net.slp.useScopes property to create scopes. For example, in the /etc/inet/slp.conf file on a host, add a new scope, called newscope, as shown:net.slp.useScopes=newscopeYour organization might, for example, have an alcove of networked devices,such as printers and fax machines, at the end of the south hall on the second floor of Building 6. These devices could be used by everyone on the second floor, or you might restrict the usage to members of a certain department. Scopes provide a way for you to provision access to the service advertisements for these machines.If the devices are dedicated to a single department, you can create a scope with the department name, for example, mktg. Devices that belong to other departments can be configured with different scope names.In another scenario, the departments might be dispersed. For instance, the mechanical engineering and the CAD/CAM departments might be split between floors 1 and 2. However, you can provide the floor 2 machines for the hosts on both floors by assigning them to the same scope. You can deploy scopes in any manner that operates well with your network and users.UAs that have particular scope are not prevented from actually using services that are advertised in other scopes. Configuring scopes controls only which service advertisements a UA detects. The service is responsible for enforcing any access control restrictions. SLP can function adequately without any scope configuration. In the Solaris operating environment, the default scope for SLP is default. If no scopes are configured, default is the scope of all SLP messages. You can configure scopes in any of the following circumstances.The organizations you support want to restrict service advertisement access to their own members. The physical layout of the organization you support suggests that services in a certain area be accessed by particular users. The service advertisements that are appropriate for specific users to see must be partitioned. An example of the first circumstance was cited in Configuring DA Discovery for Dial-up Networks. An example of the second is a situation in which an organization is spread between two buildings, and you want users in a building to access local services in that building. You can configure users in Building 1 with the B1 scope, while you configure users in Building 2 with the B2 scope. When you modify the net.slp.useScopes property in the slpd.conf file, you configure scopes for all agents on the host. If the host is running any SAs or is acting as a DA, you must configure this property if you want to configure the SAs or DA into scopes other than default. If only UAs are running on the machine and the UAs should discover SAs and DAs supporting scopes other than default, you do not need to configure the property unless you want to restrict the scopes the UAs use. If the property is not configured, UAs can automatically discover available DAs and scopes through slpd. The SLP daemon uses active and passive DA discovery to find DAs, or it uses SA discovery if no DAs are running. Alternatively, if the property is configured, UAs use only the configured scopes and do not discard them.If you decide to configure scopes, you should consider keeping the default scope on the list of configured scopes unless you are sure that all SAs in the network have scopes configured. If any SAs are left unconfigured, UAs with configured scopes are unable to find them. This situation occurs because the unconfigured SAs automatically have scope default, but the UAs have the configured scopes.If you also decide to configure DAs by setting the net.slp.DAAddresses property, be sure that the scopes that are supported by the configured DAs are the same as the scopes that you have configured with the net.slp.useScopes property. If the scopes are different, slpd prints an error message when it is restarted. Use the following procedure to add scope names to the net.slp.useScopes property in the slp.conf file. &rolestepA;Stop slpd and all SLP activity on the host.# svcadm disable network/slp Back up the default /etc/inet/slp.conf file before you change the configuration settings. Change the net.slp.useScopes property in the slpd.conf file:net.slp.useScopes=<scope names>scope namesA list of strings that indicate which scopes a DA or SA is allowed to use when making requests, or which scopes a DA must supportDefault Value=Default for SA and DA/Unassigned for UA Use the following to construct scope names:Any alphanumeric characters, uppercase or lowercase Any punctuation characters (except for: '', \, !, <, =, >, and ~) Spaces that are considered part of the name Non-ASCII charactersYou use a backslash to escape non-ASCII characters. For example, UTF-8 encoding uses 0xc3a9 hex code to represent the letter e with the French aigue accent. If the platform does not support UTF-8, you use the UTF-8 hex code as the escape sequence \c3\a9. For example, to specify scopes for eng and mktg groups in bldg6, you change the net.slp.useScopes line to the following.net.slp.useScopes=eng,mktg,bldg6 Save your changes and close the file. Restart slpd to activate your changes.# svcadm enable network/slp This section describes the strategic deployment of DAs in a network that is running SLP.SLP functions adequately with only the base agents (UAs and SAs), and with no deployed DAs or configured scopes. All agents that lack specific configurations use the default scope. DAs serve as caches for service advertisements. Deploying DAs decreases the number of messages that are sent on the network and reduces the time that is required to receive responses to messages. This capability enables SLP to accommodate larger networks.The primary reason to deploy DAs is to reduce the amount of multicast traffic and the delays that are associated with gathering unicast replies. In a large network with many UAs and SAs, the amount of multicast traffic that is involved in service discovery can become so large that network performance degrades. By deploying one or more DAs, UAs must unicast to DAs for service and SAs must register with DAs by using unicast. The only SLP-registered multicast in a network with DAs is for active and passive DA discovery.SAs register automatically with any DAs they discover within a set of common scopes, rather than accepting multicast service requests. Multicast requests in scopes that are not supported by the DA are still answered directly by the SA, however. Service requests from UAs are unicast to DAs rather than multicast onto the network when a DA is deployed within the UA's scopes. Consequently, DAs within the UA's scopes reduce multicast. By eliminating multicast for normal UA requests, the time that is required to obtain replies to queries is greatly reduced (from seconds to milliseconds).DAs act as a focal point for SA and UA activity. Deploying one or several DAs for a collection of scopes provides a centralized point for monitoring SLP activity. By turning on DA logging, it is easier to monitor registrations and requests than by checking the logs from multiple SAs that are scattered around the network. You can deploy any number of DAs for a particular scope or scopes, depending on the need to balance the load.In networks without multicast routing enabled, you can configure SLP to use broadcast. However, broadcast is very inefficient, because it requires each host to process the message. Broadcast also does not normally propagate across routers. As a result, in a network without multicast routing support, services can be discovered only on the same subnet. Partial support for multicast routing leads to inconsistent ability to discover services on a network. Multicast messages are used to discover DAs. Partial support for multicast routing, therefore, implies that UAs and SAs register services with all known DAs in the SA's scope. For example, if a UA queries a DA that is called DA1 and the SA has registered services with DA2, the UA will fail to discover a service. See Configuring Broadcast-Only Routing for more information on how to deploy SLP on networks without multicast enabled.On a network with inconsistent site-wide support for multicast routing, you must configure the SLP UAs and SAs with a consistent list of DA locations by using the net.slp.DAAdresseses property.Finally, the Solaris SLPv2 DA supports interoperability with SLPv1. SLPv1 interoperability is enabled by default in the Solaris DA. If your network contains SLPv1 devices, such as printers, or you need to interoperate with Novell Netware 5, which uses SLPv1 for service discovery, you should deploy a DA. Without a DA, the Solaris SLP UAs are unable to find SLPv1 advertised services. Deploy DAs on your enterprise if any of the following conditions are true:Multicast SLP traffic exceeds 1 percent of the bandwidth on your network, as measured by snoop. UA clients experience long delays or timeouts during multicast service requests. You want to centralize the monitoring of SLP service advertisements for particular scopes on one or several hosts. Your network does not have multicast enabled and consists of multiple subnets that must share services. Your network employs devices that support earlier versions of SLP (SLPv1) or you would like SLP service discovery to interoperate with Novell Netware 5. Use the following procedure to set the net.slp.isDA property to True in the slp.conf file. You can assign only one DA per host. &rolestepA;Stop slpdand all SLP activity on the host.# svcadm disable network/slp Back up the default /etc/inet/slp.conf file before you change the configuration settings. Set the net.slp.isDA property in the slpd.conf file to True:net.slp.isDA=True Save your changes and close the file. Restart slpd to activate your changes.# svcadm enable network/slp This section provides suggestions for where to place DAs in different situations.When multicast routing is not enabled and DAs are required to bridge service discovery between subnetsIn this situation, a DA must be placed on a host with interfaces and all subnets that share services. The net.slp.interfaces configuration property does not need to be set, unless IP packets are not routed among the interfaces. See Multihoming Configuration for SLP for more information on configuring the net.slp.interfaces property. When DAs are deployed for scalability and the primary consideration is optimizing agent accessUAs typically make many requests for services to DAs. An SA registers with the DA once, and can refresh the advertisement at periodic but infrequent intervals. As a result, UA access to DAs is far more frequent than SA access. The number of service advertisements is also usually smaller than the number of requests. Consequently, most DA deployments are more efficient if the deployment is optimized for UA access. Situating DAs so that they are topologically close to UAs on the network to optimize UA accessNaturally, you must configure the DA with a scope that is shared by both the UA and SA clients. You can deploy multiple DAs for the same collection of scopes as a means of load balancing. Deploy DAs in any of the following circumstances:UA requests to a DA are timing out, or are returning with the DA_BUSY_NOW error. The DA log shows that many SLP requests are being dropped. The network of users who share services in the scopes spans a number of buildings or physical sites. You can run a snoop trace of SLP traffic to determine how many UA requests return with the DA_BUSY_NOW error. If the number of UA requests returned is high, UAs in buildings physically and topologically distant from the DA can exhibit slow response or excessive timeouts. In such a scenario, you can deploy a DA in each building to improve response for UA clients within the building.Links that connect buildings are often slower than the local area networks within the buildings. If your network spans multiple buildings or physical sites, set the net.slp.DAAddresses property in the /etc/inet/slp.conf file to a list of specific host names or addresses so that the UAs access only the DAs you specify.If a particular DA is using large amounts of host memory for service registrations, reduce the number of SA registrations by reducing the number of scopes the DA supports. You can split into two a scope that has many registrations. You can then support one of the new scopes by deploying another DA on another host. A multihomed server acts as a host on multiple IP subnets. The server can sometimes have more than one network interface card and can act as a router. IP packets, including multicast packets, are routed between the interfaces. In some situations, routing between interfaces is disabled. The following sections describe how to configure SLP for such situations.Without configuration, slpd listens for multicast and for UDP/TCP unicast on the default network interface. If unicast and multicast routing is enabled between interfaces on a multihomed machine, no additional configuration is needed. This is because multicast packets that arrive at another interface are properly routed to the default. As a result, multicast requests for DA or other service advertisements arrive at slpd. If routing is not turned on for some reason, configuration is required. If one of the following conditions exist, you might need to configure multihomed machines.Unicast routing is enabled between the interfaces and multicast routing is disabled. Unicast routing and multicast routing are both disabled between the interfaces. When multicast routing is disabled between interfaces, it is usually because multicast has not been deployed in the network. In that situation, broadcast is normally used for service discovery that is not DA-based and for DA discovery on the individual subnets. Broadcast is configured by setting the net.slp.isBroadcastOnly property to True. Task Description For Instructions Configure the net.slp.interfaces property Set this property to enable slpd to listen for unicast and multicast/broadcast SLP requests on the specified interfaces. Configuring the net.slp.interfaces Property Arrange proxy service advertisements so that UAs on subnets get service URLs with reachable addresses Restrict proxy advertisement to a machine that is running slpd connected to a single subnet rather than a multihomed host. Proxy Advertising on Multihomed Hosts Place the DAs and configure scopes to assure reachability between UAs and SAs Configure the net.slp.interfaces property on multihomed hosts with a single interface host name or address.Run a DA on a multihomed host, but configure scopes so that SAs and UAs on each subnet use different hosts. DA Placement and Scope Name Assignment If the net.slp.interfaces property is set, slpd listens for unicast and multicast/broadcast SLP requests on the interfaces that are listed in the property, rather than on the default interface. Usually, you set the net.slp.interfaces property in conjunction with enabling broadcast by setting the net.slp.isBroadcastOnly property, because multicast has not been deployed in the network. However, if multicast has been deployed, but is not being routed on this particular multihomed host, a multicast request can arrive at slpd from more than one interface. This situation can occur when the routing of packets is handled by another multihomed host or router that connects the subnets that are served by the interfaces.When such a situation occurs, the SA server or the UA that is sending the request receives two responses from slpd on the multihomed host. The responses are then filtered by the client libraries and the client does not see them. The responses are, however, visible in the snoop trace.If unicast routing is turned off, services that are advertised by SA clients on multihomed hosts might not be reachable from all the subnets. If services are unreachable, SA clients can do the following:Advertise one service URL for each individual subnet. Assure that requests from a particular subnet are answered with a reachable URL. The SA client library makes no effort to assure that reachable URLs are advertised. The service program, which might or might not handle a multihomed host with no routing, is then responsible for assuring that reachable URLs are advertised. Before you deploy a service on a multihomed host with unicast routing disabled, use snoop to determine whether the service handles requests from multiple subnets correctly. Furthermore, if you plan to deploy a DA on the multihomed host, see DA Placement and Scope Name Assignment.Use the following procedure to change the net.slp.interfaces property in the slp.conf file. &rolestepA;Stop slpd and all SLP activity on the host.# svcadm disable network/slp Back up the default /etc/inet/slp.conf file before you change the configuration settings. Change the net.slp.interfaces property in the slpd.conf file:net.slp.interfaces=valuevalueList of IPv4 addresses or host names of the network interface cards on which the DA or SA should listen for multicast, unicast UDP, and TCP messages on port 427 For example, a server with three network cards and multicast routing that is turned off is connected to three subnets. The IP addresses of the three network interfaces are 192.147.142.42, 192.147.143.42, and 192.147.144.42. The subnet mask is 255.255.255.0. The following property setting causes slpd to listen on all three interfaces for unicast and multicast/broadcast messaging:net.slp.interfaces=192.147.142.42,192.147.143.42,192.147.144.42You can specify IP addresses or resolvable host names for the net.slp.interfaces property. Save your changes and close the file. Restart slpd to activate your changes.# svcadm enable network/slp If a host with multiple interfaces advertises services by using slpd and proxy registration, the service URLs that are advertised by slpd must contain reachable host names or addresses. If unicast routing is enabled between the interfaces, hosts on all subnets can reach hosts on other subnets. Proxy registrations can also be made for a service on any subnet. If, however, unicast routing is disabled, service clients on one subnet cannot reach services on another subnet through the multihomed host. However, those clients might be able to reach the services through another router.For example, suppose the host with default host name bigguy has three interface cards on three different unrouted subnets. The host names on these subnets are bigguy, with IP address 192.147.142.42, bigguy1, with IP address 192.147.143.42, and bigguy2, with IP address 192.147.144.42. Now suppose that a legacy printer, oldprinter, is connected to the 143 subnet and that the URL service:printing:lpr://oldprinter/queue1 is configured with the net.slp.interfaces to listen on all interfaces. The oldprinter URL is proxy-advertised on all interfaces. The machines on the 142 and 144 subnets receive the URL in response to service requests, but are unable to access the oldprinter service.The solution to this problem is to perform the proxy advertisement with slpd running on a machine that is connected to the 143 subnet only, rather than on the multihomed host. Only hosts on the 143 subnet can obtain the advertisement in response to a service request. The placement of DAs and assignment of scope names on a network with a multihomed host must be done carefully to assure that clients obtain accessible services. Be particularly cautious when routing is disabled and the net.slp.interfaces property is configured. Again, if unicast routing is enabled between the interfaces on a multihomed machine, no special DA and scope configuration is necessary. The advertisements are cached with the DA identify services that are accessible from any of the subnets. However, if unicast routing is disabled, poor placement of DAs can result in problems.To see what problems can result in the previous example, consider what would happen if bigguy runs a DA, and clients on all subnets have the same scopes. SAs on the 143 subnet register their service advertisements with the DA. UAs on the 144 subnet can obtain those service advertisements, even though hosts on the 143 subnet are unreachable.One solution to this problem is to run a DA on each subnet and not on the multihomed host. In this situation, the net.slp.interfaces property on the multihomed hosts should be configured with a single interface host name or address, or it should be left unconfigured, forcing the default interface to be used. A disadvantage of this solution is that multihomed hosts are often large machines that could better handle the computational load of a DA.Another solution is to run a DA on the multihomed host, but configure scopes so that the SAs and UAs on each subnet have a different scope. For example, in the previous situation, UAs and SAs on the 142 subnet might have a scope that is called scope142. UAs and SAs on the 143 subnet might have another scope that is called scope143 and UAs and SAs on the 144 subnet could have third scope that is called scope144. You can configure the net.slp.interfaces property on bigguy with the three interfaces so that the DA serves three scopes on the three subnets. Configuring the net.slp.interfaces property enables a DA on the multihomed host to bridge service advertisements between the subnets. Such configuration is useful if multicast routing is turned off in the network, but unicast routing between interfaces on a multihomed host is enabled. Because unicast is routed between the interfaces, hosts on a subnet different from the subnet on which the service is located can contact the service when they receive the service URL. Without the DA, SA servers on a particular subnet receive only broadcasts that were made on the same subnet, so they cannot locate services off of their subnet.The most common situation that necessitates configuration of the net.slp.interfaces property occurs when multicast is not deployed on the network and broadcast is used instead. Other situations require careful thought and planning to avoid unnecessary duplicate responses or unreachable services.