WESTERN-MULTIPLEX-MIB: View SNMP OID List / Download MIB

This persistent variable contains the primary serial number of this System.

A table that identifies hardware components with embedded software within the system. If a system has no entries, then the system is assumed to be comprised only of the primary processing unit (where the SNMP Agent resides). Each row of this table is identified by its index, the combined 'compIDSerialNum' and 'compIDType'.

A row of the compIDTable that represents a single hardware component of the system.

This persistent variable contains the serial number of the component. If the component has no serial number, then the variable has the value ''.

This persistent variable contains the type of the component as evidence by name and part number. Enumeration: 'unknown': 1, 'service-channel-unit-50500': 6, 'network-management-unit-50900': 7, 'transmitter-pa-50301': 4, 'mux-50200': 2, 'transmitter-50300': 3, 'receiver-50400': 5.

This variable contains the location of the component within the system. 'unknown' indicates that the location is not known. 'integral' indicates that the component is located at the only location possible for that type of component within this system. 'removed' indicates that the component has been removed, and has not been replaced. An Agent implementation may choose to just remove the row if the component has been removed. 'side-a' indicates that this component is located on side A. 'side-b' indicates that this component is located on side B. Enumeration: 'unknown': 1, 'removed': 3, 'integral': 2, 'side-a': 10, 'side-b': 11.

This non-persistent variable contains the current state of the component. 'removed' indicates that the component has been removed, and has not been replaced. An Agent implementation may choose to just remove the row if the component has been removed. 'unknown' indicates that the component's state is not known. 'normal' indicates that the component is operating normally and has no reported abnormal conditions. 'abnormal' indicates that the component is operating abnormally as determined by one or more reported abnormal conditions. 'force-reset' is the only value that the user can SET this variable to. When a user sets the variable to 'force-reset', and the system supports the operation, then the component is reset, and this variable will be internally set to 'unknown', until the component has performed initialization. At that time the component state may be updated. Setting this variable to any value other than 'force-reset' will return an error. Enumeration: 'unknown': 2, 'removed': 1, 'abnormal': 4, 'force-reset': 10, 'normal': 3.

This variable contains the current date and time of the primary real time clock of the system. The format is MM/DD/YYYY HH:MM where: MM/DD/YYYY: is the month/day/year HH:MM is the hours:minutes in military time (hours from 00-23). The user may SET the date, time, or date and time. This time is assumed to represent the local time at the physical site of the system. However, an installation may set the date and time relative to another reference, such as Greenwich England (for Universal Time Clock) as desired.

This persistent variable can be used by a Network Administrator to record the local time zone, time offset or day light savings time information. This information is not used by the system to adjust it real time clock. The maximum size of this string is 31 characters. Input characters will be parsed for printable ASCII characters, any characters outside of this set will be removed without an error condition. Special characters such as punctuation, numbers, braces, square boxes, underbars, etc. are allowed if the character has a value between 32 ( ' ') and 126 ( '~') decimal inclusive. Blanks are considered valid. The default value is a .

Setting this non-persistent variable to 'force-reset' allows an SNMP user to force the platform to reboot. Setting this variable to 'normal' has no effect. 'normal' will always be returned on a 'get' of this variable. Enumeration: 'force-reset': 10, 'normal': 1.

This non-persistent variable contains a date and timestamp of the platform's Real Time Clock at the time of the most recent boot of the platform. The format is MM/DD/YYYY HH:MM where: MM/DD/YYYY: is the month/day/year HH:MM is the hours:minutes in military time (hours from 00-23).

This persistent variable contains a date and timestamp of the platform's Real Time Clock at the time of the platform boot of the system just prior to the most recent boot of the platform. The format is MM/DD/YYYY HH:MM where: MM/DD/YYYY: is the month/day/year HH:MM is the hours:minutes in military time (hours from 00-23).

This persistent variable contains the number of platform reboots since the date specified in 'bootClearDate'. A value of '0', indicates that this counter was reset by the writing of 'bootClearDate', since the time that this platform was last rebooted, as specified by 'bootDate'.

The SNMP user writing any value to this persistent variable, causes any input to be ignored, and the current date and time to be written to this variable. In addition, the variable 'bootRebootCount' will be cleared to '0'. This variable provides a historical record that indicates when 'bootClearDate' was last cleared. The format is MM/DD/YYYY HH:MM where: MM/DD/YYYY: is the month/day/year HH:MM is the hours:minutes in military time (hours from 00-23).

This persistent variable indicates the maximum size of the system event log. Some Western Multiplex platforms allow this variable to be modified, such that the new size will be used either immediately or when the system next resets. Other platforms do not allow this variable to be set, and return 'ReadOnly' to SNMP set operations. The non-persistent system event log is a circular history or log of system events. Events are added to the log depending upon replacement rules and controlling filter variables. New log entries may replace existing log entries when the log contains 'logMaxSize' records. In some cases, the new entry will not be added, because the governing rules require more important log events to be retained.

This non-persistent variable indicates the current number of the system event log records. The non-persistent system event log is a circular history or log of system events. Events are added to the log depending upon replacement rules and controlling filter variables. The system log is created as an empty log whenever the platform resets.

This non-persistent variable increments every time a system event is added to the system log. It has an initial value of 0. When a log record is created or replaced, the 'logIndexNumber' is incremented, then stored within the new log record's 'logRecIndexNumber'. Thus the log record with a 'logRecIndexNumber' of 1 is the first system event that was placed into the log.

This non-persistent variable indicates the current health of the Network Management Unit, or NMU, System as determined by the contents of the system log. This variable indicates the highest severity level of any system log record that has a 'health' qualifier, but no 'Radio' qualifier. Records that do not have a 'health' qualifier do not effect this variable. Records that have been 'NORMALIZED' (see the definition in 'logRecDescription') do not effect this variable. 'critical-health' is the highest severity level, followed in decreasing order by 'major-health', 'minor-health', 'warning-health', and 'normal-health', which is the lowest 'health' severity level. If this variable has a value of 'normal-health', then either there are no records that effect health in the system log, or the only health effecting records (not qualified by 'Radio') have a severity level of 'normal-health'. Enumeration: 'warning-health': 2, 'minor-health': 3, 'normal-health': 1, 'major-health': 4, 'critical-health': 5.

This non-persistent variable indicates the current health of the attached managed Radio system as determined by the contents of the system log. This variable indicates the highest severity level of any system log record that has a 'health' and 'radio' qualifiers. Records that do not have a 'health' and a 'radio' qualifier do not effect this variable. Records that have been 'NORMALIZED' (see the definition in 'logRecDescription') do not effect this variable. 'critical-health' is the highest severity level, followed in decreasing order by 'major-health', 'minor-health', 'warning-health', and 'normal-health', which is the lowest 'health' severity level. If this variable has a value of 'normal-health', then either there are no records that effect health and are qualified by 'Radio' in the system log, or the only health effecting records qualified by 'radio' have a severity level of 'normal-health'. Enumeration: 'warning-health': 2, 'minor-health': 3, 'normal-health': 1, 'major-health': 4, 'critical-health': 5.

This persistent variable indicates the desired severity level for adding a system event to the log based upon a severity level. This control variable thus acts as a severity level filter. This only applied to system events that DO NOT effect health. Health effecting events are always added to the system log. 'critical' is the highest severity level, followed in decreasing order by 'major', 'minor', 'warning', and 'normal', which is the lowest severity level. Specifying a severity level with this variable indicates that log events of that level and higher and log events not controlled by a severity filter will be considered for addition to the system log. These events will be added, unless the log is full ( 'logCurrentSize' equals 'logMaxSize') and replacement rules do not allow the event to be added. Replacement rules only allow a new event to replace a lower severity level event or an equal severity event that is older. Setting this variable to 'critical' is the most restrictive. Only log events with a severity level of critical, or that do not use a severity level will be considered for addition, unless limited by replacement rules. Setting this variable to 'normal' allows all system events to be considered for addition, unless limited by replacement rules. The default value for this variable is 'normal'. Enumeration: 'major': 4, 'warning': 2, 'critical': 5, 'minor': 3, 'normal': 1.

