Cisco Performance Engine User Guide, 2.1.5 - Configuring the Collectors [Cisco Performance Engine]

Table Of Contents

Configuring the Collectors

BTS Collectors

BtsBilling Collector

Requirements

XML Configuration

Data Export

Threshold Crossing Alerts

BtsBilling Collector Plugin

Properties File

BtsTm Collector

XML Configuration

Data Export

Threshold Crossing Alerts and Purging Data

Properties File

BulkMib Collector

Requirements

XML Configuration

Creating a BulkMib Collector Using the GUI

Sample XML Configuration

Data Export, Threshold Crossing Alerts, Purging Data, and Hotspot Polling

Limitations

BulkMib Collector Plugins

Sample Configuration

ByteCap Data Collector

Requirements

XML Configuration

Hotspot and Periodic Exported Data

Summary Exported Data

CallMgrCdr Collector

Cisco Call Manager Setup Requirements

CallMgrCdr Collector Setup

Configuring CallMgrCdr Using the GUI

Creating a Schedule

Creating a Device

Creating a Device for a Secure Mode of Collection

Creating Data Export1

Creating a Data Export2

Creating Data Export3

Creating an Event Notification

Creating a Threshold

Creating a CallMgrCdr Collector

XML Configuration with JDBC Mode

XML Configuration with SSH/SFTP Mode

Data Export

CDR Report Format

CDR Plus CMR Report Format

Summarized Hourly Report Format

Summarized Daily Report Format

CDRPlusCMR Report Format

Hourly Report Format

Threshold Crossing Alerts

CBQoS Collector

XML Configuration

Thresholds

Data Export Format

ClusterMib Collector

XML Configuration

Data Export

Threshold Crossing Alerts, Purging Data, and Hotspot Polling

Limitations

DOCSIS Data Collector

Requirements

XML Configuration

Database Tables

Data Export, Threshold Crossing Alerts, Purging Data, and Hotspot Polling

Data Export

Pre-Defined Queries

Threshold Crossing Alerts

Purging Data

IosCliOps Collector

Creating an IosCliOps Collector with the GUI

XML Configuration

Syntax of Regular Expression File

Data Export Format

Threshold Crossing Alerts, Purging Data, and Hotspot Polling

Add/Remove Operations From a Device

Add/Remove Operations From a Device Group

Limitations

Mib Collector

Requirements

Create a Mib Collector with SNMP Get

XML Configuration

Table Retrieval

Selective Polling

Data Export

Threshold Crossing Alerts, Purging Data, and Hotspot Polling

Limitations

Mib Collector Plugins

Processor Plugin

Formatter Plugin

Data Export

Threshold Processing on Plugin Data

NetFlowMediator Collector

Requirements

XML Configuration

Data Export

Threshold Crossing Alerts and Hotspot Polling

Purging Data

Limitations

MPLS/VPN PE-PE Traffic Reports

Configuration

Output Format

RADIUS Collector

Requirements

XML Configuration

Data Export

Threshold Crossing Alerts, Purging Data, and Hotspot Polling

Limitations

SAA Collectors

SAA Collector Add/Remove Operations

SAA Collectors in Cisco PerfE

Configuration of the SAA Operation

SAAIcmpEcho Collector

Requirements

XML Configuration

Creating an SaaIcmpEcho Collector with the GUI

Data Export

Threshold Crossing Alerts, Purging Data, and Hotspot Polling

Limitations

SAAJitter Collector

Requirements

XML Configuration

Creating an SaaJitter Collector with the GUI

Creating an SaaJitter Collector for CODEC Data Collection

Data Export

Threshold Crossing Alerts, Purging Data, and Hotspot Polling

Limitations

SAAUdpEcho Collector

Requirements

XML Configuration

Creating an SaaUdpEcho Collector with the GUI

Data Export

Threshold Crossing Alerts, Purging Data, and Hotspot Polling

Limitations

System Collector

Requirements

Creating a System Collector with the GUI

Viewing System Collector Data as Graphs

XML Configuration

Threshold Processing

Data Export, Threshold Crossing Alerts, and Purging Data

Limitations

VoiceCallStatistics Collector

Requirements

XML Configuration

Data Export

Threshold Crossing Alerts, Purging Data, and Hotspot Polling

VoipDAS Collector

Requirements

XML Configuration

Data Export, Threshold Crossing Alerts, Purging Data, and Hotspot Polling

Limitations

VPDNCustomer Collector

XML Configuration

Data Export

Threshold Crossing Alerts, Purging Data, and Hotspot Polling

Configuring the Collectors

This chapter describes the format of the XML files that are used to set up and collect data from the collectors. The XML files describe the collectors by specifying schedules, devices, data handlers, notifiers, and collector names. Each collector type has its own set of parameters that must be defined.

Several of the collectors support hotspot polling, data exporting, data purging, and threshold processing. Cisco PerfE also has built-in VoIP templates you can use to set up collectors. Refer to Chapter 5, "Features Supported by Collectors," for specific information on the XML format for these features.

This chapter is divided into sections for each type of collector. Each section describes that collector's unique attributes and how to set them.

•BTS Collectors

–BtsBilling Collector

–BtsTm Collector

•BulkMib Collector

•ByteCap Data Collector

•CallMgrCdr Collector

•CBQoS Collector

•ClusterMib Collector

•DOCSIS Data Collector

•IosCliOps Collector

•Mib Collector

•NetFlowMediator Collector

•RADIUS Collector

•SAA Collectors

–SAAIcmpEcho Collector

–SAAJitter Collector

–SAAUdpEcho Collector

•System Collector

•VoiceCallStatistics Collector

•VoipDAS Collector

•VPDNCustomer Collector.

BTS Collectors

This section assumes you are familiar with the BTS 10200 product. Refer to the following web site for more information on the BTS 10200 product:

http://www.cisco.com/univercd/cc/td/doc/product/voice/index.htm

Note A Cisco Connection Online (CCO) username and password is required to access the BTS 10200 documentation.

BtsBilling Collector

The BtsBilling collector waits for Cisco PerfE or the Billing Mediator to FTP billing records over to the Cisco PerfE and processes the records according to the XML configuration.

The BtsQosProcessor plugin will extract only Quality of S3ervice (QoS) information from the records and export this data. Cisco PerfE does not configure a BTS EMS.

Requirements

Note This requirement is needed when the BTS EMS will be sending CDRs directly to the Cisco PerfE host. If a mediator is placed between the BTS EMS and Cisco PerfE host, refer to the mediator's User Guide to determine how to configure the BTS EMS host.

The billing account address must be configured at the BTS EMS host manually. Use the change billing-acct-addr command to send a billing record to the Cisco PerfE host:
change billing-acct-addr; 
billing-file-prefix=<cnsperfe->; 
billing-server-addr=<CNS_PerfE_host-ip-address>; 
billing-server-directory=<CNS_PerfE_Home>/data/bts/cdr; 
user-name=dasadmin; 
password=<dasadmin-password>; 
polling-internal=15;
XML Configuration
<das>
      <create>
            <schedule name="15M">
                  <interval>PT15M</interval>
            </schedule>
            <schedule name="30M">
                  <interval>PT30M</interval>
            </schedule>
            <device name="BtsHost">
                  <telnet>
                        <ipaddress>10.0.0.1</ipaddress>
                        <username>user1</username>
                        <password>pass1</password>
                  </telnet>
                  <ftp>
                  </ftp>
            </device>
            <dataHandler name="BtsBillingHandler">
                  <url>
                        <prefix>ftp://user2:pass2@10.0.0.4/%2Fdata/</prefix>
                  </url>
            </dataHandler>
            <processor name="BtsQos">
                  <plugin name="QOS">
                        <class>com.cisco.das.BTSCollector.BtsQosProcessor</class>
                        <parameter name="version">3.3</parameter>
                  </plugin>
            </processor>
            <collector name="BtsBilling">
                  <BtsBillingCollector>
                        <processor name="BtsQos"/>
                        <schedule name="15M"/>
                        <device name="BtsHost"/>
                        <dataHandler name="BtsBillingHandler">
                              <schedule name="30M"/>
                        </dataHandler>
                  </BtsBillingCollector>
             </collector>
      </create>
      <add/>
      <start>
            <collector name="BtsBilling"/>
      </start>
</das>
Data Export

The BtsQosProcessor plugin only exports the following information:
<HEADER>COLLECT_TIMESTAMP,BILLING_CALL_TYPE,BILLING_CALL_ELAPSED_T
IME,BILLING_ORIG_NUMBER,BILLING_TERM_NUMBER,ORIG_QOS_TIME,TERM_QOS
_TIME,ORIG_QOS_PACKETS_SENT,ORIG_QOS_PACKETS_RECD,ORIG_QOS_OCTETS_S
ENT,ORIG_QOS_OCTETS_RECD,ORIG_QOS_PACKETS_LOST,ORIG_QOS_JITTER,ORIG_
QOS_AVG_LATENCY,TERM_QOS_PACKETS_SENT,TERM_QOS_PACKETS_RECD,TERM
_QOS_OCTETS_SENT,TERM_QOS_OCTETS_RECD,TERM_QOS_PACKETS_LOST,TERM_
QOS_JITTER,TERM_QOS_AVG_LATENCY</HEADER>
<DATA>2002-10-19 19:31:19.88,3,00:01:20,9723701417,,2,,1,2,0,0,0,0,66,0,0,0,0,0,
0,0</DATA>
If the BtsBilling collector is configured without the BtsQosProcessor plugin, the collector exports the billing records in the same format as the BTS EMS. Refer to the BTS 10200 documentation for the complete format of the billing records.

Threshold Crossing Alerts

The BtsBilling collector supports thresholds in Qos data only.
<threshold name="QoSOrigJitter">
   <attribute name=ORIG_QOS_JITTER">
         <raiseOperation>GTE</raiseOperation>
         <raiseValue>500</raiseValue>
         <clearOperation>LT</clearOperation>
         <clearValue>200<</clearValue>
         <level>major</level>
  </attribute>
</threshold>
BtsBilling Collector Plugin

The BtsBilling collector supports the BtsQosProcessor processor plugin.

When this plugin is configured, the BtsBilling collector only exports QoS data, otherwise, it exports the complete billing records received from the BTS EMS.

Properties File

das.properties:
bts.billing.ftp.dir=<billing records ftp over from bts ems or mediation system>
bts.billing.file.prefix=<billing file prefix>
Note These values should match the values specified in the change billing-acct-addr command only when CDRs are sent directly to the BTS EMS.

BtsTm Collector

The BtsTm collector retrieves various Traffic Measurement (TM) reports from the BTS EMS host.

The following traffic measurement categories are available from the BTS 10200 EMS:

Measurement Data Type

Measure Data Description

ISDN

ISDN signaling protocol-related information.

CALLP

Call processing specific information.

MGA

MGCP signaling protocol-related information.

SIM

Service Interaction Manager related information.

POT-FS

POTS/Centrex/Tandem Feature related information.

AIN-FS

AIN Feature Server related information.

ISUP

ISDN User Part (SS7) signaling protocol information.

TG-USAGE

Trunk Group usage-related information.

ANM

Announcement Server related information.

H323

H.323 signaling protocol-related information.

BILLING

Call Detail Data related information.

SIA

Signaling Interface Adapter related information.

For an overview of the various measurement data reports for the BTS 10200, see Appendix B, "Measurement Data Report Formats".

XML Configuration
<das>
      <create>
            <schedule name="S1">
                  <start>2003-01-01T00:05:00.000-00:00</start>
                  <interval>PT15M</interval>
            </schedule>
            <schedule name="S2">
                  <start>2003-01-01T00:07:00.000-00:00</start>
                  <interval>PT15M</interval>
            </schedule>
            <device name="BtsHost">
                  <telnet>
                        <ipaddress>10.0.0.1</ipaddress>
                        <username>optiuser</username>
                        <password>optiuser</password>
                        <prompt>CLI</prompt>
                  </telnet>
                  <ftp>
                        <ipaddress>10.0.0.1</ipaddress>
                        <username>optiuser</username>
                        <password>optiuser</password>
                  </ftp>
            </device>
            <dataHandler name="BtsTmDH">
                  <ftp>
                        <urlPrefix>ftp://user1:pass1@10.0.0.1/data/</urlPrefix>
                  </ftp>
            </dataHandler>
            <notifier name="BtsNotifier">
                  <cns>
                        <subject>cns.cisco.das.listener</subject>
                  </cns>
            </notifier>
            <threshold name="MGA_TPM_UNREACHABLE">
                  <attribute name="mga.MGA_TPM_UNREACHABLE">
                        <raiseOperation>GT</raiseOperation>
                        <raiseValue>0</raiseValue>
                        <clearOperation>EQ</clearOperation>
                        <clearValue>0</clearValue>
                        <level>minor</level>
                  </attribute>
            </threshold>
            <collector name="BtsTm01">
                  <BtsTmCollector>
                        <schedule name="S1"/>
                        <device name="BtsHost"/>
                        <threshold name="MGA_TPM_UNREACHABLE"/>
                        <notifier name="BtsNotifier"/>
                        <dataHandler name="BtsTmDH">
                              <schedule name="S2"/>
                        </dataHandler>
                        <tmType>mga</tmType>
                        <tmType>tg-usage</tmType>
                        <standbyEMS>10.0.0.2</standbyEMS>
                  </BtsTmCollector>
            </collector>
      </create>
      <start>
            <collector name="BtsTm01"/>
      </start>
