Internet RFC/STD/FYI/BCP Archives
Alternate Formats: rfc1147.txt | rfc1147.ps | rfc1147.pdf
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
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.
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.
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.
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.
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:
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.
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.
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
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
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
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
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
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
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
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
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
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
X
Dual Manager
map
snmpxbar
snmpxconn
snmpxmon
snmpxperf
snmpxperfmon
snmpxrtmetric
WIN/MGT Station
XNETMON (II)
xnetperfmon
xup
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.
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.
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.
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
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).
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.
AVAILABILITY
A commercial product available from:
C.D., Ltd.
P.O. Box 58363
Seattle, WA 98138
(206) 243-8700
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
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.
AVAILABILITY
Commercial product of:
Wellfleet Communications, Inc.
12 DeAngelo Drive
Bedford, MA 01730-2204
(617) 275-2400
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.
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.
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)
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.
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.
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)
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.
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
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.
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.
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
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.
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
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.
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
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.
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.
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."
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)
[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
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.
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.
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.
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
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.
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
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
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).
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.
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.
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.
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)
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)
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.
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
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.
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.
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
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
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.
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)
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.
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.
SOFTWARE REQUIRED
4.0BSD UNIX or greater, or related OS.
AVAILABILITY
Copyrighted, commercially available from
Network Integrators,
(408) 927-0412.
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.
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).
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.
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.
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
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.
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.
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