This non-persistent variable counts the number of occurrences of system events that were not logged to the system log because of a specific filter that specifically disabled that event from being logged. This counter has an initial value of 0 at the platform's boot time, and cannot be reset. For example the Network Management Unit, or NMU has 16 external alarm inputs. Each of these external alarms has a controlling variable 'alarmLogControl' which filters whether alarm or normal transitions will be logged to the system log. Specific filters never effect health related events. Specific filters have the highest precedence, and are examined before any other recording filters. The other log recording filter statistics are 'logFilteredSeverity' and 'logFilteredRules'.

This non-persistent variable counts the number of occurrences of system events that where not logged to the system event log, because 'logSeverityFilter' restricted its placement into the system log. This counter has an initial value of 0 at the platform's boot time, and cannot be reset. There are two other log recording filter statistics are 'logFilteredSpecific' and 'logFilteredRules'. A system event that effects health is always added to the system log. A system event that does not effect health may not be added to the system log depending upon three possible filters. Such an event may have an associated specific log filter which is checked when that event occurs to determine if the event should be logged. If allowed by the specific filter, or if the event has no specific filter, then the event is processed by the logging sub-system. The logging sub-system then determines if the severity level of the event is important enough to require logging. This is determined by comparing the event's severity level with the variable 'logSeverityFilter'. If the level is below the acceptance criteria, the event is filtered, and not added to the log. In such a case, this variable, 'logFilteredSeverity' is incremented, and the event is ignored. Otherwise, the logging sub-system performs further checks by examinining the system log. If the log is full ('logCurrentSize' equals 'logMaxSize'), and replacement rules do not allow the event to be placed in the system log, then the event is filtered (not logged) and 'logFilteredRules' is incremented.

This non-persistent variable increments every time a system event occurs, that is not added to the system log, because of replacement rules. This counter has an initial value of 0 at the platform's boot time, and cannot be reset. The other log recording filter statistics are 'logFilteredSpecific' and 'logFilteredSeverity'. A system event that effects health is always added to the system log. A system event that does not effect health may not be added to the system log depending upon three possible filters. Such an event may have an associated specific log filter which is checked when that event occurs to determine if the event should be logged. If allowed by the specific filter, or if the event has no specific filter, then the event is processed by the logging sub-system. The logging sub-system then determines if the severity level of the event is important enough to require logging. This is determined by comparing the event's severity level with the variable 'logSeverityFilter'. If the level is below the acceptance criteria, the event is filtered, and not added to the log. In such a case, this variable, 'logFilteredSeverity' is incremented, and the event is ignored. Otherwise, the logging sub-system performs further checks by examinining the system log. If the log is full ('logCurrentSize' equals 'logMaxSize'), and replacement rules do not allow the event to be placed in the system log, then the event is filtered (not logged) and 'logFilteredRules' is incremented.

This persistent variable determines the maximum size of the 'logRecTable', as returned to an SNMP user. For system that are connected via wire-less communications it is useful to limit the bandwidth requirements of SNMP access, particularly for table accesses that can be bandwidth intensive. The range of valid values for this variable is 5 to 'logMaxSize', inclusive. Setting this variable to any value forces 'logViewPageControl' to be set to 1. The default value for this variable is 'logMaxSize'. When 'logViewPageSize' is set at any value smaller than 'logMaxSize', the 'logRecTable' may have multiple pages, depending upon how many log records are present in the log ('logCurrentSize'), and the viewing filter 'logViewSeverityFilter'. The variable 'logViewPageControl' allows the SNMP user to retrieve any of these pages. For example, if 'logMaxSize' and 'logCurrentSize' is 50, and 'logViewPageSize' is 5, then there could be effectively 10 logical pages (depending upon view filters). 'logViewEvents' indicates the number of system events that would be displayable on all pages of the 'logRecTable' given the view filtering criteria specified by the current value of 'logViewSeverityFilter'. Examining 'logViewEvents' may assist in choosing a useful value of for this variable 'logViewPageSize'. The retrieval of the 'logRecTable' is also effected by the other viewing variables, which provide sorting and filtering controls. These other variables are: 'logViewSeverityFilter', 'logViewMethod', 'logViewDirection', 'logViewAge'.

This non-persistent variable allows a user to control the present page view of the 'logRecTable'. When 'logViewPageSize' is set at any value smaller than 'logMaxSize', the 'logRecTable' may have multiple pages, depending upon how many log records are present in the log ('logCurrentSize'), and the viewing filter 'logViewSeverityFilter'. This variable 'logViewPageControl' allows the SNMP user to retrieve any of these pages. For the purpose of clarity in the description below, lets assume 'logCurrentSize' is 47, and 'logViewPageSize' is 10. With this example, there would be 5 viewable pages, identified as pages 1, 2, 3, 4, and 5. Pages 1 through 4 have 10 log records each, while page 5 has only 7 records. Setting this variable to 1 causes the first view page to be retrieved when 'logRecTable' is next read by the SNMP user. That is records 1 through 10 would be retrieved. Setting this variable to 2 causes the records 11 through 20 to be retrieved. Setting 'logViewPageControl' to 3 causes 21 through 30; 4 causes 31 through 40; and 5 causes 41 through 47 to be retrieved the next time 'logRecTable' is read. The viewing of a different page becomes a two step operation; first this variable 'logViewPageControl' is set with a value then the 'logRecTable' is read. The default value is 1. Allowable values are 1 through the value which represents the last page at any specific point in time that this variable is written. If the input value is larger than the value representing the last page, then the input is ignored (no error returned), and 'logViewPageControl' is set to the last page given the current system log and viewing filter criteria ('logViewFilter'). A input value of 0 is accepted (without error) to represent the first page. Thus a 1 is written. If at any time the current view of the system log has changed (because of the dynamic nature of the system log), such that 'logViewPageControl' is too large, then this variable will be automatically set to a new value that represents the last page. Thus the only time a 'logRecTable' is retrieve empty, is because there are no records matching the view filter criteria, not because 'logViewPageControl' indicates an invalid page. 'logViewEvents' indicates the number of system events that would be displayable on all pages of the 'logRecTable' given the view filtering criteria specified by the current value of 'logViewSeverityFilter'. Examining 'logViewEvents' may assist in choosing how a user may want to change this variable 'logViewPageControl'. The retrieval of the 'logRecTable' is also effected by the view sorting variables 'logViewMethod', 'logViewDirection', and 'logViewAge' which provide sorting criteria. (These determine the order of the the records.) Also note, that the system log is a dynamic history of events. Records may be deleted automatically because of replacement rules (new events overwriting older events), or through human interaction via SNMP, or possible a platform's console or configuration port interface. With such a situation, a user may retrieve the next or previous page, and see some or all of the same log events that where presented earlier. Similarly, the user may completely overlook a record that shifts from a logical position on a particular page during one retrieval and has moved to a different page when the next retrieval occurs. This variable is automatically given the value of 1 whenever any of the other viewing variables are modified ('logViewPageSize', and these identified below). The retrieval of the 'logRecTable' is effected by the other viewing variables, which provide sorting and filtering controls. These other variables are: 'logViewSeverityFilter', 'logViewMethod', 'logViewDirection', 'logViewAge'.

