SNMPXMON2(1) — NEWS-OS Programmer’s Manual

NAME

snmpxmon2 − SNMP graphical network monitor version 2

SYNOPSIS

snmpxmon2 configfile options

DESCRIPTION

snmpxmon2 is a more sophisticated descendant of the snmpxmon application. It is a graphical application based on X Windows Version 11 and the Simple Network Management Protocol. snmpxmon2 will determine the status of the network entities it is configured to monitor by querying the designated entities and the displaying information on the status of those entities. snmpxmon2 views the world as a collection of managed networks, each with members consisting of manageable network entities (routers, hosts etc.). The relationship between networks and primitive entities (manageable network entities) is many-many: a network has many primitive entities as members, and any given primitive entity may be a member of multiple networks. Serial links in snmpxmon2 are represented as two half-links, each emanating from the primitive entity that is at that endpoint of the serial link. Connections to LANs and RINGs consist of a single link from the primitive entity to the LAN/RING. The snmpxmon2 application consists of three processes: a display process to manage the snmpxmon2 display, a poller process to gather information on primitive entities, and a trap-acceptor process to receive SNMP traps. Each process will perform logging of internal activity to a separate log file (location configured by user). The snmpxmon2 display process is responsible for managing the snmpxmon2 display(s), and accepting user input. The snmpxmon2 poller process is responsible for gathering network management information by polling managed entities. The poller process will start out polling managed entities at a predetermined (user-configurable) interval with the SNMP. In the event that a response is not received from a managed entity, the poller process will decrease the polling interval for that managed entity, increasing the rate at which the non-responding entity is polled. A (user-settable) minimum polling interval is used to limit the amount of system and network resources consumed by adjusting the polling interval downwards. In the event that a (user-configurable) threshold is exceeded in the number of attempts made to contact a non-responding entity via SNMP, snmpxmon2 will back-down and attempt to contact the non-responding entity with the use of ICMP Echos. Once it is established that an entity may be contacted via ICMP Echos, snmpxmon2 will revert to attempting to gather network management information via the SNMP. The trap-acceptor process is responsible for accepting SNMP traps from managed entities. The trap-acceptor process will log all traps received to a (user-configurable) logfile in a format identical to that of the snmptrapd application. In addition, the trap-acceptor process will update the status of primitive entities based on link status (LinkUp, LinkDown) traps received.

Using X Resources

Snmpxmon2 reads the command line arguments, then passes through the users $HOME/.Xdefaults file and creates a local resource database. Any command line option will take precedence over the .Xdefaults parameter. Here are a list of all settable snmpxmon2 parameters in .Xdefaults format, the values given are the default values if nothing is specified:

snmpxmon2.display:1:0.0
snmpxmon2.font:6x10
snmpxmon2.geometry:NULL (as big as font dictates)
snmpxmon2.borderwidth:2
snmpxmon2.name:snmpxmon2
snmpxmon2.reverseVideo:off
snmpxmon2.color:on
snmpxmon2.background:NavyBlue
snmpxmon2.foreground:white
snmpxmon2.bordercolor:red
snmpxmon2.upcolor:green
snmpxmon2.downcolor:red
snmpxmon2.unknowncolor:yellow
snmpxmon2.icmpcolor:grey
snmpxmon2.pnbordercolor:khaki
snmpxmon2.status:on
snmpxmon2.bell:on
snmpxmon2.pulse:on
snmpxmon2:term:xterm
snmpxmon2:pingTerm:xterm
snmpxmon2:telnetTerm:xterm
snmpxmon2:helpTerm:xterm
snmpxmon2:snmplookupTerm:xterm
snmpxmon2:helpTerm:xterm
snmpxmon2:snmpSrcTerm:xterm
snmpxmon2:traceRouteTerm:xterm
snmpxmon2:trapTerm:xterm
snmpxmon2:logTerm:xterm

THE SNMPXMON2 CONFIGURATION FILE

The snmpxmon2 configuration file is the primary means of configuring the snmpxmon2 application. All keywords in the file are case insensitive. Parameters occurring after the keywords, however, are case sensitive. Comments are denoted by a ’#’ preceded either by white space or by the beginning of the line, and followed immediately by white space (ie., ’# ’ with ’#’ in column 1, or ’ # ’ -- this is necessary to allow the embedding of ’#’ in parameters) and end with the end of the line. Note that ’#’ alone does not denote the beginning of a comment. Names of any type (Network name, primitive entity name, community name etc.) must begin with a letter of the alphabet and may not contain white space. IP addresses must be specified as a dotted quad. Specifying only the network or local portion of an IP address is illegal. The snmpxmon2 configuration file will accept the following options:

(1)PRIMENT
Syntax: PRIMENT name { icmponly | pcomm [tcomm] } if1 if2 if3 ...

