If you have a need to have MRTG properly grab input and output usage information from network switches or routers, you need to be aware that SNMP counters for the original 32-bit counters representing this data can roll-over (circle back to zero) during the time interval between polling by MRTG. This is not a limitation of MRTG per se, but illustrates that port speeds have increased from less than 1 Mb/sec to 10 Gb/sec (or more) since SNMP was first standardized by the IETF in 1988 (RFC 1067). OIDs had to be added that use 64-bit counters to handle this. This posting describes how to do this in MRTG 2.16.
cfgmaker has logic in it that will access these larger counters, but only if you use SNMP version 2c or 3 when querying for them. To use SNMP version 2c, you add the option --snmp-options=:::::2 to the command line before the target (e.g. community@router-name) when you use cfgmaker. Please note that there are devices (like the Apple Time Capsule) which do not support the 64-bit counters, so using SNMP version 2c for them will produce a configuration that generates no results when MRTG is run. To determine how best to proceed, I run cfgmaker twice (one with the option and one without) and compare the two configuration files. I use the SNMP version 2c file when it will generate results and the SNMP version 1 file otherwise.
If you have a requirement to use SNMP version 3, the options on the command line are --enablesnmpv3 --snmp-options:::::3. You also need to specify the username of the SNMP version 3 user that is authorized to use SNMP version 3 to query the device.
Here is an example using SNMP version 3 and a Cisco Catalyst 2960 Switch running IOS 12.2(53)SE2.
The configuration file generated when used by MRTG will query the switch using SNMP version 3 retrieving data from the 64-bit counters.
I want to thank Jeff Chandler for commenting about MRTG and SNMP version 3 on another post. It made me curious enough to figure it out and write it up for this posting.
Backups of desktop systems should be a standard feature for all IT environments. For users of OS X on Apple Systems, this requirement is addressed through Time Machine, a built-in backup system that runs transparently in the background. For home users and small businesses (or even larger businesses with few Apple Desktops), Apple offers an archiving system (which also doubles as a wireless access point when needed) called Time Capsule
. This posting shows how to monitor the availability of Time Capsule using Nagios, a popular open-source network monitoring and alerting system. To learn more about Nagios, I recommend the book Nagios: System and Network Monitoring.
Be sure to get the latest edition.
Nagios organizes monitoring in to two categories: host and services. Host availability is monitored by configuring a host object. For the services to the monitored on the host, a service object is created for those services of interest. Generally, the host object once installed and activated will using ping to determine the availability of the host. Service objects will generally use a plug-in, sometimes a custom plug-in, to determine the availability of services on that host. For the purposes of this posting, I am using a widely available plug-in called check_ifstatus which can be installed a part of the FreeBSD ports nagios-plugins package. If installed from the FreeBSD ports collection, the plug-in will automatically be configured for use by Nagios and can be used in a service object or template directly.
When adding a new device type to Nagios, it’s important to consider how that device will be represented on Nagios’ web pages. This means selecting an appropriate icon, vrml image and statusmap image to represent the device. The FreeBSD ports collection comes with a set of logos that cover most common devices called nagios-base-logos. For the Time Capsule, I want to use an icon that looked like the device. I found a satisfactory one at deviantArt by ElevatorHappyFun. Nagios uses logos that are 40×40 pixels, so I use Photoshop to resize the icon of the Time Capsule to that size (this is in the Image menu in Photoshop) and then (based on guidance from the Nagios Wiki ) I change the image mode to Indexed from RGB format (also in the Image menu). Because the Time Capsule is a long short box, there is a lot of blank space above the box. That’s ok. The image needs to be square to work properly with Nagios. This work is now saved as a PNG file (I call it time-capsule40.png), transferred to the Nagios server and installed in the Nagios image file location (which on FreeBSD is /usr/local/www/nagios/images/logos by default). The final step is to create another version of the icon in GD2 format. When the gd FreeBSD port is installed (as part of installing Nagios), pngtogd2 is also installed. I do the conversion by entering the command line pngtogd2 time-capsule40.png time-capsule.gd2 0 1 to create an uncompressed GD2 formatted icon file (The Nagios FAQ suggests it be uncompressed).
To add the host to Nagios, I create a template for Time Capsule devices (I have three in my network) and then create a host object for each Time Capsule referencing that template. Here is the template entry:
define host{
name apple-time-capsule
icon_image time-capsule40.png
statusmap_image time-capsule.gd2
vrml_image time-capsule40.png
use generic-switch
register 0
}
Because I am using Nagios 3.2.1, I can take advantage of a new feature in Nagios 3 by putting the information on the images directly in the host template. The old approach of using a hostextinfo object still works as well, but is deprecated in Nagios 3 and will likely no longer work when Nagios 4 comes out.
With the host template in place, I now add the three Time Capsules in my network using these objects:
define host{
use apple-time-capsule
host_name red-tc
alias Red Time Campsule
address 192.0.2.2
hostgroups wireless-ap
parents blue-tc
}
define host{
use apple-time-capsule
host_name blue-tc
alias Blue Time Campsule
address 192.0.2.3
hostgroups wireless-ap
parents switch
}
define host{
use apple-time-capsule
host_name green-tc
alias Green Time Campsule
address 192.0.2.4
hostgroups wireless-ap
parents blue-tc
}
Besides host availability, I want to know that all the interfaces in the Time Capsule are operational. To do that, I am using the check_ifstatus plug-in. Here is the service object to activate this checking:
define service {
service_description Network Interface Status
check_command check_ifstatus!public
use network-service
host_name red-tc,green-tc,blue-tc
}
Now, with a restart of Nagios, these three Time Capsules will be checked for availability with ping and have the status of the interfaces checked using check_ifstatus using SNMP version 1 and a community of public.
Logging data for service testing results (when everything is working properly) should look like this:
[05-11-2010 00:00:00] CURRENT SERVICE STATE: red-tc;Network Interface Status;OK;HARD;1;OK: host '192.0.2.2', interfaces up: 6, down: 0, dormant: 0, excluded: 0, unused: 0
[05-11-2010 00:00:00] CURRENT SERVICE STATE: green-tc;Network Interface Status;OK;HARD;1;OK: host '192.0.2.4', interfaces up: 6, down: 0, dormant: 0, excluded: 0, unused: 0
[05-11-2010 00:00:00] CURRENT SERVICE STATE: blue-tc;Network Interface Status;OK;HARD;1;OK: host '192.0.2.3', interfaces up: 7, down: 0, dormant: 0, excluded: 0, unused: 0
blue-tc shows 7 interfaces because its wan interface is in use. This port is not used on the other two since they are being used to extend an existing wireless network. Two other configuration notes:
- The Time Capsules are configured with static IP addresses. While not strictly required, I don’t want to have to depend on DNS resolution in order to monitor devices on my network, so I choose to statically configure devices that are not portable.
- The Time Capsules are configured to respond to SNMP queries (version 1 or 2c only) using the community public.
Now, I am able to see the Time Capsules in my status map as well as get notices from Nagios should any interface go down any of the Time Capsules become unavailable.
I have been using the MRTG package for many years and it remains a quick and easy way to collect longitudinal data from network devices that support SNMP (and it can be extended to do more, but that’s a topic for a future posting). In this post, I am writing about some of the experimental features of MRTG in the current release 2.16. Keep in mind that these features are still under development and so information in this posting may be out of date at some future time. I will endeavor to update this posting as things change to keep it current.
At its heart, MRTG is a polling engine and is usually used to grab two scaler data items (usually via SNMP) which by default are added to PNG-based graphs which are made available though a web page. There have been several tutorials on how to setup MRTG. A good one is available in a book called Open Source Network Administration (Prentice Hall Series in Computer Networking and Distributed Systems)
and is available on the web as of this posting at http://www.informit.com/articles/article.aspx?p=102611&seqNum=4. On FreeBSD, MRTG is available via The FreeBSD Ports collection in /usr/ports/net-mgmt/mrtg directory and can be installed from there very easily.
In this posting, I am using cfgmaker and indexmaker. Both come with the MRTG package and are useful ways to quicky generate the configuration files used by MRTG and then build a web page that can display the PNG-graphs generated when MRTG does its polling.
Recently, I was updating the pages I maintain for the Southeast Texas GigaPOP (SETG), a consortium of higher-education institutions that make use of a Houston-area MAN to facilitate high-speed network connections among themselves and to the Lonestar Research and Education Network (LEARN). I had been using MRTG for years to plot the usage on the links that make up the MAN and wanted to update that installation to the latest software. Because the MAN make use of Cisco Catalyst 6500 switches and a Juniper MX-Series switch, I thought it would be great to make use of the new experimental features to make the usage information easier to navigate and eliminate information that would not be interesting to the consortium members.
The new experimental features in cfgmaker seem to be optimized for Cisco Systems gear and that made it very easy to customize the configuration file for the Cisco Catalyst 6500s in the SETG MAN. For these devices, I was primarily interested in reporting on the input and output usage on the physical interfaces. To create a configuration file just for those interfaces, I invoked cfgmaker using this command line:
cfgmaker --ifdesc=alias --global 'options[_]:bits' --global 'WriteExpires:Yes' --global 'IconDir:/icons/' --global 'WorkDir:/local/mrtg/data/devicename' --output='/local/mrtg/cfg/devicename.cfg' --if-filter='((!$if_is_ciscovlan && !$if_is_loopback && $if_type!=53 && $if_type!=1) && $if_admin && $if_oper)' --snmp-options=:::::2 community@device.gigapop.gen.tx.us
The experimental feature exploited here is the if-filter directive. In this particular case, I didn’t want anything related to Cisco VLANs, Loopbacks or devices of type 1 (a catch-all for types not specified in the SNMP standards) or 53 (a virtual interface). I wanted the interfaces reported on to be both administratively and operationally up. This generated a configuration file that contained only physical interfaces and that satisfied my requirements for these devices.
For the Juniper MX, it was harder because the SNMP device type reported for the management port and some other ports that were not of interest would not be covered by the same filter. So, I modified the filter for the Juniper to explicitly exclude the devices with descriptions that matched the names of the devices that were not of interest. The command line I used for it was this:
cfgmaker --ifdesc=alias --global 'options[_]:bits' --global 'WriteExpires:Yes' --global 'IconDir:/icons/' --global 'WorkDir:/local/mrtg/data/devicename' --output='/local/mrtg/cfg/devicename.cfg' --if-filter='((!$if_is_loopback && $if_type!=53 && $if_type!=1 && $if_type!=135 && ($if_description !~ /em|fxp|pd|pe|gr|ip|vt|mt|pd/)) && $if_admin && $if_oper)' --snmp-options=:::::2 community@devicename.gigapop.gen.tx.us
Here I added device type 135 (Layer 2 VLAN using 802.1Q) and used the $if_description along with a Perl pattern binding operator to eliminiate those devices with descriptions that were not of interest.
After I updated mrtg to use the new configuration files in its polling, I was ready to use indexmaker to build the index pages. The only thing I was doing different from the default here is setting the title of the page. The command line looks like this:
indexmaker --title="Devicename Node" /local/mrtg/cfg/devicename.cfg
The results of all this work is available at http://www.gigapop.gen.tx.us/mrtg/. [Due to some idiosyncrasies with how IPv6 is currently configured for SETG, you may want to try the IPv4 URL which is http://www.ipv4.gigapop.gen.tx.us/mrtg/.]
Of course, there are more experimental features available in MRTG than if-filter, but it was the one I thought most interesting and about which I could not find much information in other blogs. I do hope that the MRTG team will keep it in the software as they continue to develop the next release of MRTG.
