Configuring Chassis for Mobility Unified Reporting System

This chapter describes the configurations required to source data for the MUR application.

IMPORTANT:

These configurations are on the chassis.

For more information on ECS configurations, see the Enhanced Charging Services Administration Guide.

This chapter describes the following topics:

Initial Configuration

If the configurations described in this section are not already available on the system, these must be configured.

Initial configuration steps:

  1. Ensure that ECS license is installed on the system.
  2. Create the ECS administrative user account as described in the Creating the ECS Administrative User Account section.
  3. Enable Active Charging as described in the Enabling Active Charging section.
  4. Create Active Charging Service as described in the Creating the Active Charging Service section.
  5. Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

    IMPORTANT:

    Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.

Installing the ECS License

The ECS in-line service is a licensed Cisco product. Separate session and feature licenses may be required. Contact your Cisco account representative for detailed information on licensing requirements.

For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.

Creating the ECS Administrative User Account

At least one administrative user account that has ECS functionality privileges must be configured on the system. This is the account that is used to log on and execute ECS-related commands. For security purposes, it is recommended that these user accounts be created along with general system functionality administration.

Use the following configuration example to create the ECS Administrative user account:

configure
   context
local
      administrator <user_name> password <password> ecs
      end
Notes:
  • Aside from having ECS capabilities, an ECS Administrator account also has the same capabilities and privileges as any other system-level administrator account.
  • You can also create system ECS user account for a config-administrator, operator, or inspector. ECS accounts have all the same system-level privileges of normal system accounts except that they have full ECS command execution capability. For example, an ECS has rights to execute every command that a regular administrator can in addition to all of the ECS commands.
  • Note that only Administrator and Config-administrator-level users can provision ECS functionality. Refer to the Configuring System Settings chapter of the System Administration Guide for additional information on administrative user privileges.

Enabling Active Charging

Active Charging must be enabled before configuring charging services.

Use the following configuration example to enable Active Charging:

configure
   require
active-charging
     context local
     interface <interface_name>
        ip
address <ipv4/ipv6_address> <ipv4/ipv6_address/mask>
        exit
     server
ftpd
     end

For more information, refer to the Enhanced Charging Services Administration Guide.

Creating the Active Charging Service

Use the following configuration example to create an Active Charging Service:

configure
  active-charging
service <service_name> [ -noconfirm ]
  end

Configuration

The following is the sequence of configurations necessary to source data to the MUR application:

  1. Activate P2P analyzer as described in the Activating P2P Analyzer section.
  2. Configure EDR flow format as described in the Configuring the EDR Flow Format section.
  3. Configure routing ruledefs and rulebase for deep-packet inspection as described in the Configuring Deep Packet Inspection section.
  4. Optional. Configure Smartphone tethering detection feature as described in the Configuring Tethering Detection Feature section.
  5. Configure EDR module as described in the EDR Module Configuration section.
  6. Configure user as described in the Configuring EDR Download Permission section.
  7. Configure the bulkstat schemas and then load it onto the gateway.
  8. Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.

Activating P2P Analyzer

Use the following configuration example to activate P2P protocol detection:

configure
  active-charging
service <service_name>
    p2p-detection
protocol all
    rulebase <rulebase_name>
      p2p
dynamic-flow-detection
      end
Notes:
  • P2P protocol detection must be activated only within rulebases used by the APNs for which P2P detection is applicable. P2P detection must not be applied to the rulebases used for APNs where such reporting is either not useful or is not possible.

Configuring the EDR Flow Format

Use the following configuration example to configure the EDR format generated for flows:

configure
  active-charging
service <service_name>
    edr-format <edr_format_name> [ -noconfirm ]
      attribute <attribute> { [ format { MM/DD/YY-HH:MM:SS | MM/DD/YYYY-HH:MM:SS | YYYY/MM/DD-HH:MM:SS | YYYYMMDDHHMMSS | seconds } ] [ localtime ] | [ { ip | tcp } { bytes | pkts } { downlink | uplink } ] priority <priority> }
      rule-variable <protocol> <rule> priority <priority>
      rule-variable
