beautypg.com

Snmpv1 and snmpv2c, Snmp mib views for snmpv1 and snmpv2c, Snmp communities – Allied Telesis AlliedWare Plus Operating System Version 5.4.4C (x310-26FT,x310-26FP,x310-50FT,x310-50FP) User Manual

Page 1771

background image

SNMP Introduction

Software Reference for x310 Series Switches

C613-50046-01 REV A

AlliedWare Plus

TM

Operating System - Version 5.4.4C

67.13

SNMPv1 and SNMPv2c

Although software levels 2.6.3 and higher support the specific facilities of SNMP v1 and v2,
their documentation is available to provide backward compatibility with older network
management systems. The far superior security features offered by implementing
SNMPv3 should be used wherever possible.

The switch’s implementation of SNMPv1 is based on RFC 1157, A Simple Network
Management Protocol (SNMP)
, and RFC 1812, Requirements for IP Version 4 Routers.

When the SNMP agent is disabled, the agent does not respond to SNMP request
messages. The agent is disabled by default. The current state and configuration of the
SNMP agent can be displayed.

SNMP MIB Views for SNMPv1 and SNMPv2c

An SNMP MIB view is a arbitrary subset of objects in the MIB. Objects in the view may be
from any part of the object name space, and not necessarily the same sub-tree. An SNMP
community profile is the pairing of an SNMP access mode (read-only or read-write) with
the access mode defined by the MIB for each object in the view. For each object in the
view, the community profile defines the operations that can be performed on the object.

Pairing an SNMP community with an SNMP community profile determines the level of
access that the agent affords to an NMS that is a member of the specified community.
When an agent receives an SNMP message, it checks the community name encoded in the
message. If the agent knows the community name, the message is deemed to be
authentic and the sending SNMP entity is accepted as a member of the community. The
community profile associated with the community name then determines the sender’s
view of the MIB and the operations that can be performed on objects in the view.

SNMP Communities

SNMP communities were introduced into SNMPv1 and retained in version 2c. Although
the switch’s software still supports communities, this is to provide backward compatibility
with legacy management systems. Communities should not be used where a secure
network is required. Instead, use the secure network features offered by SNMPv3.

An SNMP community is a pairing of an SNMP agent with a set of SNMP application
entities. Communities are the main configuration item in the switch’s implementation of
SNMPv1 and v2, and are defined in terms of a list of IP addresses which define the SNMP
application entities (trap hosts and management stations) in the community.

Important community names act as passwords and provide minimal authentication. Any
SNMP application entity that knows a community name can read the value of any instance
of any object in the MIB implemented in the switch. Any SNMP application entity that
knows the name of a community with write access can change the value of any instance of
any object in the MIB implemented in the switch, possibly affecting the operation of the
switch. For this reason, take care with the security of community names.

When a trap is generated by the SNMP agent it is forwarded to all trap hosts in all
communities. The community name and manager addresses are used to provide trivial
authentication. An incoming SNMP message is deemed authentic if it contains a valid
community name and originated from an IP address defined as a management station for
that community.

When a community is disabled, the SNMP agent behaves as if the community does not
exist and generates authentication failure traps for messages directed to the disabled
community.