Category Archives: Systems Administration

Zabbix: how to monitor Radius (and other services) with external check items and netcat (nc)

You can monitor Radius (and other services too, such as DNS and other) with Zabbix external check feature and netcat (nc).

How do external check items work?

“External check” items are monitored by Zabbix using external scripts, running on the server; you can create your own scripts and put them in the ExternalScripts directory, as defined by the zabbix_server.conf file:

# Location of external scripts
ExternalScripts=/etc/zabbix/externalscripts

You can setup an external check item using the following syntax for the key parameter:

Type: External check
Key: script[parameters]

For example, you can configure Zabbix to run the script checkradius.sh and to pass it the host IP address:

Description: Radius – Authentication
Type: External check
Key: checkradius.sh[{IPADDRESS}]
Type of information: Numeric (unsigned)

Zabbix will execute checkradius.sh HOSTNAME|HOSTIPADDRESS IPADDRESS, where HOSTNAME|HOSTIPADDRESS is the host name or IP address (it depends on the “Connect to” host parameter), and IPADDRESS is the value of the macro {IPADDRESS} used as parameter.

How to use netcat with external check items

With netcat (nc) you can send a host UDP or TCP data and get a response from it. For example, you can send a Radius authentication packet and wait for a response from the server.

Of course Netcat knows nothing about Radius or other protocols, it simply sends and receives data, so you have to forge an Access-Request packet and to parse an Access-Accept response.

Radius - Access-Request packetTo build the Radius Access-Request packet I simply sniffed a real packet using Wireshark and then I exported it to my Zabbix server (you can see it in the picture).

Once you have sent the Access-Request packet, you should receive an Access-Accept response from your server, so you can parse the response to see if it is the one you expected. You can do this using od to convert netcat output in hex and then grep the Radius Access-Accept code (0x02).

External check item and script configuration

My script uses only one argument, the one Zabbix always passes to external scripts, so I did’nt configure it to pass other parameters:

Description: Radius – Authentication
Type: External check
Key: checkradius.sh[]
Type of information: Numeric (unsigned)

The script gets the Radius packet to send to the server from the $1.rad file, where $1 is the host name or IP address; for example, for the Radius server at 10.0.0.1 I will put the Access-Request packet in the 10.0.0.1.rad file.

EDIT 2011-10-13: I think I forgot the “#! /bin/bash” line!

UPDATE 2011-12-01: I added the timelimit command to the script (you can install it with apt-get install timelimit). This command runs another command (nc in my script) and kills it after a specified time lapse. This is useful to handle endless netcat timeout. Remember to raise the default Timeout in the Zabbix configuration file in order to match your command timeout (file /etc/zabbix/zabbix_server.conf, parameter Timeout=10).

#! /bin/bash

cat /etc/zabbix/externalscripts/$1.rad | 
        timelimit -q -t 5 -T 5 nc -u -w 1 $1 1812 | od -t x1 | 
        grep "0000000 02" > /dev/null
if [ $? == 0 ]; then
        echo 1
        exit 1
else
        echo 0
        exit 0
fi

References

Radius RFC: http://www.ietf.org/rfc/rfc2865.txt

Zabbix: http://www.zabbix.com/

Netcat: http://netcat.sourceforge.net/

Wireshark: http://www.wireshark.org/

ACS URL configuration via DHCP Vendor Specific Information

As stated in TR-069, a CPE has 3 ways to know about the ACS URL it has to use for configuration and management; 2 of these ways are not very exciting, while the remaining one opens interesting scenarios for a true plug-and-play deployment.

The not less interesting ACS configuration methods expect the URL to be built-in in the CPE (by factory, for example), or to be configured locally via a LAN-side CPE auto-configuration protocol.

The really interesting method is based on DHCP. Anyway, a CPE doesn’t need to implement this or other methods to be TR-069 compliant; all of them are optional.

Operations

A CPE which implements this mechanism sends a DHCP Request with the string “dslforum.org” in the Vendor Class Identifier (DHCP option 60); at this point, the DHCP server can send back a DHCP ACK with the Vendor Specific Information (DHCP option 43) containing CWMP informations.