PRIMENT name if1 if2 if3 ...

Define the existence of a primitive entity name in the configuration, without classifying it further as either an End System or an Intermediate System. The entity name has interfaces if1, if2, if3 ... which may be specified as either IP addresses or as interface numbers preceded by ’#’ (eg: ’#1’ is interface 1). IP addresses and interface numbers may be freely mixed on a line. Note however that some of the features of snmpxmon2 (backing down to ICMP, trap acceptance) are dependent on IP addresses. Although the application will work (insofar SNMP polling and display) in a limited fashion, it is most highly recommended that the IP address of an interface be used to specify it, if there is an IP address associated with the interface at all. All interfaces of the primitive entity that are to be used in displaying network connectivity must be defined as part of the entity’s definition (ie., they must occur on the PRIMENT line). Since interfaces that aren’t used for displaying network connectivity are ignored by snmpxmon2 for display purposes, it is recommended that all interfaces of a network entity be defined when the entity itself is defined.

It is possible in the specification of a PRIMENT to specify that the entity is to be polled with ICMP only, by use of the ’icmponly’ flag (this is case sensitive) to replace the SNMP polling community (’icmponly’ will not be accepted by snmpxmon2 as a legal community). If the PRIMENT being specified may be polled by either SNMP or ICMP, a community tcomm may be specified in addition to the SNMP polling community pcomm. Omission of the optional trap community will result in snmpxmon2 accepting and processing any trap sent by a configured network entity, regardless of community. All primitive entities must be defined before any networks (WANs, LANs, RINGs) or serial links (SLINKs).

(2)ISENT
ISENT name if1 if2 if3 ...
Defines a primitive network entity to be an Intermediate System specifically. At present, there is no difference between an ISENT and a PRIMENT.

(3)
ESENT name if1 if2 if3 ....
Defines a primitive network entity to be an End System specifically. ESENTs are displayed differently (on a reverse video rectangle) than are ISENTs and PRIMENTs in the snmpxmon2 display.

(4)WAN
Syntax: WAN name priment1 x1 y1 netent3 x3 y3 priment3 if3
Defines a Wide Area Network consisting of a number of primitive entities, together with peers (peer networks) that the WAN being defined connects to. The WAN being defined has name ’name’ which occurs as the first parameter on the line. Parameters on a WAN line can be: the name of a primitive entity that is a member of a network (eg: priment1), followed by the coordinates used for displaying the primitive entity in question (eg: x1 y1); or the name of a peer network (eg: netent3) followed by the coordinates (eg: x3 y3) to be used for displaying the peer network in relation to the WAN being defined, followed by the name of the gateway to the peer network (priment3), together with the interface of the gateway (if3) that connects the network to its peer. The gateway to the peer network (priment3) must have been defined previously as a member of the network.

(5)LAN
Syntax: LAN name xl1 yl1 xl2 yl2 ent1 x1 y1 if1 net3 x3 y3 priment3 if3
Defines a Local Area Network consisting of a number of primitive entities, together with peers (peer networks) that the LAN being defined connects to. The LAN being defined has name ’name’ which occurs as the first parameter on the line. The next four parameters (xl1 yl1 xl2 yl2) define the location of the LAN on the display. Parameters on a LAN line (apart from the first 5) can be: the name of a primitive entity that is a member of a network (eg: priment1), followed by the coordinates used for displaying the primitive entity in question (eg: x1 y1), followed by the specification of the interface connecting the primitive entity to the LAN (if1); or the name of a peer network (eg: netent3) followed by the coordinates (eg: x3 y3) to be used for displaying the peer network in relation to the LAN being defined, followed by the name of the gateway to the peer network (priment3), together with the interface of the gateway (if3) that connects the network to its peer. The gateway to the peer network (priment3) must have been defined previously as a member of the network.

(6)RING
Syntax: RING name xr yr rd ent1 x1 y1 if1 net3 x3 y3 priment3 if3
Defines a Ring type LAN consisting of a number of primitive entities, together with peers (peer networks) that the RING being defined connects to. The RING being defined has name ’name’ which occurs as the first parameter on the line. The next three parameters (xr yr rd) respectively define the coordinates of the center and the diameter of the ring. Parameters on a RING line (apart from the first 5) can be: the name of a primitive entity that is a member of a network (eg: priment1), followed by the coordinates used for displaying the primitive entity in question (eg: x1 y1), followed by the specification of the interface connecting the primitive entity to the RING (if1); or the name of a peer network (eg: netent3) followed by the coordinates (eg: x3 y3) to be used for displaying the peer network in relation to the RING being defined, followed by the name of the gateway to the peer network (priment3), together with the interface of the gateway (if3) that connects the network to its peer. The gateway to the peer network (priment3) must have been defined previously as a member of the network.

