path: root/doc/rfc/rfc1147.txt

          Network Working Group                    R. Stine, Editor
          Request for Comments: 1147                   SPARTA, Inc.
          FYI: 2                                         April 1990


                   FYI on a Network Management Tool Catalog:
              Tools for Monitoring and Debugging TCP/IP Internets
                           and Interconnected Devices


          Status of this Memo

          The goal of this FYI memo is to provide practical informa-
          tion to site administrators and network managers.  This memo
          provides information for the Internet community.  It does
          not specify any standard.  It is not a statement of IAB pol-
          icy or recommendations.  Comments, critiques, and new or
          updated tool descriptions are welcome, and should be sent to
          Robert Stine, at stine@sparta.com, or to the NOCTools work-
          ing group, at noctools@merit.edu.

          Distribution of this memo is unlimited.

          1. Introduction

          This catalog contains descriptions of several tools avail-
          able to assist network managers in debugging and maintaining
          TCP/IP internets and interconnected communications
          resources.  Entries in the catalog tell what a tool does,
          how it works, and how it can be obtained.

          The NOCTools Working Group of the Internet Engineering Task
          Force (IETF) compiled this catalog in 1989.  Future editions
          will be produced as IETF members become aware of tools that
          should be included, and of deficiencies or inaccuracies.
          Developing an edition oriented to the OSI protocol suite is
          also contemplated.

          The tools described in this catalog are in no way endorsed
          by the IETF.  For the most part, we have neither evaluated
          the tools in this catalog, nor validated their descriptions.
          Most of the descriptions of commercial tools have been pro-
          vided by vendors.  Caveat Emptor.

          1.1 Purpose

          The practice of re-inventing the wheel seems endemic to the
          field of data communications.  The primary goal of this



          IETF NOCTools Working Group                         [Page 1]
^L
          RFC 1147    FYI: Network Management Tool Catalog  April 1990


          document is to fight that tendency in a small but useful
          way.  By listing the capabilities of some of the available
          network management tools, we hope to pool and share
          knowledge and experience.  Another goal of this catalog is
          to show those new in the field what can be done to manage
          internet sites.  A network management tutorial at the end of
          the document is of further assistance in this area.
          Finally, by omission, this catalog points out the network
          management tools that are needed, but do not yet exist.

          There are other sources of information on available network
          management tools.  Both the DDN Protocol Implementation and
          Vendors Guide and the DATAPRO series on data communications
          and LANs are particularly comprehensive and informative.
          The DDN Protocol Implementation and Vendors Guide addresses
          a wide range of internet management topics, including
          evaluations of protocol implementations and network
          analyzers.* The DATAPRO volumes, though expensive (check
          your local university or technical libraries!), are good
          surveys of available commercial products for network manage-
          ment.  DATAPRO also includes tutorials, market analyses,
          product evaluations, and predictions on technology trends.

          1.2 Scope

          The tools described in this document are used for managing
          the network resources, LANs, and devices that are commonly
          interconnected by TCP/IP internets.  This document is not,
          however, a "how to" manual on network management.  While it
          includes a tutorial, the coverage is much too brief and gen-
          eral to serve as a sole source: a great deal of further
          study is required of aspiring network managers.  Neither is
          this catalog is an operations manual for particular tools.
          Each individual tool entry is brief, and emphasizes the uses
          to which a tool can be put.  A tool's documentation, which
          in some cases runs to hundreds of pages, should be consulted
          for assistance in its installation and operation.

          1.3 Overview

          Section 1 describes the purpose, scope, and organization of
          this catalog.

          Section 2 lists and explains the standard keywords used in
          _________________________
          * Instructions for obtaining the DDN Protocol Guide are
          given in Section 7 of the appendix.




          IETF NOCTools Working Group                         [Page 2]
^L
          RFC 1147    FYI: Network Management Tool Catalog  April 1990


          the tool descriptions.  The keywords can be used as a sub-
          ject index into the catalog.

          Section 3, the main body of the catalog, contains the
          entries describing network management tools.  The tool
          entries in Section 3 are presented in alphabetical order, by
          tool name.  The tool descriptions all follow a standard for-
          mat, described in the introduction to Section 3.

          Following the catalog, there is an appendix that contains a
          tutorial on the goals and practice of network management.

          1.4 Acknowledgements

          The compilation and editing of this catalog was sponsored by
          the Defense Communications Engineering Center (DCEC), con-
          tract DCA100-89-C-0001.  The effort grew out of an initial
          task to survey current internet management tools.  The cata-
          log is largely, however, the result of volunteer labor on
          the part of the NOCTools Working Group, the User Services
          Working Group, and many others.  Without these volunteer
          contributions, the catalog would not exist.  The support
          from the Internet community for this endeavor has been
          extremely gratifying.

          Several individuals made especially notable contributions.
          Mike Patton, Paul Holbrook, Mark Fedor and Gary Malkin were
          particularly helpful in composition and editorial review,
          while Dave Crocker provided essential guidance and
          encouragement.  Bob Enger was active from the first with the
          gut work of chairing the Working Group and building the
          catalog.  Phill Gross helped to christen the NOCTools Work-
          ing Group, to define its scope and goals, and to establish
          its role in the IETF.  Mike Little contributed the formative
          idea of enhancing and publicizing the management tool survey
          through IETF participation.

          Responsibility for any deficiencies and errors remains, of
          course, with the editor.












          IETF NOCTools Working Group                         [Page 3]
^L
          RFC 1147    FYI: Network Management Tool Catalog  April 1990


          2. Keywords

          This catalog uses "keywords" for terse characterizations of
          the tools.  Keywords are abbreviated attributes of a tool or
          its use.  To allow cross-comparison of tools, uniform key-
          word definitions have been developed, and are given below.
          Following the definitions, there is an index of catalog
          entries by keyword.

          2.1 Keyword Definitions

          The keywords are always listed in a prefined order, sorted
          first by the general category into which they fall, and then
          alphabetically.  The categories that have been defined for
          management tool keywords are:

               o+    the general management area to which a tool
                    relates or a tool's functional role;

               o+    the network resources or components that are
                    managed;

               o+    the mechanisms or methods a tool uses to perform
                    its functions;

               o+    the operating system and hardware environment of a
                    tool; and

               o+    the characteristics of a tool as a hardware pro-
                    duct or software release.


          The keywords used to describe the general management area or
          functional role of a tool are:

          Alarm
               a reporting/logging tool that can trigger  on  specific
               events within a network.

          Analyzer
               a traffic monitor that reconstructs and interprets pro-
               tocol messages that span several packets.

          Benchmark
               a tool used to evaluate the performance of network com-
               ponents.





          IETF NOCTools Working Group                         [Page 4]
^L
          RFC 1147    FYI: Network Management Tool Catalog  April 1990



          Control
               a tool that can change the state or status of a  remote
               network resource.

          Debugger
               a tool that by generating arbitrary packets  and  moni-
               toring traffic, can drive a remote network component to
               various states and record its responses.

          Generator
               a traffic generation tool.

          Manager
               a distributed network management system or system  com-
               ponent.

          Map
               a tool that can discover and report a system's topology
               or configuration.

          Reference
               a tool for documenting MIB structure or  system  confi-
               guration.

          Routing
               a packet route discovery tool.

          Security
               a tool for analyzing or reducing threats to security.

          Status
               a tool that remotely tracks the status of network  com-
               ponents.

          Traffic
               a tool that monitors packet flow.


          The keywords used to identify the network resources or com-
          ponents that a tool manages are:

          Bridge
               a tool for controlling or monitoring LAN bridges.







          IETF NOCTools Working Group                         [Page 5]
^L
          RFC 1147    FYI: Network Management Tool Catalog  April 1990



          CHAOS
               a tool for controlling or monitoring implementations of
               the CHAOS protocol suite or network components that use
               it.

          DECnet
               a tool for controlling or monitoring implementations of
               the  DECnet  protocol  suite or network components that
               use it.

          DNS
               a Domain Name System debugging tool.

          Ethernet
               a tool for controlling or monitoring network components
               on ethernet LANs.

          FDDI
               a tool for controlling or monitoring network components
               on FDDI LANs or WANs.

          IP
               a tool for controlling or monitoring implementations of
               the  TCP/IP  protocol  suite or network components that
               use it.

          OSI
               a tool for controlling or monitoring implementations of
               the  OSI  protocol suite or network components that use
               it.

          NFS
               a Network File System debugging tool.

          Ring
               a tool for controlling or monitoring network components
               on Token Ring LANs.

          SMTP
               an SMTP debugging tool.

          Star
               a tool for controlling or monitoring network components
               on StarLANs.


          The keywords used to describe a tool's mechanism are:



          IETF NOCTools Working Group                         [Page 6]
