1.1. Introduction This supplemental document describes the installation procedure for the Windows-based SNMP agent software accompanying the MultiCommManager and how it can be utilized from an SNMP management node. In actuality, the installation of the SNMP agent software also involves the installation of Windows-based TCP/IP communication software. 1.2 Installation The installation of the SNMP agent software accompanying the MultiCommManager is accomplished by inserting the diskette labeled "NEWT" and typing :install. The installation of the agent software can be done either before or after the installation of the MultiCommManager. Refer to chapters 2 and 3 of "NEWT TCP/IP for Windows Installation and User’s Guide" for details concerning NEWT installation procedures. Note: If the machine being targeted for installation is currently running TCP/IP software other than NEWT, it must first be de-installed before installing the NEWT diskette. 1.3 MultiCommManager as an SNMP Agent The effects of the MultiCommManager’s ability to act as an SNMP agent are entirely transparent on the agent node. The only indication that it is acting in such a capacity is the appearance of the NEWT icon which represents the presence of the NEWT TCP/IP kernel. Refer to chapter 6 of "NEWT TCP/IP for Windows Installation and User’s Guide" for a description of the information available when double-clicking on this icon. 1.4 Remote Rack Management Capabilities The key to remote management of SNMP agent nodes in a TCP/IP network environment lies in the definition of a Management Information Base (MIB) for the agent. This MIB must be defined on the SNMP management node and is used access, manage and convey fault/status information on the agent node. The MIB must be minimally comprised of the standard MIB, known as MIB-II. Additional enterprise-specific MIBs may also be defined to allow for more specific remote management capabilities. Accompanying the MultiCommManager software is the source definition of an enterprise-specific MIB which defines not only the information which may be remotely retrieved and managed, but also the traps which can be sent to the management node from the MultiCommManager. Traps are the mechanisms used in this environment to convey fault and status information as they occur on the agent node. The filename of the MultiCommManager-specific MIB is named multi1.mib . The appropriate MIB must be copied to the SNMP management node and compiled into a machine-readable form using a MIB compiler on that node. The information defined in the MultiCommManager-specific MIB can be broken down into six major components. The first component consists of system-wide information. The next four components consist of tables used to store information specific to racks, modems, configuration files and callback security respectively. The last component consists of all trap definitions along with corresponding control variables which allow the enabling and disabling of each trap. The following sub-sections give a more detailed look at each of these components and how they may be used to perform remote management. System-wide Information This grouping of scalar fields includes information such as the software version of the executing MultiCommManager, the percentage of free disk space on your machine, the percentage of free disk space at which a low memory warning is issued and the percentage of free disk space at which event logging is disabled (if enabled). The first two of the aforementioned fields are read-only, while the last two are read-write. Also maintained in this group is information pertinent to the initiating and terminating of what will be termed "remote management sessions". A remote management session must be initiated in order to acquire write access privileges within the MultiCommManager. Without this privilege SNMP management stations will be unable to perform management functions (e.g., resetting racks/modems, configuring modems, etc.) as they will only be afforded read access privileges on MIB data. Refer to section 1.5 in this document for details on how to initiate and terminate these sessions. The Rack Table The rack table consists of four read-only fields and one writeable field. The read-only fields are used to describe the rack’s configuration (e.g., whether a rack is on-line, the status of its power supplies, etc.). The writable field is used solely to perform management actions upon the rack. Currently, the only action which is allowed upon a rack is to reset it. The result of this operation is identical to resetting it via the Reset Controller option in the MultiCommManager's Control Menu. The Modem Tables Information specific to individual modems is represented in two tables and an additional scalar field as described below. THE GENERAL MODEM TABLE The general modem table consists of several fields which describe its current configuration. The first four fields are read-only and are used to describe the a given modem’s location in the current rack configuration. Another read-only field is defined to describe the modem’s current status (e.g., not installed, on line, free, etc.). There are six writable fields also included. The first five allow for the retrieval and setting of information concerning a modem’s type (dial up, lease line, etc.), security mode (inbound, outbound, etc.), operation mode (synchronous, asynchronous), lease line mode (answer, originate) and configuration file (which must be an existing .cfg file). The sixth field is once again used solely to perform management actions upon a modem. These actions are described below with their corresponding operations within the MultiCommManager in parenthesis. * Toggling a modem in and out of service (OOS option in the Control Menu). * Hanging up a modem (Hangup Modem option in the Control Menu). * Resetting a modem (Reset Modem option in the Control Menu). * Performing various modem tests (Test Modem option in the Control Menu). * Configuring a modem using the modem’s currently designated configuration file (Load Configuration option in the Control Menu). * Configuring a modem as described above and saving the configuration in the modem’s RAM. THE CALL TRAFFIC TABLE This table is not accessible to SNMP manager get and set operations. It exists solely to define the information which is to accompany call traffic status traps. The information included in this table is identical to the information found in the MultiCommManager's Call Traffic Window. THE CALL TRAFFIC ENABLE/DISABLE FIELD This field is used to toggle the enabling/disabling of the agent to send call traffic traps to the SNMP management node. Upon startup of the MultiCommManager, the sending of these traps will be disabled. The enabling of these traps is cautioned for systems with high call traffic as the number of traps sent could possibly overload the network. The Configuration File Table This table primarily consists of a list of configuration files (.cfg) which may be used to configure a particular modem or set of modems. The Callback Security Table This table consists of five read-only fields of which the last four fields display the identical information found in the callback queue window. The first field is simply introduced as an index field to allow for easy access to each table entry. Fault and Status Traps The type of fault and status traps sent to the SNMP management node from the MultiCommManager can be grouped into three categories: 1. Traps corresponding to faults and statuses as currently tracked in the Fault and Status Window. 2. Traps corresponding to call traffic events as currently tracked in the Call Traffic Window. 3. Traps which provide supplemental error information whenever select SNMP management actions fail. Most traps may be enabled or disabled on an individual basis. Also included in the MIB are aggregate variables which allow for quick enabling/disabling of a logical group of traps (for instance all status traps, fault traps or call traffic traps). Upon startup of the MultiCommManager the sending of trap information defaults as follows: - Call traffic traps will be disabled. The enabling of these traps is cautioned for systems with high call traffic as the number of traps sent could possibly overload the network. - All other traps are enabled. 1.5 Usage Examples The purpose of this section is to supply examples of certain remote functions from SNMP management nodes. This is done in an effort to show how the MultiCommManager MIB can be used to perform various remote management tasks. Note that the specifics on how to perform the get and set operations on the management node depend upon the SNMP management software in use on that node. Refer to your SNMP management manual for details on how to perform these operations. Initiating a Remote Management Session As mentioned earlier, a remote management session must be initiated if an SNMP management station wishes to modify MIB data (and thus perform management functions against the MultiCommManager). To determine if a such a session is currently open, perform a get operation on the sysAccessLevel.0 variable in the mmmSystem group. If the value returned is "read", then a session is not open. To initiate a remote management session perform a set operation on the sysMgmtSession.0 variable in the mmmSystem group with the following string value: LOGIN where at least one blank space separates the keyword LOGIN and the password which you supply. Note that the keyword LOGIN is case- insensitive while the password is case-sensitive. To verify that session initiation was successful perform another get operation on sysAccessLevel.0. Its value should now be "read-write". The password supplied must match the system password of the MultiModemManager. This password is new for release 3.0 and defaults to PUBLIC upon installation. It may be changed within the MultiCommManager via the System Password option in the Setup menu. Terminating a Remote Management Session To terminate a remote management session (and thus return to read-only mode) perform a set operation on sysMgmtSession.0 with the following string value: LOGOUT where once again the keyword LOGOUT is case-insensitive. To verify that termination was successful perform a get operation on sysAccessLevel.0. Its value should now be "read". Setting a Modem Out-Of-Service (OOS) To remotely set a modem out-of-service simply perform a set operation against the modemAction.r.s.m column instance in the modem table (where r is the rack number 1-254, s is the slot number 1-16 and m is the modem number 1-3) with a value of set_oos. Verification of this operation’s success can be achieved by issuing a get operation against the modemStatus.r.s.m column instance (with r, s and m being identical to those values used in the set operation). The returned value should be oos. To return the modem back in service simply issue a set operation against the modemAction.r.s.m column instance with a value of clear_oos. Resetting a Modem To remotely reset a modem simply perform a set operation against the modemAction.r.s.m column instance in the modem table with a value of reset. The result of this operation will be identical to the Reset Modem option in the MultiCommManager’s control menu. Configuring a Modem This example actually consists of two parts; setting a configuration file for a given modem and configuring the modem with the specified file. To set a configuration file for a modem: Issue a set operation against the modemConfigFile.r.s.m column instance in the modem table with the value being the file name of the new configuration file. This file name must be an existing configuration file created through the MultiCommManager’s configuration manager on the remote node. A list of all such files can be obtained by remotely fetching all configFileName column values from the configuration table. Do not include the path name on the set operation as this will be automatically determined on the remote node. To configure the modem: Issue a set operation against the modemAction.r.s.m column instance of the modem table (with the values of r, s and m being identical to the prior operation) with a value of configure (or configure_and_store_in_memory if you wish the configuration to be saved in the modem’s RAM). Viewing the Callback Security Queue This is simply done by issuing get operations against the columns of the callback table. Beware that since this queue is dynamically changing, it may be possible to have retrieved a column instance for a given queue entry only to have that entry disappear when attempting to retrieve a different column instance on that entry (although this problem can be avoided if the SNMP management software is able to perform row by row retrieval). Viewing Fault and Status Information Since fault and status information is sent to the SNMP management node in the form of traps, this information can only be viewed where the SNMP management software displays trap information, typically in some sort of log file or trap window. The information accompanying the trap includes a brief description (a more detailed description can be obtained by looking at the trap definition in the MultiCommManager MIB) and either the rack number, slot number or modem location associated with the fault/status depending on the nature of the trap. As mentioned earlier, the MIB definition is designed to allow the SNMP management station control over the sending of most fault and status traps by the MultiCommManager. In order to disable a specific trap simply perform a set operation on the desired trap in the trap control section of the MIB with a value of 0 (disabled). The trap can later be enabled by performing a set with a value of 1 (enabled). Viewing Call Traffic Information Once again the MultiCommManager sends this information to the SNMP management node in the form of traps. However, the sending of these traps is initially disabled upon MultiCommManager startup. This is a precautionary measure owed to the fact that a potentially high number of call traffic traps being sent could overload a network. If this is not the case for your given application and you wish to view these traps, then perform a set operation upon the mmmCallTrafficTraps scalar variable in the trapControl group with a value of enable. Look for a log file or trap window in the SNMP management software which contains the subsequent call traffic trap information. The information accompanying these traps includes a brief description followed by values for all the columns defined in the call traffic table. Setting the Event Logging Threshold This example is concerned with disabling the event logging feature upon reaching a specified threshold of available memory. To determine the current threshold for your remote MultiCommManager system perform a get operation on the sysEventLogging.0 variable instance in the mmmSystem group. The value shown here is the minimum free disk space percentage in which event logging will still take place. To change this value simply replace the value with your desired value and perform a set operation upon the sysEventLogging variable. Resetting a Rack Controller This example illustrates how to remotely reset a rack controller. The result of this operation will be identical to performing the Reset Controller option in the MultiCommManager’s control menu. The operation itself consists of performing a set operation against the rackAction.r column instance in the rack table (where r represents the rack number 1-254 upon which the operation is to be performed) with a value of reset.