Event Logging with Cisco

Introduction

Good afternoon, dear readers, in this article I want to consider one of the main ways of logging events in cisco – syslog. Also, in addition to it, we will consider snmp traps, let’s try to set up a “beautiful” collection of logs on the linux server. syslog logging in cisco is a rather old and inconvenient thing, about which write many who work with her. Various shortcomings and what is connected with them will not be considered in this article, only the minimum functions for setting up the server and network devices.

Theory

Let’s start with the fact that all logging happens right when you configure devices, as an example, when you switch from network device configuration to privileged mode, you will see a message on the screen:

R1(config)#exit
R1#
May 10 22:25:56.133: %SYS-5-CONFIG_I: Configured from console by console

This method is called console logging and it is enabled automatically on cisco network devices. Buffered logging is also enabled, which collects all log messages into RAM, to view them, just enter the “show logging” command. But let’s not talk about simple logging, our main task is to consider the main way to send messages to a third-party server or device, syslog and SNMP traps are suitable for these measures.

syslog

When using syslog, we need to understand what we want to transmit, for this we need Cisco Severity and Escalation Guidelineswhich describes each level of severity (severity) of messages:

1. Alerts – Urgent intervention required

2. Critical – Critical events

3. Errors – Error messages in the operation of the router

4. Warning – All kinds of warnings

5. Notifications – Various important notifications

6. Informational – Informational messages

7. Debugging – Debugging messages

For clarity, the test bench will use 7 and 5 message severity levels.

Also, for convenience, we will use the protocol NTPto synchronize the time of sending log messages between routers.

When messages arrive at the syslog server, it uses special rules and categories to write and sort into a specific file. Standard syslog categories include: User – messages generated by user processes, Kern – messages generated by the kernel, Mail – messages from the mail system, Daemon – messages generated by system daemons, Auth – messages related to user authorization, LPR – messages from the printing system, News – messages from the news server, UUCP – reserved for the UUCP system, Cron – messages received from cron.

Next come the so-called “locales” or categories (Local0 – Local7) reserved for use by the system administrator.

SNMP

SNMP – used to read / read and change data from network devices, there are 4 versions: 1, 2, v2c, 3. The main difference between the versions is security. Since version 3, snmp has undergone major changes and even its package looks different than in earlier versions. You can read more at any wikipedia.

SNMP traps – a trap that a Cisco device will send to a third-party SNMP server with a message to collect events occurring on a network device.

Practical part

syslog

Our test bench will be built in GNS3 and will consist of: linux server, switch and two cisco routers. First of all, let’s set up an NTP server to synchronize time between the router and two switches. For the starting link, or for our ntp server, let’s take R1, specify “stratum 1” for the starting point of synchronization with other devices:

R1(config)#ntp master 1

Next, on all other devices, specify the NTP server:

R2(config)#ntp server 11.10.10.1

Since the algorithm of the NTP protocol is not fast, it will take some time to wait for time synchronization between network devices. To track the status, you need the command:

R2#show ntp associations
  address         ref clock       st   when   poll reach  delay  offset   disp
 ~11.10.10.1      .LOCL.           1     39     64     0  0.000   0.000 15937.
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

Here NTP is still synchronizing, when there is *~ ip address, it will mean full synchronization between devices. To send logs to our server, use the command:

R1(config)#logging trap debugging
R1(config)#logging host 10.10.10.50 transport udp port 514
R1(config)#logging origin-id hostname

In this case, we redirect all log messages to the address of our server, and also specify the port – udp 514. We will enter the same commands on S1 and R2 of course, we will specify a static route towards our main network.

After a successful connection to the server, the network device will display a notification:

*May 10 09:32:23.147: %SYS-6-LOGGINGHOST_STARTSTOP: Logging to host 10.10.10.50 port 514 started - CLI initiated

Next, we go to our linux server, in which we need to configure the collection of logs. To successfully transfer the udp, tcp packet on the linux server, we need to change rsyslog.conf, namely, remove comments from four lines:

# provides UDP syslog reception
module(load="imudp")
input(type="imudp" port ="514")
# provides TCP syslog reception
module(load="imtcp")
input(type="imtcp" port ="514")

Next, we need to set up files for logging, I suggest creating a separate directory for each network device for each file:

$template dynFile, "/var/log/%HOSTNAME%/syslog.log"
*.*                                        ?dynFile

After restarting the rsyslog.service daemon, separate directories are created with the name of the ip address of the network device and the file. Namely:

At this stage, setting up a simple syslog server is over.

SNMP TRAPS

In the test bench, which will be exactly the same as when setting up syslog, the version of snmp traps is given in example 3. What is its difference from all the rest?

