There are two common ways to get management information about your network devices to a central server: syslog and SNMP. Both are fairly old protocols with long and complicated histories.

Syslog background

Syslog is one of the ancient protocols. It originated in the BSD UNIX TCP/IP implementation as a way of aggregating log messages over the network. Because of that history, syslog has a couple of quirks that don’t appear to make a lot of sense anymore but are still there.

First, it has a built-in severity level from 0 to 7 and a facility code between 0 and 23. The current standard, RFC 5424, indicates that these values are “not normative but often used.” The facility codes cover things like mail system, line printer subsystem, network news, and UUCP (Unix-to-Unix copy) subsystems — things that network devices don’t have.

The severity level is somewhat more useful, if also rather arbitrary.

Cisco devices don’t send level 0 alerts because level 0 is considered to indicate complete unrecoverable system disasters, in which case syslog is not reliable.

1 Emergency – Crisis
2 Alerts – Action must be taken immediately
3 Critical – Probably quite important
4 Error – Fairly important
5 Warning – Probably not important
6 Notification – Really not all that important
7 Informational – Mostly things you don’t care about at all
8 Debugging – Messages associated with debug commands

Traditionally, syslog has also had a priority value, which is severity level multiplied by facility code. It has no applicability to network devices.

Syslog was traditionally sent over UDP port 514 as unencrypted free-form text. In RFC 5424, this was changed so that now all syslog implementations are required to support TLS (Transport Layer Security) encryption, with UDP as an optional legacy alternative. However, the traditional UDP version is still completely pervasive.

On more recent “crypto” versions of Cisco IOS software, it’s possible to configure a TLS key. However, this presents several problems. First, you need to make sure your log server has the same key. Second, because it’s fundamentally session-oriented, it will generally be slower and more likely to cause resource problems on the network, the server, or the network device in cases where something is really wrong. Third, it’s vastly more difficult to configure. And fourth, your logging server has to support the same TLS implementation, and many don’t.

While it’s certainly true that legacy syslog’s lack of encryption is a serious security problem, I’ve always viewed its simplicity as a virtue. As long as you never send syslog messages through untrusted networks, I don’t see a problem with using it. If you must send these messages over the Internet, for example, then just put them in an IPsec VPN (virtual private network). So I always recommend using the legacy UDP version.

SNMP background

SNMP (Simple Network Management Protocol) supports three essential functions.

  1. It allows you to “get” from a central server to your devices to get current status information.
  2. It allows the device to send special alerts to the central server whenever certain interesting events occur.
  3. You can use the polling function to “set” configuration parameters.

Polling generally falls into two categories: periodic and ad hoc. Periodic polling is where your network management server queries the device on a schedule, generally every few minutes, to get the current values of a set of status indicators, statistical counters, or other parameters. Ad hoc queries are manually initiated by the operator to check on similar parameters.

These parameters are described in MIB (management information base) files, which are sort of like database schemas. They show the relationships between different tables of values, and describe what the values mean. In general, without the MIB you don’t know what to poll.

There are two ways the device can automatically send alerts to the server without being specifically polled for information: traps and informs. A trap is the traditional method. It’s a simple UDP packet fired off into the network with no confirmation of delivery and no retransmission mechanism, just a wing and a prayer. An inform is a more recent addition to the protocol that includes the ability to confirm the alert was delivered, and to retransmit if it wasn’t. Informs are one of the features introduced in SNMPv3.

I generally prefer to use SNMPv2c. Unlike version 1, it includes longer counter variables, which are important for keeping accurate statistics on faster interfaces. And unlike version 3, it doesn’t require complicated cryptographic key management. Similar to syslog, I don’t recommend allowing SNMP over untrusted networks. So the encryption and authentication features of version 3 are not strictly required.

I also don’t like using the “set” function in SNMP because it’s too hard to validate who made the changes, and too easy to make disastrous configuration errors. The problem is that it’s often exceptionally difficult to know exactly what you’re changing when you use the SNMP “set” feature.

Further, SNMP is fundamentally stateless. In many cases, configuration changes have to be done in a particular order. In other words, network device configuration is a stateful problem, and I consider SNMP to be essentially inconsistent with device configuration. As a result, I always disable the SNMP “set” feature.

Configuring syslog

Syslog is remarkably simple to configure. To get it working, you just need to define the IP address of the logging server and enable logging.

logging buffered 32000
logging host 172.16.1.1

This configuration fragment does two things. The first command enables local logging on the device and sets a buffer size of 32KB. This isn’t required for syslog, but I find it extremely useful to have log messages on the device. The second command sends those same log messages to the specified central log server.

Configuring SNMP

When you configure SNMP, you need to separately configure the traps and “gets,” and I recommend disabling “sets”. In the Cisco configuration syntax, SNMP “gets” are “reads” and “sets” are “writes.” The following shows an SNMPv2c configuration with traps and read-only polling.

snmp-server community CiscoWhisperer ro 99
snmp-server enable traps
snmp-server host 172.16.1.1 CiscoWhisperer
!
access-list 99 permit host 172.16.1.1
access-list 99 deny any log

In this configuration I’ve defined the community string “CiscoWhisperer.” This is an arbitrary value that you should think of as sort of an SNMP password. Bear in mind that this value gets passed through the network in clear text, so it’s not terribly secure. For this reason, I’ve also implemented ACL (access control list) number 99 to only allow SNMP polls from a single particular IP address, which would be the network management station. I’ve also assumed the same device is the SNMP trap receiver.

Notice the critical little keyword “ro” for “read-only” on the first command. This completely disables SNMP “set” or write requests.

You’ll also notice that I’ve set the same community string for traps as for polls. Frankly I’ve never understood the need for community strings in traps. I suppose you could use it to make sure the trap came from the right device and wasn’t spoofed somehow, but in practice I’ve never seen any network management station configured to check trap community strings.

It’s often a good idea to set a couple of standard variables on your network devices to help with troubleshooting, but you can consider it strictly optional.

snmp-server location Waterloo LAN switch
snmp-server contact Name, Phone number