Hello and welcome back to the CCNA Series on IP Services. In the previous posts, we discussed DHCP and First Hop Redundancy protocols. In this post, we will conclude the series by going through two important Network Management protocols: SNMP and Syslog. We will start with some theoretical background and then move on to practical configurations of the concepts.

Simple Network Management Protocol (SNMP)

The Simple Network Management Protocol (SNMP) is the foundation of network management. It provides a standard framework for monitoring (and managing) devices on a network. There are three components in SNMP:

  1. The SNMP manager: This is a device that uses SNMP to manage or control devices on a network. The SNMP Manager in this case is usually a Network Monitoring System. Typically, you install a Network Monitoring Software that uses SNMP to monitor and control devices on the network. Some examples of network monitoring software (in ascending order of cost) include:
    1. MRTG: Multi-Rate Traffic Grapher. This is an open source NMS developed by Tobias Oetiker. You can set it up on Windows or Linux from the command line. It is completely free. You can download a copy here.
    2. PRTG: Paessler’s adaptation of the MRTG with GUI and support. You can download a free trial version here.
    3. Solarwinds Network Monitoring Suite: Solarwinds is more expensive because it provides an extended suite of features. You can explore some of the features (they come with a 30-day trial version) here.
    4. HP Openview: HP Open View, which is now included as part of HP’s Business Technology Optimization tools, is a large suite of tools used for Network Management.Note: Although you do not need to know different examples of NMS for the CCNA exam, it is quite relevant in the real world.
  2. The SNMP Agent: The SNMP Agent resides within the devices that are being controlled or managed. Cisco devices support SNMP and, as such, can be monitored by SNMP managers. On most devices, you need to enable SNMP and configure some parameters before you can have appropriate communication.
  3. The Management information Base (MIB): This is the database of objects being managed using SNMP. For every network event, there is an SNMP object that has been assigned to the event by the number. The object has a unique identifier called the Object Identifier (OID). The collection of several OIDs is what makes up the Management Information Base. An example of a network event on a router is the Status of the Line protocol on FastEthernet0/0. This event is assigned a unique OID and an SNMP manager can poll a client to check the status of the OID.

Now that we have examined the components of SNMP, let us examine the three kinds of SNMP operations:

  1. GET: In a GET operation, an SNMP manager polls a device to check the value of an OID (or a group of OIDs) and the device responds with the value of that OID. The SNMP manager must have a read access in order to perform a GET operation.
  2. SET: In a SET Operation. An SNMP manager changes the value of an object variable. For instance, you can change the SNMP value of the enable secret of a router (that way, you have changed the router’s enable secret). The SNMP manager must have a write access in order to perform a SET operation.
  3. Notifications: In the case of notifications. The SNMP agent sends unsolicited messages to the manager. When these notifications are sent without a request for confirmation, they are called traps. If an agent sends a notification with a request for confirmation of receipt, the notification is called an inform.

SNMP has evolved over the years. There are three versions of SNMP supported by the Cisco IOS:

  1. Version 1: Oldest version of SNMP. It uses community strings as a form of security.
  2. Version 2c: Enhanced framework to include more protocols and larger MIB. Security is still based on community strings.
  3. Version 3: In versions 1 and 2c, security of the SNMP can easily be compromised using a sniffer. This is because SNMP versions 1 and 2c use a clear text community string. In SNMP version 3, security has been enhanced by providing 3 key features:
    1. Message Integrity
    2. Authentication: This is implemented using Message-Digest 5 (MD5) and Secure Hash Algorithms (SHA).
    3. Encryption: This is implemented using a 56-bit encryption algorithm called Data Encryption Standard (DES).

Now that we have learnt the basic theory behind SNMP, let us look at a quick example. The network Diagram is simple. R1 is connected to a Network Management System (NMS), as shown below:

First, we will configure SNMP on R1 so that the NMS can poll R1 for information.

All SNMP configurations in the IOS start with the snmp-server keyword. You should explore the features using the context sensitive help in the IOS. When a community string is defined on a router, any SNMP manager with the right community string can perform GET and SET operations on the device.

I have set up PRTG on the NMS for test purposes and configured monitoring parameters on PRTG. Remember that the NMS uses OIDs to poll for information from the device. In this case, PRTG is polling for different parameters that give an indication of the health of the device. The results after a few minutes of polling are shown below:

We can see that the NMS has automatically polled for key information about the device and created a monitoring dashboard for the router. The information can be further analyzed and you can set up alerts and logs based on device performance. For instance, you can configure the NMS to send you an email when the CPU process is too high.

Now, we will also configure the router to send some traps (unsolicited messages) to the server. Let us configure the router to send messages to the server if a link goes up or down.

There is a whole lot of stuff that you can accomplish with SNMP. I encourage you to download trial versions of some network monitoring software and see for yourself. For the sake of this article, we will stop here and move on to another important network management protocol – Syslog.


Syslog is a protocol used for logging messages on a network device. It is defined in RFC 5524. If you have ever configured a Cisco device, chances are high that you have encountered a Syslog message.

All these messages that appear on the console when you are configuring a device, that lets you know the state of the device, are Syslog messages.

For the CCNA exam, you should understand three major concepts in Syslog messages:

    1. How the protocol works: Messages are generated from internal programs on a device called facilities. These messages can be sent to different destinations based on the configuration specified on the device. When Syslog happens over a network, it uses UDP port 514 for communication between source and destination.
    2. Messages can be of various levels: There are 8 severity levels in Syslog. You can specify at which severity level you want to send your message to a Syslog destination. When you specify a severity level, messages in that severity level and all the levels below are sent to the destination. For example if you specify severity level 4, messages in levels 4, 3, 2, 1 and 0 would be sent to the destination. The severity levels are shown in the table below:





      System unusable messages


      Immediate action required messages


      Critical condition messages


      Error condition messages


      Warning condition messages


      Normal but significant messages


      Informational messages


      Debugging messages
    3. Destination: The destination of the messages can be set using the CLI. Syslog destinations in the IOS include:
      1. Console: Logging messages of a particular level are sent to the console. This is turned on by default to level 7. Messages that are logged onto the console can only be viewed if you are directly connected to the console. To view the messages via a VTY (telnet) session, you need to issue the “terminal monitor” command.
      2. Logging buffer: A buffer is a memory location that can be used to store log messages. Sometimes you might need to turn off console logging and store them temporarily in a buffer. You can do that by issuing the following commands:

The command tells the router to stop console logging but to send all logs to the buffer. All Syslog messages with severity levels 7 and below would be sent to the buffer memory. We can test this by shutting down an interface (this should generate a log) and checking the logging buffer.


Notice that there is no error message sent to the console. However, when we view the logging buffer, we find that the Syslog messages have been sent to the buffer.

3. An external Syslog server: You can configure logging to an external Syslog server. You do this with 2 commands: logging host command specifies the IP address of the Syslog server while logging trap command specifies the level of messages that would be sent to the Syslog server. To configure the router to send Syslog messages with levels 6 and below to a server located on, we can issue the commands as shown below:

Now let us test by bringing back interface f0/1 up.

I have installed aS server on and we can see the logs from the Syslog server below;

Note: The Syslog server used above (3cDaemon) also has TFTP and FTP features and it is free. Highly recommended!

Wow, we have come to the end of this 4-part series on IP Services. I hope this series has brought you closer to your goal of passing the new CCNA exam. And even if you do not plan to take the exam, I hope you have learned something that you can apply in the real world. Thank you for reading and feel free to drop your thoughts and questions in the comments section.