traffic-type priority  <priority>
      rule-variable
voip-duration priority  <priority>
      event-label <event-label> priority <priority>
      end
Notes:
  • The rule-variable traffic-type and rule-variable voip-duration keywords must be configured to enable voice-call-duration (VCD) based reporting.
  • p2p-protocol is a mandatory field in a flow-edr configurations. However, this field cannot be added to the edr-format configuration unless P2P is licensed. Contact your Cisco account representative for information on how to obtain a license.
  • For information on EDR format configuration and rule variables, refer to the EDR Format Configuration Mode Commands chapter of the Command Line Interface Reference.

The following is a sample flow end EDR configuration.

configure
  active-charging
service ecs_svc1
    edr-format edr_flow_format
      attribute sn-start-time format seconds priority 10
      attribute sn-end-time format seconds priority 20
      attribute radius-calling-station-id priority 30
      rule-variable ip server-ip-address priority 60
      attribute sn-server-port priority 70
      attribute sn-app-protocol priority 80
      attribute sn-parent-protocol priority 81
      rule-variable ip protocol priority 82
      rule-variable p2p protocol priority 90
      attribute sn-volume-amt ip
bytes uplink priority 100
      attribute sn-volume-amt ip
bytes downlink priority 110
      attribute sn-volume-amt ip
pkts uplink priority 120
      attribute sn-volume-amt ip
pkts downlink priority 130
      rule-variable bearer 3gpp charging-id priority 140
      rule-variable bearer 3gpp imei priority 141
      rule-variable bearer 3gpp rat-type priority 142
      rule-variable bearer 3gpp user-location-information priority 143
      rule-variable
traffic-type priority 160
      rule-variable
voip-duration priority 170
      end

The following is a sample HTTP EDR configuration.

configure
  active-charging
service ecs_svc1
    edr-format edr_http_format
      attribute sn-start-time format seconds priority 10
      attribute sn-end-time format seconds priority 20
      attribute radius-calling-station-id priority 30
      rule-variable ip server-ip-address priority 50
      rule-variable http host priority 70
      rule-variable http content type priority 80
      attribute transaction-downlink-bytes priority 90
      attribute transaction-uplink-bytes priority 100
      attribute transaction-downlink-packets priority 110
      attribute transaction-uplink-packets priority 120
      rule-variable bearer 3gpp charging-id priority 130
      end

Verifying your Configuration

To verify your configuration, in the Exec Mode, enter the following command:

show active-charging edr-format name <edr_format_name>

Configuring Deep Packet Inspection

This section provides the example configurations that are required for deep packet inspection.

Configuring Routing Rule Definition

Use the following configuration example to create and configure a routing ruledef:

configure
  active-charging
service <service_name>
    ruledef <ruledef_name>
      <protocol> <expression>
<operator> <condition>
        rule-application routing
        end
Notes:
  • The rule-application routing command specifies the ruledef type. If not specified, by default, the system configures the ruledef as a charging ruledef.
  • For information on all the protocol types, expressions, operators, and conditions supported, refer to the Ruledef Configuration Mode Commands chapter of the Command Line Interface Reference.
  • Up to 10 rule matches can be configured in one ruledef.
  • MMS rules must be set appropriately and MMS should be activated at ECS to support MMS reporting in MUR.

The following is a sample ruledef configuration.

configure
   active-charging
service srv1
      ruledef
http_anymatch
      http
any-match = TRUE
      exit
      ruledef
icmp_anymatch
      icmp
any-match = TRUE
      exit
      ruledef
ip_anymatch
      ip
any-match = TRUE
      exit
      ruledef
mms_anymatch
      mms
any-match = TRUE
      exit
      ruledef
rr_http_80
      tcp
either-port = 80
      rule-application
routing
      exit
      ruledef
rr_http_8080
      tcp
either-port = 8080
      rule-application
routing
      exit
      ruledef
rr_mms_http_ct
      http