This persistent variable indicates the desired severity level or levels (and qualifiers) for viewing the 'logRecTable'. This control variable thus acts as a severity level viewing filter. 'critical' is the highest severity level, followed in decreasing order by 'major', 'minor', 'warning', and 'normal', which is the lowest severity level. These severity levels can be further qualified with an indication that the 'health' of the system is effected because of this event. In such a case, these events are indicated with the '-health' suffix ( 'critical-health', 'major-health', 'minor-health', 'warning-health', 'normal-health'). Specifying a severity level with this variable indicates that ONLY log events of that level will be available for retrieval via the 'logRecTable'. For example, if this variable was set to 'major-health', only log events with a severity level of 'major' and a health qualifier will be viewed when the 'logRecTable' is next retrieved. If this variable was set to 'warning', only log events with a severity level of 'warning' and NO health qualifier will be viewed when the 'logRecTable' is next retrieved. The values 'all', 'all-health-NORMALIZED', 'all-health-not-NORMALIZED', 'all-health', and 'all-non-health' allow a broader range of log events to be retrieved. As implied by the names, 'all' will enable the log records to be retrieved; 'all-health-NORMALIZED' allows all records qualified with a health indicator that have been NORMALIZED to be retrieved; 'all-health-not-NORMALIZED' allows all records qualified with a health indicator that have NOT been NORMALIZED to be retrieved; 'all-health' will allow any log records that effect health to be retrieved, and 'all-non-health' will allow all log records that DO NOT effect health to be retrieved. The default value is 'all'. The value of this variable, 'logViewSeverityFilter', effects 'logViewEvents' which indicates the number of log records that would be viewable by retrieving all pages of 'logRecTable' when using the filtering criteria of this variable. Setting this variable to any value forces 'logViewPageControl' to be set to 1. 'other' indicates a class of log record, rather than a severity level. The severity level of 'other' is considered less important than 'normal'. 'other' primarily is used to indicate a 'Debug' type of log record. Log records of severity level 'other' can be viewed when 'logViewSeverityFilter' is set to either 'all', or 'other'. The retrieval of the 'logRecTable' is effected by the other viewing variables, which provide sorting and page controls. These other variables are: 'logViewPageSize', 'logViewPageControl', 'logViewMethod', 'logViewDirection', 'logViewAge'. Enumeration: 'major': 4, 'all-health-NORMALIZED': 13, 'normal': 1, 'warning-health': 7, 'minor-health': 8, 'all-health-not-NORMALIZED': 14, 'all': 16, 'other': 11, 'warning': 2, 'all-non-health': 12, 'critical': 5, 'major-health': 9, 'critical-health': 10, 'all-health': 15, 'normal-health': 6, 'minor': 3.

This persistent variable determines the sort method used for retrieving the 'logRecTable'. 'chronological' allows the table to be viewed sorted by time, either oldest to newest, or vice versa, depending upon the setting of 'logViewAge'. When 'logViewMethod' is set to 'chronological', the variable 'logViewDirection', has no effect on the sorting. 'severity' allows the table to be viewed sorted by severity level, either 'critical' to 'normal', or vice versa, depending upon the setting of 'logViewDirection', and by age depending upon 'logViewAge'. The default value for this variable is 'chronological'. Setting this variable to any value forces ' logViewPageControl' to be set to 1. The retrieval of the 'logRecTable' is effected by the other viewing variables, which provide sorting, filtering and page controls. These other variables are: 'logViewPageSize', 'logViewPageControl', 'logViewSeverityFilter', 'logViewDirection', 'logViewAge'. Enumeration: 'chronological': 1, 'severity': 2.

This persistent variable determines the direction of the severity related sorting of log records used for retrieving the 'logRecTable'. 'critical-to-normal' allows the table to be viewed sorted starting with 'critical' log records first, then moving to less severe, 'major', and others, until 'normal' records are retrieved. 'normal-to-critical' allows the table to be viewed sorted starting with 'normal' log records first, then moving to move severe, 'warning', and others, until 'critical' records are retrieved. 'logViewMethod' and 'logViewDirection' also effect the viewing order of the 'logRecTable'. 'logViewMethod' determines whether the table is retrieved primarily by chronological order, or by severity order. 'logViewMethod' takes precedence over the other viewing variables. 'logViewDirection' only applies when the 'logRecTable' is viewed by severity level. In such a case, it determines whether the records are viewed from 'critical' to 'normal' or vice versa. 'logViewDirection' takes precedence over 'logViewAge'. The default value for this variable is 'critical-to-normal'. Setting this variable to any value forces 'logViewPageControl' to be set to 1. The retrieval of the 'logRecTable' is effected by the other viewing variables, which provide sorting, filtering and page controls. These other variables are: 'logViewPageSize', 'logViewPageControl', 'logViewSeverityFilter', 'logViewMethod', 'logViewAge'. Enumeration: 'normal-to-critical': 2, 'critical-to-normal': 1.

This persistent variable determines the direction of the time related sorting of log records used for retrieving the 'logRecTable'. 'oldest-to-newest' allows the table to be viewed sorted by time, returning the oldest log records first, followed by the newer. 'newest-to-oldest' allows the table to be viewed sorted by time, returning the newest log records first, followed by the older. 'logViewMethod' and 'logViewDirection' also effect the viewing order of the 'logRecTable'. 'logViewMethod' determines whether the table is retrieved primarily by chronological order, or by severity order. 'logViewMethod' takes precedence over the other viewing variables. 'logViewDirection' only applies when the 'logRecTable' is viewed by severity level. In such a case, it determines whether the records are viewed from 'critical' to 'normal' or vice versa. 'logViewDirection' takes precedence over 'logViewAge'. The default value for this variable is 'newest-to-oldest'. Setting this variable to any value forces 'logViewPageControl' to be set to 1. The retrieval of the 'logRecTable' is effected by the other viewing variables, which provide sorting, filtering and page controls. These other variables are: 'logViewPageSize', 'logViewPageControl', 'logViewSeverityFilter', 'logViewMethod', 'logViewDirection'. Enumeration: 'newest-to-oldest': 2, 'oldest-to-newest': 1.

This non-persistent variable indicates the number of system events that would be displayable on all pages of the 'logRecTable' given the view filtering criteria specified by the current value of 'logViewSeverityFilter'. This variable may be a different value than 'logCurrentSize', which indicates the total number of records in the system event log. The view paging variables 'logViewPageSize', and 'logViewPageControl' do not effect the value of this variable. The view sorting variables 'logViewMethod', 'logViewDirection', and 'logViewAge' do not effect the value of this variable. This value changes dynamically depending upon the current content of the system event log, and the view filtering variable 'logViewSeverityFilter'.

This persistent variable indicates the desired severity level or levels (and qualifiers) for the logging sub-system to generate a SNMP generic log trap, called 'logGenericTrap'. System events that are qualified as having an associated specific trap will NOT be allowed to generate a second generic trap ('logGenericTrap'), and are not considered filtered by this variable, because these events are defined by other specific traps. This variable operates as a specific trap filter by restricting which system events cause the 'logGenericTrap' to be sent. If a trap is not sent due to this filter, then 'trapFilteredSpecific' is incremented. The generation of the this trap is also controlled by 'logTrapHysteresis'. The default value is 'none', which specifies that the 'logGenericTrap' will not be sent. The log record contains the severity level in 'logRecSeverity'. 'critical' is the highest severity level, followed in decreasing order by 'major', 'minor', 'warning', and 'normal', which is the lowest severity level. These severity levels can be further qualified with an indication that the 'health' of the system is effected because of this event. In such a case, these events are indicated with the '-health' suffix ( 'critical-health', 'major-health', 'minor-health', 'warning-health', 'normal-health'). Specifying a severity level (or qualifier) with this variable indicates that ONLY log events of that level (or qualifier) or higher will be allowed to cause the associated generic trap to be sent (unless limited by the trap management controls, 'trapControl', 'trapMgrTable.trapMgrAddress', 'trapMgrTable.trapMgrControl', and 'trapSeverityFilter'). The '-health' qualifier restricts trap generation to those events that effect health. The 'all-non-health' restricts trap generation to events at any level that do not effect health. The absence of a '-health' or '-non-health' indicates that the health effecting qualifier is not considered, only the severity level. For example, if this variable was set to 'major-health', only log events with a severity level of 'major' or higher ('critical') and qualified as effecting health will be allowed to generate the SNMP trap 'logGenericTrap'. If this variable was set to 'warning', only log events with a severity level of 'warning' or higher will be allowed to generate the SNMP trap 'logGenericTrap'. (In this case, the health qualifier is NOT considered.) The values 'all', 'all-health', and 'all-non-health' allow a broader range of log events to be specified. As implied by the names, 'all' will enable all events to generate traps, 'all-health' will allow any log records that effect health to generate traps, and 'all-non-health' will allow all log records that DO NOT effect health to generate traps. Enumeration: 'major': 4, 'normal': 1, 'warning-health': 7, 'minor-health': 8, 'all': 13, 'warning': 2, 'all-non-health': 11, 'critical': 5, 'major-health': 9, 'critical-health': 10, 'none': 14, 'all-health': 12, 'normal-health': 6, 'minor': 3.

