Cisco Performance Engine User Guide, 2.1.5
Configuring the Collectors
Downloads: This chapterpdf (PDF - 0.98MB) | Feedback

Configuring the Collectors

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">
            <!-- callStatus: completed, abandoned, or failed ->
            <callStatus>completed</callStatus>
            <!-- gatewayCall: did the call involve a gateway: no, originating, terminating 
->
            <gatewayCall>originating</gatewayCall>
            <cdrData>x1,x2,...</cdrData>
         </cdr>
      </call>
   </device>
</report> [padmat1]

For the description of the fields specified in the <cdrData> tag, refer to the following documentation:

Call Detail Record Definition for Release 3.3(2)

http://www.cisco.com/univercd/cc/td/doc/product/voice/vpdd/cdd/3_3/3_3_2/cdr332.pdf

CDR Plus CMR Report Format

<report name="cdrPlusCmr" version="1">
   <collector name="callmgrCdrCollector"/>
   <device name="callmgrDev">
      <call callId="xxx" callManagerId="xxx" clusterId="xxx">
         <cdr callId="xxx" callManagerId="xxx" clusterId="xxx" >
            <!-- callStatus: completed, abandoned, or failed ->
            <callStatus>completed</callStatus>
            <!-- gatewayCall: did the call involve a gateway: no, originating, terminating 
->
            <gatewayCall>originating</gatewayCall>
            <cdrData>x1,x2,...</cdrData>
            <cmr>
               <cmrData>y1,y2,...</cmrData>
               <cmrData>y1,y2,...</cmrData>
            </cmr>
         </cdr>
      </call>
   </device>
</report>

For the description of the fields specified in the <cmrData> tag, refer to the following documentation:

Call Detail Record Definition for Release 3.3(2)

http://www.cisco.com/univercd/cc/td/doc/product/voice/vpdd/cdd/3_3/3_3_2/cdr332.pdf

Summarized Hourly Report Format

recordVersion,recordType,collectorName,deviceName,dateTimeStamp,totalAttemptedCalls, totalCompletedCalls,totalAbandonedCalls,totalFailedCalls,totalIncomingGWCalls, totalOutgoingGWCalls, totalGWCalls, maxDuration, minDuration,avgDuration, maxJitter,maxLatency,maxPacketLost, maxPacketSent,maxOctetsSent, maxPacketRecv, maxOctetsRecv,avgJitter,avgLatency,avgPacketLost, avgPacketSent,avgOctetsSent, avgPacketRecv,avgOctetsRecv

Summarized Daily Report Format

version,recordType,collectorName,deviceName,timestamp,totalAttemptedCalls, totalCompletedCalls, totalAbandonedCalls, totalFailedCalls,totalIncomingGWCalls, totalOutgoingGWCalls,totalGWCalls,maxDuration,minDuration,avgDuration, maxJitter,maxLatency,maxPacketLost,maxPacketSent,maxOctetsSent,maxPacketRecv, maxOctetsRecv,avgJitter, avgLatency,avgPacketLost,avgPacketSent, avgOctetsSent, avgPacketRecv,avgOctetsRecv

CDRPlusCMR Report Format

<report name="cdrPlusCmr" version="1">
	<collector name="CCM01"/>
	<device name="CCMDev">
   	<call callId="6" callManagerId="1" clusterId="StandAloneCluster">
   	<cdr callId="6" callManagerId="1" clusterId="StandAloneCluster">
      <callStatus>completed</callStatus>
      <gatewayCall>terminating</gatewayCall>
		 
<cdrData>1,6,16777227,1060883906,1,0,1250323328,0,5000,0,16,1250323328,4001,4,20,196274356
0,16777228,1,0,1250323328,0,5001,5001,0,0,1250323328,4002,4,20,1962743560,1060883906,10608
83909,5001,8e885cd8-9c29-436a-8da8-9a098045cab0,,,,,3,SEP000011110001,SEP000011110002,0,0,
0,12,0,0,0,StandAloneCluster,0</cdrData>
      <cmr>
         	
<cmrData>1,6,1,5000,16777227,1060883909,295,49468,277,46531,0,0,0,fa03d143-f96d-4c16-a215-
8c22baf8bc46,,SEP000011110001,StandAloneCluster</cmrData>
         	
<cmrData>1,6,1,5001,16777228,1060883909,295,49468,277,46531,0,0,0,92e01fa1-112c-4b31-95ce-
b388cdb86130,,SEP000011110002,StandAloneCluster</cmrData>
   </cmr>
   </cdr>
   </call>
   <call callId="5" callManagerId="1" clusterId="StandAloneCluster">
   <cdr callId="5" callManagerId="1" clusterId="StandAloneCluster">
      <callStatus>completed</callStatus>
<gatewayCall>terminating</gatewayCall>
<cdrData>1,5,16777225,1060883901,1,0,1250323328,0,5008,0,16,1250323328,4009,4,20,4990698,1
6777226,1,0,1250323328,0,5005,5005,0,0,1250323328,4010,4,20,4990698,1060883902,1060883905,
5005,76468193-e695-494a-aa49-40763a368aca,,,,,3,SEP000011110009,SEP00001111000A,0,0,0,12,0
,0,0,StandAloneCluster,0</cdrData>
      <cmr>
         
<cmrData>1,5,1,5008,16777225,1060883905,295,49468,277,46531,0,0,0,d6afe4c4-21a8-4507-97a9-
5d71dcf72c1a,,SEP000011110009,StandAloneCluster</cmrData>
         
<cmrData>1,5,1,5005,16777226,1060883905,295,49468,277,46531,0,0,0,42e206a1-212b-4f9e-aa42-
f04d96de589b,,SEP00001111000A,StandAloneCluster</cmrData>
   </cmr>
   </cdr>
   </call>
</device>
</report>

Hourly Report Format

recordVersion,recordType,collectorName,collectorDevice,dateTimeStamp,totalAttemptedCalls,t
otalCompletedCalls,totalAbandonedCalls,totalFailedCalls,totalIncomingGWCalls,totalOutgoing
GWCalls,totalGWCalls,maxDuration,minDuration,avgDuration,maxJitter,maxLatency,maxPacketLos
t,maxPacketSent,maxOctetsSent,maxPacketRecv,maxOctetsRecv,avgJitter,avgLatency,avgPacketLo
st,avgPacketSent,avgOctetsSent,avgPacketRecv,avgOctetsRecv
1,3,CCM01,CCMDev,1060880400,10,10,0,0,0,10,10,3,3,3,0,0,0,295,49468,277,46531,0,0,0,295,49
468,277,46531

Threshold Crossing Alerts

The Call Manager CDR collector supports thresholds on summarized data. The format of the threshold name is the name of the summarized report plus the attribute in that report.

For example:

	<threshold name="hourlyAverageJitter">
	     <attribute name="hourlySummary.avgJitter">
	     
	</threshold>

	<threshold name="dailyFailedCalls">
	     <attribute name="dailySummary.totalFailedCalls">
	     
	</threshold>

The following thresholds are supported:

totalFailedCalls

maxJitter

maxLatency

maxPacketLost

avgJitter

avgLatency

avgPacketLost.

CBQoS Collector

The CBQoS collector collect s Class Map and Police Statistics from the CLASS BASED QoS (CBQos) MIB implemented on the gateway.

The CBQoS collector also collects the following statistic tables:

cbQosTSStatsTable

cbQosMatchStmtStatsTable

cbQosREDClassStatsTable

The following statistics are collected:

cbQosMatchPrePolicyBitRate,cbQosTSStatsDelayedByte64,cbQosTSStatsDelayedPkt64,cbQosTSStatsDropByte64,cbQosTSStatsDropPkt64,cbQosTSStatsActive,cbQosTSStatsCurrentQSize,cbQosREDValue,cbQosREDRandomDropPkt64,cbQosREDRandomDropByte64,cbQosREDTailDropPkt64,cbQosREDTailDropByte64,cbQosREDTransmitPkt64,cbQosREDTransmitByte64,cbQosREDECNMarkPkt64,cbQosREDECNMarkByte64,cbQosREDMeanQSizeUnits,cbQosREDMeanQSize

The Modular Qos CLI (MQC) is a CLI structure that allows you to create traffic service policies and attach these service policies to interfaces. A traffic policy contains a traffic class and one or more QoS features. A traffic class is used to classify traffic, while the QoS feature in the traffic class determines how to treat the classified traffic.

Refer to the following link for more information on the MQC:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcprt8/

XML Configuration

<das>
      <create>
            <schedule name="15min">
                  <interval>PT15M</interval>
            </schedule>

            <schedule name=20min">
                  <interval>PT20M</interval>
            </schedule>

            <device name="cbqos-dev">
                  <snmp>
                        <ipaddress>10.0.1.71</ipaddress>
                        <readCommunity>public</readCommunity>
                        <writeCommunity>public</writeCommunity>
                  </snmp>
            </device>

            <dataHandler name="CBQoSExporter">
                  <url>
                        <prefix>ftp://user:passwd@host/incoming/cbQoS/</prefix>
                  </url>
            </dataHandler>
            <notifier name="notifier1">
                  <cns>
                        <subject>cns.cisco.das.listener</subject>
                  </cns>
            </notifier>

            <threshold name="CBQoSThresholds">
                  <attribute name="55.DT.queue1.cbQosCMPrePolicyPkt">
                        <raiseOperation>GT</raiseOperation>
                        <raiseValue>300</raiseValue>
                        <clearOperation>LT</clearOperation>
                        <clearValue>4</clearValue>
                        <level>minor</level>
                  </attribute>
                  <attribute name="55.DT.queue3.1.bQosREDTransmitPkt64"> 
                        <raiseOperation>GTE</raiseOperation>
                        <raiseValue>300</raiseValue>
                        <clearOperation>LTE</clearOperation>
                        <clearValue>250</clearValue>
                        <level>minor</level>
                  </attribute>
            </threshold>

            <collector name="CBQoS">
                  <CBQoSCollector>
                        <schedule name="15min"/>
                        <device name="cbqos-dev"/>
                        <threshold name="CBQoSThresholds"/>
                        <notifier name="notifier1"/>
                        <dataHandler name="CBQoSExporter">
                              <schedule name="20min"/>
                        </dataHandler>
                  </CBQoSCollector>
            </collector>

      </create>
      <add/>
      <start>
            <collector name="CBQoS"/>
      </start>
</das>

Thresholds

The CBQoS collector supports thresholds. The threshold attribute name format is as follows:

<attribute name="ifIndex.servicePolicyName.classMapName.statName">

Refer to the example above.

The format supports both servicePolicyName and policeStatName.

servicePolicyName—the name used in the policy-map command in the IOS configuration file

policeStatName—the name of the police statistics variable.

See the CISCO-CLASS-BASED-QOS-MIB.my MIB for more detailed information.

For configuring thresholds with attributes from the cbQosREDClassStatsTable, the format of the threshold attribute is:

<attribute name="ifIndex.servicePolicyName.classmapName.redValue.attribute">

Following are the supported threshold names:

cbQosCMPrePolicyPkt

cbQosCMPrePolicyByte

cbQosCMPrePolicyBitRate

cbQosCMPostPolicyByte

cbQosCMPostPolicyBitRate

cbQosCMDropPkt

cbQosCMDropByte

cbQosCMDropBitRate

cbQosMatchPrePolicyBitRate

cbQosPoliceConformedPkt

cbQosPoliceConformedByte

cbQosPoliceConformedBitRate

cbQosPoliceExceededPkt

cbQosPoliceExceededByte

cbQosPoliceExceededBitRate

cbQosPoliceViolatedPkt

cbQosPoliceViolatedByte

cbQosPoliceViolatedBitRate

cbQosQueueingCurrentQDepth

cbQosQueueingMaxQDepth

cbQosQueueingDiscardByte64

cbQosQueueingDiscardPkt64

cbQosREDValue

cbQosREDRandomDropPkt64

cbQosREDRandomDropByte64

cbQosREDTailDropPkt64

cbQosREDTailDropByte64

cbQosREDTransmitPkt64

cbQosREDTransmitByte64

cbQosREDECNMarkPkt64

cbQosREDECNMarkByte64

cbQosREDMeanQSize

cbQosTSStatsDelayedByte64

cbQosTSStatsDelayedPkt64

cbQosTSStatsDropByte64

cbQosTSStatsDropPkt64

cbQosTSStatsCurrentQSize.

Data Export Format

The CBQoS collector has been enhanced to collect statistics for the following Statistics tables:

cbQosMatchStmtStats

cbQosTSStats

cbQosREDClassStats.

The following attributes are collected from the Statistics tables:

cbQosMatchStmtStats:

cbQosMatchPrePolicyPkt64

cbQosMatchPrePolicyByte64

cbQosMatchPrePolicyBitRate

cbQosTSStats:

cbQosTSStatsDelayedByte64

cbQosTSStatsDelayedPkt64

cbQosTSStatsDropByte64