content type = application/vnd.wap.mms-message
      rule-application
routing
      exit
      ruledef
rr_mms_http_url
      http
url ends-with .mms
      rule-application
routing
      exit
      ruledef
rr_mms_wsp_ct
      wsp
content type = application/vnd.wap.mms-message
      rule-application
routing
      exit
      ruledef
rr_mms_wsp_ct_uri
      rule-application
routing
      exit
      ruledef
rr_mms_wsp_url
      wsp
url ends-with .mms
      rule-application
routing
      exit
      ruledef
rr_wsp_cl_dst_port
      udp
dst-port = 9200
      rule-application
routing
      exit
      ruledef
rr_wsp_cl_src_port
      udp
src-port = 9200
      rule-application
routing
      exit
      ruledef
rr_wsp_co_dst_port
      udp
dst-port = 9201
      rule-application
routing
      exit
      ruledef
rr_wsp_co_src_port
      udp
src-port = 9201
      rule-application
routing
      exit
      end

Verifying your Configuration

To verify your configuration, in the Exec Mode, enter the following command:

show active-charging ruledef routing

Configuring Rulebase

Use the following configuration example to route traffic to the appropriate analyzer within each rulebase where the reporting is applicable.

configure
  active-charging
service <service_name>
    rulebase <rulebase_name> [ -noconfirm ]
      route
priority  <priority> ruledef <ruledef_name> analyzer <analyzer> [ description ]
      rtp
dynamic-flow-detection
      flow
end-condition handoff timeout normal-end-signaling session-end edr edr_format_name
edr transaction-complete
http edr-format edr_format_name
      end
Notes:
  • The edr and edr-format options are available only in 12.1 and earlier releases.

The following is a sample rulebase configuration.

configure
  active-charging
service ecs_svc1
    rulebase p2p-rb
      flow
end-condition handoff timeout normal-end-signaling session-end edr edr_flow_format
      action
priority 4 ruledef rtsp_setup charging-action
standard
      action
priority 5 ruledef rtsp_play charging-action
standard
      action
priority 6 ruledef rtsp_teardown charging-action
standard
      action
priority 7 ruledef rtsp_anymatch charging-action
standard
      action
priority 10 ruledef sip_anymatch charging-action
handshake
      action
priority 11 ruledef rtp_anymatch charging-action
handshake
      action
priority 12 ruledef udp_anymatch charging-action
handshake
      action
priority 13 ruledef tcp_anymatch charging-action
handshake
      action
priority 16 ruledef mms_anymatch
charging-action policy1
      action
priority 60 ruledef http_anymatch
charging-action standard
      action
priority 95 ruledef udp_anymatch
charging-action standard
      action
priority 99 ruledef icmp_anymatch
charging-action standard
      action
priority 100 ruledef ip_anymatch charging-action
handshake
      action
priority 990 ruledef tcp_anymatch charging-action
standard
      action
priority 1000 ruledef ip_anymatch charging-action
standard
      route
priority 1 ruledef rr_wsp_co_src_port analyzer wsp-connection-oriented
      route
priority 2 ruledef rr_wsp_co_dst_port analyzer wsp-connection-oriented
      route
priority 3 ruledef rr_wsp_cl_src_port analyzer wsp-connection-less
      route
priority 4 ruledef rr_wsp_cl_dst_port analyzer wsp-connection-less
      route
priority 5 ruledef rr_http_80 analyzer http
      route
priority 6 ruledef rr_http_8080 analyzer http
      route
priority 7 ruledef rr_mms_http_ct analyzer mms
      route
priority 8 ruledef rr_mms_http_url analyzer mms
      route
priority 9 ruledef rr_mms_wsp_ct analyzer mms
      route
priority 10 ruledef rr_mms_wsp_url analyzer mms
      route
priority 11 ruledef rr_mms_wsp_ct_uri analyzer mms
      route
priority 60 ruledef sip_src analyzer sip
      route
priority 65 ruledef sip_dst analyzer sip
      route
