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.
Parsed from file WESTERN-MULTIPLEX-MIB.mib
Module: WESTERN-MULTIPLEX-MIB
Vendor: Western Multiplex
Module: WESTERN-MULTIPLEX-MIB
[Automatically extracted from oidview.com]
trapMaxPerWindow OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "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." ::= { trap 7 }
| OID | Name | Sub children | Sub Nodes Total | Description |
|---|---|---|---|---|
| 1.3.6.1.4.1.3727.20.10.5.1 | trapControl | 0 | 0 | This persistent variable controls the generation of SNMP traps by the Agent within the NMU of the radio. 'disabled' forces the Ag… |
| 1.3.6.1.4.1.3727.20.10.5.2 | trapClearDate | 0 | 0 | The SNMP user writing any value to this variable, causes the following variables to be modified: 1) 'trapMgrCounter' variables of… |
| 1.3.6.1.4.1.3727.20.10.5.3 | trapMgrTable | 1 | 5 | This table contains a list of trap managers that the Agent must attempt to sent its traps, assuming other controls (or filters) a… |
| 1.3.6.1.4.1.3727.20.10.5.4 | trapFlow | 0 | 0 | This variable indicates whether the Agent has its ability to send SNMP traps limited because it has sent 'trapMaxPerWindow' traps… |
| 1.3.6.1.4.1.3727.20.10.5.5 | trapLastTimestamp | 0 | 0 | This variable contains the Date and Time that the Agent attempted to send the last trap. (The time the Agent formatted the SNMP t… |
| 1.3.6.1.4.1.3727.20.10.5.6 | trapWindowPeriod | 0 | 0 | This persistent variable indicates the time period in minutes that is used by the feedback/pin trap limiting algorithm as specifi… |
| 1.3.6.1.4.1.3727.20.10.5.10 | trapSequenceClearDate | 0 | 0 | The SNMP user writing any value to this variable, causes the following variables to be modified: 1) 'trapSequenceNumber' variable… |
| 1.3.6.1.4.1.3727.20.10.5.11 | trapSequenceNumber | 0 | 0 | This persistent variable increments every time an enterprise or standard trap (coldStart, LinkUp, etc.) is generated by the Netwo… |
| 1.3.6.1.4.1.3727.20.10.5.12 | trapSeverityFilter | 0 | 0 | This persistent variable indicates the desired severity level for sending a generated SNMP trap based upon this severity level. T… |
| 1.3.6.1.4.1.3727.20.10.5.13 | trapCommunity | 0 | 0 | This persistent variable identifies the community string to be used when sending traps to any of the trap managers specified in '… |
| 1.3.6.1.4.1.3727.20.10.5.18 | trapFilteredSpecific | 0 | 0 | This variable counts the number of occurrences of events that have an associated SNMP trap, and no trap was sent due to a trap fi… |
| 1.3.6.1.4.1.3727.20.10.5.19 | trapFilteredControl | 0 | 0 | This variable counts the number of occurrences of events that have an associated SNMP trap, and no trap was sent due to the 'trap… |
| 1.3.6.1.4.1.3727.20.10.5.20 | trapFilteredManager | 0 | 0 | This variable counts the number of occurrences of events that have an associated SNMP trap, and no trap was sent due to the 'trap… |
| 1.3.6.1.4.1.3727.20.10.5.21 | trapFilteredSeverity | 0 | 0 | This variable counts the number of occurrences of events that have an associated SNMP trap, and no trap was sent due to the trap … |
| 1.3.6.1.4.1.3727.20.10.5.22 | trapColdStartControl | 0 | 0 | This persistent variable controls whether the Agent will attempt to sent a trap the MIB II 'coldStart' trap whenever the Network … |
| 1.3.6.1.4.1.3727.20.10.5.23 | trapLinkDownControl | 0 | 0 | This persistent variable controls whether the Agent will attempt to sent a trap the MIB II 'linkDown' trap whenever the Network M… |
| 1.3.6.1.4.1.3727.20.10.5.24 | trapLinkUpControl | 0 | 0 | This persistent variable controls whether the Agent will attempt to sent a trap the MIB II 'linkUp' trap whenever the Network Man… |