For SNMPv1/v2c, access to an SNMP server by an
SNMP client is governed by a proprietary SNMP community table that
identifies those communities that have read-only, read-write, or administrative
permission to the SNMP MIB stored on a particular server.
When an SNMP server receives a request, the server
extracts the client’s IP address and the community name. The
SNMP community table is searched for a matching community. If a match
is found, its access list name is used to validate the IP address.
If the access list name is null, the IP address is accepted. A nonmatching
community or an invalid IP address results in an SNMP authentication
error.
Each entry in the community table identifies:
An SNMP community name
A user’s privilege level
An IP access list
Community Name
The community name acts as a password and is used
to authenticate messages sent between an SNMP client and a router
containing an SNMP server. The community name is sent in every packet
between the client and the server.
Privilege Levels
SNMP has three privilege levels:
Read-only—Read-only access to the entire MIB except
for SNMP configuration objects
Read-write—Read-write access to the entire MIB except
for SNMP configuration objects
Admin—Read-write access to the entire MIB
IP Access List
The IP access list identifies those IP addresses
of SNMP clients permitted to use a given SNMP community.
snmp-server community
Use to configure an authorized SNMP community for access
to the SNMP MIBs and to associate SNMPv1/v2c communities with SNMP
MIB views.
The community name serves as a password and permits access
to an SNMP server. The name can be up to 31 characters, and it must
be enclosed in quotation marks.
The maximum number of communities in each virtual router
is 32.
By default, an SNMP community permits only read-only access.
The view name allows configuration with available dynamic
views.
Example
host1(config)#snmp-server community “
boston” view view1 rw
Use the no version to delete
a community from the SNMP community table.
With dynamic configurable views and groups you
can fine-tune application features to a specific group, You can have
32 view entries (with distinct names) per virtual router. Because
there is no limit to the number of entries within a distinct view
name, you can configure complex views. You can also have 32 access
entries (with distinct names) per virtual router. All views are on
a per-virtual-router basis; although static views are on a per-virtual-router
basis, they cannot be altered. If you modify a view, the system deletes
the original entry and creates the new view. Therefore, if the new
view fails, the original view is no longer available.
SNMP v3 configurations are allowed only at the
maximum CLI privilege level (15).
snmp-server group
Use to dynamically configure server groups. You must access
the CLI at privilege level 15 to view or use this command.
Setting the server’s contact person and location
provides helpful identifiers for the SNMP server. These identifiers
are arbitrary and do not affect the server’s function, but they
are useful to have.
snmp-server contact
Use these commands to configure the SNMP server’s
contact person and the server’s location.
The contact is the person who manages the server.
The location is the server’s physical location.
Each of these parameters can be up to 64 characters.
Example
host1(config)#snmp-server contact Bob Smith
host1(config)#snmp-server location 3rdfloor
Use the no version of these
commands to clear the contact or location identifier from the SNMP
configuration.
The SNMP server must support a PDU with an upper
limit of 484 bytes or greater. There is no need to coordinate the
maximum packet size across the entire network. Many requests and responses
tend to be smaller than the maximum value.
snmp-server packetsize
Use to set the SNMP server’s maximum packet size.
Increase this value to improve the efficiency of the GetBulk
operation.
Example
host1(config)#snmp-server packetsize 1000
Use the no version to set the
SNMP packet size to the default maximum size, 1500 bytes.
You can set up the router to send memory warning
messages when memory utilization reaches a specified value.
memory
Use to configure memory warning parameters. You set a
high memory utilization value and an abated memory utilization value.
When the system reaches the high utilization value, it sends warning
messages. When memory usage falls to the abated utilization value,
the system stops sending warning messages.
Example
host1(config)#memory warning 80 70
Use the no version to return
to the default values, 85 for high utilization and 75 for abated memory
utilization.
You can set up the SNMP agent to compress the number
of interface instances in the standard interface and stack tables.
You can also control the interface numbering method used in the interface
tables.
Compressing Interfaces
You can compress interfaces by interface type and
by the administrative status of the interface. Compressing interfaces
removes them from the ifTable, the ifStackTable, and the ipAddrTable,
which increases table retrieval performance. For example, if you want
statistics kept only on IP interfaces, then you can compress all interfaces
except IP; subsequently, only IP interfaces will appear in the ifTable,
the ifStackTable, and the ipAddrTable.
To compress interfaces that have an administrative
status of down, use the snmp-server interfaces compress-restriction command.
To compress interfaces according to type, use the
snmp-server interfaces compress command. To see the list of interfaces
that you can remove, use the CLI help:
host1(config)#snmp-server interfaces compress
?
Atm Atm interface layer
Atm1483 Atm1483 interface layer
AtmAal5 AtmAal5 interface layer
. . . SonetVT SonetVT
interface layer
VlanMajor VlanMajor interface layer
VlanSub VlanSub interface layer <cr>
If you enter the snmp-server interfaces compress
command without keywords, the following interface types are removed
from the interface tables:
ip
ppp
ethernetSubinterface
hdlc
ipLoopback
ipVirtual
pppLinkInterface
pppoeInterface
slepInterface/ciscoHdlc
snmp-server interfaces compress
Use to remove interface sublayers from the ifTable, the
ifStackTable, and the ipAddrTable.
Use the no version to remove
the restriction and allow interfaces with an administrative status
of down in the ifTable, the ifStackTable, and the ipAddrTable.
Each interface in the ifTable is assigned an ifIndex
number. RFC 1213 required that ifIndexes use contiguous integers and
that the ifIndex be less than the value of the total number of interfaces
(ifNumber). More recent RFCs—1573, 2232, and 2863—removed
these restrictions to accommodate interface sublayers. The E-series
router implementation of SNMP derives index numbers in 32-bit values
that are unique on a given router. This numbering scheme can result
in large gaps in the ifIndex.
Legacy network management software that was designed
to work with RFC 1213 implementations expects contiguous integers
and can fail when the software encounters large gaps in the ifIndex.
By default, the router uses a numbering scheme
based on RFC 2863. For compatibility with RFC 1213, you can set up
the router to use contiguous numbers and to limit the values of the
ifIndex and the ifNumber.
snmp-server interfaces rfc1213
Use to set up the interface numbering method in the IfTable
to use contiguous integers, which provides compatibility with versions
of SNMP that are based on RFC 1213.
The maxIfIndex option sets the maximum
value of the ifIndex field that the system will allocate.
The maxIfNumber option sets the maximum
number of interfaces allowed in the interface tables.
Caution:
Reducing the value of the maxIfIndex and/or maxIfNumber
causes the router to automatically reboot to factory default settings.
When the IfIndex and IfNumber maximums are reached, the
system logs the event and ignores the creation of additional interfaces,
which means that new interfaces are not visible in the interface table.