priority 70 ruledef rtsp_src analyzer rtsp
      route
priority 75 ruledef rtsp_dst analyzer rtsp
      route
priority 250 ruledef sdp_route analyzer sdp
      rtp
dynamic-flow-detection
      edr
transaction-complete http edr edr_http_format
      edr
voip-call-end edr edr_flow_format
      udr
threshold interval 60
      udr
threshold volume total 100000
      p2p
dynamic-flow-detection
      end

Verifying your Configuration

To verify your configuration, in the Exec Mode, enter the following command:

show active-charging rulebase name <rulebase_name>

Configuring Charging Action

Use the following configuration example to configure a charging action:

configure
  active-charging
service <service_name>
    charging-action <charging_action_name> [ -noconfirm ]
      content-id <content_id>
      retransmissions-counted
      billing-action [ edr <edr_format> [ wait-until-flow-ends ] | egcdr | exclude-from-udrs | radius ] +
      flow
idle-timeout <idle_timeout>
      end

Verifying your Configuration

To verify your configuration, in the Exec Mode, enter the following command:

show active-charging charging-action name <charging_action_name>

Configuring Tethering Detection Feature

This section describes how to configure the Tethering Detection feature to detect subscriber flows from PC devices tethered to mobile smartphones. For details on how this feature is implemented, see the Enhanced Charging Services Administration Guide.

To enable and configure the Tethering Detection feature, use the following configuration:

configure
   active-charging
service <ecs_service_name>
      tethering-database [ os-signature <os_signature_db_file_name> | tac <tac_db_file_name> | ua-signature <ua_signature_db_file_name> ] +
      ruledef <tethering_detection_ruledef_name>
         tethering-detection { flow-not-tethered | flow-tethered }
         exit
      rulebase <rulebase_name>
         tethering-detection [ os-db-only | ua-db-only ]
         action
priority <priority> ruledef <tethering_detection_ruledef_name> charging-action <charging_action_name>
         ...
         end

Upgrading Tethering Detection Databases

To upgrade the Tethering Detection feature databases, in the Exec mode, use the following CLI command:

upgrade tethering-detection
database { all | os-signature | tac | ua-signature } [ -noconfirm ]

Sample Configurations