In version 3 added advanced security. We can create accounts, profiles and groups for which we can prescribe certain rules. These rules include the mode of reading and writing to sensors, as well as determining their availability. In the future, we will try to create a user and will transfer a standard profile (view), which already has some available sensors. Also in this version we added user authentication and encryption, you have the choice of which one to use:

• noAuthnoPriv – passwords are transmitted in clear text;

• AuthnoPriv – being authenticated, carried out using cryptographic algorithms;

• AuthPriv – support for authentication and encryption.

As mentioned above, there are many standard profiles, in order to find out which ones are available and which one suits you best, use “show snmp view”

Now let’s move on to configuring network devices, we need to enable the snmp server itself and create an access-list, remembering to specify a password, in ro or rw mode, depending on your needs.

R1(config)#access-list 1 permit host 10.10.10.50
R1(config)#snmp-server community cisco ro 1
R1(config)#snmp-server enable traps snmp

It is worth noting that snmp traps is more flexible in configuration than syslog, when enabled, you can specify in which mode these messages will be served:

R1(config)#snmp-server enable traps snmp authentication ?
  coldstart  Enable coldStart trap
  linkdown   Enable linkDown trap
  linkup     Enable linkUp trap
  warmstart  Enable warmStart trap

Above, the configuration of the snmp server version 2 was given, in the future these commands will not be required, but to understand the operation of the snmp-server, I advise you to start working with the v2c version.

The next step is to create our own profile, to which we transfer or exclude some sensors from it. We will also create a group and pass our profile there:

R1(config)#snmp-server view EXAMPLE 1.3.6.1.4.1.9.2.1.56.0 included
R1(config)#snmp-server view EXAMPLE 1.3.6.1.2.1.2.2.1.8.0 included
R1(config)#snmp-server view EXAMPLE 1.3.6.1.2.1.1.3.0 included
R1(config)#snmp-server group EX v3 auth read EXAMPLE

For the test bench, I decided to use the standard v1default profile, but no one forbids you from using your group described above, the main thing is to write down or exclude the necessary sensors.

After we create an admin user with sha encryption and a password of cisco123:

R1(config)#snmp-server user admin EX v3 auth sha cisco
R1(config)#snmp-server host 10.10.10.50 version 3 auth admin

To check the performance, I advise you to use snmpget on our linux server:

snmpget -u admin -l authNoPriv -a SHA -A cisco123 10.10.10.1 1.3.6.1.2.1.1.3.0
iso.3.6.1.2.1.1.3.0 = Timesticks: (71632) 0:11:56.32

Now let’s move on to setting up the linux server, namely, we will change the snmp.conf configuration file by uncommenting one line “mibs :”

Next we need to install snmpd, snmptrap, snmptt. In snmpd, you need to go to the configuration and change two lines, instead of a local connection to the daemon, allow any connection on port 162.

#agentaddress 127.0.0.1,[::1]
agentaddress udp:162, udp6:[::1]:162

You also need to configure all other utilities. All of them are located in the “/etc/snmp/” directory.

In snmptrapd.conf we need to create a user and set the traphandle:

authUser admin SHA cisco123
traphandle default snmptthandler

In snmptt.ini we change the parameters:

mode = daemon
net_snmp_perl_enable = 1
unknown_trap_log_enable = 1

Now all that remains is to restart snmpd and snmptt to apply the changes:

systemclt restart snmptrapd
systemclt restart snmptt

After sending a trap from a network device, our server receives the packet and writes it to the /var/log/snmptt/ directory

For example, let’s try to create loopback 100 and turn it off:

R1(config)#int loopback 100
R1(config-if)#no shutdown
May 22 08:45:01.490: %LINK-3-UPDOWN: Interface Loopback100, changed state to up
May 22 08:45:02.489: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback100  , changed state to up
R1(config-if)#shutdown
May 22 08:45:39.344: %LINK-5-CHANGED: Interface Loopback100, changed state to ad  ministratively down
May 22 08:45:40.344: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback100  , changed state to down

The snmptt.log file appeared on our server, which records our actions:

Mon May 10 04:41:45 2023 .1.3.6.1.6.3.1.1.5.4 Normal "Status Events" UNKNOWN - Link up on interface
6. Admin state: Loopback100. Operational state: 24
Mon May 10 04:41:57 2023 .1.3.6.1.6.3.1.1.5.4 Normal "Status Events" UNKNOWN - Link down on interface
6. Admin state: Loopback100. Operational state: 24

This completes the configuration of a simple snmptraps server!

Conclusion

In this article, I tried to consider setting up logging on the cisco server and network devices as simply as possible. From pleasant and useful, I leave the reader links to more detailed settings for these logging methods, as well as some useful commands: syslog, snmptraps, snmptrap, snmptraps v3, NTP.

In the next article, we will consider a deeper configuration of aaa accounting logging on cisco network devices.