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.