SOFTWARE REQUIRED
Some UNIX variant or some other OS with a Berkeley
Socket Compatibility Library. X-Windows.
AVAILABILITY
Snmpxmon is available in the NYSERNet SNMP Software
Distribution, which is licensed, copyrighted software.
To obtain information regarding the package send mail
to: snmplisc@nisc.nyser.net or call +1 518-283-8860.
NAME
snmpxperf
KEYWORDS
manager, status; IP; NMS, SNMP, X; UNIX.
ABSTRACT
Snmpxperf is a network monitoring application based on
X-Windows Version 11 Release 2 and the Simple Network
Management Protocol. The application monitors a single
numeric MIB object and displays its value in an EKG
style histogram. Snmpxperf supports color graphics.
MECHANISM
Snmpxperf uses SNMP to gather its information. The MIB
object to be graphed must be specified on the command
line. The polling interval can be changed dynamically
from within snmpxperf.
CAVEATS
An SNMP agent must be running in the network entity
being monitored in order for snmpxperf to be useful.
BUGS
Auto-scaling sometimes doesn't downscale the EKG-graph
enough on large spikes. This results in some of the
graph running into the button boxes at the top of the
window. Generally, Bugs are fixed as reports come in.
Report bugs to: nysersnmp@nisc.nyser.net
LIMITATIONS
Can only graph one numeric MIB object per invocation.
HARDWARE REQUIRED
Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
tion I, DECstation, and a Solbourne 4/802.
SOFTWARE REQUIRED
Some UNIX variant or some other OS with a Berkeley
Socket Compatibility Library. X-Windows.
AVAILABILITY
Snmpxperf is available in the NYSERNet SNMP Software
Distribution, which is licensed, copyrighted software.
To obtain information regarding the package send mail
to: snmplisc@nisc.nyser.net or call +1 518-283-8860.
NAME
snmpxperfmon
KEYWORDS
manager, status, traffic; IP; NMS, SNMP, X; UNIX.
ABSTRACT
Snmpxperfmon is a network monitoring application based
on X-Windows Version 11 Release 2 and the Simple Net-
work Management Protocol. The application monitors a
single Network Entity and displays graphical informa-
tion pertaining to the entities interface traffic
statistics. Snmpxperfmon supports color graphics.
MECHANISM
Snmpxperfmon uses SNMP to gather its information. The
MIB agent to be polled must be specified on the command
line. The agent is then queried about all of its
interfaces. Four EKG-style graphs are constructed for
each interface (input pkts, output pkts, input Octets,
output Octets).
CAVEATS
An SNMP agent must be running in the network entity
being monitored in order for snmpxperfmon to be useful.
BUGS
Generally, bugs are fixed as reports come in. Report
bugs to: nysersnmp@nisc.nyser.net
LIMITATIONS
Can only graph one network entity per invocation. Can
only graph the amount of interfaces which will fit on a
single bitmap display. Does not auto-scale or resize.
HARDWARE REQUIRED
Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
tion I, DECstation, and a Solbourne 4/802.
SOFTWARE REQUIRED
Some UNIX variant or some other OS with a Berkeley
Socket Compatibility Library. X-Windows.
AVAILABILITY
Snmpxperfmon is available in the NYSERNet SNMP Software
Distribution, which is licensed, copyrighted software.
To obtain information regarding the package send mail
to: snmplisc@nisc.nyser.net or call +1 518-283-8860.
NAME
snmpxrtmetric
KEYWORDS
manager, routing; IP; NMS, SNMP, X; UNIX.
ABSTRACT
Snmpxrtmetric is a network monitoring application based
on X-Windows Version 11 Release 2 and the Simple Net-
work Management Protocol. The application monitors the
routing table of a specific agent and displays the RIP
routing metric of certain destination networks in bar
chart format.
MECHANISM
Snmpxrtmetric uses SNMP to gather its information. A
configuration file is used to determine which destina-
tion networks will be graphed. The agent to be queried
is specified on the command line. Snmpxrtmetrtic sup-
ports color graphics.
CAVEATS
An SNMP agent must be running in the network entity
being monitored in order for snmpxrtmetric to be use-
ful.
BUGS
None outstanding. They are fixed as reports come in.
Report bugs to: nysersnmp@nisc.nyser.net
LIMITATIONS
SNMP polling is done synchronously. The destination
networks must be configured by manually adding informa-
tion to a configuration file.
HARDWARE REQUIRED
Developed on Sun 3/60, Sun 3/260, tested on a SPARCsta-
tion I, DECstation, and a Solbourne 4/802.
SOFTWARE REQUIRED
Some UNIX variant or some other OS with a Berkeley
Socket Compatibility Library. The X window system.
AVAILABILITY
Snmpxrtmetric is available in the NYSERNet SNMP
Software Distribution, which is licensed, copyrighted
software. To obtain information regarding the package
send mail to: snmplisc@nisc.nyser.net or call +1 518-
283-8860.
NAME
SpiderMonitor P220, K220 and
SpiderAnalyzer P320, K320
KEYWORDS
alarm, analyzer, generator, traffic; DECnet, ethernet,
IP, OSI; eavesdrop; standalone; sourcelib.
ABSTRACT
The SpiderMonitor and SpiderAnalyzer are protocol
analyzers for performing ethernet LAN diagnostics, mon-
itoring, traffic generation, and troubleshooting. The
SpiderMonitor has the capability of capturing every
packet on a network and of decoding the first four
layers of the OSI protocol model. The SpiderAnalyzer
has additional software for decoding higher protocol
layers. Protocol suites understood: TCP/IP (including
SNMP and applications-layer protocols), OSI, XNS, DEC-
net and IPX. User-definable decodes can be written in
'C' with the Microsoft version 5.0 'C' compiler. A
decode guide is provided.
The SpiderAnalyzer supports multiple simultaneous
filters for capturing packets using predefined patterns
and error states. Filter patterns can also trigger on
NOT matching 1 or more filters, an alarm, or a speci-
fied time.
The SpiderAnalyzer can also employ TDR (Time Domain
Reflectometry) to find media faults, open or short cir-
cuits, or transceiver faults. It can transmit OSI,
XNS, and Xerox link-level echo packets to user-
specified stations, performs loop round tests.
In traffic generation mode, the SpiderAnalyzer has the
ability to generate packets at random intervals of ran-
dom lengths or any combination of random or fixed
interval or length, generation of packets with CRC
errors, or packets that are too short, or packets that
are too long.
Output from the SpiderMonitor/Analyzer can be imported
to database or spreadsheet packages.
MECHANISM
The SpiderMonitor and Spider Analyzer are available as
stand-alone, IBM PC compatible packages based upon a
Compaq III portable system, or as a plug-in boards for
any IBM XT/AT compatible machine. The model 220 (Spi-
derMonitor) systems provide a functional base suited
for most network management needs. The model 320 (Spi-
derAnalyzer) systems provide extended functionality in
the development mode and traffic generation mode as
well more filtering capabilities than the 220 models.
CAVEATS
Traffic generation will congest an operational ether-
net.
BUGS
None known.
LIMITATIONS
Monitoring of up to 1024 stations and buffering of up
to 1500 packets. The model 220 provides for 3 filters
with a filter depth of 46 bytes. The model 320 pro-
vides for 4 filters and a second level of filtering
with a filter depth of 64 bytes.
HARDWARE REQUIRED
PX20s are self contained, the KX20s require an IBM
PC/XT-AT compatible machine with 5 megabytes of hard
disk storage and the spare slot into which the board
kit is plugged.
SOFTWARE REQUIRED
None. The SpiderAnalyzer requires the Microsoft 'C'
Compiler, Version 5.0 for writing user defined decodes.
AVAILABILITY
The SpiderMonitor/Analyzer is available commercially.
For information on your local representative, call or
write:
Spider Systems, Inc.
12 New England Executive Park
Burlington, MA 01803
Telephone: 617-270-3510
FAX: 617-270-9818
NAME
SPIMS -- the Swedish Institute of Computer Science
(SICS) Protocol Implementation Measurement System tool.
KEYWORDS
benchmark, debugger; IP, OSI; spoof; UNIX.
ABSTRACT
SPIMS is used to measure the performance of protocol
and "protocol-like" services including response time
(two-way delay), throughput and the time to open and
close connections. It has been used to:
o+ benchmark alternative protocol implementations,
o+ observe how performance varies when parameters in
specific implementations have been varied (i.e.,
to tune parameters).
SPIMS currently has interfaces to the DoD Internet Pro-
tocols: UDP, TCP, FTP, SunRPC, the OSI protocols from
the ISODE 4.0 distribution package: FTAM, ROSE, ISO TP0
and to Sunlink 5.2 ISO TP4 as well as Stanford's VMTP.
Also available are a rudimentary set of benchmarks,
stubs for new protocol interfaces and a user manual.
For an example of the use of SPIMS to tune protocols,
see:
Nordmark & Cheriton, "Experiences from VMTP: How
to achieve low response time," _I_F_I_P _W_G_6._1/_6._4:
_P_r_o_t_o_c_o_l_s _f_o_r _H_i_g_h-_S_p_e_e_d _N_e_t_w_o_r_k_s, May 1989,
Zurich. To be published.
MECHANISM
SPIMS runs as user processes and uses a TCP connection
for measurement set-up. Measurements take place
between processes over the measured protocol. SPIMS
generates messages and transfers them via the measured
protocol service according to a user-supplied specifi-
cation. SPIMS has a unique measurement specification
language that is used to specify a measurement session.
In the language there are constructs for different
application types (e.g., bulk data transfer), for
specifying frequency and sequence of messages, for dis-
tribution over message sizes and for combining basic
specifications. These specifications are independent
of both protocols and protocol implementations and can
be used for benchmarking. For more details on the
internals of SPIMS, see:
Nordmark & Gunningberg, "SPIMS: A Tool for Proto-
col Implementation Performance Measurements" _P_r_o_c.
_o_f _1_3:_t_h _C_o_n_f. _o_n _L_o_c_a_l _C_o_m_p_u_t_e_r _N_e_t_w_o_r_k_s, Min-
neapolis 1989, pp 222-229.
CAVEATS
None.
BUGS
None known.
LIMITATIONS
None reported.
HARDWARE REQUIRED
No restrictions.
SOFTWARE REQUIRED
SPIMS is implemented on UNIX, including SunOS 4.,
4.3BSD UNIX, DN (UNIX System V, with extensions) and
Ultrix 2.0/3.0. It requires a TCP connection for meas-
urement set-up. No kernel modifications or any modifi-
cations to measured protocols are required.
AVAILABILITY
SPIMS is not in the public domain; the software is
covered by licenses. The Swedish Institute of Computer
Science has released the research prototype of SPIMS
for research and non-commercial use. Commercial organ-
izations may obtain the research prototype, but it is
for internal research only and for no commercial use
whatsoever. A commercial, supported version of SPIMS is
distributed by TeleLOGIC Uppsala AB, Sweden.
For universities and non-profit organizations, SPIMS
source code is distributed free of charge. There are
two ways to get the software:
1. FTP. If you have an Internet FTP connection, you
can use anonymous FTP to sics.se [192.16.123.90],
and retrieve the file in pub/spims-
dist/dist890915.tar.Z (this is a .6MB tar image)
in BINARY mode. Log in as user anonymous and at
the password prompt, use your complete electronic
mail address.
2. On a Sun 1/4-inch cartridge tape. For mailing, a
handling fee of US$150.00 will be charged. Submit
a bank check with the request. Do not send tapes
or envelopes.
For other organizations, the SPIMS source code for the
research prototype is distributed for a one-time fee of
US$500.00. Organizations interested in the research
prototype need to contact SICS via email and briefly
motivate why they qualify (non-commercial use) for the
research prototype. They will thereafter get a permis-
sion to obtain a copy from the same distribution source
as for universities.
For more information about the research prototype dis-
tribution, contact:
Swedish Institute of Computer Science
Att: Birgitta Klingenberg
P.O. Box 1263
S-164 28 Kista
SWEDEN
e-address: spims@sics.se
Phone: +46-8-7521500, Fax: +46-8-7517230
TeleLOGIC Uppsala AB, a subsidiary of Swedish Telecom,
distributes and supports a version of SPIMS for commer-
cial use. It consists of object code for SunOS 4.,
4.3BSD UNIX, DNIX, and Ultrix 2.0/3.0. Support for
other UNIX-like implementations will be considered
according to demand. The same interfaces to the DoD
Internet and OSI protocols from the ISODE 4.0 are
included as well as a user manual.
For further information about SPIMS for the commercial
user please contact:
Claes Hojenberg
TeleLOGIC Uppsala AB
P.O. Box 1218
S-751 42 UPPSALA
Sweden
e-address: claes@uplog.se
Phone: +46-18-189400, Fax: +46-18-132039
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.
NAME
tcpdump
KEYWORDS
traffic; ethernet, IP, NFS; UNIX, VMS; free.
ABSTRACT
Tcpdump can interpret and print headers for the follow-
ing protocols: ethernet, IP, ICMP, TCP, UDP, NFS, ND,
ARP/RARP, AppleTalk. Tcpdump has proven useful for
examining and evaluating the retransmission and window
management operations of TCP implementations.
MECHANISM
Much like etherfind, tcpdump writes a log file of the
frames traversing an ethernet interface. Each output
line includes the time a packet is received, the type
of packet, and various values from its header.
CAVEATS
None.
BUGS
None known.
LIMITATIONS
Public domain version requires a kernel patch for
SunOS.
HARDWARE REQUIRED
Ethernet.
SOFTWARE REQUIRED
BSD UNIX or related OS, or VMS.
AVAILABILITY
Available, though subject to copyright restrictions,
via anonymous FTP from ftp.ee.lbl.gov. The source and
documentation for the tool is in compressed tar format,
in file tcpdump.tar.Z. Also available from
spam.itstd.sri.com, in directory pub. For VMS hosts
with DEC ethernet controllers, available as part of TGV
MultiNet IP software package.
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).
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
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.
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.
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.
NAME
Unisys Network Control Center (NCC)
KEYWORDS
alarm, benchmark, control, generator, manager, map,
reference, status, traffic; ethernet, FDDI, IP; NMS,
ping, SNMP; UNIX.
ABSTRACT
The Unisys Defense Systems Network Control Center (NCC)
provides high-performance software to support the
management and control of TCP/IP-based networks. The
network management system uses the Simple Network
Management Protocol (SNMP) to exchange management
information between the NCC and network devices. The
NCC supports the Management Information Base (MIB)
[RFC-1066] and the Structure and Identification of
Management Information for TCP/IP-based Internets
[RFC-1065]. In addition, Unisys has extended the MIB
definitions to support the features of Unisys FDDI LAN
devices, such as the FDDI Smart Concentrators, the FDDI
Host Network Front Ends, and the Remote FDDI, FDDI-to-
LAN, and FDDI-to-DDN gateways.
The NCC supports seven applications. The network
topology map displays the physical and logical maps of
the network. The configuration management tool sup-
ports the modification and validation of network device
configuration data as well as the modification of MIB
configuration data. The performance monitoring tool
supports the collection and analysis of statistical
parameters from network devices. The status monitoring
tool reports on the up/down status and responsiveness
of network devices using ICMP. The accounting tool is
used to collect, store, and display user job activity
at the subscriber hosts. The NCC database entry sup-
ports RFC1066 object definitions and Unisys-specific
object definitions to support the Unisys FDDI devices.
And finally, the trap reporting tool reports the
arrival of error and event notifications using UDP
datagrams. The NCC supports all the trap messages
defined in RFC1098.
MECHANISM
The NCC is based on the Simple Network Management Pro-
tocol (SNMP).
CAVEATS
None.
BUGS
None known.
LIMITATIONS
None reported.
HARDWARE REQUIRED
A minimal platform consists of a Sun 3/60FC-8, with at
least 200 MB disk and cartridge tape (1/4"). A full-
sized color monitor, more disk, and a workstation based
on a higher performance processor is beneficial to NCC
activities.
SOFTWARE REQUIRED
SunOS Version 4.0 running the SunView windowing en-
vironment and the SYBASE Relational Data Base Manage-
ment System.
AVAILABILITY
Commercially available as a turn-key package or as a
software product from:
Unisys Defense Systems
5151 Camino Ruiz
Camarillo, California 93010
(805) 987-6811
(Dale Russell <dsr@cam.unisys.com>)
NAME
WIN/MGT Station -- Network Management Station for
SunOS.
KEYWORDS
alarm, control, manager, routing, status, traffic; eth-
ernet, IP; NMS, SNMP, X; UNIX; library.
ABSTRACT
WIN/MGT Station for SunOS is a network management
software product based on the SNMP. It provides the
capability to manage standards-based networking pro-
ducts from The Wollongong Group as well as other ven-
dors. Fully compliant with RFCs 1065, 1066 and 1098,
WIN/MGT Station uses a menu-driven graphical user
interface.
WIN/MGT capabilities include configuration, performance
and fault management for SNMP-based agents. The
WIN/MGT station can perform polling to monitor the
status of all MIB variables defined in RFC1066,
"Management Information Base for network management of
TCP/IP-based internets." In addition, the WIN/MGT Sta-
tion can process "trap" messages from SNMP agents.
Furthermore, the WIN/MGT Station can support any
private extension to the Management Information Base
with minimal user configuration.
An icon-driven network interface map allows the user to
monitor their network topology and status. Changes in
the operational status of any manageable network ele-
ment is displayed visually and audibly.
The WIN/MGT package includes an Applications Program-
ming Interface (API) for the "C" language. The API is
a set of libraries that enable an applications program
to perform SNMP "set" and "get" operations. This
allows users to integrate site-specific applications
with WIN/MGT.
SNMP agent software for the Sun 3 host is also provided
so that the Network Management Station itself can also
be monitored and managed.
MECHANISM
The WIN/MGT Station uses SNMP to monitor and control
SNMP agents.
CAVEATS
None.
BUGS
None known.
LIMITATIONS
A theoretical limitation of approximately 18,000 net-
work elements can be managed.
HARDWARE REQUIRED
Any model of Sun 3 system. Recommended minimums
include 8 MB RAM, 100 MB disk space (30 MB to start),
and color monitor. Also tested on DECstation 3100,
PS/2 (with SCO UNIX) and Macintosh IIcx computer using
A/UX.
SOFTWARE REQUIRED
SunOS 4.x. MIT X Window System, Release 11, version 3,
or OpenWindows (X.11/NeWS) from Sun Microsystems, Inc.
WIN/MGT Station for SunOS is provided on 1/4" tape in
cpio format.
AVAILABILITY
A commercial product of:
The Wollongong Group, Inc.
1129 San Antonio Rd.
Palo Alto, CA 94303
(415) 962-7200 br fax (415) 968-3619
internet oldera@twg.com
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
NAME
XNETMON -- an X windows based SNMP network management
station from SNMP Research.
KEYWORDS
alarm, control, manager, map, routing, security,
status; DECnet, ethernet, IP, OSI, ring, star; NMS,
SNMP, X; DOS, UNIX, VMS; sourcelib.
ABSTRACT
The XNETMON application implements a powerful network
management station based on the X window system. It
provides network managers tools for fault management,
configuration management, performance management, and
security management. It can be successfully used with
many types of networks including those based on various
LAN media, and wide area networks. XNETMON has been
used with multiprotocol devices including those which
support TCP/IP, DECnet, and OSI protocols. The fault
management tool displays the map of the network confi-
guration with node and link state indicated in one of
several colors to indicate current status. Alarms may
be enabled to alert the operator of events occurring in
the network. Events are logged to disk. The confi-
guration management tool may be used to edit the net-
work management information base stored in the network
management station to reflect changes occurring in the
network. Other features include graphs and tabular
tools for use in fault and performance management and
mechanisms by which additional variables, such as
vendor-specific variables, may be added. The XNETMON
application comes complete with source code including a
powerful set of portable libraries for generating and
parsing SNMP messages. Output data from XNETMON may be
transferred via flat files for additional report gen-
eration by a variety of statistical packages.
MECHANISM
The XNETMON application is based on the Simple Network
Management Protocol (SNMP). Polling is performed via
the powerful SNMP get-next operator and the SNMP get
operator. Trap directed polling is used to regulate
the focus and intensity of the polling.
CAVEATS
None.
BUGS
None known.
LIMITATIONS
The monitored and managed nodes must implement the SNMP
over UDP per RFC1098 or must be reachable via a proxy
agent.
HARDWARE REQUIRED
X windows workstation with UDP socket library. Mono-
chrome is acceptable but color is far superior.
SOFTWARE REQUIRED
X windows version 11 release 3 or later.
AVAILABILITY
This is a commercial product available under license
from:
SNMP Research
P.O. Box 8593
Knoxville, TN 37996-4800
(615) 573-1434 (Voice)
(615) 573-9197 (FAX)
Attn: Dr. Jeff Case
NAME
xnetperfmon -- a graphical network performance and
fault management tool from SNMP Research.
KEYWORDS
manager, status; DECnet, ethernet, IP, OSI, ring, star;
NMS, SNMP, X; DOS, UNIX, VMS; sourcelib.
ABSTRACT
Xnetperfmon may be used to plot SNMP variables as a
graphical display. These graphs are often useful for
fault and performance management. Variables may be
plotted as gauges versus time. Alternatively, counters
may be plotted as delta count/delta time (rates). The
user may easily customize the variables to be plotted,
labels, step size, update interval, and the like. The
scales automatically adjust whenever a point to be
plotted would go off scale.
MECHANISM
The xnetperfmon application communicates with remote
agents or proxy agents via the Simple Network Manage-
ment Protocol (SNMP).
CAVEATS
All plots for a single invocation of xnetperfmon must
be for variables provided by a single network manage-
ment agent. However, multiple invocations of xnetperf-
mon may be active on a single display simultaneously or
proxy agents may be used to summarize information at a
common point.
BUGS
None known.
LIMITATIONS
None reported.
HARDWARE REQUIRED
Systems supporting X windows.
SOFTWARE REQUIRED
X Version 11 release 2 or later.
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
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.
Network Management Tutorial
This tutorial is an overview of the practice of network
management. Reading this section is no substitute for know-
ing your system, and knowing how it is used. Do not wait
until things break to learn what they ought to do or how
they usually work: a crisis is not the time for determining
how "normal" packet traces should look. Furthermore, it
takes little imagination to realize that you do not want to
be digging through manuals while your boss is screaming for
network service to be restored.
We assume an acquaintance with the TCP/IP protocol suite and
the Internet architecture. There are many available refer-
ences on these topics, several of which are listed below in
Section 7.
Since many of the details of network management are system-
specific, this tutorial is a bit superficial. There is,
however, a more fundamental problem in prescribing network
management practices: network management is not a well-
understood endeavor. At present, the cutting edge of net-
work management is the use of distributed systems to collect
and exchange status information, and then to display the
data as histograms or trend lines. It is not clear that we
know what data should be collected, how to analyze it when
we get it, or how to structure our collection systems. For
now, automated, real-time control of internets is an aspira-
tion, rather than a reality. The communications systems
that we field are apparently more complex than we can
comprehend, which no doubt accounts in part for their fre-
quently surprising behavior.
The first section of this tutorial lists the overall goals
and functions of network management. It presents several
aspects of network management, including system monitoring,
fault detection and isolation, performance testing, confi-
guration management, and security. These discussions are
followed by a bibliographic section. The tutorial closes
with some final advice for network managers.
1. Network Management Goals and Functions
An organization's view of network management goals is shaped
by two factors:
1. people in the organization depend on the system
working,
2. LANs, routers, lines, and other communications
resources have costs.
From the organizational vantage point, the ultimate goal of
network management is to provide a consistent, predictable,
acceptable level of service from the available data communi-
cations resources. To achieve this, a network manager must
first be able to perform fault detection, isolation, and
correction. He must also be able to effect configuration
changes with a minimum of disruption, and measure the utili-
zation of system components.
People actually managing networks have a different focus.
Network managers are usually evaluated by the availability
and performance of their communications systems, even though
many factors of net performance are beyond their control.
To them, the most important requirement of a network manage-
ment tool is that it allows the detection and diagnosis of
faults before users can call to complain: users (and bosses)
can often be placated just by knowing that a network problem
has been diagnosed. Another vital network management func-
tion is the ability to collect data that justify current or
future expenditures for the data communications plant and
staff.
Following a section on system monitoring, this tutorial
addresses fault, performance, configuration, and security
management. By fault management, we mean the detection,
diagnosis, and correction of network malfunctions. Under
the subject of performance management, we include support
for predictable, efficient service, as well as capacity
planning and capacity testing. Configuration management
includes support for orderly configuration changes (usually,
system growth), and local administration of component names
and addresses. Security management includes both protecting
system components from damage and protecting sensitive
information from unintentional or malicious disclosure or
corruption.
Readers familiar with the ISO management standards and
drafts will note both that we have borrowed heavily from the
"OSI Management Framework," except that we have omitted the
"account management" function. Account management seems a
bit out of place with the other network management
functions. The logging required by account management is
likely to be done by specialized, dedicated subsystems that
are distinct from other network management components.
Hence, this tutorial does not cover account management.
Rest assured, however, that account management, if required,
will be adequately supported and staffed.
For those with a DoD background, security may also seem out
of place as a subtopic of network management. Without
doubt, communications security is an important issue that
should be considered in its own right. Because of the
requirements of trust for security mechanisms, security com-
ponents will probably not be integrated subcomponents of a
larger network management system. Nevertheless, because a
network manager has a responsibility to protect his system
from undue security risks, this tutorial includes a discus-
sion on internet security.
2. System Monitoring
System monitoring is a fundamental aspect of network manage-
ment. One can divide system monitoring into two rough
categories: error detection and baseline monitoring.
System errors, such as misformatted frames or dropped pack-
ets, are not in themselves cause for concern. Spikes in
error rates, however, should be investigated. It is sound
practice to log error rates over time, so that increases can
be recognized. Furthermore, logging error rates as a func-
tion of traffic rates can be used to detect congestion.
Investigate unusual error rates and other anomalies as they
are detected, and keep a notebook to record your
discoveries.
Day-to-day traffic should be monitored, so that the opera-
tional baselines of a system and its components can be
determined. As well as being essential for performance
management, baseline determination and traffic monitoring
are the keys to early fault detection.
A preliminary step to developing baseline measurements is
construction of a system map: a graphical representation of
the system components and their interfaces. Then, measure-
ments of utilization (i.e., use divided by capacity) are
needed. Problems are most likely to arise, and system tun-
ing efforts are most likely to be beneficial, at highly
utilized components.
It is worthwhile to develop a source/destination traffic
matrix, including a breakdown of traffic between the local
system and other internet sites. Both volume and type of
traffic should be logged, along with its evolution over
time. Of particular interest for systems with diskless
workstations is memory swapping and other disk server
access. For all systems, broadcast traffic and routing
traffic should be monitored. Sudden increases in the vari-
ance of delay or the volume of routing traffic may indicate
thrashing or other soft failures.
In monitoring a system, long-term averages are of little
use. Hourly averages are a better indicator of system use.
Variance in utilization and delay should also be tracked.
Sudden spikes in variance are tell-tale signs that a problem
is looming or exists. So, too, are trends of increased
packet or line errors, broadcasts, routing traffic, or
delay.
3. Fault Detection and Isolation
When a system fails, caution is in order. A net manager
should make an attempt to diagnose the cause of a system
crash before rebooting. In many cases, however, a quick
diagnosis will not be possible. For some high priority
applications, restoring at least some level of service will
have priority over fault repair or even complete fault diag-
nosis. This necessitates prior planning. A net manager
must know the vital applications at his site. If applica-
tions require it, he must also have a fall-back plan for
bringing them online. Meanwhile, repeated crashes or
hardware failures are unambiguous signs of a problem that
must be corrected.
A network manager should prepare for fault diagnosis by
becoming familiar with how diagnostic tools respond to net-
work failure. In times of relative peace, a net manager
should occasionally unplug the network connection from an
unused workstation and then "debug" the problem.
When diagnosing a fault or anomaly, it is vital to proceed
in an orderly manner, especially since network faults will
usually generate spurious as well as accurate error mes-
sages. Remember to keep in mind that the network itself is
failing. Do not place too much trust in anything obtained
remotely. Furthermore, it is unlikely to be significant
that remote information such as DNS names or NFS files can-
not be obtained.
Even spurious messages can be revealing, because they pro-
vide clues to the problem. From the data at hand, develop
working hypotheses about probable causes of the problems you
detect. Direct your further data gathering efforts so that
the information you get will either refute or support your
hypotheses.
An orderly approach to debugging is facilitated if it is
guided by a model of network behavior. The following por-
tions of this section present such a model, along with a
procedure for checking network connectivity. The section
concludes with some hints for diagnosing a particularly
tricky class of connectivity problem.
3.1 A Network Model as a Diagnostic Framework
The point of having a model of how things work is to have a
basis for developing educated guesses about how things go
wrong. The problem of cascading faults -- faults generating
other faults -- makes use of a conceptual model a virtual
necessity.
In general, only problems in a component's hardware or
operating system will generate simultaneous faults in multi-
ple protocol layers. Otherwise, faults will propagate vert-
ically (up the protocol stack) or horizontally (between
peer-level communications components). Applying a concep-
tual model that includes the architectural relations of net-
work components can help to order an otherwise senseless
barrage of error messages and symptoms.
The model does not have to be formal or complex to bring
structure to debugging efforts. A useful start is something
as simple as the following:
1. Applications programs use transport services:
TCP/UDP. Before using service, applications that
accept host names as parameters must translate the
names into IP addresses. Translation may be based
on a static table lookup (/etc/hosts file in UNIX
hosts), the DNS, or yellow pages. Nslookup and
DiG are tools for monitoring the activities of the
DNS.
2. Transport protocol implementations use IP ser-
vices. The local IP module makes the initial
decision on forwarding. An IP datagram is for-
warded directly to the destination host if the
destination is on the same network as the source.
Otherwise, the datagram is forwarded to a gateway
attached to the network. On BSD hosts, the con-
tents of a host's routing table are visible by use