Traps

If you enable the option Send information about system events (traps) to the target addresses specified in the following table, the recipients configured under Target addresses and Target parameters will receive the corresponding information. The system events that trigger a message can be restricted by trap filters.

Target addresses

The list of target addresses is used to configure the addresses of the recipients to whom the SNMP agent sends the SNMP traps.

Name

Give the entry a descriptive name here.

Transport address

Configure the address of the recipient here. This address describes the IP address and port number of a recipient of an SNMP trap and is specified in the syntax "<IP address> : <Port>" (e.g. 128.1.2.3:162). UDP port 162 is used for SNMP traps.

Source address

Here you have the option to configure a sender address for the device to use in place of the one that would otherwise be used automatically for this target address. If you have configured loopback addresses, you can specify them here as source address. You can enter an address in various forms:

Name of the IP network (ARF network), whose address should be used.
"INT" for the address of the first intranet.
"DMZ" for the address of the first DMZ
Important: If there is an interface called "DMZ", its address will be taken in this case.
LB0…LBF for one of the 16 loopback addresses or its name.
Furthermore, any IP address can be entered in the form x.x.x.x.

Note: If the source address set here is a loopback address, these will be used unmasked on the remote client.

Target parameter name

Here you select the desired entry from the list of recipient parameters.

Target parameter name

In this table you configure how the SNMP agent handles the SNMP traps that it sends to the recipient.

Name

Give the entry a descriptive name here.

Message processing model

Here you specify the protocol for which the SNMP agent structures the message.

User / security name

Here you select a security name you assigned to an SNMP community. It is also possible to specify the name of an existing configured user.

Security model

SNMPv3 introduced the principle of the "Security Model", so that the SNMP configuration in LCOS primarily uses the security model "SNMPv3". However, for compatibility reasons it may be necessary to allow for the versions SNMPv2c or even SNMPv1, and to select these accordingly. Select one of the following entries accordingly:

SNMPv1: Data is transmitted by SNMPv1. Users are authenticated by the community string in the SNMP message only. Communication is not encrypted. This corresponds to the security level "NoAuthNoPriv".
SNMPv2: Data is transmitted by SNMPv2c. Users are authenticated by the community string in the SNMP message only. Communication is not encrypted. This corresponds to the security level "NoAuthNoPriv".
SNMPv3 (USM): Data is transmitted by SNMPv3. This can only be selected together with SNMP users. The effective possible security level depends on the user's chosen authentication and encryption methods.

Security level

Set the security level that applies for the recipient to receive the SNMP trap.

No authentication/No privacy: The SNMP request is valid without the use of specific authentication methods. Authentication merely requires the user to belong to an SNMP community (for SNMPv1 and SNMPv2c) or to specify a valid user name (for SNMPv3). Data transfer is not encrypted.
Authentication/No privacy: Authentication makes use of the hash algorithms set for the user. Data communication is not encrypted.
Authentication and privacy: Authentication makes use of the hash algorithms set for the user. Data communication is encrypted by DES or AES algorithms.

Trap filter

Certain SNMP traps or even large numbers of SNMP traps can be unwanted on the receiving servers. For this reason, you can add an SNMP filter list that allows you to selectively pass or withhold SNMP traps based on their manufacturer-specific OIDs or the OIDs contained in the variable bindings.

Note: Traps for the user "root" cannot be filtered. Filtering requires the use of a separate SNMP user.

Index

The position of this entry in the filter list. The list is checked from the smallest to the largest value until the first hit.

View name

The View name is the name of a view that this filter rule applies to. If Access to subtree for the relevant view is set to "added", the corresponding traps can be prevented by the filter action "deny" in a related filter rule. However, if Access to subtree of the relevant view is set to "removed", the filter action "Allow" still sends the messages as an exception. Since the views can contain multiple entries of the same name with different access settings, it must be possible to set the filter action irrespective of the value of the corresponding setting for Access to subtree.

Spec. trap ID

Specifies a certain trap ID that can contain wildcards and ranges. An empty entry applies to all specific trap IDs of the device. See the examples in the following table.

OID	Description
	Applies to every OID.
1.2.3	Applies to all OIDs that start with "1.2.3".
1.*.3	Applies to all OIDs that start with "1", then contain any value, and then continue with "3".
1.2-3.4	Applies to all OIDs that start with "1", continue with a number ranging from "2 to 3", and then a "4".
1.2.3-4,7-8	Applies to all OIDs that start with "1.2" and continue with a number ranging from "3 to 4" or "7 to 8".

Important: Wildcards and ranges can occur anywhere in an OID, and an OID may also contain multiple wildcards or ranges. However, each position may only contain either a wildcard or a range.

A LANCOM device maps the generic trap OIDs of the SNMP protocol to certain vendor-specific OIDs:

Name	Generic OID	OID at LANCOM
coldStart	0	1.3.6.1.6.3.1.1.5.1
warmStart	1	1.3.6.1.6.3.1.1.5.2
linkDown	2	1.3.6.1.6.3.1.1.5.3
linkUp	3	1.3.6.1.6.3.1.1.5.4
authenticationFailure	4	1.3.6.1.6.3.1.1.5.5
egpNeighborLoss	5	1.3.6.1.6.3.1.1.5.6

Var. Binding ID

Specifies an OID that must be in the trap’s variable bindings, which in turn may contain wildcards and ranges. Also see Spec. trap ID, An empty entry applies to all variable bindings of the device.

Filter action

In case of a match with the set IDs, you can either "Allow" the trap to so send it, or "Deny" it so that it is discarded.