</das>
The BTS-EMS generates reports every fifteen minutes. Therefore, the scheduler S1 is configured to collect data from the BTS-EMS every fifteen minutes, plus some offset. The offset in this case is five minutes as indicated by the <start> tag.

Data Export

The file contains the name of the report, in this case MGA, then attribute names are specified in the <header> tag, followed by the actual data values specified in the <data> tag.
<MGA>
<HEADER>MGA_TIMESTAMP,MGA_TPM_DECODER_ERROR,MGA_TPM_ENC
ODE_ERROR,MGA_TPM_UNREACHABLE,MGA_TPM_SEND_FAILED,MGA_TP
M_CRCX_ACK_RECVD,MGA_TPM_CRCX_NACK_RECVD,MGA_TPM_CRCX_S
ENT,MGA_TPM_MDCX_ACK_RECVD,MGA_TPM_MDCX_NACK_RECVD,MGA
_TPM_MDCX_SENT,MGA_TPM_DLCX_RECVD,MGA_TPM_DLCX_SENT,MGA_
TPM_DLCX_ACK_RECVD,MGA_TPM_RQNT_ACK_RECVD,MGA_TPM_RQNT_
SENT,MGA_TPM_AUEP_ACK_RECVD,MGA_TPM_AUEP_NACK_RECVD,MGA_
TPM_AUEP_SENT,MGA_TPM_NTFY_RECVD,MGA_TPM_RSIP_RECVD,MGA_T
PM_RSIP_ACK_SENT</HEADER>
<DATA>2002-05-05 16:15:00,0,0,0,0,30,0,30,50,0,50,0,32,32,0,189,0,189,0,0,0 
</DATA>
</MGA>
Each exported data file has the following format:
<reportName>
      <header>col1Name, col2Name,....colXName</header>
      <data>col1Data,col2Data,....colXData</data>
</reportName>
The number of columns within the <data> tag might be less than the number of columns in the <header> tag depending upon the BTS 10200 version used.

Threshold Crossing Alerts and Purging Data

The BtsTm collector supports thresholds. The threshold attribute name format is:
<report-name>.<attr-name>
Example:
mga.MGA_TPM_UNREACHABLE
See the XML configuration for a complete example (above).

The following is the syntax for thresholds relating to TG-USAGE reports:
tg-usage.<attrName>.<grptype>.<grpid>
Thresholds for all trunk groups:
tg-usage.<attrName>
Thresholds for a particular trunk group:
tg-usage.<attrName>.<grptype>
Threshold for a particular trunk group type and id:
tg.usage.<attrName>.grptype>.<grpid>
The BtsTm Collector also supports purging of collected performance data. This is done on a schedule configured for all of Cisco PerfE or based on an individual purger.

Properties File

das.properties:
bts.tm.report.dir=<bts ems dir where reports are located>
bts.tm.file.prefix=<report file prefix>
bts.cnspe.tmp.dir=<where to ftp the reports from bts ems>
BulkMib Collector

Many Cisco devices support SNMP for performance data retrieval. Retrieving large tables using SNMP results in many SNMP getbulk requests, resulting in more overhead. Therefore, many Cisco devices support bulk file transfer to retrieve large tables. The device must be configured to indicate the objects to retrieve through the bulk transfer facility and when the transfer is requested, the device writes these objects to the specified file and transfers the file using FTP to the requested host. The BulkMIB collector limits bulk file transfer to only tables (the OIDs specified in the BulkMib collector tag must be the OIDs of a table).

The BulkMib collector uses the CISCO-BULK-MIB.my and CISCO-FTP-CLIENT.my MIBs at the device. During each collection period, the BulkMib collector configures the bulk MIB and FTP client MIB, requests the file be created, and requests the file be sent using FTP. It then removes the configuration at the device. Therefore, certain overhead is associated for Cisco PerfE when setting up bulk MIB transfers for each collection and the device must generate and FTP the file for each collection. Due to these reasons, it is recommended a bulk MIB transfer be used for retrieving large tables with a reasonable collection frequency.

FTP related parameters are mandatory parameters that you have to configure. This information is not maintained in the das.properties file.

Except for data collection, the BulkMib and Mib collectors behave similarly with respect to threshold processing, data export, and data purge.

Requirements

You must set the limits for the tables in these MIBs appropriately (cbfDefineMaxFile, cbfDefineMaxObjects, cbfStatusMaxFiles, and cfcRequestMaximum).

The properties bulkmib.ftp.username and bulkmib.ftp.password are stored in CISCO-FTP-CLIENT-MIB.my.

The user account used for FTP must have write privileges to the <CNS_PerfE_Home>/tmp directory. Furthermore, the FTP daemon must be enabled on the Cisco PerfE host.

In addition, take note of the following:

•Cisco IOS software release 12.0 or later is recommended. Earlier IOS images might fail when using the BulkMIB collector.

•Check the MIB Locator tools to determine if the CISCO-BULK-FILE-MIB and CISCO-FTP-CLIENT-MIB MIBs are supported:

http://www.cisco.com/warp/public/477/nms_tools.shtml

•The Bulk MIB is not supported on Catalyst OS devices.

•SNMP must be configured on the device with the read-write community string set. Check the following web location on how to configure SNMP:

http://www.cisco.com/warp/public/477/SNMP/12.html

•The router does not support SFTP. FTP is used to transfer data from the device to the Cisco PerfE host.

Note that in Cisco PerfE, the dasadmin account is used by the BulkMib collector to FTP data to the Cisco PerfE host. If Cisco PerfE is installed under the /opt directory, FTP fails because the dasadmin user cannot access the /opt directory. As a result, the /etc/ftpaccess file should have the dasadmin user in the access list as follows.
realuser root dasadmin
This enables dasadmin user to access root directories, for example, /opt.

XML Configuration

The following XML tags can be configured for a BulkMib collector:

Table 6-1 Tags in the XML Configuration for the BulkMib Collector

XML Tag

Purpose

Mandatory/ Optional

localFtpServer

ipaddress
username
password

The name or IP address of the local FTP server. The name of the host where Cisco PerfE is running in order for the network device to FTP the file.

The username and password correspond to the user account to FTP files to the Cisco PerfE host.

When not specified, the username and password configured in the das.properties file is used.

Optional

oid

The Object Identifiers (OIDs) specified in the BulkMib collector tag must be the OID of a table.

Mandatory.

Creating a BulkMib Collector Using the GUI

To create a BulkMib collector, follow these steps:

Step 1 Choose Configuration > Collectors > BulkMib Collector.

The BulkMib Collector window appears.

Step 2 Click Create.

The Create BulkMib Collector window appears.

Step 3 Enter the Name. (BulkMibCollect)

Step 4 Choose an existing schedule, then click Select. (BulkMibSchedule)

Step 5 Choose an existing SNMP type device, then click Select. (BulkMibDevice)

Step 6 Choose existing Data Export, then click Select. (BulkMibExport)

Step 7 Choose to enable or disable Save Data in DB. (enable)

Step 8 Click LocalFtpServerInfo.

Step 9 Enter the following information:

•IP Address (10.77.12.94)

•User Name (dasadmin)

•Password (dasadmin)

Step 10 Add Table OIDs. (atTable)

Step 11 Click Apply to create the BulkMib collector.

You should receive a status message indicating success or failure, for example:

Operation: Create

Collector: BulkMibCollect

Result: Successful

Sample XML Configuration
<collector name="BulkMibCollect">
      <BulkMibCollector>
      <schedule name="BulkMibSchedule"/>
      <device name="BulkMibDevice"/>
      <dataHandler name="BulkMibExport"/>
      <localFtpServer>
            <ipaddress>10.77.12.94</ipaddress>
            <username>dasadmin</username>
            <password>dasadmin</password>
      </localFtpServer>
      <oid>atTable</oid>
      </BulkMibCollector>
</collector>
Data Export, Threshold Crossing Alerts, Purging Data, and Hotspot Polling

Refer to the MIB collector sections: "Data Export" section and "Threshold Crossing Alerts, Purging Data, and Hotspot Polling" section.

Limitations

Cisco PerfE does not support retrieval of SNMP OPAQUE data types. Cisco PerfE supports only table transfers in bulk transfer file.

BulkMib Collector Plugins

Mib Collector plugins are also supported in the BulkMib collector configuration. The difference is that the BulkMib collector does not support querying scalar MIB attributes. For example, the sysUpTime attribute, which is used in computation in the Mib collector, cannot be queried using the BulkMib collector. As a result, the collectionTime attribute is used for computations. This is the time interval between two successive polls.

Because the collectionTime attribute is in seconds, when compared to the sysUpTime attribute, which is in hundredths of a second, computation can use the collectionTime value directly. Therefore, there is slight change in the processor components with regard to this.

Templates for different processor components for the BulkMib collector are as follows:

1. Delta plugin:
<das> 
      <create> 
            <processor name="P1"> 
                  <plugin name="das.jar"> 
                        <class>GenericFormula</class> 
                        <parameter name="delta.1">ifInOctets</parameter> 
                        <parameter name="delta.2">collectionTime</parameter> 
                        <parameter name="result.1">deltaIfInOctets delta.1</parameter> 
                        <parameter name="result.2">deltaCollectionTime delta.2</parameter> 
                  </plugin> 
            </processor> 
      </create> 
</das>
2. Percentage In Link Utilization:
<das> 
      <create> 
            <processor name="P1"> 
                  <plugin name="das.jar"> 
                        <class>GenericFormula</class> 
                        <parameter name="delta.1">ifInOctets</parameter> 
                        <parameter name="delta.2">collectionTime</parameter> 
                        <parameter name="var.1">ifSpeed</parameter> 
                        <parameter name="int.1">100</parameter> 
                        <parameter name="int.2">8</parameter> 
                        <parameter name="op.1">divide delta.1 delta.2</parameter> 
                        <parameter name="op.2">multiply op.1 int.2</parameter> 
                        <parameter name="op.3">multiply op.2 int.1</parameter> 
                        <parameter name="op.4">divide op.3 var.1</parameter> 
                        <parameter name="result.1">pctInLinkUtilization op.4</parameter> 
                  </plugin> 
            </processor> 
      </create> 
</das>
3. Percentage Out Link Utilization:
<das> 
      <create> 
            <processor name="P1"> 
                  <plugin name="das.jar"> 
                        <class>GenericFormula</class> 
                        <parameter name="delta.1">ifOutOctets</parameter> 
                        <parameter name="delta.2">collectionTime</parameter> 
                        <parameter name="var.1">ifSpeed</parameter> 
                        <parameter name="int.1">100</parameter> 
                        <parameter name="int.2">8</parameter> 
                        <parameter name="op.1">divide delta.1 delta.2</parameter> 
                        <parameter name="op.2">multiply op.1 int.2</parameter> 
                        <parameter name="op.3">multiply op.2 int.1</parameter> 
                        <parameter name="op.4">divide op.3 var.1</parameter> 
                        <parameter name="result.1">pctOutLinkUtilization op.4</parameter> 
                  </plugin> 
            </processor> 
      </create> 
</das>
4. Percentage In Link Utilization with Configured Bandwidth:
<das> 
      <create> 
            <processor name="P1"> 
                  <plugin name="das.jar"> 
                        <class>GenericFormula</class> 
                        <parameter name="delta.1">ifInOctets</parameter> 
                        <parameter name="delta.2">collectionTime</parameter> 
                        <parameter name="int.1">100</parameter> 
                        <parameter name="int.2">512000</parameter> 
                        <parameter name="op.1">multiply delta.1 int.1</parameter> 
                        <parameter name="op.2">multiply delta.2 int.2</parameter> 
                        <parameter name="op.3">divide op.1 op.2</parameter> 
                        <parameter name="result.1">pctInLinkUtilBW op.3</parameter> 
                  </plugin> 
            </processor> 
      </create> 