This persistent variable indicates the desired hysteresis time value that allows the logging sub-system to generate a SNMP generic log trap, called 'logGenericTrap'. System events that are qualified as having an associated specific trap will NOT be allowed to generate a second generic trap. This control, allows a system event to be NORMALIZED within the 'logTrapHysteresis' time limit. If the event is not normlized, then the 'logGenericTrap' will be sent if not filtered by 'logTrapSeverityFilter', which also controls the generation of this trap. In addition trap management controls may filter this trap from being sent. 'logTrapSeverityFilter', may restrict the generation of a trap based upon the severity level as specified in 'logRecSeverity'. The units are in seconds with the default value value of 120 which is the maximum allowed. The value of 0 is the minimum, which allows the trap to be generated immediately. The timing resolution is plus/minus 15 seconds.

This table contains system log events records. The non-persistent system event log is a circular history or log of system events. A system event that effects health is always added to the system log. A system event that does not effect health may not be added to the system log depending upon three possible filters. These are described in the definition for 'logSeverityFilter'. The retrieval of the 'logRecTable' is effected by the viewing variables, which provide sorting, filtering and page controls. These variables are: 'logViewPageSize', 'logViewPageControl', 'logViewSeverityFilter', 'logViewMethod', 'logViewDirection', 'logViewAge'.

Current list of system log records as limited by the MIB paging, sorting and viewing filters.

When a log record is created or replaced, the 'logIndexNumber' is incremented, then stored within the new log record's 'logRecIndexNumber'. Thus the log record with a 'logRecIndexNumber' of 1 is the first system event that was placed into the log. This log record can be deleted if 1) it does NOT effect health, or 2) if it effects health, it is currently NORMALIZED. This operation can be accomplished by setting this variable to 0. Setting this variable to any other value results in a BAD-VALUE error. If the record is not found, then NO-SUCH-NAME is return. If the record effects health and has not been NORMALIZED, then a READ-ONLY error is returned. This variable is also the SNMP table definition 'index' which identifies a particular 'row' of the SNMP table. The retrieval of any variable of the 'logRecTable' is effected by the viewing variables, which provide sorting, filtering and page controls. These variables are: 'logViewPageSize', 'logViewPageControl', 'logViewSeverityFilter', 'logViewMethod', 'logViewDirection', 'logViewAge'.

The severity level of the log record. 'critical' is the highest severity level, followed in decreasing order by 'major', 'minor', 'warning', and 'normal', which is the lowest severity level. These severity levels can be further qualified with an indication that the 'health' of the system is effected because of this event. In such a case, these events are indicated with the '-health' suffix ( 'critical-health', 'major-health', 'minor-health', 'warning-health', 'normal-health'). Additionally, a health effecting event can be normalized by an associated event. For example, on the Network Management Unit, or NMU, the radio PPP link going down is normalized by the radio PPP going up, and vice versa. When a health effecting event is subsequently normalized (and have no further subsequent occurance), then the log record indicates this qualification with the '-NORMALIZED' suffix as below: 'normal-NORMALIZED', 'warning-NORMALIZED', 'minor-NORMALIZED', 'major-NORMALIZED', 'critical-NORMALIZED'. 'other' indicates a class of log record, rather than a severity level. The severity level of 'other' is considered less important than 'normal'. 'other' primarily is used to indicate a 'Debug' type of log record. Some log events have configurable severity levels. Others have predetermined (non-configurable) severity levels. At the time this log record was added, or as it replaced another record, the 'logSeverityFilter' allowed this event to be logged. The retrieval of any variable of the 'logRecTable' is effected by the viewing variables, which provide sorting, filtering and page controls. These variables are: 'logViewPageSize', 'logViewPageControl', 'logViewSeverityFilter', 'logViewMethod', 'logViewDirection', 'logViewAge'. Enumeration: 'major': 4, 'normal-NORMALIZED': 11, 'normal': 1, 'warning-NORMALIZED': 12, 'warning-health': 7, 'minor-health': 8, 'major-NORMALIZED': 14, 'other': 50, 'warning': 2, 'critical': 5, 'major-health': 9, 'critical-health': 10, 'critical-NORMALIZED': 15, 'minor-NORMALIZED': 13, 'normal-health': 6, 'minor': 3.

The type of event recorded in the log record. See the product release note for detailed explanations of these events. The retrieval of any variable of the 'logRecTable' is effected by the viewing variables, which provide sorting, filtering and page controls. These variables are: 'logViewPageSize', 'logViewPageControl', 'logViewSeverityFilter', 'logViewMethod', 'logViewDirection', 'logViewAge'. Enumeration: 'radio-t1-line-driver-alarm': 26, 'nv-write-err': 12, 'radio-fan-2-alarm': 32, 'radio-receiver-synth-alarm': 33, 'trap-encode-err': 5, 'agent-oid-err': 3, 'malloc-err': 7, 'rtc-set-via-men': 20, 'radio-ber': 29, 'internal-err': 6, 'radio-fan-1-alarm': 31, 'radio-t1-code-violation-alarm': 27, 'buf-pool-err': 8, 'rtc-needs-setting': 14, 'trapFlow-closed': 16, 'ualarm-normal-xition': 2, 'link-ppp-port-down': 18, 'enet-ip-err': 15, 'nv-read-err': 13, 'agent-authen-fail': 11, 'rtc-set-via-mib': 19, 'radio-sync-alarm': 28, 'radio-t1-input-alarm': 25, 'dup-route-on-if': 21, 'radio-alarm-summary': 24, 'ualarm-alarm-xition': 1, 'socket-err': 22, 'link-ppp-port-up': 17, 'radio-transmitter-synth-alarm': 34, 'agent-intern-err': 4, 'radio-ais': 30, 'radio-down': 23, 'unreach-trap-mgr': 10.

This variable contains a textual details of the system log record. Each log record contains : 1) a timestamp indicating when this event last occurred; 2) a 32-bit location number that uniquely identifies the location in the software; 3) a 32-bit error number which provides additional information to further identify the event; 4) a counter indicating the number of times that this event occurred (and was not filtered); 5) a timestamp indicating when this event first occurred, and the 'logIndexNumber' of that first event; 6) a 'specTrap' indication flag marking whether the event has a specific Trap associated with it (the trap may or may not have been sent); 7) a 'NORMALIZED' indication flag marking whether this event record had a subsequent associated event that normalized the original health-related event. If the record is marked for item 7, then it also contains a timestamp of this cancelling event. 'NORMALIZED' events revert to 'non-NORMALIZED' if the event occurs again (without a subsequent normalization). (Item 7 only applies to events that effect the 'health' of the system). 8) a 'Radio' indication flag marking whether the event indicates a radio or nmu event. Items 1, 2, and 3 are always included in this variable as '[mm/dd hh:mm:ss] L:llllllll E:eeeeeeee', where: 1) 'mm/dd' indicate the month/day with 'hh:mm:ss' as 'hour:minute:second'; 2) 'llllllll' is a hexadecimal location; and 3) 'eeeeeeee' is a hexadecimal error number. Item 8 if present causes the string 'RADIO' to be concatenated to the previous string. Item 7 if present causes the string 'NORMALIZED:[mm/dd hh:mm:ss]' (the timestamp of the normalizing event) to be concatenated to the previous string. Items 4 and 5 are also included, if this log record has been marked with multiple occurences. In such a case, the string 'T times 1st:[mm/dd hh:mm:ss](N)' is concatenated to the previous string(s). 'T' is a decimal count of the number of occurences, and the additional timestamp indicates when the first occurence was added to the system log. '(N)' is the 'logIndexNumber' of this first occurance. Item 6 if present causes the string 'specTrap' to be concatenated to the previous string(s). The log record contains additional information that is contained in the other mib variables, namely, 'logRecIndexNumber', 'logRecSeverity', and 'logRecEvent'. The retrieval of any variable of the 'logRecTable' is effected by the viewing variables, which provide sorting, filtering and page controls. These variables are: 'logViewPageSize', 'logViewPageControl', 'logViewSeverityFilter', 'logViewMethod', 'logViewDirection', 'logViewAge'.

