Deploying DAs
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.
Why Deploy an SLP DA?
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.
When to Deploy DAs
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.
How to Deploy DAs
Use the following procedure to set the net.slp.isDA property to True in the
slp.conf file.
Note - You can assign only one DA per host.
- Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
- 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
Where to Place DAs
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 subnets
In 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 access
UAs 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 access
Naturally, you must configure the DA with a scope that is shared by both the UA and SA clients.
Placing Multiple DAs for Load Balancing
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.