</das>
5. Percentage Out Link Utilization with Configured Bandwidth:
<das> 
      <create> 
            <processor name="P1"> 
                  <plugin name="das.jar"> 
                        <class>GenericFormula</class> 
                        <parameter name="delta.1">ifOutOctets</parameter> 
                        <parameter name="delta.2">collectionTime</parameter> 
                        <parameter name="int.1">100</parameter> 
                        <parameter name="int.2">512000</parameter> 
                        <parameter name="op.1">multiply delta.1 int.1</parameter> 
                        <parameter name="op.2">multiply delta.2 int.2</parameter> 
                        <parameter name="op.3">divide op.1 op.2</parameter> 
                        <parameter name="result.1">pctOutLinkUtilBW op.3</parameter> 
                  </plugin> 
            </processor> 
      </create> 
</das>
6. AAA Server plugin:
<das> 
      <load> 
            <mib name="CISCO-AAA-SERVER-MIB.my"/> 
      </load> 
      <create> 
            <processor name="P1"> 
                  <plugin name="das.jar"> 
                        <class>GenericFormula</class> 
                        <parameter name="delta.1">casAuthenTransactionFailures</parameter> 
                        <parameter 
name="delta.2">casAuthenTransactionSuccesses</parameter>
                        <parameter name="int.1">100</parameter> 
                        <parameter name="op.1">multiply delta.1 int.1</parameter> 
                        <parameter name="op.2">plus delta.1 delta.2</parameter> 
                        <parameter name="op.3">divide op.1 op.2</parameter> 
                        <parameter name="result.1">pctCasAuthenFailuresBW op.3</parameter> 
                  </plugin> 
            </processor> 
      </create> 
</das>
Sample Configuration
<das> 
      <create> 
            <schedule name="BulkMibSchedule"> 
                  <start>2002-03-06T00:00:00.000-08:00</start> 
                  <interval>PT2M</interval> 
                  <interTaskDelay>PT0.1S</interTaskDelay> 
            </schedule> 
            <device name="BulkMibDevice"> 
                  <snmp> 
                        <ipaddress>10.77.11.70</ipaddress> 
                        <readCommunity>public</readCommunity> 
                        <writeCommunity>private</writeCommunity> 
                  </snmp> 
            </device> 
            <dataHandler name="BulkMibExport"> 
                  <url> 
                        <prefix>ftp://mramacha:cisco123@10.77.11.94/%2Fdata/MibPlugin</pre
fix> 
                  </url> 
            </dataHandler> 
            <collector name="BulkMibCollect"> 
                  <BulkMibCollector> 
                        <processor name="P1"/> 
                        <schedule name="BulkMibSchedule"/> 
                        <device name="BulkMibDevice"/> 
                        <dataHandler name="BulkMibExport"/> 
                        <oid>ifTable</oid> 
                  </BulkMibCollector> 
            </collector> 
      </create> 
      <start> 
            <collector name="BulkMibCollect"/> 
      </start> 
</das>
ByteCap Data Collector

The ByteCap Data collector provides information about the amount of data traffic to and from a cable modem. This information can be used to identify usage characteristics of a subscriber along with potential abusers of the terms of service (for example, upstream data transfers identify a large upstream traffic transfer which might indicate the subscriber is running servers).

The ByteCap Data collector collects this information from the CMTS using SNMP and the data can be transferred through framework hotspot and periodic polling.

Requirements

The ByteCap Data collector requires the framework definition of the CMTS as a device, as described below.

XML Configuration

The following is a sample XML configuration for the BDC (schedule, device and data handlers must be defined prior to the collector). The database must contain an entry for uBR01.

Define the device to the framework as an SNMPv3 capable device:
              <device name="ubr1">            
                <snmp>                
                  <ipaddress>10.5.1.2</ipaddress>                
                  <readCommunity>public1</readCommunity>                
                  <timeout>PT5S</timeout>                
                  <retry>4</retry>                
                  <version>SNMPv3</version>                
                  <port>161</port>                
                  <userName>HORSHAM</userName>                
                  <authProtocol>MD5</authProtocol>                
                  <authPassword>HORSHAM1</authPassword>            
                </snmp>        
              </device>
Algorithms exist in the ByteCap collector that allow the higher level system to identify three tiered summaries of data:

•daily

•weekly

•monthly.

These are purely ASCII mnemonics for ease of use. The algorithms defined are:

•MonthlySummary= SUM(numberOfPeriods) = # of weekly summaries in a month

•WeeklySummary= SUM(numberOfUnits) = # of daily summaries in a week

•DailySummary= SUM(interval) = # hours in a day.

As an example:
Bytecap collector is set to run every 4 hours
Set Daily "numberOfCollections" = 6 ( * 4 hours = 24hours)
Set Weekly "numberOfUnits" = 7 ( * 24 hours = 7 days)
Set Monthly "numberOfPeriods" = 4 ( * 7 days = 28 days)
For each interval expiration, the data is exported to a specified location.

Raw data collected is automatically purged when numberOfCollections has expired and only the last numberOfCollections worth of raw data is maintained.

Daily summaries are automatically purged and only the last numberOfUnits are stored. The purge method of weekly summaries is automatic after monthly has fired. The purge method of monthly summaries is under the control of the framework purge.

Example XML
<?xml version="1.0" encoding="UTF-8"?>
<das>
    <create>
     <notifier name="CNSnotifier_bytecap">
        <cns>
            <subject>cns.cisco.das.listener_bytecap</subject>
        </cns>
      </notifier>
      <dataHandler name="hotspot_bytecap">
        <cns>
          <subject>cns.cisco.das.listener_bytecap</subject>
        </cns>
      </dataHandler>
     <purger name="purge_bytecap">
	     <time>2002-10-23T15:00:00.000-05:00</time>
         <interval>PT1440H</interval>
         <delay>PT720H</delay>
      </purger>
      <collector name="bytecap1">
        <DocsisByteCapCollector>
         <schedule name="sch4hr"/>
         <device name="ubr1"/>
         <device name="ubr2"/>   
		 <notifier name="CNSnotifier_bytecap"/> 
         <dataHandler name="hotspot_bytecap"/>
         <purger name="purge_bytecap"/>
         <byteCapSummary>
		    <dataHandler name="hotspot_bytecap"/>
		    <numberOfPeriods>4</numberOfPeriods>
		    <period>
		       <dataHandler name="hotspot_bytecap"/>
		       <numberOfUnits>7</numberOfUnits>
		       <unit>
		          <dataHandler name="hotspot_bytecap"/>
			      <numberOfCollections>6</numberOfCollections>
		       </unit>
			</period>
		 </byteCapSummary> 
  		</DocsisByteCapCollector>
	  </collector>
      </create>
	<add/>
	<start>
	   <collector name="bytecap1"/>
        </start>
</das>
Hotspot and Periodic Exported Data
<BYTECAP>
cmtsip|macaddress|lastcollectedtime|totalinoctets|totaloutoctets
10.87.117.2|00:02:16:d5:a4:0d|2003-03-21 09:01:54.356|2119769|1315060
10.87.117.2|00:04:27:a5:c0:45|2003-03-21 09:01:54.326|2242028|1385945
10.87.117.2|00:04:27:a5:c0:81|2003-03-21 09:01:54.34|2189981|1314685
10.87.117.2|08:00:3e:08:ef:4c|2003-03-21 09:01:54.376|1897436|1436540
10.87.117.2|00:08:0e:16:fb:be|2003-03-21 09:01:54.363|2689849|0
10.87.117.2|00:04:bd:b7:81:ca|2003-03-21 09:01:54.393|2689908|0
10.87.117.2|00:02:16:d5:a4:27|2003-03-21 09:01:54.323|2367606|1314639
</BYTECAP>
Summary Exported Data

The following are snippets of the data available through Hotspot or Periodic, based upon the defined summarization:

Daily:
<BYTECAP title="daily">
cmtsip|macaddress|lastcollectedtime|totalinoctets|totaloutoctets
10.87.117.2|00:04:27:a5:c0:81|2003-03-21 09:01:54.34|2189981|1314685
10.87.117.2|00:02:16:d5:a4:27|2003-03-21 09:01:54.323|2367606|1314639
10.87.117.2|08:00:3e:08:ef:4c|2003-03-21 09:01:54.376|1897436|1436540
10.87.117.2|00:02:16:d5:a4:0d|2003-03-21 09:01:54.356|2119769|1315060
10.87.117.2|00:08:0e:16:fb:be|2003-03-21 09:01:54.363|2689849|0
10.87.117.2|00:04:27:a5:c0:45|2003-03-21 09:01:54.326|2242028|1385945
10.87.117.2|00:04:bd:b7:81:ca|2003-03-21 09:01:54.393|2689908|0
</BYTECAP>
Weekly:
<BYTECAP title="weekly">
cmtsip|macaddress|lastcollectedtime|totalinoctets|totaloutoctets
10.87.117.2|00:02:16:d5:a4:0d|2003-03-21 09:01:54.356|2119769|1315060
10.87.117.2|00:08:0e:16:fb:be|2003-03-21 09:01:54.363|2689849|0
10.87.117.2|00:04:27:a5:c0:45|2003-03-21 09:01:54.326|2242028|1385945
10.87.117.2|00:04:bd:b7:81:ca|2003-03-21 09:01:54.393|2689908|0
10.87.117.2|00:04:27:a5:c0:81|2003-03-21 09:01:54.34|2189981|1314685
10.87.117.2|00:02:16:d5:a4:27|2003-03-21 09:01:54.323|2367606|1314639
10.87.117.2|08:00:3e:08:ef:4c|2003-03-21 09:01:54.376|1897436|1436540
</BYTECAP>
Monthly:
<BYTECAP title="monthly">
cmtsip|macaddress|lastcollectedtime|totalinoctets|totaloutoctets
10.87.117.2|00:04:27:a5:c0:45|2003-03-21 09:01:54.326|2242028|1385945
10.87.117.2|08:00:3e:08:ef:4c|2003-03-21 09:01:54.376|1897436|1436540
10.87.117.2|00:04:bd:b7:81:ca|2003-03-21 09:01:54.393|2689908|0
10.87.117.2|00:02:16:d5:a4:0d|2003-03-21 09:01:54.356|2119769|1315060
10.87.117.2|00:04:27:a5:c0:81|2003-03-21 09:01:54.34|2189981|1314685
10.87.117.2|00:08:0e:16:fb:be|2003-03-21 09:01:54.363|2689849|0
10.87.117.2|00:02:16:d5:a4:27|2003-03-21 09:01:54.323|2367606|1314639
</BYTECAP>
The interval of data in the historical storage for monthly is available through XML:

Note The <start> and <end> tags and data are ignored for the collection interval query.
<get>
	 <data>
	   <collector name="bytecap1"/>
	   <device name="ubr1"/>
	   <start>2002-06-27T12:30:00.000-08:00</start>
       <end>2003-08-27T13:30:00.000-08:00</end>
       <url>ftp://guest:guest@161.44.33.23/%2F/home/guest/das/data1/bytecap.txt</url>
	 </data>
	</get>
The stored historical information can be retrieved on demand by higher level applications.

Monthly Data:
<das>
    <get>
	 <data>
	   <collector name="bytecap1"/>
	   <device name="ubr1"/>
	   <start>2002-06-27T12:30:00.000-08:00</start>
       <end>2003-08-27T13:30:00.000-08:00</end>
       
<url>ftp://guest:guest@161.44.33.23/%2F/home/guest/das/data1/bytecap-monthly.txt</url>
	   <parameter name="docsisQueryType">
            docsis-bytecap-monthly
       </parameter>
	 </data>
	</get>
Weekly data.
	<get>
	 <data>
	   <collector name="bytecap1"/>
	   <device name="ubr1"/>
	   <start>2002-06-27T12:30:00.000-08:00</start>
       <end>2003-08-27T13:30:00.000-08:00</end>
       
<url>ftp://guest:guest@161.44.33.23/%2F/home/guest/das/data1/bytecap-weekly.txt</url>
	   <parameter name="docsisQueryType">
            docsis-bytecap-weekly
       </parameter>
	 </data>
	</get>
