test

Service Location Protocol Administration Guide

Chapter 4 Configuring Network Properties

SLP includes a collection of configuration properties that control the network interaction characteristics of slpd and the client libraries. In most cases, the default configurations of these properties require no change. However, for certain types of network media or network topologies, changes might be required to accommodate varying latencies or bandwidth or to prevent potential problems on your network.

This chapter lists types of scenarios in which you might want to alter the default SLP configuration property settings.

Changing Network Configuration Properties

The SLP network properties are designed to control particular aspects of interaction between slpd, the client library, and the network. This section lists procedures for altering the following types of SLP networking properties:

In each area, various properties control different aspects of the configuration. The following sections describe how to configure SLP.

Modifying DA Advertising and Discovery Frequency

In some situations, you might need to modify the frequency of DA advertising or DA discovery. DA advertising and discovery are controlled by the following properties:

The reasons why you might want to modify the default DA advertising and discovery configuration are:

Limiting UAs and SAs to Statically Configured DAs

In some cases, it might be necessary to limit UAs and SAs to obtain only their DA addresses from the static configuration information in the slp.conf file. You can accomplish this by disabling passive and active DA discovery in slpd.

Disable passive discovery by setting the net.slp.passiveDADetection property to False. This causes slpd to ignore unsolicited DA advertisements.

Disable initial and periodic active discovery by setting the net.slp.DAActiveDiscoveryInterval to -1. This causes slpd to refrain from performing initial active DA discovery, and from periodically polling for new DAs.

Perform these configurations only on those hosts executing the UAs and SAs that are restricted to using their static configurations. As a consequence of these configuration actions, slpd obtains DA information only from the net.slp.DAAddresses property in the slp.conf file.

Modifying DA Advertising and Discovery Timing

For certain combinations of network media and the overall network topology, you might need to modify the timing of passive DA advertisements and periodic active discovery requests. This section provides these examples:

Configuring the DA Heartbeat for Frequent Partitions

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, then slpd registers all advertisements on its host with the DA, in order for the set of service advertisements in the scopes to be consistent.

One way slpd discovers DAs is by the initial unsolicited advertisement a DA sends out when it boots. slpd uses the periodic unsolicited advertisement (the heartbeat) to determine whether a DA is still active, and removes the DAs it uses and offers to UAs if a heartbeat fails to appear.

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. slpd 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 DAs from its cache during the partitions 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.

The net.slp.DAHeartBeat property controls how often a DA multicasts an unsolicited DA advertisement. By default, the DA heartbeat period is set to 3 hours (10800 seconds). The following entry decreases the DA heartbeat value to one hour: 


net.slp.DAHeartBeat=3600

Configuring DA Discovery for Dial-up Networks

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 they are activated, so minimizing extraneous calls can reduce the cost of using the dial-up network.

You can disable DA discovery completely using the method described in "Limiting UAs and SAs to Statically Configured DAs". If DA discovery is completely disabled, the net.slp.DAAddresses property must be set in slp.conf on the hosts executing UAs and SAs so that they access the correct DA.

You can reduce unsolicited DA advertisements and active discovery by increasing the DA heartbeat period and the active discovery period. In the following example, both the active discovery interval and the DA heartbeat are set to about 18 hours. The first line shows the setting for the host executing the DA:


net.slp.DAHeartBeat=65535

On the hosts executing the UAs and SAs, the active discovery interval is configured as:


net.slp.DAActiveDiscoveryInterval=65535

Both property values are measured in seconds.

Network Congestion Is High

If network congestion is high, you might want to limit the amount of multicast. If DAs have not already been deployed in the network, deploying DAs can drastically cut back on 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 using the method described in "Configuring DA Discovery for Dial-up Networks". You can completely eliminate multicast for DA discovery using the method described in "Limiting UAs and SAs to Statically Configured DAs".

Accommodating Different Network Media, Topology, or Configuration

Depending on the underlying network media and configuration in your network, you can tune SLP performance by modifying one of the following parameters:

This section describes how to use these properties to tune SLP performance.

Reducing the Interval Between SA Reregistrations

SAs need to periodically refresh their service advertisements before the lifetime expires. 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 timing out and are dropped. Timing out of UA requests has many possible causes, so before assuming that DA overloading is the problem, you should use a snoop trace to check the lifetimes of service advertisements registered with a service registration. If the lifetimes are short and reregistrations are occurring often, then timeouts are probably due to too-frequent reregistrations. A service registration is a reregistration if the fresh flag is not set. See Appendix A, SLP Message Types for more information on service registration messages.

The following example sets the minimum refresh interval for SAs to one hour:


net.slp.DAAttributes=(min-refresh-interval=3600)