The following examples illustrate two different implementations of the Tethering Detection feature’s configuration.

  • The following type of configuration is suitable where ECS performance is critical and the operator wants to put in a flat charging plan in place for all the tethered traffic. In such a scenario, addition of a single new ruledef to the configuration suffices. Placing this ruledef at the highest priority in the rulebase will ensure all the tethered flows are charged as per the tariff plan for tethered traffic.
    configure
    
       active-charging
    service ecs_service
    
          tethering-database
    
          ruledef
    tethered-traffic
    
             tethering-detection
    flow-tethered
    
             tcp
    any-match = TRUE
    
             exit
    
          ruledef
    ftp-pkts
    
             ftp
    any-match = TRUE
    
             exit
    
          ruledef
    http-pkts
    
             http
    any-match = TRUE
    
             exit
    
          ruledef
    tcp-pkts
    
             tcp
    any-match = TRUE
    
             exit
    
          ruledef
    ip-pkts
    
             ip
    any-match = TRUE
    
             exit
    
          ruledef
    http-port
    
             tcp
    either-port = 80
    
             rule-application
    routing
    
             exit
    
          ruledef
    ftp-port
    
             tcp
    either-port = 21
    
             rule-application
    routing
    
             exit
    
          charging-action
    premium
    
             content-id
    1
    
             retransmissions-counted
    
             billing-action
    egcdr
    
             exit
    
          charging-action
    standard
    
             content-id
    2
    
             retransmissions-counted
    
             billing-action
    egcdr
    
             exit
    
          rulebase
    consumer
    
             tethering-detection
    
             action
    priority 10 ruledef tethered-traffic charging-action premium
    
             action
    priority 20 ruledef ftp-pkts charging-action standard
    
             action
    priority 30 ruledef http-pkts charging-action standard
    
             action
    priority 40 ruledef tcp-pkts charging-action standard
    
             action
    priority 50 ruledef ip-pkts charging-action standard
    
             route
    priority 80 ruledef http-port analyzer http
    
             exit
    
          rulebase
    default
    
          end
    
  • The following type of configuration is suitable when operators want to apply differentiated charging to various flows that are found to be tethered. In this case, traffic that requires different charging action or content ID when it is tethered will be identified using two ruledefs, one with “flow-is-tethered = TRUE” option and another without this option. This configuration provides finer granularity of control but results in higher performance degradation because the rule matching tree size increases.
    configure
    
       active-charging
    service ecs_service
    
          tethering-database
    
          ruledef
    ftp-pkts
    
             ftp
    any-match = TRUE
    
             exit
    
          ruledef
    ftp-pkts-tethered
    
             ftp
    any-match = TRUE
    
             tethering-detection
    flow-tethered
    
             exit 
    
          ruledef
    http-pkts
    
             http
    any-match = TRUE
    
             exit
    
          ruledef
    http-pkts-tethered
    
             http
    any-match = TRUE
    
             tethering-detection
    flow-tethered 
    
             exit
    
          ruledef
    tcp-pkts
    
             tcp
    any-match = TRUE
    
             exit
    
          ruledef
    tcp-pkts-tethered
    
             tcp
    any-match = TRUE
    
             tethering-detection
    flow-tethered
    
             exit
    
          ruledef
    ip-pkts
    
             ip
    any-match = TRUE
    
             exit
    
          ruledef
    ip-pkts-tethered
    
             ip
    any-match = TRUE
    
             tethering-detection
    flow-tethered
    
             exit
    
          ruledef
    http-port
    
             tcp
    either-port = 80
    
             rule-application
    routing
    
             exit
    
          ruledef
    ftp-port
    
             tcp
    either-port = 21
    
             rule-application
    routing
    
             exit 
    
          charging-action
    premium-http
    
             content-id
    10
    
             retransmissions-counted
    
             billing-action
    egcdr
    
             exit
    
          charging-action
    premium-ftp
    
             content-id
    20
    
             retransmissions-counted
    
             billing-action
    egcdr
    
             exit
    
          charging-action
    premium
    
             content-id
    1
    
             retransmissions-counted
    
             billing-action
    egcdr
    
             exit
    
          charging-action
    standard
    
             content-id
    2
    
             retransmissions-counted
    
             billing-action
    egcdr
    
             exit
    
          rulebase
    consumer
    
             tethering-detection
    
             action
    priority 10 ruledef ftp-pkts-tethered charging-action premium-ftp
    
             action
    priority 20 ruledef ftp-pkts charging-action standard
    
             action
    priority 30 ruledef http-pkts-tethered charging-action premium-http
    
             action
    priority 40 ruledef http-pkts charging-action standard
    
             action
    priority 50 ruledef tcp-pkts-tethered charging-action premium
    
             action
    priority 60 ruledef tcp-pkts charging-action standard
    
             action
    priority 70 ruledef ip-pkts-tethered charging-action premium
    
             action
    priority 80 ruledef ip-pkts charging-action standard
    
             route
    priority 80 ruledef http-port analyzer http
    
             exit
    
          rulebase
    default
    
             end
    

EDR Module Configuration

Use the following configuration example to configure the EDR module:

configure
  context <context_name>
    edr-module
active-charging-service 
      file
name <file_name> rotation volume <file_size_bytes> rotation time <file_complete_seconds> rotation num-records <records_number> storage-limit <storage_limit_bytes> headers reset-indicator
edr-format-name trap-on-file-delete compression gzip file-sequence-number
rulebase-seq-num
      cdr [ push-interval <interval> | remove-file-after-transfer | transfer-mode { pull | push
primary { encrypted-url <enc_url> | url <url> } [ secondary { encrypted-secondary-url <enc_sec_url> | url <sec_url> } ] } + | use-harddisk ]
      end
