Allied Telesis SNMP Rel. 2.0.0 User manual

SNMP Reference Manual

SNMP Reference Manual
Page 1 of 37
SNMP Reference Manual
SNMP Reference Manual Rel. 2.0.0
Copyright © 2004 Allied Telesis
All rights reserved. No part of this publication may be reproduced without prior written permission
from Allied Telesis.
Allied Telesis reserves the right to make changes in specifications and other information contained in
this document without prior written notice. The information provided herein is subject to change
without notice. In no event shall Allied Telesis be liable for any incidental, special, indirect, or
consequential damages whatsoever, including but not limited to lost profits, arising out of or related to
this manual or the information contained herein, even if Allied Telesis has been advised of, known, or
should have known, the possibility of such damages.
All trademarks are the property of their respective owners.

SNMP Reference Manual
Page 2 of 37
Contents
INTRODUCTION TO SNMP CONFIGURATION ........................................................................................5
SNMP CONFIGURATION WITHIN THE SNMPV3 ADMINISTRATION FRAMEWORK .....................7
INTRODUCTION .........................................................................................................................7
SECURITY ...............................................................................................................................................................................7
MECHANISMS USED BY SNMPV3 SECURITY..............................................................................................................7
LOCAL CONFIGURATION DATASTORE .......................................................................................9
CONFIGURATION FILE FORMAT..................................................................................................................................9
CONFIGURATION FOR ALL SNMPV3 ENTITIES .......................................................................10
CONFIGURING SNMPV3 USERS...................................................................................................................................10
BREAKDOWN OF AN SNMPENGINEID....................................................................................................................11
CONFIGURING AN AGENT TO RECEIVE REQUESTS AND SEND TRAPS .............................................................................12
CONFIGURATION FOR AUTHENTICATION.......................................................................................................................12
CONFIGURATION FOR NO AUTHENTICATION ................................................................................................................13
ADDITIONAL CONFIGURATION FOR SNMPV3 AGENT ENTITIES .............................................13
CONFIGURING VIEW-BASED ACCESS CONTROL...............................................................................................13
DEFINING FAMILIES OF VIEW SUBTREES..................................................................................................................13
DEFINING GROUPS AND ACCESS RIGHTS .............................................................................................................15
ASSIGNING PRINCIPALS TO GROUPS.......................................................................................................................16
CONFIGURING NOTICATIONS..................................................................................................17
DEFINING NOTIFICATIONS..........................................................................................................................................17
DEFINING TARGET ADDRESSES..................................................................................................................................18

SNMP Reference Manual
Page 3 of 37
DEFINING TARGET PARAMETERS...............................................................................................................................19
CONFIGURING NOTIFICATION FILTERS....................................................................................20
CREATING A NOTIFICATION FILTER .......................................................................................................................20
ASSOCIATING A FILTER WITH A NOTIFICATION PARAMETER.....................................................................22
CONFIGURING SOURCE ADDRESS CHECKING...........................................................................23
MATCHING EXACTLY ONE SOURCE ADDRESS ...................................................................................................25
MATCHING ANY SOURCE ADDRESS ........................................................................................................................25
MATCHING A SOURCE ADDRESS IN A SUBNET ..................................................................................................25
EXAMPLES............................................................................................................................................................ 27
NOAUTHNOPRIV SNMPV3 USERS .........................................................................................27
AUTHNOPRIV SNMPV3 USERS ...............................................................................................28
ADDITIONAL CONFIGURATION FOR SNMPV3 AGENT ENTITIES .............................................29
CONFIGURING CONTEXT NAMES............................................................................................................................29
ADDITIONAL CONFIGURATION FOR SNMPV1 AND SNMPV2 AGENT ENTITIES.....................30
CONFIGURING COMMUNITIES...................................................................................................................................30
EXAMPLES ............................................................................................................................................................................31
MIB ..........................................................................................................................................................................................33
STANDARD (PUBLIC) MIB .......................................................................................................33
STANDARD TRAPS ...........................................................................................................................................................34
ENTERPRISE (PRIVATE) MIB ....................................................................................................34
PRIVATE TRAPS ..................................................................................................................................................................35

