Configuring SNMP on Switches, and Syslog



This article follows up on last month’s article, Configuring SNMP in Cisco Routers. We’ll talk briefly about SNMP and switches, and also about Syslog.

previous article  Configuring SNMP in Cisco Routers




Syslog is a UNIX process that handles error and status message logging on behalf of system and other processes (daemons). The Event Viewer subsystem on NT is a direct NT counterpart. And there are also free (and not-so-free) syslog daemons now available for NT. For example, Cisco Resource Manager Essentials  includes a syslog message receiver, and syslog reporting functionality.

The command “logging address” on a router tells the router to copy console messages to syslog on the specified system (address). You can alternatively send the console messages via SNMP traps by enabling the syslog traps, as we saw in the last article. The figure below illustrates this process.

If you have CiscoWorks installed , syslogd is set up to log messages to the file /var/log/nmslog, at least on UNIX. If you do a “tail  -f  /var/log/nmslog” command you can watch messages as they get appended to this file. (Go into and out of config mode on a router to test this — of course you need to have put in that logging command if you’re going to see anything).

If you have the old CiscoWorks (legacy CiscoWorks? I doubt the product manager wants me calling it that!), then it provides a process called nmlogd, that sends each appended line in /var/log/nmslog as an SNMP trap to the SNMP trap port, 162, on the same system. This allows the messages to be handed off to HP OpenView or your other primary network management platform. Which in turn may have a trouble ticket system bolted onto it.

The virtue of this is that it provides an easy way to get the console messages to your trouble ticket system, without UNIX scripting (or NT PERL scripting, or vendor-supplied shims to pull in the messages from /var/log/nmslog).

The drawback is that you may not want those messages going into the trouble ticket system. They’re arguably useful messages, but they can be a bit overwhelming, and you’re probably going to have enough other SNMP traps and other indications to open tickets and initiate fire-fighting efforts. With RME, you can instead keep them in the separate syslog log file, and still produce useful reports telling you what’s been happening among your routers and switches.

The more insidious effect of nmlogd is that it not only may help you fill your disk or trouble ticket database, but it also can bring your CPU to its knees. The problem is that as each line appends to /var/log/nmslog, a separate SNMP trap gets sent, using the HP OpenView snmptrap command (if you have HPOV). That means a shell invocation per line, a fairly hefty UNIX amount of processing. Each one may only be a sub-second hit on the CPU, but when you’re getting 10’s of messages per second, it can be substantial.

SNMP in Cisco Switches


Note that some Cisco switches run IOS variants. For those switches, the SNMP-related commands should be approximately those discussed in the previous article. Here, we’ll focus on XDI-based switches (those with the Cat5000-type command line interface, CLI). And we’ll look at what’s in software release 4.5.

This command lets you specify the community strings. Defaults are public, private, secret. The read-write-all community string allows you to change the community strings. Unfortunately, the XDI switches only allow one community string per access level. Doing the command without a community string at the end removes the community string for the specified access level.

Enables or disables RMON support in the switch (ordinary mini-RMON or limited RMON version 1 MAC-layer statistics).
Allows access to RMON MAC layer statistics, history, events, and alarms groups (and on Token Ring, some of the Token Ring RMON groups). While disabled by default, can be useful in watching all ports on a switch to see which ones have high utilization, broadcast, multicast, collision or error rates.

This enables or disables specific traps or all traps. Good stuff! (For details, see the manual — I don’t want to reproduce all that fine detail here!)

This specifies which system SNMP traps are sent to, using what community string. Part of basic SNMP configuration on the switch. You can do this multiple times, to add systems to the trap receiver table. The command, clear snmp trap {receiver_address} clears a receiver from the table. Or you can clear snmp trap all to clear all receivers.

Then there are the more obscure SNMP commands in the XDI switches.

This enables the Network Analysis Module, NAM. It’s not much use if you don’t have one.

The lets the NAM receive the NFFC cache data. You need a Netflow Monitor license to visit the Cisco URL and receive the password required to enable this feature (the password in the command).

Enable or disable your vlan agent. If you have a NAM, this is a way to load it down watching things on a per-VLAN basis. If it is not overworked, that’s a reasonable thing to do.

Enables or disables RMON VLAN mode: NAM statistics by VLAN vice source MAC address.

Finally, to see what you’ve wrought, there’s show snmp. If you like testing what you’ve done, to make sure traps get sent, received, and processed correctly, there’s also the useful:

For syslog, the set logging server commands allow you to enable syslog messages, configure where they get sent, and tweak the various parameters.