Using snoop to Monitor SLP Activity

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 snoop(1M).

---

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

---

How to Use snoop to Run SLP Traces

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Run snoop with the slp command-line argument.

   Brief Mode:
   # snoop slp

   When 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 slp

   When 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

   ---

   Note - You can use the slp command-line argument with other snoop options.

   ---

Analyzing a snoop slp Trace

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.

---

Note - 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] ok

1. Shows 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.

2. 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.

3. 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.

4. Repeats the multicast operation that is shown in the previous line.

5. 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.

6. 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.

7. Shows the echo server on slphost1 deregistering the echo service advertisement. The SLP daemon on slphost1 forwards the deregistration to the DA on slphost2.

8. 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.

Where to Go From Here

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).