Daily data.
    <get>
	 <data>
	   <collector name="bytecap1"/>
	   <device name="ubr1"/>
	   <start>2002-06-27T12:30:00.000-08:00</start>
       <end>2003-08-27T13:30:00.000-08:00</end>
       
<url>ftp://guest:guest@161.44.33.23/%2F/home/guest/das/data1/bytecap-daily.txt</url>
	   <parameter name="docsisQueryType">
            docsis-bytecap-daily
       </parameter>
	 </data>
	</get>
CallMgrCdr Collector

The Cisco Call Manager provides voice call information data in two forms. It generates Call Detail Records (CDRs) for each call placed to and from IP phones, conference bridges, and off-net PSTN gateways. In addition, it generates the Call Management Record (CMR) associated with each CDR record. The CDRs and corresponding CMR records provide voice quality statistics. The CMR records contain the count of bytes sent, packets sent, jitter and latency, and dropped packets.

The CMR records are normally generated for each call when a call involves an IP phone as an endpoint. If both endpoints are IP phones, two CMR records are generated, one for each phone.

The Cisco CallMgrCdr collector provides the following features:

•An XML interface to configure the collector from a local/remote host

•Hourly and daily summary reports

•Periodic and on-demand export of Summary and CDR reports

•Thresholds supported on hourly and daily reports

•Different purge levels for different reports

•Support of multiple Call Manager CDR collectors.

With Cisco CNS PerfE 2.1.4, the CallMgrCdr collector has been enhanced to access data from the Cisco Call Manager system using a secure mode through the SSH/SFTP (Secure Shell/Secure FTP) approach. With this approach, the CallMgrCdr collector connects to the Cisco Call Manager system using SSH and executes an isql command to retrieve the CDR/CMR records from the database. These records are then retrieved at the Cisco CNS PerfE host from the Cisco Call Manager host using SFTP.

During secure collection, the Cisco Call Manager Collector internally uses the isql command to export data out of Cisco Call Manager. By default, this exported data is in CSV format. If the data fields contain a comma (,) the data will not be correctly parsed. You must change the delimiter property in the das.properties file to any appropriate delimiter:

callmgr.secure.delimiter=, delimiter used to separate data fields in data exported from Cisco Call Manager

Refer to "das.properties Properties File" section for more information.

Cisco Call Manager Setup Requirements

The following parameters should be enabled on the Cisco Call Manager system in order for the CallMgrCdr collector to collect the CDRs and CMRs from the Cisco Call Manager's database. Make sure these parameters are enabled:

•CdrEnabled—enables/disables CDR records

•CallDiagnosticsEnabled—enables/disables CMR records

•Microsoft's SQL JDBC drive (required if JDBC mode of collection is used)

Note The JDBC driver is not shipped with the product. You must download the driver from Microsoft's website. Please refer to the Installation Guide for more information on how to download and install the JDBC driver.

•SSH/SFTP sertver software running on the Call Manager system

•A user must be created on the Cisco Call Manager host. The username details are used during the device creation in Cisco CNS PerfE. The CDR/CMR files are placed in the specified user's home directory on the Cisco Call Manager host machine.

Note Cisco Call Manager 3.3.2 does not certify SSH server software. The CallMgrCdr collector has been tested with TectiaServer-A-4.2.0.21. This software is available at http://www.ssh.com. If you intend on using the CallMgrCdr collector in SSH/SFTP mode, you must install this server software on the Cisco Call Manager host machine before configuring the CallMgrCdr collector.

CallMgrCdr Collector Setup

The CallMgrCdr collector retrieves the data from the Cisco Call Manager CDR database. The collector must wait for the Call Manager to populate the CDRs into the CDR database after the voice call has completed. As a result, the interval delay settings for CDR and CMR collection are specified by the following parameters:

The CDR collection range is determined as follows:

starttime = currenttime - collectionOffset - collectionScheduleInterval

endtime = currenttime + collectionScheduleInterval

The <collectMode> tag options are:

•CDR—collect only CDRs

•CDRPlusCMR—collect CDRs plus CMRs.

Configuring CallMgrCdr Using the GUI

This section contains the following sections:

•Creating a Schedule

•Creating a Device

•Creating Data Export1

•Creating a Data Export2

•Creating Data Export3

•Creating an Event Notification

•Creating a Threshold

•Creating a CallMgrCdr Collector.

Creating a Schedule

To create a schedule, follow these steps:

Step 1 Choose Configuration > Common Components > Schedule.

The Schedule window appears.

Step 2 Click Create.

The Create Schedule window appears.

Step 3 Enter the following information:

•Name (S1)

•Start Time (2003-01-01T00:00:00.000-08:00)

•Interval (PT15M).

Step 4 Click Apply to create the Schedule.

You should receive a status message indicating success or failure, for example:

Operation: Create

Schedule: S1

Result: Successful.

Creating a Device

To create a device, follow these steps:

Step 1 Choose Configuration > Common Components > Device.

The Device window appears.

Step 2 Click Create.

The Create Device window appears.

Step 3 Enter the Name. (CCMDev)

Step 4 Click JDBC.

