As said in my previous post about this topic, I’ve made a small Perl script to build Zabbix configuration for Cisco Class-Based QoS monitoring.
As first, I have to say I’m NOT a Perl programmer, so I think real Perl programmers will find my script a shocking jumble of code. I apoligize!
Any suggestion would be appreciate!
This is a beta version of the script: use it at your own risk!
You can find the script here. It requires Net::SNMP module (“apt-get install libnet-snmp-perl” on Debian to install it).
What it does
This script lets you to monitor Cisco QoS stats and counters in your Zabbix NMS using the builtin SNMP agent. You can store the same stats you can see with a “show policy-map interface …” command and have graphs built on them.
You can get values from class-maps, match statements, traffic policing and shaping.
How it works
When you run the script (with proper arguments!) it walks through the SNMP MIB of your device and discovers QoS policies layout; then, it builds Zabbix items and graphs about objects it finds.
How to use it
Unfortunately Zabbix has a quite complex database structure, so I preferred to use the builtin import/export feature instead of manipulating tables directly in my script to add items and graphs.
The output is formatted on the basis of the Zabbix XML configuration file.
To use the script you have to export your Cisco device configuration from the Zabbix Configuration / Export/Import menu, then merge the script’s output within the <host> XML element and, finally, import the new XML file into Zabbix.
Usage is pretty simple:
./ciscocbqos HOST [-c SNMP_COMMUNITY] -o OUTPUT_PATH OBJECTS_TO_MONITOR
Here, HOST is the Cisco device IP address, SNMP_COMMUNITY is the SNMP read community (default to public), and OBJECTS_TO_MONITOR is a list of one or more objects you want to add to Zabbix (objects are class-maps, match statements, traffic policing and traffic shaping). More options are available: you can see the full help just running ./ciscocbqos without any argument.
For example, if you want to monitor traffic-shaping on router at 192.168.0.1 you can run
./ciscocbqos 192.168.0.1 -c myreadcommunity -o /root/qos +trafficshaping
Once done, you will find /root/qos.items and /root/qos.graphs files containing a scrap of Zabbix XML file to merge with your existing configuration. At this point all you have to do is to put qos.items and qos.graphs content inside the <host> XML element of the exported Zabbix file (line 17 and 18 of the following example).
<?xml version="1.0"?> <zabbix_export version="1.0" date="21.04.09" time="17.59"> <hosts> <host name="MYCISCODEVICE"> <useip>1</useip> <dns></dns> <ip>192.168.0.1</ip> <port>10050</port> <status>0</status> <groups> <group>Router</group> </groups> <templates> <template>Template_Cisco_Device</template> <template>Template_MyOwnTemplate</template> </templates> qos.items content goes here qos.graphs content goes here </host> </hosts> <dependencies> </dependencies> </zabbix_export>
Zabbix keys and SNMP indexes
As you know Zabbix uses keys to uniquely identify items within a host; SNMP agent gets those values from devices and stores them using their keys. This script can be ran in two ways to build Zabbix keys: with or without the +p option.
You should use the +p option only if your device has the “snmp mib persist cbqos” command in the configuration. This option lets the script to build keys based on the SNMP indexes: if you use the “snmp mib persist cbqos” command indexes are maintained after device restart.
With no “snmp mib persist cbqos” command in the config, you should run the script without the +p option, in order to build Zabbix keys on the basis of a hash of items descriptions. In this scenario you have to run the script every time you restart your device, cause SNMP indexes will change and Zabbix items will be outdated.
The cbqos keyword was added starting from IOS 12.4(4)T.
Here are some Zabbix graphs generated using the script:
Latest posts by Pier Carlo Chiodi (see all)
- Route server feature-rich and automatic configuration - 13 February 2017
- Large BGP Communities playground - 15 September 2016
- RFC7050 (DNS64 prefix via ipv4only.arpa) on RIPE Atlas probes - 9 March 2016