This persistent variable controls the generation of SNMP traps by the Agent within the NMU of the radio. 'disabled' forces the Agent to not generate any SNMP traps. 'unLimited' allows the Agent to send any and all traps, without any controls to limit the flow. (Other filters may cause traps not to be sent.) 'unLimited' is the default value. 'feedbackPinLimited' causes the Agent to limit the number of traps that can be sent in a specified time period. If the Agent needs to send more traps than allowed, then it sends a final Trap (nmu.trap.nmTrapsDisabled) indicating that the limit has been reached. The Agent then disables its ability to send traps. This method is described in RFC 1224. Setting this MIB to 'feedbackPinLimited' automatically causes the variable 'trapFlow' to be forced to 'open'. For details see the MIB descriptions for the two other controlling variables 'trapWindowPeriod' and 'trapMaxPerWindow'. The Agent determines if a trap can be sent by examining several controls (or filters), all of which enable the sending of the trap. These are described in their order of checking below: One, the MIB variable that enables that specific trap to be sent is enabled. (Each trap can be selectively enabled or disabled.) If a trap is not sent due to this filter, then 'trapFilteredSpecific' is incremented. Two, the MIB 'trapControl', is set to 'unLimited'; or, it is set to 'feedbackPinLimited' and 'trapFlow' is set to 'open'. If a trap is not sent due to this filter, then 'trapFilteredControl' is incremented. Three, one or more trap managers must be defined in the table 'trapMgrTable' with a valid IP address in 'trapMgrTable.trapMgrAddress', and their control variable 'trapMgrTable.trapMgrControl' must be configured to 1) 'both' or 'standard' and the trap is a standard trap; or 2) 'enterprise' or 'both', and the trap is an enterprise trap. If a trap is not sent due to this filter, then 'trapFilteredManager' is incremented. Four, the trap has no associated severity level, or the severity level of the trap is equal or higher than the value specified by the severity filter 'trapSeverityFilter'. If a trap is not sent due to this filter, then 'trapFilterdSeverity' is incremented. Enumeration: 'disabled': 1, 'unLimited': 2, 'feedbackPinLimited': 3.

The SNMP user writing any value to this variable, causes the following variables to be modified: 1) 'trapMgrCounter' variables of the 'trapMgrTable' are cleared; 2) 'trapLastTimestamp' is given the value 'never-sent'; 3) 'trapFilteredSpecific' is cleared; 4) 'trapFilteredControl' is cleared; 5) 'trapFilteredManager' is cleared; 6) 'trapFilteredSeverity' is cleared; 7) and with 'trapClearDate', the user-entered value is ignored, and the current date and time are recorded instead. This variable provides a historical record that indicates when the statistics were last cleared. This non-persistent variable also is given an initial value of 'NMU reset' whenever the Network Management Unit, or NMU processor is reset. The format is MM/DD/YYYY HH:MM where: MM/DD/YYYY: is the month/day/year HH:MM is the hours:minutes in military time (hours from 00-23).

This table contains a list of trap managers that the Agent must attempt to sent its traps, assuming other controls (or filters) allow. Each row of this table identifies a trap manager by IP address and allows the sending of standard or enterprise traps to be enabled or disabled. The number of traps send to the manager are also counted ('trapMgrCounter'), starting at the time specified by 'trapClearDate'. This implementation allows a maximum of 5 trap managers to be defined. A manager can be added, by changing a row with a manager's address of '0.0.0.0' to a valid IP address. A manager can be deleted, by changing a row with a manager's address that has a valid IP address to a value of '0.0.0.0'. Each row of this table is identified by its an index 'trapMgrIndex'.

Current SNMP Trap Manager information for a specific Manager.

The index number of this row, which describes a trap manager. The index number of remaining trap managers will not be renumbered, if a trap manager is added or deleted. This non-persistent variable may be renumbered when the Network Management Unit, or NMU processor is reset.

This persistent variable contains the IP address of a SNMP Trap manager. This implementation allows a maximum of 5 trap managers to be defined. A manager can be added, by changing a row with a manager's address of '0.0.0.0' to a valid IP address. A manager can be deleted, by changing a row with a manager's address that has a valid IP address to the value 0.0.0.0. Rebooting, or resetting the Network Management Unit, or NMU, has no effect upon this variable, unless the non-volatile memory record containing this variable is unreadable. In such a case, the NMU creates a new record, and resets this variable to 0.0.0.0.

This persistent variable controls whether the Agent will attempt to sent a trap to the specific manager, depending upon other controls (or filters). If these conditions are met, then the Agent will attempt to send an SNMP trap, to this manager, at which time it will increment 'trapMgrCounter'. If this variable, 'trapMgrControl' is set to 'both', then this Agent will send both enterprise and standard traps to this manager. If this variable, 'trapMgrControl' is set to 'standard', then this Agent will send only standard traps to this manager. If this variable, 'trapMgrControl' is set to 'enterprise', then this Agent will send only enterprise traps to this manager. This variable, may only be set when 'trapMgrAddress' has an IP address other than '0.0.0.0'. If this variable, is set to 'none', then this manager will never be sent a trap from this Agent. This is the default value. The Agent determines if a trap can be sent by examining several controls (or filters), all of which enable the sending of the trap. These are described in their order of checking below: One, the MIB variable that enables that specific trap to be sent is enabled. (Each trap can be selectively enabled or disabled.) If a trap is not sent due to this filter, then 'trapFilteredSpecific' is incremented. Two, the MIB 'trapControl', is set to 'unLimited'; or, it is set to 'feedbackPinLimited' and 'trapFlow' is set to 'open'. If a trap is not sent due to this filter, then 'trapFilteredControl' is incremented. Three, one or more trap managers must be defined in the table 'trapMgrTable' with a valid IP address in 'trapMgrTable.trapMgrAddress', and their control variable 'trapMgrTable.trapMgrControl' must be configured to 1) 'both' or 'standard' and the trap is a standard trap; or 2) 'enterprise' or 'both', and the trap is an enterprise trap. If a trap is not sent due to this filter, then 'trapFilteredManager' is incremented. Four, the trap has no associated severity level, or the severity level of the trap is equal or higher than the value specified by the severity filter 'trapSeverityFilter'. If a trap is not sent due to this filter, then 'trapFilteredSeverity' is incremented. Enumeration: 'both': 1, 'none': 4, 'enterprise': 3, 'standard': 2.

The number of SNMP traps that have been sent to this manager by the Agent, since the date and time specified by 'trapClearDate'. This counter can be cleared by setting 'trapClearDate'. This non-persistent variable also is cleared whenever the Network Management Unit, or NMU processor is reset.

This variable indicates whether the Agent has its ability to send SNMP traps limited because it has sent 'trapMaxPerWindow' traps during a time period specified by 'trapWindowPeriod'. This method is called the Feedback/Pin technique for limiting traps, and is described in RFC 1224. This method is enabled by setting 'trapControl' to 'feedbackPinLimited'. The value of 'open', indicates that the Agent is allowed to send traps, and is not currently limited. The value of 'closed', indicates that the Agent is currently not allowed to send traps, because of a self-limiting condition. (The Agent sets the value to 'closed' itself). The SNMP user may only write a value of 'open' to this MIB, and only when 'trapControl' is set to 'feedbackPinLimited'. If the SNMP user wants to disable sending traps, then the variable 'trapControl' should be set to 'disabled', which causes this variable to automatically be set to 'closed'. This non-persistent variable is set to an initial value of 'open' whenever the 'trapControl' has a value of 'unLimited' or 'feedbackPinLimited', or whenever an SNMP user sets 'trapControl' to 'feedbackPinLimited'. The Agent determines if a trap can be sent by examining several controls (or filters), all of which enable the sending of the trap. These are described in their order of checking below: One, the MIB variable that enables that specific trap to be sent is enabled. (Each trap can be selectively enabled or disabled.) If a trap is not sent due to this filter, then 'trapFilteredSpecific' is incremented. Two, the MIB 'trapControl', is set to 'unLimited'; or, it is set to 'feedbackPinLimited' and 'trapFlow' is set to 'open'. If a trap is not sent due to this filter, then 'trapFilteredControl' is incremented. Three, one or more trap managers must be defined in the table 'trapMgrTable' with a valid IP address in 'trapMgrTable.trapMgrAddress', and their control variable 'trapMgrTable.trapMgrControl' must be configured to 1) 'both' or 'standard' and the trap is a standard trap; or 2) 'enterprise' or 'both', and the trap is an enterprise trap. If a trap is not sent due to this filter, then 'trapFilteredManager' is incremented. Four, the trap has no associated severity level, or the severity level of the trap is equal or higher than the value specified by the severity filter 'trapSeverityFilter'. If a trap is not sent due to this filter, then 'trapFilteredSeverity' is incremented. Enumeration: 'open': 1, 'closed': 2.