cbQosTSStatsDropPkt64

cbQosTSStatsActive

cbQosTSStatsCurrentQSize

cbQosREDClassStats:

cbQosREDRandomDropPkt64

cbQosREDRandomDropByte64

cbQosREDTailDropPkt64

cbQosREDTailDropByte64

cbQosREDTransmitPkt64

cbQosREDTransmitByte64

cbQosREDECNMarkPkt64

cbQosREDECNMarkByte64

cbQosREDMeanQSizeUnits

cbQosREDMeanQSize.

The header of the exported file contains all of the above attributes along with cbQosREDValue, which is the index for the cbQosREDClassStats table.

Thresholds can be configured for all of the above attributes except the following:

cbQosTSStatsActive

cbQosREDMeanQSizeUnits.

ClusterMib Collector

The ClusterMib collector collects statistics from multiple devices in a cluster and summarizes the data for each cluster. The ClusterMib collector only uses the device group (deviceGroup) instead of both the device and device group. Each device group is essentially a cluster of devices. Data collected from the devices within a device group are summarized and presented to the management interface. Attributes are summarized to sum, minimum, maximum, and average.

XML Configuration

The <ClusterMib Collector> tag contains configuration information specific to the ClusterMib collector. It has the snmpGet tag that contains a list of OIDs. snmpGet uses an SNMP get to poll the SNMP agent for an instance OID. The OIDs can be specified as the name of the node or in numeric form. For example, system.sysDescr.0 can be specified as: sysDescr.0, 1.1.0, or .1.3.6.1.2.1.1.1.0.

Following is a sample XML configuration (schedule name and deviceGroup must be defined prior to the collector):

<collector name="cluster_collection">
      <ClusterMibCollector>
            <schedule name="s1"/>
            <deviceGroup name="dg1"/>
            <snmpGet>
                  <oid>cvpdnSystemTunnelTotal</oid>
                  <oid>cvpdnSystemSessionTotal</oid>
                  <oid>cvpdnSystemDeniedUsersTotal</oid>
            </snmpGet>		
      </ClusterMibCollector>
</collector>

Data Export

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

Sample data:

<ClusterMibData>
      <collector name="cluster_collection">
            <collectionTime time="2001-12-21T03:15:00Z">
                  <cluster name="dg1">
                        <device name="GW1.cisco.com"/>
                        <device name="GW2.cisco.com"/>
                        <attribute name="cvpdnSystemTunnelTotal">
                              <sum>5000</sum>
                              <min>1000</min>
                              <max>4000</max>
                              <avg>2500</avg>
                              <count>2</count>
                        </attribute>
                        <attribute name="cvpdnSystemSessionTotal">
                              <sum>10000</sum>
                              <min>3000</min>
                              <max>7000</max>
                              <avg>5000</avg>
                              <count>2</count>
                        </attribute>
                  </cluster>
            </collectionTime>
      </collector>
</ClusterMibData>

Threshold Crossing Alerts, Purging Data, and Hotspot Polling

The ClusterMib collector also supports threshold crossing/clearing alerts (TCAs). Five types of threshold attributes exist for each OID collected. These include sum, min, max and avg of the OID values and the count for the number of devices collected from. For example, with <oid>cvpdnSystemDeniedUsersTotal.0</oid>, the following attributes can be checked against the threshold:

sysUpTime.0.sum

sysUpTime.0.min

sysUpTime.0.max

sysUpTime.0.avg

sysUpTime.0.count.

The ClusterMib collector also supports the 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 Mib collector.

It 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, the data is written to the CNS Integration bus based on the configuration.

Cisco PerfE supports data collection from any SNMP v2c MIBs. The MIBs should be loaded before the collector is configured in Cisco PerfE.

Limitations

This collector supports SNMP v2c and SNMPv3 but does not support plugins.

DOCSIS Data Collector

Cisco CNS PerfE provides support for collecting DOCSIS information. This is achieved by using the DOCSIS Data collector (DDC) included with Cisco CNS PerfE.

The DDC is designed to collect information that is of interest for a NOC operator at a Multiple System Operator (MSO), a cable service provider that also provides other services such as high-speed data (HSD) and/or voice telephony services. The DDC provides information for the NOC personnel to examine the following information for a customer's cable modem:

the cable modem's status (functioning or non-functioning)

the status of other infrastructure equipment involved in providing high-speed data service.

The DDC interacts with the cable modem and the CMTS, which is Cisco's uBR, using SNMP and can use information from a customers's database for cable modem to CMTS association and to obtain location information.

The DDC collects data using SNMP and forwards the information from multi-vendor CMTS's and the cable modems across the HFC plant by using FTP and the CNS bus.

Requirements

The DDC requires the framework definition of the CMTS's as a device. See the XML configuration below.

If the number of CMTS's under management is more than a nominal number (10), it is recommended you increase the max cache Java property.

At or around line 82 in the $DAS_HOME/config/das.properties file, change:

MEM.JAVA_MAX_CACHE=256M

to

MEM.JAVA_MAX_CACHE=512M

You may have to further increase the cache if the number of CMTS's under management exceeds 25.

XML Configuration