Notes:
  • The <context_name> must be the context specified for accounting.
  • The cdr use-harddisk command is only available on the ASR 5000 platform.
  • The cdr use-harddisk command specifies storing files on the hard disk. The reporting server will download these files through the SPIO interface on the SMC and will delete the files after successful retrieval.
  • The edr-format-name keyword must be configured to distinguish between different EDRs. The EDR file name must be configured in an accepted format so that the Offline Subscriber Reporting functionality can be used effectively. For information on this functionality and the EDR file name configuration recommendations, see the Cisco Mobility Unified Reporting System Online Help documentation.
  • The files will be compressed to save storage and transmission bandwidth.
  • For the PULL model, an external device like L-ESS is used to pull the EDR files from the chassis via SFTP. Whereas, for the PUSH model, the chassis is configured to push the files to the required destination.

    IMPORTANT:

    The chassis automatically creates /edr and /udr directories on the destined path on MUR server when you configure it to push the files.

  • The values recommended for rotation volume and rotation time keywords are 40 MB and 300 seconds respectively.

IMPORTANT:

In RHEL-based deployments, L-ESS is NOT required as the Enhanced Charging Services (ECS) module can be configured to push the xDRs directly to the MUR reporting server. Push from ASR chassis is the Cisco recommended deployment model. Currently L-ESS is supported only on Solaris platforms. For information on the L-ESS installation instructions, refer to the ESS Installation and Administration Guide. Existing deployments where L-ESS is installed, to pull EDRs from chassis, may continue with their deployment model in the 12.0 version of MUR Software Release and later.

The following is a sample EDR PUSH configuration.

configure
 context test
  edr-module
active-charging-service
    file
name EDRFILE rotation
num-records 10000 storage-limit 268435456 headers
reset-indicator trap-on-file-delete compression gzip file-sequence-number
rulebase-seq-num
    cdr
transfer-mode push primary url  sftp://root:nulink@10.4.72.54/inpilot-local/Ash_Test/starbi/server/data
via local-context
    cdr
push-interval 60
    cdr
remove-file-after-transfer
    cdr
use-harddisk
    end

The following is a sample EDR PULL configuration.

configure
 context local
  edr-module
active-charging-service 
    file
name EDRFILE1 rotation
time 300 rotation
num-records 10000 storage-limit 268435456 headers
reset-indicator trap-on-file-delete compression gzip file-sequence-number
rulebase-seq-num
    cdr
remove-file-after-transfer
    cdr
use-harddisk
    end

Verifying your Configuration

To verify your configuration, in the Exec Mode, enter the following command:

show configuration context <context_name>

Pushing EDR/UDR Files Manually

To manually push EDR/UDR files to the configured L-ESS, in the Exec mode, enter the following command:

cdr-push { all | local-filename <file_name> }
Notes:
  • Before you can use this command, in the EDR/UDR Configuration Mode, the CDR transfer mode and file locations must be set to push.
  • <file_name> must be absolute path of the local file to push.

For more information on the cdr command, please refer to the Command Line Interface Reference.

Configuring EDR Download Permission

Use the following configuration example to configure EDR download permission:

configure
  context
local
    administrator <administrator_id> password <password> ftp nocli
    end
Notes:
  • The user must be configured in the local context with administrative privileges to download and delete EDRs from the hard disk. The ftp nocli options restrict access to FTP only.

Configuring Bulkstats Schemas Using GUI

MUR provides a user interface to configure bulk statistics schemas on chassis / gateway via SSH and SFTP. The Client sends HTTP request to MUR to configure schemas on a particular gateway after providing inputs to the parameters needed for schema configuration. MUR server receives the HTTP request, generates a configuration file on the fly, sends the configuration file to the gateway via SFTP and loads it on to the gateway through SSH.

IMPORTANT:

In StarOS 10.0 and earlier releases, WEM is used to configure the bulkstats schemas on the chassis if user has deployed WEM. In case if WEM has not been deployed, then please contact your Cisco account representative for obtaining the embedded bulkstats configuration file.