This variable contains the Date and Time that the Agent attempted to send the last trap. (The time the Agent formatted the SNMP trap packet and delivered it to Internal IP stack. It is not known if the trap was delivered correctly to the target SNMP manager.) A value of 'never-sent' indicates that the Agent has not sent a Trap since 'trapClearDate' was last set. Any change to 'trapClearDate' causes this variable to be set to 'never-sent'. This non-persistent variable is set to an initial value of 'never-sent' whenever the Network Management Unit, or NMU processor is reset. The format is MM/DD/YYYY HH:MM where: MM/DD/YYYY: is the month/day/year HH:MM is the hours:minutes in military time (hours from 00-23).

This persistent variable indicates the time period in minutes that is used by the feedback/pin trap limiting algorithm as specified in RFC 1224. The smallest value allowed for 'trapWindowPeriod' is 1 and the largest value allowed is 1440 which specifies a period of 24 hours. The default value is 15. This variable only takes affect when 'trapControl' is set to 'feedbackPinLimited'. This method operates as described below: If 'trapMaxPerWindow' traps occur and are sent by the Agent in the time period specified by the 'trapWindowPeriod' and another trap needs to be sent, then the Agent ignores this over the limit trap, and forces itself into a mode where it will send no more traps. The Agent sends the 'trapsDisabled' Trap, prior to entering this mode. The Agent then sets the 'trapFlow' control variable to 'closed' which allows no more traps to be sent until this variable is set to 'open', by an SNMP set operation. The agent sends the 'trapsDisabled' Trap, so that an SNMP manager will have an indication that it has sent an excessive number of traps. The agent sets the 'trapFlow' variable to 'closed', so that a Manager can poll this variable periodically, and determine that this Agent has sent too many traps. A Network Administrator can then perform more selective MIB inquiries to determine a more complete status of theis unit. When this limiting condition occurs, the Agent also logs a system event with a severity of 'MAJOR', marking the event as effecting the health of the system. This impact on the health of the NMU is canceled when either 'trapFlow' is set back to 'open', or 'trapControl' is changed to any value other than 'feedbackPinLimited'. If 'trapWindowPeriod' is modified during an active timing period of this feedback method, then the Agent performs in this manner. 1) If the valid new value is larger than the previous value for 'trapWindowPeriod', then the new value is used for any trap timing in the future, and the previous trap history is expanded to the new period size. 2) If the valid new value is smaller than the previous value for 'trapWindowPeriod', then the current trap history is shorten (by reducing the older entries), and the new value is used for any trap timing in the future. A simple example: The Agent can be configured to allow one trap per minute by setting 'trapWindowPeriod' to 1, and 'trapMaxPerWindow' to 1. With this configuration, if at any time a trap needs to be sent within 1 minute of a previous trap, the Agent would limit itself. This implementation of the Feedback Pin technique uses a timing quantum that is one minute as determined by the system's clock. The timing quantum is synchronized to a particular second determined by the first trap of a new window period. All traps within 60 seconds of this starting second accumulate to represent traps sent within that quantum-minute. Traps continue to be counted, and assigned to a new quantum-minute depending upon the starting second, and an aggregate counter represents the total number of traps within the current period. As the full period of history accumulates, traps associated with a quantum-minute at the front of the period reduce the aggregate total as the current clock moves into a new quantum-minute. Thus this window period is a moving period related to the current clock. A new synchronizing second is not choosen unless there is a full 'trapWindowPeriod' that has no traps sent. With this situation, a new starting second is chosen when the new trap needs to be sent. The NMU's system clock resolution is not extremely accurate, but provides reasonable accuracy for limiting traps with this technique.

This persistent variable indicates the maximum number of traps that can occur and be sent during the time period specified by 'trapWindowPeriod', without the Agent limiting itself. This variable is used by the feedback/pin trap limiting algorithm as specified in RFC 1224. The smallest value allowed is 1 and the largest value allowed is 60. The default value is 15. This variable only takes affect when 'trapControl' is set to 'feedbackPinLimited'. This method operates as described below: If 'trapMaxPerWindow' traps occur and are sent by the Agent in the time period specified by the 'trapWindowPeriod' and another trap needs to be sent, then the Agent ignores this over the limit trap, and forces itself into a mode where it will send no more traps. The Agent sends the 'trapsDisabled' Trap, prior to entering this mode. The Agent then sets the 'trapFlow' control variable to 'closed' which allows no more traps to be sent until this variable is set to 'open', by an SNMP set operation. The agent sends the 'trapsDisabled' Trap, so that an SNMP manager will have an indication that it has sent an excessive number of traps. The agent sets the 'trapFlow' variable to 'closed', so that a Manager can poll this variable periodically, and determine that this Agent has sent too many traps. A Network Administrator can then perform more selective MIB inquiries to determine a more complete status of theis unit. When this limiting condition occurs, the Agent also logs a system event with a severity of 'MAJOR', marking the event as effecting the health of the system. This impact on the health of the NMU is canceled when either 'trapFlow' is set back to 'open', or 'trapControl' is changed to any value other than 'feedbackPinLimited'. If 'trapMaxPerWindow' is modified during an active timing period of this feedback method, then the Agent performs in this manner. 1) If the Agent has sent less traps in the current time period than the new valid value, then the new value for 'trapMaxPerWindow' is used subsequently for determining the trap limit. 2) If the Agent has sent more traps in the current time period than the new value, then the current history is reduced by removing older historical 'minutes' and their associated traps from the aggregate total of the period. These are reduced, until the aggregate trap count exactly equals the new value for 'trapMaxPerWindow', which is used subsequently for determining the trap limit. In this way, the 'trapsDisabled' will not be sent until the new limited is exceeded. A simple example: The Agent can be configured to allow one trap per minute by setting 'trapWindowPeriod' to 1, and 'trapMaxPerWindow' to 1. With this configuration, if at any time a trap needs to be sent within 1 minute of a previous trap, the Agent would limit itself. This implementation of the Feedback Pin technique uses a timing quantum that is one minute as determined by the system's clock. The timing quantum is synchronized to a particular second determined by the first trap of a new window period. All traps within 60 seconds of this starting second accumulate to represent traps sent within that quantum-minute. Traps continue to be counted, and assigned to a new quantum-minute depending upon the starting second, and an aggregate counter represents the total number of traps within the current period. As the full period of history accumulates, traps associated with a quantum-minute at the front of the period reduce the aggregate total as the current clock moves into a new quantum-minute. Thus this window period is a moving period related to the current clock. A new synchronizing second is not choosen unless there is a full 'trapWindowPeriod' that has no traps sent. With this situation, a new starting second is chosen when the new trap needs to be sent. The NMU's system clock resolution is not extremely accurate, but provides reasonable accuracy for limiting traps with this technique.

The SNMP user writing any value to this variable, causes the following variables to be modified: 1) 'trapSequenceNumber' variable is cleared. 2) 'trapSequenceClearDate', the user-entered value is ignored, and the current date and time are recorded instead. This persistent variable provides a historical record that indicates when the 'trapSequenceNumber' was set to 0. Rebooting, or resetting the Network Management Unit, or NMU, has no effect upon this variable, unless the non-volatile memory record containing this variable is unreadable. In such a case, the NMU creates a new record, resets the variable 'trapSequenceNumber' to 0, and records the current timestamp in this variable, and in the record. The format is MM/DD/YYYY HH:MM where: MM/DD/YYYY: is the month/day/year HH:MM is the hours:minutes in military time (hours from 00-23).