SNMP Reference Manual
Page 4 of 37
Tables
Table 1 - registered snmpEngineID for AT-RG600.......................................................................................... 12
Table 2 – limitations to support of the standard MIB...................................................................................... 34
Table 3 – the sysInfo group ................................................................................................................................... 34
Table 4 - the sysUsers group ............................................................................................................................... 35
Table 5 – the sysAdmin group .............................................................................................................................. 35
Table 6 – Private Traps........................................................................................................................................... 36
Figures
Figure 1 - A manager Entity ..................................................................................................................................... 5
Figure 2 - An agent Entity......................................................................................................................................... 6
Figure 3 - HMAC expression .................................................................................................................................. 8
Figure 4 - vacmViewTreeFamilyMask .................................................................................................................. 14
Figure 5 – vacmViewTreeFamilyMask continued .............................................................................................. 15
Figure 6 - snmpNotifyFilterMask .......................................................................................................................... 21
Figure 7 - snmpNotifyFilterMask continued....................................................................................................... 22
Figure 8 - snmpTargetAddrTMask ....................................................................................................................... 25
Figure 9 ...................................................................................................................................................................... 25
Figure 10 .................................................................................................................................................................... 25
Figure 11 .................................................................................................................................................................... 26
Figure 12 .................................................................................................................................................................... 26

SNMP Reference Manual
Introduction to SNMP configuration Page 5 of 37
Introduction to SNMP configuration
This chapter introduces the configuration of SNMP module on AT-RG600 Residential Gateway family.
To describe the SNMP configuration process the following terminology is used:
• ENTITY
a network management element that consists of an SNMP engine and one or more applications.
• ENGINE
a component of an SNMP entity that consists of a message processing subsystem, a security
subsystem, an access control subsystem (as appropriate), and a dispatcher.
• APPLICATION
a component of an SNMP entity that determines the function of the entity. Applications include a
command generator, command responder, notification originator, notification receiver, proxy
forwarder, etc.
The SNMP entity that is commonly called a MANAGER is an engine plus a command generator application
and a notification receiver application.
FIGURE 1- A MANAGER ENTITY

SNMP Reference Manual
Introduction to SNMP configuration Page 6 of 37
The SNMP entity that is commonly called an AGENT is an engine plus a command responder and a
notification originator. Other types of entities are possible, because other combinations of engine and
applications are viable.
FIGURE 2- AN AGENT ENTITY

SNMP Reference Manual
SNMP configuration within the SNMPv3 administration framework Page 7 of 37
SNMP configuration within the SNMPv3
administration framework
The SNMPv3 Administration Framework is a configuration infrastructure for SNMPv3 users, but it can
also be used to remotely configure and administer SNMPv1 and SNMPv2c community strings.
Introduction
The SNMPv3 security administration framework provides a strong authentication mechanism,
authorization with fine granularity, complete access control, security level controls which include two
authentication algorithms1and an optional privacy protocol, and a MIB document for remote
configuration.
Security
SNMPv3 provides advanced security mechanisms for protecting against threats to management
operations. These security mechanisms are not new: they are taken from the SNMPv2 Draft Standards.
The following sections describe the potential threats and how SNMPv3 protects against these threats.
SNMPv3 addresses in particular the following four threats:
• MASQUERADE
the masquerade threat is when an unauthorized user attempts to carry out management operations
by assuming the identity of an authorized user. SNMPv3 can verify the identity of the originator of
the SNMPv3 message.
• MODIFICATION OF INFORMATION
modification of information is the threat that a user will (by malice or error) alter a message in
transit between the source and the destination, thereby carrying out unauthorized management
activity. SNMPv3 can verify that the SNMPv3 message was not altered in transit between the
originator and the recipient.
• MESSAGE STREAM MODIFICATION
message stream modification occurs when (by malice or error) management messages are
reordered, replayed, or delayed. SNMPv3 can verify that a received message is timely.
Mechanisms used by SNMPv3 security
SNMPv3 security protects against masquerade, modification of information, and message
stream modification by using the Hash-based Message Authentication Code (HMAC) with MD5
Message Digest Algorithm (MD5) in a symmetric, i.e. private, key mode. MD5, defined in
1Trivial authentication requiring only a correct user names and strong authentication based on an MD5 hash algorithm.