IMPORTANT:

In StarOS 11.0 and later releases, you can configure Bulkstat schemas only through the MUR GUI by selecting ADMIN > BULKSTATS menu.

Prior to configuring the bulkstats schemas, ensure that the following checks are performed:
  • The gateway must be running and active.
  • Enable SFTP and FTP servicesFor Solaris setup:
    • FTP must be enabled on the MUR server.To enable the FTP daemon, use the following command:/usr/sbin/svcadm/ enable ftpTo disable the FTP daemon, use the following command:/usr/sbin/svcadm/ disable ftp
    For RHEL setup:
    • FTP must be enabled on the MUR server.To enable the FTP daemon, use the following command:service vsftpd startTo disable the FTP daemon, use the following command:service vsftpd stop
  • SSH version 2.0 key must be generated on the gateway. To generate the SSH version 2.0 key through the CLI, enter the following command:
    configure
    
      context
    local
    
        ssh
    generate key type v2-rsa 
    
        ssh
    generate key type v2-dsa 
    
        end
    
  • Secure Shell (SSH) configuration mode must be enabled on the gateway. To enable the SSH configuration mode, enter the following command:
    configure
    
      context
    local
    
        server
    sshd
    
        end
    
  • FTP/SFTP must be allowed on the gateway for the “SSH Username” that will be entered in the Bulkstat Schema Configuration screen. For example, if the username is staradmin and password is test then the following commands should be used to enable FTP/SFTP for staradmin user.
    configure
    
      context
    local
    
        administrator
    staradmin password test ftp 
    
        end
    

IMPORTANT:

The bulkstats report will be visible to users only when the schemas are configured successfully.

For information on how to configure the bulkstats schemas, see the Cisco Mobility Unified Reporting System Online Help documentation.

Supported Bulkstat Schemas

This section provides the list of bulk statistics schemas that are supported in MUR for reporting.
  • SS7RD
  • MME
  • SGW
  • MIPV6HA
  • PGW
  • IMSA
  • NAT_REALM
  • ASNGW
  • PORT
  • SGSN
  • MISC
  • CARD
  • MIPFA
  • GTPP
  • PHSGW
  • CSCFINTF
  • RADIUS
  • APN
  • CLOSEDRP
  • LAC
  • SGTP
  • IPPOOL
  • SCCP
  • GPRS
  • SS7LINK
  • CSCF
  • MAG
  • CONTEXT
  • SYSTEM
  • ECS
  • PHSPC
  • EGTPC
  • RP
  • PPP
  • MIPHA
  • PDG
  • GTPC
  • PDIF
  • IPSG
  • LMA
  • AAL2
  • ALCAP
  • ASNPC
  • BCMCS
  • CS_NW_RANAP
  • CS_NW_RTP
  • DCCA
  • DPCA
  • GTPU
  • HNBGW_HNBAP
  • HNBGW_RANAP
  • HNBGW_RTP
  • HNBGW_RUA
  • HNBGW_SCTP
  • LNS
  • PCC_POLICY
  • PCC_QUOTA
  • PCC_SERVICE
  • PCC_SP_ENDPT
  • PS_NW_RANAP
  • MVS

For more information on these bulkstats, refer to the Statistics and Counters Reference.

All the bulkstats counters mentioned in the Statistics and Counters Reference for particular schema might not be present due to the limitation of ASR 5K bulkstat implementation.

Supported SNMP Traps

The alarm generation feature aids in proactively monitoring the nodes and important resources of MUR. This feature also provides configuration interface for setting up thresholds and other key information related to critical resources. Alarms are generated when these thresholds are exceeded and various actions can be performed such as sending e-mail, syslog messages, Simple Network Management Protocol (SNMP) traps.

It is necessary to configure the SNMP manager or Network Node Manager (NNM) to receive these notifications. The SNMP server and SNMP event configurations can be made through the System menu in the Web-based MUR GUI.