The net.slp.DAAttributes property has units of seconds. The default minimum reregistration period is zero (0), so that an SA is free to reregister whenever it chooses.

Configuring the Multicast Time to Live Property

The multicast time to live (net.slp.multicastTTL property) determines the range over which a multicast packet is propagated in 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 is the case with the standard IP TTL. If the TTL becomes zero, the packet is discarded. Therefore, using TTL scoping for SLP multicast requires that your routers be properly configured so that packets are limited to a particular subsection of your intranet.

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 it 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, but values below 32 can be used to restrict multicast to a set of accessible subnets, provided the routers are properly configured with TTLs.

Configuring the Packet Size

The default packet size for SLP is 1400 bytes, and this 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, setting the net.slp.MTU property is necessary.

You can also increase the packet size if your network medium has larger packets. However, unless the service advertisements from SAs or queries from UAs are frequently overflowing the default packet size, configuration should not be necessary. You can determine whether the default packet size is overflowing frequently by using snoop to check whether UA requests are overflowing often, and rolling over to use TCP instead of UDP.

The net.slp.MTU property measures the complete IP packet size, including the link layer header, the IP header, and the UDP or TCP header, as well as the SLP message.

Configuring Broadcast Instead of Multicast

SLP is designed to use multicast for service discovery in the absence of DAs and for DA discovery. For various reasons, some networks do not deploy multicast routing. 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 in networks where broadcast is used. A DA on a multihomed host can bridge service discovery between multiple subnets with multicast disabled. See Chapter 8, Configuring SLP on Multihomed Hosts for more information on deploying DAs on multihomed hosts.

Modifying Timeouts on SLP Discovery Requests

There are two general situations where timeouts on SLP discovery requests might need to be modified:

Changing Default Timeouts

High network latency can cause UAs and SAs to time out in making their requests and registrations before a response returns. Latency can be a problem if a UA is separated from an SA, or both a UA and SA are separated from a DA, either by multiple subnets, a dial-up line, or a WAN. You can determine whether latency is a problem by checking whether UAs and SAs are timing out on requests and registrations and their SLP requests are failing, or by using ping to measure the actual latency.

The sets of configuration properties that control timeouts:

If frequent timeouts are occurring during multicast service discovery or DA discovery, the net.slp.multicastMaximumWait property should be increased from its default value of 15000 milliseconds (15 seconds). Increasing the maximum wait period allows more time for requests on high latency networks to complete. After this property is increased, you should also modify the net.slp.multicastTimeouts and net.slp.DADiscoveryTimeouts lists so that the sum of the integer timeout values in the lists equals the net.slp.multicastMaximumWait value.

As an example, suppose you have determined that multicast requests require 20 seconds (20000 milliseconds) instead of 15 seconds to complete. The following property configurations change the maximum wait time and the list of multicast timeouts:


net.slp.multicastMaximumWait=20000
net.slp.multicastTimeouts=2000,5000,6000,7000
net.slp.DADiscoveryTimeouts=3000,3000,6000,8000

If your network has low latency, you can reduce the net.slp.multicastMaximumWait configuration value and the values in the two multicast timeout lists to reduce waiting time.

A similar procedure works for the timeouts involved in sending a UDP datagram to a DA, except the upper bound on the DA timeout is determined by the sum of the elements in the net.slp.datagramTimeouts list and not a separate property. A UDP datagram is repeatedly sent to a DA until a response is received or the timeout bound is reached. If frequent timeouts occur, the values in the list can be increased.

For example, suppose, as above, you need to increase the datagram timeout bound to 20000 milliseconds to avoid frequent timeouts. The following configuration will achieve that:


net.slp.datagramTimeouts=2000,5000,6000,7000

In high performance networks, you can perform this procedure in reverse to reduce the timeout bound for multicast and unicast UDP datagram transmission. This will reduce the amount of latency in satisfying SLP requests.

Configuring the Random Wait Bound

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 in a network of hosts running slpd as an SA server and a host running slpd as a DA. If multiple service registration messages for the same service from the host running slpd as an SA server are appearing in the snoop trace, then you might have a problem with collisions.

Collisions can be a particular problem at boot time. When a DA is first coming up, it sends out unsolicited advertisements and the SAs respond with their 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 controlled by the net.slp.randomWaitBound. The default random wait bound is 1000 milliseconds (1 second).

You can lengthen the maximum wait by configuring the property. For example:


net.slp.randomWaitBound=5000

This example lengthens the random wait to 5000 milliseconds (5 seconds).

Lengthening the random wait bound causes longer delay in registration with the DA, so SAs can complete registrations with newly discovered DAs more slowly, thereby avoiding collisions and timeouts.