SNMP Reference Manual
SNMP configuration within the SNMPv3 administration framework Page 8 of 37
RFC1321, takes “as input a message of arbitrary length and produces as output a fingerprint or ‘message
digest’ of the input.”
HMAC, defined in RFC2104,
• computes an MD5 hash (H)on the concatenation of
(a) the shared secret key (K), which has been XORed with the hexadecimal value ‘36 ’(ipad),
and
(b) the SNMP message (text), which contains zero bytes in the digest field, to produce an
intermediate digest, and
• computes an MD5 hash on the concatenation of
(a) the shared secret key, which has been XORed with the hexadecimal value ‘5C ’(opad),
and
(b) the intermediate digest to produce the final digest.
The HMAC function is summarized by the following expression:
FIGURE 3- HMAC EXPRESSION
HMAC is used in the following manner to protect against threats to management operations:
• The sender and intended recipient of the SNMPv3 message share a secret key.
• When the sender constructs the outgoing message, the sender’s notion of the SNMP agent ’s time is
inserted into the message, and the digest field is padded with zeros. The HMAC function is then used
to compute a digest (“fingerprint”) over the concatenation of the sender ’s notion of the shared
secret key and SNMPv3 message.
• The digest is then inserted into the message at the position where the padding previously had been.
• The message is then sent.
• When the recipient receives the message, the digest in the incoming message is saved.
• The recipient inserts zeros into the incoming message at the position where the shared secret key
previously had been.
• In the same manner as the sender, the recipient uses HMAC to compute a digest of the incoming
message (with padding instead of a digest) and the recipient ’s notion of the shared secret key.
The recipient then compares:
• the digest computed over the incoming message,
• the digest that was saved from the incoming message.
If the shared secret key has not been compromised2, and if the two digests above exactly match, then
there is a high degree of confidence3that the following statements about the message are true:
2SNMPv3 cannot protect against the threat of compromised keys. If an unauthorized user knows a shared secret key, then that user can masquerade as another user, modify
messages in transit, and modify the message stream.