This option lets DHCP servers to send one or more vendor specific parameters to clients, encoded in the form option_code/value_length/value; CWMP specifies two parameters: option code 1 for ACS URL and option code 2 for the ProvisioningCode.

When CPE receive the URL it can start the standard CWMP connection and operations with the given ACS.

Applications

The use of this mechanism let us to build interesting scenarios: you can deploy CPEs at the customer sites without a line of configuration, you can bind CPEs CWMP ID to a customer and let DHCP/ACS do the rest, or interact with a RADIUS server to obtain the circuit ID by the IP address and automatically bind it to the right customer.

Configurations

Microsoft Windows Server 2003

DHCP Option 43 on Win2K3 for ACS URL To setup your Microsoft Windows Server 2003 box to send DHCP Option 43 you have to edit the Scope Options and configure it in a way like the one you can see in the image (click to enlarge). To reach this window, you have to open the DHCP management console from the Administrative Tools, then expand the Superscope and the Scope you want to apply the option to. In the example, we used the URL http://my.acs.com.

dhcpd

To configure dhcpd, you can use the option vendor-encapsulated-options option:

subnet 192.168.0.0 netmask 255.255.255.0 {
        option routers 192.168.0.1;
        range 192.168.0.100 192.168.0.105;
        append dhcp-parameter-request-list 43;
        option vendor-encapsulated-options 01:11:68:74:74:70:3A:2F:2F:61:63:73:2E:6D:65:2E:63:6F:6D;
}

In any case you have to remember the 3 fields: option_code, value_length and value.
In this example we use http://acs.me.com as ACS URL, so our option will contain 0x01 (CWMP option for ACS URL), 0x11 (hex of decimal 17 = length of the URL) then the other 17 bytes forming the URL.

You may ask: why the append dhcp-parameter-request-list 43?;
Well, I tested this ACS discovery mechanism with an AVM Fritz!Box Fon 7170 firmware 58.04.67 at its factory settings; I plugged the LAN cable on its LAN1 interface then I powered it up. When it sends its DHCP REQUEST, it does not insert option 43 in the Parameter Request List, so dhcpd doesn’t send it back to the CPE. The above command tells dhcpd to always send option 43 in the OFFER/ACK.

References

TR-069 at Boadband Forum, par. “3.1 ACS Discovery”;

RFC2132 – DHCP Options and BOOTP Vendor Extensions, par. “8.4. Vendor Specific Information”.

Zabbix tool for Cisco Class-Based QoS monitoring

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!

Disclaimer

This is a beta version of the script: use it at your own risk!

Download

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

&lt;?xml version=&quot;1.0&quot;?&gt;
&lt;zabbix_export version=&quot;1.0&quot; date=&quot;21.04.09&quot; time=&quot;17.59&quot;&gt;
	&lt;hosts&gt;
		&lt;host name=&quot;MYCISCODEVICE&quot;&gt;
			&lt;useip&gt;1&lt;/useip&gt;
			&lt;dns&gt;&lt;/dns&gt;
			&lt;ip&gt;192.168.0.1&lt;/ip&gt;
			&lt;port&gt;10050&lt;/port&gt;
			&lt;status&gt;0&lt;/status&gt;
			&lt;groups&gt;
				&lt;group&gt;Router&lt;/group&gt;
			&lt;/groups&gt;
			&lt;templates&gt;
				&lt;template&gt;Template_Cisco_Device&lt;/template&gt;
				&lt;template&gt;Template_MyOwnTemplate&lt;/template&gt;
			&lt;/templates&gt;
			qos.items content goes here
			qos.graphs content goes here
		&lt;/host&gt;
	&lt;/hosts&gt;
	&lt;dependencies&gt;
	&lt;/dependencies&gt;
&lt;/zabbix_export&gt;

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.

Some graphs

Here are some Zabbix graphs generated using the script:

Traffic policing

Traffic policing

Traffic policing class-map

Traffic policing class-map

Interface overview (stack of class-map)

Interface overview (stack of class-map)

Cisco Class-Based QoS SNMP MIB and statistics monitor for NMS

