This chapter provides information on planning and enabling SLP. The following sections discuss SLP configuration and the process for enabling SLP.SLP Configuration Considerations Using snoop to Monitor SLP Activity The SLP daemon is preconfigured with default properties. If your enterprise functions well with default settings, the SLP deployment requires virtually no administration. In some situations, however, you might want to modify the SLP properties to tune network operations or to activate certain features. With a few configuration changes you can enable SLP logging, for example. The information in a SLP log and in snoop traces can then help you decide if additional configuration is necessary.SLP configuration properties reside in the slp.conf file, which is located in the /etc/inet directory. If you decide to change the default property settings, refer to Chapter 9, Administering SLP (Tasks) for the appropriate procedures.Before you modify SLP configuration settings, consider the following questions that are related to key aspects of network administration:What network technologies are operating in the enterprise? How much network traffic can the technologies handle smoothly? How many services, of what type, are available on the network? How many users are on the network? What services do they require? Where are users located in relation to their most frequently accessed services? You can use the SLP-enabled snoop utility and SLP logging utilities to decide if reconfiguration is necessary and what properties you need to modify. For example, you might reconfigure certain properties to do the following: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 The snoop utility is a passive administrative tool that provides network traffic information. The utility itself generates minimal traffic and enables you to watch all activity on your network as it occurs.The snoop utility provides traces of the actual SLP message traffic. For example, when you run snoop with the slp command-line argument, the utility displays traces with information on SLP registrations and deregistrations. You can use the information to gauge the network load by checking which services are being registered and how much reregistration activity its occurring.The snoop utility is also useful for observing the traffic flow between SLP hosts in your enterprise. When you run snoop with the slp command-line argument, you can monitor the following types of SLP activity to determine if network or agent reconfiguration is needed:The number of hosts that are using a particular DA. Use this information to decide whether to deploy additional DAs for load balancing. The number of hosts that are using a particular DA. Use this information to help you determine whether to configure certain hosts with new or different scopes. Whether UA requests a timeout or DA acknowledgment is slow. You can determine whether a DA is overloaded by monitoring UA timeouts and retransmissions. You can also check if the DA requires more than a few seconds to send registration acknowledgments to an SA. Use this information to rebalance the network load on the DA, if necessary, by deploying 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. You can also use snoop to trace other kinds of SLP traffic, such as the following:Traffic between UA clients and DAs Traffic between multicasting UA clients and replying SAs For more information about snoop, refer to the snoop1M.Use the netstat command in conjunction with snoop to view traffic and congestion statistics. For more information about netstat, refer to netstat1M. &rolestepA;Run snoop with the slp command-line argument.Brief Mode: # snoop slpWhen you run snoop in the default brief mode, ongoing output is delivered to your screen. SLP messages are truncated to fit on one line per SLP trace. Verbose Mode: # snoop -v slpWhen you run snoop in verbose mode, snoop delivers ongoing, unabbreviated output to your screen, which provides the following information:The complete address of the service URL All service attributes The registration lifetime All security parameters and flags, if any are available You can use the slp command-line argument with other snoop options. In the following example, slpd runs on slphost1 in the default mode as an SA server. The SLP daemon initializes and registers slphost2 as an echo server. Then, the snoop slp process is invoked on slphost1.To simplify the description of the trace results, the lines in the following snoop output are flagged with line numbers. (1) slphost1 -> 239.255.255.253 SLP V@ SrvRqst [24487] service:directory-agent [] (2) slphost2 -> slphost1 SLP V2 DAAdvert [24487] service:directory-agent://129 (3) slphost1 -> 239.255.255.253 SLP V2 SrvRqst [24487] service:directory-agent [] (4) slphost1 -> 239.255.255.253 SLP V2 SrvRqst [24487] service:directory-agent [] (5) slphost1 -> slphost2 SLP V2 SrvReg [24488/tcp]service:echo.sun:tcp://slphost1: (6) slphost2 -> slphost1 SLP V2 SrvAck [24488/tcp] ok (7) slphost1 -> slphost2 SLP V2 SrvDereg [24489/tcp] service:echo.sun:tcp://slphost1: (8) slphost2 -> slphost1 SLP V2 SrvAck [24489/tcp] okShows slpd on slphost1 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. Indicates that the active discovery request 24487 from trace 1 is answered by slpd, which is running as a DA on the host slphost2. The service URL from slphost2 has been truncated 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. Shows multicasts from the UAs on slphost1 for additional DAs. Because slphost2 has already answered the request, it refrains from responding again, and no other DAs reply. Repeats the multicast operation that is shown in the previous line. Shows a slpd on slphost1 forwarding SA client registrations to the DA on slphost2. A unicast service registration (SrvReg) for an echo server is made by slphost1 to the DA on slphost2. Shows slphost2 responding to the slphost1 SrvReg with a service acknowledgment (SrvAck) that indicates the registration is successful.Traffic between the echo server that runs the SA client and the SLP daemon on slphost1 does not appear in the snoop trace. This absence of information is because the snoop operation is performed over the network loopback. Shows the echo server on slphost1 deregistering the echo service advertisement. The SLP daemon on slphost1 forwards the deregistration to the DA on slphost2. Shows slphost2 responding to the slphost1 with a service acknowledgment (SrvAck) that indicates that the deregistration is successful.The /tcp parameter that is appended to the message number on lines 5, 6, 7, and 8 indicates that the message exchange occurred by TCP. After monitoring the SLP traffic, you can use the information that was collected from the snoop traces to help determine whether any reconfiguration of the SLP defaults is needed. Use the related information in Chapter 9, Administering SLP (Tasks) for configuring SLP property settings. For more information about SLP messaging and service registrations, refer to Chapter 11, SLP (Reference).