This persistent variable increments every time an enterprise or standard trap (coldStart, LinkUp, etc.) is generated by the Network Management Unit, or NMU. Any change to 'trapSequenceClearDate' causes this variable to be cleared to 0. This object is sent in the var-bind list of each enterprise trap and can be used by management stations and network administrators to detect when a trap has been lost. It is incremented just after to the encoding and queuing of the SNMP trap packet within the NMU's Agent; therefore a value of '0' encoded in a variable binding of a trap represents the first trap send, since the timestamp represented by 'trapSequenceClearDate'. The value of this variable, indicates the number of traps sent since the timestamp represented by 'trapSequenceClearDate'.

This persistent variable indicates the desired severity level for sending a generated SNMP trap based upon this severity level. This control variable thus acts as a severity level filter. 'critical' is the highest severity level, followed in decreasing order by 'major', 'minor', 'warning', and 'normal', which is the lowest severity level. Specifying a severity level with this variable indicates that SNMP traps of that level and higher and traps not controlled by a severity filter will be sent when generated, unless limited by 'trapControl', 'trapFlow', 'trapMgrControl' or enable/disable variables for specific traps. Setting this variable to 'critical' is the most restrictive. Only SNMP traps with a severity level of critical, or that do not use a severity level will be sent when generated unless limited by other filters. Setting this variable to 'normal' allows all SNMP traps that are generated to be sent unless limited by other filters. The default value for this variable is 'normal'. The Agent determines if a trap can be sent by examining several controls (or filters), all of which enable the sending of the trap. These are described in their order of checking below: One, the MIB variable that enables that specific trap to be sent is enabled. (Each trap can be selectively enabled or disabled.) If a trap is not sent due to this filter, then 'trapFilteredSpecific' is incremented. Two, the MIB 'trapControl', is set to 'unLimited'; or, it is set to 'feedbackPinLimited' and 'trapFlow' is set to 'open'. If a trap is not sent due to this filter, then 'trapFilteredControl' is incremented. Three, one or more trap managers must be defined in the table 'trapMgrTable' with a valid IP address in 'trapMgrTable.trapMgrAddress', and their control variable 'trapMgrTable.trapMgrControl' must be configured to 1) 'both' or 'standard' and the trap is a standard trap; or 2) 'enterprise' or 'both', and the trap is an enterprise trap. If a trap is not sent due to this filter, then 'trapFilteredManager' is incremented. Four, the trap has no associated severity level, or the severity level of the trap is equal or higher than the value specified by the severity filter 'trapSeverityFilter'. If a trap is not sent due to this filter, then 'trapFilteredSeverity' is incremented. Enumeration: 'major': 4, 'warning': 2, 'critical': 5, 'minor': 3, 'normal': 1.

This persistent variable identifies the community string to be used when sending traps to any of the trap managers specified in 'trapMgrTable'. All traps sent by this SNMP Agent will include this community string. SNMP trap managers, can have the community string displayed in the trap log. In addition to IP address, network administrators can use the community string to help identify the Agent that generated the trap. This community string can contain a maximum of 32 characters. The minimum string is a string compose of a single character. If this variable is set to a empty or null string, then the Agent will ignore the null string, and set this variable to the default value. Input characters will be parsed for printable ASCII characters, any characters outside of this set will be removed without an error condition. Special characters such as punctuation, numbers, braces, square boxes, underbars, etc. are allowed if the character has a value between 33 ( '!') and 126 ( '~') decimal inclusive. Blanks are considered invalid. The default value is the string 'NMU-', where represents the 8 character serial number of the NMU.

This variable counts the number of occurrences of events that have an associated SNMP trap, and no trap was sent due to a trap filter that specifically disabled that trap since the date and time specified by 'trapClearDate'. (For example 'alarmTrapControl' filters 'alarmTrap1' through 'alarmTrap32' and 'normalTrap1' through 'normalTrap32'.) This non-persistent variable is set to 0 whenever the Network Management Unit, or NMU, processor is reset. This counter can be cleared by setting 'trapClearDate'. The Agent determines if a trap can be sent by examining several controls (or filters), all of which enable the sending of the trap. These are described in their order of checking below: One, the MIB variable that enables that specific trap to be sent is enabled. (Each trap can be selectively enabled or disabled.) If a trap is not sent due to this filter, then 'trapFilteredSpecific' is incremented. Two, the MIB 'trapControl', is set to 'unLimited'; or, it is set to 'feedbackPinLimited' and 'trapFlow' is set to 'open'. If a trap is not sent due to this filter, then 'trapFilteredControl' is incremented. Three, one or more trap managers must be defined in the table 'trapMgrTable' with a valid IP address in 'trapMgrTable.trapMgrAddress', and their control variable 'trapMgrTable.trapMgrControl' must be configured to 1) 'both' or 'standard' and the trap is a standard trap; or 2) 'enterprise' or 'both', and the trap is an enterprise trap. If a trap is not sent due to this filter, then 'trapFilteredManager' is incremented. Four, the trap has no associated severity level, or the severity level of the trap is equal or higher than the value specified by the severity filter 'trapSeverityFilter'. If a trap is not sent due to this filter, then 'trapFilteredSeverity' is incremented.

This variable counts the number of occurrences of events that have an associated SNMP trap, and no trap was sent due to the 'trapControl' trap filter since the date and time specified by 'trapClearDate'. When the filter check was performed, either 'trapControl' was set to 'disabled'; or 'trapControl' was set to 'feedbackPinLimited' and 'trapFlow' was set to 'closed'. This non-persistent variable is set to 0 whenever the Network Management Unit, or NMU, processor is reset. This counter can be cleared by setting 'trapClearDate'. The Agent determines if a trap can be sent by examining several controls (or filters), all of which enable the sending of the trap. These are described in their order of checking below: One, the MIB variable that enables that specific trap to be sent is enabled. (Each trap can be selectively enabled or disabled.) If a trap is not sent due to this filter, then 'trapFilteredSpecific' is incremented. Two, the MIB 'trapControl', is set to 'unLimited'; or, it is set to 'feedbackPinLimited' and 'trapFlow' is set to 'open'. If a trap is not sent due to this filter, then 'trapFilteredControl' is incremented. Three, one or more trap managers must be defined in the table 'trapMgrTable' with a valid IP address in 'trapMgrTable.trapMgrAddress', and their control variable 'trapMgrTable.trapMgrControl' must be configured to 1) 'both' or 'standard' and the trap is a standard trap; or 2) 'enterprise' or 'both', and the trap is an enterprise trap. If a trap is not sent due to this filter, then 'trapFilteredManager' is incremented. Four, the trap has no associated severity level, or the severity level of the trap is equal or higher than the value specified by the severity filter 'trapSeverityFilter'. If a trap is not sent due to this filter, then 'trapFilteredSeverity' is incremented.

This variable counts the number of occurrences of events that have an associated SNMP trap, and no trap was sent due to the 'trapMgrControl' filters, or the 'trapMgrTable' contained no valid IP address of trap managers in the variable 'trapMgrAddress'. This counter represents these occurrences since the date and time specified by 'trapClearDate'. This non-persistent variable is set to 0 whenever the Network Management Unit, or NMU, processor is reset. This counter can be cleared by setting 'trapClearDate'. The Agent determines if a trap can be sent by examining several controls (or filters), all of which enable the sending of the trap. These are described in their order of checking below: One, the MIB variable that enables that specific trap to be sent is enabled. (Each trap can be selectively enabled or disabled.) If a trap is not sent due to this filter, then 'trapFilteredSpecific' is incremented. Two, the MIB 'trapControl', is set to 'unLimited'; or, it is set to 'feedbackPinLimited' and 'trapFlow' is set to 'open'. If a trap is not sent due to this filter, then 'trapFilteredControl' is incremented. Three, one or more trap managers must be defined in the table 'trapMgrTable' with a valid IP address in 'trapMgrTable.trapMgrAddress', and their control variable 'trapMgrTable.trapMgrControl' must be configured to 1) 'both' or 'standard' and the trap is a standard trap; or 2) 'enterprise' or 'both', and the trap is an enterprise trap. If a trap is not sent due to this filter, then 'trapFilteredManager' is incremented. Four, the trap has no associated severity level, or the severity level of the trap is equal or higher than the value specified by the severity filter 'trapSeverityFilter'. If a trap is not sent due to this filter, then 'trapFilteredSeverity' is incremented.