As stated in the official CISCO-CLASS-BASED-QOS-MIB file, Cisco Class-Based QoS MIB “provides read access to Quality of Service (QoS) configuration and statistics information for Cisco platforms that support the Modular Quality of Service Command-line Interface“.

In other words, the integration of this MIB in a SNMP-based NMS lets you to monitor all the values you can see with the show policy-map IOS command.

This MIB has not a so straightforward structure as other MIBs have, so integration with NMS can be a little diffcult.

Let’s take a deeper look at its structure; in a future post I’ll show how to use this information to monitor IOS QoS statistics in Zabbix.

We’ll use the following trivial IOS configuration for our examples:

class-map match-any NonLocal
 match access-group 10
!
class-map match-all ICMP
 match protocol icmp
!
policy-map CPP
  description Applied to control plan - In
 class NonLocal
   police cir 8000
     conform-action transmit
     exceed-action drop
!
policy-map LAN_Out
  description Applied to fa0/0 - Out
 class ICMP
  bandwidth 10
 class class-default
  fair-queue
!
interface FastEthernet0/0
 ip address 192.168.0.8 255.255.255.0
 service-policy output LAN_Out
!
access-list 10 deny   192.168.0.0 0.0.0.255
access-list 10 permit any
!
control-plane
 service-policy input CPP

In this MIB informations are stored on a lot of tables:

  • cbQosServicePolicyTable and cbQosObjectsTable define QoS policies layout;
  • cbQosXXXCfgTable tables define configuration details for the objects (ClassMap, PolicyMap, Match statements…);
  • cbQosXXXStatsTable tables define runtime statistics for the same objects.

As first, we have to look at cbQosServicePolicyTable: here we find bindings between policy-maps and interfaces, as in the service-policy command:

cbQosServicePolicyTable
-----------------------

# snmpwalk -v 2c -c public -m ALL 192.168.0.8 .1.3.6.1.4.1.9.9.166.1.1.1

CISCO-CLASS-BASED-QOS-MIB::cbQosIfType.1043 = INTEGER: mainInterface(1)
CISCO-CLASS-BASED-QOS-MIB::cbQosIfType.1099 = INTEGER: controlPlane(5)
CISCO-CLASS-BASED-QOS-MIB::cbQosPolicyDirection.1043 = INTEGER: output(2)
CISCO-CLASS-BASED-QOS-MIB::cbQosPolicyDirection.1099 = INTEGER: input(1)
CISCO-CLASS-BASED-QOS-MIB::cbQosIfIndex.1043 = INTEGER: 1
CISCO-CLASS-BASED-QOS-MIB::cbQosIfIndex.1099 = INTEGER: 1
CISCO-CLASS-BASED-QOS-MIB::cbQosFrDLCI.1043 = INTEGER: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosFrDLCI.1099 = INTEGER: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosAtmVPI.1043 = Gauge32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosAtmVPI.1099 = Gauge32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosAtmVCI.1043 = Gauge32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosAtmVCI.1099 = Gauge32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosEntityIndex.1043 = INTEGER: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosEntityIndex.1099 = INTEGER: 0

cbQosPolicyIndex is the table’s index (1043, 1099 in the previous example); it identifies the service-policy.

cbQosIfType defines the type of interface which the service-policy is applied to: mainInterface(1), subInterface(2), frDLCI(3), atmPVC(4), controlPlane(5), vlanPort(6).

cbQosPolicyDirection tells the direction of the traffic: input(1) and output(2).

Other parameters depend on cbQosIfType value and represent specific objects identifiers (ifIndex, DLCI, VPI/VCI, … ).

From the previous example we can see there are 2 service-policies, with ID 1043 and 1099, applied for output traffic to a physical interface with ifIndex 1, and for input traffic to the control-plane.

The second important table is cbQosObjectsTable, where all objects (class-map, match, set statements…) are stored, classified (cbQosObjectsType), identified within the configuration (cbQosConfigIndex) and related to the service-policy or other objects (cbQosParentObjectsIndex). Here we have a two-fields index: cbQosPolicyIndex and cbQosObjectsIndex:

