Chapter 2 Planning the Solaris SLP Deployment

This chapter lists SLP planning considerations for your deployment and describes how to use the Solaris snoop utility to determine whether any of the SLP properties would benefit from additional configuration.

• "SLP Configuration Considerations"

• "Monitoring SLP Activity"

• "Deciding What to Reconfigure"

SLP Configuration Considerations

The Solaris 8 release is shipped with SLP installed and pre-configured with default property settings. If your enterprise operates well with the original SLP settings, the SLP deployment requires virtually no administration. However, in some cases, you might want to alter the default SLP settings to tune SLP network operation or activate various SLP features. For example, with a few configuration changes, you can enable logging for SLP activity exclusively, then check the log file to determine whether additional reconfiguration is needed.

SLP configuration properties reside in the slp.conf file located in the /etc/inet directory. If you determine that some reconfiguration of the default property settings is needed, after reading the information in this chapter and analyzing the efficiency of SLP activity on the system, then consult the remaining chapters for the appropriate procedures.

Before you alter any of the SLP configuration property settings, consider the following:

• Types of network technologies operating in the enterprise

• Types of traffic the technologies handle smoothly

• Number and types of network services

• Number of users and the services they use

• Locations of users in relation to their most frequently accessed services

Monitoring SLP Activity

The snoop utility is a passive administrative tool that provides network traffic information while generating minimal network traffic itself. Invoking snoop enables you to watch all activity on your network as it occurs.

The snoop utility provides a printout of the actual SLP message traffic. For example, using snoop with the slp command line argument, the utility displays SLP traces of registrations and deregistrations by which you can gauge the kinds of services being registered and the amount of reregistration activity, which in turn enables you to gauge the network load.

The snoop utility is also useful for observing the traffic flow between hosts in your SLP enterprise. Using snoop with the slp command line argument, you can gauge and monitor the following types of SLP activity to determine whether any network or agent reconfiguration is needed:

• The number of hosts using a particular DA. With this information, you can determine whether to deploy additional DAs for load balancing.

• Which hosts are using which DAs. With this information, you can determine whether particular hosts should be configured with new or different scopes.

• UA requests are timing out and need to be retransmitted, or the DA requires more than a few seconds to send registration acknowledgments to an SA. You can determine whether that particular DA is overloaded. Also, you can gauge whether to rebalance the network load on the DA by placing additional DAs, or changing the scope configurations.

Using snoop with the -V (verbose) command line argument, you can obtain registration lifetimes and value of the fresh flag in SrvReg to determine whether the number of reregistrations should be reduced. However, if you invoke snoop with the verbose option, the volume of text printed out tends to be large. Therefore, you might dump the text to a file and sort through it later.

You can use snoop to trace other kinds of SLP traffic, as well. For example:

• Traffic between UA clients and DAs

• Traffic between multicasting UA clients and replying SAs

For more information about snoop, refer to the snoop(1M) man page.

Use the netstat command in conjunction with snoop to view traffic and congestion statistics. For more information about netstat, refer to the netstat(1M) man page.

Regulating Display Output

The snoop command provides various filters and options through which you control the focus of the snoop trace and the length of its output. Additionally, you can use snoop slp with any other snoop expression.

When using the snoop utility, you can select either brief or verbose mode for the output. In verbose mode, snoop delivers ongoing, unabbreviated output to your monitor, which provides the following types of information:

• The complete address for the service URL

• All service attributes

• The registration lifetime

• All security parameters and flags, if any

Type the following command to invoke snoop with the slp filter in verbose mode:

# snoop slp -v

The default setting for snoop is brief mode, which delivers ongoing output to your monitor that is truncated to fit one line per SLP message.

Deciding What to Reconfigure

You can use the SLP-enabled snoop utility and SLP logging utilities to decide what needs reconfiguring. For example, you might want to reconfigure certain properties to:

• Accommodate a mix of network media that have varying latencies and bandwidth characteristics

• Recover the enterprise from network failures or unplanned partitioning

• Add DAs to reduce proliferation of SLP multicasts

• Implement new scopes to organize users with their most frequently accessed services

Analyzing a snoop slp Trace

The following sample traces illustrate how to start snoop with the SLP filter (in the default brief mode), and the kinds of traces it might show. This example is invoked using the following command:

# snoop slp

In this example, when snoop slp is invoked on the host vesuvius, slpd starts on vesuvius and initializes and registers the host umunum as an echo server. slpd on vesuvius runs in the default mode as an SA server.

To make it easier to describe the trace results, the lines have been separated and identified with the trace line number.

Trace 1 shows slpd on vesuvius performing active directory agent discovery by multicasting to the SLP multicast group address in search of directory agents. The message number, (24487), for the active discovery is indicated in square brackets in the trace display:

(1) vesuvius -> 239.255.255.253 SLP V@ SrvRqst [24487] service:directory-agent []

Trace 2 illustrates the SLP mechanism in which matching pairs of request-reply messages are identified by their matching message numbers:

(2) umunum -> vesuvius SLP V2 DAAdvert [24487] service:directory-agent://129

Trace 2 indicates that the active discovery request 24487 from trace 1 is answered by slpd running as a DA on the host umunum. The service URL from umunum has been truncated in the trace to fit on a single line. The DA has sent a DA advertisement in reply to the multicast directory agent discovery message, as indicated by the matching message numbers in traces 1 and 2.

Traces 3 and 4 show multicasts from the UAs on vesuvius for additional DAs. Because umunum has already answered the request, it refrains from responding again, and no other DAs reply.

(3) vesuvius -> 239.255.255.253 SLP V2 SrvRqst [24487] service:directory-agent []
(4) vesuvius -> 239.255.255.253 SLP V2 SrvRqst [24487] service:directory-agent []

In the next two traces, slpd on vesuvius forwards registrations made by SA clients to the DA on the host umunum. Note that the traffic between the echo server running the SA client and slpd on vesuvius does not appear in the snoop trace because it is performed over the network loopback. Traces 5 and 6 show slpd on vesuvius forwarding the service registration to the DA on umunum, and the reply from umunum.

The message exchange shown in lines 5 and 6 of the trace occurs by TCP, as is indicated by the tcp appended to the message number in each case.

(5) vesuvius -> umunum SLP V2 SrvReg [24488/tcp]service:echo.sun:tcp://vesuvius:
(6) umunum -> vesuvius SLP V2 SrvAck [24488/tcp] ok

Trace 5 shows a unicast service registration (SrvReg) for an echo server, which is made by vesuvius to the DA on umunum. Trace 6 shows umunum responding to vesuvius' SrvReg with a service acknowledgment (SrvAck), indicating that the registration is successful.

In the next example, the echo server program on vesuvius deregisters the echo service advertisement. slpd on vesuvius forwards the deregistration to the DA on umunum.

(1) vesuvius -> umunum SLP V2 SrvDereg [24489/tcp] service:echo.sun:tcp://vesuvius:
(2) umunum -> vesuvius SLP V2 SrvAck [24489/tcp] ok

The echo server, umunum, informs the host, vesuvius, that the deregistration was successful by way of a SrvAck. The initial exchange between the echo server SA client and slpd does not appear. The reply indicates that the deregistration succeeded.

Where to Go From Here

After monitoring the SLP traffic, you can use the information collected from the snoop traces to help determine whether any reconfiguration of the SLP defaults is needed. Use the related information in Chapter 3, Configuring SLP Properties and Chapter 4, Configuring Network Properties for configuring SLP property settings. For more information about SLP messaging and service registrations, refer to Appendix A, SLP Message Types.