Table of Contents (Start)

Unknown Traps

The Unknown Traps page displays the SNMP traps SevOne NMS receives for which you do not define a trap event. Simple Network Management Protocol traps are an aspect of SNMP that enables a device to send information. An example of a trap trigger is when a new interface is added or a device is restarted. The traps that appear on the Unknown Traps page are less meaningful than traps for which you define a trap event. Trap events enable you to assign real meaning to SNMP traps. The goal is to enable you to define trap events (either ignore, log, or alert) for the traps that are specific to your environment. The Cluster Manager > Cluster Settings tab enables you to define how many days to save unknown traps.

To access the Unknown Traps page from the navigation bar, click the Events menu, select Archive, and then select Unknown Traps.

images/download/attachments/163972359/unknowntraps-version-1-modificationdate-1693242033010-api-v2.png

Filter

Filters enable you to limit the traps that appear in the list. All filters are optional and cumulative.

Click the Peer drop-down and select the peer that receives the traps.
Click the Target OID to display the SNMP OID Browser or enter the name of the target OID to display traps for a specific OID.
In the IP Address field, enter the IP address from which to display traps.
Click the Time Span drop-down and select a time span to display traps for a specific time span.
Click the Time Zone drop-down and select the time zone for the time span.
Click Apply Filter button to display the traps that meet your filter criteria.

Trap Manager

Configure Trap Event

The Configure Trap Event button enables you to define a trap event for the unknown trap. After you define the trap event, the trap is handled in the way you specify and future trap occurrences appear on the Logged Traps page, when applicable.

Select a trap in the list under Traps (in the left pane).
In the right pane, select the check box for each variable to include in the trap event definition.
Click Configure Trap Event to display the Trap Event Editor with applicable fields pre-populated.

For SNMPv3 traps, if the credentials of the received traps does not match any of the entries defined in Trap v3 Receiver, you will see an error message in the OID field.

For example, your OID field will contain the following.

Decryption error (v3 securityname: MD5AES)

List of Unknown Traps

Traps

The unknown traps list displays traps from most recent to oldest.

IP Address - displays the IP address from where the trap came.
Time - displays the time SevOne NMS received the trap.
OID - displays the trap's object identifier (OID) that could be used to define a trap event.
Variable Number - displays the number of variables associated with the trap.

Variables

Click on a trap to display the following in the Variables section.

Variable - displays the name of the variable with a check box. Select the check box to include the variable in the trap event definition.
Type - displays the variable type.
Value - displays the value that triggers the trap.

Min/Max recommendation for trap values

SevOne-trapd Thread Count	Processed Max	Received Max
Default = 10	1k/tps	1k/tps
Max = 99	1.5k/tps	4k/tps

The maximum number of traps per second (tps) that SevOne-trapd is able to process is 1.5k regardless of type/volume and also, regardless of configured SevOne-trapd thread count (The default value is 10 and maximum value is 99).

When trap count is set to its default value (=10), 1k/tps can be processed while receiving 1k/tps. If 2k/tps are sent, maximum of 1.5k/tps can be processed. Some traps are lost due to the task queue filling to its maximum, resulting in traps being discarded. This also causes systemd-journal to balloon in CPU usage resulting in the following error.

Error

SevOne-trapd[2439]: MainApp::handleMessage: Failed to queue trap (task list is full).

When SevOne-trapd thread count is set to its maximum value (= 99), 1.5k/tps can be processed while receiving 4k/tps without overflowing the queue over time. This remains true regardless of the trap type.

There is a slight decrease in trap processing on the half-hour due to cron runs. This decrease is momentary and does not appear to cause a queue overload at the maximum value of 4k/tps received (1.5k/tps processed).

5k/tps received with the maximum thread count of 99 will over time cause a queue overrun. With a maximum processing rate of 1.5k/tps, the incoming traps cannot be processed fast enough resulting in incoming traps being discarded when the queue is full.