cbQosObjectsTable
-----------------

# snmpwalk -v 2c -c public -m ALL 192.168.0.8 .1.3.6.1.4.1.9.9.166.1.5.1

CISCO-CLASS-BASED-QOS-MIB::cbQosConfigIndex.1043.1043 = Gauge32: 1035
CISCO-CLASS-BASED-QOS-MIB::cbQosConfigIndex.1043.1045 = Gauge32: 1029
CISCO-CLASS-BASED-QOS-MIB::cbQosConfigIndex.1043.1047 = Gauge32: 1033
CISCO-CLASS-BASED-QOS-MIB::cbQosConfigIndex.1043.1049 = Gauge32: 1037
CISCO-CLASS-BASED-QOS-MIB::cbQosConfigIndex.1043.1051 = Gauge32: 1025
CISCO-CLASS-BASED-QOS-MIB::cbQosConfigIndex.1043.1053 = Gauge32: 1027
CISCO-CLASS-BASED-QOS-MIB::cbQosConfigIndex.1043.1085 = Gauge32: 1079
CISCO-CLASS-BASED-QOS-MIB::cbQosConfigIndex.1099.1099 = Gauge32: 1063
CISCO-CLASS-BASED-QOS-MIB::cbQosConfigIndex.1099.1101 = Gauge32: 1057
CISCO-CLASS-BASED-QOS-MIB::cbQosConfigIndex.1099.1103 = Gauge32: 1061
CISCO-CLASS-BASED-QOS-MIB::cbQosConfigIndex.1099.1105 = Gauge32: 1065
CISCO-CLASS-BASED-QOS-MIB::cbQosConfigIndex.1099.1107 = Gauge32: 1025
CISCO-CLASS-BASED-QOS-MIB::cbQosConfigIndex.1099.1109 = Gauge32: 1027
CISCO-CLASS-BASED-QOS-MIB::cbQosObjectsType.1043.1043 = INTEGER: policymap(1)
CISCO-CLASS-BASED-QOS-MIB::cbQosObjectsType.1043.1045 = INTEGER: classmap(2)
CISCO-CLASS-BASED-QOS-MIB::cbQosObjectsType.1043.1047 = INTEGER: matchStatement(3)
CISCO-CLASS-BASED-QOS-MIB::cbQosObjectsType.1043.1049 = INTEGER: queueing(4)
CISCO-CLASS-BASED-QOS-MIB::cbQosObjectsType.1043.1051 = INTEGER: classmap(2)
CISCO-CLASS-BASED-QOS-MIB::cbQosObjectsType.1043.1053 = INTEGER: matchStatement(3)
CISCO-CLASS-BASED-QOS-MIB::cbQosObjectsType.1043.1085 = INTEGER: queueing(4)
CISCO-CLASS-BASED-QOS-MIB::cbQosObjectsType.1099.1099 = INTEGER: policymap(1)
CISCO-CLASS-BASED-QOS-MIB::cbQosObjectsType.1099.1101 = INTEGER: classmap(2)
CISCO-CLASS-BASED-QOS-MIB::cbQosObjectsType.1099.1103 = INTEGER: matchStatement(3)
CISCO-CLASS-BASED-QOS-MIB::cbQosObjectsType.1099.1105 = INTEGER: police(7)
CISCO-CLASS-BASED-QOS-MIB::cbQosObjectsType.1099.1107 = INTEGER: classmap(2)
CISCO-CLASS-BASED-QOS-MIB::cbQosObjectsType.1099.1109 = INTEGER: matchStatement(3)
CISCO-CLASS-BASED-QOS-MIB::cbQosParentObjectsIndex.1043.1043 = Gauge32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosParentObjectsIndex.1043.1045 = Gauge32: 1043
CISCO-CLASS-BASED-QOS-MIB::cbQosParentObjectsIndex.1043.1047 = Gauge32: 1045
CISCO-CLASS-BASED-QOS-MIB::cbQosParentObjectsIndex.1043.1049 = Gauge32: 1045
CISCO-CLASS-BASED-QOS-MIB::cbQosParentObjectsIndex.1043.1051 = Gauge32: 1043
CISCO-CLASS-BASED-QOS-MIB::cbQosParentObjectsIndex.1043.1053 = Gauge32: 1051
CISCO-CLASS-BASED-QOS-MIB::cbQosParentObjectsIndex.1043.1085 = Gauge32: 1051
CISCO-CLASS-BASED-QOS-MIB::cbQosParentObjectsIndex.1099.1099 = Gauge32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosParentObjectsIndex.1099.1101 = Gauge32: 1099
CISCO-CLASS-BASED-QOS-MIB::cbQosParentObjectsIndex.1099.1103 = Gauge32: 1101
CISCO-CLASS-BASED-QOS-MIB::cbQosParentObjectsIndex.1099.1105 = Gauge32: 1101
CISCO-CLASS-BASED-QOS-MIB::cbQosParentObjectsIndex.1099.1107 = Gauge32: 1099
CISCO-CLASS-BASED-QOS-MIB::cbQosParentObjectsIndex.1099.1109 = Gauge32: 1107