^L
          RFC 1147    FYI: Network Management Tool Catalog  April 1990



          Curses
               a tool that uses the "curses" tty interface package.

          Eavesdrop
               a tool  that  silently  monitors  communications  media
               (e.g., by putting an ethernet interface into "promiscu-
               ous" mode).

          NMS
               the tool is a component of or queries a Network Manage-
               ment System.

          Ping
               a tool that sends packet probes such as ICMP echo  mes-
               sages;  to  help  distinguish tools, we do not consider
               NMS queries or protocol spoofing (see below) as probes.

          Proprietary
               a distributed tool that uses proprietary communications
               techniques to link its components.

          SNMP
               a network management system or component based on SNMP,
               the Simple Network Management Protocol.

          Spoof
               a tool that tests operation of remote protocol  modules
               by peer-level message exchange.

          X
               a tool that uses X-Windows.


          The keywords used to describe a tool's operating environment
          are:

          DOS
               a tool that runs under MS-DOS.

          HP
               a tool that runs on Hewlett-Packard systems.

          Macintosh
               a tool that runs on Macintosh personal computers.






          IETF NOCTools Working Group                         [Page 7]
^L
          RFC 1147    FYI: Network Management Tool Catalog  April 1990



          Standalone
               an integrated hardware/software tool that requires only
               a network interface for operation.

          UNIX
               a tool that runs under 4.xBSD UNIX or related OS.

          VMS
               a tool that runs under DEC's VMS operating system.


          The keywords used to describe a tool's characteristics as a
          hardware or software acquisition are:

          Free
               a tool is available at no charge, though other restric-
               tions may apply (tools that are part of an OS distribu-
               tion but not otherwise  available  are  not  listed  as
               "free").

          Library
               a tool packaged with either an Application  Programming
               Interface (API) or object-level subroutines that may be
               loaded with programs.

          Sourcelib
               a collection of source code  (subroutines)  upon  which
               developers may construct other tools.






















          IETF NOCTools Working Group                         [Page 8]
^L
          RFC 1147    FYI: Network Management Tool Catalog  April 1990


          2.2 Tools Indexed by Keywords

          Following is an index of catalog entries sorted by keyword.
          This index can be used to locate the tools with a particular
          attribute: tools are listed under each keyword that charac-
          terizes them.  The keywords and the subordinate lists of
          tools under them are in alphabetical order.

          In the interest of brevity, some liberties have been taken
          with tool names.  Capitalization of the names is as speci-
          fied by the tool developers or distributers.  Note that
          parenthetical roman numerals following a tool's name are not
          actually part of the name.  The use of roman numerals to
          differentiate tools with the same name is explained in the
          introduction of Section 3.

          alarm                           bridge
               CMIP Library                    ConnectVIEW
               EtherMeter                      decaddrs
               LanProbe                        NMC
               LANWatch                        proxyd
               NETMON (III)                    Snmp Libraries
               osilog                          snmpd
               SERAG
               sma
               Snmp Libraries             CHAOS
               snmptrapd                       LANWatch
               SpiderMonitor                   map
               Unisys NCC
               WIN/MGT Station
               xnetmon (I)                control
               XNETMON (II)                    CMIP Library
                                               ConnectVIEW
                                               NETMON (III)
          analyzer                             NMC
               LANWatch                        proxyd
               Sniffer                         Snmp Libraries
               SpiderMonitor                   snmpset
                                               TokenVIEW
                                               Unisys NCC
          benchmark                            WIN/MGT Station
               hammer                          XNETMON (II)
               nhfsstone
               SPIMS
               spray
               TTCP
               Unisys NCC




          IETF NOCTools Working Group                         [Page 9]
^L
          RFC 1147    FYI: Network Management Tool Catalog  April 1990



          curses                          DOS
               Internet Rover                  Comp. Security Checklist
               net_monitor                     ConnectVIEW
               nfswatch                        hammer
               osimon                          hopcheck
               snmpperfmon                     LAN Patrol
                                               LANWatch
                                               netmon (I)
          debugger                             NETMON (III)
               SPIMS                           netwatch
                                               OverVIEW
                                               ping
          DECnet                               Snmp Libraries
               decaddrs                        snmpd (II)
               LANWatch                        TokenVIEW
               NETMON (III)                    XNETMON (II)
               net_monitor                     xnetperfmon
               NMC
               Sniffer
               Snmp Libraries             eavesdrop
               SpiderMonitor                   ENTM
               XNETMON (II)                    etherfind
               xnetperfmon                     EtherView
                                               LAN Patrol
                                               LanProbe
          DNS                                  LANWatch
               DiG                             NETMON (II)
               LANWatch                        netwatch
               netmon (I)                      nfswatch
               nslookup                        NNStat
                                               OSITRACE
                                               Sniffer
                                               SpiderMonitor
                                               Tcplogger
                                               TRPT















          IETF NOCTools Working Group                        [Page 10]
^L
          RFC 1147    FYI: Network Management Tool Catalog  April 1990



          ethernet                        free
               arp                             arp
               ConnectVIEW                     CMIP Library
               ENTM                            CMU SNMP
               etherfind                       DiG
               etherhostprobe                  ENTM
               EtherMeter                      etherhostprobe
               EtherView                       hammer
               LAN Patrol                      hopcheck
               LanProbe                        HyperMIB
               LANWatch                        Internet Rover
               map                             map
               NETMON (III)                    netmon (I)
               netwatch                        NETMON (II)
               Network Integrator              netstat
               nfswatch                        netwatch
               NMC                             net_monitor
               NNStat                          nfswatch
               proxyd                          nhfsstone
               SERAG                           NNStat
               Sniffer                         NPRV
               Snmp Libraries                  nslookup
               snmpd (II)                      osilog
               SpiderMonitor                   osimic
               tcpdump                         osimon
               Unisys NCC                      OSITRACE
               WIN/MGT Station                 ping
               XNETMON (II)                    query
               xnetperfmon                     sma
                                               SNMP Kit
                                               tcpdump
          FDDI                                 tcplogger
               Unisys NCC                      traceroute
                                               TRPT
                                               TTCP


                                          generator
                                               hammer
                                               nhfsstone
                                               ping
                                               Sniffer
                                               SpiderMonitor
                                               spray
                                               TTCP
                                               Unisys NCC




          IETF NOCTools Working Group                        [Page 11]
^L
          RFC 1147    FYI: Network Management Tool Catalog  April 1990



          HP                              IP
               xup                             arp
                                               CMU SNMP
                                               Dual Manager
                                               ENTM
                                               etherfind
                                               etherhostprobe
                                               EtherView
                                               getone
                                               hammer
                                               hopcheck
                                               Internet Rover
                                               LANWatch
                                               map
                                               Netlabs CMOT Agent
                                               Netlabs SNMP Agent
                                               netmon (I)
                                               NETMON (II)
                                               NETMON (III)
                                               netstat
                                               netwatch
                                               net_monitor
                                               nfswatch
                                               NMC
                                               NNStat
                                               NPRV
                                               OverVIEW
                                               ping
                                               proxyd
                                               query
                                               SERAG
                                               Sniffer
                                               SNMP Kit
                                               Snmp Libraries
                                               snmpask
                                               snmpd (I)
                                               snmpd (II)
                                               snmplookup
                                               snmpperfmon
                                               snmppoll
                                               snmpquery
                                               snmproute
                                               snmpset
                                               snmpsrc
                                               snmpstat
                                               snmptrapd
                                               snmpwatch



          IETF NOCTools Working Group                        [Page 12]
^L
          RFC 1147    FYI: Network Management Tool Catalog  April 1990


               snmpxbar
               snmpxconn                  manager
               snmpxmon                        CMIP Library
               snmpxperf                       CMU SNMP
               snmpxperfmon                    ConnectVIEW
               snmpxrtmetric                   decaddrs
               SpiderMonitor                   Dual Manager
               SPIMS                           getone
               spray                           LanProbe
               Tcpdump                         map
               Tcplogger                       Netlabs CMOT Agent
               Traceroute                      Netlabs SNMP Agent
               TRPT                            NETMON (III)
               TTCP                            NMC
               Unisys NCC                      NNStat
               WIN/MGT Station                 osilog
               xnetmon (I)                     osimic
               XNETMON (II)                    osimon
               xnetperfmon                     OverVIEW
                                               sma
                                               SNMP Kit
          library                              Snmp Libraries
               CMIP Library                    snmpask
               Dual Manager                    snmpd (I)
               LANWatch                        snmpd (II)
               proxyd                          snmplookup
               WIN/MGT Station                 snmpperfmon
                                               snmppoll
                                               snmpquery
          Macintosh                            snmproute
               HyperMIB                        snmpsrc
                                               snmpset
                                               snmpstat
                                               snmptrapd
                                               snmpwatch
                                               snmpxbar
                                               snmpxconn
                                               snmpxmon
                                               snmpxperf
                                               snmpxperfmon
                                               snmpxrtmetric
                                               TokenVIEW
                                               Unisys NCC
                                               WIN/MGT Station
                                               xnetmon (I)
                                               XNETMON (II)
                                               xnetperfmon




          IETF NOCTools Working Group                        [Page 13]
^L
          RFC 1147    FYI: Network Management Tool Catalog  April 1990



          map                             NMS
               decaddrs                        CMU SNMP
               etherhostprobe                  ConnectVIEW
               EtherMeter                      decaddrs
               LanProbe                        Dual Manager
               map                             EtherMeter
               NETMON (III)                    getone
               Network Integrator              LanProbe
               NPRV                            map
               Snmp Libraries                  Netlabs CMOT Agent
               snmpxconn                       Netlabs SNMP Agent
               snmpxmon                        NETMON (III)
               Unisys NCC                      NMC
               xnetmon (I)                     NNStat
               XNETMON (II)                    OverVIEW
                                               proxyd
                                               SERAG
          NFS                                  SNMP Kit
               etherfind                       Snmp Libraries
               EtherView                       snmpask
               nfswatch                        snmpd (I)
               nhfsstone                       snmpd (II)
               Sniffer                         snmplookup
               tcpdump                         snmpperfmon
                                               snmppoll
                                               snmpquery
                                               snmproute
                                               snmpset
                                               snmpsrc
                                               snmpstat
                                               snmptrapd
                                               snmpwatch
                                               snmpxbar
                                               snmpxconn
                                               snmpxmon
                                               snmpxperf
                                               snmpxperfmon
                                               snmpxrtmetric
                                               TokenVIEW
                                               Unisys NCC
                                               WIN/MGT Station
                                               xnetmon (I)
                                               XNETMON (II)
                                               xnetperfmon






          IETF NOCTools Working Group                        [Page 14]
^L
          RFC 1147    FYI: Network Management Tool Catalog  April 1990



          OSI                             ring
               CMIP Library                    ConnectVIEW
               Dual Manager                    LANWatch
               LANWatch                        map
               Netlabs CMOT Agent              NETMON (III)
               NETMON (III)                    netwatch
               osilog                          proxyd
               osimic                          Sniffer
               osimon                          Snmp Libraries
               OSITRACE                        snmpd (II)
               sma                             TokenVIEW
               Sniffer                         XNETMON (II)
               Snmp Libraries                  xnetperfmon
               SpiderMonitor
               SPIMS
               XNETMON (II)               routing
               xnetperfmon                     arp
                                               ConnectVIEW
                                               decaddrs
          ping                                 etherhostprobe
               etherhostprobe                  getone
               hopcheck                        hopcheck
               Internet Rover                  NETMON (III)
               map                             netstat
               netmon (I)                      net_monitor
               net_monitor                     NMC
               NPRV                            NPRV
               ping                            query
               spray                           Snmp Libraries
               traceroute                      snmproute
               TTCP                            snmpsrc
               Unisys NCC                      snmpxrtmetric
               xup                             traceroute
                                               WIN/MGT Station
                                               XNETMON (II)
          proprietary
               ConnectVIEW
               EtherMeter                 security
               LanProbe                        Comp. Security Checklist
               SERAG                           ConnectVIEW
               TokenVIEW                       Dual Manager
                                               LAN Patrol
                                               SERAG
          reference                            XNETMON (II)
               HyperMIB
               Unisys NCC




          IETF NOCTools Working Group                        [Page 15]
^L
          RFC 1147    FYI: Network Management Tool Catalog  April 1990



          SMTP                            sourcelib
               Internet Rover                  CMIP Library
               LANWatch                        CMU SNMP
               mconnect                        HyperMIB
               Sniffer                         Internet Rover
                                               LANWatch
                                               map
          SNMP                                 NETMON (III)
               CMU SNMP                        net_monitor
               decaddrs                        proxyd
               Dual Manager                    SNMP Kit
               getone                          Snmp Libraries
               map                             Snmpd (II)
               Netlabs SNMP Agent              SpiderMonitor
               NETMON (III)                    XNETMON (II)
               NMC                             xnetperfmon
               OverVIEW
               proxyd
               SNMP Kit                   spoof
               Snmp Libraries                  DiG
               snmpask                         Internet Rover
               snmpd (I)                       mconnect
               snmpd (II)                      nhfsstone
               snmplookup                      nslookup
               snmpperfmon                     query
               snmppoll                        SPIMS
               snmpquery
               snmproute
               snmpset                    standalone
               snmpsrc                         EtherMeter
               snmpstat                        Sniffer
               snmptrapd                       SpiderMonitor
               snmpwatch
               snmpxbar
               snmpxconn                  star
               snmpxmon                        LAN Patrol
               snmpxperf                       LANWatch
               snmpxperfmon                    map
               snmpxrtmetric                   NETMON (III)
               Unisys NCC                      proxyd
               WIN/MGT Station                 Sniffer
               xnetmon (I)                     Snmp Libraries
               XNETMON (II)                    snmpd (II)
               xnetperfmon                     XNETMON (II)
                                               xnetperfmon





          IETF NOCTools Working Group                        [Page 16]
^L
          RFC 1147    FYI: Network Management Tool Catalog  April 1990



          status                          traffic
               CMIP Library                    ENTM
               CMU SNMP                        etherfind
               ConnectVIEW                     EtherMeter
               DiG                             EtherView
               Dual Manager                    LAN Patrol
               getone                          LanProbe
               Internet Rover                  LANWatch
               LanProbe                        NETMON (II)
               mconnect                        netwatch
               Netlabs CMOT Agent              Network Integrator
               Netlabs SNMP Agent              nfswatch
               netmon (I)                      NMC
               net_monitor                     NNStat
               NMC                             osimon
               NNStat                          OSITRACE
               NPRV                            Sniffer
               nslookup                        snmpxperfmon
               osimic                          SpiderMonitor
               osimon                          tcpdump
               OverVIEW                        tcplogger
               ping                            TRPT
               proxyd                          Unisys NCC
               sma                             WIN/MGT Station
               SNMP Kit
               Snmp Libraries
               snmpask
               snmpd (I)
               snmpd (II)
               snmplookup
               snmpperfmon
               snmppoll
               snmpquery
               snmpstat
               snmpwatch
               snmpxbar
               snmpxconn
               snmpxmon
               snmpxperf
               snmpxperfmon
               TokenVIEW
               Unisys NCC
               WIN/MGT Station
               xnetmon (I)
               XNETMON (II)
               xnetperfmon
               xup



          IETF NOCTools Working Group                        [Page 17]
^L
          RFC 1147    FYI: Network Management Tool Catalog  April 1990


                                               snmpxbar
          UNIX                                 snmpxconn
               arp                             snmpxmon
               CMIP Library                    snmpxperf
               CMU SNMP                        snmpxperfmon
               decaddrs                        snmpxrtmetric
               DiG                             SPIMS
               Dual Manager                    spray
               etherfind                       tcpdump
               etherhostprobe                  tcplogger
               EtherView                       traceroute
               getone                          TRPT
               Internet Rover                  TTCP
               map                             Unisys NCC
               mconnect                        WIN/MGT Station
               NETMON (II)                     xnetmon (I)
               netstat                         XNETMON (II)
               Network Integrator              xnetperfmon
               net_monitor
               nfswatch
               nhfsstone                  VMS
               NMC                             arp
               NNStat                          ENTM
               nslookup                        netstat
               osilog                          net_monitor
               osimic                          NPRV
               osimon                          nslookup
               OSITRACE                        ping
               ping                            Snmp Libraries
               proxyd                          tcpdump
               query                           traceroute
               SERAG                           TTCP
               sma                             XNETMON (II)
               SNMP Kit                        xnetperfmon
               Snmp Libraries
               snmpask
               snmpd (I)
               snmpd (II)
               snmplookup
               snmpperfmon
               snmppoll
               snmpquery
               snmproute
               snmpset
               snmpsrc
               snmpstat
               snmptrapd
               snmpwatch



          IETF NOCTools Working Group                        [Page 18]
^L
          RFC 1147    FYI: Network Management Tool Catalog  April 1990



          X
               Dual Manager
               map
               snmpxbar
               snmpxconn
               snmpxmon
               snmpxperf
               snmpxperfmon
               snmpxrtmetric
               WIN/MGT Station
               XNETMON (II)
               xnetperfmon
               xup





































          IETF NOCTools Working Group                        [Page 19]
^L
          RFC 1147    FYI: Network Management Tool Catalog  April 1990


          3. Tool Descriptions

          This section is a collection of brief descriptions of tools
          for managing TCP/IP internets.  These entries are in alpha-
          betical order, by tool name.

          The entries all follow a standard format.  Immediately after
          the NAME of a tool are its associated KEYWORDS.  Keywords
          are terse descriptions of the purposes or attributes of a
          tool.  A more detailed description of a tool's purpose and
          characteristics is given in the ABSTRACT section.  The
          MECHANISM section describes how a tool works.  In CAVEATS,
          warnings about tool use are given.  In BUGS, known bugs or
          bug-report procedures are given.  LIMITATIONS describes the
          boundaries of a tool's capabilities.  HARDWARE REQUIRED and
          SOFTWARE REQUIRED relate the operational environment a tool
          needs.  Finally, in AVAILABILITY, pointers to vendors,
          online repositories, or other sources for a tool are given.

          We deal with the problem of tool-name clashes -- different
          tools that have the same name -- by appending parenthetical
          roman numerals to the names.  For example, BYU, MITRE, and
          SNMP Research each submitted a description of a tool called
          "NETMON." These tools were independently developed, are
          functionally different, run in different environments, and
          are no more related than Richard Burton the 19th century
          explorer and Richard Burton the 20th century actor.  BYU's
          tool "NETMON" is listed as "NETMON (I)," MITRE's as "NETMON
          (II)," and the tool from SNMP Research as "NETMON (III)."

          The parenthetical roman numerals reveal only the order in
          which the catalog editor received the tool descriptions.
          They should not be construed to indicate any sort of prefer-
          ence, priority, or rights to a tool name.

















          IETF NOCTools Working Group                        [Page 20]
^L
          Internet Tool Catalog                                    ARP


          NAME
               arp

          KEYWORDS
               routing; ethernet, IP; UNIX, VMS; free.

          ABSTRACT
               Arp displays and can modify the internet-to-ethernet
               address translations tables used by ARP, the address
               resolution protocol.

          MECHANISM
               The arp program accesses operating system memory to
               read the ARP data structures.

          CAVEATS
               None.

          BUGS
               None known.

          LIMITATIONS
               Only the super user can modify ARP entries.

          HARDWARE REQUIRED
               No restrictions.

          SOFTWARE REQUIRED
               BSD UNIX or related OS, or VMS.

          AVAILABILITY
               Available via anonymous FTP from uunet.uu.net, in
               directory bsd-sources/src/etc.  Available with 4.xBSD
               UNIX and related operating systems.  For VMS, available
               as part of TGV MultiNet IP software package, as well as
               Wollongong's WIN/TCP.















          IETF NOCTools Working Group                        [Page 21]
^L
          Internet Tool Catalog                           CMIP LIBRARY


          NAME
               CMIP Library

          KEYWORDS
               alarm, control, manager, status; OSI; UNIX; free,
               library, sourcelib.

          ABSTRACT
               The CMIP Library implements the functionality of the
               Common Management Information Service/Protocol as in
               the documents ISO DP 9595-2/9596-2 of March 1988.  It
               can act as a building block for the construction of
               CMIP-based agent and manager applications.

          MECHANISM
               The CMIP library uses ISO ROS, ACSE and ASN.1 presenta-
               tion, as implemented in ISODE, to provide its service.

          CAVEATS
               None.

          BUGS
               None known.

          LIMITATIONS
               The M-CREATE, M-DELETE and M-ACTION protocol primitives
               are not implemented in this version.

          HARDWARE REQUIRED
               Developed on Sun3, tested on Sun3 and VAXStation.

          SOFTWARE REQUIRED
               The ISODE protocol suite, BSD UNIX.

          AVAILABILITY
               The CMIP library and related management tools built
               upon it, known as OSIMIS (OSI Management Information
               Service), are publicly available from University Col-
               lege London, England via FTP and FTAM.  To obtain
               information regarding a copy send email to
               gknight@ac.ucl.cs.uk or call +44 1 380 7366.










          IETF NOCTools Working Group                        [Page 22]
^L
          Internet Tool Catalog                               CMU SNMP


          NAME
               The CMU SNMP Distribution

          KEYWORDS
               manager, status; IP; NMS, SNMP; UNIX; free, sourcelib.

          ABSTRACT
               The CMU SNMP Distribution includes source code for an
               SNMP agent, several SNMP client applications, an ASN.1
               library, and supporting documentation.

               The agent compiles into about 10 KB of 68000 code.  The
               distribution includes a full agent that runs on a
               Kinetics FastPath2/3/4, and is built into the KIP
               appletalk/ethernet gateway.  The machine independent
               portions of this agent also run on CMU's IBM PC/AT
               based router.

               The applications are designed to be useful in the real
               world.  Information is collected and presented in a
               useful format and is suitable for everyday status moni-
               toring.  Input and output are interpreted symbolically.
               The tools can be used without referencing the RFCs.

          MECHANISM
               SNMP.

          CAVEATS
               None.

          BUGS
               None reported.  Send bug reports to
               sw0l+snmp@andrew.cmu.edu.  ("sw0l" is "ess double-you
               zero ell.")

          LIMITATIONS
               None reported.

          HARDWARE REQUIRED
               The KIP gateway agent runs on a Kinetics FastPath2/3/4.
               Otherwise, no restrictions.

          SOFTWARE REQUIRED
               The code was written with efficiency and portability in
               mind.  The applications compile and run on the follow-
               ing systems: IBM PC/RT running ACIS Release 3, Sun3/50
               running SUNOS 3.5, and the DEC microVax running Ultrix
               2.2.  They are expected to run on any system with a



          IETF NOCTools Working Group                        [Page 23]
^L
          Internet Tool Catalog                               CMU SNMP


               Berkeley socket interface.

          AVAILABILITY
               This distribution is copyrighted by CMU, but may be
               used and sold without permission.  Consult the copy-
               right notices for further information.  The distribu-
               tion is available by anonymous FTP from the host
               lancaster.andrew.cmu.edu (128.2.13.21) as the files
               pub/cmu-snmp.9.tar, and pub/kip-snmp.9.tar.  The former
               includes the libraries and the applications, and the
               latter is the KIP SNMP agent.

               Please direct questions, comments, and bug reports to
               sw0l+snmp@andrew.cmu.edu.  ("sw0l" is "ess double-you
               zero ell.")  If you pick up this package, please send a
               note to the above address, so that you may be notified
               of future enhancements/changes and additions to the set
               of applications (several are planned).

































          IETF NOCTools Working Group                        [Page 24]
^L
          Internet Tool Catalog            COMPUTER SECURITY CHECKLIST


          NAME
               Computer Security Checklist

          KEYWORDS
               security; DOS.

          ABSTRACT
               This program consists of 858 computer security ques-
               tions divided up in thirteen sections.  The program
               presents the questions to the user and records their
               responses.  After answering the questions in one of the
               thirteen sections, the user can generate a report from
               the questions and the user's answers.  The thirteen
               sections are: telecommunications security, physical
               access security, personnel security, systems develop-
               ment security, security awareness and training prac-
               tices, organizational and management security, data and
               program security, processing and operations security,
               ergonomics and error prevention, environmental secu-
               rity, and backup and recovery security.

               The questions are weighted as to their importance, and
               the report generator can sort the questions by weight.
               This way the most important issues can be tackled
               first.

          MECHANISM
               The questions are displayed on the screen and the user
               is prompted for a single keystroke reply.  When the end
               of one of the thirteen sections is reached, the answers
               are written to a disk file.  The question file and the
               answer file are merged to create the report file.

          CAVEATS
               None.

          BUGS
               None known.

          LIMITATIONS
               None reported.

          HARDWARE REQUIRED
               No restrictions.

          SOFTWARE REQUIRED
               DOS operating system.




          IETF NOCTools Working Group                        [Page 25]
^L
          Internet Tool Catalog            COMPUTER SECURITY CHECKLIST



          AVAILABILITY
               A commercial product available from:
                    C.D., Ltd.
                    P.O. Box 58363
                    Seattle, WA 98138
                    (206) 243-8700












































          IETF NOCTools Working Group                        [Page 26]
^L
          Internet Tool Catalog                            CONNECTVIEW


          NAME
               ConnectVIEW

          KEYWORDS
               control, manager, routing, security, status; bridge,
               ethernet, ring; NMS, proprietary; DOS.

          ABSTRACT
               The ConnectVIEW Network Management System consists of
               various software managers that control and manage Hal-
               ley System's internets made of of ConnectLAN 100 ether-
               net and ConnectLAN 200 Token Ring Brouters.  The
               management software provides an icon-based graphical
               network display with real-time monitoring and report-
               ing, along with configuration, fault, performance and
               security management functions for managing ConnectLAN
               brouters.  A Planning function is also provided that
               allows users to draw their networks.

          MECHANISM
               Proprietary.

          CAVEATS
               The ConnectVIEW software must be running under Micro-
               soft Windows, preferably on a dedicated management sta-
               tion.  There is, however, no degradation of LAN
               throughput.

          BUGS
               None known.

          LIMITATIONS
               Currently works only with Halley System's products.

          HARDWARE REQUIRED
               Requires a PC/AT compatible, with 640KB RAM, EGA
               adapter and monitor, keyboard, mouse, and ethernet
               adapter.

          SOFTWARE REQUIRED
               MSDOS 3.3 or higher.  Microsoft Windows/286 version
               2.1.

          AVAILABILITY
               Commercially available from:
                    Halley Systems, Inc.
                    2730 Orchard Parkway
                    San Jose, CA  95134



          IETF NOCTools Working Group                        [Page 27]
^L
          Internet Tool Catalog                            CONNECTVIEW


          NAME
               decaddrs, decaroute, decnroute, xnsroutes, bridgetab

          KEYWORDS
               manager, map, routing; bridge, DECnet; NMS, SNMP; UNIX.

          ABSTRACT
               These commands display private MIB information from
               Wellfleet systems.  They retrieve and format for
               display values of one or several MIB variables from the
               Wellfleet Communications private enterprise MIB, using
               the SNMP (RFC1098).  In particular these tools are used
               to examine the non-IP modules (DECnet, XNS, and Bridg-
               ing) of a Wellfleet system.

               Decaddrs displays the DECnet configuration of a
               Wellfleet system acting as a DECnet router, showing the
               static parameters associated with each DECnet inter-
               face.  Decaroute and decnroute display the DECnet
               inter-area and intra-area routing tables (that is area
               routes and node routes).  Xnsroutes displays routes
               known to a Wellfleet system acting as an XNS router.
               Bridgetab displays the bridge forwarding table with the
               disposition of traffic arriving from or directed to
               each station known to the Wellfleet bridge module.  All
               these commands take an IP address as the argument and
               can specify an SNMP community for the retrieval.  One
               SNMP query is performed for each row of the table.
               Note that the Wellfleet system must be operating as an
               IP router for the SNMP to be accessible.

          MECHANISM
               Management information is exchanged by use of SNMP.

          CAVEATS
               None.

          BUGS
               None known.

          LIMITATIONS
               None reported.

          HARDWARE REQUIRED
               Distributed and supported for Sun 3 systems.

          SOFTWARE REQUIRED
               Distributed and supported for SunOS 3.5 and 4.x.



          IETF NOCTools Working Group                        [Page 28]
^L
          Internet Tool Catalog            DECADDRS, DECAROUTE, et al.



          AVAILABILITY
               Commercial product of:
                    Wellfleet Communications, Inc.
                    12 DeAngelo Drive
                    Bedford, MA 01730-2204
                    (617) 275-2400












































          IETF NOCTools Working Group                        [Page 29]
^L
          Internet Tool Catalog                                    DIG


          NAME
               DiG

          KEYWORDS
               status; DNS; spoof; UNIX; free.

          ABSTRACT
               DiG (domain information groper), is a command line tool
               which queries DNS servers in either an interactive or a
               batch mode.  It was developed to be more
               convenient/flexible than nslookup for gathering perfor-
               mance data and testing DNS servers.

          MECHANISM
               Dig is built on a slightly modified version of the bind
               resolver (release 4.8).

          CAVEATS
               none.

          BUGS
               None known.

          LIMITATIONS
               None reported.

          HARDWARE REQUIRED
               No restrictions.

          SOFTWARE REQUIRED
               BSD UNIX.

          AVAILABILITY
               DiG is available via anonymous FTP from venera.isi.edu
               in pub/dig.1.0.tar.Z.
















          IETF NOCTools Working Group                        [Page 30]
^L
          Internet Tool Catalog                           DUAL MANAGER


          NAME
               Dual Manager

          KEYWORDS
               alarm, control, manager, map, security, status; IP,
               OSI; NMS, SNMP, X; UNIX; library.

          ABSTRACT
               Netlabs' Dual Manager provides management of TCP/IP
               networks using both SNMP and CMOT protocols.  Such
               management can be initiated either through the X-
               Windows user interface (both Motif and Openlook), or
               through OSI Network Management (CMIP) commands.  The
               Dual Manager provides for configuration, fault, secu-
               rity and performance management.  It provides extensive
               map management features, including scanned maps in the
               background.  It provides simple mechanisms to extend
               the MIB and assign specific lists of objects to
               specific network elements, thereby providing for the
               management of all vendors' specific MIB extensions.  It
               provides an optional relational DBMS for storing and
               retrieving MIB and alarm information.  Finally, the
               Dual Manager is an open platform, in that it provides
               several Application Programming Interfaces (APIs) for
               users to extend the functionality of the Dual Manager.

               The Dual Manager is expected to work as a TCP/IP
               "branch manager" under DEC's EMA, AT&T's UNMA and other
               OSI-conformant enterprise management architectures.

          MECHANISM
               The Netlabs Dual Manager supports the control and moni-
               toring of network resources by use of both CMOT and
               SNMP message exchanges.

          CAVEATS
               None.

          BUGS
               None known.

          LIMITATIONS
               None reported.

          HARDWARE REQUIRED
               Runs on Sun/3 and Sun/4s.





          IETF NOCTools Working Group                        [Page 31]
^L
          Internet Tool Catalog                           DUAL MANAGER



          SOFTWARE REQUIRED
               Available on System V or SCO Open Desktop environments.
               Uses X-Windows for the user interface.

          AVAILABILITY
               Commercially available from:
                    Netlabs Inc
                    11693 Chenault Street Ste 348
                    Los Angeles CA 90049
                    (213) 476-4070
                    lam@netlabs.com (Anne Lam)







































          IETF NOCTools Working Group                        [Page 32]
^L
          Internet Tool Catalog                                   ENTM


          NAME
               ENTM -- Ethernet Traffic Monitor

          KEYWORDS
               traffic; ethernet, IP; eavesdrop; VMS; free.

          ABSTRACT
               ENTM is a screen-oriented utility that runs under
               VAX/VMS.  It monitors local ethernet traffic and
               displays either a real time or cumulative, histogram
               showing a percent breakdown of traffic by ethernet pro-
               tocol type.  The information in the display can be
               reported based on packet count or byte count.  The per-
               cent of broadcast, multicast and approximate lost pack-
               ets is reported as well.  The screen display is updated
               every three seconds.  Additionally, a real time, slid-
               ing history window may be displayed showing ethernet
               traffic patterns for the last five minutes.

               ENTM can also report IP traffic statistics by packet
               count or byte count.  The IP histograms reflect infor-
               mation collected at the TCP and UDP port level, includ-
               ing ICMP type/code combinations.  Both the ethernet and
               IP histograms may be sorted by ASCII protocol/port name
               or by percent-value.  All screen displays can be saved
               in a file for printing later.

          MECHANISM
               This utility simply places the ethernet controller in
               promiscuous mode and monitors the local area network
               traffic.  It preallocates 10 receive buffers and
               attempts to keep 22 reads pending on the ethernet dev-
               ice.

          CAVEATS
               Placing the ethernet controller in promiscuous mode may
               severly slow down a VAX system.  Depending on the speed
               of the VAX system and the amount of traffic on the  lo-
               cal  ethernet,  a large amount of CPU time may be spent
               on the Interrupt Stack.  Running this code on any  pro-
               duction system during operational hours is discouraged.










          IETF NOCTools Working Group                        [Page 33]
^L
          Internet Tool Catalog                                   ENTM



          BUGS
               Due to a bug in the VAX/VMS ethernet/802 device driver,
               IEEE  802 format packets may not always be detected.  A
               simple test is performed to "guess" which  packets  are
               in  IEEE  802  format (DSAP equal to SSAP).  Thus, some
               DSAP/SSAP pairs may be reported as  an  ethernet  type,
               while  valid ethernet types may be reported as IEEE 802
               packets.

               In some hardware configurations, placing an ethernet
               controller in promiscuous mode with automatic-restart
               enabled will hang the controller.  Our VAX 8650 hangs
               running this code, while our uVAX IIs and uVAX IIIs do
               not.

               Please report any additional bugs to the author at:
                    Allen Sturtevant
                    National Magnetic Fusion Energy Computer Center
                    Lawrence Livermore National Laboratory
                    P.O. Box 808; L-561
                    Livermore, CA  94550
                    Phone : (415) 422-8266
                    E-Mail: sturtevant@ccc.nmfecc.gov

          LIMITATIONS
               The user is required to have PHY_IO, TMPMBX and NETMBX
               privileges.  When activated, the program first checks
               that the user process as enough quotas remaining
               (BYTLM, BIOLM, ASTLM and PAGFLQUO) to successfully run
               the program without entering into an involuntary wait
               state.  Some quotas require a fairly generous setting.

               The contents of IEEE 802 packets are not examined.
               Only the presence of IEEE 802 packets on the wire is
               reported.

               The count of lost packets is approximated.  If, after
               each read completes on the ethernet device, the utility
               detects that it has no reads pending on that device,
               the lost packet counter is incremented by one.

               When the total number of bytes processed exceeds
               7fffffff hex, all counters are automatically reset to
               zero.

          HARDWARE REQUIRED
               A DEC ethernet controller.



          IETF NOCTools Working Group                        [Page 34]
^L
          Internet Tool Catalog                                   ENTM



          SOFTWARE REQUIRED
               VAX/VMS version V5.1+.

          AVAILABILITY
               For executables only,  FTP  to  the  ANONYMOUS  account
               (password  GUEST) on CCC.NMFECC.GOV and GET the follow-
               ing files:

               [ANONYMOUS.PROGRAMS.ENTM]ENTM.DOC     (ASCII text)
               [ANONYMOUS.PROGRAMS.ENTM]ENTM.EXE     (binary)
               [ANONYMOUS.PROGRAMS.ENTM]EN_TYPES.DAT (ASCII text)
               [ANONYMOUS.PROGRAMS.ENTM]IP_TYPES.DAT (ASCII text)






































          IETF NOCTools Working Group                        [Page 35]
^L
          Internet Tool Catalog                              ETHERFIND


          NAME
               etherfind

          KEYWORDS
               traffic; ethernet, IP, NFS; eavesdrop; UNIX.

          ABSTRACT
               Etherfind examines the packets that traverse a network
               interface, and outputs a text file describing the
               traffic.  In the file, a single line of text describes
               a single packet: it contains values such as protocol
               type, length, source, and destination.  Etherfind can
               print out all packet traffic on the ethernet, or
               traffic for the local host.  Further packet filtering
               can be done on the basis of protocol: IP, ARP, RARP,
               ICMP, UDP, ND, TCP, and filtering can also be done
               based on the source, destination addresses as well as
               TCP and UDP port numbers.

          MECHANISM
               In usual operations, and by default, etherfind puts the
               interface in promiscuous mode.  In 4.3BSD UNIX and
               related OSs, it uses a Network Interface Tap (NIT) to
               obtain a copy of traffic on an ethernet interface.

          CAVEATS
               None.

          BUGS
               None known.

          LIMITATIONS
               Minimal protocol information is printed.  Can  only  be
               run by the super user.  The syntax is painful.

          HARDWARE REQUIRED
               Ethernet.

          SOFTWARE REQUIRED
               SunOS.

          AVAILABILITY
               Executable included in Sun  OS  "Networking  Tools  and
               Programs" software installation option.







          IETF NOCTools Working Group                        [Page 36]
^L
          Internet Tool Catalog                         ETHERHOSTPROBE


          NAME
               etherhostprobe

          KEYWORDS
               map, routing; ethernet, IP; ping; UNIX; free.

          ABSTRACT
               Output list of hosts on an ethernet that respond to IP
               ARP.  Produces a list in the following format:

                    08:00:20:01:96:62   128.18.4.114    apptek4
                    08:00:20:00:02:fe   128.18.4.115    apptek5
                    08:00:20:00:57:6a   128.18.4.116    apptek6
                    08:00:20:00:65:34   128.18.4.117    apptek7
                    08:00:20:06:58:6f   128.18.4.118    apptek8
                    08:00:20:00:03:4f   128.18.4.119    apptek9

               The first column is the ethernet address, the second
               the IP address, and the third is the hostname (which is
               omitted if the name could not be found via gethost-
               byaddr).  A starting and ending IP address may be
               specified on the command line, which will limit the
               search.

          MECHANISM
               Etherhostprobe sends a UDP packet to the ``echo'' port,
               then looks in the kernel's ARP cache for the
               corresponding address entry.  Explicit response (or
               lack of same) to the UDP packet is ignored.  The cache
               will be checked up to four times at one-quarter-second
               intervals.  Note that this allows the program to be run
               by a user with no special privileges.

          CAVEATS
               Etherhostprobe will fill the kernel's ARP cache with
               possibly useless entries, possibly causing delays to
               programs foolishly attempting to accomplish real work.

               Etherhostprobe causes -lots- of ARPs to be generated,
               possibly fooling network monitoring software (or peo-
               ple) into concluding that something is horribly broken.

               Etherhostprobe spends up to one second looking for each
               possible address.  Thus, exhaustively searching a
               class-C network will take about four minutes, and
               exhaustively searching a class-B network will take
               about 18 hours.  Exhaustively searching a class-A net-
               work will take the better part of a year, so don't even



          IETF NOCTools Working Group                        [Page 37]
^L
          Internet Tool Catalog                         ETHERHOSTPROBE


               think about it.

               Etherhostprobe will be fooled by gateways that imple-
               ment proxy ARP; every possible address on the proxy-
               ARPed subnet will be listed with the gateway's ethernet
               address.

          BUGS
               None known.

          LIMITATIONS
               If a given machine is not running IP ARP at the time
               that it is probed, it will be considered nonexistent.
               In particular, if a given machine is down at the time
               that it is probed . . .

               All hosts being probed must be on the same (possibly
               bridged) ethernet.

          HARDWARE REQUIRED
               No restrictions, but see below.

          SOFTWARE REQUIRED
               Runs on SunOS 3.5, and possibly elsewhere.  The major
               non-standard portion of code is ``tx_arp.c'', which
               reads the kernel's ARP cache.

          AVAILABILITY
               Copyrighted, but  freely  distributed.   Available  via
               anonymous  FTP  from  spam.itstd.sri.com (128.18.10.1).
               From pub directory, file EHP.1 for etherhostprobe,  and
               files IPF.1 and IPF.2 for ipForwarding.



















          IETF NOCTools Working Group                        [Page 38]
^L
          Internet Tool Catalog                             ETHERMETER


          NAME
               EtherMeter (tm), model LANB/150

          KEYWORDS
               alarm, map, traffic; ethernet; NMS, proprietary; stan-
               dalone.

          ABSTRACT
               The Network Applications Technology (NAT) EtherMeter
               product is a dedicated ethernet traffic monitor that
               provides statistics on the ethernet segment to which it
               is attached.  The EtherMeter reports three major kinds
               of statistics.  For good packets, it reports the total
               number of good packets seen on the segment, the number
               of multicast and broadcast packets, and the total
               number of bytes in all packets seen.  For packets with
               errors, it reports the number of CRC errors, short
               packets, oversize packets, and alignment errors.  It
               also reports the distribution of packet by type, and
               the number of protocols seen on the segment.  A count
               of transmit collisions is reported.  Peak and current
               ethernet utilization rates are also reported, etc.
               Alarms can be set for utilization rate, packet rate,
               total error count, and delta error.

               The EtherMeter reports the statistics to a Network
               Management Station (NMS), also available from NAT, via
               IP/UDP datagrams, so that the meters can be monitored
               through routers.  The NMS displays graphical and/or
               textual information, and EtherMeter icons turn colors
               to indicate status.  Alarms can be set, and if the lev-
               els are exceeded an audible alarm is generated on the
               NMS, and the EtherMeter icon changes from green to yel-
               low on the network map.

          MECHANISM
               The EtherMeter is a self-contained board that can
               either be plugged into a PC/AT bus for power or
               installed in a small stand-alone enclosure.  The board
               can be obtained with either a 10BASE5 thick ethernet
               transceiver cable connector, or a 10BASE2 thin ethernet
               BNC connector.

          CAVEATS
               The EtherMeter is primarily a passive device whose only
               impact  on  the  network  will come from the monitoring
               packets sent to the NMS.  The EtherMeter is assigned an
               IP address for communication with the NMS.



          IETF NOCTools Working Group                        [Page 39]
^L
          Internet Tool Catalog                             ETHERMETER



          BUGS
               None known.

          LIMITATIONS
               Proprietary protocol currently in use.  The company has
               stated its intention to develop SNMP for the EtherMeter
               product in the first half of 1990.  Currently the NMS
               does not keep log files.  This limitation is ack-
               nowledged, and plans are underway to add ASCII log file
               capability to the NMS.

          HARDWARE REQUIRED
               An EtherMeter board and a PC/AT bus to plug it into, or
               a stand-alone enclosure with power supply (available
               from NAT).  A Network Management Station and its
               software is required as well, to fully interact with
               the EtherMeter devices.

          SOFTWARE REQUIRED
               The EtherMeter software is included in ROM on the dev-
               ice.  The NMS software is bundled in with the NMS
               hardware.

          AVAILABILITY
               The EtherMeter device, stand-alone enclosure, and  Net-
               work  Management  Station,  are  available commercially
               from:

                    Network Application Technology, Inc.
                    21040 Homestead Road
                    Cupertino, California 95014
                    Phone: (408) 733-4530
                    Fax: (408) 733-6478

















          IETF NOCTools Working Group                        [Page 40]
^L
          Internet Tool Catalog                              ETHERVIEW


          NAME
               EtherView(tm)

          KEYWORDS
               traffic; ethernet, IP, NFS; eavesdrop; UNIX.

          ABSTRACT
               EtherView is a network monitoring tool which runs on
               Sun workstations and allows you to monitor your hetero-
               geneous internet network.  It monitors all systems on
               the ethernet.  It has three primary functions:

               Load Profile:  It allows users to monitor the load on
               the ethernet over extended periods of time.  The net-
               work administrator can use it to characterize load gen-
               erated by a node on the network, determine which sys-
               tems and applications generate how much of the load and
               how that load fluctuates over long periods of time.

               NFS Profile:  It allows the network administrator to
               determine the load on NFS servers, the average response
               time NFS servers and the mix of NFS load on each of the
               servers.  Users can use the data to benchmark different
               NFS servers, determine which servers are overloaded,
               deduce the number of clients that each server can sup-
               port and evaluate the effectiveness of NFS accelera-
               tors.

               Protocol Analyzer:  Users can capture packets based on
               source, destination, application, protocol, bit pat-
               tern, packet size or a boolean filtering expression.
               It provides all standard features such as configurable
               buffer size, packet slicing and bit pattern based
               triggering criterion.  It does automatic disassembly of
               NFS, TCP, UDP, IP, ICMP, ARP and RARP packets.  Packets
               can be examined in any combination of summary, hex or
               detail format.

          MECHANISM
               EtherView uses the Sun's NIT interface to turn the eth-
               ernet interface into promiscuous mode to capture pack-
               ets.  A high level process manages the interface and a
               low level process does the actual capturing and filter-
               ing.  Shared memory is used to communicate between the
               two processes.

          BUGS
               None known.



          IETF NOCTools Working Group                        [Page 41]
^L
          Internet Tool Catalog                              ETHERVIEW



          LIMITATIONS
               Because of limitations in Sun's NIT  interface,  Ether-
               View will not capture packets originating from the sys-
               tem where it is run.

               EtherView requires super-user privileges on the system
               where it is run.

          HARDWARE REQUIRED
               EtherView runs on all models of Sun-3, Sun-4 and Sun-
               386i.

          SOFTWARE REQUIRED
               Sun-3      - SunOS 4.0.3. (SunOS 4.0 with NIT fixes).
               Sun-4      - SunOS 4.0.
               Sun-386i   - SunOS 4.0.

               Runs under SunView.
               Will run under X Windows in future.

          AVAILABILITY
               EtherView is copyrighted, commercial product of:
                    Matrix Computer Systems, Inc.
                    7 1/2 Harris Road
                    Nashua, NH 03062

                    Tel: (603) 888-7790
                    email: ...uunet!matrix!eview






















          IETF NOCTools Working Group                        [Page 42]
^L
          Internet Tool Catalog                GETONE, GETMANY, et al.


          NAME
               getone, getmany, getroute, getarp, getaddr, getif,
               getid.

          KEYWORDS
               manager, routing, status; IP; NMS, SNMP; UNIX.

          ABSTRACT
               These commands retrieve and format for display values
               of one or several MIB variables (RFC1066) using the
               SNMP (RFC1098).  Getone and getmany retrieve arbitrary
               MIB variables; getroute, getarp, getaddr, and getif
               retrieve and display tabular information (routing
               tables, ARP table, interface configuration, etc.), and
               getid retrieves and displays system name, identifica-
               tion and boot time.

               Getone <target> <mibvariable> retrieves and displays
               the value of the designated MIB variable from the
               specified target system.  The SNMP community name to be
               used for the retrieval can also be specified.  Getmany
               works similarly for groups of MIB variables rather than
               individual values.  The name of each variable, its
               value and its data type is displayed.  Getroute returns
               information from the ipRoutingTable MIB structure,
               displaying the retrieved information in an accessible
               format.  Getarp behaves similarly for the address
               translation table; getaddr for the ipAddressTable; and
               getif displays information from the interfaces table,
               supplemented with information from the ipAddressTable.
               Getid displays the system name, identification, ipFor-
               warding state, and the boot time and date.  All take a
               system name or IP address as an argument and can
               specify an SNMP community for the retrieval.  One SNMP
               query is performed for each row of the table.

          MECHANISM
               Queries SNMP agent(s).

          CAVEATS
               None.

          BUGS
               None known.

          LIMITATIONS
               None reported.




          IETF NOCTools Working Group                        [Page 43]
^L
          Internet Tool Catalog                GETONE, GETMANY, et al.



          HARDWARE REQUIRED
               Distributed and supported for Sun 3 systems.

          SOFTWARE REQUIRED
               Distributed and supported for SunOS 3.5 and 4.x.

          AVAILABILITY
               Commercial product of:
                    Wellfleet Communications, Inc.
                    12 DeAngelo Drive
                    Bedford, MA 01730-2204
                    (617) 275-2400






































          IETF NOCTools Working Group                        [Page 44]
^L
          Internet Tool Catalog                         HAMMER & ANVIL


          NAME
               hammer & anvil

          KEYWORDS
               benchmark, generator; IP; DOS; free.

          ABSTRACT
               Hammer and anvil are the benchmarking programs for IP
               routers.  Using these tools, gateways have been tested
               for per-packet delay, router-generated traffic over-
               head, maximum sustained throughput, etc.

          MECHANISM
               Tests are performed on a gateway in an isolated
               testbed.  Hammer generates packets at controlled rates.
               It can set the length and interpacket interval of a
               packet stream.  Anvil counts packet arrivals.

          CAVEATS
               Hammer should not be run on a live network.

          BUGS
               None reported.

          LIMITATIONS
               Early versions of hammer could not produce inter-packet
               intervals shorter than 55 usec.

          HARDWARE REQUIRED
               Hammer runs on a PC/AT or compatible, and anvil
               requires a PC or clone.  Both use a Micom Interlan
               NI5210 for LAN interface.

          SOFTWARE REQUIRED
               MS-DOS.

          AVAILABILITY
               Hammer and anvil are copyrighted, though free.  Copies
               are available from pub/eutil on husc6.harvard.edu.












          IETF NOCTools Working Group                        [Page 45]
^L
          Internet Tool Catalog                               HOPCHECK


          NAME
               hopcheck

          KEYWORDS
               routing; IP; ping; DOS; free.

          ABSTRACT
               Hopcheck is a tool that lists the gateways traversed by
               packets sent from the hopcheck-resident PC to a desti-
               nation.  Hopcheck uses the same mechanism as traceroute
               but is for use on IBM PC compatibles that have ethernet
               connections.  Hopcheck is part of a larger TCP/IP pack-
               age that is known as ka9q that is for use with packet
               radio.  Ka9q can coexist on a PC with other TCP/IP
               packages such as FTP Inc's PC/TCP, but must be used
               independently of other packages.  Ka9q was written by
               Phil Karn.  Hopcheck was added by Katie Stevens,
               dkstevens@ucdavis.edu.  Unlike traceroute, which
               requires a UNIX kernel mod, hopcheck will run on the
               standard, unmodified ka9q release.

          MECHANISM
               See the description in traceroute.

          CAVEATS
               See the description in traceroute.

          BUGS
               None known.

          LIMITATIONS
               Host table required.  Does not work with domain name
               server or with IP address as the argument.  This is
               mainly an inconvenience.

          HARDWARE REQUIRED
               IBM PC compatible with ethernet network interface card,
               though does not work with 3Com 505 board.

          SOFTWARE REQUIRED
               DOS.










          IETF NOCTools Working Group                        [Page 46]
^L
          Internet Tool Catalog                               HOPCHECK



          AVAILABILITY
               Free.  On deposit at the National Center for Atmospher-
               ic  Research.   For  access  from  UNIX,  available via
               anonymous FTP from windom.ucar.edu, in directory "etc,"
               as  hopcheck.tar.Z.   For  access  directly  from a PC,
               fetch nethop.exe and readme.hop; nethop.exe is  execut-
               able.  Also available via anonymous FTP at ucdavis.edu,
               in the nethopexe or nethopsrc suite of files in  direc-
               tory "dist."









































          IETF NOCTools Working Group                        [Page 47]
^L
          Internet Tool Catalog                               HYPERMIB


          NAME
               HyperMIB

          KEYWORDS
               reference; Macintosh; free, sourcelib.

          ABSTRACT
               HyperMIB is a hypertext presentation of the MIB
               (RFC1066).  The tree structure of the MIB is presented
               graphically, and the user traverses the tree by select-
               ing branches of the tree.  When the MIB variables are
               displayed, selecting them causes a text window to
               appear and show the definition of that variable (using
               the actual text of the MIB document).

          MECHANISM
               The Apple Macintosh HyperCard utility is used.  The
               actual text of the MIB document is read into scrollable
               text windows, and a string search is done on the vari-
               able selected.  A person familiar with HyperCard pro-
               gramming could modify the program to suit their needs
               (such as to add the definitions for their company's
               private space).

          CAVEATS
               None.

          BUGS
               None known.

          LIMITATIONS
               This program only gives the definition of the MIB vari-
               ables.  It cannot poll a node to find the value of the
               variables.

          HARDWARE REQUIRED
               Apple Macintosh computer with at least 1MByte of RAM.

          SOFTWARE REQUIRED
               Apple Macintosh operating system and HyperCard.

          AVAILABILITY
               This software may be copied and given away without
               charge.  The files are available by anonymous FTP on
               CCC.NMFECC.GOV.  The files are:

               [Anonymous.programs.HyperMIB]Hyper_MIB.help  (ASCII text)
               [Anonymous.programs.HyperMIB]Hyper.MIB       (binary)



          IETF NOCTools Working Group                        [Page 48]
^L
          Internet Tool Catalog                               HYPERMIB


               [Anonymous.programs.HyperMIB]MIB.tree        (binary)

               The software is also available for a nominal fee from:

               National Energy Software Center
               Argonne National Laboratory
               9700 South Cass Avenue
               Argonne, Illinois 60439
               (312) 972-7250










































          IETF NOCTools Working Group                        [Page 49]
^L
          Internet Tool Catalog                         INTERNET ROVER


          NAME
               Internet Rover

          KEYWORDS
               status; IP, SMTP; curses, ping, spoof; UNIX; free,
               sourcelib.

          ABSTRACT
               Internet Rover is a prototype network monitor that uses
               multiple protocol "modules" to test network functional-
               ity.  This package consists of two primary pieces of
               code: the data collector and the problem display.

               There is one data collector that performs a series of
               network tests, and maintains a list of problems with
               the network.  There can be many display processes all
               displaying the current list of problems which is useful
               in a multi-operator NOC.

               The display task uses curses, allowing many terminal
               types to display the problem file either locally or
               from a remote site.  Full source is provided.  The data
               collector is easily configured and extensible.  Contri-
               butions such as additional protocol modules, and shell
               script extensions are welcome.

          MECHANISM
               A configuration file contains a list of nodes,
               addresses, NodeUp? protocol test (ping in most cases),
               and a list of further tests to be performed if the node
               is in fact up.  Modules are included to test TELNET,
               FTP, and SMTP.  If the configuration contains a test
               that isn't recognized, a generic test is assumed, and a
               filename is checked for existence.  This way users can
               create scripts that create a file if there is a prob-
               lem, and the data collector simply checks the existence
               of that file to determine if there is problem.

          CAVEATS
               None.

          BUGS
               None known.








          IETF NOCTools Working Group                        [Page 50]
^L
          Internet Tool Catalog                         INTERNET ROVER



          LIMITATIONS
               This tools does not yet have the capability to  perform
               actions based on the result of the test.  Rather, it is
               intended for a multi-operator environment,  and  simply
               displays a list of what is wrong with the net.

          HARDWARE REQUIRED
               This software is known to run on Suns and IBM RTs.

          SOFTWARE REQUIRED
               Curses, 4.xBSD UNIX socket programming  libraries,  BSD
               ping.

          AVAILABILITY
               Full source available via anonymous FTP from  merit.edu
               (35.1.1.42)   in   the   ~ftp/pub/inetrover  directory.
               Source and executables are public  domain  and  can  be
               freely  distributed for non-commercial use.  This pack-
               age is unsupported, but bug reports and  fixes  may  be
               sent to: wbn@merit.edu.






























          IETF NOCTools Working Group                        [Page 51]
^L
          Internet Tool Catalog                             LAN PATROL


          NAME
               LAN Patrol

          KEYWORDS
               security, traffic; ethernet, star; eavesdrop; DOS.

          ABSTRACT
               LAN Patrol is a full-featured network analyzer that
               provides essential information for effective fault and
               performance management.  It allows network managers to
               easily monitor user activity, find traffic overloads,
               plan for growth, test cable, uncover intruders, balance
               network services, and so on.  LAN Patrol uses state of
               the art data collection techniques to monitor all
               activity on a network, giving an accurate picture of
               how it is performing.

               LAN Patrol's reports can be saved as ASCII files to
               disk, and imported into spreadsheet or database pro-
               grams for further analysis.

          MECHANISM
               The LAN Patrol interface driver programs a standard
               interface card to capture all traffic on a network seg-
               ment.  The driver operates from the background of a
               standard PC, maintaining statistics for each station on
               the network.  The information can be viewed on the PC's
               screen, or as a user-defined report output either to
               file or printer.

          CAVEATS
               None.  Normal operation is completely passive, making
               LAN Patrol transparent to the network.

          BUGS
               None known.

          LIMITATIONS
               LAN Patrol can monitor up to 10,000 packets/sec on an
               AT class PC, and is limited to monitoring a maximum of
               1024 stations for intervals of up to 30 days.

               Because LAN Patrol operates at the physical level, it
               will only see traffic for the segment on which it is
               installed; it cannot see traffic across bridges.






          IETF NOCTools Working Group                        [Page 52]
^L
          Internet Tool Catalog                             LAN PATROL



          HARDWARE REQUIRED
               Computer: IBM PC/XT/AT, PS/2 Model 30,  or  compatible.
               Requires  512K  memory and a hard drive or double-sided
               disk drive.

               Display: Color or monochrome text.  Color display
               allows color-coding of traffic information.

               Ethernet, StarLAN, LattisNet, or StarLAN 10 network
               interface card.

          SOFTWARE REQUIRED
               PC DOS, MS-DOS version 3.1 or greater.

          AVAILABILITY
               LAN Patrol many be purchased through  network  dealers,
               or directly from:
                    Legend Software, Inc.
                    Phone:  (201) 227-8771
                    FAX:    (201) 906-1151






























          IETF NOCTools Working Group                        [Page 53]
^L
          Internet Tool Catalog                               LANPROBE


          NAME
               LanProbe -- the HP 4990S LanProbe Distributed Analysis
               System.

          KEYWORDS
               alarm, manager, map, status, traffic; ethernet; eaves-
               drop, NMS; proprietary.

          ABSTRACT
               The LanProbe distributed monitoring system performs
               remote and local monitoring of ethernet LANs in a pro-
               tocol and vendor independent manner.

               LanProbe discovers each active node on a segment and
               displays it on a map with its adapter card vendor name,
               ethernet address, and IP address.  Additional informa-
               tion about the nodes, such as equipment type and physi-
               cal location can be entered in to the data base by the
               user.

               When the NodeLocator option is used, data on the actual
               location of nodes is automatically entered and the map
               becomes an accurate representation of the physical lay-
               out of the segment.  Thereafter when a new node is
               installed and becomes active, or when a node is moved
               or becomes inactive, the change is detected and shown
               on the map in real time.  The system also provides the
               network manager with precise cable fault information
               displayed on the map.

               Traffic statistics are gathered and displayed and can
               be exported in (comma delimited) CSV format for further
               analysis.  Alerts can be set on user defined thres-
               holds.

               Trace provides a remote protocol analyzer capability
               with decodes for common protocols.

               Significant events (like power failure, cable breaks,
               new node on network, broadcast IP source address seen,
               etc.) are tracked in a log that is uploaded to Pro-
               beView periodically.

               ProbeView generates reports that can be manipulated by
               MSDOS based word processors, spreadsheets, and DBMS.






          IETF NOCTools Working Group                        [Page 54]
^L
          Internet Tool Catalog                               LANPROBE



          MECHANISM
               The system consists of one or more LanProbe segment
               monitors and ProbeView software running under Microsoft
               Windows.  The LanProbe segment monitor attaches to the
               end of an ethernet segment and monitors all traffic.
               Attachment can be direct to a thin or thick coax cable,
               or via an external transceiver to fiber optic or twist-
               ed pair cabling.  Network data relating to the segment
               is transferred to a workstation running ProbeView via
               RS-232, ethernet, or a modem connection.

               ProbeView software, which runs on a PC/AT class works-
               tation, presents network information in graphical
               displays.

               The HP4992A NodeLocator option attaches to the opposite
               end of the cable from the HP4991A LanProbe segment mon-
               itor.  It automatically locates the position of nodes
               on the ethernet networks using coaxial cabling schemes.

          CAVEATS
               None.

          BUGS
               None known.

          LIMITATIONS
               None reported.

          HARDWARE REQUIRED
               HP 4991A LanProbe segment monitor
               HP 4992A NodeLocator (for optional capabilities)
               80386 based PC capable of running MS-Windows

          SOFTWARE REQUIRED
               HP 4990A ProbeView
               MSDOS 3.0 or higher and Microsoft Windows/286 2.1.

          AVAILABILITY
               A commercial product available from:
                    Hewlett-Packard Company
                    P.O. Box 10301,
                    Palo Alto, CA  94303-0890







          IETF NOCTools Working Group                        [Page 55]
^L
          Internet Tool Catalog                               LANWATCH


          NAME
               LANWatch

          KEYWORDS
               alarm, analyzer, traffic; CHAOS, DECnet, DNS, ethernet,
               IP, OSI, ring, SMTP, star; eavesdrop; DOS; library,
               sourcelib.

          ABSTRACT
               LANWatch 2.0 is an inexpensive, powerful and flexible
               network analyzer that runs under DOS on personal com-
               puters and requires no hardware modifications to either
               the host or the network.  LANWatch is an invaluable
               tool for installing, troubleshooting, and monitoring
               local area networks, and for developing and debugging
               new protocols.  Network managers using LANWatch can
               inspect network traffic patterns and packet errors to
               isolate performance problems and bottlenecks.  Protocol
               developers can use LANWatch to inspect and verify
               proper protocol handling.  Since LANWatch is a
               software-only package which installs easily in existing
               PCs, network technicians and field service engineers
               can carry LANWatch in their briefcase for convenient
               network analysis at remote sites.

               LANWatch has two operating modes: Display and Examine.
               In Display Mode, LANWatch traces network traffic by
               displaying captured packets in real time.  Examine Mode
               allows you to scroll back through stored packets to
               inspect them in detail.  To select a subset of packets
               for display, storage or retrieval, there is an exten-
               sive set of built-in filters.  Using filters, LANWatch
               collects only packets of interest, saving the user from
               having to sort through all network traffic to isolate
               specific packets.  The built-in filters include alarm,
               trigger, capture, load, save and search.  They can be
               controlled separately to match on source or destination
               address, protocol, or packet contents at the hardware
               and transport layers.  LANWatch also includes suffi-
               cient source code so users can modify the existing
               filters and parsers or add new ones.

               The LANWatch distribution includes executables and
               source for several post-processors: a TCP protocol
               analyzer, a node-by-node traffic analyzer and a dump
               file listing tool.

          MECHANISM



          IETF NOCTools Working Group                        [Page 56]
^L
          Internet Tool Catalog                               LANWATCH


               Uses many common PC network interfaces by placing them
               in promiscuous mode and capturing traffic.

          CAVEATS
               Most PC network interfaces will not capture 100% of the
               traffic on a fully-loaded network (primarily missing
               back-to-back packets).

          BUGS
               None known.

          LIMITATIONS
               LANWatch can't analyze what it doesn't see (see
               Caveats).

          HARDWARE REQUIRED
               LANWatch requires a PC or PS/2 with a supported network
               interface card.

          SOFTWARE REQUIRED
               LANWatch runs in DOS.  Modification of the supplied
               source code or creation of additional filters and
               parsers requires Microsoft C 5.1

          AVAILABILITY
               LANWatch is commercially available from FTP Software,
               Incorporated, 26 Princess Street, Wakefield, MA, 01880
               (617 246-0900).























          IETF NOCTools Working Group                        [Page 57]
^L
          Internet Tool Catalog                                    MAP


          NAME
               map -- Interactive Network Map

          KEYWORDS
               manager, map; CHAOS, ethernet, IP, ring, star; NMS,
               ping, SNMP, X; UNIX; free, sourcelib.

          ABSTRACT
               Map draws a map of network connectivity and allows
               interactive examination of information about various
               components including whether hosts can be reached over
               the network.

               The program is supplied with complete source and is
               written in a modular fashion to make addition of dif-
               ferent protocols stacks, displays, or hardcopy devices
               relatively easy.  This is one of the reasons why the
               initial version supports at least two of each.  Contri-
               butions of additional drivers in any of these areas
               will be welcome as well as porting to additional plat-
               forms.

          MECHANISM
               Net components are pinged by use of ICMP echo and,
               optionally, CHAOS status requests and SNMP "gets."  The
               program initializes itself from static data stored in
               the file system and therefore does not need to access
               the network in order to get running (unless the static
               files are network mounted).

          CAVEATS
               As of publication, the tool is in beta release.

          BUGS
               Several minor nits, documented in distribution files.
               Bug discoveries should be reported by email to Bug-
               Map@LCS.MIT.Edu.

          LIMITATIONS
               See distribution file for an indepth discussion of sys-
               tem capabilities and potential.

          HARDWARE REQUIRED
               An X display is needed for interactive display of the
               map, non-graphical interaction is available in non-
               display mode.  For hardcopy output a PostScript or Tek-
               tronix 4692 printer is required.




          IETF NOCTools Working Group                        [Page 58]
^L
          Internet Tool Catalog                                    MAP



          SOFTWARE REQUIRED
               BSD UNIX or related OS.  IP/ICMP is required;
               CHAOS/STATUS and SNMP can be used but are optional.
               X-Windows is required for interactive display of the
               map.

          AVAILABILITY
               As of publication, map is in beta release.  To be added
               to the email forum that discusses the software, or to
               obtain individual files or instructions on getting the
               full current release, send a request to:

                    MAP-Request@LCS.MIT.Edu.

               The program is Copyright MIT.  It is available via
               anonymous FTP with a license making it free to use and
               distribute for non-commercial purposes.

































          IETF NOCTools Working Group                        [Page 59]
^L
          Internet Tool Catalog                               MCONNECT


          NAME
               mconnect

          KEYWORDS
               status; SMTP; spoof; UNIX.

          ABSTRACT
               Mconnect allows an interactive session with a remote
               mailer.  Mail delivery problems can be diagnosed by
               connecting to the remote mailer and issuing SMTP com-
               mands directly.

          MECHANISM
               Opens a TCP connection to remote SMTP on port 25.  Pro-
               vides local line buffering and editing, which is the
               distinction between mconnect and a TELNET to port 25.

          CAVEATS
               None.

          BUGS
               None known.

          LIMITATIONS
               Mconnect is not a large improvement over using a TELNET
               connection to port 25.

          HARDWARE REQUIRED
               No restrictions.

          SOFTWARE REQUIRED
               BSD UNIX or related OS.

          AVAILABILITY
               Available with 4.xBSD UNIX and related operating sys-
               tems.















          IETF NOCTools Working Group                        [Page 60]
^L
          Internet Tool Catalog                     NETLABS CMOT AGENT


          NAME
               Netlabs CMOT Agent

          KEYWORDS
               manager, status; IP, OSI; NMS.

          ABSTRACT
               Netlabs' CMOT code debuted in Interop 89.  The CMOT
               code comes with an Extensible MIB, which allows users
               to add new MIB variables.  The code currently supports
               all the MIB variables in RFC 1095 via the data types in
               RFC 1065, as well as the emerging MIB-II, which is
               currently in experimental stage.  The CMOT has been
               benchmarked at 100 Management Operations per Second
               (MOPS) for a 1-MIPS machine.

          MECHANISM
               The Netlabs CMOT agent supports the control and moni-
               toring of network resources by use of CMOT message
               exchanges.

          CAVEATS
               None.

          BUGS
               None known.

          LIMITATIONS
               None reported.

          HARDWARE REQUIRED
               Portable to most hardware.

          SOFTWARE REQUIRED
               Portable to most operating systems.

          AVAILABILITY
               Commercially available from:
                    Netlabs Inc
                    11693 Chenault Street Ste 348
                    Los Angeles CA 90049
                    (213) 476-4070
                    lam@netlabs.com (Anne Lam)








          IETF NOCTools Working Group                        [Page 61]
^L
          Internet Tool Catalog                     NETLABS SNMP AGENT


          NAME
               Netlabs SNMP Agent.

          KEYWORDS
               manager, status; IP; NMS, SNMP.

          ABSTRACT
               Netlabs' SNMP code debuted in Interop 89, where it
               showed interoperation of the code with several imple-
               mentations on the show floor.  The SNMP code comes with
               an Extensible MIB, which allows users to add new MIB
               variables.  The code currently supports all the MIB
               variables in RFC 1066 via the data types in RFC 1065,
               as well as the emerging MIB-II, which is currently in
               experimental stage.  The SNMP has been benchmarked at
               200 Management Operations per Second (MOPS) for a 1-
               MIPS machine.

          MECHANISM
               The Netlabs SNMP agent supports the control and moni-
               toring of network resources by use of SNMP message
               exchanges.

          CAVEATS
               None.

          BUGS
               None known.

          LIMITATIONS
               None reported.

          HARDWARE REQUIRED
               Portable to most hardware.

          SOFTWARE REQUIRED
               Portable to most operating systems.

          AVAILABILITY
               Commercially available from:
                    Netlabs Inc
                    11693 Chenault Street Ste 348
                    Los Angeles CA 90049
                    (213) 476-4070
                    lam@netlabs.com (Anne Lam)






          IETF NOCTools Working Group                        [Page 62]
^L
          Internet Tool Catalog                             NETMON (I)


          NAME
               netmon

          KEYWORDS
               status; DNS, IP; ping; DOS; free.

          ABSTRACT
               Netmon is a DOS-based program that pings hosts on a
               monitored list at user-specified intervals.  In addi-
               tion, a user may optionally ping hosts not on the list.

               Netmon also performs domain lookups.  Furthermore, a
               user may build and send a domain query to any desired
               DNS server.

          MECHANISM
               The tool works by using the echo service feature of
               ICMP.  It reports if it receives an incorrect response
               or no response.

          CAVEATS
               Depending on the frequency of pinging and the number of
               hosts pinged, netmon could create a high volume of
               traffic.

          BUGS
               None known.

          LIMITATIONS
               None reported.

          HARDWARE REQUIRED
               A PC, and a Western Digital WD8003 interface card (or
               any other card for which there is a packet driver for
               FTP Software Inc.'s PC/TCP kernel).  Both monochrome
               and color displays are supported, though color is
               recommended.

          SOFTWARE REQUIRED
               DOS operating system, and the PC/TCP Kernel by FTP
               Software, Inc.

          AVAILABILITY
               The BYU modified version is available for anonymous FTP
               from Dcsprod.byu.edu, in directory "programs."  It can
               be freely distributed for non-commercial use.





          IETF NOCTools Working Group                        [Page 63]
^L
          Internet Tool Catalog                            NETMON (II)


          NAME
               NETMON and iptrace

          KEYWORDS
               traffic; IP; eavesdrop; UNIX; free.

          ABSTRACT
               NETMON is a facility to enable communication of net-
               working events from the BSD UNIX operating system to a
               user-level network monitoring or management program.
               Iptrace is a program interfacing to NETMON which logs
               TCP-IP traffic for performance measurement and gateway
               monitoring. It is easy to build other NETMON-based
               tools using iptrace as a model.

               NETMON resides in the 4.3BSD UNIX kernel.  It is
               independent of hardware-specific code in UNIX.  It is
               transparent to protocol and network type, having no
               internal assumptions about the network protocols being
               recorded.  It is installed in BSD-like kernels by
               adding a standard function call (probe) to a few points
               in the input and output routines of the protocols to be
               logged.

               NETMON is analogous to Sun Microsystems' NIT, but the
               interface tap function is extended by recording more
               context information.  Aside from the timestamp, the
               choice of information recorded is up to the installer
               of the probes.  The NETMON probes added to the BSD IP
               code supplied with the distribution include as context:
               input and output queue lengths, identification of the
               network interface, and event codes labeling packet dis-
               cards.  (The NETMON distribution is geared towards
               measuring the performance of BSD networking protocols
               in an IP gateway).

               NETMON is designed so that it can reside within the
               monitored system with minimal interference to the net-
               work processing.  The estimated and measured overhead
               is around five percent of packet processing.

               The user-level tool "iptrace" is provided with NETMON.
               This program logs IP traffic, either at IP-level only,
               or as it passes through the network interface drivers
               as well.  As a separate function, iptrace produces a
               host traffic matrix output.  Its third type of output
               is abbreviated sampling, in which only a pre-set number
               of packets from each new host pair is logged.  The



          IETF NOCTools Working Group                        [Page 64]
^L
          Internet Tool Catalog                            NETMON (II)


               three output types are configured dynamically, in any
               combination.

               OSITRACE, another logging tool with a NETMON interface,
               is available separately (and documented in a separate
               entry in this catalog).

          MECHANISM
               Access to the information logged by NETMON is through a
               UNIX special file, /dev/netmon.  User reads are blocked
               until the buffer reaches a configurable level of full-
               ness.

               Several other parameters of NETMON can be tuned at com-
               pile time.  A diagnostic program, netmonstat, is
               included in the distribution.

          CAVEATS
               None.

          BUGS
               Bug reports and questions should be addressed to:
                    ie-tools@gateway.mitre.org
               Requests to join this mailing list:
                    ie-tools-request@gateway.mitre.org
               Questions and suggestions can also be directed to:
                    Allison Mankin (703)883-7907
                    mankin@gateway.mitre.org

          LIMITATIONS
               A NETMON interface for tcpdump and other UNIX protocol
               analyzers is not included, but it is simple to write.
               NETMON probes for a promiscuous ethernet interface are
               similarly not included.

          HARDWARE REQUIRED
               No restrictions.

          SOFTWARE REQUIRED
               BSD UNIX-like network protocols or the ability to
               install the BSD publicly available network protocols in
               the system to be monitored.









          IETF NOCTools Working Group                        [Page 65]
^L
          Internet Tool Catalog                            NETMON (II)



          AVAILABILITY
               The NETMON distribution is available by anonymous FTP
               in pub/netmon.tar or pub/netmon.tar.Z from aelred-
               3.ie.org.  A short user's and installation guide,
               NETMON.doc, is available in the same location.  The
               NETMON distribution is provided "as is" and requires
               retention of a copyright text in code derived from it.
               It is copyrighted by the MITRE-Washington Networking
               Center.









































          IETF NOCTools Working Group                        [Page 66]
^L
          Internet Tool Catalog                          NETMON (III)


          NAME
               NETMON -- an SNMP-based network management tool from
               SNMP Research.

          KEYWORDS
               alarm, control, manager, map, routing; DECnet, ether-
               net, IP, OSI, ring, star; NMS, SNMP; DOS; sourcelib.

          ABSTRACT
               The NETMON application implements a network management
               station based on a low-cost DOS-based platform.  It can
               be successfully used with many types of networks,
               including both wide area networks and those based on
               various LAN media.  NETMON has been used with multipro-
               tocol devices including those which support TCP/IP,
               DECnet, and OSI protocols.  The fault management tool
               displays the map of the network configuration with
               current node and link state indicated in one of several
               colors.  Alarms may be enabled to alert the operator of
               events occurring in the network.  Events are logged to
               disk.  The NETMON application comes complete with
               source code including a powerful set of portable
               libraries for generating and parsing SNMP messages.
               Output data from NETMON may be transferred via flat
               files for additional report generation by a variety of
               statistical packages.

          MECHANISM
               The NETMON application is based on the Simple Network
               Management Protocol (SNMP).  Polling is performed via
               the powerful SNMP get-next operator and the SNMP get
               operator.  Trap directed polling is used to regulate
               the focus and intensity of the polling.

          CAVEATS
               None.

          BUGS
               None known.

          LIMITATIONS
               The monitored and managed nodes must implement the SNMP
               over UDP per RFC 1098 or must be reachable via a proxy
               agent.

          HARDWARE REQUIRED
               The minimum system is a IBM Personal Computer (4.77
               MHz) with DOS 3.0 or later, an Enhanced Graphics



          IETF NOCTools Working Group                        [Page 67]
^L
          Internet Tool Catalog                          NETMON (III)


               Adapter, Enhanced Graphics Monitor, a single 360 Kbyte
               floppy drive, and an ethernet adapter.  However, most
               users will find a hard disk to be helpful for storing
               network history and will be less impatient with a fas-
               ter CPU.

          SOFTWARE REQUIRED
               DOS 3.0 or later and TCP/IP software from one of
               several sources.

          AVAILABILITY
               This is a commercial product available under license
               from:

                    SNMP Research
                    P.O. Box 8593
                    Knoxville, TN 37996-4800
                    (615) 573-1434 (Voice)
                    (615) 573-9197 (FAX)
                    Attn:  Dr. Jeff Case































          IETF NOCTools Working Group                        [Page 68]
^L
          Internet Tool Catalog                                NETSTAT


          NAME
               netstat

          KEYWORDS
               routing; IP; UNIX, VMS; free.

          ABSTRACT
               Netstat is a program that accesses network related data
               structures within the kernel, then provides an ASCII
               format at the terminal.  Netstat can provide reports on
               the routing table, TCP connections, TCP and UDP
               "listens", and protocol memory management.

          MECHANISM
               Netstat accesses operating system memory to read the
               kernel routing tables.

          CAVEATS
               Kernel data structures can change while netstat is run-
               ning.

          BUGS
               None known.

          LIMITATIONS
               None reported.

          HARDWARE REQUIRED
               No restrictions.

          SOFTWARE REQUIRED
               BSD UNIX or related OS, or VMS.

          AVAILABILITY
               Available via anonymous FTP from uunet.uu.net, in
               directory bsd-sources/src/ucb.  Available with 4.xBSD
               UNIX and related operating systems.  For VMS, available
               as part of TGV MultiNet IP software package, as well as
               Wollongong's WIN/TCP.












          IETF NOCTools Working Group                        [Page 69]
^L
          Internet Tool Catalog                               NETWATCH


          NAME
               netwatch

          KEYWORDS
               traffic; ethernet, IP, ring; eavesdrop; DOS; free.

          ABSTRACT
               PC/netwatch listens to an attached local broadcast net-
               work and displays one line of information for every
               packet that goes by.  This information consists of the
               "to" and "from" local network addresses, the packet
               length, the value of the protocol type field, and 8
               selected contiguous bytes of the packet contents.
               While netwatch is running it will respond to commands
               to display collected information, change its operating
               mode, or to filter for specific types of packets.

          MECHANISM
               Puts controller in promiscuous mode.

          CAVEATS
               None.

          BUGS
               None known.

          LIMITATIONS
               The monitor can handle a burst rate of about 200 pack-
               ets per second.  Packets arriving faster than that are
               missed (but counted in the statistics of the network
               driver).  The display rate is about 25 packets per
               second and there is a buffer that can hold 512
               undisplayed packets.  The monitor discards overflow
               packets.

          HARDWARE REQUIRED
               IBM PC compatible with CGA and network interface (3com
               3C501, Interlan NI5010, or proNet p1300).

          SOFTWARE REQUIRED
               DOS 2.0 or higher, MicroSoft C (to generate custom exe-
               cutables)









          IETF NOCTools Working Group                        [Page 70]
^L
          Internet Tool Catalog                               NETWATCH



          AVAILABILITY
               Available as a utility program in the pcip distribution
               from host husc6.harvard.edu, in directory pub/pcip.
               Available in a standalone package via anonymous FTP
               from windom.ucar.edu, in file pc/network/netwatch.arc;
               a binary "dearc" program is also available from
               windom.ucar.edu.











































          IETF NOCTools Working Group                        [Page 71]
^L
          Internet Tool Catalog                   NETWORK INTEGRATOR I


          NAME
               Network Integrator I

          KEYWORDS
               map, traffic; ethernet; UNIX.

          ABSTRACT
               This tool monitors traffic on network segments.  All
               information is dumped to either a log file or, for
               real-time viewing, to a command tool window.  Data is
               time-stamped according to date and time.  Logging can
               continue for up to 24 hours.

               The tool is flexible in data collection and presenta-
               tion.  Traffic filters can be specified according to
               header values of numerous protocols, including those
               used by Apple, DEC, Sun, HP, and Apollo.  Bandwidth
               utilization can be monitored, as well as actual load
               and peak throughput.  Additionally, the Network
               Integrator can analyze a network's topology, and record
               the location of all operational nodes on a network.

               Data can be displayed in six separate formats of bar
               graphs.  In addition, there are several routines for
               producing statistical summaries of the data collected.

          MECHANISM
               The tools work through RPC and XDR calls.

          CAVEATS
               Although the tool adds only little traffic to a net-
               work, generation of statistics from captured files
               requires a significant portion of a workstation's CPU.

          BUGS
               None known.

          LIMITATIONS
               Must be root to run monitor.  There does not seem to be
               a limit to the number of nodes, since it monitors by
               segments.  The only major limitation is the amount of
               disk space that a user can commit to the log files.
               The size of the log files, however, can be controlled
               through the tool's parameters.

          HARDWARE REQUIRED
               Sun3 or Sun4.




          IETF NOCTools Working Group                        [Page 72]
^L
          Internet Tool Catalog                   NETWORK INTEGRATOR I


          SOFTWARE REQUIRED
               4.0BSD UNIX or greater, or related OS.

          AVAILABILITY
               Copyrighted, commercially available from
               Network Integrators,
               (408) 927-0412.












































          IETF NOCTools Working Group                        [Page 73]
^L
          Internet Tool Catalog                            NET_MONITOR


          NAME
               net_monitor

          KEYWORDS
               routing, status; DECnet, IP; curses, ping; UNIX, VMS;
               free, sourcelib.

          ABSTRACT
               Net_monitor uses ICMP echo (and DECnet reachability
               information on VAX/VMS) to monitor a network.  The mon-
               itoring is very simplistic, but has proved useful.  It
               periodically tests whether hosts are reachable and
               reports the results in a full-screen display.  It
               groups hosts together in common sets.  If all hosts in
               a set become unreachable, it makes a lot of racket with
               bells, since it assumes that this means that some com-
               mon piece of hardware that supports that set has
               failed.  The periodicity of the tests, hosts to test,
               and groupings of hosts are controlled with a single
               configuration file.

               The idea for this program came from the PC/IP monitor
               facility, but is an entirely different program with
               different functionality.

          MECHANISM
               Reachability is tested using ICMP echo facilities for
               TCP/IP hosts (and DECnet reachability information on
               VAX/VMS).  A DECnet node is considered reachable if it
               appears in the list of hosts in a "show network" com-
               mand issued on a routing node.

          CAVEATS
               This facility has been found to be most useful when run
               in a window on a workstation rather than on a terminal
               connected to a host.  It could be useful if ported to a
               PC (looks easy using FTP Software's programming
               libraries), but this has not been done.  Curses is very
               slow and cpu intensive on VMS, but the tool has been
               run in a window on a VAXstation 2000.  Just don't try
               to run it on a terminal connected to a 11/750.

          BUGS
               None known.







          IETF NOCTools Working Group                        [Page 74]
^L
          Internet Tool Catalog                            NET_MONITOR



          LIMITATIONS
               This tool is not meant to be a replacement for a more
               comprehensive network management facility such as is
               provided with SNMP.

          HARDWARE REQUIRED
               A host with a network connection.

          SOFTWARE REQUIRED
               Curses, 4.xBSD UNIX socket programming libraries (lim-
               ited set) and some flavor of TCP/IP that supports ICMP
               echo request (ping).  It has been run on VAX/VMS run-
               ning WIN/TCP and several flavors of 4BSD UNIX (includ-
               ing SunOS 3.2, 4.0, and 4.3BSD).  It could be ported to
               any platform that provides a BSD-style programming li-
               brary with an ICMP echo request facility and curses.

          AVAILABILITY
               Requests should be sent to the author:

               Dale Smith
               Asst Dir of Network Services
               University of Oregon
               Computing Center
               Eugene, OR  97403-1211

               Internet: dsmith@oregon.uoregon.edu.
               BITNET: dsmith@oregon.bitnet
               UUCP: ...hp-pcd!uoregon!dsmith
               Voice: (503)686-4394

               With the source code, a makefile is provided for most
               any UNIX box and a VMS makefile compatible with the
               make distributed with PMDF.  A VMS DCL command file is
               also provided, for use by those VMS sites without
               "make."

               The author will attempt to fix bugs, but no support is
               promised.  The tool is copyrighted, but free (for now).











          IETF NOCTools Working Group                        [Page 75]
^L
          Internet Tool Catalog                               NFSWATCH


          NAME
               nfswatch

          KEYWORDS
               traffic; ethernet, IP, NFS; curses, eavesdrop; UNIX;
               free.

          ABSTRACT
               Nfswatch monitors all incoming ethernet traffic to an
               NFS file server and divides it into several categories.
               The number and percentage of packets received in each
               category is displayed on the screen in a continuously
               updated display.

               All exported file systems are monitored by default.
               Other files may optionally be monitored.  Options also
               allow monitoring of traffic destined for a remote host
               instead of the local host, or monitoring traffic sent
               by a single host.  Items such as the sample interval
               length can be adjusted either on the command line or
               interactively.  Facilities for taking screen
               "snapshots," saving all data to a log file, and summar-
               izing the log file are included.  Nfslogsum, a program
               that summarizes the log file, is included in the dis-
               tribution.

          MECHANISM
               Nfswatch uses the Network Interface Tap in promiscuous
               mode to monitor the ethernet.  It filters out NFS pack-
               ets destined for the local (or remote) host, and then
               decodes the file handles in order to determine which
               file or file system a request pertains to.

          CAVEATS
               Because the NFS file handle is a non-standard (server
               private) piece of data, the file system monitoring part
               of the program will break whenever the format of a file
               handle is not what it expects to see.  This is easily
               fixed in the code, however.  The code presently under-
               stands SunOS 4.0 file handles.

          BUGS
               None known.








          IETF NOCTools Working Group                        [Page 76]
^L
          Internet Tool Catalog                               NFSWATCH



          LIMITATIONS
               Up to 256 exported file systems and 256 individual
               files can be monitored, but only (2 * (DisplayLines -
               16)) will be displayed on the screen (all data will be
               written to the log file).

               Only NFS requests made by client machines are counted;
               the NFS traffic generated by the server in response to
               these requests is not counted.

          HARDWARE REQUIRED
               Has been tested on Sun-3 and Sun-4 systems.  No
               hardware dependencies, but see below.

          SOFTWARE REQUIRED
               SunOS 4.0 or higher.  The STREAMS NIT device is used.
               Fairly easy code modifications should be able to make
               it run under older SunOS releases, or other versions of
               BSD UNIX with a NIT-like device.

          AVAILABILITY
               Copyrighted, but freely distributable.  Available via
               anonymous FTP from hosts icarus.riacs.edu and
               spam.itstd.sri.com in pub/nfswatch.tar.Z.  There should
               also be a copy on the 1989 Sun User's Group tape.

























          IETF NOCTools Working Group                        [Page 77]
^L
          Internet Tool Catalog                              NHFSSTONE


          NAME
               nhfsstone

          KEYWORDS
               benchmark, generator; NFS; spoof; UNIX; free.

          ABSTRACT
               Nhfsstone (pronounced n-f-s-stone, the "h" is silent)
               is an NFS benchmarking program.  It is used on an NFS
               client to generate an artificial load with a particular
               mix of NFS operations.  It reports the average response
               time of the server in milliseconds per call and the
               load in calls per second.  The nhfsstone distribution
               includes a script, "nhfsnums" that converts test
               results into plot(5) format so that they can be graphed
               using graph(1) and other tools.

          MECHANISM
               Nhfsstone is an NFS traffic generator.  It adjusts its
               calling patterns based on the client's kernel NFS
               statistics and the elapsed time.  Load can be generated
               over a given time or number of NFS calls.

          CAVEATS
               Nhfsstone will compete for system resources with other
               applications.

          BUGS
               None known.

          LIMITATIONS
               None reported.

          HARDWARE REQUIRED
               No restrictions.

          SOFTWARE REQUIRED
               4.xBSD-based UNIX

          AVAILABILITY
               Available via anonymous FTP from bugs.cs.wisc.edu.
               Alternatively, Legato Systems will provide the program
               free of charge, if certain conditions are met.  Send
               name and both email and U.S. mail addresses to:
                    Legato Systems, Inc.
                    Nhfsstone
                    260 Sheridan Avenue
                    Palo Alto, California  94306



          IETF NOCTools Working Group                        [Page 78]
^L
          Internet Tool Catalog                              NHFSSTONE



               A mailing list is maintained for regular information
               and bug fixes: nhfsstone@legato.com or
               uunet!legato.com!nhfsstone.  To join the list:
               nhfsstone-request@legato.com or
               uunet!legato.com!nhfsstone-request.













































          IETF NOCTools Working Group                        [Page 79]
^L
          Internet Tool Catalog                                    NMC


          NAME
               NMC -- the Hughes LAN Systems 9100 Network Management
               Center

          KEYWORDS
               control, manager, routing, status, traffic; bridge,
               DECnet, ethernet, IP; NMS, SNMP; UNIX.

          ABSTRACT
               The 9100 Network Management Center provides the capa-
               bility to manage and control standards-based networking
               products from Hughes LAN Systems' and other vendors.
               This management extends to all network products that
               are equipped with the industry standard SNMP (Simple
               Network Management Protocol).  A comprehensive rela-
               tional database manages the data and ensures easy
               access and control of resources throughout the network.

               9100 NMC software provides the following functions:

               Database Management
                    Stores and retrieves the information required to
                    administer and configure the network.  It can be
                    used to:
                         Store and recall configuration data for all
                         devices.
                         Provide availability history for devices.
                         Provides full-function SQL interface.
                         Assign new internet addresses.
                         Provide administrative information such as
                         physical location of devices, person respon-
                         sible, maintenance history, asset data,
                         hardware/software versions, etc.

               Configuration Management
                    A comprehensive configuration model that enables
                    you to:
                         Retrieve configuration information from SNMP
                         devices.
                         Configure HLS devices using SNMP.
                         Configures attributes relating to TCP/IP,
                         DECnet and other protocols in HLS devices
                         using SNMP.
                         Poll devices to compare their current attri-
                         bute values with those in the database and
                         produce reports of the discrepancies.
                         Collect data about the state of the network.




          IETF NOCTools Working Group                        [Page 80]
^L
          Internet Tool Catalog                                    NMC



               Performance Management
                    Displays local network traffic graphically, by
                    packet size, protocol, network utilization,
                    sources and destinations of packets, etc.

               Fault Management
                    Provides availability monitoring and indicates
                    potential problems.
                         Scheduled availability monitoring of devices.
                         SNMP traps (alarms) are recorded in an alarm
                         log.
                         New alarms are indicated by a flashing icon
                         and optional audio alert.
                         Possible causes and suggested actions for the
                         alarms are listed.
                         Cumulative reports can be produced.

               Utilities Function
                    Allows you to view and/or stop existing NMC
                    processes, and to define schedules for invoking
                    NMC applications and database maintenance utili-
                    ties.

          MECHANISM
               SNMP.

          CAVEATS
               None reported.

          BUGS
               None known.

          LIMITATIONS
               Maximum number of nodes that can be monitored is
               18,000.  This can include Hosts, Terminal Servers, PCs,
               and Bridges.

          HARDWARE REQUIRED
               The host for the NMC software is a Sun 3 desktop works-
               tation.  Recommended minimum hardware is the Sun 3/80
               Color with a 1/4" SCSI tape drive.

          SOFTWARE REQUIRED
               The NMC, which is provided on 1/4" tape format, runs on
               the Sun 4.0 Operating System.





          IETF NOCTools Working Group                        [Page 81]
^L
          Internet Tool Catalog                                    NMC



          AVAILABILITY
               A commercial product of:
                    Hughes LAN Systems Inc.
                    1225 Charleston Road
                    Mountain View, CA 94043
                    Phone: (415) 966-7300
                    Fax: (415) 960-3738
                    RCA Telex: 276572










































          IETF NOCTools Working Group                        [Page 82]
^L
          Internet Tool Catalog                                 NNSTAT


          NAME
               NNStat

          KEYWORDS
               manager, status, traffic; ethernet, IP; eavesdrop, NMS;
               UNIX; free.

          ABSTRACT
               NNStat is a collection of programs that provides an
               internet statistic collecting capability.  The NNStat
               strategy for statistic collection is to collect traffic
               statistics via a promiscuous ethernet tap on the local
               networks, versus instrumenting the gateways.  If all
               traffic entering or leaving a network or set of net-
               works traverses a local ethernet, then by stationing a
               statistic gathering agent on each local network a pro-
               file of network traffic can be gathered.  Statistical
               data is retrieved from the local agents by a global
               manager.

               A program called "statspy" performs the data gathering
               function.  Essentially, statspy reads all packets on an
               ethernet interface and records all information of
               interest.  Information of interest is gathered by exa-
               mining each packet and determining if the source or
               destination IP address is one that is being monitored,
               typically a gateway address.  If so then the contents
               of the packet are examined to see if they match further
               criteria.

               A program called "collect" performs global data collec-
               tion.  It periodically polls various statspy processes
               in the domain of interest to retrieve locally logged
               statistical data.

               The NNSTAT distribution comes with several sample awk
               programs which process the logged output of the collect
               program.

          MECHANISM
               Local agents (statspy processes) collect raw traffic
               data via a promiscuous ethernet tap.  Statistical, fil-
               tered or otherwise reduced data is retrieved from the
               local agents by a global manager (the "collect" pro-
               cess).

          CAVEATS
               None.



          IETF NOCTools Working Group                        [Page 83]
^L
          Internet Tool Catalog                                 NNSTAT



          BUGS
               Bug fixes, extensions, and other pointers are discussed
               in the electronic mail forum, bytecounters.  To join,
               send a request to bytecounters-request@venera.isi.edu.
               Forum exchanges are archived in the file
               bytecounters/bytecounters.mail, available via anonymous
               FTP from venera.isi.edu.

          LIMITATIONS
               NNStat presumes a topology of one or more long haul
               networks gatewayed to local ethernets.

               A kernel mod required to run with SunOS4.  These mods
               are described in the bytecounters archive.

          HARDWARE REQUIRED
               Ethernet interface.  Sun 3, Sun 4 (SPARC), or PC RT
               workstation.

          SOFTWARE REQUIRED
               Distribution is for BSD UNIX, could easily be adapted
               to any UNIX with promiscuous ethernet support.

          AVAILABILITY
               Distribution is available via anonymous FTP from
               venera.isi.edu, in file pub/NNStat.tar.Z.  Documenta-
               tion is in pub/NNStat.userdoc.ms.Z.























          IETF NOCTools Working Group                        [Page 84]
^L
          Internet Tool Catalog                                   NPRV


          NAME
               NPRV -- IP Node/Protocol Reachability Verifier

          KEYWORDS
               map, routing, status; IP; ping; VMS; free.

          ABSTRACT
               NPRV is a full-screen, keypad-oriented utility that
               runs under VAX/VMS.  It allows the user to quickly scan
               through a user-defined list of IP addresses (or domain
               names) and verify a node's reachability.  The node's
               reachability is determined by performing an ICMP echo,
               UDP echo and a TCP echo at alternating three second
               intervals.  The total number of packets sent and
               received are displayed, as well as the minimum, average
               and maximum round-trip times (in milliseconds) for each
               type of echo.  Additionally, a "trace route" function
               is performed to determine the path from the local sys-
               tem to the remote host.  Once all of the trace route
               information has filled the screen, a "snapshot" of the
               screen can be written to a text file.  Upon exiting the
               utility, these text files can be used to generate a
               logical network map showing host and gateway intercon-
               nectivity.

          MECHANISM
               The ICMP echo is performed by sending ICMP ECHO REQUEST
               packets.  The UDP and TCP echoes are performed by con-
               necting to the UDP/TCP echo ports (port number 7).  The
               trace route information is compiled by sending alter-
               nating ICMP ECHO REQUEST packets and UDP packets with
               very large destination UDP port numbers (in two
               passes).  Each packet is initially sent with a TTL
               (time to live) of 1.  This should cause an ICMP TIME
               EXCEEDED error to be generated by the first routing
               gateway.  Then each packet is sent with a TTL of 2.
               This should cause an ICMP TIME EXCEEDED error to be
               generated by the second routing gateway.  Then each
               packet is sent with a TTL of 3, and so on.  This pro-
               cess continues until an ICMP ECHO REPLY or UDP PORT
               UNREACHABLE is received.  This indicates that the
               remote host has been reached and that the trace route
               information is complete.

          CAVEATS
               This utility sends one echo packet per second (ICMP,
               UDP or TCP), as well as sending out one trace route
               packet per second.  If a transmitted trace route packet



          IETF NOCTools Working Group                        [Page 85]
^L
          Internet Tool Catalog                                   NPRV


               is returned in less than one second, another trace
               route packet is sent in 100 milliseconds.  This could
               cause a significant amount of contention on the local
               network.

          BUGS
               None known.  Please report any discovered bugs to the
               author at:
                    Allen Sturtevant
                    National Magnetic Fusion Energy Computer Center
                    Lawrence Livermore National Laboratory
                    P.O. Box 808; L-561
                    Livermore, CA  94550
                    Phone : (415) 422-8266
                    E-Mail: sturtevant@ccc.nmfecc.gov

          LIMITATIONS
               The user is required to have SYSPRV privilege to per-
               form the ICMP Echo and trace route functions.  The
               utility will still run with this privilege disabled,
               but only the UDP Echo and TCP Echo information will be
               displayed.  This utility is written in C, but unfor-
               tunately it cannot be easily ported over to UNIX since
               many VMS system calls are used and all screen I/O is
               done using the VMS Screen Management Routines.

          HARDWARE REQUIRED
               Any network interface supported by TGV Incorporated's
               MultiNet software.

          SOFTWARE REQUIRED
               VAX/VMS V5.1+ and TGV Incorporated's MultiNet version
               2.0.

          AVAILABILITY
               For executables only, FTP to the ANONYMOUS account
               (password GUEST) on CCC.NMFECC.GOV (128.55.128.30) and
               GET the following files:

               [ANONYMOUS.PROGRAMS.NPRV]NPRV.DOC     (ASCII text)
               [ANONYMOUS.PROGRAMS.NPRV]NPRV.EXE     (binary)
               [ANONYMOUS.PROGRAMS.NPRV]SAMPLE.IPA   (ASCII text)









          IETF NOCTools Working Group                        [Page 86]
^L
          Internet Tool Catalog                               NSLOOKUP


          NAME
               nslookup

          KEYWORDS
               status; DNS; spoof; UNIX, VMS; free.

          ABSTRACT
               Nslookup is a program used for interactive query of
               ARPA Internet domain servers.  This program is useful
               for diagnosing routing or mail delivery problems, where
               often a local domain server is responding with an
               incorrect internet address.  It is essentially a data-
               base front end which converts user queries into domain
               name queries.  By default nslookup queries the local
               domain name server but you can specify additional
               servers.  Additional information beyond the mapping of
               domain names to internet addresses is possible.

          MECHANISM
               Formats and sends domain name queries.

          CAVEATS
               None.

          BUGS
               None known.

          LIMITATIONS
               None known.

          HARDWARE REQUIRED
               No restrictions.

          SOFTWARE REQUIRED
               BSD UNIX or related OS, or VMS.

          AVAILABILITY
               Nslookup is part of the "named" distribution, available
               via anonymous FTP from uunet.uu.net, in directories
               bsd-sources/src/etc and bsd-sources/src/network, and
               part of the "bind" distribution, available via
               anonymous FTP from ucbarpa.berkeley.edu, in directory
               4.3.  Also available with 4.xBSD UNIX and related
               operating systems.  For VMS, available as part of TGV
               MultiNet IP software package, as well as Wollongong's
               WIN/TCP.





          IETF NOCTools Working Group                        [Page 87]
^L
          Internet Tool Catalog                                 OSILOG


          NAME
               osilog -- OSI event Logger

          KEYWORDS
               alarm, manager; OSI; UNIX; free.

          ABSTRACT
               The osilog program receives management event reports
               for the operation of the ISODE Transport layer (ISO
               Transport Protocol class 0) on one or more managed sys-
               tems, formats them suitably to facilitate post-
               processing and records them for future analysis.

          MECHANISM
               It communicates with the System Management Agents
               (SMAs) on the selected systems via CMIP.

          CAVEATS
               The System Management Agent (SMA) must be running on
               the hosts selected to provide management reports.

          BUGS
               None known.

          LIMITATIONS
               ISODE Transport Layer only supported by the SMA at
               present.

          HARDWARE REQUIRED
               Developed and tested on Sun3.

          SOFTWARE REQUIRED
               The ISODE protocol suite, BSD UNIX.

          AVAILABILITY
               The osilog and related tools, known as OSIMIS (OSI
               Management Information Service), are publicly available
               from University College London, England via FTP and
               FTAM.  To obtain information regarding a copy send
               email to gknight@ac.ucl.cs.uk or call +44 1 380 7366.











          IETF NOCTools Working Group                        [Page 88]
^L
          Internet Tool Catalog                                 OSIMIC


          NAME
               osimic -- OSI Microscope

          KEYWORDS
               manager, status; OSI; UNIX; free.

          ABSTRACT
               The osimic program is a human user interface to the
               management information base on the ISODE Transport
               layer (ISO Transport Protocol class 0).  It allows
               browsing through the management information tree and
               enables the manipulation of attribute values.  It is
               implemented using the SunView package of the SunTools
               window system.

          MECHANISM
               It communicates with the System Management Agent (SMA)
               on the selected system via CMIP.

          CAVEATS
               The System Management Agent (SMA) must be running on
               the host where the mib is being examined.

          BUGS
               None known.

          LIMITATIONS
               ISODE Transport Layer only supported by the SMA at
               present.

          HARDWARE REQUIRED
               Developed and tested on Sun3.

          SOFTWARE REQUIRED
               The ISODE protocol suite, BSD UNIX, SunView/SunTools.

          AVAILABILITY
               The osimic and related tools, known as OSIMIS (OSI
               Management Information Service), are publicly available
               from University College London, England via FTP and
               FTAM.  To obtain information regarding a copy send
               email to gknight@ac.ucl.cs.uk or call +44 1 380 7366.









          IETF NOCTools Working Group                        [Page 89]
^L
          Internet Tool Catalog                                 OSIMON


          NAME
               osimon -- OSI Monitor

          KEYWORDS
               manager, status, traffic; OSI; curses; UNIX; free.

          ABSTRACT
               The osimon program monitors activity of the ISODE Tran-
               sport layer (ISO Transport Protocol class 0), display-
               ing entries for the active transport entities and con-
               nections.  The display is dynamically updated in the
               case of significant events such as connection opening
               and closing and packet traffic, as information is
               received in the form of event reports from a SMA.  It
               uses the UNIX curses package for screen management.

          MECHANISM
               It communicates with the System Management Agent (SMA)
               on the selected system via CMIP.

          CAVEATS
               The System Management Agent (SMA) must be running on
               the host being monitored.

          BUGS
               For the terminal type Sun, there are some transient
               problems with the display.

          LIMITATIONS
               ISODE Transport Layer only supported at present.

          HARDWARE REQUIRED
               Developed and tested on Sun3 for various terminal
               types.

          SOFTWARE REQUIRED
               The ISODE protocol suite, BSD UNIX.

          AVAILABILITY
               The osimon and related tools, known as OSIMIS (OSI
               Management Information Service), are publicly available
               from University College London, England via FTP and
               FTAM.  To obtain information regarding a copy send
               email to gknight@ac.ucl.cs.uk or call +44 1 380 7366.







          IETF NOCTools Working Group                        [Page 90]
^L
          Internet Tool Catalog                               OSITRACE


          NAME
               OSITRACE

          KEYWORDS
               traffic; OSI; eavesdrop; UNIX; free.

          ABSTRACT
               OSITRACE is a network performance tool that displays
               information about ISO TP4 connections.  One line of
               output is displayed for each packet indicating the
               time, source, destination, length, packet type,
               sequence number, credit, and any optional parameters
               contained in the packet.  Numerous options are avail-
               able to control the output of OSITRACE.

               To obtain packets to analyze, OSITRACE uses Sun
               Microsystems' Network Interface Tap (NIT) in SunOS 3.4,
               3.5, and 4.0.X.  OSITRACE may also obtain data from the
               NETMON utility which is described as another tool
               entry.

               In Sun systems, OSITRACE may be easily installed: OSI
               kernel support is not needed, nor is any other form of
               OSI software support.

          MECHANISM
               This tool has been designed in such a way that code to
               process different protocol suites may be easily added.
               As such, OSITRACE also has the ability to trace the DOD
               TCP protocols.

          CAVEATS
               None.

          BUGS
               Bug reports and questions should be addressed to: ie-
               tools@gateway.mitre.org

               Requests to join this mailing list: ie-tools-
               request@gateway.mitre.org

               Questions and suggestions can also be directed to: Greg
               Hollingsworth, gregh@gateway.mitre.org

          LIMITATIONS
               None reported.





          IETF NOCTools Working Group                        [Page 91]
^L
          Internet Tool Catalog                               OSITRACE



          HARDWARE REQUIRED
               No restriction.

          SOFTWARE REQUIRED
               SunOS 3.4, 3.5, or 4.0.X, or BSD UNIX-like network pro-
               tocols with NETMON installed.

          AVAILABILITY
               OSITRACE is copyrighted by the MITRE-Washington Net-
               working Center, but freely distributed "as is."  It re-
               quires retention of a copyright text in code derived
               from it.  The distribution is available by anonymous
               FTP in pub/pdutrace.tar or pub/pdutrace.tar.Z from
               aelred-3.ie.org.




































          IETF NOCTools Working Group                        [Page 92]
^L
          Internet Tool Catalog                               OVERVIEW


          NAME
               OverVIEW

          KEYWORDS
               manager, status; IP; NMS, SNMP; DOS.

          ABSTRACT
               Network and internet monitor; Performance monitor;
               Fully Graphic user interface; Event logging; TFTP boot
               server

          MECHANISM
               OverVIEW uses SNMP to query routers, gateways and
               hosts.  Also supports SGMP, PING and is committed to
               CMIP/CMOT.  The SNMP queries allow dynamic determina-
               tion of configuration and state.  Sets of related
               queries allows monitoring of congestion and faults.
               The hardware and software are sold as an integrated
               package.

          CAVEATS
               None.

          BUGS
               None known.

          LIMITATIONS
               256 nodes, 256 nets

          HARDWARE REQUIRED
               80286, 640K, EGA, mouse.

          SOFTWARE REQUIRED
               MS-DOS, OverVIEW, Network kernel, Mouse driver, SNMP
               agents for monitored devices.

          AVAILABILITY
               Fully supported product of Proteon, Inc.  For more
               information, contact:
                   Proteon, Inc.             Phone: (508) 898-2800
                   2 Technology Drive        Fax:   (508) 366-8901
                   Westborough, MA  01581    Telex: 928124









          IETF NOCTools Working Group                        [Page 93]
^L
          Internet Tool Catalog                                   PING


          NAME
               ping

          KEYWORDS
               generator, status; IP; ping; DOS, UNIX, VMS; free.

          ABSTRACT
               Ping is perhaps the most basic tool for internet
               management.  It verifies that a remote IP implementa-
               tion and the intervening networks and interfaces are
               functional.  It can be used to measure round trip
               delay.  Numerous versions of the ping program exist.

          MECHANISM
               Ping is based on the ICMP ECHO_REQUEST message.

          CAVEATS
               If run repeatedly, ping could generate high system
               loads.

          BUGS
               None known.

          LIMITATIONS
               PC/TCP's ping is the only implementation known support
               both loose and strict source routing.  Though some ping
               implementations support the ICMP "record route"
               feature, the usefulness of this option for debugging
               routes is limited by the fact that many gateways do not
               correctly implement it.

          HARDWARE REQUIRED
               No restrictions.

          SOFTWARE REQUIRED
               None.

          AVAILABILITY
               Ping is widely included in TCP/IP distributions.  Pub-
               lic domain versions of ping are available via anonymous
               FTP from uunet.uu.net, in directory bsd-
               sources/src/etc, and from venera.isi.edu, in directory
               pub.








          IETF NOCTools Working Group                        [Page 94]
^L
          Internet Tool Catalog                                 PROXYD


          NAME
               proxyd -- SNMP proxy agent daemons from SNMP Research.

          KEYWORDS
               control, status; bridge, ethernet, IP, ring, star; NMS,
               SNMP; UNIX; library, sourcelib.

          ABSTRACT
               SNMP proxy agents may be used to permit the monitoring
               and controlling of network elements which are otherwise
               not addressable using the SNMP management protocol
               (e.g., a network bridge that implements a proprietary
               management protocol).  Similarly, SNMP proxy agents may
               be used to protect SNMP agents from redundant network
               management agents through the use of caches.  Finally,
               SNMP proxy agents may be used to implement elaborate
               MIB access policies.  The proxy agent daemon listens
               for SNMP queries and commands from logically remote
               network management stations, translates and retransmits
               those as appropriate network management queries or
               cache lookups, listens for and parses the responses,
               translates the responses into SNMP responses, and
               returns those responses as SNMP messages to the network
               management station that originated the transaction.
               The proxy agent daemon also emits SNMP traps to identi-
               fied trap receivers.  The proxy agent daemon is archi-
               tected to make the addition of additional vendor-
               specific variables a straight-forward task.  The proxy
               application comes complete with source code including a
               powerful set of portable libraries for generating and
               parsing SNMP messages and a set of command line utili-
               ties.

          MECHANISM
               Network management variables are made available for
               inspection and/or alteration by means of the Simple
               Network Management Protocol (SNMP).

          CAVEATS
               None.

          BUGS
               None known.

          LIMITATIONS
               This application is a template for proxy application
               writers.




          IETF NOCTools Working Group                        [Page 95]
^L
          Internet Tool Catalog                                 PROXYD


               Only a few of the many LanBridge 100 variables are sup-
               ported.

          HARDWARE REQUIRED
               System from Sun Microsystems, Incorporated.

          SOFTWARE REQUIRED
               Sun OS 3.5 or 4.x

          AVAILABILITY
               This is a commercial product available under license
               from:

                    SNMP Research
                    P.O. Box 8593
                    Knoxville, TN 37996-4800
                    (615) 573-1434 (Voice)
                    (615) 573-9197 (FAX)
                    Attn:  Dr. Jeff Case
































          IETF NOCTools Working Group                        [Page 96]
^L
          Internet Tool Catalog                                  QUERY


          NAME
               query, ripquery

          KEYWORDS
               routing; IP; spoof; UNIX; free.

          ABSTRACT
               Query allows remote viewing of a gateway's routing
               tables.

          MECHANISM
               Query formats and sends a RIP request or POLL command
               to a destination gateway.

          CAVEATS
               Query is intended to be used a a tool for debugging
               gateways, not for network management.  SNMP is the pre-
               ferred protocol for network management.

          BUGS
               None known.

          LIMITATIONS
               The polled gateway must run RIP.

          HARDWARE REQUIRED
               No restriction.

          SOFTWARE REQUIRED
               4.3BSD UNIX or related OS.

          AVAILABILITY
               Available with routed and gated distributions.

               Routed may be obtained via anonymous FTP from
               uunet.uu.net, in file bsd-
               sources/src/network/routed.tar.Z.

               Gated may be obtained via anonymous FTP from
               devvax.tn.cornell.edu.  Distribution files are in
               directory pub/gated.










          IETF NOCTools Working Group                        [Page 97]
^L
          Internet Tool Catalog                                  SERAG


          NAME
               SERAG -- the Simple Event Reporting and Alarm Genera-
               tion tool

          KEYWORDS
               alarm, security; ethernet, IP; NMS, proprietary; UNIX.

          ABSTRACT
               The Simple Event Reporting and Alarm Generation (SERAG)
               collects error messages and other event reports from
               servers on a LAN.  Any node with UDP/IP can be the
               source of such messages/reports.  The logging of error
               messages is integrated with the audit trail facility of
               the Network Control Server (NCS) from 3COM.  Alarms are
               generated on the NCS based on predefined conditions.
               Alarms may be sent to the console of the NCS, logged in
               a file, or routed via WAN to a service center.

               SERAG can automatically detect a predefined set of
               errors in the servers and generate alarms.  The break-
               down of a server in the LAN may also result in alarm
               generation.

               SERAG creates an error log that can be used for post-
               testing analysis.

          MECHANISM
               The tool searches through the audit trail (error log)
               files for events specified by the user.  The search may
               be constrained to specific nodes in the network and to
               a specific time frame.  Events may be combined into
               conditions which are logical expressions (e.g., look
               for eventA and eventB and not eventC within time frame
               so and so).  This is an interactive query facility to
               analyze the audit trail (error log).

               The user may also ask for such conditions to be checked
               at regular intervals, and specify routing of error mes-
               sages in case the condition is satisfied.  The checking
               of such conditions is done by a daemon process running
               in the background.

          CAVEATS
               May impact the performance of the NCS if error logs are
               big, or if conditions are computationally complex.

          BUGS
               None known.



          IETF NOCTools Working Group                        [Page 98]
^L
          Internet Tool Catalog                                  SERAG



          LIMITATIONS
               None reported.

          HARDWARE REQUIRED
               A workstation running UNIX.

          SOFTWARE REQUIRED
               Implemented in C (using lex and yacc) on a Sun 3/50.
               Also runs under Xenix.  Should work with most versions
               of UNIX.

          AVAILABILITY
               Developed jointly by ELAB-RUNIT and Norsk Data:

                    Tor Didriksen, Ole-Hjalmar Kristensen, Steinar
                    Haug,
                    Eldfrid Oefsti Oevstedal, Tor Staalhane
                    ELAB-RUNIT
                    N-7034 Trondheim
                    Norway

                    phone: +47 7 593000
                    fax  : +47 7 532586
                    email: didrik@idt.unit.no
                      sthaug@idt.unit.no
                      kristensen@vax.runit.unit.no

               Commercially available from:
                    Norsk Data A/S
                    P.O. Box 25, Bogerud
                    N-0621 Oslo 6
                    Norway
                    ref: network management/security management/fault
                    management

                    phone: +47 2 627500
                    fax  : +47 2 296796













          IETF NOCTools Working Group                        [Page 99]
^L
          Internet Tool Catalog                                    SMA


          NAME
               sma -- OSI System Management Agent

          KEYWORDS
               alarm, manager, status; OSI; UNIX; free.

          ABSTRACT
               The sma is a CMIP agent which runs on BSD UNIX and pro-
               vides access to management information on the operation
               of the ISODE transport layer (ISO Transport Protocol
               class 0).  It also supports the sending of event
               reports.  Activity can be recorded in a log file.

          MECHANISM
               The sma communicates with the active ISODE transport
               entities using UNIX UDP sockets in order to receive the
               management information which is made available to other
               manager processes via CMIP.

          CAVEATS
               None.

          BUGS
               None known.

          LIMITATIONS
               ISODE Transport Layer only supported at present.

          HARDWARE REQUIRED
               Developed on Sun3, tested on Sun3 and VAXStation.

          SOFTWARE REQUIRED
               The ISODE protocol suite, BSD UNIX.

          AVAILABILITY
               The sma and related tools, known as OSIMIS (OSI Manage-
               ment Information Service), are publicly available from
               University College London, England via FTP and FTAM.
               To obtain information regarding a copy send email to
               gknight@ac.ucl.cs.uk or call +44 1 380 7366.











          IETF NOCTools Working Group                       [Page 100]
^L
          Internet Tool Catalog                                SNIFFER


          NAME
               Sniffer

          KEYWORDS
               analyzer, generator, traffic; DECnet, ethernet, IP,
               NFS, OSI, ring, SMTP, star; eavesdrop; standalone.

          ABSTRACT
               The Network General Sniffer is a protocol analyzer for
               performing LAN diagnostics, monitoring, traffic genera-
               tion, and troubleshooting.  The Sniffer protocol
               analyzer has the capability of capturing every packet
               on a network and of decoding all seven layers of the
               OSI protocol model.  Capture frame selection is based
               on several different filters: protocol content at lower
               levels; node addresses; pattern matching (up to 8
               logically-related patterns of 32 bytes each); and des-
               tination class.  Users may extend the protocol
               interpretation capability of the Sniffer by writing
               their own customized protocol interpreters and linking
               them to the Sniffer software.

               The Sniffer displays network traffic information and
               performance statistics in real time, in user-selectable
               formats.  Numeric station addresses are translated to
               symbolic names or manufacturer ID names.  Network
               activities measured include frames accepted, Kbytes
               accepted, and buffer use.  Each network version has
               additional counters for activities specific to that
               network.  Network activity is expressed as
               frames/second, Kbytes/second, or per cent of network
               bandwidth utilization.

               Data collection by the Sniffer may be output to printer
               or stored to disk in either print-file or spread-sheet
               format.

               Protocol suites understood by the Sniffer include:
               Banyan Vines, IBM Token-Ring, Novell Netware, XNS/MS-
               Net (3Com 3+), DECnet, TCP/IP (including SNMP and
               applications-layer protocols such as FTP, SMTP, and
               TELNET), X Windows (for X version 11), NFS, and several
               SUN proprietary protocols (including mount, pmap, RPC,
               and YP).  Supported LANs include: ethernet, Token-ring
               (4Mb and 16Mb versions), ARCNET, StarLAN, IBM PC Net-
               work (Broadband), and Apple Localtalk Network.

          MECHANISM



          IETF NOCTools Working Group                       [Page 101]
^L
          Internet Tool Catalog                                SNIFFER


               The Sniffer is a self-contained, portable protocol
               analyzer that require only AC line power and connection
               to a network to operate.  Normally passive (except when
               in Traffic Generator mode), it captures images of all
               or of selected frames in a working buffer, ready for
               immediate analysis and display.

               The Sniffer is a standalone device.  Two platforms are
               available: one for use with single network topologies,
               the other for use with multi-network topologies.  Both
               include Sniffer core software, a modified network
               interface card (or multiple cards), and optional proto-
               col interpreter suites.

               All Sniffer functions may be remotely controlled from a
               modem-connected PC.  Output from the Sniffer can be
               imported to database or spreadsheet packages.

          CAVEATS
               In normal use, the Sniffer is a passive device, and so
               will not adversely effect network performance.  Perfor-
               mance degradation will be observed, of course, if the
               Sniffer is set to Traffic Generator mode and connected
               to an active network.

          BUGS
               None known.

          LIMITATIONS
               None reported.

          HARDWARE REQUIRED
               None.  The Sniffer is a self-contained unit, and
               includes its own interface card.  It installs into a
               network as would any normal workstation.

          SOFTWARE REQUIRED
               None.

          AVAILABILITY
               The Sniffer is available commercially.  For information
               on your local representative, call or write:

                    Network General Corporation 4200 Bohannon Drive
                    Menlo Park, CA  94025 Phone: (415) 688-2700 Fax:
                    415-321-0855

               For acquisition by government agencies, the Sniffer is



          IETF NOCTools Working Group                       [Page 102]
^L
          Internet Tool Catalog                                SNIFFER


               included on the GSA schedule.


















































          IETF NOCTools Working Group                       [Page 103]
^L
          Internet Tool Catalog                   SNMP DEVELOPMENT KIT


          NAME
               The SNMP Development Kit

          KEYWORDS
               manager, status; IP; NMS, SNMP; UNIX; free, sourcelib.

          ABSTRACT
               The SNMP Development Kit comprises C Language source
               code for a programming library that facilitates access
               to the management services of the SNMP (RFC 1098).
               Sources are also included for a few simple client
               applications whose main purpose is to illustrate the
               use of the library.  Example client applications query
               remote SNMP agents in a variety of modes, and generate
               or collect SNMP traps.  Code for an example SNMP agent
               that supports a subset of the Internet MIB (RFC 1066)
               is also included.

          MECHANISM
               The Development Kit facilitates development of SNMP-
               based management applications -- both clients and
               agents.  Example applications execute SNMP management
               operations according to the values of command line
               arguments.

          CAVEATS
               None.

          BUGS
               Fixed in the next release.

          LIMITATIONS
               None reported.

          HARDWARE REQUIRED
               The SNMP library source code is highly portable and
               runs on a wide range of platforms.

          SOFTWARE REQUIRED
               The SNMP library source code has almost no operating
               system dependencies and runs in a wide range of
               environments.  Certain portions of the example SNMP
               agent code are specific to the 4.3BSD implementation of
               the UNIX system for the DEC MicroVAX.

          AVAILABILITY
               The Development Kit is available via anonymous FTP from
               host allspice.lcs.mit.edu.  The copyright for the



          IETF NOCTools Working Group                       [Page 104]
^L
          Internet Tool Catalog                   SNMP DEVELOPMENT KIT


               Development Kit is held by the Massachusetts Institute
               of Technology, and the Kit is distributed without
               charge according to the terms set forth in its code and
               documentation.  The distribution takes the form of a
               UNIX tar file.

               Bug reports, questions, suggestions, or complaints may
               be mailed electronically to snmp-dk@ptt.lcs.mit.edu,
               although no response in any form is guaranteed.  Dis-
               tribution via UUCP mail may be arranged by contacting
               the same address.  Requests for hard-copy documentation
               or copies of the distribution on magnetic media are
               never honored.






































          IETF NOCTools Working Group                       [Page 105]
^L
          Internet Tool Catalog                         SNMP LIBRARIES


          NAME
               Snmp Libraries and Utilities from SNMP Research.

          KEYWORDS
               alarm, control, manager, map, routing, status; bridge,
               DECnet, ethernet, IP, OSI, ring, star; NMS, SNMP; DOS,
               UNIX, VMS; sourcelib.

          ABSTRACT
               The SNMP Libraries and Utilities serve two purposes:

               1)   to act as building blocks for the construction of
                    SNMP-based agent and manager applications; and

               2)   to act as network management tools for network
                    fire fighting and report generation.

               The libraries perform ASN.1 parsing and generation
               tasks for both network management station applications
               and network management agent applications.  These
               libraries hide the details of ASN.1 parsing and genera-
               tion from application writers and make it unnecessary
               for them to be expert in these areas.  The libraries
               are very robust with considerable error checking
               designed in.  The several command line utilities
               include applications for retrieving one or many vari-
               ables, retrieving tables, or effecting commands via the
               setting of remote network management variables.

          MECHANISM
               The parsing is performed via recursive descent methods.
               Messages are passed via the Simple Network Management
               Protocol (SNMP).

          CAVEATS
               None.

          BUGS
               None known.

          LIMITATIONS
               None reported.









          IETF NOCTools Working Group                       [Page 106]
^L
          Internet Tool Catalog                         SNMP LIBRARIES



          HARDWARE REQUIRED
               This software has been ported to a wide range of sys-
               tems, too numerous to itemize.  It includes worksta-
               tions, general purpose timesharing systems, and embed-
               ded hardware in intelligent network devices such as re-
               peaters, bridges, and routers.

          SOFTWARE REQUIRED
               C compiler, TCP/IP library from a variety of sources.

          AVAILABILITY
               This is a commercial product available under license
               from:

                    SNMP Research
                    P.O. Box 8593
                    Knoxville, TN 37996-4800
                    (615) 573-1434 (Voice)
                    (615) 573-9197 (FAX)
                    Attn:  Dr. Jeff Case






























          IETF NOCTools Working Group                       [Page 107]
^L
          Internet Tool Catalog                                SNMPASK


          NAME
               snmpask

          KEYWORDS
               manager, status; IP; NMS, SNMP; UNIX.

          ABSTRACT
               Snmpask is a network monitoring application which gath-
               ers specific information from a single network entity
               at regular intervals and stores this information into
               UNIX flat files.  A report generation package is
               included in the NYSERNet SNMP Software Distribution to
               produce reports and graphs from the raw data.

          MECHANISM
               Snmpask uses SNMP to gather its information.  The agent
               which must be queried and the variables to query for
               are specified in a configuration file.

          CAVEATS
               An SNMP agent must be running in the network entity
               being monitored in order for snmpask to be useful.

          BUGS
               None outstanding.  They are fixed as reports come in.
               Report bugs to:  nysersnmp@nisc.nyser.net

          LIMITATIONS
               SNMP polling is done synchronously.  Only a single
               agent can be polled per snmpask process.  Only 16 vari-
               ables can be requested per snmpask process.

          HARDWARE REQUIRED
               Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
               tion I, DECstation, and a Solbourne 4/802.

          SOFTWARE REQUIRED
               Some UNIX variant or some other OS with a Berkeley
               Socket Compatibility Library.

          AVAILABILITY
               Snmpask is available in the NYSERNet SNMP Software Dis-
               tribution, which is licensed, copyrighted software.  To
               obtain information regarding the package send mail to:
               snmplisc@nisc.nyser.net or call +1 518-283-8860.






          IETF NOCTools Working Group                       [Page 108]
^L
          Internet Tool Catalog                              SNMPD (I)


          NAME
               snmpd

          KEYWORDS
               manager, status; IP; NMS, SNMP; UNIX.

          ABSTRACT
               Snmpd is an SNMP agent which runs on UNIX derivatives
               and answers network management queries from network
               management stations supporting SNMP.  Snmpd also sup-
               ports the sending of SNMP traps.

          MECHANISM
               Snmpd conforms to SNMP as specified in RFC 1098.  Cer-
               tain user configurable options are manipulated through
               a simple configuration file.

          CAVEATS
               UNIX does not support all of the MIB variables speci-
               fied in RFC 1066.  Snmpd does the best it can to find
               the answers.

          BUGS
               None outstanding.  They are fixed as reports come in.
               report bugs to:  nysersnmp@nisc.nyser.net

          LIMITATIONS
               See CAVEATS.

          HARDWARE REQUIRED
               Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
               tion I, DECstation, and a Solbourne 4/802.

          SOFTWARE REQUIRED
               Some UNIX variant.

          AVAILABILITY
               Snmpd is available in the NYSERNet SNMP Software Dis-
               tribution, which is licensed, copyrighted software.  To
               obtain information regarding the package send mail to:
               snmplisc@nisc.nyser.net or call +1 518-283-8860.










          IETF NOCTools Working Group                       [Page 109]
^L
          Internet Tool Catalog                            SNMPD (II)


          NAME
               snmpd -- an SNMP host/gateway agent daemon from SNMP
               Research.

          KEYWORDS
               manager, status; bridge, ethernet, IP, ring, star; NMS,
               SNMP; DOS, UNIX; sourcelib.

          ABSTRACT
               The snmpd agent daemon listens for and responds to net-
               work management queries and commands from logically
               remote network management stations.  The agent daemon
               also emits SNMP traps to identified trap receivers.
               The agent daemon is architected to make the addition of
               additional vendor-specific variables a straight-forward
               task.  The snmpd application comes complete with source
               code including a powerful set of portable libraries for
               generating and parsing SNMP messages and a set of com-
               mand line utilities.

          MECHANISM
               Network management variables are made available for
               inspection and/or alteration by means of the Simple
               Network Management Protocol (SNMP).

          CAVEATS
               None.

          BUGS
               None known.

          LIMITATIONS
               Only the operating system variables available without
               source code modifications to the operating system and
               device device drivers are supported.

          HARDWARE REQUIRED
               This software has been ported to a wide range of sys-
               tems, too numerous to itemize.  It includes worksta-
               tions, general purpose timesharing systems, and embed-
               ded hardware in intelligent network devices such as
               repeaters, bridges, and routers.

          SOFTWARE REQUIRED
               C compiler, ".h" files for operating system.






          IETF NOCTools Working Group                       [Page 110]
^L
          Internet Tool Catalog                            SNMPD (II)



          AVAILABILITY
               This is a commercial product available under license
               from:

                    SNMP Research
                    P.O. Box 8593
                    Knoxville, TN 37996-4800
                    (615) 573-1434 (Voice)
                    (615) 573-9197 (FAX)
                    Attn:  Dr. Jeff Case








































          IETF NOCTools Working Group                       [Page 111]
^L
          Internet Tool Catalog                             SNMPLOOKUP


          NAME
               snmplookup

          KEYWORDS
               manager, status; IP; NMS, SNMP; UNIX.

          ABSTRACT
               Snmplookup is a network monitoring application that
               allows the interactive querying of a network entity.
               Snmplookup mimics nslookup, the DNS interactive query
               tool, in style and feel.

          MECHANISM
               Snmplookup uses SNMP to gather its information.  The
               network entity to be queried and the variable to be
               retrieved can be entered from the command shell after
               snmplookup is invoked.

          CAVEATS
               An SNMP agent must be running on the network entity
               being monitored.

          BUGS
               None outstanding.  They are fixed as reports come in.
               Report bugs to:  nysersnmp@nisc.nyser.net

          LIMITATIONS
               See CAVEATS.

          HARDWARE REQUIRED
               Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
               tion I, DECstation, and a Solbourne 4/802.

          SOFTWARE REQUIRED
               Some UNIX variant or some other OS with a Berkeley
               Socket Compatibility Library.

          AVAILABILITY
               Snmplookup is available in the NYSERNet SNMP Software
               Distribution, which is licensed, copyrighted software.
               To obtain information regarding the package send mail
               to: snmplisc@nisc.nyser.net or call +1 518-283-8860.









          IETF NOCTools Working Group                       [Page 112]
^L
          Internet Tool Catalog                            SNMPPERFMON


          NAME
               snmpperfmon

          KEYWORDS
               manager, status; IP; curses, NMS, SNMP; UNIX.

          ABSTRACT
               Snmpperfmon is a network monitoring application based
               on the Berkeley curses terminal graphics package and
               the Simple Network Management Protocol.  The applica-
               tion monitors certain interface statistics from a sin-
               gle agent and displays them in tabular form on a stan-
               dard terminal screen.

          MECHANISM
               Snmpperfmon uses SNMP to gather its information.  The
               agent to be queried is specified on the command line.

          CAVEATS
               An SNMP agent must be running in the network entity
               being monitored in order for snmpperfmon to be useful.

          BUGS
               None outstanding.  They are fixed as reports come in.
               Report bugs to:  nysersnmp@nisc.nyser.net

          LIMITATIONS
               SNMP polling is done synchronously.  Only the predeter-
               mined (read "hard coded") interface statistics can be
               displayed.

          HARDWARE REQUIRED
               Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
               tion I, DECstation, and a Solbourne 4/802.

          SOFTWARE REQUIRED
               Some UNIX variant or some other OS with a Berkeley
               Socket Compatibility Library.  The "curses" library.

          AVAILABILITY
               Snmpperfmon is available in the NYSERNet SNMP Software
               Distribution, which is licensed, copyrighted software.
               To obtain information regarding the package send mail
               to: snmplisc@nisc.nyser.net or call +1 518-283-8860.







          IETF NOCTools Working Group                       [Page 113]
^L
          Internet Tool Catalog                               SNMPPOLL


          NAME
               snmppoll

          KEYWORDS
               manager, status; IP; NMS, SNMP; UNIX.

          ABSTRACT
               Snmppoll is a network monitoring application which
               gathers specific information from a network at regular
               intervals and stores this information into UNIX flat
               files.  A report generation package is included in the
               NYSERNet SNMP Software Distribution to produce reports
               and graphs of raw data collected via SNMP.

          MECHANISM
               Snmppoll uses SNMP to gather its information.  The
               agents which must be queried and the variables to query
               for are specified in a configuration file.

          CAVEATS
               An SNMP agent must be running in the network entity
               being monitored in order for snmppoll to be useful.

          BUGS
               None outstanding.  They are fixed as reports come in.
               Report bugs to:  nysersnmp@nisc.nyser.net

          LIMITATIONS
               SNMP polling is done synchronously.

          HARDWARE REQUIRED
               Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
               tion I, DECstation, and a Solbourne 4/802.

          SOFTWARE REQUIRED
               Some UNIX variant or some other OS with a Berkeley
               Socket Compatibility Library.

          AVAILABILITY
               Snmppoll is available in the NYSERNet SNMP Software
               Distribution, which is licensed, copyrighted software.
               To obtain information regarding the package send mail
               to: snmplisc@nisc.nyser.net or call +1 518-283-8860.








          IETF NOCTools Working Group                       [Page 114]
^L
          Internet Tool Catalog                              SNMPQUERY


          NAME
               snmpquery

          KEYWORDS
               manager, status; IP; NMS, SNMP; UNIX.

          ABSTRACT
               Snmpquery is a network monitoring application which
               allows the simple query of a single network entity from
               the command line.

          MECHANISM
               Snmpquery uses SNMP to gather its information.  The
               entity to be monitored and the variables to be
               retrieved must be specified on the command line.

          CAVEATS
               An SNMP agent must be running on the network entity
               being monitored.

          BUGS
               None outstanding.  They are fixed as reports come in.
               Report bugs to:  nysersnmp@nisc.nyser.net

          LIMITATIONS
               Only one network entity can be managed per invocation.

          HARDWARE REQUIRED
               Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
               tion I, DECstation, and a Solbourne 4/802.

          SOFTWARE REQUIRED
               Some UNIX variant or some other OS with a Berkeley
               Socket Compatibility Library.

          AVAILABILITY
               Snmpquery is available in the NYSERNet SNMP Software
               Distribution, which is licensed, copyrighted software.
               To obtain information regarding the package send mail
               to: snmplisc@nisc.nyser.net or call +1 518-283-8860.











          IETF NOCTools Working Group                       [Page 115]
^L
          Internet Tool Catalog                              SNMPROUTE


          NAME
               snmproute

          KEYWORDS
               manager, routing; IP; NMS, SNMP; UNIX.

          ABSTRACT
               Snmproute is a network monitoring application that
               allows the user to query for the entire routing table
               or a single routing table entry from a network entity.

          MECHANISM
               Snmproute uses SNMP to gather its information.  The
               network entity to be queried and the destination net-
               work to be queried for must be specified on the command
               line.

          CAVEATS
               An SNMP agent must be running on the network entity
               being monitored.

          BUGS
               None outstanding.  They are fixed as reports come in.
               Report bugs to:  nysersnmp@nisc.nyser.net

          LIMITATIONS
               Only one network entity can be queried per invocation.

          HARDWARE REQUIRED
               Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
               tion I, DECstation, and a Solbourne 4/802.

          SOFTWARE REQUIRED
               Some UNIX variant or some other OS with a Berkeley
               Socket Compatibility Library.

          AVAILABILITY
               Snmproute is available in the NYSERNet SNMP Software
               Distribution, which is licensed, copyrighted software.
               To obtain information regarding the package send mail
               to: snmplisc@nisc.nyser.net or call +1 518-283-8860.










          IETF NOCTools Working Group                       [Page 116]
^L
          Internet Tool Catalog                                SNMPSET


          NAME
               snmpset

          KEYWORDS
               control, manager; IP; NMS, SNMP; UNIX.

          ABSTRACT
               Snmpset is a network management application that allows
               the alteration of a single variable in a specific
               agent.

          MECHANISM
               Snmpset uses SNMP to alter the agent variables.  The
               agent to which the set is directed and the variable to
               alter must be specified on the command line.  The user
               is prompted before any changes are made.

          CAVEATS
               An SNMP agent must be running in the network entity
               being managed in order for snmpset to be useful.  In
               addition, a read-write community must be configured on
               the agent.

          BUGS
               None outstanding.  They are fixed as reports come in.
               Report bugs to:  nysersnmp@nisc.nyser.net

          LIMITATIONS
               Only one variable can be altered per invocation.

          HARDWARE REQUIRED
               Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
               tion I, DECstation, and a Solbourne 4/802.

          SOFTWARE REQUIRED
               Some UNIX variant or some other OS with a Berkeley
               Socket Compatibility Library.

          AVAILABILITY
               Snmpset is available in the NYSERNet SNMP Software Dis-
               tribution, which is licensed, copyrighted software.  To
               obtain information regarding the package send mail to:
               snmplisc@nisc.nyser.net or call +1 518-283-8860.








          IETF NOCTools Working Group                       [Page 117]
^L
          Internet Tool Catalog                                SNMPSRC


          NAME
               snmpsrc

          KEYWORDS
               manager, routing; IP; NMS, SNMP; UNIX.

          ABSTRACT
               Snmpsrc is a network monitoring application that starts
               at a specified router in the network and traces the
               path of a given destination network from the starting
               router.

          MECHANISM
               Snmpsrc uses SNMP to gather its information.  The
               starting router and destination network must be speci-
               fied on the command line.

          CAVEATS
               An SNMP agent must be running on all of the routers in
               the path to the destination network in order for a com-
               plete path to be reported back to the user.  The same
               SNMP community must also be configured in every SNMP
               agent in the path to the destination network.

          BUGS
               None outstanding.  They are fixed as reports come in.
               Report bugs to:  nysersnmp@nisc.nyser.net

          LIMITATIONS
               See CAVEATS.

          HARDWARE REQUIRED
               Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
               tion I, DECstation, and a Solbourne 4/802.

          SOFTWARE REQUIRED
               Some UNIX variant or some other OS with a Berkeley
               Socket Compatibility Library.

          AVAILABILITY
               Snmpsrc is available in the NYSERNet SNMP Software Dis-
               tribution, which is licensed, copyrighted software.  To
               obtain information regarding the package send mail to:
               snmplisc@nisc.nyser.net or call +1 518-283-8860.







          IETF NOCTools Working Group                       [Page 118]
^L
          Internet Tool Catalog                               SNMPSTAT


          NAME
               snmpstat

          KEYWORDS
               manager, status; IP; NMS, SNMP; UNIX.

          ABSTRACT
               Snmpstat is a network monitoring application that gath-
               ers specific information from a network at regular
               intervals and stores this information into a commercial
               database.  A report generation package is included in
               the NYSERNet SNMP Software Distribution to produce
               reports and graphs of raw data collected via SNMP.

          MECHANISM
               Snmpstat uses SNMP to gather its information.  The
               agents which must be queried and the variables to query
               for are specified in a configuration file.

          CAVEATS
               An SNMP agent must be running in the network entity
               being monitored in order for snmpstat to be useful.

          BUGS
               None outstanding.  They are fixed as reports come in.
               Report bugs to:  nysersnmp@nisc.nyser.net

          LIMITATIONS
               SNMP polling is done synchronously.  Currently, Ingres
               is the only commercial database supported.  SQL is the
               query language being used.

          HARDWARE REQUIRED
               Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
               tion I, DECstation, and a Solbourne 4/802.

          SOFTWARE REQUIRED
               Some UNIX variant or some other OS with a Berkeley
               Socket Compatibility Library.

          AVAILABILITY
               Snmpstat is available in the NYSERNet SNMP Software
               Distribution, which is licensed, copyrighted software.
               To obtain information regarding the package send mail
               to: snmplisc@nisc.nyser.net or call +1 518-283-8860.






          IETF NOCTools Working Group                       [Page 119]
^L
          Internet Tool Catalog                              SNMPTRAPD


          NAME
               snmptrapd

          KEYWORDS
               alarm, manager; IP; NMS, SNMP; UNIX.

          ABSTRACT
               Snmptrapd is an SNMP trap agent that runs on UNIX
               derivatives.  It receives and logs traps which are gen-
               erated from snmp agents.  A report generation package
               is included in the NYSERNet SNMP Software Distribution
               to produce reports and graphs of raw data collected via
               SNMP.

          MECHANISM
               Snmptrapd conforms to SNMP as specified in RFC 1098.
               Certain user configurable options are manipulated
               through a simple configuration file.

          CAVEATS
               None.

          BUGS
               None outstanding.  They are fixed as reports come in.
               Report bugs to:  nysersnmp@nisc.nyser.net

          LIMITATIONS
               Snmptrapd only logs traps into a UNIX flat file.

          HARDWARE REQUIRED
               Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
               tion I, DECstation, and a Solbourne 4/802.

          SOFTWARE REQUIRED
               Some UNIX variant.

          AVAILABILITY
               Snmptrapd is available in the NYSERNet SNMP Software
               Distribution, which is licensed, copyrighted software.
               To obtain information regarding the package send mail
               to: snmplisc@nisc.nyser.net or call +1 518-283-8860.










          IETF NOCTools Working Group                       [Page 120]
^L
          Internet Tool Catalog                              SNMPWATCH


          NAME
               snmpwatch

          KEYWORDS
               manager, status; IP; NMS, SNMP; UNIX.

          ABSTRACT
               Snmpwatch is a network monitoring application that mon-
               itors variables in a single network entity and reports
               when they have changed value.

          MECHANISM
               Snmpwatch uses SNMP to gather its information.  The
               entity to be monitored and the variables to be watched
               must be specified on the command line.  Once a value
               changes, snmpwatch prints out the value and the vari-
               able to the standard output.

          CAVEATS
               An SNMP agent must be running on the network entity
               being monitored.  Upon invocation, the initial value of
               each variable will printed out to the standard output.

          BUGS
               None outstanding.  They are fixed as reports come in.
               Report bugs to:  nysersnmp@nisc.nyser.net

          LIMITATIONS
               Only one network entity can be managed per invocation.

          HARDWARE REQUIRED
               Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
               tion I, DECstation, and a Solbourne 4/802.

          SOFTWARE REQUIRED
               Some UNIX variant or some other OS with a Berkeley
               Socket Compatibility Library.

          AVAILABILITY
               Snmpwatch is available in the NYSERNet SNMP Software
               Distribution, which is licensed, copyrighted software.
               To obtain information regarding the package send mail
               to: snmplisc@nisc.nyser.net or call +1 518-283-8860.








          IETF NOCTools Working Group                       [Page 121]
^L
          Internet Tool Catalog                               SNMPXBAR


          NAME
               snmpxbar

          KEYWORDS
               manager, status; IP; NMS, SNMP, X; UNIX.

          ABSTRACT
               Snmpxbar is a network monitoring application based on
               X-Windows Version 11 Release 2 and the Simple Network
               Management Protocol.  The application monitors a single
               numeric MIB object and displays its value in a bar
               chart.  Snmpxbar supports color graphics.

          MECHANISM
               Snmpxbar uses SNMP to gather its information.  The MIB
               object to be graphed must be specified on the command
               line.  The polling interval can be changed dynamically
               from within snmpxbar.

          CAVEATS
               An SNMP agent must be running in the network entity
               being monitored in order for snmpxbar to be useful.

          BUGS
               Bugs are fixed as reports come in.  Report bugs to:
               nysersnmp@nisc.nyser.net

          LIMITATIONS
               Can only graph one numeric MIB object per invocation.

          HARDWARE REQUIRED
               Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
               tion I, DECstation, and a Solbourne 4/802.

          SOFTWARE REQUIRED
               Some UNIX variant or some other OS with a Berkeley
               Socket Compatibility Library.  X-Windows.

          AVAILABILITY
               Snmpxbar is available in the NYSERNet SNMP Software
               Distribution, which is licensed, copyrighted software.
               To obtain information regarding the package send mail
               to: snmplisc@nisc.nyser.net or call +1 518-283-8860.








          IETF NOCTools Working Group                       [Page 122]
^L
          Internet Tool Catalog                              SNMPXCONN


          NAME
               snmpxconn

          KEYWORDS
               manager, map, status; IP; NMS, SNMP, X; UNIX.

          ABSTRACT
               Snmpxconn is a network monitoring application based on
               X-Windows Version 11 Release 2 and the Simple Network
               Management Protocol.  The application monitors a number
               of (configurable) network entities and graphically dep-
               icts the TCP connections associated with the network
               entities via a TCP topology map.

          MECHANISM
               Snmpxconn uses SNMP to gather its information.  A con-
               figuration file is used to determine the network enti-
               ties to be monitored.  There are certain command line
               arguments which manipulate the X environment and SNMP
               actions.

          CAVEATS
               An SNMP agent must be running in the network entity
               being monitored in order for snmpxconn to be useful.

          BUGS
               None outstanding.  They are fixed as reports come in.
               Report bugs to:  nysersnmp@nisc.nyser.net

          LIMITATIONS
               SNMP polling is done synchronously.  The network enti-
               ties must be configured by manually adding information
               to a configuration file.

          HARDWARE REQUIRED
               Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
               tion I, DECstation, and a Solbourne 4/802.

          SOFTWARE REQUIRED
               Some UNIX variant or some other OS with a Berkeley
               Socket Compatibility Library.  X-Windows.

          AVAILABILITY
               Snmpxconn is available in the NYSERNet SNMP Software
               Distribution, which is licensed, copyrighted software.
               To obtain information regarding the package send mail
               to: snmplisc@nisc.nyser.net or call +1 518-283-8860.




          IETF NOCTools Working Group                       [Page 123]
^L
          Internet Tool Catalog                               SNMPXMON


          NAME
               snmpxmon

          KEYWORDS
               manager, map, status; IP; NMS, SNMP, X; UNIX.

          ABSTRACT
               Snmpxmon is a network monitoring application based on
               X-Windows Version 11 Release 2 and the Simple Network
               Management Protocol.  This application will determine
               the status of sites and links it is configured to moni-
               tor (via its configuration file) by querying the desig-
               nated sites and then displaying the result in a map
               form.  Snmpxmon supports color graphics.

          MECHANISM
               Snmpxmon uses SNMP to gather its information.  A confi-
               guration file is used to design the topology map.
               There are certain command line arguments which manipu-
               late the X environment and SNMP actions.

          CAVEATS
               An SNMP agent must be running in the network entity
               being monitored in order for snmpxmon to be useful.

          BUGS
               None outstanding.  They are fixed as reports come in.
               Report bugs to:  nysersnmp@nisc.nyser.net

          LIMITATIONS
               SNMP polling is done synchronously.  The topology map
               must be configured by hand.

          HARDWARE REQUIRED
               Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
               tion I, DECstation, and a Solbourne 4/802.

          SOFTWARE REQUIRED
               Some UNIX variant or some other OS with a Berkeley
               Socket Compatibility Library.  X-Windows.

          AVAILABILITY
               Snmpxmon is available in the NYSERNet SNMP Software
               Distribution, which is licensed, copyrighted software.
               To obtain information regarding the package send mail
               to: snmplisc@nisc.nyser.net or call +1 518-283-8860.





          IETF NOCTools Working Group                       [Page 124]
^L
          Internet Tool Catalog                              SNMPXPERF


          NAME
               snmpxperf

          KEYWORDS
               manager, status; IP; NMS, SNMP, X; UNIX.

          ABSTRACT
               Snmpxperf is a network monitoring application based on
               X-Windows Version 11 Release 2 and the Simple Network
               Management Protocol.  The application monitors a single
               numeric MIB object and displays its value in an EKG
               style histogram.  Snmpxperf supports color graphics.

          MECHANISM
               Snmpxperf uses SNMP to gather its information.  The MIB
               object to be graphed must be specified on the command
               line.  The polling interval can be changed dynamically
               from within snmpxperf.

          CAVEATS
               An SNMP agent must be running in the network entity
               being monitored in order for snmpxperf to be useful.

          BUGS
               Auto-scaling sometimes doesn't downscale the EKG-graph
               enough on large spikes.  This results in some of the
               graph running into the button boxes at the top of the
               window.  Generally, Bugs are fixed as reports come in.
               Report bugs to:  nysersnmp@nisc.nyser.net

          LIMITATIONS
               Can only graph one numeric MIB object per invocation.

          HARDWARE REQUIRED
               Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
               tion I, DECstation, and a Solbourne 4/802.

          SOFTWARE REQUIRED
               Some UNIX variant or some other OS with a Berkeley
               Socket Compatibility Library.  X-Windows.

          AVAILABILITY
               Snmpxperf is available in the NYSERNet SNMP Software
               Distribution, which is licensed, copyrighted software.
               To obtain information regarding the package send mail
               to: snmplisc@nisc.nyser.net or call +1 518-283-8860.





          IETF NOCTools Working Group                       [Page 125]
^L
          Internet Tool Catalog                           SNMPXPERFMON


          NAME
               snmpxperfmon

          KEYWORDS
               manager, status, traffic; IP; NMS, SNMP, X; UNIX.

          ABSTRACT
               Snmpxperfmon is a network monitoring application based
               on X-Windows Version 11 Release 2 and the Simple Net-
               work Management Protocol.  The application monitors a
               single Network Entity and displays graphical informa-
               tion pertaining to the entities interface traffic
               statistics.  Snmpxperfmon supports color graphics.

          MECHANISM
               Snmpxperfmon uses SNMP to gather its information.  The
               MIB agent to be polled must be specified on the command
               line.  The agent is then queried about all of its
               interfaces.  Four EKG-style graphs are constructed for
               each interface (input pkts, output pkts, input Octets,
               output Octets).

          CAVEATS
               An SNMP agent must be running in the network entity
               being monitored in order for snmpxperfmon to be useful.

          BUGS
               Generally, bugs are fixed as reports come in.  Report
               bugs to:  nysersnmp@nisc.nyser.net

          LIMITATIONS
               Can only graph one network entity per invocation.  Can
               only graph the amount of interfaces which will fit on a
               single bitmap display.  Does not auto-scale or resize.

          HARDWARE REQUIRED
               Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
               tion I, DECstation, and a Solbourne 4/802.

          SOFTWARE REQUIRED
               Some UNIX variant or some other OS with a Berkeley
               Socket Compatibility Library.  X-Windows.

          AVAILABILITY
               Snmpxperfmon is available in the NYSERNet SNMP Software
               Distribution, which is licensed, copyrighted software.
               To obtain information regarding the package send mail
               to: snmplisc@nisc.nyser.net or call +1 518-283-8860.



          IETF NOCTools Working Group                       [Page 126]
^L
          Internet Tool Catalog                           SNMPXPERFMON


          NAME
               snmpxrtmetric

          KEYWORDS
               manager, routing; IP; NMS, SNMP, X; UNIX.

          ABSTRACT
               Snmpxrtmetric is a network monitoring application based
               on X-Windows Version 11 Release 2 and the Simple Net-
               work Management Protocol.  The application monitors the
               routing table of a specific agent and displays the RIP
               routing metric of certain destination networks in bar
               chart format.

          MECHANISM
               Snmpxrtmetric uses SNMP to gather its information.  A
               configuration file is used to determine which destina-
               tion networks will be graphed.  The agent to be queried
               is specified on the command line.  Snmpxrtmetrtic sup-
               ports color graphics.

          CAVEATS
               An SNMP agent must be running in the network entity
               being monitored in order for snmpxrtmetric to be use-
               ful.

          BUGS
               None outstanding.  They are fixed as reports come in.
               Report bugs to:  nysersnmp@nisc.nyser.net

          LIMITATIONS
               SNMP polling is done synchronously.  The destination
               networks must be configured by manually adding informa-
               tion to a configuration file.

          HARDWARE REQUIRED
               Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
               tion I, DECstation, and a Solbourne 4/802.

          SOFTWARE REQUIRED
               Some UNIX variant or some other OS with a Berkeley
               Socket Compatibility Library.  The X window system.









          IETF NOCTools Working Group                       [Page 127]
^L
          Internet Tool Catalog                          SNMPXRTMETRIC



          AVAILABILITY
               Snmpxrtmetric is available in the NYSERNet SNMP
               Software Distribution, which is licensed, copyrighted
               software.  To obtain information regarding the package
               send mail to: snmplisc@nisc.nyser.net or call +1 518-
               283-8860.












































          IETF NOCTools Working Group                       [Page 128]
^L
          Internet Tool Catalog                          SPIDERMONITOR


          NAME
               SpiderMonitor P220, K220 and
               SpiderAnalyzer P320, K320

          KEYWORDS
               alarm, analyzer, generator, traffic; DECnet, ethernet,
               IP, OSI; eavesdrop; standalone; sourcelib.

          ABSTRACT
               The SpiderMonitor and SpiderAnalyzer are protocol
               analyzers for performing ethernet LAN diagnostics, mon-
               itoring, traffic generation, and troubleshooting.  The
               SpiderMonitor has the capability of capturing every
               packet on a network and of decoding the first four
               layers of the OSI protocol model.  The SpiderAnalyzer
               has additional software for decoding higher protocol
               layers.  Protocol suites understood: TCP/IP (including
               SNMP and applications-layer protocols), OSI, XNS, DEC-
               net and IPX.  User-definable decodes can be written in
               'C' with the Microsoft version 5.0 'C' compiler.  A
               decode guide is provided.

               The SpiderAnalyzer supports multiple simultaneous
               filters for capturing packets using predefined patterns
               and error states.  Filter patterns can also trigger on
               NOT matching 1 or more filters, an alarm, or a speci-
               fied time.

               The SpiderAnalyzer can also employ TDR (Time Domain
               Reflectometry) to find media faults, open or short cir-
               cuits, or transceiver faults.  It can transmit OSI,
               XNS, and Xerox link-level echo packets to user-
               specified stations, performs loop round tests.

               In traffic generation mode, the SpiderAnalyzer has the
               ability to generate packets at random intervals of ran-
               dom lengths or any combination of random or fixed
               interval or length, generation of packets with CRC
               errors, or packets that are too short, or packets that
               are too long.

               Output from the SpiderMonitor/Analyzer can be imported
               to database or spreadsheet packages.

          MECHANISM
               The SpiderMonitor and Spider Analyzer are available as
               stand-alone, IBM PC compatible packages based upon a
               Compaq III portable system, or as a plug-in boards for



          IETF NOCTools Working Group                       [Page 129]
^L
          Internet Tool Catalog                          SPIDERMONITOR


               any IBM XT/AT compatible machine.  The model 220 (Spi-
               derMonitor) systems provide a functional base suited
               for most network management needs.  The model 320 (Spi-
               derAnalyzer) systems provide extended functionality in
               the development mode and traffic generation mode as
               well more filtering capabilities than the 220 models.

          CAVEATS
               Traffic generation will congest an operational ether-
               net.

          BUGS
               None known.

          LIMITATIONS
               Monitoring of up to 1024 stations and buffering of up
               to 1500 packets.  The model 220 provides for 3 filters
               with a filter depth of 46 bytes.  The model 320 pro-
               vides for 4 filters and a second level of filtering
               with a filter depth of 64 bytes.

          HARDWARE REQUIRED
               PX20s are self contained, the KX20s require an IBM
               PC/XT-AT compatible machine with 5 megabytes of hard
               disk storage and the spare slot into which the board
               kit is plugged.

          SOFTWARE REQUIRED
               None.  The SpiderAnalyzer requires the Microsoft 'C'
               Compiler, Version 5.0 for writing user defined decodes.

          AVAILABILITY
               The SpiderMonitor/Analyzer is available commercially.
               For information on your local representative, call or
               write:

                    Spider Systems, Inc.
                    12 New England Executive Park
                    Burlington, MA  01803
                    Telephone:  617-270-3510
                    FAX:        617-270-9818










          IETF NOCTools Working Group                       [Page 130]
^L
          Internet Tool Catalog                                  SPIMS


          NAME
               SPIMS -- the Swedish Institute of Computer Science
               (SICS) Protocol Implementation Measurement System tool.

          KEYWORDS
               benchmark, debugger; IP, OSI; spoof; UNIX.

          ABSTRACT
               SPIMS is used to measure the performance of protocol
               and "protocol-like" services including response time
               (two-way delay), throughput and the time to open and
               close connections.  It has been used to:

               o+    benchmark alternative protocol implementations,

               o+    observe how performance varies when parameters in
                    specific implementations have been varied (i.e.,
                    to tune parameters).

               SPIMS currently has interfaces to the DoD Internet Pro-
               tocols: UDP, TCP, FTP, SunRPC, the OSI protocols from
               the ISODE 4.0 distribution package: FTAM, ROSE, ISO TP0
               and to Sunlink 5.2 ISO TP4 as well as Stanford's VMTP.
               Also available are a rudimentary set of benchmarks,
               stubs for new protocol interfaces and a user manual.
               For an example of the use of SPIMS to tune protocols,
               see:
                    Nordmark & Cheriton, "Experiences from VMTP: How
                    to achieve low response time," _I_F_I_P _W_G_6._1/_6._4:
                    _P_r_o_t_o_c_o_l_s _f_o_r _H_i_g_h-_S_p_e_e_d _N_e_t_w_o_r_k_s, May 1989,
                    Zurich.  To be published.

          MECHANISM

               SPIMS runs as user processes and uses a TCP connection
               for measurement set-up.  Measurements take place
               between processes over the measured protocol.  SPIMS
               generates messages and transfers them via the measured
               protocol service according to a user-supplied specifi-
               cation.  SPIMS has a unique measurement specification
               language that is used to specify a measurement session.
               In the language there are constructs for different
               application types (e.g., bulk data transfer), for
               specifying frequency and sequence of messages, for dis-
               tribution over message sizes and for combining basic
               specifications.  These specifications are independent
               of both protocols and protocol implementations and can
               be used for benchmarking.  For more details on the



          IETF NOCTools Working Group                       [Page 131]
^L
          Internet Tool Catalog                                  SPIMS


               internals of SPIMS, see:
                    Nordmark & Gunningberg, "SPIMS: A Tool for Proto-
                    col Implementation Performance Measurements" _P_r_o_c.
                    _o_f _1_3:_t_h _C_o_n_f. _o_n _L_o_c_a_l _C_o_m_p_u_t_e_r _N_e_t_w_o_r_k_s, Min-
                    neapolis 1989, pp 222-229.

          CAVEATS
               None.

          BUGS
               None known.

          LIMITATIONS
               None reported.

          HARDWARE REQUIRED
               No restrictions.

          SOFTWARE REQUIRED
               SPIMS is implemented on UNIX, including SunOS 4.,
               4.3BSD UNIX, DN (UNIX System V, with extensions) and
               Ultrix 2.0/3.0.  It requires a TCP connection for meas-
               urement set-up.  No kernel modifications or any modifi-
               cations to measured protocols are required.

          AVAILABILITY
               SPIMS is not in the public domain; the software is
               covered by licenses.  The Swedish Institute of Computer
               Science has released the research prototype of SPIMS
               for research and non-commercial use.  Commercial organ-
               izations may obtain the research prototype, but it is
               for internal research only and for no commercial use
               whatsoever. A commercial, supported version of SPIMS is
               distributed by TeleLOGIC Uppsala AB, Sweden.

               For universities and non-profit organizations, SPIMS
               source code is distributed free of charge.  There are
               two ways to get the software:

               1.   FTP.  If you have an Internet FTP connection, you
                    can use anonymous FTP to sics.se [192.16.123.90],
                    and retrieve the file in pub/spims-
                    dist/dist890915.tar.Z (this is a .6MB tar image)
                    in BINARY mode.  Log in as user anonymous and at
                    the password prompt, use your complete electronic
                    mail address.

               2.   On a Sun 1/4-inch cartridge tape.  For mailing, a



          IETF NOCTools Working Group                       [Page 132]
^L
          Internet Tool Catalog                                  SPIMS


                    handling fee of US$150.00 will be charged.  Submit
                    a bank check with the request.  Do not send tapes
                    or envelopes.

               For other organizations, the SPIMS source code for the
               research prototype is distributed for a one-time fee of
               US$500.00.  Organizations interested in the research
               prototype need to contact SICS via email and briefly
               motivate why they qualify (non-commercial use) for the
               research prototype.  They will thereafter get a permis-
               sion to obtain a copy from the same distribution source
               as for universities.

               For more information about the research prototype dis-
               tribution, contact:

                    Swedish Institute of Computer Science
                    Att: Birgitta Klingenberg
                    P.O. Box 1263
                    S-164 28 Kista
                    SWEDEN

                    e-address: spims@sics.se
                    Phone: +46-8-7521500, Fax: +46-8-7517230

               TeleLOGIC Uppsala AB, a subsidiary of Swedish Telecom,
               distributes and supports a version of SPIMS for commer-
               cial use.  It consists of object code for SunOS 4.,
               4.3BSD UNIX, DNIX, and Ultrix 2.0/3.0.  Support for
               other UNIX-like implementations will be considered
               according to demand.  The same interfaces to the DoD
               Internet and OSI protocols from the ISODE 4.0 are
               included as well as a user manual.

               For further information about SPIMS for the commercial
               user please contact:
                    Claes Hojenberg
                    TeleLOGIC Uppsala AB
                    P.O. Box 1218
                    S-751 42 UPPSALA
                    Sweden

                    e-address: claes@uplog.se
                    Phone: +46-18-189400, Fax: +46-18-132039







          IETF NOCTools Working Group                       [Page 133]
^L
          Internet Tool Catalog                                  SPRAY


          NAME
               spray

          KEYWORDS
               benchmark, generator; IP; ping; UNIX.

          ABSTRACT
               Spray is a traffic generation tool that generates RPC
               or UDP packets, or ICMP Echo Requests.  The packets are
               sent to a remote procedure call application at the des-
               tination host.  The count of received packets is
               retrieved from the remote application after a certain
               number of packets have been transmitted.  The differ-
               ence in packets received versus packets sent represents
               (on a LAN) the packets that the destination host had to
               drop due to increasing queue length.  A measure of
               throughput relative to system speed and network load
               can thus be obtained.

          MECHANISM
               See above.

          CAVEATS
               Spray can congest a network.

          BUGS
               None known.

          LIMITATIONS
               None reported.

          HARDWARE REQUIRED
               No restrictions.

          SOFTWARE REQUIRED
               SunOS

          AVAILABILITY
               Supplied with SunOS.












          IETF NOCTools Working Group                       [Page 134]
^L
          Internet Tool Catalog                                TCPDUMP


          NAME
               tcpdump

          KEYWORDS
               traffic; ethernet, IP, NFS; UNIX, VMS; free.

          ABSTRACT
               Tcpdump can interpret and print headers for the follow-
               ing protocols: ethernet, IP, ICMP, TCP, UDP, NFS, ND,
               ARP/RARP, AppleTalk.  Tcpdump has proven useful for
               examining and evaluating the retransmission and window
               management operations of TCP implementations.

          MECHANISM
               Much like etherfind, tcpdump writes a log file of the
               frames traversing an ethernet interface.  Each output
               line includes the time a packet is received, the type
               of packet, and various values from its header.

          CAVEATS
               None.

          BUGS
               None known.

          LIMITATIONS
               Public domain version requires a kernel patch for
               SunOS.

          HARDWARE REQUIRED
               Ethernet.

          SOFTWARE REQUIRED
               BSD UNIX or related OS, or VMS.

          AVAILABILITY
               Available, though subject to copyright restrictions,
               via anonymous FTP from ftp.ee.lbl.gov.  The source and
               documentation for the tool is in compressed tar format,
               in file tcpdump.tar.Z.  Also available from
               spam.itstd.sri.com, in directory pub.  For VMS hosts
               with DEC ethernet controllers, available as part of TGV
               MultiNet IP software package.








          IETF NOCTools Working Group                       [Page 135]
^L
          Internet Tool Catalog                              TCPLOGGER


          NAME
               tcplogger

          KEYWORDS
               traffic; IP; eavesdrop; UNIX; free.

          ABSTRACT
               Tcplogger consists of modifications to the 4.3BSD UNIX
               source code, and a large library of post-processing
               software.  Tcplogger records timestamped information
               from TCP and IP packets that are sent and received on a
               specified connection.  For each TCP packet, information
               such as sequence number, acknowledgement sequence
               number, packet size, and header flags is recorded.  For
               an IP packet, header length, packet length and TTL
               values are recorded.  Customized use of the TCP option
               field allows the detection of lost or duplicate pack-
               ets.

          MECHANISM
               Routines of 4.3BSD UNIX in the netinet directory have
               been modified to append information to a log in memory.
               The log is read continuously by a user process and
               written to a file.  A TCP option has been added to
               start the logging of a connection.  Lots of post-
               processing software has been written to analyze the
               data.

          CAVEATS
               None.

          BUGS
               None known.

          LIMITATIONS
               To get a log at both ends of the connection, the modi-
               fied kernel should be run at both the hosts.

               All connections are logged in a single file, but
               software is provided to filter out the record of a sin-
               gle connection.

          HARDWARE REQUIRED
               No restrictions.

          SOFTWARE REQUIRED
               4.3BSD UNIX (as modified for this tool).




          IETF NOCTools Working Group                       [Page 136]
^L
          Internet Tool Catalog                              TCPLOGGER



          AVAILABILITY
               Free, although a 4.3BSD license is required.  Contact
               Olafur Gudmundsson (ogud@cs.umd.edu).















































          IETF NOCTools Working Group                       [Page 137]
^L
          Internet Tool Catalog                              TOKENVIEW


          NAME
               TokenVIEW

          KEYWORDS
               control, manager, status; ring; NMS, proprietary; DOS.

          ABSTRACT
               Network Management tool for 4/16 Mbit IEEE 802.5 Token
               Ring Networks.  Monitors active nodes and ring errors.
               Maintains database of nodes, wire centers and their
               connections.  Separate network management ring allows
               remote configuration of wire centers.

          MECHANISM
               A separate network management ring used with Proteon
               Intelligent Wire Centers allows wire center configura-
               tion information to be read and modified from a single
               remote workstation.  A log of network events used with
               a database contain nodes, wire centers and their con-
               nections, facilitates tracking and correction of net-
               work errors.  Requires an "E" series PROM, sold with
               package.

          CAVEATS
               Currently, only ISA bus cards support the required E
               series PROM.

          BUGS
               None known.

          LIMITATIONS
               256 nodes, 1 net.

          HARDWARE REQUIRED
               512K RAM, CGA or better, hard disk, mouse supported.

          SOFTWARE REQUIRED
               MS-DOS, optional mouse driver

          AVAILABILITY
               Fully supported product of Proteon, Inc.  Previously
               sold as Advanced Network Manager (ANM).  For more in-
               formation, contact:
                   Proteon, Inc.             Phone: (508) 898-2800
                   2 Technology Drive        Fax:   (508) 366-8901
                   Westborough, MA  01581    Telex: 928124





          IETF NOCTools Working Group                       [Page 138]
^L
          Internet Tool Catalog                             TRACEROUTE


          NAME
               traceroute

          KEYWORDS
               routing; IP; ping; UNIX, VMS; free.

          ABSTRACT
               Traceroute is a tool that allows the route taken by
               packets from source to destination to be discovered.
               It can be used for situations where the IP record route
               option would fail, such as intermediate gateways dis-
               carding packets, routes that exceed the capacity of an
               datagram, or intermediate IP implementations that don't
               support record route.  Round trip delays between the
               source and intermediate gateways are also reported
               allowing the determination of individual gateways con-
               tribution to end-to-end delay.

               Enhanced versions of traceroute have been developed
               that allow specification of loose source routes for
               datagrams.  This allows one to investigate the return
               path from remote machines back to the local host.

          MECHANISM
               Traceroute relies on the ICMP TIME_EXCEEDED error
               reporting mechanism.  When an IP packet is received by
               an gateway with a time-to-live value of 0, an ICMP
               packet is sent to the host which generated the packet.
               By sending packets to a destination with a TTL of 0,
               the next hop can be identified as the source of the
               ICMP TIME EXCEEDED message.  By incrementing the TTL
               field the subsequent hops can be identified.  Each
               packet sent out is also time stamped.  The time stamp
               is returned as part of the ICMP packet so a round trip
               delay can be calculated.

          CAVEATS
               Some IP implementations forward packets with a TTL of
               0, thus escaping identification.  Others use the TTL
               field in the arriving packet as the TTL for the ICMP
               error reply, which delays identification.

               Sending datagrams with the source route option will
               cause some gateways to crash.  It is considered poor
               form to repeat this behavior.

          BUGS
               None known.



          IETF NOCTools Working Group                       [Page 139]
^L
          Internet Tool Catalog                             TRACEROUTE



          LIMITATIONS
               Most versions of UNIX have errors in the raw IP code
               that require kernel mods for the standard version of
               traceroute to work.  A version of traceroute exists
               that runs without kernel mods under SunOS 3.5 (see
               below), but it only operates over an ethernet inter-
               face.

          HARDWARE REQUIRED
               No restrictions.

          SOFTWARE REQUIRED
               BSD UNIX or related OS, or VMS.

          AVAILABILITY
               Available by anonymous FTP from ftp.ee.lbl.gov, in file
               traceroute.tar.Z.  It is also available from
               uc.msc.umn.edu.

               A version of traceroute that supports Loose Source
               Record Route, along with the source code of the
               required kernel modifications and a Makefile for
               installing them, is available via anonymous FTP from
               zerkalo.harvard.edu, in directory pub, file
               traceroute_pkg.tar.Z.

               A version of traceroute that runs under SunOS 3.5 and
               does NOT require kernel mods is available via anonymous
               FTP from dopey.cs.unc.edu, in file
               ~ftp/pub/traceroute.tar.Z.

               For VMS, traceroute is available as part of TGV Mul-
               tiNet IP software package.

















          IETF NOCTools Working Group                       [Page 140]
^L
          Internet Tool Catalog                                   TRPT


          NAME
               TRPT -- transliterate protocol trace

          KEYWORDS
               traffic; IP; eavesdrop; UNIX; free.

          ABSTRACT
               TRPT displays a trace of a TCP socket events.  When no
               options are supplied, TRPT prints all the trace records
               found in a system, grouped according to TCP connection
               protocol control block (PCB).

               An example of TRPT output is:

               38241 ESTABLISHED:input
               [e0531003..e0531203)@6cc5b402(win=4000)<ACK> -> ESTA-
               BLISHED
               38241 ESTABLISHED:user RCVD -> ESTABLISHED
               38266 ESTABLISHED:output
               6cc5b402@e0531203(win=4000)<ACK> -> ESTABLISHED
               38331 ESTABLISHED:input
               [e0531203..e0531403)@6cc5b402(win=4000)<ACK,FIN,PUSH>
               -> CLOSE_WAIT
               38331 CLOSE_WAIT:output
               6cc5b402@e0531404(win=3dff)<ACK> -> CLOSE_WAIT
               38331 CLOSE_WAIT:user RCVD -> CLOSE_WAIT
               38343 LAST_ACK:output
               6cc5b402@e0531404(win=4000)<ACK,FIN> -> LAST_ACK
               38343 CLOSE_WAIT:user DISCONNECT -> LAST_ACK
               38343 LAST_ACK:user DETACH -> LAST_ACK

          MECHANISM
               TRPT interrogates the buffer of TCP trace records that
               is created when a TCP socket is marked for debugging.

          CAVEATS
               Prior to using TRPT, an analyst should take steps to
               isolate the problem connection and find the address of
               its protocol control blocks.

          BUGS
               None reported.

          LIMITATIONS
               A socket must have the debugging option set for TRPT to
               operate.  Another problem is that the output format of
               TRPT is difficult.




          IETF NOCTools Working Group                       [Page 141]
^L
          Internet Tool Catalog                                   TRPT


          HARDWARE REQUIRED
               No restrictions.

          SOFTWARE REQUIRED
               BSD UNIX or related OS.

          AVAILABILITY
               Included with BSD and SunOS distributions.  Available
               via anonymous FTP from uunet.uu.net, in file bsd-
               sources/src/etc/trpt.tar.Z.









































          IETF NOCTools Working Group                       [Page 142]
^L
          Internet Tool Catalog                                   TTCP


          NAME
               TTCP

          KEYWORDS
               benchmark, generator; IP; ping; UNIX, VMS; free.

          ABSTRACT
               TTCP is a traffic generator that can be used for test-
               ing end-to-end throughput.  It is good for evaluating
               TCP/IP implementations.

          MECHANISM
               Cooperating processes are started on two hosts.  The
               open a TCP connection and transfer a high volume of
               data.  Delay and throughput are calculated.

          CAVEATS
               Will greatly increase system load.

          BUGS
               None known.

          LIMITATIONS
               None reported.

          HARDWARE REQUIRED
               No restrictions.

          SOFTWARE REQUIRED
               BSD UNIX or related OS, or VMS.

          AVAILABILITY
               Source for BSD UNIX is available via anonymous FTP from
               vgr.brl.mil, in file ftp/pub/ttcp.c, and from sgi.com,
               in file sgi/src/ttcp.c.  A version of TTCP has also
               been submitted to the USENET news group
               comp.sources.unix.  For VMS, ttcp.c is included in the
               MultiNet Programmer's Kit, a standard feature of TGV
               MultiNet IP software package.












          IETF NOCTools Working Group                       [Page 143]
^L
          Internet Tool Catalog                             UNISYS NCC


          NAME
               Unisys Network Control Center (NCC)

          KEYWORDS
               alarm, benchmark, control, generator, manager, map,
               reference, status, traffic; ethernet, FDDI, IP; NMS,
               ping, SNMP; UNIX.

          ABSTRACT
               The Unisys Defense Systems Network Control Center (NCC)
               provides high-performance software to support the
               management and control of TCP/IP-based networks.  The
               network management system uses the Simple Network
               Management Protocol (SNMP) to exchange management
               information between the NCC and network devices.  The
               NCC supports the Management Information Base (MIB)
               [RFC-1066] and the Structure and Identification of
               Management Information for TCP/IP-based Internets
               [RFC-1065].  In addition, Unisys has extended the MIB
               definitions to support the features of Unisys FDDI LAN
               devices, such as the FDDI Smart Concentrators, the FDDI
               Host Network Front Ends, and the Remote FDDI, FDDI-to-
               LAN, and FDDI-to-DDN gateways.

               The NCC supports seven applications.  The network
               topology map displays the physical and logical maps of
               the network.  The configuration management tool sup-
               ports the modification and validation of network device
               configuration data as well as the modification of MIB
               configuration data.  The performance monitoring tool
               supports the collection and analysis of statistical
               parameters from network devices.  The status monitoring
               tool reports on the up/down status and responsiveness
               of network devices using ICMP.  The accounting tool is
               used to collect, store, and display user job activity
               at the subscriber hosts.  The NCC database entry sup-
               ports RFC 1066 object definitions and Unisys-specific
               object definitions to support the Unisys FDDI devices.
               And finally, the trap reporting tool reports the
               arrival of error and event notifications using UDP
               datagrams.  The NCC supports all the trap messages
               defined in RFC 1098.

          MECHANISM
               The NCC is based on the Simple Network Management Pro-
               tocol (SNMP).





          IETF NOCTools Working Group                       [Page 144]
^L
          Internet Tool Catalog                             UNISYS NCC



          CAVEATS
               None.

          BUGS
               None known.

          LIMITATIONS
               None reported.

          HARDWARE REQUIRED
               A minimal platform consists of a Sun 3/60FC-8, with at
               least 200 MB disk and cartridge tape (1/4").  A full-
               sized color monitor, more disk, and a workstation based
               on a higher performance processor is beneficial to NCC
               activities.

          SOFTWARE REQUIRED
               SunOS Version 4.0 running the SunView windowing en-
               vironment and the SYBASE Relational Data Base Manage-
               ment System.

          AVAILABILITY
               Commercially available as a turn-key package or as a
               software product from:
                    Unisys Defense Systems
                    5151 Camino Ruiz
                    Camarillo, California 93010
                    (805) 987-6811
                    (Dale Russell <dsr@cam.unisys.com>)





















          IETF NOCTools Working Group                       [Page 145]
^L
          Internet Tool Catalog                        WIN/MGT STATION


          NAME
               WIN/MGT Station -- Network Management Station for
               SunOS.

          KEYWORDS
               alarm, control, manager, routing, status, traffic; eth-
               ernet, IP; NMS, SNMP, X; UNIX; library.

          ABSTRACT
               WIN/MGT Station for SunOS is a network management
               software product based on the SNMP.  It provides the
               capability to manage standards-based networking pro-
               ducts from The Wollongong Group as well as other ven-
               dors.  Fully compliant with RFCs 1065, 1066 and 1098,
               WIN/MGT Station uses a menu-driven graphical user
               interface.

               WIN/MGT capabilities include configuration, performance
               and fault management for SNMP-based agents.  The
               WIN/MGT station can perform polling to monitor the
               status of all MIB variables defined in RFC 1066,
               "Management Information Base for network management of
               TCP/IP-based internets."  In addition, the WIN/MGT Sta-
               tion can process "trap" messages from SNMP agents.
               Furthermore, the WIN/MGT Station can support any
               private extension to the Management Information Base
               with minimal user configuration.

               An icon-driven network interface map allows the user to
               monitor their network topology and status.  Changes in
               the operational status of any manageable network ele-
               ment is displayed visually and audibly.

               The WIN/MGT package includes an Applications Program-
               ming Interface (API) for the "C" language.  The API is
               a set of libraries that enable an applications program
               to perform SNMP "set" and "get" operations.  This
               allows users to integrate site-specific applications
               with WIN/MGT.

               SNMP agent software for the Sun 3 host is also provided
               so that the Network Management Station itself can also
               be monitored and managed.

          MECHANISM
               The WIN/MGT Station uses SNMP to monitor and control
               SNMP agents.




          IETF NOCTools Working Group                       [Page 146]
^L
          Internet Tool Catalog                        WIN/MGT STATION


          CAVEATS
               None.

          BUGS
               None known.

          LIMITATIONS
               A theoretical limitation of approximately 18,000 net-
               work elements can be managed.

          HARDWARE REQUIRED
               Any model of Sun 3 system.  Recommended minimums
               include 8 MB RAM, 100 MB disk space (30 MB to start),
               and color monitor.  Also tested on DECstation 3100,
               PS/2 (with SCO UNIX) and Macintosh IIcx computer using
               A/UX.

          SOFTWARE REQUIRED
               SunOS 4.x.  MIT X Window System, Release 11, version 3,
               or OpenWindows (X.11/NeWS) from Sun Microsystems, Inc.
               WIN/MGT Station for SunOS is provided on 1/4" tape in
               cpio format.

          AVAILABILITY
               A commercial product of:
                    The Wollongong Group, Inc.
                    1129 San Antonio Rd.
                    Palo Alto, CA  94303
                    (415) 962-7200 br fax (415) 968-3619
                    internet  oldera@twg.com





















          IETF NOCTools Working Group                       [Page 147]
^L
          Internet Tool Catalog                            XNETMON (I)


          NAME
               xnetmon, xpmon

          KEYWORDS
               alarm, manager, map, status; IP; NMS, SNMP; UNIX.

          ABSTRACT
               Xnetmon and xpmon provide graphical representation of
               performance and status of SNMP-capable network ele-
               ments.  Xnetmon presents a schematic network map
               representing the up/down status of network elements;
               xpmon draws a pen plot style graph of the change over
               time of any arbitrary MIB object (RFC1066).  Both xnet-
               mon and xpmon use the SNMP (RFC1098) for retrieving
               status and performance data.

          MECHANISM
               Xnetmon polls network elements for the status of their
               interfaces on a controllable polling interval.  Pop-up
               windows displaying the values of any MIB variable are
               supported by separate polls.  When SNMP traps are
               received from a network element, that element and all
               adjacent elements are immediately re-polled to update
               their status.  The layout of the network map is stati-
               cally configured.  Xpmon repeatedly polls (using SNMP)
               the designated network element for the value of the
               designated MIB variable on the user-specified interval.
               The change in the variable is then plotted on the strip
               chart.  The strip chart regularly adjusts its scale to
               the current maximum value on the graph.

          CAVEATS
               Polling intervals should be chosen with care so as not
               to affect system performance adversely.

          BUGS
               None known.

          LIMITATIONS
               None reported.

          HARDWARE REQUIRED
               Distributed and supported for Sun-3 systems.

          SOFTWARE REQUIRED
               SunOS 3.5 or 4.x; X11, release 2 or 3.





          IETF NOCTools Working Group                       [Page 148]
^L
          Internet Tool Catalog                            XNETMON (I)



          AVAILABILITY
               Commercial product of:
                    Wellfleet Communications, Inc.
                    12 DeAngelo Drive
                    Bedford, MA 01730-2204
                    (617) 275-2400












































          IETF NOCTools Working Group                       [Page 149]
^L
          Internet Tool Catalog                           XNETMON (II)


          NAME
               XNETMON -- an X windows based SNMP network management
               station from SNMP Research.

          KEYWORDS
               alarm, control, manager, map, routing, security,
               status; DECnet, ethernet, IP, OSI, ring, star; NMS,
               SNMP, X; DOS, UNIX, VMS; sourcelib.

          ABSTRACT
               The XNETMON application implements a powerful network
               management station based on the X window system.  It
               provides network managers tools for fault management,
               configuration management, performance management, and
               security management.  It can be successfully used with
               many types of networks including those based on various
               LAN media, and wide area networks.  XNETMON has been
               used with multiprotocol devices including those which
               support TCP/IP, DECnet, and OSI protocols.  The fault
               management tool displays the map of the network confi-
               guration with node and link state indicated in one of
               several colors to indicate current status.  Alarms may
               be enabled to alert the operator of events occurring in
               the network.  Events are logged to disk.  The confi-
               guration management tool may be used to edit the net-
               work management information base stored in the network
               management station to reflect changes occurring in the
               network.  Other features include graphs and tabular
               tools for use in fault and performance management and
               mechanisms by which additional variables, such as
               vendor-specific variables, may be added.  The XNETMON
               application comes complete with source code including a
               powerful set of portable libraries for generating and
               parsing SNMP messages.  Output data from XNETMON may be
               transferred via flat files for additional report gen-
               eration by a variety of statistical packages.

          MECHANISM
               The XNETMON application is based on the Simple Network
               Management Protocol (SNMP).  Polling is performed via
               the powerful SNMP get-next operator and the SNMP get
               operator.  Trap directed polling is used to regulate
               the focus and intensity of the polling.

          CAVEATS
               None.

          BUGS



          IETF NOCTools Working Group                       [Page 150]
^L
          Internet Tool Catalog                           XNETMON (II)


               None known.

          LIMITATIONS
               The monitored and managed nodes must implement the SNMP
               over UDP per RFC 1098 or must be reachable via a proxy
               agent.

          HARDWARE REQUIRED
               X windows workstation with UDP socket library.  Mono-
               chrome is acceptable but color is far superior.

          SOFTWARE REQUIRED
               X windows version 11 release 3 or later.

          AVAILABILITY
               This is a commercial product available under license
               from:

                    SNMP Research
                    P.O. Box 8593
                    Knoxville, TN 37996-4800
                    (615) 573-1434 (Voice)
                    (615) 573-9197 (FAX)
                    Attn:  Dr. Jeff Case



























          IETF NOCTools Working Group                       [Page 151]
^L
          Internet Tool Catalog                            XNETPERFMON


          NAME
               xnetperfmon -- a graphical network performance and
               fault management tool from SNMP Research.

          KEYWORDS
               manager, status; DECnet, ethernet, IP, OSI, ring, star;
               NMS, SNMP, X; DOS, UNIX, VMS; sourcelib.

          ABSTRACT
               Xnetperfmon may be used to plot SNMP variables as a
               graphical display.  These graphs are often useful for
               fault and performance management.  Variables may be
               plotted as gauges versus time.  Alternatively, counters
               may be plotted as delta count/delta time (rates).  The
               user may easily customize the variables to be plotted,
               labels, step size, update interval, and the like.  The
               scales automatically adjust whenever a point to be
               plotted would go off scale.

          MECHANISM
               The xnetperfmon application communicates with remote
               agents or proxy agents via the Simple Network Manage-
               ment Protocol (SNMP).

          CAVEATS
               All plots for a single invocation of xnetperfmon must
               be for variables provided by a single network manage-
               ment agent.  However, multiple invocations of xnetperf-
               mon may be active on a single display simultaneously or
               proxy agents may be used to summarize information at a
               common point.

          BUGS
               None known.

          LIMITATIONS
               None reported.

          HARDWARE REQUIRED
               Systems supporting X windows.

          SOFTWARE REQUIRED
               X Version 11 release 2 or later.








          IETF NOCTools Working Group                       [Page 152]
^L
          Internet Tool Catalog                            XNETPERFMON



          AVAILABILITY
               This is a commercial product available under license
               from:

                    SNMP Research
                    P.O. Box 8593
                    Knoxville, TN 37996-4800
                    (615) 573-1434 (Voice)
                    (615) 573-9197 (FAX)
                    Attn:  Dr. Jeff Case








































          IETF NOCTools Working Group                       [Page 153]
^L
          Internet Tool Catalog                                    XUP


          NAME
               xup

          KEYWORDS
               status; ping, X; HP.

          ABSTRACT
               Xup uses the X-Windows to display the status of an
               "interesting" set of hosts.

          MECHANISM
               Xup uses ping to determine host status.

          CAVEATS
               Polling for status increases network load.

          BUGS
               None known.

          LIMITATIONS
               None reported.

          HARDWARE REQUIRED
               Runs only on HP series 300 and 800 workstations.

          SOFTWARE REQUIRED
               Version 10 of X-Windows.

          AVAILABILITY
               A standard command for the HP 300 & 800 Workstations.





















          IETF NOCTools Working Group                       [Page 154]
^L
          Appendix                         Network Management Tutorial


                             Network Management Tutorial


          This tutorial is an overview of the practice of network
          management.  Reading this section is no substitute for know-
          ing your system, and knowing how it is used.  Do not wait
          until things break to learn what they ought to do or how
          they usually work: a crisis is not the time for determining
          how "normal" packet traces should look.  Furthermore, it
          takes little imagination to realize that you do not want to
          be digging through manuals while your boss is screaming for
          network service to be restored.

          We assume an acquaintance with the TCP/IP protocol suite and
          the Internet architecture.  There are many available refer-
          ences on these topics, several of which are listed below in
          Section 7.

          Since many of the details of network management are system-
          specific, this tutorial is a bit superficial.  There is,
          however, a more fundamental problem in prescribing network
          management practices: network management is not a well-
          understood endeavor.  At present, the cutting edge of net-
          work management is the use of distributed systems to collect
          and exchange status information, and then to display the
          data as histograms or trend lines.  It is not clear that we
          know what data should be collected, how to analyze it when
          we get it, or how to structure our collection systems.  For
          now, automated, real-time control of internets is an aspira-
          tion, rather than a reality.  The communications systems
          that we field are apparently more complex than we can
          comprehend, which no doubt accounts in part for their fre-
          quently surprising behavior.

          The first section of this tutorial lists the overall goals
          and functions of network management.  It presents several
          aspects of network management, including system monitoring,
          fault detection and isolation, performance testing, confi-
          guration management, and security.  These discussions are
          followed by a bibliographic section.  The tutorial closes
          with some final advice for network managers.

          1. Network Management Goals and Functions

          An organization's view of network management goals is shaped
          by two factors:





          IETF NOCTools Working Group                       [Page 155]
^L
          Appendix                         Network Management Tutorial



               1.   people in the organization depend on the system
                    working,

               2.   LANs, routers, lines, and other communications
                    resources have costs.

          From the organizational vantage point, the ultimate goal of
          network management is to provide a consistent, predictable,
          acceptable level of service from the available data communi-
          cations resources.  To achieve this, a network manager must
          first be able to perform fault detection, isolation, and
          correction.  He must also be able to effect configuration
          changes with a minimum of disruption, and measure the utili-
          zation of system components.

          People actually managing networks have a different focus.
          Network managers are usually evaluated by the availability
          and performance of their communications systems, even though
          many factors of net performance are beyond their control.
          To them, the most important requirement of a network manage-
          ment tool is that it allows the detection and diagnosis of
          faults before users can call to complain: users (and bosses)
          can often be placated just by knowing that a network problem
          has been diagnosed.  Another vital network management func-
          tion is the ability to collect data that justify current or
          future expenditures for the data communications plant and
          staff.

          Following a section on system monitoring, this tutorial
          addresses fault, performance, configuration, and security
          management.  By fault management, we mean the detection,
          diagnosis, and correction of network malfunctions.  Under
          the subject of performance management, we include support
          for predictable, efficient service, as well as capacity
          planning and capacity testing.  Configuration management
          includes support for orderly configuration changes (usually,
          system growth), and local administration of component names
          and addresses.  Security management includes both protecting
          system components from damage and protecting sensitive
          information from unintentional or malicious disclosure or
          corruption.

          Readers familiar with the ISO management standards and
          drafts will note both that we have borrowed heavily from the
          "OSI Management Framework," except that we have omitted the
          "account management" function.  Account management seems a
          bit out of place with the other network management



          IETF NOCTools Working Group                       [Page 156]
^L
          Appendix                         Network Management Tutorial


          functions.  The logging required by account management is
          likely to be done by specialized, dedicated subsystems that
          are distinct from other network management components.
          Hence, this tutorial does not cover account management.
          Rest assured, however, that account management, if required,
          will be adequately supported and staffed.

          For those with a DoD background, security may also seem out
          of place as a subtopic of network management.  Without
          doubt, communications security is an important issue that
          should be considered in its own right.  Because of the
          requirements of trust for security mechanisms, security com-
          ponents will probably not be integrated subcomponents of a
          larger network management system.  Nevertheless, because a
          network manager has a responsibility to protect his system
          from undue security risks, this tutorial includes a discus-
          sion on internet security.

          2. System Monitoring

          System monitoring is a fundamental aspect of network manage-
          ment.  One can divide system monitoring into two rough
          categories: error detection and baseline monitoring.

          System errors, such as misformatted frames or dropped pack-
          ets, are not in themselves cause for concern.  Spikes in
          error rates, however, should be investigated.  It is sound
          practice to log error rates over time, so that increases can
          be recognized.  Furthermore, logging error rates as a func-
          tion of traffic rates can be used to detect congestion.
          Investigate unusual error rates and other anomalies as they
          are detected, and keep a notebook to record your
          discoveries.

          Day-to-day traffic should be monitored, so that the opera-
          tional baselines of a system and its components can be
          determined.  As well as being essential for performance
          management, baseline determination and traffic monitoring
          are the keys to early fault detection.

          A preliminary step to developing baseline measurements is
          construction of a system map: a graphical representation of
          the system components and their interfaces.  Then, measure-
          ments of utilization (i.e., use divided by capacity) are
          needed.  Problems are most likely to arise, and system tun-
          ing efforts are most likely to be beneficial, at highly
          utilized components.




          IETF NOCTools Working Group                       [Page 157]
^L
          Appendix                         Network Management Tutorial


          It is worthwhile to develop a source/destination traffic
          matrix, including a breakdown of traffic between the local
          system and other internet sites.  Both volume and type of
          traffic should be logged, along with its evolution over
          time.  Of particular interest for systems with diskless
          workstations is memory swapping and other disk server
          access.  For all systems, broadcast traffic and routing
          traffic should be monitored.  Sudden increases in the vari-
          ance of delay or the volume of routing traffic may indicate
          thrashing or other soft failures.

          In monitoring a system, long-term averages are of little
          use.  Hourly averages are a better indicator of system use.
          Variance in utilization and delay should also be tracked.
          Sudden spikes in variance are tell-tale signs that a problem
          is looming or exists.  So, too, are trends of increased
          packet or line errors, broadcasts, routing traffic, or
          delay.

          3. Fault Detection and Isolation

          When a system fails, caution is in order.  A net manager
          should make an attempt to diagnose the cause of a system
          crash before rebooting.  In many cases, however, a quick
          diagnosis will not be possible.  For some high priority
          applications, restoring at least some level of service will
          have priority over fault repair or even complete fault diag-
          nosis.  This necessitates prior planning.  A net manager
          must know the vital applications at his site.  If applica-
          tions require it, he must also have a fall-back plan for
          bringing them online.  Meanwhile, repeated crashes or
          hardware failures are unambiguous signs of a problem that
          must be corrected.

          A network manager should prepare for fault diagnosis by
          becoming familiar with how diagnostic tools respond to net-
          work failure.  In times of relative peace, a net manager
          should occasionally unplug the network connection from an
          unused workstation and then "debug" the problem.

          When diagnosing a fault or anomaly, it is vital to proceed
          in an orderly manner, especially since network faults will
          usually generate spurious as well as accurate error mes-
          sages.  Remember to keep in mind that the network itself is
          failing.  Do not place too much trust in anything obtained
          remotely.  Furthermore, it is unlikely to be significant
          that remote information such as DNS names or NFS files can-
          not be obtained.



          IETF NOCTools Working Group                       [Page 158]
^L
          Appendix                         Network Management Tutorial


          Even spurious messages can be revealing, because they pro-
          vide clues to the problem.  From the data at hand, develop
          working hypotheses about probable causes of the problems you
          detect.  Direct your further data gathering efforts so that
          the information you get will either refute or support your
          hypotheses.

          An orderly approach to debugging is facilitated if it is
          guided by a model of network behavior.  The following por-
          tions of this section present such a model, along with a
          procedure for checking network connectivity.  The section
          concludes with  some hints for diagnosing a particularly
          tricky class of connectivity problem.

          3.1 A Network Model as a Diagnostic Framework

          The point of having a model of how things work is to have a
          basis for developing educated guesses about how things go
          wrong.  The problem of cascading faults -- faults generating
          other faults -- makes use of a conceptual model a virtual
          necessity.

          In general, only problems in a component's hardware or
          operating system will generate simultaneous faults in multi-
          ple protocol layers.  Otherwise, faults will propagate vert-
          ically (up the protocol stack) or horizontally (between
          peer-level communications components).  Applying a concep-
          tual model that includes the architectural relations of net-
          work components can help to order an otherwise senseless
          barrage of error messages and symptoms.

          The model does not have to be formal or complex to bring
          structure to debugging efforts.  A useful start is something
          as simple as the following:

               1.   Applications programs use transport services:
                    TCP/UDP.  Before using service, applications that
                    accept host names as parameters must translate the
                    names into IP addresses.  Translation may be based
                    on a static table lookup (/etc/hosts file in UNIX
                    hosts), the DNS, or yellow pages.  Nslookup and
                    DiG are tools for monitoring the activities of the
                    DNS.

               2.   Transport protocol implementations use IP ser-
                    vices.  The local IP module makes the initial
                    decision on forwarding.  An IP datagram is for-
                    warded directly to the destination host if the



          IETF NOCTools Working Group                       [Page 159]
^L
          Appendix                         Network Management Tutorial


                    destination is on the same network as the source.
                    Otherwise, the datagram is forwarded to a gateway
                    attached to the network.  On BSD hosts, the con-
                    tents of a host's routing table are visible by use
                    of the "netstat" command.*

               3.   IP implementations translate the IP address of a
                    datagram's next hop (either the destination host
                    or a gateway) to a local network address.  For
                    ethernets, the Address Resolution Protocol (ARP)
                    is commonly used for this translation.  On BSD
                    systems, an interface's IP address and other con-
                    figuration options can be viewed by use of the
                    "ifconfig" command, while the contents of a host's
                    ARP cache may be viewed by use of "arp" command.

               4.   IP implementations in hosts and gateways route
                    datagrams based on subnet and net identifiers.
                    Subnetting is a means of allocating and preserving
                    IP address space, and of insulating users from the
                    topological details of a multi-network campus.
                    Sites that use subnetting reserve portions of the
                    IP address's host identifier to indicate particu-
                    lar networks at their campus.  Subnetting is
                    highly system-dependent.  The details are a criti-
                    cal, though local, issue.  As for routing between
                    separate networks, a variety of gateway-to-gateway
                    protocols are used.  Traceroute is a useful tool
                    for investigating routing problems.  The tool,
                    "query," can be used to examine RIP routing
                    tables.

          A neophyte network manager should expand the above descrip-
          tion so that it accurately describes his particular system,
          _________________________
          * Initial forwarding may actually be complex and
          vulnerable to multiple points of failure.  For example,
          when sending an IP datagram, 4.3BSD hosts first look
          for a route to the particular host.  If none has been
          specified for the destination, then a search is made
          for a route to the network of the destination.  If this
          search also fails, then as a last resort, a search is
          made for a route to a "default" gateway.  Routes to
          hosts, networks, and the "default" gateway may be stat-
          ic, loaded at boot time and perhaps updated by operator
          commands.  Alternatively, they may be dynamic, loaded
          from redirects and routing protocol updates.




          IETF NOCTools Working Group                       [Page 160]
^L
          Appendix                         Network Management Tutorial


          and learn the tools and techniques for monitoring the opera-
          tions at each of the above stages.

          3.2 A Simple Procedure for Connectivity Check

          In this section, we describe a procedure for isolating a
          TCP/IP connectivity problem.** In this procedure, a series
          of tests methodically examine connectivity from a host,
          starting with nearby resources and working outward. The
          steps in our connectivity-testing procedure are:

          1.   As an initial sanity check, ping your own IP address
               and the loopback address.

          2.   Next, try to ping other IP hosts on the local subnet.
               Use numeric addresses when starting off, since this
               eliminates the name resolvers and host tables as poten-
               tial sources of problems.  The lack of an answer may
               indicate either that the destination host did not
               respond to ARP (if it is used on your LAN), or that a
               datagram was forwarded (and hence, the destination IP
               address was resolved to a local media address) but that
               no ICMP Echo Reply was received.  This could indicate a
               length-related problem, or misconfigured IP Security.

          3.   If an IP router (gateway) is in the system, ping both
               its near and far-side addresses.

          4.   Make sure that your local host recognizes the gateway
               as a relay.  (For BSD hosts, use netstat.)

          5.addresses
               Still using numeric IP addresses, try to ping hosts
               beyond the gateway.  If you get no response, run hop-
               check or traceroute, if available.  Note whether your
               packets even go to the gateway on their way to the des-
               tination.  If not, examine the methods used to instruct
               your host to use this gateway to reach the specified
               destination net (e.g., is the default route in place?
               Alternatively, are you successfully wire-tapping the
               IGP messages broadcast on the net you are attached to?)

          _________________________
          ** Thanks to James VanBokkelen, president of FTP
          Software, for sharing with us a portion of a PC/TCP
          support document, the basis for the above connectivity
          procedure.




          IETF NOCTools Working Group                       [Page 161]
^L
          Appendix                         Network Management Tutorial


               If traceroute is not available, ping, netstat, arp, and
               a knowledge of the IP addresses of all the gateway's
               interfaces can be used to isolate the cause of the
               problem.  Use netstat to determine your next hop to the
               destination.  Ping that IP address to ensure the router
               is up.  Next, ping the router interface on the far sub-
               net.  If the router returns "network unreachable" or
               other errors, investigate the router's routing tables
               and interface status.  If the pings succeed, ping the
               close interface of the succeeding next hop gateway, and
               so on.  Remember the routing along the outbound and
               return paths may be different.

          6.   Once ping is working with numeric addresses, use ping
               to try to reach a few remote hosts by name.  If ping
               fails when host names are used, check the operation of
               the local name-mapping system (i.e., with nslookup or
               DiG).  If you want to use "shorthand" forms ("myhost"
               instead of "myhost.mydomain.com"), be sure that the
               alias tables are correctly configured.

          7.   Once basic reachability has been established with ping,
               try some TCP-based applications: FTP and TELNET are
               supported on almost all IP hosts, but FINGER is a
               simpler protocol.  The Berkeley-specific protocols
               (RSH, RCP, REXEC and LPR) require extra configuration
               on the server host before they can work, and so are
               poor choices for connectivity testing.

          If problems arise in steps 2-7 above, rerunning the tests
          while executing a line monitor (e.g., etherfind, netwatch,
          or tcpdump) can help to pinpoint the problem.

          The above procedure is sound and useful, especially if lit-
          tle is known about the cause of the connectivity problem.
          It is not, however, guaranteed to be the shortest path to
          diagnosis.  In some cases, a binary search on the problem
          might be more effective (i.e., try a test "in the middle,"
          in a spot where the failure modes are well defined).  In
          other cases, available information might so strongly suggest
          a particular failure that immediately testing for it is in
          order.  This last "approach," which might be called "hunting
          and pecking," should be used with caution: chasing one will
          o' the wisp after another can waste much time and effort.

          Note that line problems are still among the most common
          causes of connectivity loss.  Problems in transmission
          across local media are outside the scope of this tutorial.



          IETF NOCTools Working Group                       [Page 162]
^L
          Appendix                         Network Management Tutorial


          But, if a host or workstation loses or cannot establish con-
          nectivity, check its physical connection.

          3.3 Limited Connectivity

          An interesting class of problems can result in a particu-
          larly mysterious failure: TELNET or other low-volume TCP
          connections work, but large file transfers fail.  FTP
          transfers may start, but then hang.  There are several pos-
          sible culprits in this problem.  The most likely suspects
          are IP implementations that cannot fragment or reassemble
          datagrams, and TCP implementations that do not perform
          dynamic window sizing (a.k.a. Van Jacobson's "Slow Start"
          algorithm).  Another possibility is mixing incompatible
          frame formats on an ethernet.

          Even today, some IP implementations in the Internet cannot
          correctly handle fragmentation or reassembly.  They will
          work fine for small packets, but drop all large packets.

          The problem can also be caused by buffer exhaustion at gate-
          ways that connect interfaces of widely differing bandwidth.
          Datagrams from a TCP connection that traverses a bottleneck
          will experience queue delays, and will be dropped if buffer
          resources are depleted.  The congestion can be made worse if
          the TCP implementation at the traffic source does not use
          the recommended algorithms for computing retransmission
          times, since spuriously retransmitted datagrams will only
          add to the congestion.* Fragmentation, even if correctly
          implemented, will compound this problem, since processing
          delays and congestion will be increased at the bottleneck.

          Serial Line Internet Protocol (SLIP) links are especially
          vulnerable to this and other congestion problems.  SLIP
          lines are typically an order of magnitude slower than other
          gateway interfaces.  Also, the SLIP lines are at times con-
          figured with MTUs (Maximum Transfer Unit, the maximum length
          of an IP datagram for a particular subnet) as small as 256
          _________________________
          * To avoid this problem, TCP implementations on the In-
          ternet must use "exponential backoff" between succes-
          sive retransmissions, Karn's algorithm for filtering
          samples used to estimate round-trip delay between TCP
          peers, and Jacobson's algorithm for incorporating vari-
          ance into the "retransmission time-out" computation for
          TCP segments.  See Section 4.2.3.1 of RFC 1122, "Re-
          quirements for Internet Hosts -- Communication Layers."




          IETF NOCTools Working Group                       [Page 163]
^L
          Appendix                         Network Management Tutorial


          bytes, which virtually guarantees fragmentation.

          To alleviate this problem, TCP implementations behind slow
          lines should advertise small windows.  Also, if possible,
          SLIP lines should be configured with an MTU no less than 576
          bytes.  The tradeoff to weigh is whether interactive traffic
          will be penalized too severly by transmission delays of
          lengthy datagrams from concurrent file transfers.

          Misuse of ethernet trailers can also cause the problem of
          hanging file transfers.  "Trailers" refers to an ethernet
          frame format optionally employed by BSD systems to minimize
          buffer copying by system software.  BSD systems with ether-
          net interfaces can be configured to send large frames so
          that their address and control data are at the end of a
          frame (hence, a "trailer" instead of a "header").  After a
          memory page is allocated and loaded with a received ethernet
          frame, the ethernet data will begin at the start of the
          memory page boundary.  Hence, the ethernet control informa-
          tion can be logically stripped from the end merely by
          adjusting the page's length field.  By manipulating virtual
          memory mapping, this same page (sans ethernet control infor-
          mation), can then be passed to the local IP module without
          additional allocation and loading of memory.  The disadvan-
          tage in using trailers is that it is non-standard.  Many
          implementations cannot parse trailers.

          The hanging FTP problem will appear if a gateway is not con-
          figured to recognize trailers, but a host or gateway immedi-
          ately "upstream" on an ethernet uses them.  Short datagrams
          will not be formatted with trailers, and so will be pro-
          cessed correctly.  When the bulk data transfer starts, how-
          ever, full-sized frames will be sent, and will use the
          trailer format.  To the gateway that receives them, they
          appear simply as misformatted frames, and are quietly
          dropped.  The solution, obviously, is to insure that all
          hosts and gateways on an ethernet are consistent in their
          use of trailers.  Note that RFC 1122, "Internet Host
          Requirements," places very strict restrictions on the use of
          trailers.

          4. Performance Testing

          Performance management encompasses two rather different
          activities.  One is passive system monitoring to detect
          problems and determine operational baselines.  The goal is
          to measure system and component utilization and so locate
          bottlenecks, since bottlenecks should receive the focus of



          IETF NOCTools Working Group                       [Page 164]
^L
          Appendix                         Network Management Tutorial


          performance tuning efforts.  Also, performance data is usu-
          ally required by upper level management to justify the costs
          of communications systems.  This is essentially identical to
          system monitoring, and is addressed at greater length in
          Section 2, above.

          Another aspect of performance management is active perfor-
          mance testing and capacity planning.  Some work in this area
          can be based on analysis.  For example, a rough estimate of
          gateway capacity can be deduced from a simple model given by
          Charles Hedrick in his "Introduction to Administration of an
          Internet-based Local Network," which is

               per-packet processing time =
                         switching time +
                                   (packet size) * (transmission bps).

          Another guideline for capacity planning is that in order to
          avoid excessive queuing delays, a system should be sized at
          about double its expected load.  In other words, system
          capacity should be so high that utilization is no greater
          than 50%.

          Although there are more sophisticated analytic models of
          communications systems than those above, their added com-
          plexity does not usually gain a corresponding accuracy.
          Most analytic models of communications nets require assump-
          tions about traffic load distributions and service rates
          that are not merely problematic, but are patently false.
          These errors tend to result in underestimating queuing
          delays.  Hence, it is often necessary to actually load and
          measure the performance of a real communications system if
          one is to get accurate performance predictions.  Obviously,
          this type of testing is performed on isolated systems or
          during off hours.  The results can be used to evaluate
          parameter settings or predict performance during normal
          operations.

          Simulations can be used to supplement the testing of real
          systems.  To be believable, however, simulations require
          validation, which, in turn, requires measurements from a
          real system.  Whether testing or simulating a system's per-
          formance, actual traffic traces should be incorporated as
          input to traffic generators.  The performance of a communi-
          cations system will be greatly influenced by its load
          characteristics (burstiness, volume, etc.), which are them-
          selves highly dependent on the applications that are run.




          IETF NOCTools Working Group                       [Page 165]
^L
          Appendix                         Network Management Tutorial


          When tuning a net, in addition to the usual configuration
          parameters, consider the impact of the location of gateways
          and print and file servers.  A few rules of thumb can guide
          the location of shared system resources.  First, there is
          the principle of locality: a system will perform better if
          most traffic is between nearby destinations.  The second
          rule is to avoid creating bottlenecks.  For example, multi-
          ple diskservers may be called for to support a large number
          of workstations.  Furthermore, to avoid LAN and diskserver
          congestion, workstations should be configured with enough
          memory to avoid frequent swapping.

          As a final note on performance management, proceed cau-
          tiously if your ethernet interface allows you to customize
          its collision recovery algorithm.  This is almost always a
          bad idea.  The best that it can accomplish is to give a few
          favored hosts a disproportionate share of the ethernet
          bandwidth, perhaps at the cost of a reduction in total sys-
          tem throughput.  Worse, it is possible that differing colli-
          sion recovery algorithms may exhibit a self-synchronizing
          behavior, so that excess collisions are generated.

          5. Configuration Management

          Configuration management is the setting, collecting, and
          storing of the state and parameters of network resources.
          It overlaps all other network management functions.  Hence,
          some aspects of configuration management have already been
          addressed (e.g., tuning for performance).  In this section,
          we will focus on configuration management activities needed
          to "hook up" a net or campus to a larger internet.  We will
          not, of course, include specific details on installing or
          maintaining internetted communications systems.  We will,
          however, skim over some of the TCP/IP configuration
          highlights.

          Configuration management includes "name management" -- the
          control and allocation of system names and addresses, and
          the translation between names and addresses.  Name-to-
          address translation is performed by "name servers." We con-
          clude this section with a few strictures on the simultaneous
          use of two automated name-servers, the Domain Name System
          (DNS), and Yellow Pages (YP).

          5.1 Required Host Configuration Data for TCP/IP internets

          In a TCP/IP internet, each host needs several items of
          information for internet communications.  Some will be



          IETF NOCTools Working Group                       [Page 166]
^L
          Appendix                         Network Management Tutorial


          host-specific, while other information will be common for
          all hosts on a subnet.  In a soon to be published RFC docu-
          ment,* R. Droms identifies the following configuration data
          required by internet hosts:

               o+    An IP address, a host specific value that can be
                    hard-coded or obtained via BOOTP, the Reverse
                    Address Resolution Protocol (RARP) or Dynamic RARP
                    (DRARP).

               o+    Subnet properties, such as the subnet mask and the
                    Maximum Transmission Unit (MTU); obviously, these
                    values are not host-specific.

               o+    Addresses of "entry" gateways to the internet;
                    addresses of default gateways are usually hard-
                    coded; though the ICMP "redirect" message can be
                    used to refine a host's routing tables, there is
                    currently no dynamic TCP/IP mechanism or protocol
                    for a host to locate a gateway; an IETF working
                    group is busy on this problem.

               o+    For hosts in internets using the Domain Name Sys-
                    tem (DNS) for name-to-address translation, the
                    location of a local DNS server is needed; this
                    information is not host-specific, and usually
                    hard-coded;

               o+    Host name (domain name, for hosts using DNS);
                    obviously host-specific; either hard-coded or
                    obtained in a boot procedure.

               o+    For diskless hosts, various boot services.  BOOTP
                    is the standard Internet protocol for downloading
                    boot configuration information.  The Trivial File
                    Transfer Protocol (TFTP) is typically used for
                    downloading boot images.  Sun computers use the
                    "bootparams" RPC mechanism for downloading initial
                    configuration data to a host.

          There are ongoing developments, most notably the work of the
          Dynamic Host Configuration Working Group of the IETF, to
          support dynamic, automatic gathering of the above data.  In
          the meantime, most systems will rely on hand-crafted confi-
          guration files.
          _________________________
          * Draft "Dynamic Configuration of Internet Hosts."




          IETF NOCTools Working Group                       [Page 167]
^L
          Appendix                         Network Management Tutorial


          5.3 Connecting to THE Internet

          The original TCP/IP Internet (spelled with an upper-case
          "I") is still active, and still growing.  An interesting
          aspect of the Internet is that it spans many independently
          administered systems.

          Connection to the Internet requires: a registered network
          number, for use in IP addresses; a registered autonomous
          system number (ASN), for use in internet routing; and, a
          registered domain name.  Fielding a primary and backup DNS
          server is a condition for registering a domain name.

          The Defense Data Network (DDN) Network Information Center
          (NIC) is responsible for registering network numbers, auto-
          nomous system numbers, and domain names.  Regional nets will
          have their own policies and requirements for Internet con-
          nections, but all use the NIC for this registration service.
          Contact the NIC for further information, at:

               DDN Network Information Center
               SRI International, Room EJ291
               333 Ravenswood Avenue
               Menlo Park, CA  94025

               Email:   HOSTMASTER@NIC.DDN.MIL
               Phone:   1-415-859-3695
                        1-800-235-3155 (toll-free hotline)

          5.4 YP and DNS: Dueling name servers.

          The Domain Name System (DNS) provides name service: it
          translates host names into IP addresses (this mapping is
          also called "resolution").  Two widespread DNS implementa-
          tions are "bind" and "named."  The Sun Yellow Pages (YP)
          system can be configured to provide an identical service, by
          providing remote, keyed access to the "hosts.byname" map.
          Unfortunately, if both DNS and the YP hosts.byname map are
          installed, they can interact in disruptive ways.

          The problem has been noted in systems in which DNS is used
          as a fallback, to resolve hostnames that YP cannot.  If DNS
          is slow in responding, the timeout in program ypserv may
          expire, which triggers a repeated request.  This can result
          in disaster if DNS was initially slow because of congestion:
          the slower things get, the more requests are generated,
          which slows things even more.  A symptom of this problem is
          that failures by the DNS server or network will trigger



          IETF NOCTools Working Group                       [Page 168]
^L
          Appendix                         Network Management Tutorial


          numerous requests to DNS.

          Reportedly, the bug in YP that results in the avalanche of
          DNS requests has been repaired in SunOS 4.1.  The problem,
          however, is more fundamental than an implementation error.
          The YP map hosts.byname and the DNS contain the same class
          of information.  One can get an answer to the same query
          from each system.  These answers may well be different:
          there is not a mechanism to maintain consistency between the
          systems.  More critical, however, is the lack of a mechanism
          or procedure to establish which system is authoritative.
          Hence, running the DNS and YP name services in parallel is
          pointless.  If the systems stay consistent, then only one is
          needed.  If they differ, there is no way to choose which is
          correct.

          The YP hosts.byname service and DNS are comparable, but
          incompatible.  If possible, a site should not run both ser-
          vices.  Because of Internet policy, sites with Internet con-
          nections MUST use the DNS.  If YP is also used, then it
          should be configured with YP-to-DNS disabled.

          Hacking a system so that it uses DNS rather than the YP
          hosts.byname map is not trivial, and should not be attempted
          by novices.  The approach is to rebuild the shared C link-
          library, so that system calls to gethostbyname() and
          gethostbyaddr() will use DNS rather than YP.  To complete
          the change, programs that do not dynamically link the shared
          C library (rcp, arp, etc.)  must also be rebuilt.

          Modified shared C libraries for Sun 3s and Sun 4s are avail-
          able via anonymous FTP from host uunet.uu.net, in the sun-
          fixes directory.  Note that use of DNS routines rather than
          YP for general name resolution is not a supported SunOS
          feature at this time.

          6. Internet Security

          The guidelines and advice in this section pertain to enhanc-
          ing the protection of data that are merely "sensitive."  By
          themselves, these measures are insufficient for protecting
          "classified" data.  Implementing the policies required to
          protect classified data is subject to stringent, formal
          review procedures, and is regulated by agencies such as the
          Defense Investigative Service (DIS) and the National Secu-
          rity Agency (NSA).

          A network manager must realize that he is responsible for



          IETF NOCTools Working Group                       [Page 169]
^L
          Appendix                         Network Management Tutorial


          protecting his system and its users.  Furthermore, though
          the Internet may appear to be a grand example of a coopera-
          tive joint enterprise, recent incidents have made it clear
          that not all Internet denizens are benign.

          A network manager should be aware that the network services
          he runs have a large impact on the security risks to which
          his system is exposed.  The prudent network manager will be
          very careful as to what services his site provides to the
          rest of the Internet, and what access restrictions are
          enforced.  For example, the protocol "finger" may provide
          more information about a user than should be given to the
          world at large.  Worse, most implementations of the protocol
          TFTP give access to all world-readable files.

          This section highlights several basic security considera-
          tions for Internet sites.  It then lists several sources of
          information and advice on improving the security of systems
          connected to the Internet.

          6.1 Basic Internet Security

          Two major Internet security threats are denial of service
          and unauthorized access.

          Denial of service threats often take the form of protocol
          spoofers or other malicious traffic generators.  These prob-
          lems can be detected through system monitoring logs.  If an
          attack is suspected, immediately contact your regional net
          office (e.g., SURANET, MILNET).  In addition, DDN users
          should contact SCC, while other Internet users should con-
          tact CERT (see below).  A cogent description of your
          system's symptoms will be needed.

          At your own site, be prepared to isolate the problems (e.g.,
          by limiting disk space available to the message queue of a
          mail system under attack).  As a last resort, coping with an
          attack may require taking down an Internet connection.  It
          is better, however, not to be too quick to quarantine your
          site, since information for coping with the attack may come
          via the Internet.

          Unauthorized access is a potentially more ominous security
          threat.  The main avenues are attacks against passwords and
          attacks against privileged system processes.

          An appallingly common means of gaining entry to systems is
          by use of the initial passwords to root, sysdiag, and other



          IETF NOCTools Working Group                       [Page 170]
^L
          Appendix                         Network Management Tutorial


          management accounts that systems are shipped with.  Only
          slightly less vulnerable are common or trivial passwords,
          since these are readily subverted by dictionary attacks.*
          Obvious steps can reduce the risk of password attacks: pass-
          words should be short-lived, at least eight characters long,
          with a mix of upper and lower case, and preferably random.
          The distasteful aspect of memorizing a random string can be
          alleviated if the password is pronounceable.

          Improving passwords does not remove all risks.  Passwords
          transmitted over an ethernet are visible to all attached
          systems.  Furthermore, gateways have the potential to inter-
          cept passwords used by any FTP or TELNET connections that
          traverse them.  It is a bad idea for the root account to be
          accessed by FTP or TELNET if the connections must cross
          untrusted elements.

          Attacks against system processes are another avenue of unau-
          thorized access.  The principle is that by subverting a sys-
          tem process, the attacker can then gain its access
          privileges.

          One approach to reducing this risk is to make system pro-
          grams harder to subvert.  For example, the widespread attack
          in November 1988 by a self-replicating computer program
          ("worm," analogous to a tapeworm) subverted the "fingerd"
          process, by loading an intrusive bootstrap program (known
          variously as a "grappling hook" or "vector" program), and
          then corrupting the stack space so that a subroutine's
          return address was overwritten with the address of the
          bootstrap program.** The security hole in fingerd consisted
          of an input routine that did not have a length check.  Secu-
          rity fixes to "fingerd" include the use of a revised input
          routine.

          A more general protection is to apply the principle of
          "least privilege."  Where possible, system routines should
          run under separate user IDs, and should have no more
          privilege than is necessary for them to function.
          _________________________
          * Exotic fantasy creatures and women's names are well
          represented in most password dictionaries.
          ** An early account of the Internet Worm incident of
          November 1988 is given by Eugene Spafford in the Janu-
          ary 89 issue of "Computer Communications Review."
          Several other articles on the worm incident are in the
          June 89 issue of the "Communications of the ACM."




          IETF NOCTools Working Group                       [Page 171]
^L
          Appendix                         Network Management Tutorial


          To further protect against attacks on system processes, sys-
          tem managers should regularly check their system programs to
          ensure that they have not been tampered with or modified in
          any way.  Checksums should be used for this purpose.  Using
          the operating system to check a file's last date of modifi-
          cation is insufficient, since the date itself can be
          compromised.

          Finally, to avoid the unauthorized replacement of system
          code, care should be exercised in assigning protection to
          its directory paths.

          Some system programs actually have "trap doors" that facili-
          tate subversion.  A trap door is the epitome of an undocu-
          mented feature: it is a hidden capability of a system pro-
          gram that allows a knowledgeable person to gain access to a
          system.  The Internet Worm exploited what was essentially a
          trap door in the BSD sendmail program.

          Ensuring against trap doors in software as complex as send-
          mail may be infeasible.  In an ideal world, the BSD sendmail
          program would be replaced by an entire mail subsystem (i.e.,
          perhaps including mail user agents, mail transfer agents,
          and text preparation and filing programs).  Any site using
          sendmail should at least obtain the less vulnerable,
          toughened distribution from ucbarpa.berkeley.edu, in file
          ~ftp/4.3/sendmail.tar.Z.  Sites running SunOS should note
          that the 4.0.3 release closed the security holes exploited
          by the Internet Worm.  Fixes for a more obscure security
          hole in SunOS are available from host uunet.uu.net in
          ~ftp/sun-fixes; these improvements have been incorporated in
          SunOS 4.1.

          Sendmail has problems other than size and complexity.  Its
          use of root privileges, its approach to alias expansion, and
          several other design characteristics present potential ave-
          nues of attack.  For UNIX sites, an alternative mail server
          to consider is MMDF, which is now at version 2.  MMDF is
          distributed as part of the SCO UNIX distribution, and is
          also available in the user contributed portion of 4.3BSD.
          Though free, MMDF is licensed, and resale is restricted.
          Sites running MMDF should be on the mmdf email list;
          requests to join this list should be sent to:
               mmdf2-request@relay.cs.net.

          Programs that masquerade as legitimate system code but which
          contain trap doors or other aides to unauthorized access are
          known as trojan horses.  Computer "viruses," intrusive



          IETF NOCTools Working Group                       [Page 172]
^L
          Appendix                         Network Management Tutorial


          software that infects seemingly innocent programs and pro-
          pagates when the infected programs are executed or copied,
          are a special case of trojan horse programs.*

          To guard against trojan horse attacks, be wary of programs
          downloaded from remote sources.  At minimum, do not download
          executables from any but the most trusted sources.  Also, as
          noted above, to avoid proliferation of "infected" software,
          checksums should be computed, recorded, and periodically
          verified.

          6.2 Security Information Clearing-Houses

          The Internet community can get security assistance from the
          Computer Emergency Response Team (CERT), established by
          DARPA in November 1988.  The Coordination Center for the
          CERT (CERT/CC) is located at the Software Engineering Insti-
          tute at Carnegie Mellon University.  The CERT is intended to
          respond to computer security threats such as the November
          '88 worm attack that invaded many defense and research com-
          puters.  Consult RFC 1135 (Reynolds, J., "The Helminthiasis
          of the Internet", USC/ISI, December 1989), for further
          information.

          CERT assists Internet sites in response to security attacks
          or other emergency situations.  It can immediately tap
          experts to diagnose and solve the problems, as well as
          establish and maintain communications with the affected com-
          puter users and with government authorities as appropriate.
          Specific responses will be taken in accordance with the
          nature of the problem and the magnitude of the threat.

          CERT is also an information clearing-house for the identifi-
          cation and repair of security vulnerabilities, informal
          assessments of existing systems in the research community,
          improvement to emergency response capability, and both ven-
          dor and user security awareness.  This security information
          is distributed by periodic bulletins, and is posted to the
          USENET news group comp.security.announce.  In addition, the
          security advisories issued by CERT, as well as other useful
          security-related information, are available via anonymous
          FTP from cert.sei.cmu.edu.

          For immediate response to attacks or incidents, CERT mans a
          _________________________
          * Virus attacks have been seen against PCs, but as yet
          have rarely been directed agains UNIX systems.




          IETF NOCTools Working Group                       [Page 173]
^L
          Appendix                         Network Management Tutorial


          24-hour hotline at (412) 268-7090.  To subscribe to CERT's
          security announcement bulletin, or for further information,
          contact:

               CERT
               Software Engineering Institute
               Carnegie Mellon University
               Pittsburgh, PA  15213-3890

               (412) 268-7080
               cert@cert.sei.cmu.edu.

          For DDN users, the Security Coordination Center (SCC) serves
          a function similar to CERT.  The SCC is the DDN's clearing-
          house for host/user security problems and fixes, and works
          with the DDN Network Security Officer.  The SCC also distri-
          butes the DDN Security Bulletin, which communicates informa-
          tion on network and host security exposures, fixes, and con-
          cerns to security and management personnel at DDN facili-
          ties.  It is available online, via kermit or anonymous FTP,
          from nic.ddn.mil, in SCC:DDN-SECURITY-yy-nn.TXT (where "yy"
          is the year and "nn" is the bulletin number).  The SCC pro-
          vides immediate assistance with DDN-related host security
          problems; call (800) 235-3155 (6:00 a.m. to 5:00 p.m.
          Pacific Time) or send e-Mail to SCC@NIC.DDN.MIL.  For 24
          hour coverage, call the MILNET Trouble Desk (800) 451-7413
          or AUTOVON 231-1713.

          The CERT/CC and the SCC communicate on a regular basis and
          support each other when problems occur.  These two organiza-
          tions are examples of the incident response centers that are
          forming; each serving their own constituency or focusing on
          a particular area of technology.

          Other network groups that discuss security issues are:
          comp.protocols.tcp-ip, comp.virus (mostly PC-related, but
          occasionally covers Internet topics), misc.security, and the
          BITNET Listserv list called VIRUS-L.

          7. Internet Information

          There are many available references on the TCP/IP protocol
          suite, the internet architecture, and the DDN Internet.  A
          soon to be published FYI RFC document, "Where to Start: A
          Bibliography of General Internetworking Information." pro-
          vides a bibliography of online and hard copy documents,
          reference materials, and multimedia training tools that
          address general networking information and "how to use the



          IETF NOCTools Working Group                       [Page 174]
^L
          Appendix                         Network Management Tutorial


          Internet."  It presents a representative collection of
          materials that will help the reader become familiar with the
          concepts of internetworking.  Inquires on the current status
          of this document can be sent to user-doc@nnsc.nsf.net or by
          postal mail to:

               Corporation for National Research Initiatives
               1895 Preston White, Suite 100
               Reston, VA  22091
               Attn: IAB Secretariat.

          Two texts on networking are especially noteworthy.  _I_n_t_e_r_-
          _n_e_t_w_o_r_k_i_n_g _W_i_t_h _T_C_P/_I_P, by Douglas Comer, is an informative
          description of the TCP/IP protocol suite and its underlying
          architecture.  The _U_N_I_X _S_y_s_t_e_m _A_d_m_i_n_i_s_t_r_a_t_i_o_n _H_a_n_d_b_o_o_k, by
          Nemeth, Snyder, and Seebass, is a "must have" for system
          administrators who are responsible for UNIX hosts.  In addi-
          tion to covering UNIX, it provides a wealth of tutorial
          material on networking, the Internet, and network manage-
          ment.

          A great deal of information on the Internet is available
          online.  An automated, online reference service is available
          from CSNET.  To obtain a bibliography of their online offer-
          ings, send the email message

               request: info
               topic: help
               request: end

          to info-server@sh.cs.net.

          The DDN NIC also offers automated access to many NIC docu-
          ments, online files, and WHOIS information via electronic
          mail.  To use the service, send an email message with your
          request specified in the SUBJECT field of the message.  For
          a sampling of the type of offerings available through this
          service, send the following message

               To: SERVICE@NIC.DDN.MIL
               Subject: help
               Msg: <none>


          The DDN Protocol Implementations and Vendors Guide, pub-
          lished by the DDN Network Information Center (DDN NIC),* is
          _________________________
          * Products mentioned in the guide are not specifically



          IETF NOCTools Working Group                       [Page 175]
^L
          Appendix                         Network Management Tutorial


          an online reference to products and implementations associ-
          ated with the DoD Defense Data Network (DDN) group of com-
          munication protocols, with emphasis on TCP/IP and OSI proto-
          cols.  It contains information on protocol policy and
          evaluation procedures, a discussion of software and hardware
          implementations, and analysis tools with a focus on protocol
          and network analyzers.  To obtain the guide, invoke FTP at
          your local host and connect to host NIC.DDN.MIL (internet
          address 26.0.0.73 or 10.0.0.51).  Log in using username
          'anonymous' with password 'guest' and get the file
          NETINFO:VENDORS-GUIDE.DOC.

          The DDN Protocol Guide is also available in hardcopy form.
          To obtain a hardcopy version of the guide, contact the DDN
          Network Information Center:

               By U.S. mail:
                       SRI International
                       DDN Network Information Center
                       333 Ravenswood Avenue, Room EJ291
                       Menlo Park, CA 94025

               By e-mail:
                       NIC@NIC.DDN.MIL

               By phone:
                       1-415-859-3695
                       1-800-235-3155 (toll-free hotline)

          For further information about the guide, or for information
          on how to list a product in a subsequent edition of the
          guide, contact the DDN NIC.

          There are many additional online sources on Internet Manage-
          ment.  RFC 1118, "A Hitchhiker's Guide to the Internet," by
          Ed Krol, is a useful introduction to the Internet routing
          algorithms.  For more of the nitty-gritty on laying out and
          configuring a campus net, see Charles Hedrick's "Introduc-
          tion to Administration of an Internet-based Local Network,"
          available via anonymous FTP from cs.rutgers.edu (sometimes
          listed in host tables as aramis.rutgers.edu), in subdirec-
          tory runet, file tcp-ip-admin.  Finally, anyone responsible
          for systems connected to the Internet must be thoroughly
          versed in the Host Requirements RFCs (RFC 1122 and RFC 1123)
          _________________________
          endorsed or recommended by the Defense Communications
          Agency (DCA).




          IETF NOCTools Working Group                       [Page 176]
^L
          Appendix                         Network Management Tutorial


          and "Requirements for Internet Gateways," RFC 1009.

          8. The Final Words on Internet Management

          Keep smiling, no matter how bad things may seem.  You are
          the expert.  They need you.

          9. Security Considerations

          Security issues are discussed in Section 6.

          10. Author's Address

          Robert H. Stine
          SPARTA, Inc.
          7926 Jones Branch Drive
          Suite 1070
          McLean, VA 22102

          EMail: STINE@SPARTA.COM































          IETF NOCTools Working Group                       [Page 177]
^L