SNMP Reference Manual
SNMP configuration within the SNMPv3 administration framework Page 9 of 37
• The message origin is authentic. That is, the user that claims to have sent the message did in fact
send it. Otherwise, the digests would have been different.
• The message contents have not been altered in transit. Otherwise, the digests would have been
different.
When an SNMP agent receives a message, it verifies that the received message is timely by comparing
the time value inside the packet with the current time. If the time value from the packet is within a “safe
”window of the actual current time, the packet is accepted. If the time value from the packet is not
within the specified window, a Report PDU containing the agent ’s notion of current time is transmitted
to the sender of the received packet, and the agent discards the received packet.
If the original message was authentic, then the sender of the original message has the ability to resend
the request. The sender of the original message will update its notion of the SNMP agent ’s time using
the time value from the Report PDU. Then, the HMAC calculations will be performed again to obtain
the digest for the same request packet containing an updated time value.
If the original message was the result of message stream modification, and if the shared secret key has
not been compromised, then the sender would not find the time value from the Report PDU to be
useful. Without the secret key, the packet digest cannot be correctly recalculated.
Local configuration datastore
SNMP configuration information must be stored locally on the Residential Gateway filesystem in a plain
ASCII text file named snmpd.cnf.
It's possible upload such file via a ftp session (using the ftp daemon facility available on the Residential
Gateway) or via the swupdate feature.
Configuration file format
Each line of the configuration file has the format <TAG> <VALUE> where <TAG> is a keyword and
<VALUE> is a valid configuration value.
Entries may be continued across multiple lines by using a backslash ( \). White space (tabs, spaces, line-
feeds/carriage-returns) and blank lines in the file are ignored. Values that are strings containing white
space must be delimited with quotation marks (").
3It is computationally infeasible to threaten a system by trying all possible keys,especially if the administration policy for the system includes a periodic changing of the keys
which are configured.

SNMP Reference Manual
SNMP configuration within the SNMPv3 administration framework Page 10 of 37
Configuration for all SNMPv3 entities
Configuring SNMPv3 users
Configuration for at least one SNMPv3 user must be provided for an SNMP engine to send or receive
SNMPv3 messages on behalf of certain SNMP applications.
To configure an SNMPv3 user, add an usmUserEntry definition in the snmpd.cnf file accordingly
the following syntax:
usmUserEntry <usmUserEngineID> <usmUserName> <usmUserAuthProtocol>
<usmUserStorageType> <usmTargetTag> <AuthKey>
usmUserEngineID
is an OctetString which is the authoritative SNMP engine’s administratively-unique identifier. For a
detailed explanation of snmpEngineID, refer to the next section.
For Get, GetNext, GetBulk, and Set requests, the SNMP entity containing the command
responder application is authoritative. Therefore, the value of the usmUserEngineID field of the
usmUserEntry in the agent ’s configuration file will be localSnmpID.
For Trap messages, the SNMP entity containing the notification generator application is authoritative.
Therefore, the value of the usmUserEngineID field of the usmUserEntry in the agent ’s
configuration file will be localSnmpID.
usmUserName
is a human readable string representing the name of the user. This is the user-based security model
dependent security ID.
UsmUserAuthProtocol
is an OBJECT IDENTIFIER that indicates whether messages sent on behalf of this user to or from the
SNMP engine identified by usmUserEngineID can be authenticated, and if so, the type of
authentication protocol which is used. The value of usm-UserAuthProtocol can be
usmNoAuthProtocol or usmHMACMD5AuthProtocol.
usmUserPrivProtocol
is an OBJECT IDENTIFIER that indicates whether messages sent on behalf of this user to or from the
SNMP engine identified by usmUserEngineID can be protected from disclosure, and if so, the type of
privacy protocol which is used. The value of usmUserPrivProtocol must be
usmNoPrivProtocol.
UsmUserStorageType
is nonVolatile, permanent, or readOnly.

SNMP Reference Manual
SNMP configuration within the SNMPv3 administration framework Page 11 of 37
usmTargetTag
is a human readable string that is used to select a set of entries in the snmpTargetAddrTable for
source address checking. If the SNMP entity should not perform source address checking, then this field
should contain a dash (-).
AuthKey
is an OctetString represented as a sequence of hexadecimal numbers separated by colons. Each
octet is within the range 0x00 through 0x. If usmUserAuthProtocol is usmNoAuthProtocol,
then this user does not have an AuthKey, and this field should contain a dash (-).
This field can also be set to a human readable string representing the user ’s authentication password;
the password will be converted to a key at run time.
It's possible define more than one SNMPv3 user. The list of all the SNMPv3 user entries is named
usmUserTable.
Breakdown of an snmpEngineID
An snmpEngineID is a globally unique identifier for an SNMP entity. All SNMPv3 entities must
possess an snmpEngineID. The snmpEngineID of an SNMP agent can be retrieved by sending a
Get request to the agent for the MIB object snmpEngineID.
The following snmpEngineID are registered for AT-RG600 Residential Gateway models:
1.3.6.1.4.1.207.1.17.1 RG613TX
1.3.6.1.4.1.207.1.17.4 RG623TX
1.3.6.1.4.1.207.1.17.5 RG613TXJ
1.3.6.1.4.1.207.1.17.6 RG656BD
1.3.6.1.4.1.207.1.17.7 RG613LH
1.3.6.1.4.1.207.1.17.8 RG613SH
1.3.6.1.4.1.207.1.17.9 RG623LH
1.3.6.1.4.1.207.1.17.10 RG623SH
1.3.6.1.4.1.207.1.17.11 RG613BD
1.3.6.1.4.1.207.1.17.12 RG623BD
1.3.6.1.4.1.207.1.17.13 RG624A
1.3.6.1.4.1.207.1.17.14 RG624B

SNMP Reference Manual
SNMP configuration within the SNMPv3 administration framework Page 12 of 37
1.3.6.1.4.1.207.1.17.15 RG634A
1.3.6.1.4.1.207.1.17.16 RG634B
1.3.6.1.4.1.207.1.17.17 RG656LH
1.3.6.1.4.1.207.1.17.18 RG656SH
1.3.6.1.4.1.207.1.17.19 RG656TX
TABLE 1- REGISTERED SNMPENGINEID FOR AT-RG600
Configuring an agent to receive requests and send traps
This section describes how to configure SNMPv3 user information only. Additional configuration is
required for an SNMP agent to actually receive SNMP requests and send SNMP Traps.
When an SNMP agent receives an SNMPv3 request from an SNMP manager, the user sending the
message must be known to the agent’s SNMP engine. If the request is sent in a secure packet, the agent
must use the use ’s security key to authenticate the message. For this operation, the keys must be pre-
configured in the snmpd.cnf con figuration file.
When an SNMP agent sends an SNMPv3 Trap to an SNMP manager, the recipient user must be known
to the agent ’s SNMP engine. If the Trap is sent in a secure packet, the agent must use the user’s
security key to compute an authentication digest for the message. For this operation, the keys must be
pre-configured in the snmpd.cnf configuration file.
⇒ For each the following examples, the snmpEngineID for the agent is used
(localSnmpID), because the receiving SNMP engine is authoritative for the security
of SNMP request messages, and the sending SNMP engine is authoritative for the
security of SNMP Trap messages.
Configuration for authentication
The following usmUserEntry configures an SNMP agent engine with information about an SNMPv3
user whose name is “myV3AuthNoPrivUser”. This entry contains the user ’s authentication password.
An SNMP request message from this user (originating from another SNMP entity) can be received if the
message was sent using no security or using MD5 authentication. The SNMP agent can send Trap
messages to this user using no security or using MD5 authentication.
usmUserEntry localSnmpID myV3AuthNoPrivUser usmHMACMD5AuthProtocol
usmNoPrivProtocol nonVolatile whereValidRequestsOriginate
myV3UserAuthPassword

SNMP Reference Manual
SNMP configuration within the SNMPv3 administration framework Page 13 of 37
Configuration for no authentication
The following usmUserEntry configures an SNMP agent engine with information about an SNMPv3
user whose name is “myV3NoAuthNoPrivUser”. This user does not have an authentication password,
so the last field contains a dash (-). An SNMP request message from this user (originating from another
SNMP entity) can be received if the message was sent using no security.
The SNMP agent can send Trap messages to this user using no security.
usmUserEntry localSnmpID myV3NoAuthNoPrivUser usmNoAuthProtocol
usmNoPrivProtocol nonVolatile whereValidRequestsOriginate –
Additional configuration for SNMPv3 agent entities
Certain SNMP applications (which are normally associated with an SNMP entity acting in the "agent”
role) require more information in addition to the information about SNMPv3 users.
Configuring view-based access control
Configuration of view-based access control must be provided for the SNMP engine to correctly process
SNMPv1, SNMPv2c, or SNMPv3 messages. Configuring view-based access control is a process that
requires three steps:
• Define a family of view subtrees.
• Define a groupand its associated access rights.
• Assign an SNMPv3 user (or SNMPv1 community string, etc) to the group defined in step2.
The following sections describe each step of this process in more detail.
Defining families of view subtrees
To configure an view tree family, add an vacmViewTreeFamily definition in the snmpd.cnf file
accordingly the following syntax:
vacmViewTreeFamily <vacmViewTreeFamilyViewName> <vacmViewTreeFamilySubtree>
<vacmViewTreeFamilyMask> <vacmViewTreeFamilyType>
<vacmViewTreeFamilyStorageType>
vacmViewTreeFamilyViewName
is a human readable string representing the name of this family of view subtrees.
vacmViewTreeFamilySubtree
is an OBJECT IDENTIFIER that identifies a subtree of the MIB; e.g. enterprises.207. This value and

SNMP Reference Manual
SNMP configuration within the SNMPv3 administration framework Page 14 of 37
vacmViewTreeFamilyMask are used to determine if an OBJECT IDENTIFIER is in this family of
view subtrees.
vacmViewTreeFamilyMask
is an OctetString represented as a sequence of hexadecimal numbers separated by colons. Each
octet is within the range 0x00 through 0xFF. A zero length OctetString is represented with a dash
(-).
vacmViewTreeFamilyType
is included or excluded and indicates if the vacmViewTreeFamilySubtree is explicitly accessible
or not accessible in this family of view subtrees.
VacmViewTreeFamilyStorageType
is nonVolatile, permanent, or readOnly.
It's possible define more than one vacmTreeFamily. The list of all the vacmTreeFamily entries is
named vacmTreeFamilyTable.
Example:
vacmViewTreeFamilyEntry All iso - included nonVolatile
defines a subtree for the view named “All” that includes the entire set of MIB objects (iso is the root
node of the MIB tree).
The vacmViewTreeFamilyMask field allows restriction of the MIB view at a finer granularity than
that of the vacmViewTreeFamilySubtree and vacmViewTreeFamilyType pair. For instance,
a view can be restricted to one row of a table (see the example below).
The value - causes the corresponding vacmViewTreeFamilyMask to be a NULL string, which in
turn allows all entries ‘below’ the vacmViewTreeFamilySubtree entry to be visible, unless
cancelled by another vacmViewTreeFamilyEntry.
The vacmViewTreeFamilyMask is built using octets that correspond to the OID being restricted.
For example, one may wish to restrict a user’s view of the ifTable to only the second row, all
columns. The OID for ifEntry.0.2 is:
1.3.6.1.2.1.2.2.1.0.2
The vacmViewTreeFamilyMask is a series of ones and zeros used for masking out parts of the
tree. A zero indicates a WILD CARD (i.e, matches anything), and a one indicates an exact match must be
made. So:
FIGURE 4- VACMVIEWTREEFAMILYMASK

SNMP Reference Manual
SNMP configuration within the SNMPv3 administration framework Page 15 of 37
would require an exact match on all fields except the table column (i.e., the 0 in ifEntry.0.2 ).
Using the above example, the bits of the vacmViewTreeFamilyMask would be grouped into bytes,
and then the right end padded with ones if necessary to fill out the last byte:
Figure 5 – vacmViewTreeFamilyMask continued
So the vacmViewTreeFamilyMask entry would be:
ff:bf
Defining groups and access rights
To configure a group and its associated access rights, add a vacmAccessEntry definition in the
snmpd.cnf file accordingly the following syntax:
vacmAccessEntry <vacmGroupName> <vacmAccessContextPrefix>
<vacmAccessSecurityModel> <vacmAccessSecurityLevel>
<vacmAccessContextMatch> <vacmAccessReadViewName> <vacmAccessWriteViewName>
<vacmAccessNotifyViewName> <vacmAccessStorageType>
vacmGroupName
is a human readable string which is the groupname.
vacmAccessContextPrefix
is a human readable string which is an entire or partial context name used to match the context name in
(or derived from) a management request. A dash (-) represents the default context.
vacmAccessSecurityModel
is snmpv1 for SNMPv1, snmpv2c for SNMPv2c, or usm for SNMPv3.
vacmAccessSecurityLevel
is noAuthNoPriv for no authentication and no privacy, and authNoPriv is for MD5 authentication
with no privacy.
vacmAccessContextMatch
is exact or prefix to indicate how the context of a request must match
vacmAccessContextPrefix.
For example, if an authenticated management request is sent in context “at-rg656bd", and if the value of
vacmAccessContextPrefix and vacmAccessContextMatch are “at-rg656” and "prefix”,

SNMP Reference Manual
SNMP configuration within the SNMPv3 administration framework Page 16 of 37
then the context name in (or derived from) the request is determined to be a correct match to the
values in this vacmAccessEntry.
vacmAccessReadViewName
is a vacmViewTreeFamilyViewName (defined by at least one vacmViewTreeFamilyEntry)
identifying the view subtrees accessible for Get, GetNext, and GetBulk requests.
vacmAccessWriteViewName
is a vacmViewTreeFamilyViewName (defined by at least one vacmViewTreeFamilyEntry)
identifying the view subtrees accessible for Set requests.
vacmAccessNotifyViewName
is a vacmViewTreeFamilyViewName (defined by at least one vacmViewTreeFamilyEntry)
identifying the view subtrees from which objects may be included as VarBinds in Trap messages and
Inform requests.
vacmAccessStorageType
is nonVolatile, permanent, or readOnly.
Assigning principals to groups
A PRINCIPAL is generic term to refer to an SNMPv3 user or an SNMPv2c or SNMPv1 community string
(see RFC2571).
To assign a principal to a group, add one or more vacmSecurityToGroupEntry definition in the
snmpd.cnf file accordingly the following syntax:
vacmSecurityToGroupEntry <vacmSecurityModel> <vacmSecurityName>
<vacmGroupName> <vacmSecurityToGroupStorageType>
vacmSecurityModel
is snmpv1 for SNMPv1, snmpv2c for SNMPv2c, or usm for SNMPv3.
vacmSecurityName
is a human readable string which is the principal.
vacmGroupName
is a human readable string which is the groupname. The groupname must be defined by at least one
vacmAccessEntry.
vacmSecurityToGroupStorageType
is nonVolatile, permanent, or readOnly.
It's possible define more than one vacmSecurityToGroupEntry. The list of all the
vacmSecurityToGroupEntry entries is named vacmSecurityToGroupTable.

SNMP Reference Manual
SNMP configuration within the SNMPv3 administration framework Page 17 of 37
Configuring notifications
AT-RG600 family SNMP agent is designed to support SNMPv1 Traps, SNMPv2c Traps, or SNMPv3
Traps. To send TRAPs, it's necessary perform some basic SNMP engine configuration as defined in the
following sections.
Configuring notification is a process that requires four steps:
• Define a notification.
• Define a set of network addresses to which a notification should be sent.
• Define parameters to use when sending notifications to each of the target addressed identified in
step2.
• Optionally, define notification filters to reduce the amount of traps sent to the target addresses.
The following sections describe each step of this process in more detail.
Defining notifications
To configure a notification, add an snmpNotifyEntry definition in the snmpd.cnf file accordingly
the following syntax:
snmpNotifyEntry <snmpNotifyName> <snmpNotifyTag> <snmpNotifyType>
<snmpNotifyStorageType>
snmpNotifyName
is a human readable string representing the name of this notification.
snmpNotifyTag
is a human readable string that is used to select a set of entries in the snmpTargetAddrTable.
snmpNotifyType
is 1(trap) or 2(inform).
nmpNotifyStorageType
is nonVolatile, permanent or readOnly.
It's possible define more than one notification. The list of all the notification entries is named
snmpNotifyTable.
Example:
snmpNotifyEntry myFirstNotify myFirstNotifyTag 1 nonVolatile
snmpNotifyEntry mySecondNotify mySecondNotifyTag 1 nonVolatile

SNMP Reference Manual
SNMP configuration within the SNMPv3 administration framework Page 18 of 37
Defining target addresses
To configure a target address (to which a notification should be sent), add one or more
snmpTargetAddrEntry definition in the snmpd.cnf file accordingly the following syntax:
snmpTargetAddrEntry <snmpTargetAddrName> <snmpTargetAddrTDomain>
<snmpTargetAddrTAddress> <snmpTargetAddrTimeout> <snmpTargetAddrRetryCount>
<snmpTargetAddrTagList> <snmpTargetAddrParams> <snmpTargetAddrStorageType>
<snmpTargetAddrTMask> <snmpTargetAddrMMS>
snmpTargetAddrName
is a human readable string representing the name of this target.
snmpTargetAddrTDomain
is an OID which indicates the network type (UDP/IP,IPX,etc.). For UDP/IP transport type, the OID
value (in dotted format) is 1.3.6.1.6.1.1 or equivalent (in English name) snmpUDPDomain.
snmpTargetAddrTAddress
is a valid address in the snmpTargetAddrTDomain. For snmpTargetAddrTDomain equal to
snmpUDPDomain, a valid address would be 192.147.142.35 :0, where the value after the colon
is the UDP port number. This address is used as the destination address for outgoing notifications.
⇒ If the port number is specified as zero, the actual destination port used for the
outgoing notification message is set to the default 162.
snmpTargetAddrTimeout
is an integer which identifies the expected maximum round triptime (in hundredths of seconds) for
communicating with the snmpTargetAddrTAddress.
When an Inform is sent to this address, and a response is not received within this time period, the
SNMP entity will assume that the response will not be delivered. The default value of 1500 (15 seconds)
is suggested by RFC2573. If the outgoing message type is not Inform then this field is ignored.
snmpTargetAddrRetryCount
is an integer which identifies the number of times the SNMP entity will attempt to retransmit an Inform
when a response is not received. The default value of 3 is suggested by RFC2573. If the outgoing
message type is not Inform, then this field is ignored.
snmpTargetAddrTagList
is a quoted string containing one or more (space-separated) tags. These tags correspond to the value of
snmpNotifyTag in the snmpNotifyTable. A notification defined in the snmpNotifyTable will
be sent to the address specified in snmpTargetAddrTDomain if the notification’s
snmpNotifyTag appears in this list of tags.

SNMP Reference Manual
SNMP configuration within the SNMPv3 administration framework Page 19 of 37
snmpTargetAddrParams
is a human readable string that is used to select a set of entries in the snmpTargetParamsTable
snmpTargetAddrStorageType
is nonVolatile, permanent, or readOnly.
snmpTargetAddrTMask
is a bitfield mask for the snmpTargetAddrTAddress and appears in the snmpd.cnf file in the
same format as the snmpTargetAddrTAddress For notifications, the value must be
255.255.255.255:0 to indicate that the Trap or Inform message will be sent to a specific
address.
⇒ SNMP does not allow for the broadcasting of notifications. However, a notification
may be sent to more than one specific address by configuring more than one
snmpTargetAddrEntry with the same tag(s)in the
snmpTargetAddrTagListfield.
snmpTargetAddrMMS
is an integer which is the maximum message size (in bytes)that can be transmitted between the local
host and the host with address snmpTargetAddrTAddress without risk of fragmentation. The
default value is 2048.
Defining target parameters
To configure parameters to be used when sending notifications, add one or more
snmpTargetParamsEntry definition in the snmpd.cnf file accordingly the following syntax:
snmpTargetParamsEntry <snmpTargetParamsName> <snmpTargetParamsMPModel>
<snmpTargetParamsSecurityModel> <snmpTargetParamsSecurityName>
<snmpTargetParamsSecurityLevel> <snmpTargetParamsStorageType>
snmpTargetParamsName
is a human readable string representing the name of this parameter.
snmpTargetParamsMPModel
is 0for SNMPv1, 1for SNMPv2c, or 3for SNMPv3.The value of this field together with the value of
snmpTargetParamsSecurityModel indicates which type of notification should be sent.
snmpTargetParamsSecurityModel
is snmpv1 for SNMPv1, snmpv2c for SNMPv2c, or usm for SNMPv3.The value of this field together
with the value of snmpTargetParamsMPModel indicates which type of notification should be sent.
snmpTargetParamsSecurityName
is a human readable string which is the principal (an SNMPv3 user, or an SNMPv2c or SNMPv1
community string) to be used in the notification.