Chapter 6 Deploying DAs

This chapter describes the strategic deployment of DAs in a network running SLP.

SLP functions adequately with only the base agents, UA and SA, and without any deployed DAs or configured scopes (all agents automatically have the default scope). However, DAs serve as caches for service advertisements, and they are useful for reducing multicast. This capability enables SLP to accommodate larger networks.

• "Why Deploy an SLP DA?"

• "When to Deploy DAs"

• "Deploying DAs"

• "Where to Place DAs"

Why Deploy an SLP DA?

The primary reason to deploy DAs is to reduce the amount of multicast traffic involved in service discovery. In a large network with many UAs and SAs, the amount of multicast traffic 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 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 taking 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, delays and timeouts are eliminated.

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 to check the logs from multiple SAs 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, DAs can be deployed on multihomed hosts to bridge SLP advertisements between the subnets. See Chapter 4, Configuring Network Properties for more information on how to deploy SLP on networks without multicast enabled.

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, like 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% of the bandwidth on your network, as measured by snoop.

• UA clients experience long delays or timeouts during multicast service requests.

• You would like to centralize 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.

Deploying DAs

In Solaris SLP, you deploy a DA by changing the default setting for the net.slp.isDA property in the host's slp.conf file, then stopping and restarting slpd. This causes slpd to start as a DA. You can assign only one DA per host.

How to Deploy a DA

1. Become superuser.

2. Edit the /etc/inet/slp.conf file and set the net.slp.isDA property to true.

   net.slp.isDA=True

3. Save the file and exit.

4. Restart slpd to deploy it as a DA.

   # /etc/init.d/slpd start

Where to Place DAs

This section provides suggestions for where to place DAs in different situations.

1. When multicast routing is not enabled and DAs are required to bridge service discovery between subnets

   In this case, 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 Chapter 8, Configuring SLP on Multihomed Hosts for more information on configuring the net.slp.interfaces property.

2. When DAs are deployed for scalability, 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 not frequent, 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.

3. Situating DAs so that they are topologically close to UAs on the network to optimize UA access

   Placing UAs topologically close to their DAs reduces the amount of routing delay for answering SLP requests. Naturally, you must configure the DA with a scope 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. Deployment of multiple DAs is suggested 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 sharing services in the scopes spans a number of buildings or physical sites.

You can do 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, which is likely if a single DA is deployed for all users, UAs in buildings physically and topologically distant from the DA can exhibit slow response or excessive timeouts. You might want to deploy a DA in each building to improve response for UA clients within the building.

Links connecting 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 a scope having many registrations into two and support one of the new scopes by deploying another DA on another host.