Threshold values should be configured for the following event identifiers (event IDs):
  • CPU Usage - CPU — This alarm is generated when the CPU resource usage exceeds the preset threshold value.
  • Disk Usage - Disk — This alarm is generated when the disk usage exceeds the threshold.
  • Memory (Swap) Usage - Mem — This alarm is generated when the memory swap usage exceeds the threshold.
  • Unprocessed Files - UnprocFiles — This alarm is generated when the count of (HTTP-EDR/EDR/CF-EDR) files pending for getting parsed (in their respective directories), exceeds the threshold value.
  • Erroneous Files - ErrFiles — This alarm is generated whenever the count of invalid files exceeds the threshold value. The file is considered as invalid either due to missing headers or the file being corrupted.
  • Erroneous Records - ErrRecords — This alarm is generated when the number of erroneous records breaches the threshold. The EDR records are considered as erroneous when any of the fields are missing in the EDR or when an invalid data is present in a particular field.
In addition to this, MUR also supports AppStatus and TaskLag event identifiers; however, these are NOT configurable.
  • Application Status - AppStatus — This alarm is generated when the MUR application is started or stopped.

    IMPORTANT:

    Please note that the alarms are sent when Scheduling server/Apache server is started or stopped. However, in the case of Postgres server, alarms are sent only when it is started.

  • Task Lag - TaskLag — This alarm is generated when a particular script like normalization/aggregation takes more time than expected to complete the job.The following scripts have been added for the Task Lag alarms, which play an important role in parsing EDR/HTTP-EDR/CF-EDR. Each of these scripts handle a specific task which is either part of aggregation or normalization.
Script Default Value of Tasklag Time (in sec/min)
Edr Normalization 300 (5 min)
Http Edr Normalization 300 (5 min)
CF Edr Normalization 300 (5 min)
Protocol Summary 1800 (30 min)
Port Aggregation 1800 (30 min)
Subscriber Aggregation (minutely) 1800 (30 min)
Subscriber Aggregation (hourly) 3600 (60 min)
Flow Count 1800 (30 min)
Http Host Aggregation (minutely) 7200 (120 min)
Http Content Summary 7200 (120 min)
Http Host Aggregation (hourly) 7200 (120 min)


IMPORTANT:

Please note that the user does not have the privilege to change these timings.

Note that these alarms (Unprocessed, Error Files, Error Records and TaskLag) can be triggered only for EDR, HTTP-EDR and CF-EDR files, and not for the bulkstats files.

  • Authentication failed for the host
  • SSH negotiation failed while connecting to the host
  • Remote Host not defined
  • Socket timed out while setting up connection
  • Directory creation failed on Master
  • Removing the file at RDP failed

IMPORTANT:

During a fresh installation of MUR, please note that there will no SNMP configurations available.

IMPORTANT:

Users with administrative privilege can only manage this configuration.

IMPORTANT:

The change in the configuration for enabling / disabling the alarm generation feature does not require a restart of the MUR application.

MUR also supports generation of KPI alarms through the GUI. KPI parser calculates the values of KPIs for which the alarms are configured through the GUI. The KPI parser uses the information stored by bulkstat parser in the database for KPI calculations and for sending alarms. This avoids reparsing of the same file and redundant connections to the DB.

KPI parser generates alarms only when the alarm functionality is enabled for MUR. The details of KPI alarms which are successfully sent can be seen through KPI Alarms Log under the System menu. For details on the log, see the Cisco Mobility Unified Reporting System Online Help documentation.

IMPORTANT:

Prior to configuring KPI alarms, you must ensure that the gateways and bulkstat schemas are configured and the bulkstats data are available.

IMPORTANT:

In the case of HA mode installation, the floating IP will be used for sending SNMP V1 alarms. For V2, there is no way to explicitly set the agent ip-address. Hence, it will still use the local node IP for sending V2 alarms.

For information on configuring the SNMP parameters, see the Cisco Mobility Unified Reporting System Online Help documentation.

For information on the SNMP traps and thresholds supported for MUR, see the Mobility Unified Reporting System MIB chapter of the SNMP MIB Reference.