cbQosConfigIndex let us to find configuration details about objects in other tables; service-policies have the same cbQosObjectsIndex as cbQosPolicyIndex. These config tables are cbQosObjectsType dependent: we have cbQosPolicyMapCfgTable, cbQosClassMapCfgTable, cbQosMatchStmtCfgTable… each object type has its own table, all referenced by cbQosConfigIndex.

Let’s see one of them…

cbQosPolicyMapCfgTable
----------------------

# snmpwalk -v 2c -c public -m ALL 192.168.0.8 .1.3.6.1.4.1.9.9.166.1.6.1

CISCO-CLASS-BASED-QOS-MIB::cbQosPolicyMapName.1035 = STRING: LAN_Out
CISCO-CLASS-BASED-QOS-MIB::cbQosPolicyMapName.1063 = STRING: CPP
CISCO-CLASS-BASED-QOS-MIB::cbQosPolicyMapDesc.1035 = STRING: Applied to fa0/0 - Out
CISCO-CLASS-BASED-QOS-MIB::cbQosPolicyMapDesc.1063 = STRING: Applied to control plan - In

We can see here our policy-maps, indexed by the cbQosConfigIndex values previously found on cbQosObjectsTable.

With the cbQosObjectsTable data we already have all informations we need to build an OID list for our NMS.

Assume we just need to monitor class-map offered rate and drop rate, as in the show policy-map interface | inc Class-map|offered. All per class-map statistics are collected on the cbQosCMStatsTable; as all stats table, it’s indexed by cbQosPolicyIndex and cbQosObjectsIndex. Take a look at the table:

cbQosCMStatsTable
-----------------

# snmpwalk -v 2c -c public -m ALL 192.168.0.8 .1.3.6.1.4.1.9.9.166.1.15.1.1

CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyPktOverflow.1043.1045 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyPktOverflow.1043.1051 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyPktOverflow.1099.1101 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyPktOverflow.1099.1107 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyPkt.1043.1045 = Counter32: 8
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyPkt.1043.1051 = Counter32: 1131
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyPkt.1099.1101 = Counter32: 281
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyPkt.1099.1107 = Counter32: 7016
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyPkt64.1043.1045 = Counter64: 8
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyPkt64.1043.1051 = Counter64: 1131
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyPkt64.1099.1101 = Counter64: 281
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyPkt64.1099.1107 = Counter64: 7016
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyByteOverflow.1043.1045 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyByteOverflow.1043.1051 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyByteOverflow.1099.1101 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyByteOverflow.1099.1107 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyByte.1043.1045 = Counter32: 784
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyByte.1043.1051 = Counter32: 114630
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyByte.1099.1101 = Counter32: 69858
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyByte.1099.1107 = Counter32: 658800
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyByte64.1043.1045 = Counter64: 784
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyByte64.1043.1051 = Counter64: 114630
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyByte64.1099.1101 = Counter64: 69858
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyByte64.1099.1107 = Counter64: 658800
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyBitRate.1043.1045 = Gauge32: 0 bits per second
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyBitRate.1043.1051 = Gauge32: 0 bits per second
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyBitRate.1099.1101 = Gauge32: 0 bits per second
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyBitRate.1099.1107 = Gauge32: 1000 bits per second
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPostPolicyByteOverflow.1043.1045 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPostPolicyByteOverflow.1043.1051 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPostPolicyByteOverflow.1099.1101 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPostPolicyByteOverflow.1099.1107 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPostPolicyByte.1043.1045 = Counter32: 784
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPostPolicyByte.1043.1051 = Counter32: 114630
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPostPolicyByte.1099.1101 = Counter32: 69668
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPostPolicyByte.1099.1107 = Counter32: 658800
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPostPolicyByte64.1043.1045 = Counter64: 784
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPostPolicyByte64.1043.1051 = Counter64: 114630
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPostPolicyByte64.1099.1101 = Counter64: 69668
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPostPolicyByte64.1099.1107 = Counter64: 658800
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPostPolicyBitRate.1043.1045 = Gauge32: 0 bits per second
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPostPolicyBitRate.1043.1051 = Gauge32: 2000 bits per second
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPostPolicyBitRate.1099.1101 = Gauge32: 2000 bits per second
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPostPolicyBitRate.1099.1107 = Gauge32: 2000 bits per second
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropPktOverflow.1043.1045 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropPktOverflow.1043.1051 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropPktOverflow.1099.1101 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropPktOverflow.1099.1107 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropPkt.1043.1045 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropPkt.1043.1051 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropPkt.1099.1101 = Counter32: 4
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropPkt.1099.1107 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropPkt64.1043.1045 = Counter64: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropPkt64.1043.1051 = Counter64: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropPkt64.1099.1101 = Counter64: 4
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropPkt64.1099.1107 = Counter64: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropByteOverflow.1043.1045 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropByteOverflow.1043.1051 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropByteOverflow.1099.1101 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropByteOverflow.1099.1107 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropByte.1043.1045 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropByte.1043.1051 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropByte.1099.1101 = Counter32: 380
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropByte.1099.1107 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropByte64.1043.1045 = Counter64: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropByte64.1043.1051 = Counter64: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropByte64.1099.1101 = Counter64: 380
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropByte64.1099.1107 = Counter64: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropBitRate.1043.1045 = Gauge32: 0 bits per second
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropBitRate.1043.1051 = Gauge32: 0 bits per second
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropBitRate.1099.1101 = Gauge32: 0 bits per second
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropBitRate.1099.1107 = Gauge32: 0 bits per second
CISCO-CLASS-BASED-QOS-MIB::cbQosCMNoBufDropPktOverflow.1043.1045 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMNoBufDropPktOverflow.1043.1051 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMNoBufDropPktOverflow.1099.1101 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMNoBufDropPktOverflow.1099.1107 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMNoBufDropPkt.1043.1045 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMNoBufDropPkt.1043.1051 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMNoBufDropPkt.1099.1101 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMNoBufDropPkt.1099.1107 = Counter32: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMNoBufDropPkt64.1043.1045 = Counter64: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMNoBufDropPkt64.1043.1051 = Counter64: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMNoBufDropPkt64.1099.1101 = Counter64: 0
CISCO-CLASS-BASED-QOS-MIB::cbQosCMNoBufDropPkt64.1099.1107 = Counter64: 0

We just need to select cbQosPolicyIndex and cbQosObjectsIndex values from cbQosObjectsTable where cbQosObjectsType = classmap(2) and attach them to the counter we need to monitor.

CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyBitRate.1043.1045 = Gauge32: 0 bits per second
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyBitRate.1043.1051 = Gauge32: 0 bits per second
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyBitRate.1099.1101 = Gauge32: 0 bits per second
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPrePolicyBitRate.1099.1107 = Gauge32: 1000 bits per second

CISCO-CLASS-BASED-QOS-MIB::cbQosCMPostPolicyBitRate.1043.1045 = Gauge32: 0 bits per second
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPostPolicyBitRate.1043.1051 = Gauge32: 2000 bits per second
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPostPolicyBitRate.1099.1101 = Gauge32: 2000 bits per second
CISCO-CLASS-BASED-QOS-MIB::cbQosCMPostPolicyBitRate.1099.1107 = Gauge32: 2000 bits per second

CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropBitRate.1043.1045 = Gauge32: 0 bits per second
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropBitRate.1043.1051 = Gauge32: 0 bits per second
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropBitRate.1099.1101 = Gauge32: 0 bits per second
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDropBitRate.1099.1107 = Gauge32: 0 bits per second

To have more details about the ClassMap statements to which these stats are related we can look at their configuration: as first we need their cbQosConfigIndex:

# snmpget -v 2c -c public -m ALL 192.168.0.8 .1.3.6.1.4.1.9.9.166.1.5.1.1.2.1043.1045

CISCO-CLASS-BASED-QOS-MIB::cbQosConfigIndex.1043.1045 = Gauge32: 1029

With cbQosConfigIndex we can get class-map details; this is the cbQosCMCfgTable table:

cbQosCMCfgTable
----------------

# snmpwalk -v 2c -c public -m ALL 192.168.0.8 .1.3.6.1.4.1.9.9.166.1.7.1

CISCO-CLASS-BASED-QOS-MIB::cbQosCMName.1025 = STRING: class-default
CISCO-CLASS-BASED-QOS-MIB::cbQosCMName.1029 = STRING: ICMP
CISCO-CLASS-BASED-QOS-MIB::cbQosCMName.1057 = STRING: NonLocal
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDesc.1025 = STRING:
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDesc.1029 = STRING:
CISCO-CLASS-BASED-QOS-MIB::cbQosCMDesc.1057 = STRING:
CISCO-CLASS-BASED-QOS-MIB::cbQosCMInfo.1025 = INTEGER: matchAny(3)
CISCO-CLASS-BASED-QOS-MIB::cbQosCMInfo.1029 = INTEGER: matchAll(2)
CISCO-CLASS-BASED-QOS-MIB::cbQosCMInfo.1057 = INTEGER: matchAny(3)

We can easily get the class-map name:

# snmpget -v 2c -c public -m ALL 192.168.0.8 .1.3.6.1.4.1.9.9.166.1.7.1.1.1.1029

CISCO-CLASS-BASED-QOS-MIB::cbQosCMName.1029 = STRING: ICMP

Of course we can build NMS configuration including more details from both objects details and statistics.

Please note that, by default, indexes “are never reused between router reboots, even when changes are made to the QoS configuration“. This is stated in the CISCO-CLASS-BASED-QOS-MIB file. Fortunately, starting from 12.4(4)T, the cbqos keyword has been added to the snmp mib persist global command.

As said, as soon as possibile I’ll post a script to use Cisco CBQoS in Zabbix… stay tuned! 😉

Some useful links:

OpenACS configuration and scripting

As first, congrats to Audrys, aka au3, OpenACS author; I played a little with OpenACS and it seems to be a really good TR-069 framework, even if in beta version.

In the last days I have found some bugs, immediately fixed by the author in the svn version; at this time (svn revision 181 and release 0.03) I suggest you to download the latest svn version and compile it (on Debian you need subversion package):

svn co http://openacs.svn.sourceforge.net/svnroot/openacs openacs
ant -f b.xml
cp dist/acs.ear /opt/jboss/server/default/deploy/

If you already have it running, be aware you need to drop db tables and lets the svn version to create them.

OpenACS exposes a javascript engine you can use to implement your configuration server logic. Of course, you need to know TR-069 (CWMP) and related Technical Reports; you can find these documents here: Broadband Forum Technical Reports

OpenACS runs the “Default” script for each Inform request it receives: in this script you can do your business and call other script.
On each script you can access objects exposed by OpenACS: you can find some information on the OpenACS wiki page on SourceForge.

You can find a Default script example at the end of this post.

Actually I’m testing OpenACS with AVM Fritz!Box Fon 7170 and they really speak the same language! Firmware upgrade and configuration changes work good, I have not yet tested parameter attributes and notification changes.

If you are interested in this matter, stay tuned! 😉

My Default script:

