compIDEntry |
1.3.6.1.4.1.3727.20.10.1.10.1 |
A row of the compIDTable that represents a single
hardware component of the system. |
Status: mandatory |
Access: not-accessible |
OBJECT-TYPE |
|
|
|
|
CompIDEntry |
|
|
logCurrentHEALTH |
1.3.6.1.4.1.3727.20.10.4.4 |
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'. |
Status: mandatory |
Access: read-only |
OBJECT-TYPE |
|
|
|
|
INTEGER |
normal-health(1), warning-health(2), minor-health(3), major-health(4), critical-health(5) |
|
logRadioHEALTH |
1.3.6.1.4.1.3727.20.10.4.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'. |
Status: mandatory |
Access: read-only |
OBJECT-TYPE |
|
|
|
|
INTEGER |
normal-health(1), warning-health(2), minor-health(3), major-health(4), critical-health(5) |
|
logSeverityFilter |
1.3.6.1.4.1.3727.20.10.4.6 |
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'. |
Status: mandatory |
Access: read-write |
OBJECT-TYPE |
|
|
|
|
INTEGER |
normal(1), warning(2), minor(3), major(4), critical(5) |
|
logViewPageSize |
1.3.6.1.4.1.3727.20.10.4.15 |
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'. |
Status: mandatory |
Access: read-write |
OBJECT-TYPE |
|
|
|
|
INTEGER |
|
|
logViewPageControl |
1.3.6.1.4.1.3727.20.10.4.16 |
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'. |
Status: mandatory |
Access: read-write |
OBJECT-TYPE |
|
|
|
|
INTEGER |
|
|
logViewSeverityFilter |
1.3.6.1.4.1.3727.20.10.4.17 |
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'. |
Status: mandatory |
Access: read-write |
OBJECT-TYPE |
|
|
|
|
INTEGER |
normal(1), warning(2), minor(3), major(4), critical(5), normal-health(6), warning-health(7), minor-health(8), major-health(9), critical-health(10), other(11), all-non-health(12), all-health-NORMALIZED(13), all-health-not-NORMALIZED(14), all-health(15), all(16) |
|
logViewMethod |
1.3.6.1.4.1.3727.20.10.4.18 |
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'. |
Status: mandatory |
Access: read-write |
OBJECT-TYPE |
|
|
|
|
INTEGER |
chronological(1), severity(2) |
|
logViewDirection |
1.3.6.1.4.1.3727.20.10.4.19 |
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'. |
Status: mandatory |
Access: read-write |
OBJECT-TYPE |
|
|
|
|
INTEGER |
critical-to-normal(1), normal-to-critical(2) |
|
logViewAge |
1.3.6.1.4.1.3727.20.10.4.20 |
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'. |
Status: mandatory |
Access: read-write |
OBJECT-TYPE |
|
|
|
|
INTEGER |
oldest-to-newest(1), newest-to-oldest(2) |
|
logTrapSeverityFilter |
1.3.6.1.4.1.3727.20.10.4.30 |
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. |
Status: mandatory |
Access: read-write |
OBJECT-TYPE |
|
|
|
|
INTEGER |
normal(1), warning(2), minor(3), major(4), critical(5), normal-health(6), warning-health(7), minor-health(8), major-health(9), critical-health(10), all-non-health(11), all-health(12), all(13), none(14) |
|
logRecEntry |
1.3.6.1.4.1.3727.20.10.4.40.1 |
Current list of system log records as limited by the
MIB paging, sorting and viewing filters. |
Status: mandatory |
Access: not-accessible |
OBJECT-TYPE |
|
|
|
|
LogRecEntry |
|
|
logRecIndexNumber |
1.3.6.1.4.1.3727.20.10.4.40.1.1 |
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'. |
Status: mandatory |
Access: read-write |
OBJECT-TYPE |
|
|
|
|
INTEGER |
|
|
logRecSeverity |
1.3.6.1.4.1.3727.20.10.4.40.1.2 |
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'. |
Status: mandatory |
Access: read-only |
OBJECT-TYPE |
|
|
|
|
INTEGER |
normal(1), warning(2), minor(3), major(4), critical(5), normal-health(6), warning-health(7), minor-health(8), major-health(9), critical-health(10), normal-NORMALIZED(11), warning-NORMALIZED(12), minor-NORMALIZED(13), major-NORMALIZED(14), critical-NORMALIZED(15), other(50) |
|
logRecEvent |
1.3.6.1.4.1.3727.20.10.4.40.1.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'. |
Status: mandatory |
Access: read-only |
OBJECT-TYPE |
|
|
|
|
INTEGER |
ualarm-alarm-xition(1), ualarm-normal-xition(2), agent-oid-err(3), agent-intern-err(4), trap-encode-err(5), internal-err(6), malloc-err(7), buf-pool-err(8), unreach-trap-mgr(10), agent-authen-fail(11), nv-write-err(12), nv-read-err(13), rtc-needs-setting(14), enet-ip-err(15), trapFlow-closed(16), link-ppp-port-up(17), link-ppp-port-down(18), rtc-set-via-mib(19), rtc-set-via-menu(20), dup-route-on-if(21), socket-err(22), radio-down(23), radio-alarm-summary(24), radio-t1-input-alarm(25), radio-t1-line-driver-alarm(26), radio-t1-code-violation-alarm(27), radio-sync-alarm(28), radio-ber(29), radio-ais(30), radio-fan-1-alarm(31), radio-fan-2-alarm(32), radio-receiver-synth-alarm(33), radio-transmitter-synth-alarm(34) |
|
logRecDescription |
1.3.6.1.4.1.3727.20.10.4.40.1.4 |
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'. |
Status: mandatory |
Access: read-only |
OBJECT-TYPE |
|
|
|
|
DisplayString |
|
|
trapControl |
1.3.6.1.4.1.3727.20.10.5.1 |
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. |
Status: mandatory |
Access: read-write |
OBJECT-TYPE |
|
|
|
|
INTEGER |
disabled(1), unLimited(2), feedbackPinLimited(3) |
|
trapMgrEntry |
1.3.6.1.4.1.3727.20.10.5.3.1 |
Current SNMP Trap Manager information for a
specific Manager. |
Status: mandatory |
Access: not-accessible |
OBJECT-TYPE |
|
|
|
|
TrapMgrEntry |
|
|
trapMgrControl |
1.3.6.1.4.1.3727.20.10.5.3.1.3 |
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. |
Status: mandatory |
Access: read-write |
OBJECT-TYPE |
|
|
|
|
INTEGER |
both(1), standard(2), enterprise(3), none(4) |
|
trapFlow |
1.3.6.1.4.1.3727.20.10.5.4 |
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. |
Status: mandatory |
Access: read-write |
OBJECT-TYPE |
|
|
|
|
INTEGER |
open(1), closed(2) |
|
trapWindowPeriod |
1.3.6.1.4.1.3727.20.10.5.6 |
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. |
Status: mandatory |
Access: read-write |
OBJECT-TYPE |
|
|
|
|
INTEGER |
|
|
trapMaxPerWindow |
1.3.6.1.4.1.3727.20.10.5.7 |
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. |
Status: mandatory |
Access: read-write |
OBJECT-TYPE |
|
|
|
|
INTEGER |
|
|
trapSeverityFilter |
1.3.6.1.4.1.3727.20.10.5.12 |
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. |
Status: mandatory |
Access: read-write |
OBJECT-TYPE |
|
|
|
|
INTEGER |
normal(1), warning(2), minor(3), major(4), critical(5) |
|
trapFilteredSpecific |
1.3.6.1.4.1.3727.20.10.5.18 |
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. |
Status: mandatory |
Access: read-only |
OBJECT-TYPE |
|
|
|
|
Counter |
|
|
trapFilteredControl |
1.3.6.1.4.1.3727.20.10.5.19 |
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. |
Status: mandatory |
Access: read-only |
OBJECT-TYPE |
|
|
|
|
Counter |
|
|
trapFilteredManager |
1.3.6.1.4.1.3727.20.10.5.20 |
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. |
Status: mandatory |
Access: read-only |
OBJECT-TYPE |
|
|
|
|
Counter |
|
|
trapFilteredSeverity |
1.3.6.1.4.1.3727.20.10.5.21 |
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. |
Status: mandatory |
Access: read-only |
OBJECT-TYPE |
|
|
|
|
Counter |
|
|
trapColdStartControl |
1.3.6.1.4.1.3727.20.10.5.22 |
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. |
Status: mandatory |
Access: read-write |
OBJECT-TYPE |
|
|
|
|
INTEGER |
enabled(1), disabled(2) |
|
trapLinkDownControl |
1.3.6.1.4.1.3727.20.10.5.23 |
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. |
Status: mandatory |
Access: read-write |
OBJECT-TYPE |
|
|
|
|
INTEGER |
enabled(1), disabled(2) |
|
trapLinkUpControl |
1.3.6.1.4.1.3727.20.10.5.24 |
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. |
Status: mandatory |
Access: read-write |
OBJECT-TYPE |
|
|
|
|
INTEGER |
enabled(1), disabled(2) |
|