JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
System Administration Guide: Network Services     Oracle Solaris 10 8/11 Information Library
search filter icon
search icon

Document Information


Part I Network Services Topics

1.  Network Service (Overview)

2.  Managing Web Cache Servers

3.  Time-Related Services

Part II Accessing Network File Systems Topics

4.  Managing Network File Systems (Overview)

5.  Network File System Administration (Tasks)

6.  Accessing Network File Systems (Reference)

Part III SLP Topics

7.  SLP (Overview)

8.  Planning and Enabling SLP (Tasks)

SLP Configuration Considerations

Deciding What to Reconfigure

Using snoop to Monitor SLP Activity

How to Use snoop to Run SLP Traces

Analyzing a snoop slp Trace

Where to Go From Here

9.  Administering SLP (Tasks)

10.  Incorporating Legacy Services

11.  SLP (Reference)

Part IV Mail Services Topics

12.  Mail Services (Overview)

13.  Mail Services (Tasks)

14.  Mail Services (Reference)

Part V Serial Networking Topics

15.  Solaris PPP 4.0 (Overview)

16.  Planning for the PPP Link (Tasks)

17.  Setting Up a Dial-up PPP Link (Tasks)

18.  Setting Up a Leased-Line PPP Link (Tasks)

19.  Setting Up PPP Authentication (Tasks)

20.  Setting Up a PPPoE Tunnel (Tasks)

21.  Fixing Common PPP Problems (Tasks)

22.  Solaris PPP 4.0 (Reference)

23.  Migrating From Asynchronous Solaris PPP to Solaris PPP 4.0 (Tasks)

24.  UUCP (Overview)

25.  Administering UUCP (Tasks)

26.  UUCP (Reference)

Part VI Working With Remote Systems Topics

27.  Working With Remote Systems (Overview)

28.  Administering the FTP Server (Tasks)

29.  Accessing Remote Systems (Tasks)

Part VII Monitoring Network Services Topics

30.  Monitoring Network Performance (Tasks)



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:

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:

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.

  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 -> SLP V@ SrvRqst [24487] service:directory-agent []
(2) slphost2 -> slphost1 SLP V2 DAAdvert [24487] service:directory-agent://129
(3) slphost1 -> SLP V2 SrvRqst [24487] service:directory-agent []
(4) slphost1 -> 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).