In the previous article, we configured the basic settings on a router to use SNMP, observed the traffic between the management station (NMS) and the managed node, and made an ACL to make the system more secure. Now we’ll go further, and in the second part of this article we’ll see another useful protocol called NetFlow.
When using SNMP, an important thing is to get to know each and every important event that occurs on our managed nodes. It’s not a best practice to continuously query the devices if they are functioning or not: It causes a lot of traffic, much of it useless. It’s much better to let the devices send messages about unusual events or errors they discover. These messages are called traps in SNMP. Let’s configure our router to send traps to the NMS, and see how to collect them.
On the router, we need to enable the sending of traps, as it is disabled by default. Then we need to tell which host will receive the traps, what version we will use, and how we can authenticate ourselves to that host (now we use the community string for this purpose). Moreover, we can use the debug service to check if the router really sends those messages. Enter the following commands:
Now on the NMS (the XP machine in the lab), launch the ManageEngine MIB Browser. In the Edit/Settings menu, choose v2c version, then go to the View menu and start Trap Viewer (or press ALT-P). Enter the community string “testing” into the Community field, then click on the Start button (notice the port number also: SNMP trap service uses UDP port 162. This can be important if we use a firewall and don’t want to block the trap messages):
It’s time to generate some events that trigger trap messages. One of the simplest ways to achieve this to enable an interface, so let’s create a loopback interface (for example Loopback1) and, after it comes up, shut it down. We can see the usual syslog messages on the console, and the debug messages also state that the SNMP messages are queued to send:
After some time, we can see the trap messages appearing in the TrapViewer window:
This output is not very useful, though, so select, for example, the last row and then click on the Show Details button. The window that appears gives us more information, the most important one in the Message field: We can read that Loopback1 went down administratively.
Let’s use another program that can be useful to experiment with. Stop the TrapViewer, close the MIB browser, and start PowerSNMP Free Manager. The first time it runs, the software asks if we want to discover available agents. Say “yes,” and the Discover SNMP Agents window appears. Click on Properties, fill in the Community, and choose version 2. Now enter the address of the R1 router into the Address field and click on Find. After the software finds our router, select and add it to the list of the SNMP agents:
The program automatically watches for traps, so if we generate some events again (turn Loopback1 up, for example), this immediately appears in the bottom, under the Traps tab. By right-clicking on a message and choosing Info, we can read the details of the message.
We can query values nearly the same way as we did with the MIB Browser. Find the desired value in the MIB tree on the right (for example, the sysName), right-click, on it and select Query. The program displays the OID; select it and click the Query button. Another method: If we already know the OID, we can click on Add, enter the OID value, and then query it. But where do we know the OID from? Cisco has a useful webpage called SNMP Object Navigator, which can be found here:
Let’s try it: Locate the “Enter OID or object name field,” enter sysContact, and then click on Translate. Soon we get the answer: The OID is 188.8.131.52.184.108.40.206, and we can read other information also. Moreover, the webpage displays the location of this object under the MIB tree. Unfortunately, if we don’t know the exact name (e.g., if we enter “contact” only), it doesn’t work.
The PowerSNMP software has a very useful function called “watch.” The first example can be monitoring the change of some value, for example the hostname (not a useful example, but simple to try J). First we need the OID of the sysName value; this can be found with the help of SNMP Object Navigator, but it is simpler to select it from the right or, even more simply, I tell you: 220.127.116.11.18.104.22.168. Now select Watch/Add Variable Watch menu entry, set the desired update interval to 5 sec (in order to see the change almost immediately), and click on Add. An entry appears under the Variable Watches in the middle of the window. Now change the hostname of the router to Router1. Soon the value will change in the manager software also.
In a real network, we can even send an email if some value exceeds a threshold. The email configuration is under the Tools/Configuration menu: enter the SMTP server and the sender/recipient information. For example, if we query the number of interfaces on the router (the ifNumber value), the result will be four: the two FastEthernet interfaces, the Loopback1 interface, and the Null0 interface. If you want to know if someone has created another interface, then place a watch for this: locate the ifNumber entry in the MIB, right click on it, choose Add watch, and set up as in the next figure:
We can use SNMP to manage workstations also. Let’s try to set up the Windows 7 machine to support SNMP! In order to this, we need to enable the SNMP protocol on Windows, as it is disabled by default. Here you can find step-by-step documentation about enabling and setting up SNMP:
Of course, use our community string settings instead of “public,” and add the NMS machine’s IP address under the “Accept SNMP packets from these hosts” section.
Now try to add this PC to the PowerSNMP manager using the Discover/SNMP agents menu, and try to query some values. For example, if I run a query against sysName, my Windows 7 PC answers like this:
Although SNMP is a useful protocol, it’s not very secure, at least in the v1 and v2 versions, because the community string can easily be discovered by a packet sniffer. So, if you want more security, use SNMv3 instead. This version gives authentication and/or privacy to our SNMP traffic. Security level authNopriv gives only authentication; on the other hand, authPriv gives privacy also. In the final SNMP exercise, we’ll set up a user on the router who can access SNMP data, instead of the community string. First, delete the previous configuration (use the no snmp-server command). We create a group, and then a user belongs to this group, with the following commands:
So, the created group name is ADMINS and it uses the authPriv security level. Our user’s name is “admin,” a member of the ADMINS group, who uses SHA for authentication and DES for privacy. Both passwords are “xy” (it’s good for lab purposes, but don’t use in live environment! One more note: if you use another version of IOS, you may find more secure protocols than DES, such as AES.) Finally, we use this username instead of the community string in the communication with the NMS. Now we need to configure the ManageEngine MIB Browser in order to try the settings. Go to Edit/Settings, select v3 version, click on Add button in the bottom and set up the parameters, as shown in the next figure:
Now try to query some values from the MIB; it should work. To check if our communication is safe, start a packet capture on the router interface, and do another query. We should see that the message is encrypted (Wireshark says “encryptedPDU: privkey Unknown“).
As we can see, SNMP can be a very useful protocol, but it can be difficult to gather data about some attributes of the network traffic with it. Cisco developed a protocol called NetFlow for that purpose. If we use NetFlow, we can answer many questions about the traffic: which protocols are in use, what nodes generates traffic and how many bytes they send or receive, who are the so called top-talkers, and so on. The router or switch can gather data on its NetFlow-enabled interfaces, and usually sends it to a device called “collector,” which processes and visualizes the data in various ways. Keep in mind that a flow, by definition, is a unidirectional sequence of bytes with common attributes, such as source and destination IP address and port, protocol, and some other values. For example, if we’re pinging a host, the sequence of the ICMP echo-request messages makes one flow, and the echo-reply packets are another flow.
Configuring NetFlow is not a difficult task. Set up another simple lab for practice, as shown in the next figure:
I use a router for Telnet, SSH, and an HTTP server. It’s a trick if you haven’t got enough memory and don’t want to run a full-featured server OS. The collector will be a Windows 7 machine, and there’s a client also. I use MicroCore Linux, version 4.7.7, which is downloadable from the GNS3 website from the Appliances section. This version of Linux needs very few resources; it’ll run with just 32 MB of RAM! The default username on it is “tc” with no password.
Start the devices and set up IP addresses. For those who are not familiar with Linux, here are the necessary commands to set up an IP address on CoreLinux (with the ip command, which is a Swiss Army knife for network setup, just like netsh in Windows):
tc@box~$ sudo su tc@box~$ ip address add 192.168.1.2/24 dev eth0 tc@box~$ ip route add default via 192.168.1.1
On the server router, we need to set up the mentioned services and a static route towards the client network. Set up a user account named admin with the password cisco to use Telnet and SSH service. Check the settings by ping and remote login to the server from the client.
Now set up NetFlow on R1. First we need to make sure that IP CEF (Cisco express forwarding) is on, but on modern devices it’s the default setting. Next we need to set up some global settings: the source of the data, the address of the collector device, the UDP port on it, and the NetFlow version (usually this is 5 or more preferably 9):
Finally, enable the collecting of data on the proper interface(s). This can be achieved in two ways: by the ip route-cache flow command, or by the ip flow egress/ingress commands. As a rule of thumb, if you want to collect data from the physical interface and its subinterfaces (if any), then use the first command, but if you want to collect data from a particular subinterface, then use the second. We’ll use the former:
Now generate some traffic from the client: Ping the server, login with Telnet and SSH, and get the homepage by telnetting to port 80 and issuing the “GET /” command. After that, go to the console of R1 and issue the show ip cache flow command. We can see a lot of information about the traffic, for example, the distribution of packet sizes, the used protocols, and how many packets they forwarded. But this is just a quick check to see if NetFlow works. We can use much specialized software on the collector PC to display data in a friendlier format. Cisco has a list of freeware applications on this webpage:
In this lab, we’ll use a freeware tool from Solarwinds called Real-time NetFlow Analyzer. Before using this, we have to set up a community string on the NetFlow router. The software can be downloaded after a short registration from the downloads page, where you can find some other useful utilities for free:
Install the analyzer program (we get another utility called NetFlow Configurator), and launch it (at first run we get a “getting started” window). Add the router device under Tools/Add Netflow device menu by its IP address and the community string. Soon after, the device appears in the main window; select its Fa0/0 interface and click on Start Flow Capture button. Generate traffic again from the client, and watch the analyzer window. You should see something like this:
As you can see, there’s no data in the Outbound traffic window. To change this, we need to issue one more command on R1’s Fa0/0 interface: ip flow egress. From now on, the router sends information about outbound traffic also, but you may need to wait for some time before the data appears. I recommend experimenting with the software; try the various settings and try some other software too.
I hope that, if you have reached this point, you have some more information about network management tools and protocols: these can be our good friends while managing our networks. They can help to quickly notice errors or unusual events, and it does matter how much time is needed to resolve them.
Configuring SNMPv3 on Cisco devices:
Some tips on configuring network settings in Linux: