Setting Up SNMP

Configuring SNMP on Cisco devices is the basic method used by most network managers for maintaining and monitoring their network. Network management platforms and applications utilize SNMP heavily for data collection and event correlation of network devices. We'll focus here on the preferred way to set up Cisco devices for SNMP management using SNMPv1 examples. For more information on SNMP and community strings, refer to "Simple Network Management Protocol" in Chapter 8, "Understanding Network Management Protocols."

NOTE

Due to the ever-evolving SNMP technology (especially SNMPv3, currently), there is no discussion on the SNMPv3 set up in the Cisco devices. If you require up-to-date information regarding SNMPv3, please refer to CCO.

Essentially, there are four steps for setting up SNMP:

1. Enable SNMP on the Cisco devices.

2. Control SNMP trap messages.

3. Set the SNMP packet size to the maximum.

4. Control SNMP access using views and access lists.

Following subsections discuss these steps in more detail.

Enabling SNMP on Cisco Devices

By configuring SNMP, you define the Network Management Station's (NMS) IP address where you want the SNMP traps to go to as well as the read-only and read-write community strings for servicing SNMP requests.

On routers, use the following configuration:

 snmp-server host host snmp-server community host [ro|rw] 

This is the basic configuration. Subsequent sections include a look at views and access-lists in conjunction with the snmp-server community command.

On Catalyst switches, use the following configuration:

 set snmp trap enable set snmp trap revr_address revr_community set snmp community [read-only|read-write] string 

Please note that by default, routers have no RW community string configured, and the Catalyst switches do. You should reconfigure these strings before deploying the devices initially into the field. You also can define multiple trap destinations as well as multiple community strings if you don't only manage from a centralized location.

Controlling SNMP Trap Messages

There are several "knobs" you can turn to control how SNMP traps are generated. We'll identify three of those methods as they apply specifically to the routers. Catalyst switches currently don't have these knobs.

Use the snmp-server enable traps configuration command to control what traps are generated. You can override the traps sent from the command snmp-server host with this configuration command. With the snmp-server host command, you can control what traps go to which host. By default, all traps are sent when this command is executed. You can control the type of SNMP traps sent by defining the specific trap or traps at the end of the snmp-server enable traps command. On Catalyst switches, all traps are enabled by default when you enable the SNMP traps.

Source the traps from the Loopback0 interface using the configuration command snmp-server trap-source Loopback0. By doing this, you can control where traps are sourced from versus having multiple IP address sourcing the traps. By default, all traps are sourced from the outgoing physical interface's IP address. It's easier to track one IP address or hostname than multiple IP addresses or hostnames from a common host (Cisco device).

Control the flow of linkup/linkdown traps by using the interface configuration command no snmp trap link-status. Use this command under interfaces that are highly transient in nature, such as ISDN BRI/PRI interfaces. You may not need to track every time an ISDN interface goes up or down, so turning off the link-status traps on those interfaces is recommended.

Setting the SNMP Packet Size to the Maximum

By default, the router sets the SNMP packet size to either 484 bytes (prior to IOS 11.2) or 1500 bytes (11.2 IOS or higher). Sometimes, multiple varbinds are embedded within an SNMP get request that exceeds the PDU (Protocol Data Unit) size of the configured SNMP packet size. This situation places a high CPU demand on the router during the IP-SNMP process because of the IP fragmentation that needs to take place at the processor level. The Catalyst switches have a fixed SNMP packet size of 1500 bytes and won't be discussed further in this section.

If the MTU size or PDU size is set to the maximum, the router can throw the SNMP response into one packet, place it in the huge system buffer pool for delivery, and perform the IP fragmentation when sending the packet out the interface (based on the MTU size of the media). The maximum configurable allowed packet size prior to 12.0 IOS is 8192 bytes, 12.0 IOS and above 17940 bytes. The practical limit and current implementation for SNMP packet size is 3072 bytes, as discussed in Chapter 8. To set up the SNMP packet size use the following configuration command:

 snmp-server packetsize 3072 

Controlling SNMP Access Using Views and Access Lists

Looking at the percentage of unknown community strings relative to total number of SNMP packets received identifies unauthorized network management stations trying to access the router via SNMP gets or sets. For example, it is important to control who can and cannot access the router via SNMP, especially with read-write access (RW), if you want to protect against rogue auto-discovery routines and limit what different users can see via SNMP. One way to police this is with IP standard access lists defined at the end of the snmp-server community configuration command or with SNMP views. Following are examples of both.

To set up access lists with SNMP you'd configure the following:

 snmp-server community string ro 1 access-list 1 permit 10.1.2.3 

where 1 is the standard IP access list number permitting the appropriate host who can access the router with the Read-Only (ro) community string.

SNMP views are a way to restrict what MIB objects can be gathered by an SNMP host based on the community string. We'll use an example from a common issue seen by customers, dealing with SNMP-gets of routing tables or ARP tables.

The issue is that the routing and arp tables are not in lexicographical order, so the IP SNMP process has to reorder the routing or ARP table. If you have a few thousand routes, IP SNMP will churn on the processor, driving the router CPU through the roof. The way to deal with this is to restrict access to the ipRouteTable and ipNetToMediaTable MIBs, so NMS stations cannot poll those objects. To mask the routing table and ARP table from SNMP getRequests you'd have to configure the following:

 snmp-server view noarproute internet included snmp-server view noarproute ipRouteTable excluded snmp-server view noarproute ipNetToMediaTable excluded snmp-server view noarproute at excluded snmp-server community public view noarproute RO 

where noarproute is the name you give the view. The actual MIB object name can also be substituted with the actual MIB OID.