(7)SLINK
Syntax: SLINK priment1 if1 priment2 if2
Defines a serial link between two primitive entities priment1, and priment2. The interfaces of the primitive entities at the endpoints of the serial links are respectively if1 and if2. SLINK definitions must occur after all primitive entities are defined, and before any network definitions (WAN, LAN and RING definitions).

(8)INTERVAL
Syntax: INTERVAL intvl
Defines the global polling interval (in seconds) to be used for polling primitive entities in the snmpxmon2 configuration.

(9)LOG
Syntax: LOG logfile loglevel
Defines the logfile and level at which activity logging occurs. Logging occurs at level loglevel , one of state-changes (1), network-activity (2), additional-information (3), exceptions (4) (specify the number for loglevel, and not the character string). loglevel n implies logging at levels 1 , 2 .. n.

(10)TRAPFILE
Syntax: TRAPFILE logfile
Defines the file logfile as the location to which traps received by snmpxmon2 are logged. The format of log entries is the same as in snmptrapd.

(11)ROUTECF
Syntax: ROUTECF configfile
Defines the configuration file to be used by the snmpxrtmetric application when it is invoked from a menu.

(12)OPTIONS
Syntax: OPTIONS opt1 opt2 -opt3 ....
Defines that certain options should be toggled on or off in the display configuration. Prepending a ’-’ to an option negates that option. Legal options are: bell: ring bell on state changes; status: display status line showing last state change. Duplication of option definitions will overwrite earlier definitions.

(13)MINPOLL
Syntax: MINPOLL intvl
Defines the minimum allowable interval for the polling of primitive entities in seconds.

(14)MAXSNMPPOLL
Syntax: MAXSNMPPOLL num
Defines the maximum number of attempts to be made to poll a primitive entity with SNMP before backing down to ICMP. After num times, the polling process will back down to using ICMP Echos to poll a primitive entity until such a time as information is received from the entity.

(15)TOPLEVEL
Syntax: TOPLEVEL netent
Designates a particular network netent defined previously in a LAN, WAN or RING definition as the ’toplevel’ network that occupies the window initially opened by snmpxmon2 upon startup. Duplicate TOPLEVEL definitions will overwrite earlier ones. The TOPLEVEL specification must occur after all networks are defined.

SNMPXMON2 MENUS

snmpxmon2 has two different menus, the General Operations Menu for invoking general commands that are not site specific, and a Command Menu for invoking site specific commands. The General Operations Menu makes the following selections available:

(1)traceroute invokes the traceroute command. A dialog box will pop up to prompt the user for the destination which the traceroute is to be performed to. Needless to say, this selection only works if traceroute is actually installed on the system on which snmpxmon2 is running.

(2)View traps: View the trap log. If there is no trap log configured into the application, a dialog box will pop up to prompt for the location of the trap log. Specifying a spurious trap log will result in nothing happening.

(3)View log: View the application activity log. If the application knows of no activity log, a dialog box will pop up asking the user to specify an activity log to be viewed.

(4)Help: Invokes the man page (this document) for snmpxmon2. The Command Menu allows the invocation of commands on a per-site basis. Commands selected from the command menu are invoked with an IP address from the list of IP addresses associated by the application with the site clicked on. The following selections are available from the Command Menu:

(1)Ping: Invokes the ping program against the site clicked on.

(2)Shell: Opens up a remote shell on the site clicked on.

(3)Snmpsrc: Invokes the snmpsrc program from the site clicked on. A dialog box will pop up to prompt the user for the destination net for the snmpsrc invocation.

(4)Snmplookup: Invokes the snmplookup application against the site clicked on.

(5)Snmpxrtmetric: Invokes the snmpxrtmetric application against the site clicked on. If the application does not know the location of the snmpxrtmetric configuration file, the user will be prompted by means of a dialog box.

(6)Snmpxperfmon: Invokes the snmpxperfmon application against the site clicked on. Note that the selections available from the two menus are only usable if the commands to be executed are on the search path of the user. Hence it is important that the commands available from the snmpxmon2 menus actually be installed on the system, and actually be on the search path of the user of snmpxmon2.

BUGS

snmpxmon2 will go into a state where all polled entities alternate between the UNKNOWN state, and the state where polling is done with ICMP Echoes if the global polling interval or the minimum polling interval is set too low. This is due to the application having too little time (as a result of the intervals being set too low) to complete an SNMP poll, resulting in a back-down to ICMP occurring immediately. As a general guideline, 1 second should be allocated in the polling interval for every network entity to be polled (ie., if 50 sites are being polled, neither the global or the minimum polling interval should be < 50s). Writing configration-file is painful since we recommnd to use the command xmon2cfg(1) which is a X-window based drawing tool for configration file.

FILES

configfileconfiguration file

Museum