Following is a sample XML configuration for the DDC (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>

Define the Collector

              <collector name="docsis1"> 
                <DocsisCollector> 
                  <schedule name="sch1M"/> 
                  <device name="ubr1"> 
                    <threshold name="threshold1"/> 
                    <cmtsConfig>

Configure the Cable Modem on the uBR and Define them to also be SNMPv3

                      <cmConfig> 
                        <readCommunity>public</readCommunity> 
                        <timeout>PT5S</timeout> 
                        <retry>1</retry> 
                        <version>SNMPv3</version> 
                        <port>161</port> 
                        <userName>HORSHAM</userName> 
                        <authProtocol>MD5</authProtocol> 
                        <authPassword>HORSHAM1</authPassword> 
                      </cmConfig> 
                      <row_origin>1</row_origin> 
                      <subscriber_count>0</subscriber_count> 
                      <threadPolicy>0</threadPolicy> 
                      
<serviceLostPercentageThreshold>10.0</serviceLostPercentageThreshold> 
                      <collectCmtsOnly>0</collectCmtsOnly>

                      <collectExtraIfTable>1</collectExtraIfTable> 

Note This is an AND function. If the collectExtraIfTable value is 1, then extra information is collected. See the "Data Export" section for information returned when this flag is set to 1.



                      <collectCdxQosCtrlUpTable>1</collectCdxQosCtrlUpTable>                        
                      <collectCdxCmtsCmStatusTable>1</collectCdxCmtsCmStatusTable>                        
                      <collectDocsIfCmtsServiceTable>1</collectDocsIfCmtsServiceTable>                        
                      <collectCdxCmCpeTable>1</collectCdxCmCpeTable> 
                       
                      <throttleSleepMillis>0</throttleSleepMillis> 
                      <throttleBusyHours> 
                        <docsisBusyHours>1100-1300</docsisBusyHours>                            
                        <docsisBusyHours>1430-1900</docsisBusyHours>                            
                        <docsisBusyHours>2330-0210</docsisBusyHours> 
                      </throttleBusyHours> 
                    </cmtsConfig> 
                  </device> 
                  <device name="ubr2"/> 
                  <notifier name="CNSnotifier"/> 
                  <dataHandler name="hotspot"/> 
                  <dataHandler name="ddc-dh"> 
                    <schedule name="sch2M"/> 
                  </dataHandler> 
                  <purger name="purge1"/> 
                  <globalConfig name="GlobalConfig1"> 
                    <maxOfflinePercent>40.0</maxOfflinePercent> 
                    <lowSnrUpsteam>-25.0</lowSnrUpsteam> 
                    <upstreamXmitPowerFloor>34.0</upstreamXmitPowerFloor> 
                    <upstreamXmitPowerCeiling>34.0</upstreamXmitPowerCeiling>                    
                    <downstreamSnrFloor>30.0</downstreamSnrFloor> 
                    <downstreamReceivePowerFloor>-15.0</downstreamReceivePowerFloor>                    
                    <downstreamReceivePowerCeiling>5.0</downstreamReceivePowerCeiling>                    
                    <maxModemsInitDCount>50</maxModemsInitDCount> 
                    <pctModemsOnlineFloor_Cmts>90.0</pctModemsOnlineFloor_Cmts>                    
                    <minimumModemCount_Cmts>100</minimumModemCount_Cmts> 
                    <pctModemsOnlineFloor_Upstream>90.0</pctModemsOnlineFloor_Upstream>                    
                    <minimumModemCount_Upstream>100</minimumModemCount_Upstream>                    
                    <pctModemsOnlineFloor_Ds>90.0</pctModemsOnlineFloor_Ds> 
                    <minimumModemCount_Downstream>100</minimumModemCount_Downstream>                    
                    <pctModemsOnlineFloor_Node>90.0</pctModemsOnlineFloor_Node>                    
                    <minimumModemCount_Node>100</minimumModemCount_Node> 
                    <writeCmtsReportsOnTimeout>1</writeCmtsReportsOnTimeout>                    
                    <collectCmtsOnly>0</collectCmtsOnly> 
                    <maxDownstreamModems>1500</maxDownstreamModems> 
                    <maxMarketModemsThreading>20000</maxMarketModemsThreading> 
                  </globalConfig> 
                </DocsisCollector> 
              </collector>

Database Tables

The database tables used by the DOCSIS Data collector must be defined after installation of Cisco CNS PerfE. They are not installed with the generic Cisco CNS PerfE product.

To define the DDC tables, do the following:


Step 1 Define the DAS_HOME UNIX environment variable to point to the root directory where Cisco CNS PerfE was installed.

Step 2 Verify the Cisco CNS PerfE system is running. If it is not, start Cisco CNS PerfE by entering the following:

cd $DAS_HOME/bin

./start.sh

Step 3 Change directory to $DAS_HOME/ddc/bin, then execute the following to create the tables DDC will use:

./install-docsis-tables.sh

The DDC in Cisco CNS PerfE, Release 2.1, does not require the data in the tables to be pre-populated as in Cisco CNS PerfE, Release 2.0, but rather allows full configuration through XML.


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

The DDC fully supports historical data storage under control of the purge function of the framework for the storage intervals defined.

The DDC supports data export forms of hotspot and periodic polling. Hotspot polling and can be configured through the XML interface.

Data Export

This section contains a sample data export:

<DOCSIS_CHANNEL_DATA>
ipAddress|ifIndex|ifDescr|ifType|totalModems|onlineModems|snmpOnlineModems|snmpT
imeouts|lowXmitPowerExceptions|highXmitPowerExceptions|lowSnrExceptions|minXmitP
ower|maxXmitPower|avgXmitPower|minSnr|maxSnr|avgSnr|lowDsRecvPowerExceptions|hig
hDsRecvPowerExceptions|docsIfSigQSignalNoise|docsIfSigQUnerroreds|docsIfSigQCorr
ecteds|docsIfSigQUncorrectables|docsIfSigQMicroreflections|userExtensionData|snm
pPollDuration|lastUpdated
10.87.117.2|4|Cable3\/0-upstream0|129|0|0|0|0|0|0|0|0.00|0.00|0.00|0.00|0.00|0.0
0|0|0|0.00|0|0|0|0| |0|2003-03-12 08:32:13.616
10.87.117.2|5|Cable3\/0-upstream1|129|2|2|2|0|0|2|0|40.00|40.00|40.00|38.40|41.3
0|39.85|0|2|31.30|1414432329|354624783|3391950922|0| |86|2003-03-12 08:32:13.593
10.87.117.2|6|Cable3\/0-upstream2|129|0|0|0|0|0|0|0|0.00|0.00|0.00|0.00|0.00|0.0
0|0|0|0.00|0|0|0|0| |0|2003-03-12 08:32:13.57
10.87.117.2|7|Cable3\/0-upstream3|129|0|0|0|0|0|0|0|0.00|0.00|0.00|0.00|0.00|0.0
0|0|0|0.00|0|0|0|0| |0|2003-03-12 08:32:13.686
10.87.117.2|8|Cable3\/0-upstream4|129|0|0|0|0|0|0|0|0.00|0.00|0.00|0.00|0.00|0.0
0|0|0|0.00|0|0|0|0| |0|2003-03-12 08:32:13.64
10.87.117.2|9|Cable3\/0-upstream5|129|0|0|0|0|0|0|0|0.00|0.00|0.00|0.00|0.00|0.0
0|0|0|0.00|0|0|0|0| |0|2003-03-12 08:32:13.626
10.87.117.2|10|Cable3\/0-downstream|128|2|2|2|0|0|2|0|40.00|40.00|40.00|38.40|41
.30|39.85|0|2|0.00|0|0|0|0| |0|2003-03-12 08:32:13.7
10.87.117.2|14|Cable6\/0-upstream0|129|5|5|5|0|1|3|0|33.70|37.00|35.04|33.20|36.
60|35.22|0|0|28.90|6750785|0|5|0| |353|2003-03-12 08:32:13.603
10.87.117.2|15|Cable6\/0-upstream1|129|0|0|0|0|0|0|0|0.00|0.00|0.00|0.00|0.00|0.
00|0|0|0.00|0|0|0|0| |0|2003-03-12 08:32:13.58
10.87.117.2|16|Cable6\/0-downstream|128|5|5|5|0|1|3|0|33.70|37.00|35.04|33.20|36
.60|35.22|0|0|0.00|0|0|0|0| |0|2003-03-12 08:32:13.713
</DOCSIS_CHANNEL_DATA>

This section provides raw data as retrieved from the attached cable modem:

<DOCSIS_MODEM_DATA>
docsIfCmtsCmStatusMacAddress|docsIfCmtsCmStatusIpAddress|cmtsIpAddress|sysDescr|
sysObjectID|sysUpTime|cmtsCmStatusDownChannelIndex|cmtsCmStatusUpChannelIndex|cm
tsCmStatusValue|cmtsCmStatusRxPower|cmtsCmStatusTimingOffSet|cmtsCmStatusIndex|d
ocsIfDownChannelPower|docsIfSigQUnerroreds|docsIfSigQUncorrectables|docsIfSigQSi
gnalNoise|docsIfCmStatusLostSyncs|docsIfCmStatusTxPower|docsIfCmStatusResets|doc
sIfCmStatusT1Timeouts|docsIfCmStatusT2Timeouts|docsIfCmStatusT3Timeouts|docsIfCm
StatusT4Timeouts|cdxIfCmtsCmStatusDynSidCount|cdxIfCmtsCmStatusAddlInfo|dot1dBas
ePortDlyExcdedDscards|docsDevServerConfigFile|cdxCmtsCmStatusValue|statusNotes|u
serExtensionData|lastUpdated|opticalNodeName
00:04:27:a5:c0:81|10.1.5.15|10.87.117.2|<<HW_REV: 3.t; VENDOR: Cisco Systems Inc
; BOOTR: 12.2(2r)T1; SW_REV: 12.2; MODEL: CVA122 >>IOS (tm) 120 Software 
(CVA120-K8O3V4Y5-M), Experimental Version 12.2 Copyright (c) 1986-2002 by cisco Systems, 
IncCompiled Sat 06-Apr-02 02:07 by 
|.1.3.6.1.4.1.9.1.306|130.37|16|14|6|-.20|2810.00|393220|3.70|1215856659|8295|35.20|9|33.7
0|570|0|0|13|7|0|00 |2.0|HorshamCM.cm|12|Upstream Xmit Power 33.7 is below 34.0| 
|2003-03-12 08:32:13.476|
00:02:16:d5:a4:0d|10.1.5.13|10.87.117.2|Cisco Internetwork Operating System Soft
ware IOS (tm) 920 Software (UBR920-K8V7Y5-M), Version 12.2(1), RELEASE SOFTWARE (fc2)
Copyright (c) 1986-2001 by cisco Systems, Inc.Compiled Fri 27-Apr-01 05:46 by cmong
|.1.3.6.1.4.1.9.1.255|56.95|16|14|6|-0.20|2813.00|393219|0.00|28728630|0|36.60|2|37.00|128
|0|0|38|2|0|00 |2.0|HorshamCM.cm|12|Upstream Xmit Power 37.0 is above 34.0| |2003-03-12 
08:32:13.486|
08:00:3e:08:ef:4c|10.1.5.10|10.87.117.2|Motorola Docsis Cable Modem; MAC=08-00-3
E-08-EF-4C; SN=26529486; REV=2.0.0 |.1.3.6.1.4.1.161.7.10.5|1.74|16|14|6|-0.20|2
132.00|393218|0.00|426136520|0|33.20|0|34.00|0|0|0|0|0|0|00 |1.0| |12| | |2003-0
3-12 08:32:13.5|
00:08:0e:16:fb:be|10.1.4.51|10.87.117.2|<<HW_REV: 0; VENDOR: Motorola; BOOTR: CG
4D_05.3.04; SW_REV: CG4D_05.4.02; MODEL: SBV4200>>OS: VxWorks 5.4|.1.3.6.1.4.1.1
166.1.200.0.1.5.4.2|97.61|10|5|6|-0.20|652.00|196610|11.70|58160070|0|41.30|0|40
.00|0|0|0|4|1|0|00 |1.0|cisco11_perl_5304_cm_dual.bin|12|Upstream Xmit Power 40.
0 is above 34.0; Downstream Recv Power 11.7 is above 5.0| |2003-03-12 08:32:13.5
13|
</DOCSIS_MODEM_DATA>

If the <collectExtraIfTable>1</collectExtraIfTable flag is set, the following is also returned.


Note The values for cdxQosCtrlUpMaxRsvdBWPercent, cdxQosCtrlUpAdmissionRejects, and cdxQosCtrlUpReservedBW in the following data require the <collectCdxQosCtrlUpTable>1</collectCdxQosCtrlUpTable> flag be set.


<DOCSIS_EXTRA_IF_LIST>
cmtsip|ifIndex|lastCollectedTime|ifType|ifAdminStatus|ifOperStatus|ifLastChange|
ifInOctets|ifInUcastPkts|ifInDiscards|ifInErrors|ifOutOctets|ifOutUcastPkts|ifOu
tDiscards|ifOutErrors|ifInMulticastPkts|ifInBroadcastPkts|ifOutMulticastPkts|ifO
utBroadcastPkts|ifCounterDiscontinuityTime|cdxCmtsCmTotal|cdxCmtsCmActive|cdxCmt
sCmRegistered|cdxQosCtrlUpMaxRsvdBWPercent|cdxQosCtrlUpAdmissionRejects|cdxQosCt
rlUpReservedBW
10.87.117.2|3|2003-03-12 08:32:13.146|127|1|1|959|2628718892|498464816|0|0|25280
32783|512134705|0|0|0|12466|608365|105159|0|3|3|3|null|null|null
10.87.117.2|4|2003-03-12 08:32:13.133|129|1|1|913|0|0|0|17742|0|0|0|0|0|0|0|0|0|
null|null|null|100|0|0
10.87.117.2|5|2003-03-12 08:32:13.11|129|1|1|927|3816738722|522883010|0|21085721
04|0|0|0|0|0|12466|0|0|0|null|null|null|100|0|0
10.87.117.2|6|2003-03-12 08:32:13.08|129|2|2|878|0|0|0|0|0|0|0|0|0|0|0|0|0|null|
null|null|100|0|0
10.87.117.2|7|2003-03-12 08:32:13.056|129|2|2|878|0|0|0|0|0|0|0|0|0|0|0|0|0|null
|null|null|100|0|0
10.87.117.2|8|2003-03-12 08:32:13.033|129|2|2|878|0|0|0|0|0|0|0|0|0|0|0|0|0|null
|null|null|100|0|0
10.87.117.2|9|2003-03-12 08:32:13.013|129|1|2|878|0|0|0|0|0|0|0|0|0|0|0|0|0|null
|null|null|100|0|0
10.87.117.2|10|2003-03-12 08:32:13.156|128|1|1|959|0|0|0|0|2528033883|512134710|
0|0|0|0|608365|105159|0|null|null|null|null|null|null
10.87.117.2|13|2003-03-12 08:32:13.123|127|1|1|351954390|270627401|999558|212|10
0|180696605|801821|0|0|24|43420|0|178151|0|8|8|8|null|null|null
10.87.117.2|14|2003-03-12 08:32:13.093|129|1|1|352003221|434415123|6957878|0|218
|0|0|0|0|24|43422|0|0|0|null|null|null|100|0|0
10.87.117.2|15|2003-03-12 08:32:13.066|129|2|2|351954093|0|0|0|0|0|0|0|0|0|0|0|0
|0|null|null|null|100|0|0
10.87.117.2|16|2003-03-12 08:32:13.043|128|1|1|351954390|0|0|0|0|180696605|80182
1|0|0|0|0|0|178151|0|null|null|null|null|null|null
</DOCSIS_EXTRA_IF_LIST>

If the <collectExtraIfTable> = 1 and <collectDocsIfCmtsServiceTable> = 1 flags are set, the following is also returned:

<DOCSIS_IF_CMTS_SERVICE_LIST>
cmtsip|ifIndex|docsIfCmtsServiceId|lastCollectedTime|docsIfCmtsServiceCmStatusIn
dex|docsIfCmtsServiceAdminStatus|docsIfCmtsServiceQosProfile|docsIfCmtsServiceCr
eateTime|docsIfCmtsServiceInOctets|docsIfCmtsServiceInPackets|cdxIfCmtsServiceOu
tOctets|cdxIfCmtsServiceOutPackets
10.87.117.2|3|1|2003-03-12 08:32:13.433|196609|1|0|2200|51440374|180004|0|0
10.87.117.2|3|2|2003-03-12 08:32:13.423|196610|1|0|2600|52730034|192288|0|0
10.87.117.2|3|3|2003-03-12 08:32:13.416|196610|1|0|2600|606988678|5057117|0|0
10.87.117.2|3|4|2003-03-12 08:32:13.41|196609|1|0|2200|604748942|5037968|0|0
10.87.117.2|3|4907|2003-03-12 08:32:13.406|196609|1|0|2200|34884|153|0|0
10.87.117.2|13|2|2003-03-12 08:32:13.393|393218|1|1|352004600|42775330|226849|29
112852|162147
10.87.117.2|13|3|2003-03-12 08:32:13.386|393219|1|1|352005600|43507260|121314|26
194529|120021
10.87.117.2|13|4|2003-03-12 08:32:13.38|393220|1|1|352007400|44949588|120993|261
97162|120033
10.87.117.2|13|5|2003-03-12 08:32:13.44|393221|1|1|352007600|45011810|123029|263
87483|121977
10.87.117.2|13|6|2003-03-12 08:32:13.43|393222|1|1|352080700|58213068|237276|267
81679|124815
</DOCSIS_IF_CMTS_SERVICE_LIST>

If the <collectExtraIfTable> = 1 and <collectCdxCmCpeTable> = 1 flags are set, the following is also returned:

<CDX_CM_CPE_LIST>
cmtsip|cdxCmCpeMacAddress|lastCollectedTime|cdxCmCpeType|cdxCmCpeIpAddress|cdxCm
CpeIfIndex|cdxCmCpeCmtsServiceId|cdxCmCpeCmStatusIndex
10.87.117.2|00:02:16:d5:a4:0d|2003-03-12 08:32:12.68|1|10.1.5.13|13|3|393219
10.87.117.2|00:02:16:d5:a4:27|2003-03-12 08:32:12.69|1|10.1.5.11|13|6|393222
10.87.117.2|00:04:27:a5:c0:45|2003-03-12 08:32:12.656|1|10.1.5.14|13|5|393221
10.87.117.2|00:04:27:a5:c0:81|2003-03-12 08:32:12.71|1|10.1.5.15|13|4|393220
10.87.117.2|00:04:bd:b7:81:ca|2003-03-12 08:32:12.696|1|10.1.4.50|3|1|196609
10.87.117.2|00:04:bd:b7:81:cc|2003-03-12 08:32:12.673|2|192.168.2.102|3|1|196609
10.87.117.2|00:08:0e:16:fb:be|2003-03-12 08:32:12.703|1|10.1.4.51|3|2|196610
10.87.117.2|00:08:0e:16:fb:c0|2003-03-12 08:32:12.686|2|192.168.2.104|3|2|196610
10.87.117.2|00:10:a4:aa:6e:fc|2003-03-12 08:32:12.723|2|192.168.3.60|13|5|393221
10.87.117.2|08:00:3e:08:ef:4c|2003-03-12 08:32:12.716|1|10.1.5.10|13|2|393218
</CDX_CM_CPE_LIST>

Pre-Defined Queries

In addition to the basic hotspot and periodic polling, the DDC also provides the following pre-defined queries:

1. Query number of collection intervals currently available:

<parameter name="docsisQueryType">
docsis-number-collection-intervals
</parameter>

2. Query of CMTS summary info:

<parameter name="docsisQueryType">
docsis-cmts-summary-info
</parameter>

3. Query of CMTS upstream summary info:

<parameter name="docsisQueryType">
docsis-cmts-upstream-summary-info
</parameter>

4. Query of specific upstream summary info by ifDescr:

<parameter name="docsisQueryType">
docsis-specific-upstream-by-ifdescr-summary-info
</parameter>
<parameter name="ifDescr">
description
</parameter>

5. Query of specific upstream summary info by ifIndex:

<parameter name="docsisQueryType">
docsis-specific-upstream-by-ifindex-summary-info
</parameter>
<parameter name="ifIndex">
99
</parameter>

6. Query of all modem info:

<parameter name="docsisQueryType">
docsis-all-modem-info
</parameter>

7. Query of all modem info by upstream ifIndex:

<parameter name="docsisQueryType">
docsis-all-modem-info-by-upstream-ifindex
</parameter>
<parameter name="ifIndex">
99
</parameter>

8. Query of all modem info by optical node name:

<parameter name="docsisQueryType">
docsis-all-modem-info-by-optical-node-name
</parameter>

Threshold Crossing Alerts

The attributes listed in Table 6-2 are available for threshold crossing alerts processing or Process plugins.


Note Threshold crossing alerts are limited to numeric data only so sysDescr is invalid.


Table 6-2 Threshold Crossing Alert Attributes 

Query String
tagname
Indexed By

sysUpTime

sysUpTime

None, scalar

sysDescr

sysDescr

None, scalar

sysObjectID

sysObjectID

None, Scalar

ifTable

ifDescr

X=ifIndex,

 

ifType

 
 

docsIfSigQUnerroreds

 
 

docsIfSigQCorrecteds

 
 

docsIfSigQUncorrectables

 
 

docsIfSigQSignalNoise

 
 

docsIfSigQMicroreflections

 
 

ifAdminStatus

 
 

ifOperStatus

 
 

ifLastChange

 
 

ifInOctets

 
 

ifInUcastPkts

 
 

ifInDiscards

 
 

ifInErrors

 
 

ifOutOctets

 
 

ifOutUcastPkts

 
 

ifOutDiscards

 
 

ifOutErrors

 

ifXentry

ifCounterDiscontinuityTime

X=ifindex

 

ifInMulticastPkts

 
 

ifInBroadcastPkts

 
 

ifOutMulticastPkts

 
 

ifOutBroadcastPkts

 

docsIfCmtsServiceTable

docsIfCmtsServiceCmStatusIndex

X=ifIndex, Y=docsIfCmtsServicdeId

 

docsIfCmtsServiceAdminStatus

 
 

docsIfCmtsServiceQosProfile

 
 

docsIfCmtsServiceCreateTime

 
 

docsIfCmtsServiceInOctets (related to the OutOctets in the next section)

 
 

docsIfCmtsServiceInPackets (related to the OutPackets in the next section)

 

CdxCmtsServiceExtEntry

cdxIfCmtsServiceOutOctets

X=ifIndex

Y= docsIfCmtsServiceId

 

cdxIfCmtsServiceOutPackets

 

cdxCmtsMacExtEntry

cdxCmtsCmTotal

X=ifIndex

 

cdxCmtsCmActive

 
 

cdxCmtsCmRegistered

 

cdxCmtsCmStatusExtEntry

cdxIfCmtsCmStatusDynSidCount

X=docsIfCmtsCmStatusIndex

 

cdxIfCmtsCmStatusAddlInfo

 

cdxCmCpeEntry

cdxCmCpeType

X=cdxCmCpeMacAddress

 

cdxCmCpeIfIndex

 
 

cdxCmCpeCmtsServiceId

 
 

cdxCmCpeIpAddress

 
 

cdxCmCpeStatusIndex

 

cdxQosCtrlUpEntry

cdxQosCtrlUpMaxRsvdBWPercent

X=ifIndex

 

cdxQosCtrlUpReservedBW

 
 

cdxQosCtrlUpAdmissionRejects

 

cmtsSummaryData

ipaddress

None, scalars

 

sysUpTime

 
 

collectionFinishTime

 
 

totalModems

 
 

onlineModems

 
 

snmpOnlineModems

 
 

cpeCount

 
 

lowXmitPowerExceptions

 
 

highXmitPowerExceptions

 
 

lowSnrExceptions

 
 

minXmitPower

 
 

avgXmitPower

 
 

minSnr

 
 

maxSnr

 
 

avgSnr

 
 

lowDsRecvPowerExceptions

 
 

highDsRecvPowerExceptions

 

cmtsChannelData

ipAddress

X = ifIndex

 

ifDescr

 
 

ifType

 
 

totalModems

 
 

onlineModems

 
 

snmpOnlineModems

 
 

lowXmitPowerExceptions

 
 

highXmitPowerExceptions

 
 

lowSnrExceptions

 
 

minXmitPower

 
 

avgXmitPower

 
 

minSnr

 
 

maxSnr

 
 

avgSnr

 
 

lowDsRecvPowerExceptions

 
 

highDsRecvPowerExceptions

 
 

docsIfSigQSignalNoise

 
 

docsIfSigQUnerroreds

 
 

docsIfSigQCorrecteds

 
 

docsIfSigQUncorrectables

 
 

lastUpdated

 

Note the following:

For summary info on the CMTS, the names are cmtsSummaryData.<tagname>

For linecard data dealing with signal quality, the names are ifTable.<ifIndex>.<tagname>

For individual linecard data and modem info, the names are cmtsChannelData.<ifIndex>.<tagname>

For multiply index entries, the names are docsIfCmtsServiceTable.<ifIndex>.<docsIfCmtsServicdeId>.tagname

The threshold attribute name ifTable.10.ifType matches ifType values for ifIndex whose ID is set to 10.

The threshold attribute name ifTable..docsIfSigQCorrecteds matches docsIfSigQCorrecteds values for all ifIndex files.

Purging Data

The DDC fully supports the framework purge mechanism.

IosCliOps Collector

The IosCliOps collector is supported in Cisco CNS PerfE, 2.1. This collector is used to poll information from IOS devices. It issues an IOS show command through telnet/ssh to a router and extracts information from output text of the show command. A regular expression file is associated with each show command and specifies the fields to be extracted from the show command output.

The IosCliOps collector supports execution of multiple commands for a device. Each command is treated as a single operation, the command output is collected, and the regular expression is applied to extract the necessary attributes. The collected data is then stored in the persistent store, thresholds can be applied, and data can be exported.

You must provide the regular expression to parse the output of the command. Regular expressions are placed in the <CNS-PerfEHOME>/config/ioscli directory:

Creating an IosCliOps Collector with the GUI

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


Step 1 Choose Configuration > Collectors > IosCliOps Collector.

The IosCliOps Collector window appears.

Step 2 Click Create.

The Create IosCliOps Collector window appears.

Step 3 Enter the Name. (c1)

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

Step 5 Choose an existing IOS device, then click Select. (dev1)

Step 6 Choose an existing data export, then click Select. (h1)

Step 7 Choose an existing event notification, then click Select. (n1)

Step 8 Choose an existing threshold, then click Select. (t1)

Step 9 Enter the following information:

IosCliOps Specific (regexp-url>file:///cnsperfe/config/ioscli/LspPing.re</regexp-url)


Note Use the Modify Collector option from the GUI to add or remove operations froma device or device group.


Step 10 Click Apply to create the IosCliOps collector.

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

Operation : Create

Collector : c1

Result : Successful


XML Configuration


<das>
    <create>
        <schedule name="5min">
            <interval>PT5M</interval>
        </schedule>

        <schedule name="15min">
	    <interval>PT15M</interval>
        </schedule>

        <device name="dev1">
	  <ios>
	    <ipaddress>10.0.0.1</ipaddress>
                <username>user1</username>
                <password>pass1</password>
	    <secret>pass2</secret>
	    <terminalServerIpAddress>10.0.0.2</terminalServerIpAddress>
	    <terminalServerPort>2001</terminalServerPort>
	    <consoleLinePassword>pass3</consoleLinePassword>
	    <connectMode>terminalserver</connectMode>
	    <transportMode>telnet</transportMode>
	  </ios>
        </device>

	<dataHandler name="dh1">
            <url>
		<prefix>ftp://user1:pass1@10.0.0.1/data/ios</prefix>
	    </url>	
	</dataHandler>
	<notifier name="n1">
	    <cns>
	       <subject>cns.cisco.das.listener</subject>
	    </cns>
	</notifier>

        <threshold name="t1">
	    <attribute name="ping.minRoundTripTime">
		<raiseOperation>EQ</raiseOperation>
		<raiseValue>20</raiseValue>
		<clearOperation>GT</clearOperation>
		<clearValue>100</clearValue>
		<level>minor</level>
	    </attribute>
	</threshold>

        <collector name="c1">
          <IosCliOpsCollector>
              <schedule name="5min"/>
              <device name="dev1">
	<operation name="op1">
	<command>ping mpls ipv4 10.131.159.252/32 sweep 1492 1500 1</command>
	</operation>
	 <operation name="op2">
	    <command>ping mpls ipv4 10.131.159.252/32</command>
	 </operation>
	      </device>	
              <threshold name="t1"/>
              <notifier name="n1"/>
              <dataHandler name="dh1">
		<schedule name="15min"/>
	      </dataHandler>
              <regexp-url>file:///cnsperfe/config/ioscli/LspPing.re</regexp-url>
            </IosCliOpsCollector>
        </collector>
    </create>
    <start>
        <collector name="c1"/>
    </start>
</das>

The <connectMode> parameter of the IOS device configuration can be either terminalserver or direct depending on the mode of device access from Cisco CNS PerfE.

The <transportMode> parameter can be either Telnet or SSH depending on the login mode supported by the device.


Note This collector only supports 3DES encryption when the SSH option is set for <transportMode>.


Syntax of Regular Expression File

The regular expression file contains the <ATTRNAMES> and <REGEXP> tags.

<ATTRNAMES>—specifies the names for the attributes extracted from the command output.

<REGEXP>—specifies the regular expression to be applied by the command. Contents to be extracted are embedded within common braces, for example:

.*Success rate is (\d+) percent

The number of attributes mentioned in <ATTRNAMES> and the number of braces in the <REGEXP> tag should match. For example, the following is the regular expression file for the ping command.

<ATTRNAMES>ping.successRate,ping.packetsReceived,ping.packetsSent,ping.minRou
ndTripTime,ping.avgRoundTripTime,ping.maxRoundTripTime</ATTRNAMES>
<REGEXP>.*Success rate is (\d+) percent \((\d+)\/(\d+)\)(?:,\s+round-
trip\s+min\/avg\/max\s+=\s+(\d+)\/(\d+)\/(\d+) ms|$)</REGEXP>

Data Export Format

Version = 1.0
CollectorName, DeviceName, OperationName, CollectionTime, 
ping.successRate,ping.packetsReceived,ping.packetsSent,ping.minRoundTripTime,ping.a
vgRoundTripTime,ping.maxRoundTripTime
c1,dev1,op2,2003-07-25T12:03:00.000Z,100,1,1,80,80,80

The header in the exported file contains the name of the collector, device, operation name, and collection time, in addition to the attribute names specified in the regular expression file.

For an IosCliOps collector, when a data handler is associated with the Schedule, one file per device will be exported and it contains all of the operations specified for this device.

For an IosCliOpscollector, when the ConsolidatedExport option is enabled, one file for all of the devices (and all the operations of the devices) associated with the IosCliOps collector, will be exported.

Threshold Crossing Alerts, Purging Data, and Hotspot Polling

The IosCliOps collector supports thresholds. The threshold attribute name format is as follows:

<attr-name> 

For example:

ping.maxRoundTripTime

See the "XML Configuration" section for a complete example.

The IosCliOps collector also supports purging data. and hotspot polling. When hotspot polling is configured, one file is exported for each operation associated with the device.

Add/Remove Operations From a Device

Once the IosCliOps collector is created, operations can be added or removed dynamically as follows:

XML Example for Adding Operations for a Given Device

<das>
  <add>
    <collector name="c1">
       <IosCliOpsCollector>
          <device name="dev1">
	 <operation name="op3">
	  <command>ping mpls ipv4 10.131.159.252/32 sweep 1492 1500 1</command>
	</operation>
          </device>	
       </IosCliOpsCollector>
    </collector>
  </add>
</das>

XML Example for Removing Operations for a Given Device

<das>
  <remove>
    <collector name="c1">
       <IosCliOpsCollector>
          <device name="dev1">
	    <operation name="op3"/>
	  </device>	
       </IosCliOpsCollector>
    </collector>
  </remove>
</das>

Add/Remove Operations From a Device Group

Multiple operations can be specified for each device group. That is, for each operation, Cisco CNS PerfE issues the IOS command at the router, collects the output, then extracts the necessary data according to the regular expression file specified; this process is repeated for all devices in the group.

<das>
    <create>
        <deviceGroup name="dg1">
  	  <device name="dev1"/>
  	  <device name="dev2"/>
        </deviceGroup>

        <collector name="c1">
          <IosCliOpsCollector>
              <schedule name="5min"/>
              <deviceGroup name="dg1">
	   <operation name="op1">
	   <command>ping mpls ipv4 10.131.159.252/32 sweep 1492 1500 1</command>
	 </operation>
	 <operation name="op2">
	    <command>ping mpls ipv4 10.131.159.252/32</command>
	 </operation>
	      </deviceGroup>	
              <dataHandler name="dh1">
		<schedule name="15min"/>
	      </dataHandler>
              <regexp-url>file:///cnsperfe/config/ioscli/LspPing.re</regexp-url>
            </IosCliOpsCollector>
        </collector>

    </create>
    <start>
      <collector name="c1"/>
    </start>
</das>

XML Example for Adding Operations for a Given Device Group

<das>
  <add>
    <collector name="c1">
       <IosCliOpsCollector>
          <deviceGroup name="dg1">
        <operation name="op3">
       <command>ping mpls ipv4 10.131.159.252/32 sweep 1492 1500 1</command>
	</operation>
	  </deviceGroup>	
       </IosCliOpsCollector>
    </collector>
  </add>
</das>

XML Example for Removing Operations for a Given Device Group

<das>
  <remove>
    <collector name="c1">
       <IosCliOpsCollector>
          <deviceGroup name="dg1">
	    <operation name="op3"/>
	  </deviceGroup>	
       </IosCliOpsCollector>
    </collector>
  </remove>
</das>

Limitations

The IosCliOps collector has a limitation that the same regular expression is applied to all of the command outputs for a given collector.

No plugins are supported in Cisco CNS PerfE, 2.1.3, for the IosCliOps collector.

Mib Collector

The Mib collector is used for generic data collection from SNMP agents. The Mib collector supports individual MIB OID instance retrieval with SNMP get or retrieval of columns in a table using SNMP getbulk requests. It is recommended SNMP getbulk requests be used when retrieving a large volume of data from one table or multiple tables for better performance. In order for the Mib collector to collect the data, the relative MIB must be loaded first.

The following properties can be used to tune the performance of the Mib collector:

snmp.attrsPerPDU

snmp.maxRepetitions

snmp.interval.

Requirements

The appropriate MIB must be loaded before querying the SNMP attributes.

The following MIBS are automatically loaded when Cisco PerfE starts, however, these MIBs will not show up in the XML configuration file:

IANAifType-MIB

RFC1213-MIB

IF-MIB

CISCO-SMI

SNMPv2-MIB

CISCO-RTTMON-MIB.

Create a Mib Collector with SNMP Get

To create a Mib collector with an SNMP get request, follow these steps:


Step 1 Choose Configuration > Collectors > Mib Collector.

The MIB Collector window appears.

Step 2 Click Create.

The Create MIB Collector window appears.

Step 3 Enter the Name. (MC)

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

Step 5 Add SNMPget OIDs.

Enter SNMPget OIDs. (sysDescr.0)

Click Add.

Step 6 Add SNMPGetMany OIDs .

Enter SNMPGetMany OIDs. (ifMtu)

Enter SNMPGetMany OIDs. (ifSpeed)

Click Add.

Step 7 Click Apply to complete the Mib collector.

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

Operation : Create

Collector : MC

Result : Successful


XML Configuration

The <MibCollector> tag contains configuration specific to the Mib collector. There are two child nodes: snmpGet and snmpGetMany. Either tag can contain a list of OIDs. SnmpGet uses an SNMP get request to poll the SNMP agent for an instance OID, whereas snmpGetMany uses a getbulk request to poll the SNMP agent for columns. The OIDs can be specified as the name of the node or in numeric form. For example system.sysDescr.0 can be specified as sysDescr.0, 1.1.0 or .1.3.6.1.2.1.1.1.0.

Sample XML configuration 1 (schedule must be defined prior to the collector):

<collector name="mc">
      <MibCollector>
            <schedule name="sample1" /> 
            <snmpGet>
                  <oid>sysDescr.0</oid> 
            </snmpGet>
            <snmpGetMany>
                  <oid>ifMtu</oid> 
                  <oid>ifSpeed.10</oid>
            </snmpGetMany>
      </MibCollector>
</collector>

Table Retrieval

To configure the <snmpGetTable> option using the GUI., see Chapter 7, "Create a MIB Collector with SNMPGetTable."

In addition to <snmpGet> and <snmpGetMany> tags, the Mib collector also supports the <snmpGetTable> tag. Currently, the Mib collector supports bulk retrieval using the <snmpGetMany> tag. This mode of collection is efficient for large tables, but inefficient for small tables.

The <snmpGetTable> option can be used to retrieve small tables efficiently.

<collector name="mc">
      <schedule name="sample1" />
      <MibCollector>
            <snmpGet>
                  <oid>sysDescr.0</oid> 
            </snmpGet>
            <snmpGetTable>
                  <table oid="ifTable">
                        <oid>ifInOctets</oid>
                        <oid>ifOutOctets</oid>
                  </table>
                  <table oid="atTable"/>
            </snmpGetTable>
      </MibCollector>
</collector>

The above example retrieves all the values for ifInOctets and ifOutOctets from ifTable and it retrieves the entire table for atTable.

Selective Polling

The selective polling feature allows you to poll specific OIDs that satisfy some criteria. The condition tags determine the match criteria. The first collection poll retrieves all of the entries in the table for condition OIDs. In consecutive polls, only the entries that match the condition criteria are retrieved. The <where> tag allows you to combine several conditions together using logical operators such as AND and OR.

Select the selective polling feature by specifying <snmpGetTableQuery> in the <MibCollector> section of the configuration.

<select>—specifies the condition on which the OIDs will be polled.

<condition>—specifies the condition. Supported operations are:

eq: equals

lt: less than

gt: greater than

<where>—specifies the relationship between different <condition> tags. This tag is optional if only one condition exists.

Example 6-1 Fetch ifInOctets and ifOutOctets OIDs for all ethernetCsmacd(6) Interfaces

<collector name="MibCollect1">
<MibCollector>
<schedule name="MibSchedule"/>
<device name="MibDevice"/>
<dataHandler name="MibExport"/>
<snmpGet>
<oid>sysName.0</oid>
</snmpGet>
<snmpGetTableQuery>
<table oid="ifTable">
<select>
<condition name="c1" oid="ifType" oper="eq">6</condition>
<where>c1</where>
</select>
<oid>ifInOctets</oid>
<oid>ifOutOctets</oid>
</table>
</snmpGetTableQuery>
</MibCollector>
</collector>

Example 6-2 Fetch ifInOctets and ifOutOctets OIDs for all Interfaces Where ifType Equals ethernetCsmacd(6), ifDescr Equals FastEthernet and ifMtu Equals 1500

<collector name="MibCollect1">
<MibCollector>
<schedule name="MibSchedule"/>
<device name="MibDevice"/>
<dataHandler name="MibExport"/>
<snmpGet>
<oid>sysName.0</oid>
</snmpGet>
<snmpGetTableQuery>
<table oid="ifTable">
<select>
<condition name="c1" oid="ifDescr" oper="eq">FastEthernet</condition>
<condition name="c2" oid="ifType" oper="eq">6</condition>
<condition name="c3" oid="ifMtu" oper="eq">1500</condition>
<where>c1 AND c2 OR c3</where>
</select>
<oid>ifInOctets</oid>
<oid>ifOutOctets</oid>
</table>
</snmpGetTableQuery>
</MibCollector>
</collector>

Example 6-3 Multiple Table Entries in <snmpGetTableQuery>

<collector name="MibCollect1">
<MibCollector>
...
<snmpGetTableQuery>
<table oid="ifTable">
<select>
<condition name="c1" oid="ifDescr" oper="eq">FastEthernet</condition>
<condition name="c2" oid="ifType" oper="eq">6</condition>
<condition name="c3" oid="ifMtu" oper="eq">1500</condition>
<where>c1 AND c2 OR c3</where>
</select>
<oid>ifInOctets</oid>
<oid>ifOutOctets</oid>
</table>
<table oid="ipRouteTable">
<select>
<condition name="c1" oid="ipRouteAge" oper="eq">0</condition>
<where>c1</where>
</select>
<oid>ipRouteMetric1</oid>
<oid>ipRouteMetric2</oid>
<oid>ipRouteMetric3</oid>
<oid>ipRouteMetric5</oid>
</table>
</snmpGetTableQuery>
</MibCollector>
</collector>

Example 6-4 Multiple <snmpGetTableQuery> Tags in MibCollector

<collector name="MibCollect1">
<MibCollector>
...
<snmpGetTableQuery>
<table oid="ifTable">
<select>
<condition name="c1" oid="ifDescr" oper="eq">FastEthernet</condition>
<condition name="c2" oid="ifType" oper="eq">6</condition>
<condition name="c3" oid="ifMtu" oper="eq">1500</condition>
<where>c1 AND c2 OR c3</where>
</select>
<oid>ifInOctets</oid>
<oid>ifOutOctets</oid>
</table>
</snmpGetTableQuery>
<snmpGetTableQuery>
<table oid="ipRouteTable">
<select>
<condition name="c1" oid="ipRouteAge" oper="eq">0</condition>
<where>c1</where>
</select>
<oid>ipRouteMetric1</oid>
<oid>ipRouteMetric2</oid>
<oid>ipRouteMetric3</oid>
<oid>ipRouteMetric5</oid>
</table>
</snmpGetTableQuery>
</MibCollector>
</collector>


Note The <where> tag is not necessary when only one condition statement is specified.


Example 6-5 Complete Selective Polling

<das>
<load>
<mib name="IF-MIB.my"/>
</load>
<create>
<collector name="MibCollect2">
<MibCollector>
<schedule name="MibSchedule"/>
<device name="MibDevice"/>
<dataHandler name="MibExport"/>
<snmpGet>
<oid>sysName.0</oid>
</snmpGet>
<snmpGetTableQuery>
<table oid="ifTable">
<select>
<condition name="c1" oid="ifType" oper="eq">6</condition>
<where>c1 </where>
</select>
<oid>ifAdminStatus</oid>
<oid>ifCounterDiscontinuityTime</oid>
<oid>ifHCInBroadcastPkts</oid>
<oid>ifHCInMulticastPkts</oid>
<oid>ifHCInOctets</oid>
<oid>ifHCInUcastPkts</oid>
<oid>ifHCOutBroadcastPkts</oid>
<oid>ifHCOutMulticastPkts</oid>
<oid>ifHCOutOctets</oid>
<oid>ifHCOutUcastPkts</oid>
<oid>ifInErrors</oid>
<oid>ifInUnknownProtos</oid>
<oid>ifOperStatus</oid>
</table>
</snmpGetTableQuery>
</MibCollector>
</collector>
</create>
</das>

Example 6-6 Selective Polling from the Memory Pool Table

<das>
<load>
<mib name="CISCO-MEMORY-POOL-MIB.my"/>
</load>
<create>
<collector name="MibCollect3">
<MibCollector>
<schedule name="MibSchedule"/>
<device name="MibDevice"/>
<dataHandler name="MibExport"/>
<snmpGet>
<oid>sysName.0</oid>
</snmpGet>
<snmpGetTableQuery>
<table oid="ciscoMemoryPoolTable">
<select>
<condition name="c1"
oid="ciscoMemoryPoolName" oper="eq">Processor</condition>
<where>c1 </where>
</select>
<oid>ciscoMemoryPoolFree</oid>
<oid>ciscoMemoryPoolLargestFree</oid>
<oid>ciscoMemoryPoolUsed</oid>
<oid>ciscoMemoryPoolValid</oid>
</table>
</snmpGetTableQuery>
</MibCollector>
</collector>
</create>
</das>

Example 6-7 Selective Polling from the cardTable


Note See Chapter 7, "Create a MIB Collector with SNMPGetTableQuery" to configure using the GUI."


<das>
<load>
<mib name="OLD-CISCO-CHASSIS-MIB.my"/>
</load>
<create>
<collector name="MibCollect4">
<MibCollector>
<schedule name="MibSchedule"/>
<device name="MibDevice"/>
<dataHandler name="MibExport"/>
<snmpGet>
<oid>sysName.0</oid>
</snmpGet>
<snmpGetTableQuery>
<table oid="cardTable">
<select>
<condition name="c1" oid="chassisType" oper="eq">365</condition>
<where>c1 </where>
</select>
<oid>cardType</oid>
<oid>cardDescr</oid>
<oid>cardIndex</oid>
<oid>cardSerial</oid>
<oid>cardHwVersion</oid>
<oid>cardSwVersion</oid>
<oid>cardSlotNumber</oid>
<oid>cardContainedByIndex</oid>
<oid>cardOperStatus</oid>
<oid>cardSlots</oid>
</table>
</snmpGetTableQuery>
</MibCollector>
</collector>
</create>
</das>

Data Export

The Mib 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. Each subsequent line contains the following data:

Table 6-3 Order of the Data Exported by the Mib Collector 

Order
Parameter

1.

Collector name.

2.

Device IP address.

3.

Data collection timestamp.

4.

Attribute name.

5.

Attribute value.


Threshold Crossing Alerts, Purging Data, and Hotspot Polling

The Mib collector supports threshold crossing/clearing alerts (TCAs). TCAs are configured for specific attributes. The collector checks for TCAs after each collection period. Attribute names can include an instance in the OID or just the column name. Examples of attribute names are: ifMtu, ifSpeed.10, and ifMtu.15.

The Mib 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 Mib collector.

The Mib collector also supports hotspot polling. If the Mib 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.

Cisco PerfE supports data collection from any SNMP v2c and SNMP v3 MIBs. The MIBs should be loaded before the collector is configured in Cisco PerfE.

Limitations

None.

Mib Collector Plugins

The Mib collector supports two types of plugins:

Processor Plugin—are used to perform computation on the collected data. Instead of exporting raw data, the collector can calculate link utilization and export this data, providing a real picture of the network.

Formatter Plugin—can be used to format the collected data, which provides additional attribute type information. When configured with the Formatter plugin, the export file of the Mib collector contains the type of the MIB attribute in addition to its default output.

Processor Plugin

Plugins are intended to perform computations on the collected data. For example, assume you collected ifInOctets and ifOutOctets using the Mib collector. Instead of exporting raw data, you can calculate link utilization using the above collected data and then export that data, providing a more real picture of the network.

This can be achieved by associating different processor components with the Mib collector.

Following are the conventions used in providing parameter names for computation:

<parameter name="<operation required>.<index>">attribute</parameter>

where:

<operation required> can be delta, int, var, op, and result

<index> is an integer.

For example:

1. <parameter name="delta.1">ifInOctets</parameter>

A delta component means that delta operation must be carried out on the ifInOctets parameter.

2. <parameter name="var.1">ifSpeed</parameter>

A var component means that the value of attribute specified i.e., ifSpeed is to be used directly for computation.

3. <parameter name="int.1">100</parameter>

An int component is used to provide integer values for computation.

4. <parameter name="op.1">divide delta.2 int.1</parameter>

An op  component is used for arithmetic operations.

The operation comes first and the next two arguments are operands.

Operations supported are plus, minus, multiply and divide.

5. <parameter name="result.1">deltaIfInOctets delta.1</parameter>

A result component is used to save and export the computed data.

Computed data is stored and exported with the name deltaIfInOctets.

Data saved and also exported is delta.1, which is nothing but a delta of ifInOctets.

Note that only two operands are allowed for each operation. If the result of an op component is a scalar value, this component value must be used as a second operand in another op component. For example:

<parameter name="delta.1">sysUpTime.0</parameter>  
<parameter name="var.1">ifSpeed</parameter>  
<parameter name="int.1">100</parameter>  
<parameter name="op.1">divide delta.1 int.1</parameter>  
<parameter name="op.2">multiply op.1 var.1</parameter> 

In this example configuration, op.1 yields a scalar value. As a result, op.1 cannot be used as the first operand in the op.2 calculation. It must be used as follows:

<parameter name="op.2">multiply var.1 op.1</parameter>

In the following example, the different processor components with sample XML configuration are explained.

Supported processor components for the Mib collector are as follows:

Delta Plugin:

<das>
      <create>
            <processor name="P1">
                  <plugin name="das.jar">
                        <class>GenericFormula</class>
                        <parameter name="delta.1">ifInOctets</parameter>
                        <parameter name="delta.2">ifOutOctets</parameter>
                        <parameter name="delta.3">sysUpTime.0</parameter>

                        <parameter name="result.1">deltaIfInOctets delta.1</parameter>
                        <parameter name="result.2">deltaIfOutOctets delta.2</parameter>
                        <parameter name="result.3">deltaSysUpTime delta.3</parameter>

                  </plugin>
            </processor>
      </create>
</das>

Percentage In Link Utilization:

sysUpTime is measured in hundredths of a second, therefore, divide this by 100.

ifSpeed is measured in bits per second, therefore, multiply by 8 to get bits per second.


Step 1 Determinethe number of bytes sent in per second:

x = delta-InOctets / (deltaSysUpTime / 100)

Step 2 Calculate number of bits per second:

y = x * 8

Step 3 Multiply by 100% before dividing ifSpeed:

z = y * 100

Step 4 Divide by ifSpeed:

utilization = z / ifSpeed


<das>
      <create>
            <processor name="P1">
                  <plugin name="das.jar">
                        <class>GenericFormula</class>
                        <parameter name="delta.1">ifInOctets</parameter>
                        <parameter name="delta.2">sysUpTime.0</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.2 int.1</parameter>

                        <parameter name="op.2">divide delta.1 op.1</parameter>
                        <parameter name="op.3">multiply op.2 int.2</parameter>
                        <parameter name="op.4">multiply op.3 int.1</parameter>
                        <parameter name="op.5">divide op.4 var.1</parameter>
                        <parameter name="result.1">pctInLinkUtilization op.5</parameter>
                  </plugin>
            </processor>
      </create>
</das>

Percentage Out Link Utilization:


Step 1 Determine number of bytes sent out per second:

x = delta-OutOctets / (deltaSysUpTime / 100)

Step 2 Calculate the number of bits per second:

y = x * 8

Step 3 Multiply by 100% before dividing ifSpeed:

z = y * 100

Step 4 Divide by ifSpeed:

utilization = z / ifSpeed


<das>
      <create>
            <processor name="P1">
                  <plugin name="das.jar">
                        <class>GenericFormula</class>
                        <parameter name="delta.1">ifOutOctets</parameter>
                        <parameter name="delta.2">sysUpTime.0</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.2 int.1</parameter>

                        <parameter name="op.2">divide delta.1 op.1</parameter>
                        <parameter name="op.3">multiply op.2 int.2</parameter>
                        <parameter name="op.4">multiply op.3 int.1</parameter>
                        <parameter name="op.5">divide op.4 var.1</parameter>
                        <parameter name="result.1">pctOutLinkUtilization op.5</parameter>
                  </plugin>
            </processor>
      </create>
</das>

Percentage In Link Utilization with Configured Bandwidth:

%InLinkUtilization = delta-InOctets * 100/(bandwidth.i * interval)

Here interval is delta-sysUpTime.

int.2 is the parameter to be used for user-configurable bandwidth.


<das>
      <create>
            <processor name="P1">
                  <plugin name="das.jar">
                        <class>GenericFormula</class>
                        <parameter name="delta.1">ifInOctets</parameter>
                        <parameter name="delta.2">sysUpTime.0</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">divide delta.2 int.1</parameter>
                        <parameter name="op.3">multiply op.2 int.2</parameter>
                        <parameter name="op.4">divide op.1 op.3</parameter>
                        <parameter name="result.1">pctInLinkUtilBW op.4</parameter>
                  </plugin>
            </processor>
      </create>
</das>

6. Percentage Out Link Utilization with Configured Bandwidth

%OutLinkUtilization = delta-OutOctets * 100/(bandwidth.i * interval)

Here the interval is delta-sysUpTime.

int.2 is the parameter to be used for user configured bandwidth.


<das>
      <create>
            <processor name="P1">
                  <plugin name="das.jar">
                        <class>GenericFormula</class>
                        <parameter name="delta.1">ifOutOctets</parameter>
                        <parameter name="delta.2">sysUpTime.0</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">divide delta.2 int.1</parameter>
                        <parameter name="op.3">multiply op.2 int.2</parameter>
                        <parameter name="op.4">divide op.1 op.3</parameter>
                        <parameter name="result.1">pctOutLinkUtilBW op.4</parameter>
                  </plugin>
            </processor>
      </create>
</das>

AAA Server Plugin:

Include casAuthenTransaction in front of every attribute name.

%failures = (delta-failures.i) * 100 / (delta-failures.i + delta.successes.i)


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

Plugin class files are placed in the /plugin/das.jar file of the Cisco PerfE installation directory.

First load the plugin as follows:

<das>
      <load>
            <plugin name="das.jar"/>
      </load>
</das>

Configure Cisco PerfE to collect the required data for computation and associate the required processor component for computing the resulting data.

Sample configuration for the Delta plugin, where P1 is defined as one of the plugins described earlier:

<das>
      <create>
            <collector name="MC">
                  <MibCollector>
                        <processor name="P1"/>
                         <schedule name="MibSchedule"/>
                        <device name="MD"/>
                        <dataHandler name="MibExport"/>
                        <snmpGet>
                              <oid>sysUpTime.0</oid>
                         </snmpGet>
                        <snmpGetMany>
                              <oid>ifInOctets</oid>
                              <oid>ifOutOctets</oid>
                        </snmpGetMany>
                  </MibCollector>
            </collector>
      </create>
      <start>
            <collector name="MC"/>
      </start>
</das>

Formatter Plugin

The export file of the Mib collector contains the MIB attribute type in addition to its default output when configured with the Formatter plugin.

<das>
      <load>
            <plugin name="das.jar"/>
      </load>
      <create>
            <formatter name="F1">
                  <plugin name="das.jar">
                        <class>MibTypeFormatter</class>
                  </plugin>
            </formatter>

            <schedule name="MibSchedule">
                  <start>2002-03-06T00:00:00.000-08:00</start>
                  <interval>PT2M</interval>
                  <interTaskDelay>PT0.1S</interTaskDelay>
            </schedule>

            <device name="MD">
                  <snmp>
                        <ipaddress>10.77.21.92</ipaddress>
                        <readCommunity>public</readCommunity>
                        <writeCommunity>private</writeCommunity>
                  </snmp>
            </device>

            <dataHandler name="MibExport">
                  <formatter name="F1"/>
                        <url>
                              <prefix>ftp://guest:guest@10.77.12.94/%2Fdata/MibPeriodic</p
refix>
                        </url>
            </dataHandler>
            <collector name="MC">
                  <MibCollector>
                        <schedule name="MibSchedule"/>
                        <device name="MD"/>
                        <dataHandler name="MibExport"/>
                        <snmpGet>
                              <oid>sysUpTime.0</oid>
                        </snmpGet>
                        <snmpGetMany>
                              <oid>ifInOctets</oid>
                        </snmpGetMany>
                  </MibCollector>
            </collector>
      </create>
      <start>
            <collector name="MC"/>
      </start>
</das>

Data Export

Following is the output format of the data export file (default output without Formatter plugin).


MC,10.77.11.92,2002-10-25T11:06:00.012Z,ifOutOctets.4,1485307
MC,10.77.11.92,2002-10-25T11:06:00.012Z,ifOutOctets.3,953335
MC,10.77.11.92,2002-10-25T11:06:00.012Z,ifOutOctets.2,0
MC,10.77.11.92,2002-10-25T11:06:00.012Z,ifOutOctets.1,0
MC,10.77.11.92,2002-10-25T11:06:00.012Z,sysUpTime.0,7734066
MC,10.77.11.92,2002-10-25T11:06:00.012Z,deltaIfOutOctets.4,3326
MC,10.77.11.92,2002-10-25T11:06:00.012Z,deltaIfOutOctets.3,1464
MC,10.77.11.92,2002-10-25T11:06:00.012Z,deltaSysUpTime.0,12008
MC,10.77.11.92,2002-10-25T11:06:00.012Z,deltaIfOutOctets.2,0
MC,10.77.11.92,2002-10-25T11:06:00.012Z,deltaIfOutOctets.1,0
MC,10.77.11.92,2002-10-25T11:06:00.012Z,ifInOctets.4,4218748
MC,10.77.11.92,2002-10-25T11:06:00.012Z,ifInOctets.3,1421588
MC,10.77.11.92,2002-10-25T11:06:00.012Z,ifInOctets.2,0
MC,10.77.11.92,2002-10-25T11:06:00.012Z,ifInOctets.1,0
MC,10.77.11.92,2002-10-25T11:06:00.012Z,deltaIfInOctets.4,6899
MC,10.77.11.92,2002-10-25T11:06:00.012Z,deltaIfInOctets.3,1742
MC,10.77.11.92,2002-10-25T11:06:00.012Z,deltaIfInOctets.2,0
MC,10.77.11.92,2002-10-25T11:06:00.012Z,deltaIfInOctets.1,0
MC,10.77.11.92,2002-10-25T11:06:00.012Z,deltaSysUpTime.0,12008

Formatter plugin output:

CollectorName,DeviceAddress,Timestamp,AttributeName,AttributeValue,AttributeType
MC,10.77.11.92,2002-10-18T03:44:00.000Z,ifInOctets.16,0,Counter32
MC,10.77.11.92,2002-10-18T03:44:00.000Z,ifInOctets.15,0,Counter32
MC,10.77.11.92,2002-10-18T03:44:00.000Z,ifInOctets.14,0,Counter32
MC,10.77.11.92,2002-10-18T03:44:00.000Z,ifInOctets.12,0,Counter32
MC,10.77.11.92,2002-10-18T03:44:00.000Z,sysUpTime.0,101561860,TimeTicks
MC,10.77.11.92,2002-10-18T03:44:00.000Z,ifInOctets.9,0,Counter32

The plugin data exported by the Mib collector is in the following order:

Table 6-4 Order of the Plugin Data Exported by the Mib Collector 

Order
Parameter

1.

collector name

2.

device IP address

3.

data collection timestamp

4.

attribute name

5.

attribute value

6.

attribute type



Note All non-SNMP attributes that are derived by the Processor plugin and configured with the Formatter plugin appear with an unknown attribute type.


Threshold Processing on Plugin Data

Thresholds can be configured on the plugin data.

For example:

<threshold name="MibThreshold">
      <attribute name="deltaSysUpTime.0">
            <raiseOperation>GT</raiseOperation>
            <raiseValue>100</raiseValue>
            <clearOperation>LT</clearOperation>
            <clearValue>50000</clearValue>
            <level>critical</level>
      </attribute>
 </threshold>


Note If the delta value of any attribute is involved in computation, the first exported file contains only raw data (that is, it will not contain computed data). Subsequent collections will export both raw and computed data.



Note IntComponent must always be provided as a second operand to OpComponent. Therefore, the following format is not allowed:
<parameter name="op.3">divide int.1 op.2</parameter>



Note If the sysUpTime attribute is not present as part of the Processor plugin when a delta on some attribute needs to be calculated, the first set of delta values calculated after system reboot are not the proper values. It is recommended you poll sysUpTime so the delta values can be calculated accurately even after device reboot.


NetFlowMediator Collector

The NetFlowMediator collector collects MPLS VPN usage data for billing and reporting purposes. It collects NetFlow data from the NetFlow Flow Collector application and aggregates the data for periods up to one hour. The NetFlowMediator collector also maps the network flow data with VPN customer information through its VPNSC/ISC integration module.

Requirements

Only one instance of the NetFlowMediator collector may be configured per Cisco PerfE system.

Correct use of this collector also requires proper configuration of the VPNSC/ISC, NetFlow FlowCollector, and the NetFlow agent in IOS.

XML Configuration

The following XML tags shown in Table 6-5 can be configured for a NetFlowMediator collector:

Table 6-5 Tags in the XML Configuration for the NetFlowMediator Collector

XML Tag
Purpose
Mandatory/ Optional

aggregatePeriod

Aggregation period in minutes. The value must be between 1 and 60 minutes.

Mandatory

aggregateDataFormat

Aggregated data format: use bin or ascii.

Mandatory

VPNSC

VPNSC/ISC host machine. If the Cisco PerfE name has more than two dots, use the IP address of the VPNSC/ISC host.

Mandatory

VPNSCUser

VPNSC/ISC administrator name.

Mandatory

VPNSCPasswd

VPNSC/ISC administrator password.

Mandatory


The following is a sample XML configuration for a NetFlowMediator collector. Note the schedule ("Schedule"), devices ("dev1" and "dev2"), notifiers ("ntf1" and "ntf2"), and purger ("purger"), must be defined prior to defining the collector.

<collector name="nfc1">
      <NetFlowCollector>
            <schedule name="Schedule"/>
            <device name="dev1"/>
            <device name="dev2"/>
            <notifier name="ntf1"/>
            <notifier name="ntf2"/>
            <purger name="purger"/>
            <aggregatePeriod>60</aggregatePeriod>
            <aggregateDataFormat>bin</aggregateDataFormat>
            <VPNSC>alexrtp-u10</VPNSC>
            <VPNSCUser>admin</VPNSCUser>
            <VPNSCPasswd>admin</VPNSCPasswd>
      </NetFlowCollector>
</collector>

Data Export

The output from the NetFlowMediator collector is done on an hourly basis. The output is in a NetFlow FlowCollector file format in either binary or ASCII format. Each time an output file is created, the filesready file is updated to indicate which files have been produced. These output files can be retrieved by using FTP.

The output data files are stored using in following path and file name:

<CNS_PerfE_Home>/data/nfc/outputfiles/<NFC host name>/<RouterIP>/<Date>/MPLSVPNUsage/
<RouterIP>.<TimeStamp>

where:

<NFC host name> is the host name or IP address of the NetFlow FlowCollector, from which the data is collected

<RouterIP> is the IP address of the router

<Date> is the date on which the data was exported

<TimeStamp> is the time that the data was exported

When data is exported in ASCII format, the items in the data header are as follows:

Source—the Router IP address

Format 2

Aggregation MPLSVPNUsage

Period—the number of minutes in the period, up to 60. If the period is equal to 0, the contents of the file is a partial result. Partial results are generated when the collector is shut down but partial aggregation results exist in memory.

Start time—start time of the NetFlowCollector record

Endtime—end time of the NetFlowCollector record

Flow—the number of flows

Missed—the number of missed records

Records—the number of records.

The data that is exported in each row of the file is described in Table 6-6. If this data is exported in ASCII format, the fields are separated by a "|".

Table 6-6 Order of the Data Exported by NetFlowMediator Collector (ASCII Format)

Order
Parameter

1.

Destination Address

2.

Input

3.

TOS

4.

Packets

5.

Octets

6.

Flows

7.

Customer

8.

Site

9.

CE


You can export the data in binary format. The binary format is defined below:

typedef struct {
	/* Keys */
	u_long srcaddr;            /* Source IP */
	u_long dstaddr;            /* Destination IP */
	u_short input;		  /* interface */
	u_char tos;                /* Type of Service */
	char pad1;                  /* Data alignment */

	/* Values */
	u_long pkts;               /* Packet count */
	u_long octets;             /* Byte count */
	u_long flows;              /* Flow count */
	u_short custlength;        /* total bytes of following customer's data */

	u_short pad2; 
	char[] customer;		  /* variable length string */
	char[] site;			  /* variable length string */
	char[] ce;			  /* variable length string */
};

NFC-like filesready files are generated daily in the <CNS_PerfE_Home>/data/nfc/logs directory (filesready.<date>). This file contains the file names of output data files.

Threshold Crossing Alerts and Hotspot Polling

The NetFlowMediator collector does not support threshold crossing alerts or hotspot polling.

Purging Data

It is recommend the NetFlowMediator collector purge be run at minimum on the following schedule. Disk space usage may require that data be purged more frequently. The following purge schedule purges data every 24 hours. Each time data is purged, any data that is older than 48 hours is purged.

<purger name="purger">
      <time>2001-12-01T00:00:00.000Z</time>
      <interval>PT24H</interval>
      <delay>PT48H</delay>
</purger>

Limitations

Using the NetFlowMediator collector in conjunction with any other Cisco PerfE collector (other than the System collector) is not supported; it must be the only Cisco PerfE collector running.

Usage requires proper configuration of the following software packages:

Cisco VPN Solution Center v 2.0.0.9 or later

Cisco NetFlow FlowCollector v 3.6 or later

Cisco IOS NetFlow Agent

This collector is valid only for capturing and reporting on MPLS VPN traffic on the Cisco CNS PerfE ingress interface. There is a limitation of one VPN per PE (sub)interface.

MPLS/VPN PE-PE Traffic Reports

In Cisco CNS PerfE, 2.1, the NetFlow Mediator Collector can alternatively be used to produce MPLS/VPN PE-PE traffic reports. All Provider Edge (PE) routers in a provider network, export traffic statistics (NetFlow Data Export or NDE) to a few hosts that run the NetFlow Collection Engine (NFC). These NFCs conduct aggregation of the NDEs they receive. The NetFlow Mediator then collects the aggregation results from the NFCs and produces the reports.


Note This feature requires CNS NetFlow Collection Engine, release 5.0.


Configuration

Provider Edge (PE) Routers

On PEs, NetFlow should be enabled on all CE-facing interfaces with the following command:

Router(config-if)# ip route-cache flow

The BGP next hop field is required by this feature. To enable BGP next hop export (supported since IOS 12.0(26)S), use the following commands at the global level:

Router# ip flow-export version 9 bgp-nexthop
Router# ip flow-export destination <NFC host IP address> <NFC port number>

NetFlow Collection Engine 5.0

On the NetFlow Collection Engine host, create an aggregator with the BGP next hop as an aggregation key in <NFC Base Directory>/config/nfc-config.xml. Follow these steps:


Step 1 Add two more value builders in <value-builders> if they are not defined:

 
<sum-value id="packet-count-32-value"> 
<field>PKTS_32</field> 
</sum-value> 
 
<sum-value id="byte-count-32-value"> 
<field>BYTES_32</field> 
</sum-value> 

Step 2 Add one more key builder in <key-builders> for the BGP next hop:

 
<inetaddress-key id="bgp-next-hop-key"> 
<field>BGP_NEXT_HOP</field> 
</inetaddress-key> 

Step 3 Add one new aggregation scheme in <aggregation-schemes>:

 
<aggregation-scheme id="nexthop"> 
<keys> 
<key id="bgp-next-hop-key"/> 
</keys> 
<values> 
<value id="packet-count-32-value"/> 
<value id="byte-count-32-value"/> 
</values> 
</aggregation-scheme>

Step 4 Add the aggregator in <aggregators>:

 
<aggregator id="bgpnexthop"> 
<aggregation-scheme id="nexthop"/> 
<period-minutes>15</period-minutes> 
<port protocol="udp">8888</port> 
<writer> 
<ascii-writer> 
<use-compression>false</use-compression> 
<filename-includes-date>false</filename-includes-date> 
</ascii-writer> 
</writer> 
</aggregator> 

CNS PerfE

The following is a sample XML configuration relevant to PE-PE traffic reports:

<?xml version="1.0" encoding="UTF-8"?>
<das>
    <create>
        <schedule name="Schedule">
            <start>2001-10-25T00:00:00.000-08:00</start>
            <interval>PT15M</interval>
        </schedule>
        <device name="dev1">
            <ftp>
                <ipaddress>nfchost1</ipaddress>
                <username>nfcuser</username>
                <password>nfcuser</password>
            </ftp>
        </device>
        <device name="dev2">
            <ftp>
                <ipaddress>nfchost2</ipaddress>
                <username>nfcuser</username>
                <password>nfcuser</password>
            </ftp>
        </device>
        <threshold name="th1">
            <attribute name="sys.disk.home.usedPercentage">
       	   <raiseOperation>GT</raiseOperation>
                <raiseValue>80</raiseValue>
                <clearOperation>LT</clearOperation>
                <clearValue>70</clearValue>
                <level>minor</level>
            </attribute>
        </threshold>
        <notifier name="ntf1">
            <cns>
                <subject>cisco.mgmt.das.notifier-listener</subject>
            </cns>
        </notifier>
        <notifier name="ntf2">
            <trap>
                <ipaddress>scmrtp2-u30</ipaddress>
            </trap>
        </notifier>
        <purger name="purger">
            <time>2001-12-01T00:00:00.000Z</time>
            <interval>PT24H</interval>
            <delay>PT48H</delay>
        </purger>
        <collector name="nfc1">
            <NetFlowCollector>
		 <schedule name="Schedule"/>
	        <device name="dev1"/>
	        <device name="dev2"/>
               <notifier name="ntf1"/>
	       <notifier name="ntf2"/>
             <purger name="purger"/>
             <reports>
		  <pe-pe-traffic-matrix>
		   <pe-list-file>/tmp/cnsperfe/config/peList</pe-list-file>
		   <nfc-agg-scheme>nexthop</nfc-agg-scheme>
		  </pe-pe-traffic-matrix>
		  <reports-time-level>daily</reports-time-level>	
		</reports>
		
            </NetFlowCollector>
        </collector>
        <collector name="sys">
            <schedule name="Schedule"/>
	     <threshold name="th1"/>
            <notifier name="ntf1"/>
	     <notifier name="ntf2"/>
            <SystemCollector/>
        </collector>
    </create>
    <start>
        <collector name="nfc1"/>
        <collector name="sys"/>
      </start>
      </das>

<pe-list-file> gives the location of a file that contains IP addresses of all PEs in the provider network. Entries in NFC results that do not match any address in the list will not be included in the PE-PE traffic reports. If this file is not given here or contains no IP addresses, no filtering will be done and all entries in the NFC results will be reported. The contents of a sample PE list file are as follows (assuming 1.1.1.1, 2.2.2.2, and 3.3.3.3 are all of the PEs in the provider network):

1.1.1.1 
2.2.2.2 
3.3.3.3 

Also note that <nfc-agg-scheme> specifies results of which aggregation scheme will be obtained from the NFC hosts. The value given here should exactly match the aggregation scheme ID specified in the NFC configuration.

Output Format

The PE-PE traffic reports are in CSV format. A sample report looks as follows:

Daily PE-PE Traffic
Start: 2003-01-31T00:00:00.001
End: 2003-02-01T00:00:00.000 
Ingress\Egress,1.1.1.1,2.2.2.2,3.3.3.3
1.1.1.1,N/A,100334/135343,150343/200342
2.2.2.2,200234/250343,N/A,300344/400343
3.3.3.3,400432/500343,250645/350343,N/A

The report has header and a data matrix. The first three rows are the header. It specifies the report frequency and type and also contains start/end time stamps. Each data row reflects traffic from a certain PE, whose IP address is displayed in the first cell of the row; each data column reports traffic to a certain destination PE. The numbers displayed in the cells are the packet count and K-byte count, separated with a slash. For example, the 400432/500343 pair in the bottom row shows there are 400432 packets containing 500343 K-bytes routed from PE 3.3.3.3 to PE 1.1.1.1, on 1/31/2003. N/A means not applicable.

All reports are stored in the $DAS_HOME/data/nfc directory with the following file structure:

$DAS_HOME/data/nfc/reports/<report-time-level>/<report-type>/<report-type>.timestamp

The report time level shows how frequently reports are run. Supported frequencies are Hourly and Daily. The report type is PE-PE-traffic-matrix. The time stamp is in the following format: yyyy_mm_dd.hhmm. For instance, 2003_02_01.0000.

Reports are kept for a certain length of time, according to the <purger> configuration as shown in the sample XML.

RADIUS Collector

The RADIUS collector receives RADIUS accounting requests and returns an accounting response (an acknowledgement) for each request back to the gateway. Cisco PerfE acts as a RADIUS accounting server and the gateway acts as the client. Transactions between gateways and the RADIUS accounting server are authenticated through the use of a shared secret which is never sent over the network. A RADIUS accounting packet is encapsulated in a UDP datagram. The default UDP port on Cisco PerfE acting as the RADIUS accounting server is 1813. The UDP port is also configurable through the XML interface.

A Cisco VoIP call may consist of several call legs, where each leg represents a part of the path of a complete call. Cisco PerfE can receive start and stop accounting requests but it will only process stop requests that are sent when a call for a call leg is completed.

Each call processed through a gateway consists of an incoming and outgoing call leg. Call legs 1 and 2 represent incoming and outgoing calls for the originating gateway, while call legs 3 and 4 represent incoming and outgoing calls for the terminating gateway of a four leg call. This information is summarized in Table 6-7.

Table 6-7 Call Leg Description

Call Leg Name
Call Leg Type
Description

Answer/Telephony

1

This call leg originates from the POTS network into the gateway. The gateway answers the call from the POTS device.

Originate/VoIP

2

This call leg originates from the gateway into the IP network.

Answer/VoIP

3

This call leg originates from the IP network into the gateway. The gateway answers the VoIP call.

Originate/Telephony

4

This call leg originates from the gateway into the POTS network.


The RADIUS collector correlates the RADIUS stop data. By default, the correlation is performed based on the schedule assigned to the RADIUS collector.

The RADIUS collector settings are specified in the <CNS_PerfE_Home>/config/das.properties and include the following properties:

Table 6-8 RADIUS Collector Settings in das.properties File

Property Name
Purpose

radius.req.threads=4

Number of request processing threads.

radius.secret=cisco

Key to generate the authenticator. Deprecated setting. Recommend using XML property.


For an overview of the file format used by the RADIUS collector, see Appendix A, "RADIUS Collector Export Data File Format".

For additional information, see the "For More Information" section on page 1-9.

Requirements


Note Only one RADIUS collector can be configured on a single Cisco CNS PerfE system.


AAA broadcast accounting in Cisco Voice gateways enables AAA accounting records to be transmitted to both a Cisco PerfE and a RADIUS AAA server. Voice gateways should be configured so only stop records are sent to the RADIUS  collector because Cisco PerfE only responds to stops. All gateways sending accounting requests to Cisco PerfE should be configured with the same RADIUS secret.

XML Configuration

The RADIUS collector has the following attributes you can configure through the XML interface:

Table 6-9 Tags in the XML Configuration for the RADIUS Collector 

XML Tag
Purpose
Mandatory/ Optional

acctPort

The UDP destination port for the RADIUS server to listen to for Radius packets.

Mandatory

ageInterval

This attribute determines when to write the call legs to the RADIUS file in the <CNS_PerfE_Home>/data/radius directory if all four legs have not been received. This value should be less than the fileInterval value. The default for ageInterval is 30 seconds.

Optional

fileInterval

This attribute determines when to generate the RADIUS file. The default for fileInterval is half of the scheduleInterval.

Optional

radiusSecret

This attribute defines the RADIUS secret key value.

Optional


Sample XML configuration:

<collector name="radiusCollector">
      <radiusCollector>
            <schedule name="RADIUSSCHEDULE"/>
            <acctPort>1813</acctPort>
            <ageInterval>PT15S</ageInterval>
            <fileInterval>PT5M</fileInterval>
            <radiusSecret>cisco</radiusSecret>
      </radiusCollector>
</collector>

Schedule interval is an attribute specified in the schedule. It determines how often to generate the VoipCorrelator files. The value should be greater than the fileInterval value.

Sample XML configuration:

<collector name="radiusCollector">
      <radiusCollector>
            <schedule name="RADIUSSCHEDULE"/>
            <acctPort>1813</acctPort>
            <ageInterval>PT15S</ageInterval>
            <fileInterval>PT5M</fileInterval>
      </radiusCollector>
</collector>

Suppose ageInterval is set to 30 seconds, fileInterval is 5 minutes, and Schedule (correlation) Interval is 15 minutes.

In this case, Cisco PerfE starts aging out RADIUS stop packets at 30 seconds and flushes the CDRs to data files in the /radius directory. If fileInterval is 5 minutes, the RADIUS Collector generates an intermediate file every 5 minutes. With a schedule interval of 15 minutes, the VoIPCorrelator correlates the RADIUS/Call History/BAMS CDRs every 15 minutes.

Data Export

With Cisco PerfE, the RADIUS collector collects RADIUS accounting packets and correlates RADIUS Call Detail Records (CDR), with the correlated RADIUS CDRs written to a data file. The data is generated in comma separated values (CSV) format. The name of this file is passed to the VoipCorrelator module. The VoipCorrelator module correlates RADIUS, Call History, and BAMS call data and saves the results in flat files in the <CNS_PerfE_Home>/data/VoipCorrelator directory. The PM application should retrieve files from this directory and then delete the files.

The filenames have the format: <dasname>_<timestamp>

For example:

nfc-ultra10_D20011219T193632Z

nfc-ultra10_D20011219T193732Z


Note The files in the <CNS_PerfE_Home>/data/radius and <CNS_PerfE_Home>/data/callhistory directories are for internal use by the system. Providing an external application acces to these files will cause unexpected behavior.



Note The RADIUS collector logs CDR statistics to the <CNS_PerfE_Home>/logs/cdr.log file. This file identifies how many CDRs are written to each data file.


The XML elements for the correlated data are as follows:

<calls>
      <call id="ABCD1234 ABCD1234 ABCD1234 ABCD1234">
            <callLegCount>4</callLegCount>
            <callLeg>...</callLeg>
            <callLeg>...</callLeg>
            <callLeg>...</callLeg>
            <callLeg>...</callLeg>
            <bams>...</bams>
      </call>
</calls>

Note The call id field represents the h323-conf-id. The schema for the data files is in <CNS_PerfE_Home>/schema/calls.xsd.


Below is an example of a RADIUS data file:

<calls>
<call id="CBB9FD53 8D613DAF 0 847B65B8">
<callLegCount>2</callLegCount>
<callLeg>VoIP,answer,001B7B14,0,01068186663,1003148814335,bj-3t-rs1-
gw3.das.com.,211.93.196.232,1003148814335,1,21:26:27.663 Beijing Tue Mar 5 
2002,21:26:50.591 Beijing Tue Mar 5 2002,21:26:50.591 Beijing Tue Mar 5 
2002,10,0,211.101.116.45,0,76,0,4,0,CBB9FD53 8D613DAF 0 847B65B8, 
subscriber=Unknown|pre-bytes-in=0|pre-bytes-out=0|pre-paks-in=0|pre-paks-
out=0|nas-rx-speed=0|nas-tx-speed=0</callLeg>
<callLeg>Telephony,originate,001B7B15,0,01068186663,1003148814335,bj-3t-rs1-
gw3.das.com,,1003148814335,1,21:26:27.707 Beijing Tue Mar 5 2002,21:26:50.623 
Beijing Tue Mar 5 2002,21:26:50.623 Beijing Tue Mar 5 
2002,10,0,211.101.116.45,76,0,4,0,0,CBB9FD53 8D613DAF 0 847B65B8, 
subscriber=Unknown|h323-ivr-out=Tariff:Unknown|pre-bytes-in=0|pre-bytes-out=0|pre-
paks-
in=0|pre-paks-out=0|nas-rx-speed=0|nas-tx-speed=0</callLeg>
</call>
<call id="47D21F4A 2F7311D6 8AA48479 4B9315DF">
<callLegCount>2</callLegCount>
<callLeg>Telephony,answer,0000F516,69,02164104400,1002223061396,tj-c-
gw1.das.com,,131002908461,1,21:25:22.670 CST Tue Mar 5 2002,21:25:22.691 CST Tue 
Mar 5 2002,21:26:31.491 CST Tue Mar 5 
2002,10,0,211.101.120.10,3572,160440,133,1286,0,47D21F4A 2F7311D6 8AA48479 
4B9315DF, subscriber=RegularLine|tariff-type=Unknown|pre-bytes-in=0|pre-bytes-
out=0|pre-paks-in=0|pre-paks-out=0|connect-progress=101|nas-rx-speed=0|nas-tx-spee
d=0</callLeg>
<callLeg>VoIP,originate,0000F5AF,13,02164104400,1002223061396,tj-c-
gw1.das.com,211.101.117.53,131002908461,1,21:26:08.574 CST Tue Mar 5 
2002,21:26:18.827 CST Tue Mar 5 2002,21:26:31.507 CST Tue Mar 5 
2002,10,0,211.101.120.10,11360,1978,355,69,10,47D21F4A 2F7311D6 8AA48479 4B9315DF, 
subscriber=RegularLine|pre-bytes-in=0|pre-bytes-out=0|pre-paks-
in=0|pre-paks-out=0|connect-progress=101|nas-rx-speed=0|nas-tx-speed=0</callLeg>
</call>
<call id="CD43276A 2F7311D6 8F648479 4B9315DF">
<callLegCount>1</callLegCount>
<callLeg>Telephony,answer,0000F76B,9,00000,1002226030493,tj-c-gw1.das.com,,1002226
030493,1,21:29:06.548 CST Tue Mar 5 2002,21:29:06.570 CST Tue Mar 5 
2002,21:29:15.180 CST Tue Mar 5 2002,10,0,211.101.120.10,0,25440,0,159,0,CD43276A 
2F7311D6 8F648479 
4B9315DF,subscriber=RegularLine|tariff-type=Unknown|pre-bytes-in=0|pre-
bytes-out=0|pre-paks-in=0|pre-paks-out=0|connect-progress=101|nas-rx-speed=0|nas-
tx-speed=0</callLeg>
</call>
</calls>

Order of Call Leg Data

The data for each call leg is listed in the CSV data file in the following order:

Table 6-10 Order of the Data Stored for Each Call Leg 

Order
Parameter Name

1.

callType

2.

callOrigin

3.

sessionId

4.

sessionTime

5.

calledStationId

6.

callingStationId

7.

gatewayId

8.

remoteAddress

9.

userName

10.

serviceType

11.

setupTime

12.

connectTime

13.

disconnectTime

14.

disconnectCause

15.

nasPortType

16.

nasIpAddress

17.

inputOctets

18.

outputOctets

19.

inputPackets

20.

outputPackets

21.

voiceQuality

22.

incomingConfId

23.

vsa name-value pairs


Threshold Crossing Alerts, Purging Data, and Hotspot Polling

Cisco PerfE purges the correlated files based on the purge parameters specified in the das.properties file. However, a purger can also be configured for the RADIUS collector. In the usual operations, the PM or the NMS application should delete files after they are retrieved.

Hotspot polling, threshold processing, on-demand data export using XML interface, and periodic scheduling of data export are not supported for this collector.

Limitations

The RADIUS collector does not support RADIUS attribute 44 (Acct-Session-Id overloading). You must enable Vendor-Specific Attributes (VSAs) by using the gw-accounting h323 vsa command on voice gateways. See Appendix A, "RADIUS Collector Export Data File Format," for a list of VSAs.

SAA Collectors

SAA collectors collect performance data measured by the Service Assurance Agent (SAA) within an IOS device. They provide different types of measurements by simulating different types of protocols. SAA is used to measure performance statistics between two routers. The source router is where SAA operations are configured. The target router is usually configured with the SAA responder.

SAA collectors interact with a Cisco device that has an IOS image that supports SAA operations (not all IOS images support SAA). The SAA collector uses SNMP to control and retrieve response time information from the Cisco device. The collected data is retrieved from rtr probe, which measures data sent between a source Cisco device to a destination Cisco device. SAA collectors in general require
rtr responder to be enabled at the target device through the Command Line Interface using the
configure terminal command at the Cisco device.

SAA Collector Add/Remove Operations


Note Use SAACollectors > Modify option to add/remove operations to a device using the GUI.


Operations can be added and removed for SAA UDPEcho, IcmpEcho, and Jitter collectors.

ADD Operation

<das>

<add>

<collector name="c">

<SaaJitterCollector> ---> 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- http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/ffun_c/fcfprt3/fcf017.htm

Command Reference-
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/ffun_r/ffrprt3/frf017.htm

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.