This variable counts the number of occurrences of events that have an associated SNMP trap, and no trap was sent due to the trap severity filter 'trapSeverityFilter'. This counter represents these occurrences since the date and time specified by 'trapClearDate'. This non-persistent variable is set to 0 whenever the Network Management Unit, or NMU, processor is reset. This counter can be cleared by setting 'trapClearDate'. The Agent determines if a trap can be sent by examining several controls (or filters), all of which enable the sending of the trap. These are described in their order of checking below: One, the MIB variable that enables that specific trap to be sent is enabled. (Each trap can be selectively enabled or disabled.) If a trap is not sent due to this filter, then 'trapFilteredSpecific' is incremented. Two, the MIB 'trapControl', is set to 'unLimited'; or, it is set to 'feedbackPinLimited' and 'trapFlow' is set to 'open'. If a trap is not sent due to this filter, then 'trapFilteredControl' is incremented. Three, one or more trap managers must be defined in the table 'trapMgrTable' with a valid IP address in 'trapMgrTable.trapMgrAddress', and their control variable 'trapMgrTable.trapMgrControl' must be configured to 1) 'both' or 'standard' and the trap is a standard trap; or 2) 'enterprise' or 'both', and the trap is an enterprise trap. If a trap is not sent due to this filter, then 'trapFilteredManager' is incremented. Four, the trap has no associated severity level, or the severity level of the trap is equal or higher than the value specified by the severity filter 'trapSeverityFilter'. If a trap is not sent due to this filter, then 'trapFilteredSeverity' is incremented.

This persistent variable controls whether the Agent will attempt to sent a trap the MIB II 'coldStart' trap whenever the Network Management Unit, or NMU, resets or is powered up. The 'coldStart' trap is defined in RFC 1215, but offers no control for enabling or disabling. This MIB represents an extension to this definition for the purpose of allowing all traps to be selectively enabled or disabled. This coldStart trap has no variable bindings. The NMU does not support the 'warmStart' trap, since it does not differentiate the type of startup. 'enabled' allows the SNMP Agent to attempt to send the coldStart trap, provided the other checks describe below do not prohibit this trap from transmission. 'disabled' disallows the SNMP Agent from attempting to send the coldStart trap, thus 'filtering' this trap from transmission'. In this case, 'trapFilteredSpecific' will be incremented. This MIB variable is the first of four checks that the NMU Agent uses to filter traps, based upon 1) a specific enable or disable control variable; 2) 'trapControl' which offers a gross on/off/limit control; 3) 'trapMgrTable' with 'trapMgrControl' and 'trapMgrAddress' which filters whether standard traps (such as this coldStart) and/or enterprise traps are sent to each specific trap manager; and 4) 'trapSeverityFilter' which filters traps according to a controlling severity level (In the case of coldStart, there is no associated severity level, so this final filter does not apply). Whenever any of these trap filters cause a trap to be filtered, the corresponding MIB statistic is incremented. These statistics are 'trapFilteredSpecific', 'trapFilteredControl', 'trapFilteredManager', and 'trapFilteredSeverity' . See the MIB descriptions for any of these above variables for details. Enumeration: 'disabled': 2, 'enabled': 1.

This persistent variable controls whether the Agent will attempt to sent a trap the MIB II 'linkDown' trap whenever the Network Management Unit, or NMU, detects a link interface with a 'down' status. The 'linkDown' trap is defined in RFC 1215, but offers no control for enabling or disabling. This MIB represents an extension to this definition for the purpose of allowing all traps to be selectively enabled or disabled. is linkDown trap has a single variable bindings of 'ifIndex', which identifies the index number of the interface in the 'down' state. 'enabled' allows the SNMP Agent to attempt to send the linkDown trap, provided the other checks describe below do not prohibit this trap from transmission. 'disabled' disallows the SNMP Agent from attempting to send the linkDown trap, thus 'filtering' this trap from transmission'. In this case, 'trapFilteredSpecific' will be incremented. This MIB variable is the first of four checks that the NMU Agent uses to filter traps, based upon 1) a specific enable or disable control variable; 2) 'trapControl' which offers a gross on/off/limit control; 3) 'trapMgrTable' with 'trapMgrControl' and 'trapMgrAddress' which filters whether standard traps (such as this linkDown) and/or enterprise traps are sent to each specific trap manager; and 4) 'trapSeverityFilter' which filters traps according to a controlling severity level (In the case of linkDown, there is no associated severity level, so this final filter does not apply). Whenever any of these trap filters cause a trap to be filtered, the corresponding MIB statistic is incremented. These statistics are 'trapFilteredSpecific', 'trapFilteredControl', 'trapFilteredManager', and 'trapFilteredSeverity' . See the MIB descriptions for any of these above variables for details. Enumeration: 'disabled': 2, 'enabled': 1.

This persistent variable controls whether the Agent will attempt to sent a trap the MIB II 'linkUp' trap whenever the Network Management Unit, or NMU, detects a link interface with a 'up' status. The 'linkUp' trap is defined in RFC 1215, but offers no control for enabling or disabling. This MIB represents an extension to this definition for the purpose of allowing all traps to be selectively enabled or disabled. This linkUp trap has a single variable bindings of 'ifIndex', which identifies the index number of the interface in the 'up' state. 'enabled' allows the SNMP Agent to attempt to send the linkUp trap, provided the other checks describe below do not prohibit this trap from transmission. 'disabled' disallows the SNMP Agent from attempting to send the linkUp trap, thus 'filtering' this trap from transmission'. In this case, 'trapFilteredSpecific' will be incremented. This MIB variable is the first of four checks that the NMU Agent uses to filter traps, based upon 1) a specific enable or disable control variable; 2) 'trapControl' which offers a gross on/off/limit control; 3) 'trapMgrTable' with 'trapMgrControl' and 'trapMgrAddress' which filters whether standard traps (such as this linkUp) and/or enterprise traps are sent to each specific trap manager; and 4) 'trapSeverityFilter' which filters traps according to a controlling severity level (In the case of linkUp, there is no associated severity level, so this final filter does not apply). Whenever any of these trap filters cause a trap to be filtered, the corresponding MIB statistic is incremented. These statistics are 'trapFilteredSpecific', 'trapFilteredControl', 'trapFilteredManager', and 'trapFilteredSeverity' . See the MIB descriptions for any of these above variables for details. Enumeration: 'disabled': 2, 'enabled': 1.

This variable contains the IP address of the last management station that attempted to access this Agent with an invalid community string. This object is used as a variable binding in an Authentication Failure Trap-PDU (mib2.snmp.authenticationFailure). A value of '0.0.0.0' indicates that no authentication failure has occurred since the NMU processor was last reset, or an IP packet received from an invalid IP address of '0.0.0.0' attempted to access a MIB variable with an invalid community string.

This variable contains the community string specified by the most recent unauthenticated attempt to access this Agent. This object is used as a variable binding in an Authentication Failure Trap-PDU (mib2.snmp.authenticationFailure). A indicates that no authentication failure has occurred since the NMU processor was last reset.

This trap is generated by the SNMP Agent when the logging subsytem has added a system event that does not have a specific trap associated with it, and 'logTrapSeverityFilter', and 'logTrapHysteresis' enable the sending of this trap. The row/column variables included in the trap are: nmu.trap.trapSequenceNumber; system.log.logRecTable.logRecIndexNumber; system.log.logRecTable.logRecSeverity; system.log.logRecTable.logRecEvent; system.log.logRecTable.logRecDescription.

This trap is sent when the SNMP Agent has generated and sent 'trapMaxPerWindow' traps in the time period specified by 'trapWindowPeriod', and another traps is attempted to be sent. The Agent limits itself by sending the 'trapsDisabled' Trap, and setting the 'trapFlow' control variable to 'closed'. This trap will only be sent when 'trapControl' is set to 'feedbackPinLimited', and the 'trapFlow' control variable has a value of 'open'. This trap is the 'alertsDisabled' trap used by the feedback/pin trap limiting algorithm as specified in RFC 1224. For details see the MIB descriptions for the two other controlling variables 'trapWindowPeriod' and 'trapMaxPerWindow'. The variables included in the trap are: trapSequenceNumber; trapLastTimestamp; trapWindowPeriod; trapMaxPerWindow.