Managing a complex network can be difficult because of a lot of different devices, protocols, and users, but we want the system to work smoothly and efficiently. Fortunately there are some good solutions for this problem. In these articles, I’ll show two very useful protocols and the related tools for network management: SNMP and NetFlow. Each topic is important part of the new CCNA R&S course as well.

Before exploring the details, let’s outline the purposes of the two protocols. SNMP (simple network management protocol) is the de facto standard for network management. We can discuss it with the help of the next figure:

In the network we have managed devices: servers, routers, switches, and PCs. There’s a special workstation from which we want to remotely manage them; it is called the network management station (NMS) and it runs a special program for this purpose, called NMA (network management application). Some well known NMAs are: CiscoWorks, IBM Tivoli, and HP OpenView. A software component called agent runs on the managed nodes. The agent is responsible for communicating with the NMA by using some network management protocol, such as SNMP. SNMP is an application-layer protocol that uses UDP for transporting data. On every node there exists a special, tree-structured database called the MIB (management information base), which holds the settings and values for that particular device. Every object in the MIB can be referenced by a numerical value called the OID (object identifier), which we can find from the root of the tree. For example, if we want to find the hostname of a Cisco router, its OID is 1.3.6.1.4.1.9.2.1.3 (it has a textual value also).

The NMS may want to know some information about the node (for example, the status of its network interfaces or what amount of traffic was produced by that node). In order to do this, the NMS sends a request message and will get a response (this is labeled with a green “1” on the figure). Sometimes the NMS wants to change some settings on the managed device, therefore it sends a “set request” and will get a response about it also. This communication is labeled with a blue “2.” And, finally, sometimes an unwanted event (most likely an error) can occur; than the node itself sends a message about it. That’s called a trap and is labeled with a red “3.” The communication takes place with SNMP messages such as GetRequest/GetResponse, SetRequest, or Trap.

The first two major releases (SNMPv1 and SNMPv2c) are not so secure, because they only use a so-called community string to authenticate the peers. This is a value that must be the same on all of the managed nodes and on the NMS, and it has two types: a read-only and a read-write community string. We can just query something with the former, but can also set up values remotely with the latter. SNMPv3 introduced stronger authentication and encryption methods, so this version is recommended when security is important.

NetFlow is another important tool for a network administrator. Its purposes are to analyze the network traffic, to collect data for make some statistics, to help in troubleshooting, and such. NetFlow is a Cisco standard, but we can use it on devices from other vendors also. It has various versions: v5 is the most common, but it is limited to analyze only IPv4 traffic. On modern devices the v9 is more useable, as it is capable of analyzing modern protocols, such as MPLS or IPv6. A device running NetFlow usually sends the data to a special node called the Netflow collector, where dedicated software processes and displays it in various forms. There are similar protocols on the market, for example Jflow, sFlow, and NetStream.

After this really terse summary of the protocols, let’s see some simple lab work to demonstrate their usage. We’ll use GNS3 because SNMP support in Packet Tracer is very limited, and NetFlow support will only be available in the upcoming PT 6.1 version. The SNMP lab topology is as follows:

The NMS can be any Windows PC. I used an XP machine; the other PC is running Windows 7 and both of them are VirtualBox clients. The SW1 is a built-in switch from GNS3. Finally, the R1 is running an IOS for 2600 series routers in my topology, but any other version will be perfect. Before the lab, the NMS machine needs some software to be installed:

On the Windows 7 node, we may need the installation media, so keep it at hand.

Now start the devices, and set up the IP addressing according to the above picture (the router uses the first useable address on both segments). Test if NMS can ping Win7 and vice versa. We can disable the Windows firewall now, as this is a fairly secure network J

Let’s start the configuration on R1. The first thing is to set up the community strings for read-only and read-write access:

Now, if someone knows the community string “testing,” he or she can query information from this device but cannot modify anything—this operation requires knowledge of the “testing123” value.

Next, we can optionally set up some information about the managed node, namely its location on the network (logical or geographical), and some information about the person who is responsible for the device:

At this point we can check the functionality of SNMP from the NMS. Start the MIB browser, and fill in the Host, Community, and Write Community fields accordingly (note that SNMP uses UDP port 161):

Now look at the left panel, where we can find the loaded MIB modules. Locate the SNMPv2-MIB tree, and open its “leaves” until we find the sysDescr object. This is the system description of the router. Let’s query its value: right click on it and choose GET, or choose it from the Operations menu. The result is:

As we can see, the program displays the object ID (OID) of this MIB object. This is a dotted string starting from the root of the MIB (indicated by a dot). The actual value can be seen on the right. If we want some more information about this object, right click on it again and choose View MIB Description. Here we can find the numerical OID (.1.3.6.1.2.1.1.1 in this case), the data type under the Syntax field (it’s a DisplayString), the method of access (this is a read-only value) and a longer textual description. This information can be valuable later.

