peer_snmpd_config(4) peer_snmpd_config(4)
peer_snmpd_config - SNMP master agent configuration
/etc/peer_snmpd_config
This file controls the behavior of the peer_snmpd(1M) daemon. It
contains information about manager applications, SNMPv1 community
definitions, and SNMPv2 party definitions. For information on the format
of v2 party definitions, please rfer to the section SNMPv2 CONFIGURATION.
The general format is:
MANAGER <addr> [ON TRANSPORT <name>] [SEND [ALL | NO | traplist]
TRAPS [TO PORT <#> ] [WITH COMMUNITY <name>]]
COMMUNITY <name> ALLOW op [,op]* [OPERATIONS] [USE encrypt
ENCRYPTION] [MEMBERS <manager> [,<manager>]* ]
where constructs enclosed in braces "[]" are optional and constructs
enclosed in braces and followed by a '*' may be repeated zero or more
times.
The MANAGER entries in the configuration file define SNMP trap
destinations. An example would be:
MANAGER server
SEND ALL TRAPS
TO PORT 999
WITH COMMUNITY public
Communities define spatial semantics, temporal semantics, and access
control policy. COMMUNITY entries determine which community strings are
valid. If no COMMUNITY entries are present then all community strings
will be accepted. An example of communities would be:
COMMUNITY public
ALLOW GET OPERATIONS
COMMUNITY superman
ALLOW ALL OPERATIONS
MEMBERS bigboss.megalith.com, 192.146.153.65
peer_snmpd implements Party based security for SNMPv2p packets. A
knowledge of SNMPv2 security issues (discussed at length in RFC 1445, RFC
1446, and RFC 1447) is helpful in understanding Party configuration.
Page 1
peer_snmpd_config(4) peer_snmpd_config(4)
A SNMPv2 entity is the actual process which performs the Network
Management operations by responding to Manager queries.
The general format is :
ENTITY <entityName> DESCRIPTION <string>
An example would be :
ENTITY peer_master DESCRIPTION "PEER Master Entity"
CONTEXT DEFINITIONS
Context definitions map directly to the context table in the party MIB
(RFC 1447). There are two major types, local and proxy contexts. The
function of a context definition is to inform the agent of a relationship
between a SNMPv2 context and a SNMPv2 entity. A local context is always
associated with a VIEW, which describes the constraints that are in
effect on this context. View definitions are described in sections
below.
The format for a local context definition is :
LOCAL CONTEXT <contextName>
VIEW <viewName>
REFERS TO ENTITY <entityName>
AS OID <oid>
An example would be :
LOCAL CONTEXT normalContext
VIEW normalView
REFERS TO ENTITY peer_master
AS 1.3.6.1.6.3.3.1.4.127.0.0.1.1
The format for a proxy context definition is :
PROXY CONTEXT <oid>
SOURCE PARTY <oid>
DESTINATION PARTY <oid>
AND CONTEXT <oid>
Each View associates a label with a set of included and excluded
subtrees. The definition corresponds to the view table in the party MIB.
The general format is :
VIEW [INCLUDE | EXCLUDE] SUBTREE <oid> [MASK <bitmask>]
Page 2
peer_snmpd_config(4) peer_snmpd_config(4)
The bitmask identifies which positions in the specified object identifier
are to be regarded as "wildcards" for the purpose of pattern-matching.
The following example view definition includes only the system and snmp
groups from MIB-II (RFC 1213) :
VIEW normalView
INCLUDE SUBTREE 1.3.6.1.2.1.1
INCLUDE SUBTREE 1.3.6.1.2.1.11
The access control entries define a policy that control communication
between the source and target parties with respect to a particular SNMPv2
context. The entries map directly to the access control list table in
the party MIB.
The general format is :
ALLOW <op>, [<op>]* OPERATIONS
SOURCE PARTY <srcPartyName>
DESTINATION PARTY <destPartyName>
CONTEXT <contextName>
As an example, the following access control definitions will enable a
SNMP Manager acting as party "initialMgrParty" to perform get, and getnext
operations on a SNMP Agent acting as party "initialAgtParty" :
ALLOW SIMPLE-GET, GET-NEXT, OPERATIONS
SOURCE PARTY initialMgrParty
DESTINATION PARTY initialAgtParty
CONTEXT normalContext
ALLOW RESPONSE, NOTIFY OPERATIONS
SOURCE PARTY initialAgtParty
DESTINATION PARTY initialMgrParty
CONTEXT normalContext
Such a configuration would allow the manager and agent to communicate
correctly.
A party definition is used to establish initial values for both
authentication and encryption keys, if used. Party definitions map
directly to the party table in the party MIB.
The general format is :
LOCAL PARTY <partyName> ON TRANSPORT <transport>
AT <ADDR>
USING <NO | MD5> AUTHENTICATION
[<WITH <key> AS KEY>]
AND <NO | DES> ENCRYPTION [<key>]
Page 3
peer_snmpd_config(4) peer_snmpd_config(4)
AS <oid>
If MD5 authentication is used, then the key has to be provided in the
next line of configuration.
The following definition complements the examples given in the preceding
sections, configuring 2 parties for MD5 authentication :
LOCAL PARTY initialAgtParty ON TRANSPORT snmpUDPDomain
AT 0x7f00000100a1
USING MD5 AUTHENTICATION
WITH 0x7468973746869737468697374686933 AS KEY
AND NO ENCRYPTION
AS 1.3.6.1.6.3.3.1.3.127.0.0.1.3
LOCAL PARTY initialMgrParty ON TRANSPORT snmpUDPDomain
AT 0x7f00000100a1
USING MD5 AUTHENTICATION
WITH 0x7468973746869737468697374686933 AS KEY
AND NO ENCRYPTION
AS 1.3.6.1.6.3.3.1.3.127.0.0.1.4
The peer_snmpd daemon is based on PEER Networks' PATROL product. PEER
Networks is a division of BMC Software Inc.
/etc/peer_snmpd_config
peer_encaps(1M), peer_snmpd(1M),
PPPPaaaaggggeeee 4444 [ Back ]
|
