RFC 1470
FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices
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
internals of SPIMS, see:
Nordmark & Gunningberg, "SPIMS: A Tool for Protocol
Implementation Performance Measurements" Proc. of 13:th
Conf. on Local Computer Networks, Minneapolis 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 AND CONTACT POINT FOR INFORMATION ABOUT THIS TOOL
SPIMS is not in the public domain and the software is
covered by licenses. Use of the SPIMS software
represents acceptance of the terms and conditions of
the licenses.
The licenses are enclosed in the distribution package.
Licenses and SPIMS cover letter can also be obtained
via an Internet FTP connection without getting the whole
software. The retrieval procedure is identical to the
below university distribution via FTP. The file to
retrieve is pub/spims-dist/licenses.tar.Z
There are two different distribution classes depending on
requesting organization:
1. Universities and non-profit organizations.
To these 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
pub/spims-dist/dist910304.tar.Z
(this is a .6MB compressed 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 handling fee of US$150.00 will be
charged. Submit a bank check with the request.
Do not send tapes or envelopes.
2. Commercial organizations.
These organizations can chose between a license for
commercial use, or a license for internal research
only and no commercial use whatsoever.
For internal research use only:
The SPIMS source code is distributed for a one
time fee of US$500.00. Organizations
interested in the research prototype need to
contact us via e-mail and briefly motivate why
they qualify (non-commercial use) for the
research prototype.
They will thereafter get a permission to
obtain a copy from the same distribution
source as for universities.
Commercial use:
A commercial version of SPIMS will eventually
be distributed and supported by a commercial
partner. nIn the meantime we will distribute
the research prototype (source code) to
interested organizations without any guaranty
or support. Contact SICS for further
information.
For more information about the research prototype
distribution and about a commercial license, 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
CONTACT POINT FOR CHANGES TO THIS CATALOG ENTRY
Bengt Ahlgren
Swedish Institute of Computer Science
Box 1263
S-164 28 KISTA, SWEDEN
Email: bengta@sics.se
Tel: +46 8 752 1562 (direct)
or +46 8 752 1500
Fax: +46 8 751 7230
Internet Tool Catalog SPRAY_SUN
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.
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. TCPware for VMS - currently interprets headers
for IP, TCP, UDP, and ICMP only.
HARDWARE REQUIRED
Any Ultrix system (VAX or DEC RISC hardware)
SOFTWARE REQUIRED
Ultrix release 4.0 or later. For Ultrix 4.1, may
require the patched "if_ln.o" kernel module, available
from Digital's Customer Support Center.
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 and TCPware for VMS from
Process Software Corporation.
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).
AVAILABILITY
Free, although a 4.3BSD license is required. Contact
Olafur Gudmundsson (ogud@cs.umd.edu).
Internet Tool Catalog TOKENVIEW_PROTEON
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
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.
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.
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.
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.
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.
Internet Tool Catalog UNISYS-PARAMAX
NAME
Paramax Network Security Server
KEYWORDS
alarm, control, manager, security, status;
ethernet, FDDI, IP; X; UNIX.
ABSTRACT
The Paramax Network Security Server (NSS) is a
security officer's tool for centralized security
management of TCP/IP-based networks. The NSS provides
capability for collection, on-line storage,
maintenance, and correlation of audit data from hosts,
workstations, servers, and network devices. Through
the X window based user interface, a security officer
can review and analyze this audit data at the NSS,
select and request filtered portions of host audit
data, and receive and analyze security alerts from
across the network. The NSS supports centralized
access control of network resources through its
capability to create and update user and host access
permissions data. The user access permissions data
identifies network addresses that each user is
permitted to access. The host access permissions data
identifies network addresses between which
communication is permitted. The NSS supports
centralized management of user authentication data
(user IDs and passwords) and other user data for use
by hosts, workstations, and servers in the network.
It generates pseudo-random pronounceable passwords for
selection and assignment to users by the security officer.
The NSS deadman timer locks the NSS screen or logs the
security officer off the NSS after periods of
inactivity. A biometric authentication device is
optional for rigorous fingerprint authentication of
users at the NSS, and logins to the NSS itself are
permitted only at the console. The NSS currently
provides centralized security management for a System High
Network. It is being upgraded for a Compartmented Mode
environment.
MECHANISM
The NSS uses the Audit Information Transfer Protocol
(AITP) for the transfer of security alerts and audit
data. AITP is NOT proprietary, and the specification
is available from the address listed below. Access to
the NSS audit database is provided via the Structured
Query Language (SQL).
CAVEATS
None.
BUGS
None known.
LIMITATIONS
None reported.
HARDWARE REQUIRED
Hardware required is a Sun 4 (SPARCStation) with a color
monitor, at least 600 MB disk, and 150 MB 1/4"
cartridge tape drive.
SOFTWARE REQUIRED
SunOS Version 4.1.1 running the Sun OpenWindows X
windowing environment and the SYBASE Relational Data
Base Management System.
AVAILABILITY AND CONTACT POINT FOR INFORMATION ABOUT THIS TOOL
Commercially available from:
Paramax Systems Corporation
5151 Camino Ruiz
Camarillo, California 93011-6004
805-987-6811
Peter Vazzana
CONTACT POINT FOR CHANGES TO THIS CATALOG ENTRY
Paramax Systems Corporation
5151 Camino Ruiz
Camarillo, California 93011-6004
805-987-6811
Nina Lewis <nina@cam.paramax.com>
Internet Tool Catalog WOLLONGONG-MANAGER
NAME
Management Station, Release 3.0
KEYWORDS
manager; ; snmp, x; sun, dec, dos;.
ABSTRACT
Management Station is a network management software
product that supports SNMP. Release 3.0 implements a
distributed network management architecture that helps
solve the scalability and reliability limitations of
using a single cpu for all SNMP management tasks.
Additionally, there are many applications provided
that are all user-configurable. The following
applications and their functionality is listed below:
General Info:
X Windows, 11.4 based implemented with OSF/Motif 1.1.1
toolkit. X Windows interface for all configuration
files. Most applications have "verbose" mode for
display of SNMP PDU traffic. On-line help and
Reference manual pages. ANSI C compliant.
Network Management Daemon:
Responsible for device discovery, trap/alarm
management and fault monitoring for the network map.
Connection with other distributed daemons and any
connected stations is accomplished with SNMP/TCP.
Configured via Manager MIB; also incorporates SMUX MIB
(RFC 1227). Sends any information to INGRES, Oracle
or Sybase via an ESQL interface. User-defined actions
include: send alarm to map; send info to flat file;
execute ESQL command; call any UNIX system command;
forward traps and filter user-defined alarms.
User-defined alarms can use any boolean expression and
MIB variable expressions can be combined with AND/OR
statements.
MIB Compiler
ASN.1 MIB compiler with X Windows interface. Accepts
RFC 1155 and 1212 format. Most vendor-specific MIBs
and proposed Internet standard MIBs already included.
Network Map
Comprehensive network monitoring map with click and
drag interface, hiearchical and virtual views.
Toolkit and preferences applications, device
discovery. Uses /etc/hosts file, NIS or DNS for
device resolution. Background pixmapping capability,
user-definable menu bar, network manager and console
operator modes via UNIX group permissions. Multiple
map use without limitation.
MIB Form and MIB Form Editor
User-designed, X-based SNMP applications. Alias for
MIB variables and interprets returned values. GET
NEXT and SET capability. User-defined polling and
multi-device [agent] capability. Configured via X
interface.
MIB Chart and MIB Chart Editor
Choice of strip chart, packed strip chart or bar
graphs. User-specified polling interval, MIB
variable(s) or MIB expressions using arithmetic
operands. Plot actual value, delta or delta/interval.
Plot multiple MIB expressions from multiple agents
simultaneously. X Windows interface. Pause polling
and grid options.
MIB Tool
X Windows application for the general viewing and
'walking' of MIB trees. GET NEXT and SET options.
Window for viewing RFC 1212 MIB definitions. Command
line interface option.
Application Programming Interface
Complete set of APIs for developers to write SNMP
applications in character mode or X Windows.
MECHANISM
Management Station uses SNMP and ICMP Echo Request to
monitor and control SNMP Agents. Network management
daemon implements Wollongong's Manager MIB, SNMP over
TCP and the SMUX protocol.
CAVEATS
none.
BUGS
See Product Release Notice.
LIMITATIONS
Limitations on number of management agents and network
management daemons not known at this time.
HARDWARE REQUIRED
Sun SPARC workstations and servers
DEC DECstations and DECsystems
Motorola MPC (Delta 8000 series)
3/486 PC and PC-compatible
16 MB RAM
n20 MB free disk space for installation
Color monitor strongly recommended
SOFTWARE REQUIRED
SunOS 4.1-1 or greater & OpenWindows 2.0 or greater (SUN)
X Windows, 11.4 or greater
RISC ULTRIX 4.1 or greater (DEC)
R32V2 (Motorola)
Open Desktop 1.1 or greater (3/486)
Provided on 1/4" cartridge, TK-50 or 3 1/2" diskettes,
as appropriate, in cpio format.
AVAILABILITY
A commercial product of:
The Wollongong Group, Inc.
1129 San Antonio Rd
Palo Alto, CA. 94303
ph.: (800) 962 - 8649 (in California)
(800) 872 - 8649 (outside California)
fax: (415) 962 - 0286
Internet Tool Catalog XNETDB
NAME
Xnetdb
KEYWORDS
database, manager, map, monitoring, status; IP; Ping,
SNMP, Unix, X; free.
ABSTRACT
Xnetdb is a network monitoring tool based on X Windows
and SNMP which also has integrated database and
statistic viewing capabilities. Xnetdb will determine
and display the status of routers and circuits it has
been told to monitor by querying the designated sites
and displaying the result. It can also query the
status of certain designated SNMP variables, such as a
default route for an important router. Additionally,
it also has integrated database functionality in that
it can display additional information about a site or
circuit such as the equipment at the site, the contact
person(s) for the site, and other useful information.
Finally it can gather designated statistical
information about a circuit and display it on demand.
MECHANISM
Xnetdb uses SNMP or ping to monitor things which its
configured to monitor. It dynamically builds a
network map on its display by querying entities and
obtaining IP addresses and subnet masks. A
configuration file tells xnetdb which IP hosts you
want to monitor.
CAVEATS
While "ping" can be used to monitor hosts, more useful
results are obtained using SNMP.
BUGS
Bugs and other assorted topics are discussed on the
xnetdb mailing list. To join, send a note to
"xnetdb-request@oar.net".
LIMITATIONS
None.
HARDWARE REQUIRED
No restrictions.
SOFTWARE REQUIRED
Most any variety of UNIX plus X-Windows and/or
OpenWindows.
AVAILABILITY
Available via anonymous ftp from ftp.oar.net
(currently 131.187.1.102) in the directory /pub/src.
Special arrangements can be made for sites without
direct IP access by sending a note to
"xnetdb-request@oar.net". There are minimal licensing
restrictions - these are detailed within the package.
Internet Tool Catalog XNETMON_SNMP_RESEARCH
NAME
XNETMON -- an X windows based SNMP network management
station from SNMP Research.
KEYWORDS
alarm, benchmark, control, debugger, manager, map,
reference, security, status, traffic;
bridge, DECnet, Ethernet, FDDI, IP, OSI, ring, star;
NMS, Ping, SNMP, X;
UNIX;
Sourcelib.
ABSTRACT
The XNETMON application implements a powerful network
management station based on the X window system.
XNETMON's network management tools for configuration,
performance, security, and fault management have been
used successfully with a wide assortment of wide- and
local-area-network topologies and medias.
Multiprotocol devices are supported
including those using TCP/IP, DECnet, and OSI
protocols.
Some features of XNETMON's network management tools include:
o Fault management tool displays a map of the network
configuration with node and link state indicated
in one of several colors to indicate current status;
o Configuration management tool may be used to edit the
network management information base stored in the
NMS to reflect changes occurring in the network;
o Graphs and tabular tools for use in fault and performance
management (e.g. XNETPERFMON);
o Mechanisms by which additional variables, such as vendor-
specific variables, may be added;
o Alarms may be enabled to alert the operator of events
occurring in the network;
o Events are logged to disk;
o Output data may be transferred via flat files for
additional report generation by a variety of
statistical packages.
The XNETMON application comes complete with source
code including a powerful set of portable libraries
for generating and parsing SNMP messages.
MECHANISM
XNETMON 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
focus and intensity of the polling.
CAVEATS
None.
BUGS
None known.
LIMITATIONS
Monitored and managed nodes must implement the SNMP over
UDP per RFC 1157 or must be reachable via a proxy agent.
HARDWARE REQUIRED
X windows workstation with UDP socket library.
Monochrome is acceptable, but color is far superior.
SOFTWARE REQUIRED
X windows version 11 release 4 or later or MOTIF.
AVAILABILITY AND CONTACT POINT FOR INFORMATION ABOUT THIS TOOL
This is a commercial product available under license
from:
SNMP Research
3001 Kimberlin Heights Road
Knoxville, TN 37920-9716
Attn: John Southwood, Sales and Marketing
(615) 573-1434 (Voice) (615) 573-9197 (FAX)
CONTACT POINT FOR CHANGES TO THIS CATALOG ENTRY
users@seymour1.cs.utk.edu
Internet Tool Catalog XNETMON_WELLFLEET
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.
AVAILABILITY
Commercial product of:
Wellfleet Communications, Inc.
12 DeAngelo Drive
Bedford, MA 01730-2204
(617) 275-2400
Internet Tool Catalog XNETPERFMON_SNMP_RESEARCH
NAME
xnetperfmon -- a graphical network performance and
fault management tool from SNMP Research.
KEYWORDS
manager, security, status;
DECnet, Ethernet, IP, OSI, ring, star;
NMS, SNMP, X;
DOS, UNIX, VMS;
sourcelib.
ABSTRACT
Xnetperfmon is a XNETMON tool used to produce plots of
SNMP variables in graphical displays. The manager may
easily customize the labels, step size, update interval,
and variables to be plotted to produce graphs for fault
and performance management. 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 Management
Protocol (SNMP).
CAVEATS
All plots for a single invocation of xnetperfmon must be
for variables provided by a single network management
agent. However, multiple invocations of xnetperfmon 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
XNETMON from SNMP Research and X Version 11 release 4 or
later (option MOTIF)
AVAILABILITY AND CONTACT POINT FOR INFORMATION ABOUT THIS TOOL
This is a commercial product available under license
from:
SNMP Research
3001 Kimberlin Heights Road
Knoxville, TN 37920-9716
Attn: John Southwood, Sales and Marketing
(615) 573-1434 (Voice) (615) 573-9197 (FAX)
CONTACT POINT FOR CHANGES TO THIS CATALOG ENTRY
users@seymour1.cs.utk.edu
Internet Tool Catalog XUP_HP
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.
Appendix: "No-Writeups" This section contains references to tools which are known to exist, but which have not been fully cataloged. If anyone wishes to author an entry for one of these tools please contact: noctools- request@merit.edu. Each mention is separated by a <form-feed> for improved readability. If you intend to actually print-out this section of the catalog, then you should probably strip-out the <ff>. tuecho.c /* * Send / receive TCP or UDP echos in any of a number of bizzare ways. * * Joel P. Bion, March 1990 * Copyright (c) 1990 cisco Systems. All rights reserved. * * This "tuecho" program is distributed in the hope that it will be * useful, but WITHOUT ANY WARRANTY; without even the implied warranty * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. * * Prompts as: * Host: -- host to send echos to -- can be name or a.b.c.d -- * Enter protocol (0 = UDP, 1 = TCP) [0]: -- UDP or TCP * Size of data portion (bytes) [100]: -- bytes in data, excluding * headers -- Number of bursts [5]: -- number of bursts of packets to * send -- Packets per burst [1]: -- packets per burst, all sent AT * ONCE -- Timeout (seconds) [2]: -- how long to wait for data * Pause interval (seconds) [0]: -- Pause interval between bursts of * frames * Type of pattern (specify = 0, increment = 1) [1]: * -- if 0 specified, allow you to specify a 16bit pattern -- as four hex digits (see below). If 1, will create a -- "incrementing", cycling pattern from 0x0000 -> 0xffff -- ->. * Enter pattern (hex value) [abcd]: -- if "0" specified above */ Availability: ftp.uu.net:/networking/cisco/tuecho.c ftp.cisco.com:tuecho.c
SPY An NFS monitoring/tracing tool
Availability:
A postscript file describing SPY is located on
ftp.uu.net:/networking/ip/nfs/spy.ps.Z
NFSTRACE
This is the rpcspy/nfstrace package.
It is described in detail in the paper "NFS Tracing by Passive
Network Monitoring", which appeared in the January, 1992 USENIX
conference.
You'll need either a DEC machine running ULTRIX (with the
packetfilter installed in the kernel) or a Sun running SunOS 4.x
(with NIT). Or you'll need to do a bit of hacking.
The package differs slightly from the version in the paper:
- The handle->name translation facility has been removed. It's
just too fragile to include in the general release. If you need it,
contact me directly and I'll be happy to mail you the code.
- The output format is a wee-bit different.
- The IBM-RT Enet filter version is also not included, since I seem to
be the only person in the world running it. RTs are really too slow
for this anyway.
To configure the package, edit the makefile in the obvious (to me at
least) way.
Note that the not all versions of SunOS NIT have working versions of
the packet timestamp mechanism. Try to set the -DSTAMPS option in
the makefile, and if that doesn't work, take it out.
If you are actually going to use this to gather traces, I'd like to
hear from you! Please send email, and share your results/traces if
your organization will allow it. I maintain a mailing list of users
for updates, etc. Send me mail to be added to it.
Happy tracing.
Matt Blaze
Department of Computer Science
Princeton University
35 Olden Street
Princeton, NJ 08544
mab@cs.princeton.edu
609-258-3946
Availability:
ftp.uu.net:/networking/ip/nfs/nfstrace.shar (or check archie)
LAMER
# Lame delegation notifier
# Author: Bryan Beecher
# Last Modified: 6/25/92
#
# To make use of this software, you need to be running the
# University of Michigan release of BIND 4.8.3, or any version
# of named that supports the LAME_DELEGATION patches posted to
# USENET. The U-M release is available via anonymous ftp from
# terminator.cc.umich.edu:/unix/dns/bind4.8.3.tar.Z.
#
# You must also have a copy of query(1) and host(1). These
# are also available via anonymous ftp in the aforementioned
# place.
# -------------------------------------------------------------
# -------------------------------------------------------------
# handle arguments
# -------------------------------------------------------------
# -d <day>
# This flag is used to append a dot-day suffix to the LOGFILE.
# Handy where log files are kept around for the last week
# and contain a day suffix.
#
# -f <logfile>
# Change the LOGFILE value altogether.
#
# -w
# Count up all of the DNS statistics for the whole week.
#
# -v
# Be verbose.
#
# -t
# Test mode. Do not send mail to the lame delegation
# hostmasters.
Availability:
ftp.uu.net:/networking/ip/dns/lamer.tar.Z (or check archie)
HOST
host - look up host names using domain server
SYNOPSIS
host [-v] [-a] [-t querytype] [options] name [server]
host [-v] [-a] [-t querytype] [options] -l domain [server]
host [-v] [options] -H [-D] [-E] [-G] domain
host [-v] [options] -C domain
host [-v] [options] -A host
DESCRIPTION
host looks for information about Internet hosts or domains.
It gets this information from a set of interconnected
servers that are spread across the world. By default, it
simply converts between host names and Internet addresses.
However, with the -t, -a and -v options, it can be used to
find all of the information about hosts or domains that is
maintained by the domain nameserver.
/*
* Extensively modified by E. Wassenaar, Nikhef-H, <e07@nikhef.nl>
*
* The officially maintained source of this program is available
* via anonymous ftp from machine 'ftp.nikhef.nl' [192.16.199.1]
* in the directory '/pub/network' as 'host.tar.Z'
*
* Also available in this directory are patched versions of the
* BIND 4.8.3 nameserver and resolver library which you may need
* to fully exploit the features of this program, although they
* are not mandatory. See the file 'README_FIRST' for details.
*
* You are kindly requested to report bugs and make suggestions
* for improvements to the author at the given email address,
* and to not re-distribute your own modifications to others.
*/
/*
* New features
*
* - Major overhaul of the whole code.
* - Very rigid error checking, with more verbose error messages.
* - Zone listing section completely rewritten.
* - It is now possible to do recursive listings into subdomains.
* - Maintain resource record statistics during zone listings.
* - Maintain count of hosts during zone listings.
* - Exploit multiple server addresses if available.
* - Option to exploit only primary server for zone transfers.
* - Option to exclude info from names that do not reside in a domain.
* - Implement timeout handling during connect and read. * - Write resource record output to optional logfile. * - Special MB tracing by recursively expanding MR and MG records. * - Special mode to check SOA records at each nameserver for domain. * - Special mode to check inverse mappings of host addresses. * - Code is extensively documented. */
PINGs
Many many versions of the PING program exist.
Each implementation has its own set of additional features.
Here are a few more PINGs that are worth taking a look at.
Version on ftp.cc.berkeley.edu:pub/ping:
This version has duplicate packet detection, Record Route,
ability to specify data pattern for packets, flood pinging, an
interval option, Multicast support, etc.
Version on nikhefh.nikhef.nl:/pub/network/rping.tar.Z:
'rping' is just like 'ping', but only a single probe packet
is sent to test the reachability of a destination.
As an option, the loose source routing facility is used
to show the roundtrip route the packet has taken.
Multiple addresses of remote hosts are tried until one
responds. As an option, each of multiple addresses can be
probed unconditionally.
Contains a patch for making loose source routing work in
case you have a SUN with an OMNINET ethernet controller.
VRFY
vrfy.tar.Z (Version 921021)
'vrfy' is a tool to verify email addresses and mailing lists.
In its simplest form it takes an address "user@domain", figures
out the MX hosts for "domain", and issues the SMTP command VRFY
at the primary MX host (optionally all), or at "domain" itself
if no MX hosts exist. Without "domain" it goes to "localhost".
More complex capabilities are: recursively expanding forward
files or mailing lists, and detecting mail forwarding loops.
Full-blown RFC822 address specifications are understood.
Syntax checking can be carried out either locally or remotely.
Various options are provided to exploit alternative protocol
suites if necessary, and to print many forms of verbose output.
Obvious limitations exist, but on average it works pretty well.
Needless to say you need internet (nameserver and SMTP) access.
See the man page and the extensive documentation in the source
for further details.
Please send comments and suggestions to Eric Wassenaar <e07@nikhef.nl>
If you want to receive notification of updates, please send an email
with the keyword "subscribe" in the subject or the body to the address
<net-dist-request@nikhef.nl>
available as: nikhefh.nikhef.nl:/pub/network/vrfy.tar.Z
XNETLOAD
NAME
xnetload - ethernet load average display for X
SYNOPSIS
xnetload[-toolkitoption ...] [-scale integer]
[-update seconds] [-hl color] [-highlight color]
[-jumpscroll pixels] [-label string] [-nolabel] host
DESCRIPTION
The xnetload program displays a periodically updating histo-
gram of the ethernet load average for the specified host.
The resulting graph is scaled as 0% to 100%, where 0%
corresponds to 0mbs and 100% corresponds to 10mbs. NOTE:
The specified host must be running rpc.etherd.
This program has been run using X11R4 and X11R5, under the following
operating systems:
SUNOS 4.1.0
SUNOS 4.1.1
ULTRIX V4.2
IRIX 3.3.2
Assuming the Imake templates and Rules are in order and in the proper
place on your system, these programs should compile and link
straightforward by running the following sequence:
xmkmf
make
Then, as root, issue the following:
make install
make install.man
Then, on your host system, (or on any other system you can rlogin or rsh
into) start the etherd daemon with the following (must be root):
/usr/etc/rpc.etherd le0 &
where le0 is the mnemonic for the primary ethernet interface.
To start the xnetload program, the following command line is suggested:
./xnetload -hl red host &
where "host" is the name of any reachable network node (including
LOCALHOST) that is running the etherd daemon. A small xload window
should appear on your local display with nine horizontal lines. The
label:
"Ethernet Load %"
should appear in the upper left hand corner, just below any additional
title bars or other decorations provided by your window manager. If the
program comes up without the nine lines, or without the "Ethernet Load"
label, then either your resource file is not properly installed in the
appropriate app-defaults directory, or you may have picked up the wrong
xnetload image. Try re-running "make install" as root, or be sure to
include the "./" in front of the command name.
Good Luck!
The following changes have been made to this directory since R3:
o Now use Athena StripChart widget.
o Understands WM_DELETE_WINDOW.
o 3-26-92 Modified from xload to xnetload by Roger Smith,
Sterling Software at NASA-Ames Research Center,
Mountain View, Calif. rsmith@proteus.arc.nasa.gov
Availability:
ftp proteus.arc.nasa.gov:pub/XEnetload.tar.Z (or check archie)
NETTEST
nettest, nettestd - Performs client and server functions for
timing data throughput
The nettest and nettestd commands invoke client and server
programs that are used for timing data throughput of various
methods of interprocess communication. For TCP and OSI con-
nections, the nettest program establishes a connection with
the nettestd program, and then it does count writes of size
bytes, followed by count reads of size bytes. For UDP, the
nettest program performs only writes; reads are not per-
formed. The nettestd program, if used with UDP connections,
reads the data packets and prints a message for each data
packet it receives. The number and size of the reads and
writes may not correlate with the number and size of the
actual data packets that are transferred; it depends on the
protocol that is chosen. If you append an optional k (or K)
to the size, count, or bufsize value, the number specified
is multiplied by 1024.
This source for nettest and nettestd are provided on an "as is"
basis. Cray Research does not provide any support for this code
(unless you are a customer who has purchased the UNICOS operating
system).
We will gladly take bug reports for nettest/nettestd. Suggested
fixes are prefered to just bug reports. Changes to allow
nettest/nettestd to run on other architectures are also welcomed. We
will try to incorporate bugfixes and update the publicly available
code, but we can make no guarantees.
For copyright information, see the notice in each source file.
Send bug-reports/fixes to:
E-mail: dab@cray.com
U.S. Mail: David Borman
Cray Research, Inc.
655F Lone Oak Drive
Eagan, MN 55121
Notes:
1) The -b option to nettestd has not been tested...
2) The ISO code should work on a 4.4BSD system, but the
gethostinfo() routine is specific to UNICOS...
Availability:
ftp sgi.com:/sgi/src/nettest
ETHERCK
etherck is a simple program that displays Sun ethernet statistics.
If you have a high percents of input errors that are due to "out of
buffers", then you can run the "iepatch" script to patch a kernel
that uses the Intel ethernet chip ("ie"). A back of the envelope
calculation shows that a .25% input error rate gives about a 10%
degradation of NFS performance if 8k packets are being used.
In our environment at Legato, patching the ie buffer allocation made
the input error rate drop more than 2 orders of magnitude. This was
after we had applied other networking fixes (e.g., using Prestoserve,
going from thin wire to twisted pair) and pushed a higher load on the
server.
Note that both etherck and iepatch must be run by root (or you can
make etherck setgid kmem).
Availability:
send EMAIL to: request@legato.com
with a Subject line: send unsupported etherck
The following is part of the 'help' file from the Legato Email
Server:
This message comes to you from the request server at Legato.COM,
request@Legato.COM. It received a message from you asking for help.
The request server is a mail-response program. That means that you
mail it a request, and it mails back the response.
The request server is a very dumb program. It does not have much
error checking. If you don't send it the commands that it
understands, it will just answer "I don't understand you".
The request server has 4 commands. Each command must be the first
word on a line. The request server reads your entire message before
it does anything, so you can have several different commands in a
single message. The request server treats the "Subject:" header line
just like any other line of the message. You can use any combination
of upper and lower case letters in the commands.
The request server's files are organized into a series of directories
and subdirectories. Each directory has an index, and each
subdirectory has an index. The top-level index gives you an overview
of what is in the subdirectories, and the index for each subdirectory
tells you what is in it.
The server has 4 commands:
"help" command: The command "help" or "send help" causes the server to
send you the help file. You already know this, of course,
because you are reading the help file. No other commands are
honored in a message that asks for help (the server figures
that you had better read the help message before you do
anything else).
SEND a request to Legato to get the rest of the help file!
NETCK
netck is a shar file that contains the sources to build "netck", a
network checker that uses the rstat(3R) protocol to gather and print
statistics from machines on the network. netck is useful to help
understand what part of what machines are potential NFS bottlenecks.
To get this file, send email to the request server with the command
"send unsupported netck".
Availability:
same as ETHERCK (send email To: request@legato.com; subject:
HELP)
References [1] Stine, R., Editor, "FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices", FYI 2, RFC 1147, Sparta, Inc., April 1990. Security Considerations Security issues are not discussed in this memo. Authors' Addresses Robert M. Enger Advanced Network and Services 1875 Campus Commons Drive, Suite 220 Reston, VA. 22091-1552 Phone: 703-758-7722 EMail: enger@reston.ans.net Joyce K. Reynolds Information Sciences Institute University of Southern California 4676 Admiralty Way Marina del Rey, CA 90292 Phone: (310) 822-1511 Email: JKREY@ISI.EDU