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.
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.
