|
|
This appendix contains online manual pages for CiscoWorks. You can access these manual pages either from your system or by referring to these pages.
The manual pages are organized alphabetically by command name. These manual pages reflect online manual page information and do not use the document conventions found in this publication. Check the online pages as the latest resource for manual page information.
aptexec - Data editing interface for the Database Management System.
The database menu system is a collection of menus used to edit various groups of database tables. The menus are organized in a hierarchical fashion for easy traversal between menus. Each menu acts as a buffer or window for data in that menus tables. There are functions to store and retrieve data in the window to and from the tables and there are functions to modify the data that is currently in the window. With these functions one can edit all data in the tables.
The tables are grouped together in one of the ways. A table will be a lookup table for another or a table will be a detail table of another. With the first relationship, the lookup table will supply a database row of additional information for each row in the other table. With the second relationship, the detail table will supply many rows of additional information for each row in the other, master, table. In each menu there will be one main table and all others will relate to the data on that table.
The main table is used to locate groups of rows from the menu's tables. Once a row from the main table is located, all other rows can be found from the data in the main row. To locate a record, one specifies in the menu some amount of known data about the main tables row and then executes the find by example function. This will find all rows that match the data entered in the menu. If there is more than one row, the find next and the find prev functions will scroll through each group of rows found.
To modify rows found or to add new rows, edit the data in the menu for one row in one or several tables. Then place the cursor in the main table if all tables have be changed or in the master table of any master-detail group that has been changed and execute the modify or add function. Only one row per table may be modified or added at a time.
The delete function works the same as the add and modify functions. Place the cursor in the main table if you wish to delete a complete group of rows or in the master table of any master-detail group you want to delete. Then execute the delete function.
Some menus will have additional functions. These functions are for quickly viewing the contents of look-up tables. The functions are labeled Show <table name>. There is also one other function in the DEVICES menu labeled Query. This will query a device by name and add its interfaces and IP addresses to the database. To use this function, Enter only a device name and execute the function. It will then display the information it retrieved.
To move the cursor between the function area at the top of the menu and the data window area, use the control R key. To erase the current field you may use control E. And to travel between fields or functions, you may use the arrow keys. There are some arrow functions in the top right of the function section of the menu. These are used to scroll through detail records when there are more rows found then there is space on the menu to display them.
The asterisk at the top right is the exit function and may be used at any time to exit.
backup_nms.sh - Bourne shell script to backup nms
backup_nms.sh
backup_nms.sh backs up the nms database to a UNIX file system or cartridge tape. The first time it is run, it creates the dump device. Subsequently, it just performs a backup and logs the date of backup to nms/etc/DBMS_backup.log
For complete information on backup_nms.sh, use the command sysman backup_nms.sh.
drop_nms - Bourne shell script to list or delete sybase user accounts
drop_nms [ <account name> ]
drop_nms is a Bourne shell script to list or delete user accounts from the sybase database. If no arguments are given then the shell script will list the current existing accounts. If an account name is used then that account will be deleted.
isalive - check to see if the server is alive
isalive [ -Uuser_name ] -Ppassword [ -Sserver_name ]
isalive checks the server with the substantially the same arguments as any SQL Server client application. If it succeeds in connecting to the server, it returns SUCCESS to the shell that called it. If it fails, it attempts to give some diagnostics and returns FAIL.
For complete information on isalive, use the command sysman isalive.
logpurg - Cisco NetCentral Centralized Log Purging Utility
logpurg [ pathname]
Logpurg is a utility to circulate the NetCentral syslog file. It renames the current NetCentral syslog file to the same pathname with a week date suffix (i.e. ncslog.Tue), then creates a new log file, and sends a SIGHUP signal to syslogd and nmlogd. After a SIGHUP signal is received, syslogd and nmlogd configure their log file.
When it is started, logpurg gets the current syslog file pathname from /etc/syslog.conf file with facility name LOCAL6 or LOCAL7, and renames it as the same name with a weekdate suffix. If there are multiple entrances for these facilities. The first occurrence in the file is used. If a command line pathname is given, the pathname is used as the current syslog file pathname. Logpurg renames the file as the same name with a weekdate and process ID suffix. Then, logpurg opens and validates $TMPDIR/.nmlogdspool, if the file exists. Otherwise, it creates and initializes one.
$TMPDIR/.nmlogdspool is a circular file, and stores the syslog file pathnames that have not been processing by nmlogd. After a new pathname file, that retrieves from
/etc/syslog.conf file, is created, logpurg sends a SIGHUP signal to syslogd and nmlogd. If the nmlogd process is not running at the time, the renamed file pathname is inserted into $TMPDIR/.nmlogdspool. In order to be able to send a signal to syslogd process, logpurg should be running as root.
| $TMPDIR/.nmlogdspool | the ncslog operation circular file |
|---|---|
| /etc/syslog.conf | the configuration file |
| /etc/syslog.pid | the process id |
syslogd(8), logpurg(8), logger(8), cron(1)
nmeventd - CiscoWorks Event Logging Daemon
nmeventd [ -v ] [ -{iL} <filename> ] [ -d ]
Nmeventd is a daemon that receives all of the event reports and traps from the SunNet Manager event dispatcher. The data received from the event dispatcher is forwarded to syslog which stores it in the centralized log (nmslog).When nmeventd starts up, it reads in a device filter listfrom the database. When nmeventd receives an event it looks through the filter list for the device to see if the event should be stored or dropped. If an event is received from a device which is not in the filter list, the event will be saved.
The device filter list may be set using the CiscoWorks application nmdevmon(1).
OPTIONS-v Give version information
-l <filename> Use logfile for logging messages, if sloshed is not running (default is
/tmp/nmeventd<pid> where <pid> is nmeventd's process id
-L <filename> Use logfile as a redundant log file. All log messages will be logged here, as
well as being sent to CiscoWorks centralized log
-d Generate debugging information.
Nmeventd can be started and stopped using the ProcessManager (nmproc).
nmproc(1), nmdevmon(1), nmlogman(1), nmdevmond(8), nmlogd(8)
nmgraphs - CiscoWorks Real-Time Graphs
nmgraphs [ -v ] <device> [community-string]
Nmgraphs provides an easy to use interface to the SunNet Manager Grapher. When the user hits a button on the main window, a group of objects which give information about the desired subject are sent to the SunNet Manager Grapher. If the SunNet Manager Grapher is not running when the user starts a graph, nmgraphs starts it.
The polling rate for nmgraphs can be set by the user which is then passed onto the SunNet Manager Grapher. This polling rate determines how often the SunNet Manager Grapher will poll the device for the necessary information.
Nmgraphs automatically grays out certain buttons when run on a device that does not support the MIB objects necessary to obtain the desired results.
For information on how to manipulate graphs once they are on the screen, refer to the SunNet Manager Users Guide or the man page on snm_gr(1).
Nmgraphs can be run from the SunNet Manager menu on a Cisco Systems device Tools Menu as "Real-Time Graphs."
-v Print out version information.
community-string Specify a community string, default is "public".
snm_gr(1), snm(1)
mib_interface - This document describes functions used to create and interface with the in-memory MIB table.
#include "snmp_data.h"
#include "als.h"
#include "mib_als_externs.h"
/nms/lib/libmibals.a
int *recreate_mib (char *InFile )
int *mk_alias_tbl (char *InFile ) table.
*alias_lookup( STRING Alias )
void *stringIdLookup( STRING ObjectId )
void *numericIdLookup( STRING ObjectId )
int get_first_alias( ALIAS_LOCATION *WhatAlias )
int get_next_alias( ALIAS_LOCATION *WhatAlias )
STRING als_loc2name( ALIAS_LOCATION *WhatAlias )
TYPE als_loc2type( ALIAS_LOCATION *WhatAlias )
STRING Alias2Name( ALIAS_NODE *WhatAlias )
TYPE Alias2Type( ALIAS_NODE *WhatAlias )
int Alias2ProType( ALIAS_NODE *WhatAlias )
void *Alias2MibNode( ALIAS_NODE *WhatAlias )
int *recreate_mib( char *InFile )
The function recreate_mib( ) builds the in-memory MIB table from the binary format MIB file, InFile. The name and location of the binary format MIB file should parallel the scheme described in the mibbld(1) manual page. The head of the MIB table created by recreate_mib
( ) is pointed to by the global variable SNMP *name_table. The hash table for accessing the MIB table is named SNMP *name_hash[HASH_SIZE]. The MIB table created by recreate_mib( ) is identical in structure to the MIB table previously used with the exception it occupies a single contiguous area of memory (if no deletions or addition are made to the table subsequent to recreate_mib( )). Recreate_mib( ) returns TRUE if successful and FALSE if unsuccessful. Recreate_mib( ) is contained in the file mib_als_blder.c
int *mk_alias_tbl( char *InFile )
The function mk_alias_tbl( ) creates the MIB alias table using the in-memory MIB table and the MIB alias file, InFile. The name and location of the MIB alias file should parallel the scheme described in the showmib(1) manual page. The in-memory MIB table must be created by recreate_mib( ) before the MIB alias table can be created with mk_alias_tbl( ).
The hash table for accessing the MIB alias table is named ALIAS_NODE *AliasHashTbl[HASH_SIZE]. Entries in the MIB alias table hash table point to linked lists of type ALIAS_NODE which in turn point to linked lists of type POID_NODE. The MIB alias table should be accessed using the function alias_lookup( ). Mk_alias_tbl( ) returns TRUE if successful and FALSE if unsuccessful. fIMk_alias_tbl( ) is contained in the file mib_als_blder.c ALIAS_NODE *alias_lookup( STRING Alias )
The function alias_lookup( ) returns a pointer of type ALIAS_NODE associated with the alias Alias. Alias_lookup( ) requires Alias to be a NULL terminated string containing one of the aliases appearing in the MIB alias file. If alias_lookup( ) is not successful, a NULL pointer is returned. Alias_lookup( ) is contained in the file als_parse.y.
void *stringIdLookup( STRING ObjectId )
The function stringIdLookup( ) returns a void pointer to the MIB table entry associated with the Object Id, ObjectId. StringIdLookup( ) requires ObjectId to be a NULL terminated string containing a textual Object Id (eg,_isoorg_dod_internet_mgmt_mib_system_sysUpTime). If stringIdLookup( ) is not successful, a NULL pointer is returned. StringIdLookup( ) is contained in the fileals_parse.y.
void *numericIdLookup(STRING ObjectId )
The function numericIdLookup( ) returns a void pointer to the MIB table entry associated with the Object Id, ObjectId. NumericIdLookup( ) requires ObjectId to be a NULL terminated string containing a numeric Object Id (eg, 43.6.1.2.1.1.3). If numericIdLookup
( ) is not successful, a NULL pointer is returned. NumericIdLookup( ) is contained in the file als_parse.y.
int get_first_alias( ALIAS_LOCATION *WhatAlias)
The function get_first_alias( ) finds the first valid alias entry in the MIB alias table. The user of get_first_alias( ) must allocate a data structure of type ALIAS_LOCATION and pass a pointer to the structure as an argument to the function. If an alias is found in the MIB alias table, get_first_alias( ) returns TRUE and a pointer to an alias node structure (ALIAS_NODE) can be found in WhatAlias->alias. If no alias is found, get_first_alias
( ) returns FALSE and all fields in the ALIAS_LOCATION structure are assigned NULL. Get_first_alias( ) is contained in the file mib_als_blder.c. The data structures ALIAS_LOCATIONand ALIAS_NODE can be found in the file als.h.
int get_next_alias( ALIAS_LOCATION *WhatAlias)
The function get_next_alias( ) finds the next valid alias entry in the MIB alias table. The user of fIget_next_alias( ) must have previously allocate a data structure of type ALIAS_LOCATION and called get_first_alias( ) to initialize the structure. Get_next_alias( ) id passed a pointer to the structure as an argument to the function. If an alias is found in the MIB alias table, get_next_alias( ) returns TRUE and a pointer to an alias node structure (ALIAS_NODE) can be found in WhatAlias->alias. If no additional aliases are found, get_next_alias( ) returns FALSE and all fields in the ALIAS_LOCATION structure are assigned NULL. Get_next_alias( ) is contained in the file mib_als_blder.c. The data structures ALIAS_LOCATION and ALIAS_NODE can be found in the file als.h.
als_loc2name (ALIAS_LOCATION *WhatAlias)
The function als_loc2name( ) returns a pointer of type STRING to the alias name contained in an ALIAS_NODE structure contained in an ALIAS_LOCATION structure. If a NULL pointer is passed to als_loc2name( ) or if the ALIAS_NODE pointer contained in ALIAS_LOCATION is found to be NULL, als_loc2name( ) returns a NULL STRING. This function is intended for use in conjunction with the functions get_first_alias( ) and get_next_alias( ). Als_loc2name( ) is contained in the file mib_als_blder.c. The data structure ALIAS_LOCATION can be found in the file als.h.
als_loc2type (ALIAS_LOCATION *WhatAlias)
The function als_loc2type( ) returns the ASN.1 variable type of the first object id associated with the ALIAS_NODE structure contained in the ALIAS_LOCATION structure. If the variable type cannot be obtained, -1 is returned. This function is intended for use in con junction with the functions get_first_alias( ) and get_next_alias( ). Als_loc2type( ) is contained in the file mib_als_blder.c. The data structure ALIAS_LOCATION can be found in the file als.h.
Alias2Name (ALIAS_NODE *WhatAlias)
Returns a pointer to alias name given an ALIAS_NODE struct. The function Alias2Name
( ) returns a pointer of type STRING to the alias name contained in an ALIAS_NODE structure. If a NULL pointer is passed to Alias2Name( ) a NULL STRING is returned. Alias2Name( ) is contained in the file mib_als_blder.c. The data structure ALIAS_NODE can be found in the file als.h.
Alias2Type( ALIAS_NODE *WhatAlias)
The function Alias2Type( ) returns the ASN.1 variable type of the first object id associated with the ALIAS_NODE structure. If the variable type cannot be obtained, -1 is returned. Alias2Type( ) is contained in the file mib_als_blder.c. The data structure ALIAS_NODE can be found in the file als.h.
int Alias2ProType (ALIAS_NODE *WhatAlias)
The function Alias2ProType returns the protocol type of the first object id associated with the ALIAS_NODE structure. If the protocol type cannot be obtained, -1 is returned. Alias2ProType( ) is contained in the file mib_als_blder.c. The data structure ALIAS_NODE can be found in the file als.h.
void *Alias2MibNode (ALIAS_NODE *WhatAlias)
Returns a void pointer to the MIB node of the first object id. The function Alias2MibNode returns a void pointer to the MIB node of the first object id associated with the ALIAS_NODE structure. Currently, the MIB node is of type SNMPNODE, but a void pointer is returned to allow future compatibility with other management protocols. If the MIB node cannot be obtained, a NULL pointer is returned. Alias2MibNode( ) is contained in the file mib_als_blder.c. The data structure ALIAS_NODE can be found in the file als.h.
mibbld (1), showmib (1), mibaliases (5).
mibbld - check syntax of one or more ASN.1 format MIB file and builds a binary format combined MIB file.
mibbld [ -f MibFile | -p PathToMibs] [ -o OutMib] [ -w 0|1|2 ] [ -t ]
Mibbld checks the contents of one or more ASN.1 format Management Information Base (MIB) file for syntax errors and creates a binary format MIB usable by the NetCentral Network Management System. The textual MIB files must be written in the ASN.1 subset format described in RFC-1065, RFC-1066 and ISO-8824. Although it is not possible to completely discuss the ASN.1 language there, major features of MIB files are discussed.
A MIB is organized into a tree structure consisting of labeled nodes. A complete Object Identifier is built by traversing the tree from the root node, collecting labels as each node is passed. For SNMP purposes, the root of the MIB tree is iso(1).
Except for the MIB tree root (iso(1)), all nodes in the tree must have the parent node defined before a child node may be defined. Upper level nodes (those above mib(1) ) may be most conveniently defined with the statement: MibName { iso org(3) dod(6) internet(1) mgmt(2) 1 }
The MibName is an arbitrary name. The numbers in parentheses are pre-assigned node numbers. The above statement reads: mgmt is the beginning of a subtree (called MibName) under internet which is under dod which is under org which is under iso.
Additional subtrees below mgmt may be defined using OBJECT IDENTIFIER statements as follows. ChildNode OBJECT IDENTIFIER ::= { ParentNode ChildNodeNumber }
For example: mib OBJECT IDENTIFIER ::= { mgmt 1 }
defines the MIB object type as a child of mgmt with a node number of 1. "In order to facilitate the use of tools for processing the definition of the MIB the OBJECT-TYPE macro may be used." [Rose] Most object type in a MIB should be defined using the OBJECT-TYPE macro. The basic format of an object type using the OBJECT-TYPE macro is as follows:
ObjectDescriptor OBJECT-TYPE
SYNTAX ASN1_Type
ACCESS AccessType
STATUS StatusType
::= ObjectIdentifier
For example:
atNetAddress OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-write
STATUS mandatory
::= { atEntry 2 }
Mibbld will issue warning and error messages regarding syntax errors, bad keywords, etc. For this reason it is wise to run with the warning level set to 1 or greater (see OPTIONS below).
For a complete discussion of the structure of a MIB file see RFC-1065 and RFC-1066. The ISO document 8824 describes ASN.1 in painful detail, but is less useful in modifying existing and creating new MIB MIB trees in each MIB file must be fully qualified, i.e. MIB trees must define the parentage of every branch from terminal object IDs to the iso(1) tree root. This also implies, all trees must have the same root (iso(1) is the recommended root). If this were not done, there would be no means of determining how one MIB tree relates to another.
| -f Mib File | Process the single MIB file specified by file name (path name) MibFile. |
| -p | PathToMibs |
| -o OutMib | Name of binary format output MIB file. |
| -w WarnLevel | Set the warning message level at the level specified by WarnLevel. A level of 0 suppresses all warning messages (including "unknown variable type", which are desir- able). A warning level of 2 is semi-picky. The default is 1. |
| -t | Print MIB table after processing. |
| -h | Prints this information (help). |
If you execute mibbld with no arguments, mibbld looks for the environment variables NMSROOT and MIBDIR (see ENVIRONMENT).
| NMSROOT | Defines the root directory for all Network Management System (NMS) software. |
| MIBDIR | Defines the directory below the NMS root directory which contains one or more MIB files. |
If MIBDIR is not defined, the MIB directory defaults to $NMSROOT/etc/mibs. If a full path to the MIB directory, or a MIB file name is specified using the -p or -f options, NMSROOT and MIBDIR are ignored.
If a binary output MIB file is not specified, the base name of the output MIB file defaults to mib.bin. The directory in which the output file appears is determined as follows:
M. Rose, K. McCloghrie; Structure and Identification of Management Information for TCP/IP-based Internets; RFC 1065 TWG, August 1988.
K. McCloghrie, M. Rose; Management Information Base for Net work Management of TCP/IP-based Internets; RFC 1066, TWG, August 1988.
J. Case, M. Fedor, M. Schoffstall, C. Davin; A Simple Network Management Protocol (SNMP); RFC 1067, Univ. of Tenn., NYSERNet, Rensselaer Poly, MIT LCS, April 1989.
Information processing system - Open System Interconnection; Specification of Abstract Syntax Notation One (ASN.1); International Organization for Standardization, Interna-tional Standard 8824, December 1987.
The line number specified in some warning and error messages may refer to the line following the line actually containing the error.
mibck - check syntax of ASN.1 format MIB file
mibck [ -f MibFile | -p PathToMibs] [ -w 0|1|2 ] [ -t ]
Mibck checks the contents of an ASN.1 format Management Information Base (MIB) file for syntax errors. MIB files must be written in the ASN.1 subset format described in RFC-1065, RFC-1066 and ISO-8824. Although it is not possible to completely discuss the ASN.1 language there, major features of MIB files are discussed.
A MIB is organized into a tree structure consisting of labeled nodes. A complete Object Identifier is built by traversing the tree from the root node, collecting labels as each node is passed. For SNMP purposes, the root of the MIB tree is iso(1).
Except for the MIB tree root (iso(1)), all nodes in the tree must have the parent node defined before a child node may be defined. Upper level nodes (those above mib(1) ) may be most conveniently defined with the statement: MibName { iso org(3) dod(6) internet(1) mgmt(2) 1 }
The MibName is an arbitrary name. The numbers in parentheses are preassigned node numbers. The above statement reads: mgmt is the beginning of a subtree (called MibName) under internet which is under dod which is under org which is under iso.
Additional subtrees below mgmt may be defined using OBJECT IDENTIFIER statements as follows. ChildNode OBJECT IDENTIFIER::= { ParentNode ChildNodeNumber }
For example:
mib OBJECT IDENTIFIER ::= { mgmt 1 }
Defines the mib object type as a child of mgmt with a node number of 1.
"In order to facilitate the use of tools for processing the definition of the MIB, the OBJECT-TYPE macro may be used." [Rose] Most object types in a MIB should be defined using the OBJECT-TYPE macro. The basic format of an object type using the OBJECT-TYPE macro is as follows:
ObjectDescriptor OBJECT-TYPE
SYNTAX ASN1_Type
ACCESS AccessType
STATUS StatusType
::= ObjectIdentifier
For example: atNetAddress OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-write
STATUS mandatory
::= { atEntry 2 }
Mibck will issue warning and error messages regarding syntax errors, bad keywords, etc. For this reason it is wise to run with the warning level set to 1 or greater (see OPTIONS below).
For a complete discussion of the structure of a MIB file see RFC-1065 and RFC-1066. The ISO document 8824 describes ASN.1 in painful detail, but is less useful in modifying existing and creating new MIBs.
| -f Mib File | Process the single MIB file specified by file name (path name) MibFile. |
| -p | PathToMibs. Process all MIB files found in the directory specified by path name PathToMibs. The ENVIRONMENT variables NMSROOT and MIBDIR are ignored. |
| -w WarnLevel | Set the warning message level at the level specified by WarnLevel. A level of 0 suppresses all warning messages (including "unknown variable type", which are desirable). A warning level of 2 is semi-picky. The default is 1. |
| -t | Print MIB table after processing. |
| -h | Prints this information (help). |
If you execute mibck with no arguments, mibck looks for the environment variables NMSROOT and MIBDIR (see ENVIRONMENT below).
| NMSROOT | Defines the root directory for all Network Management System (NMS) software. |
| MIBDIR | Defines the directory below the NMS root directory which contains one or more MIB files.If MIBDIR is not defined, the MIB directory defaults to $NMSROOT/etc/mibs.If a full path to the MIB directory or MIB file name is specified using the -p or-f options, NMSROOT and MIBDIR are ignored. |
M. Rose, K. McCloghrie; Structure and Identification of Management Information for TCP/IP-based Internets; RFC 1065, TWG, August 1988.
K. McCloghrie, M. Rose; Management Information Base for Net work Management of TCP/IP-based Internets; RFC 1066, TWG, August 1988.
J. Case, M. Fedor, M. Schoffstall, C. Davin; A Simple Network Management Protocol (SNMP); RFC 1067, Univ. of Tenn., NYSERNet, Rensselaer Poly, MIT LCS, April 1989.
Information processing system - Open System Interconnection; Specification of Abstract Syntax Notation One (ASN.1); International Organization for Standardization, Interna- tional Standard 8824, December 1987.
The line number specified in some warning and error messages may refer to the line following the line actually containing the error.
move_nms.sh - Bourne shell script to move nms to a different server
move_nms.sh
move_nms.sh creates a dump device on both servers, creates nms on the destination server, and then dumps nms on the source server and loads it on the destination server. For complete information on move_nms.sh, use the command sysman move_nms.sh.
nmadmin - CiscoWorks Security Management
nmadmin [ -v ]
Nmadmin is an application which manages the CiscoWorks user authentication and activities logging. There are three windows, the applications window (the main window), the users and groups window, and the permissions window. Under options of each window, you will see a Summary command to bring up the summary window. The summary window shows the status summary of the current window.
In the applications window, you can turn on and off of the privilege checking for each application. Fox example, when users first install CiscoWorks, none of the privilege checking is turned on. You should be able to run any application with asking for login.
In the users and groups window, you can add, delete and modify users, groups, and user/group assignment.
In the permissions window, you can assign the read/write permissions per security attribute to each group.
-v Give version information
nmsanms(1)
nmconfman - CiscoWorks Device Configuration Management
nmconfman [ -v ]
Nmconfman is a CiscoWorks application which can dynamically access the configuration parameters of the local and remote Cisco Systems devices in network and analyze or alter them as necessary.
The main control window for Configuration Management displays the devices known to the Configuration Management program and the various files associated with each device as well as the function buttons used for control while in the configuration management function.
Devices recognized by Configuration Management are those in the database Devices table. If a device is not listed, check the Devices tables using the Devices Management under SNM Tools menu.
Devices known to the CiscoWorks software are listed in the Device Names scroll window on the left side of the window. When a device name in the left window is selected by clicking on it with the left mouse button, the list of configuration script files associated with that device are listed in the Configurations Versions scroll window. If no configuration script files have been stored, or if no device name has been highlighted the Configurations Versions scroll window will be blank.
The maximum size of a single device configuration script is 64K characters. The number of configurations that can be stored in the database depends only on how much of available disk memory CiscoWorks allocates to database functions.
-v Give version information
nmdevman(1)
nmcontacts - CiscoWorks Contacts
nmcontacts [ -s ] [ -v ] <device>
Nmcontacts shows the user the person(s) who is responsible for a device. For each person, nmcontacts shows their name, address, phone number and electronic mail address.
Contacts are setup through the use of the CiscoWorks Device Management application. Each device can have a unique set of contacts.
Nmcontacts can be run from the SunNet Manager menu on a Cisco Systems device Tools Menu as "Contacts."
-s Print output to stdout only.
-v Print out version information.
snm(1), nmdevman(1)
nmdevman ---CiscoWorks Device Management
The CiscoWorks Device Management window provides access to the Admins, Devices, Lines, Locations, Networks, People and Vendors database forms.
The menus appearing in the Device Management window are described below:
| File Menu | The following commands are available from the File menu: Print Command To print the form, select the file menu and pull down to the Print command option. The Snapshot application will appear. Consult your SunOS Deskset Reference Guide for information on how to use Snapshot. |
| Version Command | To display the current version of the NetCentral software running on your system, select the file menu and pull down to the Version command option. You can also press Control-V(^V). Click on OK to close the window. |
| Quit Command | To exit the Form window, select the file Menu and pull down to the Quit command option. You can also press Control-Q (^Q). Activating Quit returns you to the Network Management menu. |
Forms Menu
The Forms Menu provides another way of accessing the database forms. To launch a form, click the right mouse button over the Forms menu and pull down to select the form desired. Then release the button. The form will appear.
Security Menu
The following commands are available from the Security menu:
DATABASE FORMS
The following database forms can be accessed via the Device Management window:
MENUS FOR DATABASE FORMS
The menus appearing on the database forms are described below.
File Menu
Edit Menu
Security Menu
Help
On-line help is available by clicking on the Help button. When you select "Help" a manual style text window displays. To read through the help file, use the scroll bar on the left side of the window.
To search for a specific keyword or keywords, type the text in the search field and press the "Search Forward" or "Search Backward" button. When the first occurrence of the text is found, the text will be highlighted. To find other occurrences of this keyword, continue to click one of the search button again. To close the help window, click on the "Quit" button and you return to the form window.
nmdevmon - CiscoWorks Device Monitor
nmdevmon [ -v ]
Nmdevmon is an application that allow the user to setup whether SunNet Manager events are logged and if the monitoring of environmental and interface information are checked for each device in the CiscoWorks Database Devices table. The user can also setup the poll rate for the monitoring of information.
If a device is set to have Log Events turned on, this results in nmeventd (1) passing all events found in SunNet Manager about this device sent to the CiscoWorks Log Manager, nmlogman (1). The monitoring of environmental and interface information is performed by nmdevmond (1).
When the user selects a device in the device scroller on the right hand side of the window, the toggle buttons representing this devices current properties are shown. After selecting devices and setting the toggles to the desired results, the user must press the Apply button which writes the information to the Devices table. To activate the current settings with nmdevmond, the user should select the "Options" menu item "Activate Changes."
Nmdevmon signals Nmdevmon can be run from the SunNet Manager Console Tools menu as "Device Monitor."
-v Print out version information.
snm(1), nmeventd(1), nmlogman(1), nmdevmond(1)
nmdevmond - Cisco NetCentral Device Monitor Daemon
nmdevmond [ -d ] [ -v ] [ -l ] [ -L ]
Nmdevmond is a daemon that monitors selected devices for interface status and environmental monitor status. The device selection is done by retrieving information from Sybase database. This information may be set by using Device Monitor (nmdevmon) interface.
For interface monitoring nmdevmond checks: number of interfaces, IP addresses, subnet masks, operational status and administrative status. If any of these values change, nmdevmond will create an event.
For environmental status, nmdevmond checks: +5 volts, -5 volts, +12 volts, and -12 volts, internal and ambient temperature. If any of these values change to cause a problem, nmdevmond will create an event.
Events created by nmdevmond go to the SunNet Manager Event Log, if SNM is up and running. Otherwise, the events go to the NetCentral Log Manager.
Nmdevmond (NetCentral Device Monitor Daemon) can be started by selecting Process Manager option from Tools button under SunNet Manager Console.
-d Print out debugging information
-v Give version information
-l Use log file <filename>
-L Use redundant log file <filename>
nmproc(8), nmlogd(8), nmeventd(8), nmdevmon(8)
nmenv - CiscoWorks Environmental Monitor
nmenv [ -v ] <device> [community-string]
Nmenv gives the user a graphical representation of the environmental statistics on a Cisco Systems device. Nmenv graphically shows the +5 voltage, -5 voltage, +12 voltage,
-12 voltage, internal temperature and airflow temperature. The Cisco Systems device must have an environmental monitor board with software release 2.0 or greater. Currently, the only such device is an AGS+ router.
The polling rate for nmenv can be set by the user. Note that the environmental monitor board only updates its statistics every 60 seconds, so polling more frequently is not recommended.
Nmenv can be run from the SunNet Manager menu on a Cisco Systems device Tools Menu as "Env. Monitor."
-v Print out version information.
community-string Specify a community string, default is "public".
nmgraphs - CiscoWorks Real-Time Graphs
nmgraphs [ -v ] <device> [community-string]
DESCRIPTION Nmgraphs provides an easy to use interface to the SunNet Manager Grapher. When the user hits a button on the main window, a group of objects which give information about the desired subject are sent to the SunNet Manager Grapher. If the SunNet Manager Grapher is not running when the user starts a graph, nmgraphs starts it.
The polling rate for nmgraphs can be set by the user which is then passed onto the SunNet Manager Grapher. This polling rate determines how often the SunNet Manager Grapher will poll the device for the necessary information.
Nmgraphs automatically grays out certain buttons when run on a device that does not support the MIB objects necessary to obtain the desired results.
For information on how to manipulate graphs once they are on the screen, refer to the SunNet Manager Users Guide or the man page on snm_gr(1).
Nmgraphs can be run from the SunNet Manager menu on a Cisco Systems device Tools Menu as "Real-Time Graphs."
-v Print out version information.
community-string Specify a community string, default is "public".
snm_gr(1), snm(1).
nmhealth - CiscoWorks Health Monitor
SYNOPSIS
nmshow [ -v ] [ -D ] [ -T ] <device> [community-string]
Nmhealth provides the user with a Cisco Systems router or communication server. The health of a device is displayed in three categories: overall device information, protocol information, and interface information.
The device information, or top section, of the window for nmhealth shows the current, one minute and five minute CPU utilization for the device in a gauge. Also shown is the number of buffer misses and the total amount of free memory on the device.
The middle section of the window shows protocol information. For each protocol a gauge shows the percentage of traffic on the router for the protocol. If a protocol is not active on a router, then it is grayed out. The last section of the window shows interface information.
For each interface, a gauge shows the interface traffic utilization. If an interface is not active on a router, then it is grayed out.
Under many of the buttons within all three sections of nmhealth are menus which allow the user to go directly to graphing the information being displayed and to look at the statistics in text format. For example, under each protocol name is a menu which allows the user to graph information about the protocol. The information graphed is exactly what is graphed from the CiscoWorks Real-Time Graphs, nmgraphs(1), program. Also, the user could select to display statistics using another menu choice. The information displayed is identical to that produced by the Cisco Works Show Command, nmshow(1), program for protocol traffic information.
To gather information nmhealth polls the device. The polling rate can be set from the `Properties..." popup found under the "Options" menu. This polling rate is also used in starting the graphs from any of the menu choices.
Nmhealth can be run from the SunNet Manager menu on a Cisco Systems device Tools Menu as "Health Monitor."
nmlogd - Cisco NetCentral Centralized Log Daemon
SYNOPSIS
nmlogd [ -d ]
Nmlogd runs as a background process, gets event records from a file logged by syslogd, formats and inserts events into NetCentral Database. Also, it filters events and notifies an application whoever registers to receive a specific event.
Nmlogd parses the syslogd messages received from facility LOCAL6 and LOCAL7. Each syslogd message is one line with syslogd message format. message is embedded in the text portion of syslogd format. There are several subfields in the format. Keywords are used to identify each subfield, and commas are delimiter. The subfield order is insensitive except that the text subfield should be the last field in the message. All the subfields are optional. For example, the syslog message is:
Sep 25 15:05:13 pile syslog: event=peer-status,subtype=Peer Down, dev=gorky,netaddr =131.108.160.25,proto=SNMP
The following are the subfield keywords:
time timestamp is local time and will be converted to GMT
dev device name
event event type
subtype event subtype
subsys the name of application subsystem that sends the event
netaddr network address for the device
proto the device network protocol
text ascii text
The flag is:
-d Turn on debugging.
When nmlogd is started, it reads $TMPDIR/.nmlogdspool to get syslog files that have not processed, and parses the event message. Then, it reads /etc/syslog.conf to get the current syslog file name logged by facility LOCAL6 or LOCAL7. If there are multiple entrances for these facilities, the first occurrence in the file is the one been processing. Nmlogd parses the event message and inserts it into NetCentral database. If an event message does not follow ncslog format, the message is treated as a text subfield. Also, an application can register with nmlogd to receive the notification.
nmlogin - CiscoWorks Login Utility
SYNOPSIS
nmlogin [ -v ]
Nmlogin is a CiscoWorks utility program which registers username and password to CiscoWorks. A user will not require to login into any application until the user logs out from Cisco Works.
-v Give version information
nmlogout(1)
nmlogman - CiscoWorks Log Management
nmlogman [ -v ]
Nmlogman is a CiscoWorks application which displays log message stored in centralized log database.
The main portion of the CiscoWorks Log window is the log message browser which displays messages found in the centralized log file. Each message has 10 fields:
These fields are represented in the CiscoWorks Log window by 10 query fields and check boxes. The browser can be scrolled left and right, top and bottom.
The Delete and Delete All buttons are used to purge the unwanted messages from the centralized log file. The Hit-Count displays the entry count of the browser.
-v Give version information
nmlogd(3)
nmlogout - CiscoWorks Logout Utility
nmlogout [ -v ]
Nmlogout is a CiscoWorks utility program to remove user registration from to CiscoWorks.
For security reason, a user should logout when the user is going to be away from the CiscoWorks station.
-v Give version information.
nmlogin(1)
nmpath - CiscoWorks Path Tool
nmpath [ -v ] [ -D ] [source] [destination]
Nmpath displays an IP routing path graphically between a source and destination device. The path displayed shows the devices themselves, the interfaces involved, the media type, and the bandwidth between each device. The pictures shown for each device come directly from the local user's SunNet Manager database.
Initially, nmpath displays a window which allows the user to specify the source and destination for discovery. These values are filled in if the source and destination are on the command line. Next, another window appears which gives the user feedback as to the progress the path discovery.
Nmpath attempts to discover entire path between the source and destination via SNMP. However, if this is not possible, nmpath uses an alternative form of path discovery, somewhat similar to traceroute(1). All devices discovered using this alternative form show on the path with unknown interfaces and bandwidth designations.
Once the path has been discovered, the main window of the application appears showing the path graphically. From this main window the user can analyze the path for link utiliza- tion or error utilization via the "Analysis" menu. The "View" menu allows the user to switch between the analysis and error views. The user can setup thresholds for changing colors on the device interfaces in the views via the "Properties" popup on the "Options" menu. The "Show Text" option, if selected, will bring up a window showing text output for each analysis. The user can also set the properties of nmpath to perform continuous analysis of the path at defined polling interval.
Also through the "Options" menu the user can rediscover the path through "Re-discover Path." If a different path is found, a new graphical path window appears.
Nmpath can be run from the SunNet Manager main Tools menu or on a Cisco Systems device Tools Menu as "Path Tool."
-v Print out version information.
-D Enable debugging.
traceroute(1), snm(1)
nmpoll - NetCentral Device Polling
nmpoll [ -v ]
Nmpoll is an application that allows the user to setup MIB Object polling groups to poll selected devices at different intervals and save the data in the Sybase database. The Nmpoll application will build Polling Groups that are configured to poll a set of MIB Objects from a set of devices at different intervals. The configuration is saved in the Sybase database which is then read by a background polling daemon which performs the polling via SNMP and stores the results back into the Sybase database. The saved data is then viewed with the Polling Summary application which allows the use of the SNM Grapher to plot the data over time.
Nmpoll can be run from the SunNet Manager Console Tools menu as "Device Polling."
-v Print out version information.
snm(1), nmpolld(1), nmsummary(1).
nmproc - CiscoWorks Process Manager
nmproc [ -v ]
The Process Manager displays the status of the background processes which CiscoWorks needs in order to collect network information. The application shows whether each daemon is On/Off, and allows users to start and stop the daemons as needed. The following processes are monitored: nmeventd
"On" and "Off" toggle buttons located next to each process name show whether the process is running or not. If a process is not running, it may be started by clicking on the "On" button. Likewise, a process which is running may be stopped by clicking on the "Off" button.
-v Print out version information
nmeventd(1), nmlogd(1), dataserver(1), nmpolld(1), nmdevmond(1), syslogd(8)
nmsanms - CiscoWorks Password Security Utility
nmsanms [ -v ]
Nmsanms is a CiscoWorks utility program which will alter the default password encryption key of the CiscoWorks default account. You need to know the sybase sa account password in order to run this program. This program generates a password encryption key file named ncspwd under $NMSROOT/etc directory.
If this file ever gets removed, the $NMSROOT/etc directory owner needs to create a dummy ncspwd under $NMSROOT/etc. Set the file protection mode to be 660, then run nmsanms as usual.
-v Give version information
nmadmin(1).
nmshow - CiscoWorks Show Commands
nmshow [ -v ] <device> [community-string] [ -I interface] [ -c command ] [ -x]
Nmshow emulates many of the popular EXEC commands found on Cisco Systems devices. Some of these command can be run on any device with an SNMP agent. When the user click on a button with a command name, a new window appears containing a display showing the results.
Nmshow automatically grays out certain buttons when run on a device that does not support the MIB objects necessary to obtain the desired results. Nmshow can be run from the SunNet Manager menu on a Cisco Systems device Tools Menu as "Show Commands."
-v Print out version information.
community-string Specify a community string, default is "public."
-I Give an interface index for "Show Interface."
-c command
Specify a command for nmshow to perform automatically.
The command is one of the following strings:
"acc": execute "Show IP Accounting Checkpoint"
"arp": execute "Show IP Arp"
"att": execute "Show AppleTalk Traffic"
"att": execute "Show AppleTalk Traffic"
"buf": execute "Show Buffers"
"dnt": execute "Show DECnet Traffic"
"env": execute "Show Environment"
"int": execute "Show Interface"
"ipr": execute "Show IP Route"
"ipt": execute "Show IP Traffic"
"mix": execute "Show Traffic Mix"
"netv": execute "Show NetView"
"nvt": execute "Show Novell Traffic"
"ver": execute "Show Version"
"vnt": execute "Show VINES Traffic"
"xnt": execute "Show XNS Traffic"
-x Execute the command and put the output in an X11window, not stdout.
Standard execution on device blee.foo.com:
example% nmshow blee.foo.com public
Perform "Show IP Route" on blee.foo.com with output going to stdout:
example% nmshow blee.foo.com public -c ipr
Perform "Show Interface" on third interface of blee.foo.com with output going to an X11 window:
example% nmshow blee.foo.com public -I 3 -c int -x
nmstartup - Start DBMS server and SNMP Query daemon.
The nmstartup command needs the environment variable NMSROOT to be set to the top level directory of the NMS tree. The command will start up the Database server and if there are no errors it will then start the SNMP query daemon, nmdaemon.
Progress information is generated on standard output.
nmdaemon
nmsummary - CiscoWorks Polling Summary
nmshow [ -v ]
Polling Summary is a tool of Performance Management of CiscoWorks. It is the interface to manage poll data. A user can use Polling Summary to start, and stop polling process, and browse poll data.
Polling Summary can be run from the SunNet Manager menu on a Cisco Systems device Tools Menu as "Polling Summary."
-v Print out version information.
nmpoll(1), snm(1).
nmsync - CiscoWorks Sync w/Sybase
nmsync [ -h <device> ] | [ -v ]
Nmsync is designed to be an easy for a user to update their Sybase database Devices form with the devices in their SunNet Manager database. This is exactly like going to the CiscoWorks Device Management Devices form, adding the devices, and for each device hitting the "Initialize" button.
To perform its function, nmsync reads each device name and the associated SNMP read community string from the current SunNet Manager database. If you synchronize a device already in the Devices form, nmsync will update the device information. If the synchronization of a device fails, an error message is shown.
Nmsync can be run from the SunNet Manager Console Tools menu as "Sync w/Sybase."
-h <device> Synchronize <device> only.
-v Print out version information.
snm(1), nmdevman(1)
recover_nms.sh - Bourne shell script to recover nms
recover_nms.sh
recover_nms.sh recovers the nms database from a UNIX file system or cartridge tape. It will read $NMSROOT/etc/DBMS_backup.log to find the device used for the last backup.
For complete information on recover_nms.sh, use the command sysman recover_nms.sh.
showmib - Displays the MIB tree contained in a binary format MIB file and checks the contents of the MIB alias file against the MIB tree.
showmib [ -a AliasFile ] [ -f MibFile | -p PathToMib ] [ -s m|a ] [ -h ]
Showmib processes the contents of a binary format Management Information Base (MIB) file and displays the contents in a hierarchical tree structure starting from the tree's root.
The MIB alias file is then processed. Aliases are displayed with corresponding fully qualified Object IDs.
-a AliasFile Name of MIB alias file. See mibaliases(5) for more information on MIB
aliases.
-f MibFile Process the single MIB file specified by filename (path name) MibFile.
-p PathToMibs Process all MIB files found in the directory specified by path name
PathToMibs. The ENVIRONMENT variables NMSROOT and MIBDIR
are ignored.
-s SuppressO Suppress output as indicated by SuppressO. If SuppressO is set to m, the
output of the MIB tree is suppressed. If SuppressO is set to a, the output of
the output of aliases is suppressed.
-h Prints this information (help).
If you execute showmib with no arguments, showmib looks for the environment variables NMSROOT and MIBDIR (see ENVIRONMENT below).
NMSROOT Defines the root directory for all Network Management System (NMS)
software.
MIBDIR Defines the directory below the NMS root directory which contains one or
more MIB files.
If MIBDIR is not defined, the MIB directory defaults to $NMSROOT/etc/mibs. If a full path to the MIB directory, or a MIB file name is specified using the -p or -f options, NMSROOT and MIBDIR are ignored.
If a MIB alias file is not specified, the base name for the MIB alias file defaults to mib.alias. The directory in which the alias file is expected to appear is determined as follows:
mibbld(1), mibaliases(5).
The line number specified in some warning and error messages may refer to the line following the line actually containing the error.
shutdown.sh - Bourne shell script to gracefully shut down the SQL Server
shutdown.sh
shutdown.sh is a Bourne shell script to gracefully shutdown the SQL Server It just performs a shutdown.
For complete information on shutdown.sh, use the command sysman shutdown.sh.
tables - DBMS tables for network management.
These are the SQL commands to create the tables that the database uses. This list is intended for reference only.
create table DevConfigs (
conf_id int,
creator char(64),
time_created int,
conf_stat char(2),
user_image text NULL,
machine_image text NULL,
comments text NULL
)
go
create table DevConfHist (
device_id int,
conf_id int,
conf_ver int,
software_ver char(16)
)
go
create table DevConfFileLoc (
device_id int,
host_name varchar(254),
file_name varchar(254)
)
go
create table addresses(
address_id smallint,
street char(32),
street_two char(32) NULL,
city char(16) NULL,
state char(16) NULL,
country char(16) NULL,
zip_code char(16)
)
go
create table admin_contacts(
admin_id smallint,
people_id smallint
)
go
create table admins(
admin_id smallint,
admin_name char(32),
admin_desc char(64) NULL
)
go
create table contacts(
device_id int,
people_id smallint
)
go
create table devices(
device_id int,
device_type smallint NULL,
device_name char(32),
device_domain char(255),
device_desc char(255) NULL,
community char(32) NULL,
admin_id smallint,
serial_number char(32) NULL,
vendor_id smallint,
address_id smallint,
software_desc char(64) NULL,
software_ver char(16) NULL,
hardware_desc char(64) NULL,
hardware_ver char(16) NULL,
loaded_conf int NULL,
conf_load_time int NULL,
conf_loader char(64) NULL
)
go
create table if_addresses(
device_id int,
interface_id tinyint,
protocol_id smallint,
protocol_type smallint NULL,
protocol_addr char(64)
)
go
create table interfaces(
interface_id tinyint,
device_id int,
interface_type smallint NULL,
interface_name char(32),
interface_desc char(64) NULL,
hardware_addr char(64) NULL,
hardware_ver char(16) NULL,
line_id int
)
go
create table line_contacts(
line_id smallint,
people_id smallint
)
go
create table lines(
line_id int,
line_group_id int NULL,
line_type smallint NULL,
line_desc char(64) NULL
)
go
create table locations(
address_id smallint,
location char(64),
street char(32) NULL,
street_two char(32) NULL,
city char(16) NULL,
state char(2) NULL,
country char(16) NULL,
zip_code char(10) NULL
)
go
create table net_numbers(
net_number_id smallint,
network_id smallint,
net_type smallint NULL,
net_number char(32),
net_mask char(32) NULL
)
go
create table networks(
network_id smallint,
network_name char(32),
admin_id smallint
)
go
create table people(
people_id smallint,
address_id smallint,
last_name char(16),
first_name char(16),
middle_name char(16) NULL,
phone_number char(16) NULL,
email_addr char(64) NULL,
title char(32) NULL,
nic_id char(8) NULL
)
go
create table polls(
table_id smallint,
device_id int,
if_index smallint
)
go
create table grouptemplate(
timestamp datetime,
device_id int,
if_index tinyint,
sysUpTime int,
)
go
create table vendor_contacts(
vendor_id smallint,
people_id smallint
)
go
create table vendors(
vendor_id smallint,
vendor_nam char(32),
street char(32),
street_two char(32) NULL,
city char(16) NULL,
state char(16) NULL,
country char(16) NULL,
zip_code char(16)
)
go
tcpdump - dump traffic on an ethernet
tcpdump [ -c count ] [ -e ] [ -f ] [ -h ] [ -H ] [ -i inter face] [ -l ] [ -n ] [ -p ] [ -q ]
[ -s snaplen ] [ -t ] [ -x ] [ -F MibFile | -P PathToMibs] [ expression ]
Tcpdump prints out the headers of packets on the ethernet that match the boolean expression. You must be root to invoke tcpdump or it must be installed setuid to root.
-c Exit after receiving count packets.
-e Print the ethernet header (source, destination, protocol and
length) on each dump line.
-f Print foreign internet addresses numerically rather than symbolically
(this option is intended to get around serious brain damage in Sun's yp
server - usually it hangs forever translating non-local internet
numbers).
-F MibFile Process the single MIB file specified by file name (path name) MibFile.
-h Prints help information.
-H Prints SNMP packet in hex in addition to the normal output.
-i Listen on interface. If no -i flag is given, the tcpdump tries to listen on
le0 then ie0 if there is no le0.
-l Make stdout line buffered. Useful if you want to see the data while
capturing it. E.g., "tcpdump -l | tee dat" or "tcpdump -l > dat &
tail -f dat".
-n Don't convert host addresses and port numbers to names.
-p Don't put the interface into promiscuous mode (i.e., tcpdump will see
only broadcast packets and packets destined for this machine).
-P PathToMibs Process all MIB files found in the directory specified by
path name PathToMibs. The ENVIRONMENT variables
NMSROOT and MIBDIR are ignored.
-q Quick (quiet?) output. Print less protocol information so output lines
are shorter.
-s snarf snaplen bytes of data from each packet rather than the default 96.
96 bytes is adequate for IP, ICMP, TCP and UDP but may truncate
protocol information from name server, NFS, and SNMP packets
(see below). Note that taking larger snapshots both increases the
amount of time it takes to process packets and, effectively, decreases
the amount of packet buffering. This may cause packets to be lost. You
should limit snaplen to the smallest number that will capture the
protocol information you're interested in.
-t Don't print a timestamp on each dump line.
-x Print each packet (minus its 14 byte ethernet header) in hex. Up to 64
bytes of the packet are printed.
expression Selects which packets will be dumped. If no expression is given, all
packets on the net will be dumped. Otherwise, only packets for which
expression is true will be dumped. The syntax of expression is
similar to that used by find(1) and etherfind(8c).
The primaries may be combined using the following operators (in order of decreasing precedence): A parenthesized group of primaries and operators (parentheses are special to the Shell and must be escaped). Negation (`!' or `not'). Concatenation (`and' or juxtaposition). Alternation (`or').
To print all packets arriving at or departing from sundown:
tcpdump host sundown
To print all traffic between local hosts and hosts at Berkeley:
tcpdump net ucb-ether
To print all ftp traffic through internet gateway snup (note that the expression is quoted to prevent the shell from (mis-)interpreting the parens):
tcpdump `gateway snup and ( port ftp or port ftp-data )'
To print traffic neither sourced from nor destined for local hosts (if you gateway to one other net, this stuff should never make it onto your local net):
tcpdump ip and not ne localnet
SNMP SUPPORT SNMP packets can be evaluated and printed by specifying the SNMP UDP port on the command line. tcpdump port snmp Tcpdump accepts and buffers the first 96 bytes of each packet by default. Although, this value is adequate for many functions of tcpdump, SNMP packets frequently require much larger buffers. Insufficiently large buffers will result in a parsing error of the packet. In this case, a parsing error message will be generated and a hex dump of the packet will take place. A buffer size of 512 bytes seems to accommodate most SNMP packets. The buffer size can be specified using the -s option.
tcpdump -s 512 port snmp
Excessively large buffers may result in the loss of packets.
Tcpdump must be able to locate one or more MIB files.
Tcpdump attempts to locate the MIB file(s) through the ENVIRONMENT variables NMSROOT and MIBDIR (see below). The -F or -P options can be used to specify an individual MIB file or an alternate path to the MIB file directory, respectively.
If a MIB file directory is specified through either the NMSROOT/MIBDIR pair or through the -P option, tcpdump will process all files found in the directory as MIB files.
NMSROOT Defines the root directory for all Network Management System (NMS)
software.
MIBDIR Defines the directory below the NMS root directory which contains one
or more MIB files.
If MIBDIR is not defined, the MIB directory defaults to $NMSROOT/etc/mibs. If a full path to the MIB directory or MIB file name is specified using the -P or -F options, NMSROOT and MIBDIR are ignored.
The output of tcpdump is protocol dependent. The following gives a brief description and examples of most of the formats.
Arp/rarp output shows the type of request and its arguments. The format is intended to be self explanatory. Here is a short sample taken from the start of an `rlogin' from host rtsg to host csam:
arp who-has csam tell rtsg
arp reply csam is-at CSAM
The first line says that rtsg sent an arp packet asking for the ethernet address of internet host csam. Csam replies with its ethernet address (in this example, ethernet addresses are in caps and internet addresses in lower case).
This would look less redundant if we had done tcpdump -n:
arp who-has 128.3.254.6 tell 128.3.254.68
arp reply 128.3.254.6 is-at 02:07:01:00:01:c4
If we had done tcpdump -e, the fact that the first packet is broadcast and the second is point-to-point would be visible:
RTSG Broadcast 0806 64: arp who-has csam tell rtsg
CSAM RTSG 0806 64: ARP reply csam is-at CSAM
For the first packet this says the ethernet source address is RTSG, the destination is the broadcast address, the type field contained hex 0806 (type ETHER_ARP) and the total length was 64 bytes.
(N.B.:The following description assumes familiarity with the TCP protocol described in RFC-793. If you are not familiar with the protocol, neither this description nor tcpdump will be of much use to you.)
The general format of a tcp protocol line is:
src > dst: flags data-seqno ack window urgent options
Src and dst are the source and destination IP addresses and ports. Flags are some combination of S (SYN), F (FIN), P (PUSH) or R (RST) or a single `.' (no flags). Data-seqno describes the portion of sequence space covered by the data in this packet (see example below). Ack is sequence number of the next data expected the other direction on this connection.
Window is the number of bytes of receive buffer space available the other direction on this connection. Urg indicates there is `urgent' data in the packet. Options are tcp options enclosed in angle brackets (e.g., <mss 1024>).
Src, dst and flags are always present. The other fields depend on the contents of the packet's tcp protocol header and are output only if appropriate.
Here is the opening portion of an rlogin from host rtsg to host csam.
rtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>
csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
rtsg.1023 > csam.login: . ack 1 win 4096
rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096
csam.login > rtsg.1023: . ack 2 win 4096
rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096
csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077
csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1
csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1
The first line says that tcp port 1023 on rtsg sent a packet to port login on csam. The S indicates that the SYN flag was set. The packet sequence number was 768512 and it con- tained no data. (The notation is first:last(nbytes) which means sequence numbers first up to but not including last which is nbytes bytes of user data.) There was no piggy- backed ack, the available receive window was 4096 bytes and there was a max-segment-size option requesting an mss of 1024 bytes.
Csam replies with a similar packet except it includes a piggy-backed ack for rtsg's SYN. Rtsg then acks csam's SYN. The . means no flags were set. The packet contained no data so there is no data sequence number. Note that the ack sequence number is a small integer (1). The first time tcpdump sees a tcp conversation, it prints the sequence number from the packet. On subsequent packets of the conversation, the difference between the current packet's sequence number and this initial sequence number is printed. This means that sequence numbers after the first can be interpreted as relative byte positions in the conversation's data stream (with the first data byte each direction being 1).
On the 6th line, rtsg sends csam 19 bytes of data (bytes 2 through 20 in the rtsg -> csam side of the conversation). The PUSH flag is set in the packet. On the 7th line, csam says it's received data sent by rtsg up to but not including byte 21. Most of this data is apparently sitting in the socket buffer since chasms receive window has gotten 19 bytes smaller. Csam also sends one byte of data to rtsg in this packet. On the 8th and 9th lines, csam sends two bytes of urgent, pushed data to rtsg.
UDP format is illustrated by this rwho packet:
actinide.who > broadcast.who: udp 84
This says that port who on host actinide sent a udp datagram to port who on host broadcast, the Internet broadcast address. The packet contained 84 bytes of user data.
Some UDP services are recognized (from the source or destination port number) and the higher level protocol information printed. In particular, Domain Name service requests (RFC-1034/1035) and Sun RPC calls (RFC-1050) to NFS.
(N.B.:The following description assumes familiarity with the Domain Service protocol described in RFC-1035. If you are not familiar with the protocol, the following description will appear to be written in greek.)
Name server requests are formatted as:
src > dst: id op? flags qtype qclass name (len)
h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)
Host h2opolo asked the domain server on helios for an address record (qtype=A) associated with the name ucbvax.berkeley.edu.
The query id was 3. The + indicates the recursion desired flag was set. The query length was 37 bytes, not including the UDP and IP protocol headers. The query operation was the normal one, Query, so the op field was omitted. If the op had been anything else, it would have been printed between the 3 and the +. Similarly, the qclass was the normal one, C_IN, and omitted. Any other qclass would have been printed immediately after the A.
A few anomalies are checked and may result in extra fields enclosed in square brackets: If a query contains an answer, name server or authority section, ancount, nscount, or arcount are printed as [na], [nn] or [nau] where n is the appropriate count. If any of the response bits are set (AA, RA or rcode) or any of the must be zero bits are set in bytes two and three, [b2&3=x] is printed, where x is the hex value of header bytes two and three.
Name server responses are formatted as:
src > dst: id op rcode flags a/n/au type class data (len)
helios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273) helios.domain >
h2opolo.1537: 2 NXDomain* 0/1/0 (97)
In the first example, helios responds to query id 3 from h2opolo with 3 answer records, 3 name server records and 7 authority records. The first answer record is type A (address) and its data is internet address 128.32.137.3. The total size of the response was 273 bytes, excluding UDP and IP headers. The op (Query) and response code (NoError) were omitted, as was the class (C_IN) of the A record.
In the second example, helios responds to query 2 with a response code of non-existent domain (NXDomain) with no answers, one name server and no authority records. The * indicates that the authoritive answer bit was set. Since there were no answers, no type, class or data were printed.
Other flag characters that might appear are - (recursion available, RA, not set) and | (truncated message, TC, set). If the question section doesn't contain exactly one entry, [nq] is printed.
Note that name server requests and responses tend to be large and the default snaplen of 96 bytes may not capture enough of the packet to print. Use the -s flag to increase the snaplen if you need to seriously investigate name server traffic. -s 128 has worked well for me.
Sun NFS (Network File System) requests and replies are printed as:
src.xid > dst.nfs: len op args
src.nfs > dst.xid: reply stat len
vs.e2766 > helios.nfs: 136 readdir fh 6.5197 8192 bytes @ 0
helios.nfs > vs.e2766: reply ok 384
vs.e2767 > helios.nfs: 136 lookup fh 6.5197 RCS.
In the first line, host vs sends a transaction with id e2766 to helios (note that the number following the src host is a transaction id, not the source port). The request was 136 bytes, excluding the UDP and IP headers. The operation was a readdir (read directory) on file handle (fh) 6.5197. 8192 bytes are read, starting at offset 0. Helios replies `ok' with 384 bytes of data. (The design of Sun's RPC protocol makes it difficult to interpret replies. I don't bother.)
In the third line, vs asks helios to lookup the name RCS in directory file 6.5197. Note that the data printed depends on the operation type. The format is intended to be self explanatory (at least, to me) if read in conjunction with an NFS protocol spec.
Note that NFS requests are very large and the above won't be printed unless snaplen is increased. I use -s 192 to watch NFS traffic.
Appletalk DDP packets encapsulated in UDP datagrams are de-encapsulated and dumped as DDP packets (i.e., all the UDP header information is discarded). The file /etc/atalk.names is used to translate appletalk net and node numbers to names. Lines in this file have the form
number name
1.254 ether
16.1 icsd-net
1.254.110 ace
The first two lines give the names of appletalk networks. The third line gives the name of a particular host (a host is distinguished from a net by the 3rd octet in the number - a net number must have two octets and a host number must have three octets.) The number and name should be separated by whitespace (blanks or tabs). The /etc/atalk.names file may contain blank lines or comment lines (lines starting with a `#').
Appletalk addresses are printed in the form:
net.host.port
144.1.209.2 > icsd-net.112.220
office.2 > icsd-net.112.220
jssmag.149.235 > icsd-net.2
(If the /etc/atalk.names doesn't exist or doesn't contain an entry for some appletalk host/net number, addresses are printed in numeric form.) In the first example, NBP (DDP port 2) on net 144.1 node 209 is sending to whatever is listening on port 220 of net icsd node 112. The second line is the same except the full name of the source node is known (`office'). The third line is a send from port 235 on net jssmag node 149 to broadcast on the icsd-net NBP port (note that the broadcast address (255) is indicated by a net name with no host number - for this reason it's a good idea to keep node names and net names distinct in /etc/atalk.names). NBP (name binding protocol) and ATP (Appletalk transaction protocol) packets have their contents interpreted. Other protocols just dump the protocol name (or number if no name is registered for the protocol) and packet size.
NBP packets are formatted like the following examples:
icsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*"
jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250
techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 1 86
The first line is a name lookup request for laserwriters sent by net icsd host 112 and broadcast on net jssmag. The nbp id for the lookup is 190. The second line shows a reply for this request (note that it has the same id) from host jssmag.209 saying that it has a laserwriter resource named RM1140 registered on port 250. The third line is another reply to the same request saying host techpit has laser-writer techpit registered on port 186. ATP packet formatting is demonstrated by the following example:
jssmag.209.165 > helios.132: atp-req 12266<0-7> 0xae030001
helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000
jssmag.209.165 > helios.132: atp-req 12266<3,5> 0xae030001
helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000
helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000
jssmag.209.165 > helios.132: atp-rel 12266<0-7> 0xae030001
jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002
Jssmag.209 initiates transaction id 12266 with host helios by requesting up to 8 packets (the `<0-7>'). The hex number at the end of the line is the value of the userdata field in the request.
Helios responds with 8 512-byte packets. The `:digit' following the transaction id gives the packet sequence number in the transaction and the number in parens is the amount of data in the packet, excluding the atp header. The `*' on packet 7 indicates that the EOM bit was set.
Jssmag.209 then requests that packets 3 & 5 be retransmitted. Helios resends them then jssmag.209 releases the transaction. Finally, jssmag.209 initiates the next request. The `*' on the request indicates that XO (exactly once) was not set.
Fragmented Internet datagrams are printed as
(frag id:size@offset+)
(frag id:size@offset)
(The first form indicates there are more fragments. The second indicates this is the last fragment.)
Id is the fragment id (in hex). Size is the fragment size (in bytes) excluding the IP header. Offset is this fragment's offset (in bytes) in the original datagram.
The fragment information is output for each fragment. The first fragment contains the higher level protocol header and the frag info is printed after the protocol info. Fragments after the first contain no higher level protocol header and the frag info is printed after the source and destination addresses. For example, here is part of an ftp from arizona.edu to lbl-rtsg.arpa over a CSNET connection that doesn't appear to handle 576 byte datagrams:
arizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 59 5a:328@0+)
arizona > rtsg: (frag 595a:204@328)
rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560
There are a couple of things to note here: First, addresses in the 2nd line don't include port numbers. This is because the TCP protocol information is all in the first fragment and we have no idea what the port or sequence numbers are when we print the later fragments. Second, the tcp sequence information in the first line is printed as if there were 308 bytes of user data when, in fact, there are 512 bytes (308 in the first frag and 204 in the second). If you are looking for holes in the sequence space or trying to match up acks with packets, this can fool you.
A packet with the IP don't fragment flag is marked with a trailing (DF).
Timestamps By default, all output lines are preceded by a timestamp. The timestamp is the current clock time in the form hh:mm:ss.frac and is as accurate as the kernel's clock (e.g., +^H_10ms on a Sun-3). The timestamp reflects the time the kernel first saw the packet. No attempt is made to account for the time lag between when the ethernet interface removed the packet from the wire and when the kernel serviced the new packet interrupt (of course, with Sun's lousy clock resolution this time lag is negligible.)
The printing of each SNMP packet begins with a line indicating the time and, source and destination of the packet:
Time Source > Destination
For example:
14:00:17.08 131.119.25.22 > bigsys.hugecomp.com
The next line begins with a Protocol Data Unit (PDU) type (e.g., GetResponse) followed by the: version number, community name, request ID, error status, and error index. For example:
GetResponse ver=0, public, Req_id=20415, no error, E_indx=0
The remainder of the packet output is made up of a sequence of VarBind (a VarBind consists of an object name followed by associated data). Object names are printed as fully qualified OBJECT DESCRIPTORs including object instances. The data associated with the object name is printed below the object name. The actual data is preceded by the SYNTAX type and number of octets encoding the data enclosed in square braces. An example of a VarBind for the system up-time might appear as:
_isoorg_dod_internet_mgmt_mib_system_sysUpTime_0:
[TimeTicks,5] 18266
If the -H option is used, the SNMP packet is displayed in hex following the textual representation of the packet.
traffic(1C), mibck(1C), nit(4P)
M. Rose, K. McCloghrie; Structure and Identification of Management Information for TCP/IP-based Internets; RFC 1065, TWG, August 1988.
K. McCloghrie, M. Rose; Management Information Base for Network Management of TCP/IP-based Internets; RFC 1066, TWG, August 1988.
J. Case, M. Fedor, M. Schoffstall, C. Davin; A Simple Network Management Protocol (SNMP); RFC 1067, Univ. of Tenn., NYSERNet, Rensselaer Poly, MIT LCS, April 1989.
AUTHORS Van Jacobson (van@helios.ee.lbl.gov), Craig Leres
(leres@helios.ee.lbl.gov) and SteveMcCanne (mccanne@helio s.ee.lbl.gov), all of Lawrence Berkeley Laboratory, University of California, Berkeley, CA. Addition of SNMP support, Michael Fredrich (fredrich@cisco.com) of cisco Systems Inc., Menlo Park, CA.
The clock resolution on a Sun is pathetic (20ms). If you want to use the timestamp to generate some of the important performance distributions (like packet interarrival time) it's best to watch something that generates packets slowly (like an Arpanet gateway or a MicroVax running VMS).
Nit doesn't let you watch your own outbound traffic. (We are in the process of debugging a replacement for NIT.)
The packet filter code is not what you'd call efficient. Don't plan on doing much with your Sun while you're monitoring a busy network. On Sun systems prior to release 3.2, NIT is very buggy. If run on an old system, tcpdump may crash the machine.
IP options are ignored. They should be printed.
Some attempt should be made to reassemble IP fragments or, at least to compute the right length for the higher level protocol.
The expression syntax is baroque. The original author of find should have investigated the wonders of yacc. (We are in the process of fixing this.)
Name server inverse queries are not dumped correctly: The (empty) question section is printed rather than real query in the answer section. Some believe that inverse queries are themselves a bug and prefer to fix the program generating them rather than tcpdump.
Apple Ethertalk DDP packets could be dumped as easily as KIP DDP packets but aren't. Even if we were inclined to do anything to promote the use of Ethertalk (we aren't), LBL doesn't allow Ethertalk on any of its networks so we'd would have no way of testing this code.
When analyzing SNMP packets, an insufficiently large buffer size will result in a parsing error of the packet and a hex dump of the packet will take place. A buffer size of 512 bytes seems to accommodate most SNMP packets. The buffer size can be specified using the -s option. A hex dump of an SNMP packet will take place if the packet cannot be parsed regardless of the buffer size.
|
Copyright 1988-1995 © Cisco Systems Inc.