Step 5 Enter the URL. (jdbc:microsoft:sqlserver://10.0.0.1:1433;Databasename=CDR;USER=CiscoCCMCDR;PASSWORD=dipsy)

Step 6 Click Apply to create the device.

You should receive a status message indicating success or failure, for example:

Operation: Create

Device: CCMDev

Result: Successful.

Creating a Device for a Secure Mode of Collection

To create a device for secure (SSH/SFTP) mode of collection, follow these steps:

Step 1 Choose Configuration > Common Components > Device.

The Device window appears.

Step 2 Click Create.

The Create Device window appears.

Step 3 Enter the Name. (CCMDev)

Step 4 Click CCM.

Step 5 Enter the Cisco Call Manager host and database details to access the data:

IP Address—the Cisco Call Manager host IP address

UserName—user name for the Cisco Call Manager host

Password—password for the above specified user

Prompt—prompt that appears when the above specified user logs in

Timeout—time out value for the login session

DBname—Cisco Call Manager database name

DBUserName—Cisco Call Manager database user name

DBPassword—password for the above specified database user name.

Step 6 Click Apply to create the device.

You should receive a status message indicating success or failure, for example:

Operation: Create

Device: CCMDev

Result: Successful.

Creating Data Export1

To create a data export, follow these steps:

Step 1 Choose Configuration > Common Components > DataExport.

The DataExport window appears.

Step 2 Click Create.

The Create DataExport window appears.

Step 3 Enter the Name. (cdrDH)

Step 4 Choose a Type. (URL)

Step 5 Enter the URL Prefix. (file:///export/data/callmgr/cdr_)

Step 6 Click Apply to create the data export.

You should receive a status message indicating success or failure, for example:

Operation: Create

DataExport: cdrDH

Result: Successful.

Creating a Data Export2

To create a second data export, follow these steps:

Step 1 Choose Configuration > Common Components > DataExport.

The DataExport window appears.

Step 2 Click Create.

The Create DataExport window appears.

Step 3 Enter the Name. (hourlySummaryDH)

Step 4 Choose a Type. (URL)

Step 5 Enter the URL Prefix. (file:///export/data/callmgr/hourly_)

Step 6 Click Apply to create the second data export.

You should receive a status message indicating success or failure, for example:

Operation: Create

DataExport: hourlySummaryDH

Result: Successful.

Creating Data Export3

To create a third data export, follow these steps:

Step 1 Choose Configuration > Common Components > DataExport.

The DataExport window appears.

Step 2 Click Create.

The Create DataExport window appears.

Step 3 Enter the Name. (dailySummaryDH)

Step 4 Choose a Type. (URL)

Step 5 Enter the URL Prefix. (file:///export/data/callmgr/daily_)

Step 6 Click Apply to create the third data export.

You should receive a status message indicating success or failure, for example:

Operation: Create

DataExport: dailySummaryDH

Result: Successful.

Creating an Event Notification

To create an event notification, follow these steps:

Step 1 Choose Configuration > Common Components > Event Notification.

The Event Notification window appears.

Step 2 Click Create.

The Create Event Notification window appears.

Step 3 Enter the Name. (callmgrNotifier)

Step 4 Choose a Type. (CNS)

Step 5 Enter the CNS Subject. (cns.cisco.das.listener)

Step 6 Click Apply to create the event notification.

You should receive a status message indicating success or failure, for example:

Operation: Create

Event Notification: callmgrNotifier

Result: Successful.

Creating a Threshold

To create a threshold, follow these steps:

Step 1 Choose Configuration > Common Components > Threshold.

The Threshold window appears.

Step 2 Click Create.

The Create Threshold window appears.

Step 3 Enter the Name. (HourlyThresholds)

Step 4 Choose a Collector Type. (CallMgrCdrCollector)

Step 5 Enter an Attribute Name. (HourlySummary.avgJitter)

Step 6 Choose a Raise Operation. (For example: EQ)

Step 7 Enter a Raise Value. (For example: 8)

Step 8 Choose a Clear Operation. (For example: GT)

Step 9 Enter a Clear Value. (For example: 4)

Step 10 Choose a Level. (For example: minor)

Step 11 Click Add.

Step 12 Click Apply to create the threshold.

You should receive a status message indicating success or failure, for example:

Operation: Create

Threshold: CallMgrCdrCollector>/HourlyThresholds

Result: Successful.

Creating a CallMgrCdr Collector

To create a CallMgrCdr collector, follow these steps:

Step 1 Choose Configuration > Collectors > CallMgrCdr Collector.

The CallMgrCdr Collector window appears.

Step 2 Click Create.

The Create CallMgrCdr Collector window appears.

Step 3 Enter the Name. (CCM01)

Step 4 Choose an existing schedule and click Select. (S1)

Step 5 Choose an existing Device and click Select. (CCMDev).

Step 6 Choose existing Data Export1, create, and associate parameter CDRPlusCMR with Data Export1and click Select. (cdrDH)

Step 7 Choose existing Data Export2, create, and associate parameter HourlySummary with Data Export2and click Select. (hourlySummaryDH)

Step 8 Choose existing Data Export3, create, and associate parameter DailySummary with Data Export3 and click Select. (dailySummaryDH)

Step 9 Choose an existing Threshold and click Select. (CallMgrCdr/HourlyThresholds)

Step 10 Choose an existing Event Notification and click Select. (callmgrNotifier)

Step 11 Choose to enable or disable Save Data in DB. (enable)

Step 12 Enter the following information:

•Collect Mode (CDRPlusCMR)

•Collection Offset (PT15M)

•Hourly Report (enabled)

•Daily Report (enabled)

•CDR Report Purge Level (PT24H)

•Hourly Report Purge Level (PT168H)

•Daily Report Purge Level (PT336H)

Step 13 Click Apply to create the CallMgrCdr collector.

You should receive a status message indicating success or failure, for example:

Operation: Create

Collector: CCM01

Result: Successful

XML Configuration with JDBC Mode
<das>
             <load/>
             <create>
                 <schedule name="S1">
                     <start>2003-01-01T00:00:00.000-08:00</start>
                     <interval>PT15M</interval>
                  </schedule>
                 <device name="CCMDev">
                     <jdbc>
                <url 
name="dbCDR">jdbc:microsoft:sqlserver://10.0.0.1:1433;Databasename=CDR;USER=CiscoCCMCDR;PA
SSWORD=dipsy</url>
                     </jdbc>
                 </device>
                 <dataHandler name="cdrDH">
                     <url>
                         <prefix>file:///export/data/callmgr/cdr_</prefix>
                     </url>
                 </dataHandler>
                 <dataHandler name="hourlySummaryDH">
                     <url>
                         <prefix>file:///export/data/callmgr/hourly_</prefix>
                     </url>
                 </dataHandler>
                 <dataHandler name="dailySummaryDH">
                     <url>
                         <prefix>file:///export/data/callmgr/daily_</prefix>
                     </url>
                 </dataHandler>
                 <notifier name="callmgrNotifier">
                     <cns>
                         <subject>cns.cisco.das.listener</subject>
                     </cns>
                 </notifier>
                 <threshold name="HourlyThresholds">
                     <attribute name="HourlySummary.avgJitter">
                         <raiseOperation>EQ</raiseOperation>
                         <raiseValue>8</raiseValue>
                         <clearOperation>GT</clearOperation>
                         <clearValue>4</clearValue>
                         <level>minor</level>
                     </attribute>
                 </threshold>
                 <collector name="CCM01">
                     <CallMgrCdrCollector>
                         <schedule name="S1"/>
                         <device name="CCMDev"/>
                         <threshold name="HourlyThresholds"/>
                         <notifier name="callmgrNotifier"/>
                         <dataHandler name="cdrDH">
                             <parameter name="report">CDRPlusCMR</parameter>
                         </dataHandler>
                         <dataHandler name="hourlySummaryDH">
                             <parameter name="report">HourlySummary</parameter>
                         </dataHandler>
                         <dataHandler name="dailySummaryDH">
                             <parameter name="report">DailySummary</parameter>
                         </dataHandler>
                         <collectMode>CDRPlusCMR</collectMode>
						<collectionOffset>PT15M</collectionOffset>
       						<hourlyReport>enabled</hourlyReport>
        						<dailyReport>enabled</dailyReport>
        						<cdrReportPurgeLevel>PT24H</cdrReportPurgeLevel>
						<hourlyReportPurgeLevel>PT168H</hourlyReportPurgeLevel>
        						<dailyReportPurgeLevel>PT336H</dailyReportPurgeLevel>
                     </CallMgrCdrCollector>
                 </collector>
             </create>
             <add/>
             <stop/>
             <start>
                 <collector name="CCM01"/>
             </start>
         </das>
XML Configuration with SSH/SFTP Mode
<das>
             <create>
                 <schedule name="S1">
                     <start>2003-01-01T00:00:00.000-08:00</start>
                     <interval>PT15M</interval>
                  </schedule>
                 <device name="CCMDev">
                     <ccm>
                        <ipaddress>CallMgr Host IP Address</ipaddress>
                        <username>callmgr host username</username>
                        <password>password for above user</password>
                        <prompt>C:\></prompt>
                        <dbname>CDR</dbname>
                        <dbusername>CiscoCCMCDR</dbusername>
                        <dbpassword> db password</dbpassword>
                     </ccm>
                 </device>
                 <dataHandler name="cdrDH">
                     <url>
                         <prefix>file:///export/data/callmgr/cdr_</prefix>
                     </url>
                 </dataHandler>
                 <dataHandler name="hourlySummaryDH">
                     <url>
                         <prefix>file:///export/data/callmgr/hourly_</prefix>
                     </url>
                 </dataHandler>
                 <dataHandler name="dailySummaryDH">
                     <url>
                         <prefix>file:///export/data/callmgr/daily_</prefix>
                     </url>
                 </dataHandler>
                 <notifier name="callmgrNotifier">
                     <cns>
                         <subject>cns.cisco.das.listener</subject>
                     </cns>
                 </notifier>
                 <threshold name="HourlyThresholds">
                     <attribute name="HourlySummary.avgJitter">
                         <raiseOperation>EQ</raiseOperation>
                         <raiseValue>8</raiseValue>
                         <clearOperation>GT</clearOperation>
                         <clearValue>4</clearValue>
                         <level>minor</level>
                     </attribute>
                 </threshold>
                 <collector name="CCM01">
                     <CallMgrCdrCollector>
                         <schedule name="S1"/>
                         <device name="CCMDev"/>
                         <threshold name="HourlyThresholds"/>
                         <notifier name="callmgrNotifier"/>
                         <dataHandler name="cdrDH">
                             <parameter name="report">CDRPlusCMR</parameter>
                         </dataHandler>
                         <dataHandler name="hourlySummaryDH">
                             <parameter name="report">HourlySummary</parameter>
                         </dataHandler>
                         <dataHandler name="dailySummaryDH">
                             <parameter name="report">DailySummary</parameter>
                         </dataHandler>
                         <collectMode>CDRPlusCMR</collectMode>
						<collectionOffset>PT15M</collectionOffset>
       						<hourlyReport>enabled</hourlyReport>
        						<dailyReport>enabled</dailyReport>
        						<cdrReportPurgeLevel>PT24H</cdrReportPurgeLevel>
						<hourlyReportPurgeLevel>PT168H</hourlyReportPurgeLevel>
        						<dailyReportPurgeLevel>PT336H</dailyReportPurgeLevel>
                     </CallMgrCdrCollector>
                 </collector>
             </create>
             <add/>
             <stop/>
             <start>
                 <collector name="CCM01"/>
             </start>
         </das>
Data Export

The CallMgrCdr collector exports CDRs and Summary reports (hourly and daily). The report parameter configured with the data handler controls the data export functionality. Each data handler supports one type of data export report. The parameter tag in the data handler determines the type of report to be exported. The same data handler can not be used to export different kinds of reports in a given CallMgrCdr collector.

In the case of CallMgr Secure Collector, the default time out for device type CCM is PT20S but this is sometimes insufficient in certain conditions where CallMgrCDR Collector has a large number of records to be collected from the CallManager database.

In such cases, the timeout parameter of the CCM device has to be increased to a suitable value till Cisco PerfE is able to collect all the records present in the CallManager Database.When there is such a timeout issue, error messages are printed in <DAS_HOME>/logs/das.log indicating that there might be timeout issues.

The CallMgrCdr collector supports the following reports:

•CDR: <parameter name="report">CDR</parameter>

•CDR: Plus CMR <parameter name="report">CDRPlusCMR</parameter>

•Hourly Summary: <parameter name="report">HourlySummary</parameter>

•Daily Summary: <parameter name="report">DailySummary</parameter>

The following section describes the contents of the various data export reports.

CDR Report Format
<report name="cdr" version="1">
   <collector name="callmgrCdrCollector"/>
   <device name="callmgrDev">
      <call callId="xxx" callManagerId="xxx" clusterId="xxx">
         <cdr callId="xxx" callManagerId="xxx" clusterId="xxx">
             this tag depends on the configured Saa Collector. Appropri

ate tag should be provided.

<device name="dev">

<operation name="op2">

<targetAddress>172.29.146.104</targetAddress>

<targetPort>8976</targetPort>

</operation>

</device>

</SaaJitterCollector>

</collector>

</add>

</das>

Remove Operation

<das>

<remove>

<collector name="c">

<SaaJitterCollector>

<device name="dev">

<operation name="op2"/>

</device>

</SaaJitterCollector>

</collector>

</remove>

</das>

SAA Collectors in Cisco PerfE

Three SAA collectors are available with Cisco PerfE:

•SAAIcmpEcho Collector

•SAAJitter Collector

•SAAUdpEcho Collector

For all SAA collectors, refer to documentation on the SAA Agent:

•Configuration Guide- /en/US/docs/ios/12_2/configfun/configuration/guide/fcf017.html

•Command Reference-
/en/US/docs/ios/12_2/configfun/command/reference/frf017.html

•Product Feature Guide-
http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00801d3a94.html#1060419

Configuration of the SAA Operation

If the SAA <operation> tag is not used, a default operation is created for backward compatibility. Configuring the <operation> tag is the preferred method.

Parameters configured outside the <operation> tag are used as default parameters for the operation. Therefore, if a parameter is missing within the <operation> tag, it looks for the parameter outside the tag.

If an Index is Provided:

Before the collector is started, the operation with the index must be configured and running on the router and the rtr responder, if required, must also be configured.

Other parameters specified in the XML are ignored.

If an Index is not Provided:

Before the collector is started, the rtr responder must be configured for the SaaJitter or SaaUdpEcho collectors.

Parameters specified in the XML are used by Cisco PerfE to automatically create the operation on the source router.

SAAIcmpEcho Collector

The SAAIcmpEcho collector measures the round trip time for Internet Control Message Protocol (ICMP) between source and destination devices.

Requirements

None.

XML Configuration

Table 6-11 describes the attributes you can set for the SAAIcmpEcho collector.

Table 6-11 Tags in the XML Configuration for the SAAIcmpEcho Collector

XML Tag

Descriptions

Mandatory/
Optional

index

The index to an existing operation already created on the router.

Optional

packetSize

The payload size of the ICMP ping packet. The default value is 64.

Optional

targetAddress

The IP address of the device upon which the SAA operation occurs. The default target address is the one specified outside the <operation> tag.

Mandatory

timeout

The amount of time to wait for a response to the operation. The default value is five seconds.

Optional

VrfName

The VRF name the SAA operation should use.

Optional

Creating an SaaIcmpEcho Collector with the GUI

To create an SAAIcmpEcho collector with the GUI, follow these steps:

Step 1 Choose Configuration > Collectors > SaaIcmpEcho Collector.

The SAAIcmpEcho Collector window appears.

Step 2 Click Create.

The Create SAAIcmpEcho Collector window appears.

Step 3 Enter the Name. (SAAicmp1)

Step 4 Choose an existing schedule and click Select. (S1).

Step 5 Choose an existing device and click Select. (dev1).

Step 6 Enter the following information

•Target Address (10.0.0.1)

• Timeout (Default is 5 seconds)

• Packet Size (The default value is 64)

• Vrf Name (op1)

Step 7 Click Apply to create the SAAIcmpEcho Collector.

You should receive a status message indicating success or failure, for example:

Operation : Create

Collector : SAAicmp1

Result : Successful

Sample XML Configuration
<collector name="SAAicmp1">
      <SaaIcmpEchoCollector>
            <schedule name="S1"/>
            <device name="dev1">
                  <operation name="op1">
                        <targetAddress>10.0.0.1</targetAddress>
                  </operation>
                  <operation name="op2">
                        <targetAddress>10.0.0.2</targetAddress>
                  </operation>
            </device>
            <dataHandler name="dh1"/>
      </SaaIcmpEchoCollector>
</collector>
Data Export

The SaaIcmpEcho collector retrieves measurements about the IcmpEcho operation and stores the data in the database. It exports data in CSV format. Data can be exported at a specified frequency or on-demand using the XML interface (using the <get> <data> tags). The first line of each data file contains the column headings separated by commas. Each subsequent line contains the following information:

Table 6-12 Order of the Data Exported by the SaaIcmpEcho Collector

Order

Parameter

1.

Collector name.

2.

Device name.

3.

Data collection timestamp.

4.

rttMonLatestRttOperCompletionTime

5.

rttMonLatestRttOperSense

6.

rttMonLatestRttOperApplSpecificSense

7.

ttMonLatestRttOperSenseDescription

8.

rttMonLatestRttOperTime

Threshold Crossing Alerts, Purging Data, and Hotspot Polling

The SaaIcmpEcho collector supports threshold crossing/clearing alerts (TCAs). TCAs can be configured only for the rttMonLatestRttOperCompletionTime attribute. The SaaIcmpEcho collector checks for TCAs after each data collection.

The SaaIcmpEcho collector supports purging of collected performance data. This is done on a schedule configured for Cisco PerfE or you can configure a purger just for this collector.

The SaaIcmpEcho collector also supports hotspot polling. If the collector is configured for hotspot polling, Cisco PerfE does not store the data internally and does not post-process the data after collection. As soon as the data is retrieved, the data is written to the CNS Integration bus based on the configuration.

Limitations

None.

SAAJitter Collector

The SAAJitter collector measures the round trip time and jitter between source and destination devices. Unlike other SAA collectors, SAAJitter requires two iterations of measurements because the jitter measurement requires data from two measurements. Therefore, the first measurement would not contain jitter values.

Requirements

A value for rtr responder must be configured on the target router.

This collector only works with Cisco devices that support the Service Assurance Agent.

The SaaJitter collector was enhanced in Cisco CNS PerfE, 2.1, to support collection of voice quality measurements (rttMonLatestJitterOperMOS and rttMonLatestOperCPIF). To support the collection of these attributes, CODEC types and its associated parameters must be specified for the operation. The following codecType values are supported:

•g711ulaw

•g711alaw

•g729a.

XML Configuration

Table 6-13 describes the attributes you can set for the SAAJitterEcho collector.

Table 6-13 Tags in the XML Configuration for the SAAJitter Collector

XML Tag

Purpose

Mandatory/
Optional

codecNumPkts :

Number of packets to be transmitted <1-60000>

Optional

codecInterval

Inter packet interval <1-60000>

Optional

codecPacketSize

Number of bytes in the payload <16-1500>

Optional

Advantage factor
< 0-20> :

Optional

control

Sends a control message to the rtr responder before the operation. The default is enabled.

Optional

index

The index to an existing operation already created on the router.

Optional

interval

The delay, in milliseconds, between each packet for an operation. The default is 20.

Optional

numOfPackets

The number of packets to send out for an operation. The default is 10.

Optional

packetSize

The payload size of the UDP packet. The default is 64.

Optional

sourcePort

The source UDP port to use. The default is 0 which means the router will select a random port.

Optional

targetAddress

The IP address of the device upon which the SAA operation occurs. The default target address is the one specified outside the <operation> tag

Mandatory

targetPort

The destination UDP port to use. The default target port is the one specified outside the <operation> tag

Mandatory

timeout

The amount of time to wait for a response to the operation.

Optional

tos

The Type of Service (TOS) field of the IP packet. The default is 0.

Optional

VrfName

The vrfName the SAA operation should use.

Optional

Creating an SaaJitter Collector with the GUI

To create an SaaJitter collector with the GUI, follow these steps:

Step 1 Choose Configuration > Collectors > SaaJitter Collector.

The SaaJitter Collector window appears.

Step 2 Click Create.

The Create SaaJitter Collector window appears.

Step 3 Enter the Name. (SAAjitter)

Step 4 Choose an existing schedule and click Select. (S1).

Step 5 Choose an existing device and click Select. (dev1).

Step 6 Enter the following information

•Target Address (10.0.9.100)

• Target Port (101)

• Source Port (100)

• Timeout (PT4S)

• Packet Size (256)

• Num. Of Packets (15)

• interval (10)

• Tos (0)

•Control (enable)

• Vrf Name (op1)

Step 7 Click Apply to create the SAAjitter Collector.

You should receive a status message indicating success or failure, for example:

Operation : Create

Collector : SaaJitter

Result : Successful

Sample XML Configuration:
<collector name="SAAjitter"> 
<SaaJitterCollector> 
<schedule name="S1"/> 
<device name="dev1"> 
<operation name="op1"> 
<targetAddress>10.0.9.100</targetAddress> 
<targetPort>101</targetPort> 
</operation> 
<operation name="op2"> 
<targetAddress>10.0.9.100</targetAddress> 
<targetPort>101</targetPort> 
<sourcePort>100</sourcePort> 
</operation> 
</device> 
<timeout>PT4S</timeout> 
<packetSize>256</packetSize> 
<numOfPackets>15</numOfPackets> 
<interval>10</interval> 
<tos>0</tos> 
<control>enable</control> 
</SaaJitterCollector> 
</collector> 
Creating an SaaJitter Collector for CODEC Data Collection

To create an SaaJitter collector for CODEC data collection, follow these steps:

Step 1 Choose Configuration > Collectors > SaaJitter Collector.

The SaaJitter Collector window appears.

Step 2 Click Create.

The Create SaaJitter Collector window appears.

Step 3 Enter the Name. (SAAicmp1)

Step 4 Choose an existing schedule and click Select. (S1).

Step 5 Choose an existing device and click Select. (dev1).

Step 6 Enter the following information

•Target Address (10.0.9.100)

• Target Port (101)

• Source Port (100)

• Timeout (PT4S)

• Packet Size (256)

• Num. Of Packets (15)

• interval (10)

• Tos (0)

•Control (enable)

• Vrf Name (op1)

• CODEC Type (g711alaw)

• CODEC Packets (40)

• CODEC Interval (100)

• CODEC PacketSize (80)

• Advantage Factor (10)

Step 7 Click Apply to complete the MIB Collector.

You should receive a status message indicating success or failure, for example:

Operation : Create

Collector : SAAjitter

Result : Successful

XML Configuration for a CODEC Data Collection
<collector name="SAAjitter"> 
<SaaJitterCollector> 
<schedule name="S1"/> 
<device name="dev1"> 
<operation name="op1"> 
<targetAddress>10.0.9.100</targetAddress> 
<targetPort>101</targetPort> 
</operation> 
<operation name="op2"> 
<targetAddress>10.0.9.100</targetAddress> 
<targetPort>101</targetPort> 
<sourcePort>100</sourcePort> 
</operation> 
</device> 
<codecType>g711alaw</codecType>  
<codecNumPkts>40</codecNumPkts>  
<codecInterval>100</codecInterval>  
<codecPacketSize>80</codecPacketSize>  
<advantageFactor>10</advantageFactor> 
</SaaJitterCollector> 
</collector> 
Data Export

The SaaJitter collector retrieves measurements about Jitter operations and stores the data in the database. It exports the data in comma separated values (CSV) format. Data can be exported at a specified frequency or on-demand using the XML interface (<get> <data> tags).

The first line of each data file contains the column headings separated by commas. Each subsequent line is as follows:

Table 6-14 Order of the Data Stored for the SaaJitter Collector

Order

Parameter

1.

collectorName

2.

deviceName

3.

collectionTime

4.

rttMonLatestRttOperCompletionTime

5.

rttMonLatestRttOperSense

6.

rttMonLatestRttOperApplSpecificSense

7.

rttMonLatestRttOperSenseDescription

8.

rttMonLatestRttOperTime

9.

rttMonLatestJitterOperNumOfRTT

10.

rttMonLatestJitterOperRTTSum

11.

rttMonLatestJitterOperRTTSum2

12.

rttMonLatestJitterOperRTTMin

13.

rttMonLatestJitterOperRTTMax

14.

rttMonLatestJitterOperMinOfPositivesSD

15.

rttMonLatestJitterOperMaxOfPositivesSD

16.

rttMonLatestJitterOperNumOfPositivesSD

17.

rttMonLatestJitterOperSumOfPositivesSD

18.

rttMonLatestJitterOperSum2PositivesSD

19.

rttMonLatestJitterOperMinOfNegativesSD

20.

rttMonLatestJitterOperMaxOfNegativesSD

21.

rttMonLatestJitterOperNumOfNegativesSD

22.

rttMonLatestJitterOperSumOfNegativesSD

23.

rttMonLatestJitterOperSum2NegativesSD

24.

rttMonLatestJitterOperMinOfPositivesDS

25.

rttMonLatestJitterOperMaxOfPositivesDS

26.

rttMonLatestJitterOperNumOfPositivesDS

27.

rttMonLatestJitterOperSumOfPositivesDS

28.

rttMonLatestJitterOperSum2PositivesDS

29.

rttMonLatestJitterOperMinOfNegativesDS

30.

rttMonLatestJitterOperMaxOfNegativesDS

31.

rttMonLatestJitterOperNumOfNegativesDS

32.

rttMonLatestJitterOperSumOfNegativesDS

33.

rttMonLatestJitterOperSum2NegativesDS

34.

rttMonLatestJitterOperPacketLossSD

35.

rttMonLatestJitterOperPacketLossDS

36.

rttMonLatestJitterOperPacketOutOfSequence

37.

rttMonLatestJitterOperPacketMIA

38.

rttMonLatestJitterOperPacketLateArrival

39.

rttMonLatestJitterOperSense

40.

rttMonLatestJitterErrorSenseDescription

41.

rttMonLatestJitterOperOWSumSD

42.

rttMonLatestJitterOperOWSum2SD

43.

rttMonLatestJitterOperOWMinSD

44.

rttMonLatestJitterOperOWMaxSD

45.

rttMonLatestJitterOperOWSumDS

46.

rttMonLatestJitterOperOWSum2DS

47.

rttMonLatestJitterOperOWMinDS

48.

rttMonLatestJitterOperOWMaxDS

49.

rttMonLatestJitterOperNumOfOW

50.

rttMonLatestJitterOperMOS

51.

rttMonLatestJitterOperICPIF

Threshold Crossing Alerts, Purging Data, and Hotspot Polling

The SaaJitter collector supports threshold crossing/clearing alerts (TCAs). TCAs can be configured only for the rttMonLatestRttOperCompletionTime attribute and checks for TCAs after each collection period. The SaaJitter collector can monitor thresholds for the attributes shown in Table 6-15.

Table 6-15 Attributes Monitored for Threshold Violations for SaaJitterColletor

Attribute

rttMonLatestRttOperCompletionTime

rttMonLatestJitterOperRTTSum

rttMonLatestJitterOperRTTSum2

rttMonLatestJitterOperRTTMin

rttMonLatestJitterOperRTTMax

rttMonLatestJitterOperMinOfPositivesSD

rttMonLatestJitterOperMaxOfPositivesSD

rttMonLatestJitterOperNumOfPositivesSD

rttMonLatestJitterOperSumOfPositivesSD

rttMonLatestJitterOperSum2PositivesSD

rttMonLatestJitterOperMinOfNegativesSD

rttMonLatestJitterOperMaxOfNegativesSD

rttMonLatestJitterOperNumOfNegativesSD

rttMonLatestJitterOperSumOfNegativesSD

rttMonLatestJitterOperSum2NegativesSD

rttMonLatestJitterOperMinOfPositivesDS

rttMonLatestJitterOperMaxOfPositivesDS

rttMonLatestJitterOperNumOfPositivesDS

rttMonLatestJitterOperSumOfPositivesDS

rttMonLatestJitterOperSum2PositivesDS

rttMonLatestJitterOperMinOfNegativesDS

rttMonLatestJitterOperMaxOfNegativesDS

rttMonLatestJitterOperNumOfNegativesDS

rttMonLatestJitterOperSumOfNegativesDS

rttMonLatestJitterOperSum2NegativesDS

rttMonLatestJitterOperPacketLossSD

rttMonLatestJitterOperPacketLossDS

rttMonLatestJitterOperPacketOutOfSequence

rttMonLatestJitterOperPacketMIA

rttMonLatestJitterOperPacketLateArrival

rttMonLatestJitterOperOWSumSD

rttMonLatestJitterOperOWSum2SD

rttMonLatestJitterOperOWMinSD

rttMonLatestJitterOperOWMaxSD

rttMonLatestJitterOperOWSumDS

rttMonLatestJitterOperOWSum2DS

rttMonLatestJitterOperOWMinDS

rttMonLatestJitterOperOWMaxDS

rttMonLatestJitterOperNumOfOW

rttMonLatestJitterOperMOS

rttMonLatestJitterOperICPIF

The SaaJitter collector supports purging of collected performance data. This is done on a schedule configured for all of Cisco PerfE or you can configure a purger just for this collector.

The SaaJitter collector also supports hotspot polling. If the collector is configured for hotspot polling, Cisco PerfE does not store the data internally and does not post-process the data after collection. As soon as the data is retrieved, the data is written to the CNS Integration bus based on the configuration.

Limitations

None.

SAAUdpEcho Collector

The SaaUdpEcho collector measures the round trip time for USer Datagram Protocol (UDP) datagrams between source and destination devices.

Requirements

A value for rtr responder must be configured on the target router.

This collector only works with Cisco devices that support the Service Assurance Agent.

XML Configuration

Table 6-16 describes the tags you can set for the SAAUdpEcho collector.

Table 6-16 Tags in the XML Configuration for the SAAUdpEcho Collector

XML Tag

Purpose

Mandatory/
Optional

control

Sends a control message to the rtr responder before the operation. The default is enabled.

Optional

index

The index to an existing operation already created on the router.

Optional

packetSize

The payload size of the UDP packet. The default is 64.

Optional

sourcePort

The source UDP port to use. The default is 0 which means the router will select a random port.

Optional

targetAddress

The IP address of the device upon which the SAA operation occurs. The default target address is the one specified outside the <operation> tag

Mandatory

targetPort

The destination UDP port to use. The default target port is the one specified outside the <operation> tag

Mandatory

timeout

The amount of time to wait for a response to the operation.

Optional

tos

The Type of Service (TOS) field of the IP packet. The default is 0.

Optional

VrfName

The vrfName the SAA operation should use.

Optional

Creating an SaaUdpEcho Collector with the GUI

To create an SaaUdpEcho collector with the GUI, follow these steps:

Step 1 Choose Configuration > Collectors > SaaUdpEcho Collector.

The SaaUdpEcho Collector window appears.

Step 2 Click Create.

The Create SaaUdpEcho Collector window appears.

Step 3 Enter the Name. (SaaUdpEcho)

Step 4 Choose an existing schedule and click Select. (S1).

Step 5 Choose an existing device and click Select. (dev1).

Step 6 Enter the following information

•Target Address (172.29.146.106)

• Target Port (100)

• Source Port (100)

• Timeout (PT3S)

• Packet Size (128)

•Tos (0)

•Control (enable)

•Vrf Name (op1)

Step 7 Click Apply to complete the SaaUdpEcho Collector.

You should receive a status message indicating success or failure, for example:

Operation : Create

Collector : SaaUdpEcho

Result : Successful

Sample XML Configuration
<collector name="SAAudpEcho"> 
<SaaUdpEchoCollector> 
<schedule name="S1"/> 
<device name="dev1"> 
<operation name="op1"> 
<targetAddress>172.29.146.106</targetAddress> 
<targetPort>100</targetPort> 
<sourcePort>100</sourcePort> 
</operation> 
<operation name="op2"> 
<targetAddress>172.29.146.106</targetAddress> 
<targetPort>100</targetPort> 
</operation> 
</device> 
<timeout>PT3S</timeout> 
<packetSize>128</packetSize> 
<tos>0</tos> 
<control>enable</control> 
</SaaUdpEchoCollector> 
</collector>
Data Export

The SaaUdpEcho collector retrieves measurements about the UdpEcho operation and stores the data in the database. It exports data in comma separated values (CSV) format. Data can be exported at a specified frequency or on-demand using the XML interface (<get> <data> tags).

The first line of each data file contains the column headings separated by commas. Each subsequent line contains the following information:

Table 6-17 Order of the Data Exported by the SaaUdpEcho Collector

Order

Parameter

1.

collectorName

2.

deviceName

3.

data collection timestamp

4.

rttMonLatestRttOperCompletionTime

5.

rttMonLatestRttOperSense

6.

rttMonLatestRttOperApplSpecificSense

7.

rttMonLatestRttOperSenseDescription

8.

rttMonLatestRttOperTime

Threshold Crossing Alerts, Purging Data, and Hotspot Polling

The SaaUdpEcho collector supports threshold crossing/clearing alerts (TCAs). TCAs can be configured only for the rttMonLatestRttOperCompletionTime attribute. The collector checks for TCAs after each collection period.

The SaaUdpEcho collector supports purging of collected performance data. This is done on a schedule configured for all of Cisco PerfE or based on an XML configuration for just this collector.

The SaaUdpEcho collector also supports hotspot polling. If the collector is configured for hotspot polling, Cisco PerfE does not store the data internally and does not post-process the data after collection. As soon as the data is retrieved, the data is written to the CNS Integration bus based on the configuration.

Limitations

None.

System Collector

The System collector monitors the health of the Cisco PerfE host, including disk, CPU, and memory usage on the system. It also monitors the CPU and memory usage of core Cisco PerfE processes such as Java, Tomcat, and database processes. The disks this collector monitors are the hard disks used for the data, the database, and <CNS_PerfE_Home>. In addition, based on the collector configuration, it can also send fatal system and informational messages during system startup and shutdown.

Note It is recommended that you configure a System collector on every Cisco PerfE host.

Requirements

None.

Creating a System Collector with the GUI

To create a System collector, follow these steps:

Step 1 Choose Configuration > Collectors > System Collector.

The System Collector window appears.

Step 2 Click Create.

The Create System Collector window appears.

Step 3 Enter the Name. (sys)

Step 4 Choose an existing schedule and click Select. (S1)

Step 5 Choose existing Data Export1 and click Select. (dh)

Step 6 Choose an existing Threshold and click Select. (th1)

Step 7 Choose an existing Event Notification1 and click Select. (trapNot)

Step 8 Choose an existing Event Notification2 and click Select. (SYScnsNot)

Step 9 Choose to enable or disable Save Data in DB. (enable)

Step 10 Click Apply to create the System Collector.

You should receive a status message indicating success or failure, for example:

Operation : Create

Collector : sys

Result : Successful

Viewing System Collector Data as Graphs

System collector data can be displayed as a graph. You can choose any three sets of supported SystemCollector data and specify the time duration to view the statistics in the form of graph. This feature supports line graphs and bar graphs.

Note To use this feature, you must set the environment variable DISPLAY on the Cisco Performance Engine host, with the IP address pointing to a machine where xserver is running permanently. For example, set DISPLAY="ipaddress":0.0 .

To view System collector data as graphs, follow these steps:

Step 1 Choose Administration > Graphs > System Collector graph.

Step 2 Select up to three sets of system collector data from the drop down boxes.

Step 3 Specify the Start time and End time.

Step 4 Select either Line Graph or Bar Graph.

Step 5 Click Draw graph to create the System Collector data graphs.

XML Configuration

No special configuration is required for the System collector.
<das> 
      <create> 
            <schedule name="S1"> 
                  <start>2001-08-31T00:00:00.000-08:00</start> 
                  <interval>PT1M</interval> 
                  <interTaskDelay>PT0.1S</interTaskDelay> 
            </schedule> 
            <dataHandler name="dh"> 
                  <ftp> 
                        <urlPrefix>ftp://userid:password@ip-address/%2Fvar/tmp/exportSYS</
urlPrefix> 
                  </ftp> 
            </dataHandler> 
            <threshold name="th1"> 
                  <attribute name="sys.disk.db.usedPercentage"> 
                        <raiseOperation>GT</raiseOperation> 
                        <raiseValue>10</raiseValue> 
                        <clearOperation>LT</clearOperation> 
                        <clearValue>30</clearValue> 
                        <level>minor</level> 
                  </attribute> 
            </threshold> 
            <notifier name="trapNot"> 
                  <trap> 
                        <ipaddress>10.77.11.125</ipaddress> 
                  </trap> 
            </notifier> 
            <notifier name="SYScnsNot"> 
                  <cns> 
                        <subject>SYS-cns</subject> 
                  </cns> 
            </notifier> 
            <collector name="sys"> 
                  <SystemCollector> 
                        <schedule name="S1"/> 
                        <threshold name="th1"/> 
                        <notifier name="SYScnsNot"/> 
                        <notifier name="trapNot"/> 
                        <dataHandler name="dh"/> 
                  </SystemCollector> 
            </collector> 
      </create> 
      <start> 
            <collector name="sys"/> 
      </start> 
</das> 
Threshold Processing

For threshold processing, the following SystemCollector variables can be configured:

•sys.memory.availableMega

•sys.memory.usedPercentage

•sys.disk.home.availableMega

•sys.disk.home.usedPercentage

•sys.disk.db.availableMega

•sys.disk.db.usedPercentage

•sys.disk.data.availableMega

•sys.disk.data.usedPercentage

•sys.cpu.loadPercentage

•java.memory.availableMega

•java.memory.usedPercentage

•cperfe.memory.usedInMB

•cperfe.memory.usedPercentage

•cperfe.cpu.loadPercentage

•db.memory.usedInMB

•db.memory.usedPercentage

•db.cpu.loadPercentage

•tomcat.memory.usedInMB

•tomcat.memory.usedPercentage

•tomcat.cpu.loadPercentage

Data Export, Threshold Crossing Alerts, and Purging Data

The System collector exports data in comma separated values (CSV) format. Data can be exported at a specified frequency or on-demand using the XML interface (<get> <data> tags). The first line of each exported file contains the column headings separated by commas.

The order of the data exported by the System collector is:

1. collector name

2. collectionTime

3. memoryAvailableMega

4. memoryUsedPercentage

5. diskHomeAvailableMega

6. diskHomeUsedPercentage

7. diskDBAvailableMega

8. diskDBUsedPercentage

9. diskDataAvailableMega

10. diskDataUsedPercentage

11. cpuLoadPercentage

12. javaMemoryAvailableMega

13. javaMemoryUsedPercentage.

The System collector supports threshold crossing/clearing alerts (TCAs). TCAs are configured for specific attributes. The collector checks for TCAs after each collection period. Attribute names on which thresholds can be configured are provided in Table 6-18.

The System collector supports purging of collected performance data. This can be done based on the purge parameters in the das.properties file or you can configure a purger for the System collector.

The System collector also supports hotspot polling. If the collector is configured for hotspot polling, Cisco PerfE does not post-process the data after collection. As soon as the data is retrieved, the data is written to the CNS Integration bus based on the configuration.

Table 6-18 System Collector Threshold Attributes

Attribute

Description

sys.memory.availableMega

Memory available on the machine (in megabytes).

sys.memory.usedPercentage

Memory used on the machine (percentage).

sys.disk.home.availableMega

Disk space available for the home directory (in megabytes).

sys.disk.home.usedPercentage

Disk space used for the home directory (percentage).

sys.disk.db.availableMega

Disk space available for the database directory (in megabytes).

sys.disk.db.usedPercentage

Disk space used for the database directory (percentage).

sys.disk.data.availableMega

Disk space available for the data directory (in megabytes).

sys.disk.data.usedPercentage

Disk space used for the data directory (percentage).

sys.cpu.loadPercentage

CPU load on the machine (percentage).

java.memory.availableMega

Memory available on the java virtual machine (in megabytes)

java.memory.usedPercentage

Memory used on the java virtual machine (percentage).

Limitations

None.

VoiceCallStatistics Collector

The VoiceCallStatistics collector (VCS collector) collects and processes data from Voice Call Performance Statistics on Cisco gateways and Cisco VoIP Internal Error Codes projects.

The Voice Call Performance Statistics provides summarized call statistics and call accounting statistics. It provides call statistics at the following levels:

•voice port

•trunk group

•IP

•PSTN

•gateway

and exports the statistics to the Cisco PerfE host through FTP.

The Cisco VoIP Internal Error Codes feature in IOS adds error counters for each subsystem. These counters are generated at the same interval as the TH counter generation and both data sets are transmitted in a single file to the Cisco PerfE host at each interval.

The VoiceCallStatistics collector is configured for receiving these statistics. It stores statistics and forwards the data to the northbound application through a consistent interface.

Requirements

The Cisco PerfE location needs to be configured with a Command Line Interface (CLI) in the Voice Call Performance Statistics device so its data files will be transferred to the specified directory on the Cisco PerfE server.

The Cisco PerfE location directory must have write permission so the network element can push the file to the same location and Cisco PerfE can remove these files after they are processed.

The router should be configured with the same name as that used in the <create> <device> tags in Cisco PerfE.

XML Configuration

The following XML example shows the typical configuration for the VoiceCallStatistics collector.
<schedule name="VCSSchedule">
      <interval>PT15M</interval>
</schedule>
<!-this device name should be the same as the router name configured on the device-->
<device name="gw1">
      ...
</device>
<collector name="VCSCollector">
      <VoiceCallStatisticsCollector>
            <schedule name="VCSSchedule"/>
            <device name="gw1"/>			
            <localDir>/export/VCSdir</localDir>
      </VoiceCallStatisticsCollector>
</collector>
Note <localDir> specifies the location on the Cisco PerfE host where the network element FTPs files to Cisco PerfE. This is the directory the routers are configured with. Routers export files to this location on the Cisco PerfE host. Cisco PerfE reads the files from this directory and processes them.

Data Export

The VoiceCallStatisitcs collector exports data in XML format. Data can be exported at a specified frequency or on-demand using the XML interface (<get> <data> tags).

Following is a typical example of exported data by the VoiceCallStatistics collector:
<VCSStats> 
      <collector name="VCSC"> 
            <device name="as5400"> 
                  <collectionTime time="2003-02-27T05:28:30.000Z"> 
                        <csrStats startTime="2003-02-26T23:25:58.000Z" 
endTime="2003-02-26T23:25:59.000Z"> 
                              <gw> 
                                    <inCalls>100</inCalls> 
                                    <inAns>100</inAns> 
                                    <inRej>0</inRej> 
                                    <outCalls>100</outCalls> 
                                    <outAns>100</outAns> 
                                    <outFail>0</outFail> 
                                    <inSeizureDur>null</inSeizureDur> 
                                    <outSeizureDur>507</outSeizureDur> 
                                    <inConnDur>504</inConnDur> 
                                    <outConnDur>504</outConnDur> 
                                    <origDisconn>0</origDisconn> 
                                    <inAnsAbnormal>0</inAnsAbnormal> 
                                    <outAnsAbnormal>0</outAnsAbnormal> 
                                    <inMcd>0</inMcd> 
                                    <outMcd>0</outMcd> 
                                    <inPDD>4630</inPDD> 
                                    <outPDD>2810</outPDD> 
                                    <inSetupDelay>1730</inSetupDelay> 
                                    <outSetupDelay>1730</outSetupDelay> 
                                    <inDiscCauseCode> 
                                          <count code="16">100</count> 
                                    </inDiscCauseCode> 
                                    <outDiscCauseCode> 
                                          <count code="16">100</count> 
                                    </outDiscCauseCode>
                              </gw> 
                              <ip> 
                              .... 
                              </ip> 
                              <pstn> 
                              .... 
                              </pstn> 
                              <tg id="orig2"> 
                              .... 
                              </tg> 
                              <vp id="6/0:D" tgid="t1"> 
                              .... 
                              </vp> 
                        </csrStats> 
                        <casrStats startTime="2003-02-26T06:49:44.000Z" 
endTime="2003-02-26T06:49:45.000Z"> 
                              <ml id="h323"> 
                                    <acctPassCriteria>1</acctPassCriteria> 
                                    <pstnInPass>0</pstnInPass> 
                                    <pstnInFail>0</pstnInFail> 
                                    <pstnOutPass>0</pstnOutPass> 
                                    <pstnOutFail>0</pstnOutFail> 
                                    <ipInPass>0</ipInPass> 
                                    <ipInFail>0</ipInFail> 
                                    <ipOutPass>0</ipOutPass> 
                                    <ipOutFail>0</ipOutFail> 
                              </ml> 
                              <ml id="ddtest"> 
                                    .... 
                                    .... 
                              </ml> 
                              .... 
                              .... 
                        </casrStats> 
                        <iecStats startTime="2003-02-26T06:49:44.000Z" 
endTime="2003-02-26T06:49:45.000Z"> 
                              <count subsysid ="3" code="5">1</count> 
            ..... 
                        </iecStats> 
                  </collectionTime> 
            </device> 
      </collector> 
</VCSStats>
Similarly, when multiple files are collected in one interval, the export format will be as follows:

Suppose the two files are collected in an interval as FN1 and FN2 at the same time as T1 (from the same device).

  FN1 has section CSR1, CASR1, IEC1.

  FN2 has sections CSR2, CASE2, IEC2.

  The output from Cisco PerfE is as follows:
<VCSStats> 
      <collector .....> 
            <device ...> 
                  <collectionTime T1> 
                        <csrStats for CSR1>       ...        </csrStats> 
                        <csrStats for CSR2>       ....       </csrStats> 
                        <casrStats for CASR1>   ....       </casrStats> 
                        <casrStats for CASR2>   ....       </casrStats> 
                        <iecStats for IEC1>         ...         </iecStats> 
                        <iecStats for IEC2>         ...         </iecStats> 
                  </collectionTime> 
          ... 
          ... 
</VCSStats>
Threshold Crossing Alerts, Purging Data, and Hotspot Polling

The VoiceCallStatistics collector supports threshold crossing/clearing alerts (TCAs). TCAs are configured for specific attributes. The collector checks for TCAs after each collection period. Attribute names on which thresholds can be configured are given below.

The VoiceCallStatistics collector supports purging of collected performance data. This can be done based on purge parameters in the das.properties file or you can configure a purger for the VoiceCallStatistics collector.

The VoiceCallStatistics collector also supports hotspot polling. If the collector is configured for hotspot polling, Cisco PerfE does not store the data internally and does not post-process the data after data collection. As soon as the data is retrieved, it is written to the CNS Integration bus based on the configuration.

The following are the supported threshold attribute names:

GW attribute names

gw.<tagname>

IP attribute names

ip.<tagname>

gw.inCalls

ip.inCalls

gw.inAns

ip.inAns

gw.inRej

ip.inRej

gw.outCalls

ip.outCalls

gw.outAns

ip.outAns

gw.outFail

ip.outFail

gw.inSeizureDur

ip.inSeizureDur

gw.outSeizureDur

ip.outSeizureDur

gw.inConnDur

ip.inConnDur

gw.outConnDur

ip.outConnDur

gw.origDisconn

ip.origDisconn

gw.inAnsAbnormal

ip.inAnsAbnormal

gw.outAnsAbnormal

ip.outAnsAbnormal

gw.inMcd

ip.inMcd

gw.outMcd

ip.outMcd

gw.inPDD

ip.inPDD

gw.outPDD

ip.outPDD

gw.inSetupDelay

ip.inSetupDelay

gw.inSetupDelay

ip.inSetupDelay

gw.outSetupDelay

ip.outSetupDelay

ip.lostPkt

ip.latency

ip.jitter

gw.inDiscCauseCode.<causecode#>

ip.inDiscCauseCode.<causecode#>

gw.outDiscCauseCode.<causecode#>

ip.outDiscCauseCode.<causecode#>

Similarly, for PSTN, the names are as follows:
pstn.<tagname>
For trunk group data, the names are as follows:
tg.<tgid>.<tagname>
For voice port data, the names are as follows:
vp.<vpid>.<tgid>.<tagname>.[code]
For IEC data, the names are as follows:
iec.<subsystemid>.<errcode>
Following are sample threshold attribute names with their intended behavior explained:

•tg.10.inCalls—match inCalls values for trunk group whose id is 10

•tg..inCalls—match inCalls values for all trunk groups

•vp.1.10.inCalls—match inCalls for the voice port whose id is 1 and trunkgroupid is 10

•vp.1..inCalls—match inCalls for the voice port whose id is 1

•vp...inCalls—match inCalls for all voice ports.

For call accounting statistics, the following threshold names are supported:
<methodList>.<methodList_name>.<threshold attributes> [ methodList is the name of the list 
(e.g. radius123) ]
For example:

•ml.radius123.acctPassCriteria

•ml.radius123.pstnInPass

•ml.radius123.pstnInFail

•ml.radius123.pstnOutPass

•ml.radius123.pstnOutFail

•ml.radius123.ipInPass

•ml.radius123.ipInFail

•ml.radius123.ipOutPass

•ml.radius123.ipOutFail.

VoipDAS Collector

The VoipDAS collector collects correlated call data from multiple Cisco PerfE hosts and correlates four call legs for each call. Because of the distributed nature of Cisco PerfE, one Cisco PerfE may not have the call detail record for all four call legs. For example, call legs 1 and 2 are collected by Cisco PerfE A, while call legs 3 and 4 are collected by Cisco PerfE B. In cases such as this, each Cisco PerfE correlates the data it has. Cisco PerfE A correlates call legs 1 and 2, while Cisco PerfE B correlates call legs 3 and 4. In this case, the VoipDas collector is similar to any other collector in Cisco PerfE and treats the underlying Cisco PerfE systems as the data sources for call correlated data.

Multiple Cisco PerfE hosts are specified in the configuration as urlPrefixes, that is, each URL Prefix identifies the username and password to access that particular Cisco PerfE host, and the data directory in which correlated files are stored. The VoipDAS collector picks up files from this directory for correlation and deletes the files from the data source after the files are retrieved.

Requirements

If an external network device will export data to Cisco PerfE host, the FTP server should be configured and running on the same host where Cisco PerfE is running. .

Note that in Cisco CNS PerfE, the dasadmin account is used by the VoIPDAS collector to FTP data to the Cisco CNS PerfE host. If Cisco CNS PerfE is installed under /opt, FTP fails because the dasadmin user cannot access the /opt directory. As a result, the /etc/ftpaccess file should have the dasadmin user in the access list as follows.
realuser root dasadmin 
This enables dasadmin user to access root directories, for example, /opt.

XML Configuration

Table 6-19 describes the tags you can set for the VoipDAS collector.

Table 6-19 Tags in the XML Configuration for the VoipDAS Collector

XML Tag

Purpose

Mandatory/
Optional

urlPrefixes

Identifies the username and password to access that particular Cisco PerfE host and the data directory in which correlated files are stored.

Mandatory

Sample XML Configuration with FTP
<collector name="v1">
      <VoipDasCollector>
            <schedule name="S1"/>
            <urlPrefix>ftp://user:passwd@DASA/%2Fopt/CSCOdas/data/VoipCorrelator/</urlPref
ix>
            <urlPrefix>ftp://user:passwd@DASB/%2Fopt/CSCOdas/data/VoipCorrelator/</urlPref
ix>
      </VoipDasCollector>
</collector>
Sample XML configuration with SFTP:
<collector name="v1">
      <VoipDasCollector>
            <schedule name="S1"/>
            <urlPrefix>ftp://user:passwd@DASA/%2Fopt/CSCOdas/data/VoipCorrelator/</urlPref
ix>
            <urlPrefix>sftp://user:passwd@DASB/%2Fopt/CSCOdas/data/VoipCorrelator/</urlPre
fix>
      </VoipDasCollector>
</collector>
Data Export, Threshold Crossing Alerts, Purging Data, and Hotspot Polling

Refer to the RADIUS collector sections: "Data Export" section and "Threshold Crossing Alerts, Purging Data, and Hotspot Polling" section. The data files from the VoipDAS collector are generated in the <CNS_PerfE_Home>/data/VoipDasCollector directory.

Limitations

Because the VoipDAS collector does very large FTP operations and correlates CDR files, it is resource-intensive. It is recommended you install the VoipDAS collector only on a 2nd-tier Cisco PerfE system (see Figure 1-1 on page 1-2 for more information on 2nd-tier systems).

VPDNCustomer Collector

VPDN (Virtual Private Dialup Network) is a feature of Cisco IOS. VPDN handles the forwarding of Point-to-Point (PPP) links from an Internet Service Provider (ISP) to a home gateway.

The VPDN tunnel's user information is a manageable entity in VPDN.

The VPDNCustomer collector is a collector in Cisco PerfE that collects data about the tunnel information for a customer using SNMP and reports the following information per customer:

•totalTunnels—total number of tunnels assigned

•totalActiveSessions—total number of active sessions currently in all tunnels

•totalDeniedUsers —total number of denied users (cumulative).

XML Configuration
<das>
      <load>
            <mib name="CISCO-VPDN-MGMT-MIB.my"/>
      </load>
      <create>
            <schedule name="VPDNSchedule">
                  <start>2002-03-06T00:00:00.000-08:00</start>
                  <interval>PT2M</interval>
            </schedule>
            <device name="VPDNDevice">
                  <snmp>
                        <ipaddress>10.0.9.25</ipaddress>
                        <readCommunity>public</readCommunity>
                        <writeCommunity>private</writeCommunity>
                  </snmp>
            </device>
            <dataHandler name="VPDNExport">
                  <url>
                        <prefix>ftp://user:password@b-netrax1/%2Fdata/VPDNPeriodic</prefix
>
                  </url>
            </dataHandler>
            <threshold name="VPDNThreshold">
                  <attribute name="totalActiveSessions.sbc">
                        <raiseOperation>GT</raiseOperation>
                        <raiseValue>30</raiseValue>
                        <clearOperation>LT</clearOperation>
                        <clearValue>100</clearValue>
                        <level>critical</level>
                  </attribute>
            </threshold>
            <notifier name="VPDNNotifyCNS">
                  <cns>
                        <subject>cns.cisco.das.listener</subject>
                  </cns>
            </notifier>
            <collector name="VPDNCollect">
                  <VPDNCustomerCollector>
                        <schedule name="VPDNSchedule"/>
                        <device name="VPDNDevice"/>
                        <threshold name="VPDNThreshold"/>
                        <notifier name="VPDNNotifyCNS"/>
                        <dataHandler name="VPDNExport"/>
                  </VPDNCustomerCollector>
            </collector>
      </create>
      <start>
            <collector name="VPDNCollect"/>
      </start>
</das>
Data Export

Data is exported in CSV format as follows:

•the first line of the file contains the version number

•the second line of the file contains the header

•the rest of the file contains the data.

Sample Data
Version = 1.0
CollectorName, DeviceName, CustomerName, Timestamp, TotalTunnels, TotalActiveSessions, 
TotalDeniedUsers
VPDNCollect,10.0.9.25,aol,2002-11-22T08:38:00.017Z,2,40,43
VPDNCollect,10.0.9.25,att,2002-11-22T08:38:00.017Z,3,18,33
VPDNCollect,10.0.9.25,sbc,2002-11-22T08:38:00.017Z,4,41,35
Threshold Crossing Alerts, Purging Data, and Hotspot Polling

The VPDNCustomer collector supports threshold crossing/clearing alerts (TCAs). TCAs are configured for specific attributes. The collector checks for TCAs after each collection period.

Thresholds can be applied to totalActiveSessions and totalDeniedUsers. CustomerName can be appended to the attribute name to support a threshold for a specific customer.

The threshold attribute names can specified as follows:

totalActiveSessions.<customername>

or

totalActiveSessions

totalDeniedUsers.<customername>

or

totalDeniedUsers

For example, if the threshold attribute name is totalActiveSessions.aol, the threshold is applied to the total number of active sessions for the aol customer. If the threshold attribute name is totalActiveSessions, the threshold is applied to all customers. This collector supports purging of collected performance data. This can be done based on purge parameters in the das.properties file or you can configure a purger for the VPDNCustomer collector.

The VPDNCustomer collector also supports hotspot polling. If the collector is configured for hotspot polling, Cisco PerfE does not store the data internally and does not post-process the data after data collection. As soon as the data is retrieved, it is written to the CNS Integration bus based on the configuration.