var i;
var sData;

sData = 'n==========================================================';
sData += 'nDeviceId:';
sData += 'n   Manufacturer: ' + cpe.Inform.DeviceId.Manufacturer;
sData += 'n   OUI: ' + cpe.Inform.DeviceId.OUI;
sData += 'n   ProductClass: ' + cpe.Inform.DeviceId.ProductClass;
sData += 'n   SerialNumber: ' + cpe.Inform.DeviceId.SerialNumber;
sData += 'nMisc:';
sData += 'n   MaxEnvelopes: ' + cpe.Inform.MaxEnvelopes;
sData += 'n   RetryCount: ' + cpe.Inform.RetryCount;
sData += 'n   CurrentTime: ' + cpe.Inform.CurrentTime;

sData += 'nEvents:' ;

for( i=0; i&lt;=cpe.Inform.Event.length-1; i++ )
   sData += 'n   ' + cpe.Inform.Event[i].EventCode+' ['+cpe.Inform.Event[i].CommandKey + ']';

sData += 'nParams:';

for( i=0; i&lt;=cpe.Inform.ParameterList.length-1; i++ )
   sData += 'n   ' + cpe.Inform.ParameterList[i].Name+'='+cpe.Inform.ParameterList[i].Value;

sData += 'n';
sData += 'n==========================================================';

logger( sData );

// ------------------------------------------------------------------------------
for( i=0; i&lt;=cpe.Inform.ParameterList.length-1; i++ )
{
       switch ( cpe.Inform.ParameterList[i].Name )
       {
               case 'InternetGatewayDevice.ManagementServer.ParameterKey':
                       cpedb.ManagementServer_ParameterKey = cpe.Inform.ParameterList[i].Value;
                       break;

               case 'InternetGatewayDevice.DeviceInfo.SpecVersion':
                       cpedb.DeviceInfo_SpecVersion = cpe.Inform.ParameterList[i].Value;
                       break;

               case 'InternetGatewayDevice.DeviceInfo.HardwareVersion':
                       cpedb.DeviceInfo_HardwareVersion = cpe.Inform.ParameterList[i].Value;
                       break;

               case 'InternetGatewayDevice.DeviceInfo.SoftwareVersion':
                       cpedb.DeviceInfo_SoftwareVersion = cpe.Inform.ParameterList[i].Value;
                       break;

               case 'InternetGatewayDevice.DeviceInfo.ProvisioningCode':
                       cpedb.DeviceInfo_ProvisioningCode = cpe.Inform.ParameterList[i].Value;
                       break;

               case 'InternetGatewayDevice.ManagementServer.ConnectionRequestURL':
                       cpedb.ManagementServer_ConnectionRequestURL = cpe.Inform.ParameterList[i].Value;
                       break;

               default:
                       if( cpe.Inform.ParameterList[i].Name.indexOf( 'InternetGatewayDevice.WANDevice.' ) &gt;= 0 )
                       {
                               cpedb.DefaultWANConnection = cpe.Inform.ParameterList[i].Name.substr( 0, cpe.Inform.ParameterList[i].Name.indexOf( '.ExternalIPAddress' ) );
                               cpedb.DefaultWANConnection_ExternalIPAddress = cpe.Inform.ParameterList[i].Value;
                       }
                       break;
       }
}
cpedb.Save()

var sEvent;
var sCommandKey;
for( i=0; i&lt;=cpe.Inform.Event.length-1; i++ )
{
       sEvent = cpe.Inform.Event[i].EventCode;
       sCommandKey = cpe.Inform.Event[i].CommandKey;

       switch ( sEvent )
       {
               case '0 BOOTSTRAP':
                       break;

               case '1 BOOT':
                       break;

               case '2 PERIODIC':
                       break;

               case '3 SCHEDULED':
                       break;

               case '4 VALUE CHANGE':
                       break;

               case '5 KICKED':
                       break;

               case '6 CONNECTION REQUEST':
                       break;

               case '7 TRANSFER COMPLETE':
                       break;

               case '8 DIAGNOSTICS COMPLETE':
                       break;
       }
}

DoSomething();