Simple Network Management Protocol
Network management software, such as CiscoWorks, uses the Simple Network Management Protocol (SNMP) to manage network devices. SNMP is the workhorse behind all those nice network diagrams, charts, and graphs. It queries the devices, collecting the data necessary to build the diagrams, charts, and graphs. SNMPv1[1] is supported on all Cisco routers. SNMPv2C is supported on all Cisco routers with IOS 11.3 or later. SNMPv2C supports bulk data transfers and more detailed error reporting than SNMPv1.
NOTE
SNMPv2C consists of SNMPv2, as defined in RFCs 1902 through 1907, and SNMPv2C, as defined in RFC 1901.[2]
Overview of SNMP
SNMP consists of managers and agents. The manager collects the data; the agent provides the data.
A manager can be part of a Network Management System (NMS) such as CiscoWorks. Agents reside on the device being managed, such as the router.
A relationship is set up between the manager and the agent so that the manager can get or set information on the agent. The manager sends SNMP messages to the agent requesting data or requesting that the agent set parameters with data specified by the manager. These messages are called gets and sets, respectively. The community of managers that can request data from the agent, or request it to set parameters, is defined using access control lists and a password. The password is called a community string. The manager includes the community string in all get and set requests. The agent, which is preconfigured with the community string, verifies that the requesting manager is allowed to perform gets and sets and that the community string is correct. The manager can request any parameter defined in the Management Information Bases (MIBs) supported by the platform running the agent. Figure 9-1 illustrates a manager requesting link status information from a router.
The management station wants to find out the operational status of serial interface 0 on the router. The management station issues an SNMP get request, requesting the MIB variable ifEntry.ifOperStatus.1. ifEntry is the list of variables that can be polled for any interface on an agent. IfOperStatus is one of the variables. 0.1 is an index value, in this case identifying interface serial 0. The community string "restricted" is included in the get request. The router responds to the request. The response indicates that the value of the requested variable equals 1. The MIB defines ifOperStatus values 1, indicating the status is up; 2, indicating the status is down; and 3, indicating the status is testing. Link serial 0 in the figure is up.
NOTE
MIB II is supported on all SNMP-capable routers. Interface variables are defined in MIB II. RFC 1213 defines MIB II.[3]
SNMP operates over UDP. SNMP also runs as a lower priority than other processes on the router. If the router is very busy running higher-priority tasks, SNMP messages can be dropped. Most manager configurations specify that more than one lost poll must occur before any state changes display.
SNMP enables you to collect a lot of information. Just about every statistic for every network device (and components within a device) and every protocol at all layers of the protocol stack can be gathered via SNMP. Sometimes the statistic being collected changes rapidly, and the manager is gathering information about the changing data, such as the number of errors occurring every minute on a flaky interface. It is tempting to use SNMP extensively and frequently to get the most accurate statistical data. Excessive SNMP traffic can adversely affect network performance, however, and therefore the amount of SNMP traffic needs to be carefully managed. Before you enable any management application, the amount of SNMP traffic (and other traffic, as well) generated by the application should be thoroughly understood.
Trap messages are sent by the agent to a management station. The traps are unsolicited and occur as the result of some event. The event may be a link down, a BGP connection failure, an authentication failure, or any number of other things. When the event occurs, the router sends an SNMP trap to the management station, informing the station of the event. The configuration of the management station dictates what is done with the trap. It may cause a piece of the network diagram to change colors, a message may be displayed on the screen, or an e-mail or page could be sent to a network manager.
SNMP provides the foundation for network management platforms, such as CiscoWorks.
CiscoWorks
Cisco networks can be managed with the assistance of CiscoWorks. CiscoWorks runs on top of a network management platform, such as HP OpenView, IBM NetView, or Sun Net Manager. The management platform provides general network diagrams, charts, and graphs, and CiscoWorks adds Cisco-specific entities, such as chassis views and device configuration management.
CiscoView is one of the CiscoWorks applications. CiscoView provides real-time views of networked Cisco devices. These views deliver a continuously updated physical picture of device configuration and performance conditions. The chassis views show front- and back-panel views of Cisco devices, including LED status lights. If you click a port shown in the chassis view, you can bring up a table of statistics related to the port, such as utilization, input and output errors, queue drops, collisions, and ignored packets. CiscoView also provides a dashboard-type view, which displays system performance of the Cisco device, such as memory usage, buffer usage, and CPU utilization. CiscoView is run from a centralized network management site from which you can review, reconfigure, and monitor essential device data from a simple GUI (that displays information such as dynamic status reports, performance statistics, and network inquiries) without having to physically check connections for each device, module, or port at every different or remote location.
The network management platform of choice and CiscoWorks work together to perform fault management, performance management, and configuration management. The diagrams, charts, and graphs rely mainly on SNMP to remain up to date.
The agent being managed by CiscoWorks must be configured to accept polls and to send traps to the CiscoWorks workstation.
Router Configuration for SNMP
Various global SNMP commands enable the router to be managed by CiscoWorks. All the global snmp commands begin with snmp-server. No specific one enables SNMP. The first snmp-server command entered enables both versions of SNMP on the router.
The router must be configured to use the same SNMP version supported by the management station.
The command to create the management community is as follows:
[no] snmp-server community string [view view-name] [ro | rw][access-list number]
The community string acts as a password between the managers and the agent. The management stations may have read-only (RO) or read/write (RW) SNMP access to the router. The CiscoWorks management station requires RW access for full manageability, specifically for the capability to set parameters, reload routers, and update configurations. SNMP is a very powerful tool. Almost all configuration and state information about the router can be read via the SNMP MIBs. Information obtained via SNMP read access could be used to learn routing tables and ARP tables, making it easier for someone to learn about specific devices and therefore specific areas of attack. SNMP write access allows configurations to be changed and links and routers to be reset. To limit which devices are allowed to read and/or write information to the router, use the access-list option. The list is a simple access list, specifying the address of the management station or a range of addresses with permitted management stations.
The only required command when enabling SNMP is snmp-server community. All the other SNMP commands are optional and provide fine-tuning of the collectable or settable information.
The view option in the snmp-server community command is used in conjunction with the following command:
snmp-server view view-name oid-tree {included | excluded}
This command limits which MIB objects an SNMP manager can access. The oid-tree, or Object Identifier tree, identifies the MIB subtree to be included or excluded. To identify a subtree, specify the top of the desired subtree using a text string consisting of numbers, such as 1.3.6.2.4, or the word, such as "system." Specifying system means that all MIB values in the system subtree are included or excluded. 1.3.6.2.1.2 is the numeric representation of iso.org.dod.mgmt.mib2.interfaces.
NOTE
Refer to the RFCs defining each individual MIB and to RFC 1902, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)," for the numeric representations of all object identifiers.
SNMP managers can send messages to users on virtual terminals and the console. The SNMP request that sends the message also specifies the action to be taken after the message has been sent, such as shut down the system. This is a very powerful tool. To enable this function, you must configure the snmp-server system-shutdown command. If you do not configure this command, the mechanism is not enabled.
Another powerful tool is the capability for TFTP servers to save and load configuration files via SNMP. You can limit this to servers specified in an access list using the snmp-server tftp-server-list number command, where number is the access list number.
The command to specify the host to which the traps are sent, and what trap types are sent, is as follows:
snmp-server host host [version {1 | 2c}] community-string [udp-port port] [trap-type]
If no trap-type is specified, all trap types enabled on the router are sent to the host. The version defines the SNMP version of the management station. The udp-port option changes the default port number.
Before any traps are sent to the specified hosts, the traps must be enabled globally. Some traps are enabled by default. Others must be enabled by the following command:
snmp-server enable traps trap-type trap-option
The snmp-server enable traps command enables the trap mechanism on the router for the specific traps. It does not specify a host to which to send them. Use this command to enable or disable traps of a certain type. When disabling traps, this overrides traps specified per host.
Another command is available to control traps on an interface basis. The interface subcommand to enable or disable link status traps on the configured interface is [no] snmp trap link-status. The traps are enabled on all interfaces by default.
For a host to receive traps, the host's address must be specified using the snmp-server host command, and the trap must be enabled globally, through either the snmp-server enable traps command, some other command, such as snmp trap link-status, or by default. Some configuration examples follow.
The configuration in Example 9-1 allows read-only access to any SNMP manager using community string "access." BGP traps are enabled and sent to hosts 172.16.1.200 and 172.16.1.201.
Example 9-1 Allowing Read-Only Access to Any SNMP Manager and Enabling BGP Trap
snmp-server community access RO
snmp-server enable traps bgp
snmp-server host 172.16.1.200 access
snmp-server host 172.16.1.201 access
A BGP external connection is established between routers 10.1.2.1 and 10.1.2.25. When the connection is cleared, traps are generated, as documented in Example 9-2.
Example 9-2 Clearing BGP External Connections Generates Traps
Bowler#clear ip bgp *
SNMP: Queuing packet to 172.16.1.200
SNMP: V1 Trap, ent bgp, addr 10.1.2.25
bgpPeerEntry.14.10.1.2.1 = 00 00
bgpPeerEntry.2.10.1.2.1 = 1
SNMP: Queuing packet to 172.16.1.201
SNMP: V1 Trap, ent bgp, addr 10.1.2.25
bgpPeerEntry.14.10.1.2.1 = 00 00
bgpPeerEntry.2.10.1.2.1 = 1
SNMP: Packet sent via UDP to 172.16.1.200
SNMP: Packet sent via UDP to 172.16.1.201
Version 1 traps are sent to both trap hosts. The router's address that is sending the traps is 10.1.2.25, which is the address of the outbound interface used when sending the packet to the trap host. The value for the MIB OID bgpPeerEntry.14.10.1.2.1, which represents the last BGP error code seen by this peer, on the connection to the peer with address 10.1.2.1, is 00 00, meaning no error was seen. The OID bgpPeerEntry.2.10.1.2.1 represents the BGP peer state, as seen by this peer for the connection to peer 10.1.2.1. A value of 1 means the state is idle.
In the configuration in Example 9-3, host 172.16.1.201 has been upgraded to SNMP version 2c, and this host receives only BGP traps. 172.16.1.200 receives only TTY traps. In addition, the source IP address of all SNMP traps is configured to be the IP address of the loopback interface, 172.16.2.25.
Example 9-3 Enabling SNMPv2C Traps and Specifying the SNMP Source IP Address
snmp-server community access RO
snmp-server enable traps bgp tty
snmp-server host 172.16.1.200 access tty
snmp-server host 172.16.1.201 version 2c access bgp
snmp-server trap-source loopback 1
When a user logs out of the router, the router sends TTY connection traps, as indicated in Example 9-4.
Example 9-4 Routers Send TTY Connection Traps When Users Log Out of the Router
#Telnet Boxer
Trying 10.1.1.1 … Open
User Access Verification
Password:
Boxer>logout
[Connection to Boxer closed by foreign host]
Boxer#
SNMP: Queuing packet to 172.16.1.200
SNMP: V1 Trap, ent enterprises.9, addr 172.16.2.25
ltsLineSessionEntry.1.66.1 = 5
tcpConnEntry.1.10.1.1.1.23.10.1.10.1.11000 = 5
ltcpConnEntry.5.10.1.1.1.23.10.1.10.1.11000 = 958
ltcpConnEntry.1.10.1.1.1.23.10.1.10.1.11000 = 45
ltcpConnEntry.2.10.1.1.1.23.10.1.10.1.11000 = 87
ltsLineEntry.18.66 =
The trap type is enterprises.9, which is generated when a router reload takes place or a TCP connection is closed.
ltsLineSessionEntry.1 represents the line session type. A value of 5 means a Telnet session generated the trap.
tcpConnEntry.1 represents the state of the TCP connection. The value 5 means the connection is closed. The next digits are the IP addresses of Boxer and the device that performed the Telnet into Boxer.
ltcpConnEntry.5 represents the length of time that the TCP connection was established, in hundredths of a second. So this connection was open for 9.58 seconds. The next two OIDs represent the number of bytes input for this TCP connection, and the number of bytes output for the connection—45 bytes were input, 87 output. The ltsLineEntry.18 displays the TACACS username, if TACACS is enabled. Example 9-5 shows the SNMPv2C BGP trap sent to 172.16.1.201.
Example 9-5 SNMPv2C BGP Trap Includes More Information Than the SNMPv1 BGP Trap
SNMP: Queuing packet to 172.16.1.201
SNMP: V2 Trap
sysUpTime.0 = 14423502
internet.6.3.1.1.4.1.0 = bgp.7.2
bgpPeerEntry.14.10.1.2.1 = 00 00
bgpPeerEntry.2.10.1.2.1 = 1
The version 2c trap includes more information than the version 1 trap. The system uptime is the time in hundredths of a second since the network management portion of the system was last reinitialized. The internet.6.3.1.1.4.1.0 OID, with a value of bgp.7.2, represents the specific trap, bgpBackwardTransition, which is generated when the connection state transitions from a higher numbered state to a lower numbered state, such as from established to idle. The traps in Example 9-6 show the BGP state entering the ESTABLISHED state.
Example 9-6 BGP State Enters ESTABLISHED
SNMP: V1 Trap, ent bgp, addr 172.16.2.25
bgpPeerEntry.14.10.1.2.1 = 00 00
bgpPeerEntry.2.10.1.2.1 = 6
SNMP: V2 Trap
sysUpTime.0 = 14425396
internet.6.3.1.1.4.1.0 = bgp.7.1
bgpPeerEntry.14.10.1.2.1 = 00 00
bgpPeerEntry.2.10.1.2.1 = 6
The internet.6.3.1.1.4.1.0 OID with value bgp.7.1 represents the bgpEstablished trap, and the peer entry value of 6 means the connection for the peer 10.1.2.1 is ESTABLISHED.
The configuration in Example 9-7 allows read-only access only to those IP addresses specified in access list 1, using community string "restricted." It also limits this host to view only a portion of the MIB, particularly the interface entries.
Example 9-7 Permitting Read-Only Access to IP Addresses Specified in an Access List
access-list 1 permit 172.16.1.200
snmp-server view interface_entries ifEntry included
snmp-server community restricted view interface_entries RO 1
No other SNMP manager can access the SNMP agent on this device with community string "restricted." If this is the only community string configured on the router, 172.16.1.200 is the only device that can read SNMP MIB variables; however, it cannot set variables. The view command configures the view named interface_entries and limits this view to the ifEntry variables only. The community command associates the defined view to the community string "restricted" and to access list 1.
Example 9-8 displays partial output from an SNMP walk on the ifEntry and the IP branches of the MIB.
Example 9-8 MIB Walk on ifEntry and IP Branches of MIB Before View Restrictions Are Placed on the Router
ObiWan:~# snmpwalk 172.16.1.7 restricted ifEntry
interfaces.ifTable.ifEntry.ifIndex.1 = 1
interfaces.ifTable.ifEntry.ifIndex.2 = 2
interfaces.ifTable.ifEntry.ifIndex.3 = 3
interfaces.ifTable.ifEntry.ifIndex.4 = 4
interfaces.ifTable.ifEntry.ifDescr.1 = Ethernet0
interfaces.ifTable.ifEntry.ifDescr.2 = Ethernet1
interfaces.ifTable.ifEntry.ifDescr.3 = Serial0
interfaces.ifTable.ifEntry.ifDescr.4 = Serial1
interfaces.ifTable.ifEntry.ifOperStatus.1 = down(2)
interfaces.ifTable.ifEntry.ifOperStatus.2 = up(1)
interfaces.ifTable.ifEntry.ifOperStatus.3 = down(2)
interfaces.ifTable.ifEntry.ifOperStatus.4 = up(1)
interfaces.ifTable.ifEntry.ifInOctets.1 = 720250042
interfaces.ifTable.ifEntry.ifInOctets.2 = 283245
interfaces.ifTable.ifEntry.ifInOctets.3 = 0
interfaces.ifTable.ifEntry.ifInOctets.4 = 761771001
interfaces.ifTable.ifEntry.ifOutOctets.1 = 779888827
interfaces.ifTable.ifEntry.ifOutOctets.2 = 228281
interfaces.ifTable.ifEntry.ifOutOctets.3 = 0
interfaces.ifTable.ifEntry.ifOutOctets.4 = 10994586
ObiWan:~# snmpwalk 172.16.1.7 restricted ip
ip.ipRouteTable.ipRouteEntry.ipRouteDest.172.16.1.0 = IpAddress: 172.16.1.0
ip.ipRouteTable.ipRouteEntry.ipRouteIfIndex.172.16.1.0 = 2
ip.ipRouteTable.ipRouteEntry.ipRouteMetric1.172.16.1.0 = 0
ip.ipRouteTable.ipRouteEntry.ipRouteNextHop.172.16.1.0 = IpAddress: 172.16.1.7
ip.ipRouteTable.ipRouteEntry.ipRouteType.172.16.1.0 = direct(3)
ip.ipRouteTable.ipRouteEntry.ipRouteProto.172.16.1.0 = local(2)
ip.ipRouteTable.ipRouteEntry.ipRouteAge.172.16.1.0 = 0
ip.ipRouteTable.ipRouteEntry.ipRouteMask.172.16.1.0 = IpAddress: 255.255.255.0
ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaPhysAddress.2.172.16.1.2 =
0:10:5a:e5:e:e3
ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaPhysAddress.2.172.16.1.7 =
0:0:c:76:5b:7d
NOTE
The snmpwalk command reads an entire branch of the MIB tree, as compared to an snmp get, which reads a single entry.
Example 9-9 shows the same snmpwalk commands after the view limitations are imposed.
Example 9-9 MIB Walk on ifEntry and IP Branches of MIB After View Restrictions Are Placed on the Router
ObiWan:~# snmpwalk 172.16.1.7 restricted ifEntry
interfaces.ifTable.ifEntry.ifIndex.1 = 1
interfaces.ifTable.ifEntry.ifIndex.2 = 2
interfaces.ifTable.ifEntry.ifIndex.3 = 3
interfaces.ifTable.ifEntry.ifIndex.4 = 4
interfaces.ifTable.ifEntry.ifDescr.1 = Ethernet0
interfaces.ifTable.ifEntry.ifDescr.2 = Ethernet1
interfaces.ifTable.ifEntry.ifDescr.3 = Serial0
interfaces.ifTable.ifEntry.ifDescr.4 = Serial1
interfaces.ifTable.ifEntry.ifOperStatus.1 = down(2)
interfaces.ifTable.ifEntry.ifOperStatus.2 = up(1)
interfaces.ifTable.ifEntry.ifOperStatus.3 = down(2)
interfaces.ifTable.ifEntry.ifOperStatus.4 = up(1)
interfaces.ifTable.ifEntry.ifInOctets.1 = 720250042
interfaces.ifTable.ifEntry.ifInOctets.2 = 334364
interfaces.ifTable.ifEntry.ifInOctets.3 = 0
interfaces.ifTable.ifEntry.ifInOctets.4 = 761771405
interfaces.ifTable.ifEntry.ifOutOctets.1 = 779888827
interfaces.ifTable.ifEntry.ifOutOctets.2 = 268919
interfaces.ifTable.ifEntry.ifOutOctets.3 = 0
interfaces.ifTable.ifEntry.ifOutOctets.4 = 10995692
End of MIB
ObiWan:~# snmpwalk 172.16.1.7 restricted ip
End of MIB
ObiWan:~# logout
The management station cannot read any portion of the MIB that is not explicitly included in the view definition.
| 
