From doing this network management work, it is apparent that Cisco has been adding a little here, a little there, to the SNMP capabilities of the routers and switches. Furthermore, my previous articles on Configuration for Manageability only scratch the surface of the topic. So it seems like it might be useful to us all to take a look at
Cisco SNMP features and what they buy us in the way of router/switch manageability. There’s enough to cover that this will be (at least) a two-article series.
Overview of Capabilities
Cisco routers and switches contain SNMP agents that can respond to standard SNMP get and set operations. That is, a management station can ask the Cisco device for information via an SNMP get, or it can tell the device to change some setting or take some actions, via a set operation. The device can also spontaneously originate traps or SNMPv2c inform notifications. In addition to SNMP, Cisco routers can also be managed via syslog reporting.
Configuring SNMP Access in Routers
The first thing you need to do is to enable SNMP access. This is done by configuring community strings, which act somewhat like passwords. (The difference is that there can be several community strings and that each one may grant different forms of access). Here’s what this might look like when configured:
snmp-server community public ro
snmp-server community ourCommStr ro
snmp-server community topsecret rw 60
snmp-server community hideit ro view noRouteTable
access-list 60 permit 10.1.1.1
access-list 60 permit 10.2.2.2
The first two lines allow read-only (get) SNMP access using either string. We configure our management stations with “ourCommStr” so we can easily cut off access via the well-known community string “public” if we so wish. (Note: non-IOS-based Cisco switches apparently do not allow multiple read-only community strings).
The third line configures the read-write (get/set) SNMP community string. This should not be the well-known string “private” (unless you like having an insecure network). The “60” restricts access to sources permitted via standard access-list 60 (the sample has shown lists the individual network management stations permitted to do read-write SNMP operations, you could also use a wildcard mask to allow all stations on selected subnets access).
The fourth line says that those using the community string “hideit” are restricted to information in the view named “noRouteTable”. This might be used to keep management stations (and HPOV Network Node Manager) from pulling huge BGP / Internet routing tables from selected routers, for example:
snmp-server view noRouteTable internet included
snmp-server view noRouteTable ip.21 excluded
snmp-server view noRouteTable ip.22 excluded
snmp-server view noRouteTable ifMIB excluded
Configuring SNMP Traps in Routers
The next thing you’ll probably want to do is get those very useful trouble-indicators, SNMP traps, sent to your management station(s). The way to configure this is as follows:
snmp-server host 10.1.1.1 public
This sends any and all SNMP traps the router sends to host
10.1.1.1 using community string “public”. (There’s no point in exposing your real community strings here — I’d just use “public” unless I ran across some incredibly picky network management software that was silly enough to try to enforce “correct” community strings on inbound traps).
If you wish to be more selective, you can list all the varieties of traps that go to each host:
snmp-server host 10.1.1.1 public snmp bgp
snmp-server host 10.2.2.2 public snmp frame-relay
This says that
10.1.1.1 is to get any SNMP or BGP traps, and
10.2.2.2 gets SNMP and frame relay traps.
This is a good way to nip any undesired messages at the source, rather than wasting network bandwidth on them, only to throw them away using HPOV or your trouble ticket system. On the other hand, life is too short to be diddling what traps go where on more than a few routers.
There is a long list of flavors of traps you can control in this fashion. Check the IOS manual or the router help for the latest items. Note that all the flavors of traps for a particular destination host go on one and the same (long!) line. Omitting any flavors list means they all get sent to that host.
You can also alter whether SNMP version 1 or 2c traps are sent, and what UDP port the traps are sent to.
If the above is all you configure, you may notice some deafening silence. You need to turn on the sending of traps in the first place — the above commands just control who gets which traps. Turn on trap sending by configuring:
snmp-server enable traps
This turns on all the varieties of traps. You can also turn on specific traps, by appending them to the above command, one trap variant at a time. Some allow for further specificity. For example
snmp-server enable traps frame-relay
snmp-server enable traps envmon temperature
snmp-server enable traps bgp
snmp-server enable traps snmp
This says the router should send the standard SNMP traps, and also BGP, Frame Relay, and Environmental Monitor traps (but only the temperature type of envmon traps).
One intriguing variety of traps you can enable is the config traps. This records on your management station that someone has configured the router. If you have way too many hands with enable password access, this can be a valuable troubleshooting tool (“what changed, and who did it”).
Another useful variety of traps is the
Syslog option to this command. This causes router console messages to be repackaged as
SNMP traps and sent to (selected) management stations. I see this as primarily useful in a PC environment, where you don’t wish to run freeware Syslog on NT and are perhaps using HPOV ProSuite or
SNMP as a trap receiver. If you wish to use the Syslog reporting in
CiscoWorks 2000 (CW2000) Resource Manager Essentials (RME), you will need to send console message to management station via
Syslog. Turning on the
Syslog trap option would then double the amount of such traffic on your network.
You probably do not want to invoke the “tty” option on the SNMP-server enable traps command. The TTY traps inform you of termination of a telnet session, which can get rather chatty and annoying. They are primarily for “milking machine” situations, where protocol translation maps some bit stream across a TCP connection between paired access servers.
You can control linkUp/linkDown traps on the interface level. To avoid hearing about every call your ISDN backup interface makes, configure:
0/0 no snmp trap link-status
Other SNMP Commands in Routers
The above is the most important part of SNMP. To keep this brief, here is a sample of some other things you might wish to configure:
snmp-server contact Orville Wright, Network Operations, (999) 123-4567
snmp-server location Engineering Dept., Floor 6, Building A-20, New York City
snmp-server tftp-server-list 60
no snmp-server trap-authentication
interface loopback 0
ip address 10.5.5.5 255.255.255.255
The first two lines specify the SNMP-retrievable contact and location. Useful, particularly if you have a lot of devices with different owners.
system-shutdown command allows a certain SNMP set operation to trigger a router reboot. CiscoWorks and RME use this when upgrading routers.
The TFTP server list allows you to restrict the TFTP servers used by SNMP-triggered TFTP operations. CiscoWorks and RME can use TFTP to move configuration files and IOS images, so you might well want to restrict the sources/destinations for better security. The list of servers might well be the same access list 60 that lists management stations permitted to do SNMP set operations.
You might well want to set the trap source address to be that of the loopback interface. Many sites wish to use this as the official management address of the router. This is a good practice, since when a key interface is down, network management software may be unable to talk to the router. If you ensure that the device name always resolves first to the loopback address (which depends on knowing you DNS server software), then there is less likely to be a problem with connectivity due to the downed interface. Setting the trap source to this address then ensures that when reverse name mapping resolves the loopback address to a hostname, the correct name is used. This means the network management software will be able to identify the device in question and, if appropriate, turn the icon red.
Less important SNMP-related router commands:
snmp-server chassis-id 123-45678
snmp-server packetsize 1500
snmp-server queue-length 1
snmp-server trap-timeout 30
The chassis ID defaults to the software chassis id, burned into the CPU card on the router. You may wish to change this to the external serial number, for automated SNMP updating of your records. (Generally, this is under-appreciated until you try to RMA a dead router that you don’t know the serial number of, or didn’t purchase support for). I’m not quite sure doing this is best practice, but it might be convenient.
Packet size specifies how big an SNMP get or set is allowed. The default is now 1500 bytes. Increasing the setting may allow more information to be transferred in one operation. If you have MIB’s with the table with many entries in a row, then this is useful to avoid tooBig errors. (SunNet Manager used to do this with the old Cisco MIB). Increasing the number with older IOS releases, from 484 to 1500, seems like a good bet.
Queue-length and trap-timeout refer to retransmission queue for SNMP traps. When an interface fails, the router may be temporarily unable to send the linkDown trap. This might be due to routing protocol convergence, the need to dial up HQ, or other causes. The router will then periodically (every 30 seconds, by default) re-try sending the SNMP trap(s) it couldn’t send. The trap-timeout changes this retry interval, default 30 seconds. The queue-length is how many traps get saved for retransmission in this fashion, default 10.
If you don’t have dial backup, you might wish to set the queue-length to 1. (Is zero allowed?) Otherwise, when a link outage is resolved, you then get a bunch of very stale and old traps telling you about the outage you just fixed.
Configuring SNMP on Switches, and Syslog