WESTERN-MULTIPLEX-MIB
AI MIB Summary
Standard SNMP MIB module defining data structures for WESTERN-MULTIPLEX-MIB.
75
Objects
Active
Status
3
Dependencies
Imported Objects
Objects
75 total| Object Name |
|---|
western-multiplex OBJECT IDENTIFIER .1.3.6.1.4.1.3727 |
RFC1213-MIB Unknown .1.3.6.1.4.1.3727 |
tsunami100-06 OBJECT IDENTIFIER .1.3.6.1.4.1.3727.20 |
system OBJECT IDENTIFIER .1.3.6.1.4.1.3727.20.10 |
component OBJECT IDENTIFIER .1.3.6.1.4.1.3727.20.10.1 |
compSerialNumberThis persistent variable contains the primary
serial number of this System.ro DisplayString ( SIZE (12)) .1.3.6.1.4.1.3727.20.10.1.1 |
compIDTableA 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'. SEQUENCE OF CompIDEntry .1.3.6.1.4.1.3727.20.10.1.10 |
compIDEntryA row of the compIDTable that represents a single
hardware component of the system. CompIDEntry .1.3.6.1.4.1.3727.20.10.1.10.1 |
compIDSerialNumThis persistent variable contains the serial
number of the component.
If the component has no serial number, then the
variable has the value '<no-serial-number>'.ro DisplayString .1.3.6.1.4.1.3727.20.10.1.10.1.1 |
compIDTypeThis persistent variable contains the type of
the component as evidence by name and part number.ro Enumeration .1.3.6.1.4.1.3727.20.10.1.10.1.2 |
compIDLocationThis 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.ro Enumeration .1.3.6.1.4.1.3727.20.10.1.10.1.3 |
compIDStateThis 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.rw Enumeration .1.3.6.1.4.1.3727.20.10.1.10.1.4 |
clock OBJECT IDENTIFIER .1.3.6.1.4.1.3727.20.10.2 |
clockDateTimeThis 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.rw DisplayString .1.3.6.1.4.1.3727.20.10.2.1 |
clockTZOffsetThis 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 <null-string>.rw DisplayString .1.3.6.1.4.1.3727.20.10.2.2 |
boot OBJECT IDENTIFIER .1.3.6.1.4.1.3727.20.10.3 |
bootRebootSetting 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.rw Enumeration .1.3.6.1.4.1.3727.20.10.3.1 |
bootDateThis 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).ro DisplayString .1.3.6.1.4.1.3727.20.10.3.2 |
bootPreviousDateThis 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).ro DisplayString .1.3.6.1.4.1.3727.20.10.3.3 |
bootRebootCountThis 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'.ro INTEGER .1.3.6.1.4.1.3727.20.10.3.4 |
bootClearDateThe 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).rw DisplayString .1.3.6.1.4.1.3727.20.10.3.5 |
log OBJECT IDENTIFIER .1.3.6.1.4.1.3727.20.10.4 |
logGenericTrap} TRAP-TYPE .1.3.6.1.4.1.3727.20.10.4.0.1 |
logMaxSizeThis 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.rw INTEGER .1.3.6.1.4.1.3727.20.10.4.1 |
logCurrentSizeThis 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.ro INTEGER .1.3.6.1.4.1.3727.20.10.4.2 |
logIndexNumberThis 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.ro Counter .1.3.6.1.4.1.3727.20.10.4.3 |
logCurrentHEALTHThis 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'.ro Enumeration .1.3.6.1.4.1.3727.20.10.4.4 |
logRadioHEALTHThis 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'.ro Enumeration .1.3.6.1.4.1.3727.20.10.4.5 |
logSeverityFilterThis 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'.rw Enumeration .1.3.6.1.4.1.3727.20.10.4.6 |
logFilteredSpecificThis 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'.ro Counter .1.3.6.1.4.1.3727.20.10.4.7 |
logFilteredSeverityThis 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.ro Counter .1.3.6.1.4.1.3727.20.10.4.8 |
logFilteredRulesThis 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.ro Counter .1.3.6.1.4.1.3727.20.10.4.9 |
logViewPageSizeThis 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'.rw INTEGER .1.3.6.1.4.1.3727.20.10.4.15 |
logViewPageControlThis 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'.rw INTEGER .1.3.6.1.4.1.3727.20.10.4.16 |
logViewSeverityFilterThis 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'.rw Enumeration .1.3.6.1.4.1.3727.20.10.4.17 |
logViewMethodThis 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'.rw Enumeration .1.3.6.1.4.1.3727.20.10.4.18 |
logViewDirectionThis 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'.rw Enumeration .1.3.6.1.4.1.3727.20.10.4.19 |
logViewAgeThis 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'.rw Enumeration .1.3.6.1.4.1.3727.20.10.4.20 |
logViewEventsThis 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'.ro INTEGER .1.3.6.1.4.1.3727.20.10.4.21 |
logTrapSeverityFilterThis 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.rw Enumeration .1.3.6.1.4.1.3727.20.10.4.30 |
logTrapHysteresisThis 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.rw INTEGER .1.3.6.1.4.1.3727.20.10.4.31 |
logRecTableThis 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'. SEQUENCE OF LogRecEntry .1.3.6.1.4.1.3727.20.10.4.40 |
logRecEntryCurrent list of system log records as limited by the
MIB paging, sorting and viewing filters. LogRecEntry .1.3.6.1.4.1.3727.20.10.4.40.1 |
logRecIndexNumberWhen 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'.rw INTEGER .1.3.6.1.4.1.3727.20.10.4.40.1.1 |
logRecSeverityThe 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'.ro Enumeration .1.3.6.1.4.1.3727.20.10.4.40.1.2 |
logRecEventThe 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'.ro Enumeration .1.3.6.1.4.1.3727.20.10.4.40.1.3 |
logRecDescriptionThis 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'.ro DisplayString (SNMPv2-TC) .1.3.6.1.4.1.3727.20.10.4.40.1.4 |
trap OBJECT IDENTIFIER .1.3.6.1.4.1.3727.20.10.5 |
trapsDisabledThis 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. TRAP-TYPE .1.3.6.1.4.1.3727.20.10.5.0.1 |
trapControlThis 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.rw Enumeration .1.3.6.1.4.1.3727.20.10.5.1 |
trapClearDateThe 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).rw DisplayString .1.3.6.1.4.1.3727.20.10.5.2 |
trapMgrTableThis 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'. SEQUENCE OF TrapMgrEntry .1.3.6.1.4.1.3727.20.10.5.3 |
trapMgrEntryCurrent SNMP Trap Manager information for a
specific Manager. TrapMgrEntry .1.3.6.1.4.1.3727.20.10.5.3.1 |
trapMgrIndexThe 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.ro INTEGER .1.3.6.1.4.1.3727.20.10.5.3.1.1 |
trapMgrAddressThis 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.rw IpAddress .1.3.6.1.4.1.3727.20.10.5.3.1.2 |
trapMgrControlThis 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.rw Enumeration .1.3.6.1.4.1.3727.20.10.5.3.1.3 |
trapMgrCounterThe 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.ro Counter .1.3.6.1.4.1.3727.20.10.5.3.1.4 |
trapFlowThis 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.rw Enumeration .1.3.6.1.4.1.3727.20.10.5.4 |
trapLastTimestampThis 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).ro DisplayString .1.3.6.1.4.1.3727.20.10.5.5 |
trapWindowPeriodThis 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.rw INTEGER .1.3.6.1.4.1.3727.20.10.5.6 |
trapMaxPerWindowThis 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.rw INTEGER .1.3.6.1.4.1.3727.20.10.5.7 |
trapSequenceClearDateThe 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).rw DisplayString .1.3.6.1.4.1.3727.20.10.5.10 |
trapSequenceNumberThis 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'.ro INTEGER .1.3.6.1.4.1.3727.20.10.5.11 |
trapSeverityFilterThis 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.rw Enumeration .1.3.6.1.4.1.3727.20.10.5.12 |
trapCommunityThis 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-<serial number>',
where <serial number> represents the 8 character serial
number of the NMU.rw DisplayString .1.3.6.1.4.1.3727.20.10.5.13 |
trapFilteredSpecificThis 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.ro Counter .1.3.6.1.4.1.3727.20.10.5.18 |
trapFilteredControlThis 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.ro Counter .1.3.6.1.4.1.3727.20.10.5.19 |
trapFilteredManagerThis 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.ro Counter .1.3.6.1.4.1.3727.20.10.5.20 |
trapFilteredSeverityThis 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.ro Counter .1.3.6.1.4.1.3727.20.10.5.21 |
trapColdStartControlThis 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.rw Enumeration .1.3.6.1.4.1.3727.20.10.5.22 |
trapLinkDownControlThis 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.rw Enumeration .1.3.6.1.4.1.3727.20.10.5.23 |
trapLinkUpControlThis 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.rw Enumeration .1.3.6.1.4.1.3727.20.10.5.24 |
auth OBJECT IDENTIFIER .1.3.6.1.4.1.3727.20.10.6 |
authUnAuthIpAddrThis 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.ro IpAddress .1.3.6.1.4.1.3727.20.10.6.1 |
authUnAuthCommunityThis 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 <null-string> indicates that no authentication
failure has occurred since the NMU processor was last
reset.ro DisplayString .1.3.6.1.4.1.3727.20.10.6.2 |