SNMPD.EXAMPLES

NAME

DESCRIPTION

man page defines the syntax and behaviour of the various
configuration directives that can be used to control the
operation of the Net-SNMP agent, and the management information
it provides.

This companion man page illustrates these directives, showing
some practical examples of how they might be used.

AGENT BEHAVIOUR

Listening addresses

The default agent behaviour (listing on the standard SNMP UDP port on
all interfaces) is equivalent to the directive:

agentaddress udp:161

or simply

agentaddress 161

The agent can be configured to only accept requests sent to the
local loopback interface (again listening on the SNMP UDP port), using:

agentaddress localhost:161 # (udp implicit)

or

agentaddress 127.0.0.1 # (udp and standard port implicit)

It can be configured to accept both UDP and TCP requests (over both IPv4
and IPv6), using:

agentaddress udp:161,tcp:161,udp6:161,tcp6:161

Other combinations are also valid.

Run-time privileges

The agent can be configured to relinquish any privileged access once it
has opened the initial listening ports. Given a suitable "snmp" group
(defined in /etc/group), this could be done using the directives:

agentuser nobody
agentgroup snmp

A similar effect could be achieved using numeric UID and/or GID values:

agentuser #10
agentgroup #10

SNMPv3 Configuration

Rather than being generated pseudo-randomly,
the engine ID for the agent could be calculated based on the MAC address
of the second network interface (eth1), using the directives:

engineIDType 3
engineIDNic eth1

or it could be calculated from the (first) IP address, using:

engineIDType 1

or it could be specified explicitly, using:

engineID "XXX – WHAT FORMAT"

ACCESS CONTROL

SNMPv3 Users

The following directives will create three users, all using exactly
the same authentication and encryption settings:

The group directives must be repeated for
both SNMPv1 and SNMPv2c requests.

The com2sec security name is distinct from the community
string that is mapped to it. They can be the same ("public")
or different ("mynet"/"private") – but what appears in thegroup directive is the security name, regardless of
the original community string.

Both of the view directives are defining simple OID
subtrees, so neither of these require an explicit mask.
The same holds for the "combined subtree2 view defined below.
In fact, a mask field is only needed when defining row slices
across a table (or similar views), and can almost always be omitted.

In general, it is advisible not to mix traditional and VACM-based
access configuration settings, as these can sometimes interfere
with each other in unexpected ways. Choose a particular style
of access configuration, and stick to it.

Typed-View Configuration

A similar configuration could also be configured as follows:

view sys2View included system
view sys2View included .1.3.6.1.2.1.25.1

This defines an explicit boolean monitor entry, looking for any process
using more than 10MB of active memory. Such processes will be reported
using the (standard) DisMan trap mteTriggerFired,
but adding an extra (wildcarded) varbind hrSWRunName.

This entry also specifies an explicit user (me, as defined
earlier) for retrieving the monitored values, and building the trap.

Objects that could potentially fluctuate around the specified level
are better monitored using a threshold monitor entry:

monitor -D -r 10 "network traffic" ifInOctets 1000000 5000000

This will send a mteTriggerRising trap whenever the incoming
traffic rises above (roughly) 500 kB/s on any network interface,
and a corresponding mteTriggerFalling trap when it falls below
100 kB/s again.

Note that this monitors the deltas between successive samples (-D)
rather than the actual sample values themselves. The same effect
could be obtained using:

The same proxy directives would also work with
(incoming) SNMPv3 requests, which can specify a context directly.
It would probably be more sensible to use contexts ofremotehost1 and remotehost2 – the names above were
chosen to indicate how these directives work together.

Note that the administrative settings for the proxied request
are specified explicitly, and are independent of the settings
from the incoming request.

An alternative use for the proxy directive is to pass
part of the OID tree to another agent (either on a remote host
or listening on a different port on the same system),
while handling the rest internally:

proxy -v 1 -c public localhost:6161 .1.3.6.1.4.1.99

This mechanism can be used to link together two separate SNMP agents.

A less usual approach is to map one subtree into a different area
of the overall MIB tree (either locally or on a remote system):

Note that the timeout and retry settings can be asymmetric
for the two directions, and the sub-agent can poll the master agent
at regular intervals (600s = every 10 minutes), to ensure the
connection is still working.