Now let’s query another interesting value, the sysUpTime, which will give us information about the time the router is up and working. Click on it in the tree and start a GET operation again. The router responds with the time in hours, minutes, and seconds. Under the MIB description we can see that it’s a TimeTicks type data, and its original data is a number: The software just converts it into human-readable format.

At this point, one can be curious the background communication of the NMS and the node. Fortunately we can easily observe this by using Wireshark, which is a packet capture program that can be easily used from GNS3. Locate the link in the topology that connects the router Fa0/0 interface to the switch, right click on it, and choose Start capturing, then select the router interface from the drop-down list. Wireshark will launch automatically and it starts to capture every frame traversing through this link. Now query the uptime again, and let’s check the communication:

First the NMS has been sent a GetRequest message, asking for the information about the object specified by the OID. The router responded with a GetResponse message that contains the value in the variable-bindings field of the SNMP message. Now we can see the raw data also: The TimeTicks value of 437151 is equal to 1 hour, 12 minutes and 51 seconds.

Next select a value from the MIB that is writeable. For example, let’s query the location, and then modify it. The GET operation is the same, and we get back the preconfigured value in sysLocation: “GNS3lab, Intense School.” Suppose that, for some reason, we have to modify this into “Intense School’s GNS3 lab”. What we need to do is to fill in the Set Value field, then choose the SET operation (for those who like keyboard shortcuts: CTRL-S). The software immediately indicates the change, and if we look at the router CLI, we can see a message there also:

%SYS-5-CONFIG_I: Configured from 192.168.1.2 by snmp

In Wireshark we can see a SetRequest message followed by a GetResponse, each of them containing the string as OctetString type. These conversations are good examples of the nature of SNMP: a simple question-and-answer based protocol that uses UDP. This simplicity can be a disadvantage in some cases: For example, when we want to do some complex modification on our devices. And, because UDP doesn’t guarantee the delivery of the packages, some information can be lost. But that is why they call it SIMPLE network management protocol!

One important thing that can be observed with Wireshark is that the SNMP messages hold the community string, and in clear text. So if one can run Wireshark and can capture our management traffic, that person can also modify it. It’s not good … What can we do? First, we can control the access to our managed nodes by ACLs. It’s very easy to build an ACL that allows only the NMS machine to get or set information on the router. How can we do that?

First create an ACL that permits only the IP address of the NMS. Then apply this ACL to the community string setting:

Now try to query the sysDescr value of the router from the Windows 7 machine. Will it succeed? Yes, it will. If you wonder why, just look at the above command: We have just set the ACL for the read-write access, but the read-only access is still open for everyone. To prove that the ACL is working, let’s try to set some value, for example the sysName, which is the hostname of the router. The result is a message after a short time: Request failed with timeout. Next, apply the ACL to the read-only community string also:

R1(config)# snmp-server community testing ro 1

After that, every request from the Windows 7 machine will be refused and only the XP host will be allowed. As a last exercise, set the router’s hostname to Router1 and observe the SNMP messages with Wireshark!

Now go on with some other SNMP messages. If we want to traverse the MIB tree or subtree, we can use the GetNext command. It gives the value of the object that follows the specified one. For example, try this: locate the sysName object, and issue the GetNext operation. The result is the actual value of the sysLocation object, which is the next in the MIB tree. If we check the background conversation with Wireshark, we can see that in the request packet the OID is different than in the response, but that’s not a surprise in this case.

All of the previous SNMP commands are really simple, but this behavior sometimes makes our life difficult. For example: We want to query the whole routing table of our router. With these Get-commands, it’s not a simple task, but fortunately we have a command that makes it easier: GetBulkRequest. One important thing: This can be used only from SNMP version 2c, so we need to modify the MIB browser settings slightly. Go to Edit/Settings, and set the radio button near v2c. Now search for the following value in the MIB: ipRouteTable. In order to do this, go to Edit/Find node (or press CTRL-F) and write it into the Find What field. When we find it, use the GetBulkRequest from the Operations menu or press CTRL-B. The result is a bunch of data containing all the pieces of the routing table. Because our program is just a browser, it cannot display it in an easily readable format, but this also represents the nature of SNMP: It gives the requested data, but in a very raw format. In the output of Wireshark, we can see the GetBulkRequest message and in the response there are numerous values in the variable-bindings field (in this case 50 entries).

These tasks hopefully helped in understanding the basics of SNMP. In the next article, we’ll continue with some other issues and we will look into the basics of NetFlow also. As homework, let’s use another MIB browser from iReasoning and do the exercises with it also. It can be useful, because this application is more similar to that in Packet Tracer and it’s an advantage if we want to do basic SNMP labs in the simulator.