Mobility Unified Reporting System Overview

This chapter provides an overview of the Mobility Unified Reporting (MUR) application.

This chapter describes the following topics:

Introduction

The Cisco Mobility Unified Reporting (MUR) system is a Web-based application providing a unified reporting interface for diverse data from Cisco Systems In-line service and storage applications.

The MUR application enables:
  • Generating customized reports and comparison charts.
    This release of MUR supports generating HTML-based historical canned reports displaying data in graphical—graphs/charts—and tabular formats. Reports for ad-hoc periods are not supported. For information on the various reports supported, see the Report Types section.
  • Analyzing the reporting data and enabling the operator to get a full understanding of the performance of the network, enabling operators to optimally configure and plan their network.
  • Supporting distributed installation which allows to view reports from multiple sites.
  • Rich visualization (Graphs/tabular form).
  • Exporting reports in Microsoft Excel, Adobe PDF, and CSV formats.
  • Report scheduling, notification, and distribution. The report notification can be in the form of alarms/traps.
    In this release, MUR supports sending e-mails to registered users’ IDs for all the alarms including the KPI alarms.
  • Capacity monitoring and planning of system supporting a suite of products such as PDSN, GGSN, SGSN, and inline service applications like Content Filtering, Stateful Firewall, Application Detection and Control (ADC).

The MUR application is available for report generation only when you install the software application on to your local server. For information on the server recommendations, refer to MUR System Requirements section in this guide. For information on how to install the MUR application, refer to the Managing Mobility Unified Reporting System Installation chapter in this guide.

The MUR application provides comprehensive and consistent set of statistics and customized reports, report scheduling and distribution from ASR chassis / in-line service product. For example, a subscriber's Quality of Experience, top 10 sites visited, top 10 users, and so on.

The MUR application provides reporting capability for Content Filtering (CF) data, bulk statistics, Key Performance Indicators (KPIs), EDR data from in-line service and storage applications. The MUR application facilitates and enhances the operators’ ability to simply and easily determine the health and usage of the network.

The chassis directly pushes the bulkstat files and EDR data to the reporting server through SFTP. MUR receives the input data from the chassis only when the Enhanced Charging Services (ECS) module is enabled and configured to generate reporting EDRs. To enable this, you must purchase and install ECSv2 license on the chassis.

IMPORTANT:

In RHEL-based deployment of MUR, L-ESS is NOT required as the ASR chassis 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 the chassis, may continue with their deployment model in the 12.0 version of MUR Software Release and later.

For information on obtaining and installing the license, see System Administration Guide and Enhanced Charging Services Administration Guide. For information on configuring the ECS module, see Configuring Chassis for Mobility Unified Reporting System chapter in this guide.

MUR receives the following types of EDRs for report processing:
  • CF-EDRs
  • Flow EDRs
  • HTTP EDRs

To reduce disk space and improve performance, MUR limits the bucket distribution for EDR data to ONLY last 2 days in case a EDR is spanning across more than 2 days or so.

For example, if the following EDR is received:

#sn-start-time,sn-end-time,radius-calling-station-id,ip-subscriber-ip-address,sn-subscriber-port,ip-server-ip-address,sn-server-port,sn-app-protocol,p2p-protocol,traffic-type,voip-duration,sn-volume-amt-ip-bytes-uplink,sn-volume-amt-ip-bytes-downlink,sn-volume-amt-ip-pkts-uplink,sn-volume-amt-ip-pkts-downlink,bearer-3gpp
rat-type,radius-called-station-id,bearer-3gpp imei,ip-protocol,bearer-3gpp
sgsn-address,sn-flow-start-time,sn-flow-end-time 1275330600,1275334200,9689944191,19.19.1.1,35111,1.1.1.1,21,8,,,0,52428800,1048576,100,200,1,apn.org1,35302703-090362-52,6,1.1.1.3,1275330600,1275334200

MUR determines the difference between the starttime and endtime attributes and limits the bucket distribution as shown here.

#starttime,endtime,protocol,rxbytes,txbytes
2011/02/26 10:00:00,2011/02/28 10:00:00,HTTP,100MB,100MB

IMPORTANT:

The bucket distribution calculation will remain intact i.e. the volume will be distributed equally among all the half-hour’s buckets that fall in the starttime and endtime.

IMPORTANT:

The MUR receives the data in terms of EDRs which are generated based on the flow. As the EDRs are flow-based and the bulkstats is a real-time data, the volumes reported in the EDR are different from the volumes reported by bulkstats.

For more information on using the MUR application to generate reports, see the Cisco Mobility Unified Reporting System Online Help documentation.

Report Types

The MUR application supports generation of canned statistical reports that can be used to analyze network performance, and decide the policies for users, and identify the customer trends, network usage patterns, network categorization, etc. The reports can be per gateway, or multiple gateways (region), or for the overall network. The reports can be generated for the usage of different entities such as gateway, content type, etc on an hourly, daily, weekly, or monthly basis.

The typical canned reports that are supported for the MUR application include:
  • Historical summary reports (Daily/Weekly/Monthly)
    • Half-hourly Reports: Usage reporting for the specified time period
    • Daily Reports: Usage reporting for the past 24-hour period (midnight through midnight)
    • Weekly Reports: Usage reporting for the past seven day period (Monday through Sunday)
    • Monthly Reports: Usage reporting for the past 30-day period (1st day of the month through the last day of the month)
  • Top “N” Reports
  • Statistical and analytical reports
  • Bulkstats and KPI reports
The static report layout comprises the following sections:
  • The report name
  • The report ownership: the user account that requested the report
  • The date and time of generation
  • The list of report parameters
  • The chart legend (displayed under the chart)

On the interactive layout the user can set a series of preferences in a specific manner. The user has the flexibility to change the type of chart from Bar to Pie (supported output types depend on the selected report). Changing the preferences like the chart type or report parameters will cause the report to refresh in the same window.

The interactive chart layout provides the following list of features:
  • Tool tip: When the mouse pointer stops over a chart series, after a short time a tool tip is displayed showing the information of the targeted sample.
  • Dynamic legend: The legend is located beneath the chart and is used to recognize the series plotted on the screen. In case of series representing either network services or subscriber packages, the colors are bound to the service/package names. This means that, for example, the HTTP Service will be rendered with a specific color for the reports. The legend is usually displayed with check-boxes associated to each color.
The MUR application provides the following reports:
  • Traffic Analysis Report: The Traffic Analysis report provides the total usage traffic (including uplink and downlink traffic) details for the following application categories:
    • Video
    • Filesharing
    • Web
    • IM
    • VOIP
    • Standard
    • Streaming
    • Tunnel
    • Gaming
    • Unclassified
    MUR supports traffic type detection for P2P protocols such as Skype, Gtalk, MSN, Yahoo, and Oscar with the use of “traffic-type” attribute present in the EDR fields. Based on the value of this EDR attribute, the data will be classified to respective protocols.
    The usage traffic is expressed in terms of megabytes (MB) or Megabits per second (Mbps) and percentage (%). The traffic can also be in gigabytes (GB) / kilobytes (KB) / bytes depending on the magnitude.
  • Traffic Distribution Report: The Traffic Distribution report provides the summary of total traffic distribution for all the protocols application categories over a specified time period. The usage traffic is represented in GB/MB/KB/Bytes and percentage.
  • Active Flow Count Report: The Active Flow Count report provides the details of traffic distribution flow count against the different application categories. This report also provides the summary of maximum number of flows in the EDR records.

    IMPORTANT:

    Active Flow Count report for current date will not be available because daily tables used to fetch this report are generated only at the end of the day. Also when the user selects a date range, for example, 10/1/2011 to 10/5/2011 where 10/5/2011 is the current date, then the report will be shown for the period 10/1/2011 to 10/4/2011 i.e. up till 10/4/2011.

    Release 12.2 onwards, the Active Flow Count report will show flow counts for a sample/bucket (as per the configured granularity) that has maximum number of flows for selected filters in flow count summary. This new behavior is applicable to data ONLY after upgrading MUR to 12.2 version. Previous data will be shown as per the old reporting behavior.
  • Unique Subscriber Hits Report: The Unique Subscriber Hits report provides an overview of the usage patterns of the entire subscriber population per protocol, for example, how many people are actually using VoIP.

    IMPORTANT:

    Unique Subscriber Hits report can be generated ONLY for a single date/week/month and not for any date-range. Also, note that the time selection is also disabled for this report.

    Typically, this report provides the total number of times a subscriber is using a specific protocol. These reports are displayed for all configured gateways.

    IMPORTANT:

    Unique Subscriber Hits report for current date will always be available on the subsequent date because unique subscribers hits calculation will be performed at the end of the day.

  • TopN versus Total Traffic Report: This report provides the summary of total usage traffic and Top N subscriber traffic for all the protocols over a specified time period. The usage traffic is represented in GB/MB/KB/Bytes and packets.
  • TopN Subscribers Report: The TopN Subscribers report simply counts the number of bytes per subscriber for different time intervals. It displays the top 10/100/1000 subscribers for each day/week/month. This report is displayed across all configured gateways, per region or per NOC.

    IMPORTANT:

    This report is not available for a multiple date range selection.

    After identifying the total amount of transferred data per subscriber, and identifying the top users, to understand the protocol and services breakdown for each subscriber, this report allows listing the different applications used by the top 10/100/1000 subscribers based on the selection of top subscriber per day/week/month.
  • TopN VCD Subscribers Report: The TopN Voice Call Duration (VCD) Subscribers report displays the top N subscribers based on their voice usage (voice duration) for Yahoo, MSN and Skype voice protocols. The summary report displays the voice summary (voice duration) for VoIP category.

    IMPORTANT:

    This report is also available per week or month.

  • Weekly Report: The weekly report provides details of the following:
    • Total traffic
    • Total traffic by category
    • VOIP Call Duration
    • Total unclassified traffic (TCP and UDP)
    • Top N subscribers
  • Monthly Report: The monthly report provides the details of total traffic across the top N protocols / application categories in a month.
  • Custom Reporting: MUR supports on-demand offline reporting of subscriber specific information to operators. This ad-hoc request could be a subscriber search request or top N search request.
    Offline Subscriber Report: The MUR aids in searching individual subscribers’ data based on certain parameters like IMSI, MSISDN, NAI, IMEI and Public and Private (NAT) subscriber IP address with ports, individually or in combination, and generates a subscriber-specific report showing the list of URLs visited by the subscriber, and other details like QoS, usage traffic, aggregate application/protocol breakdown, etc for the specified time period. MUR mainly supports this search functionality to track a subscriber or a set of subscribers for lawful intercept.
    To use this Offline Reporting feature seamlessly, you must configure the EDR Filename Format appropriately through the Gateway configuration from ADMIN tab, and organize the archive directory date-wise. For information on how to manage the archive directory, see the Managing Archive Directory section in the MUR Administration and Management chapter of this guide.
    Offline Top N Subscribers Report: MUR also facilitates to generate an offline report that covers the % of volume/duration used by top n% subscribers. This report provides information on the absolute number of subscribers and the list of MSISDNs to facilitate correlation with the provisioning data. In this release, this ad-hoc report is available per APN group, Device Group, Location Group, and Service Profile.
    Through this custom TopN reporting feature, it is possible to monitor and report the video traffic usage as and when needed. This report is mainly required to identify TopN hosts for video traffic and also to determine the biggest sources of video traffic, which drives the network load at a greater extent.
    HTTP content type will be used to identify the video traffic. Ideally video traffic should be derived from flow-EDRs. Since the video usage monitoring report is generated based on HTTP content type, only HTTP traffic will be counted.
    For more information on these features, see the Cisco Mobility Unified Reporting System Online Help documentation.
    Reports based on Tethering Configuration: Tethering refers to the use of a mobile smartphone as a USB dongle/modem to provide Internet connectivity to PC devices (laptops, PDAs, tablets, and so on) running on the smartphone's data plan. Typically, for smartphone users, most operators have in place an unlimited data plan, the usage of which is intended to be from the smartphone as a mobile device. However, some subscribers use the low cost / unlimited usage data plan to provide Internet connectivity to their laptops in places where normal Internet connection via broadband/WiFi may be costly, unavailable, or insecure.
    The ASR chassis works in conjunction with the MUR application to facilitate tethering detection on the chassis. The EDRs generated by the chassis will be enhanced to include OS signatures.
    MUR processes flow-EDR files containing OS signature and IMEI field, HTTP files containing OS signature, User Agent, and IMEI field, and populates the tethering data in database files.
    For more information on this feature, see the Cisco Mobility Unified Reporting System Online Help documentation and Enhanced Charging Services Administration Guide.
  • DPI Report: The Deep Packet Inspection (DPI) reports are the canned statistical reports at the gateway level and region level. You can configure the MUR application to generate the reports for any of the available gateways.
    In this release, MUR supports generating daily, weekly and monthly summary details and busy hour traffic usage details for the following report categories:
    • Traffic Analysis Report
    • Traffic Distribution Report
    • Active Flow Count Report
    • Unique Subscribers Hits Report
    • TopN Reports — Report on Top N vs Total Traffic, TopN subscribers, TopN VCD subscribers

    IMPORTANT:

    Release 12.2 onwards, users with only administrative privileges can decrypt the subscriber’s MSISDN to make it appear in the clear text format in the weekly reports.

    MUR has the capability to report the following details per protocol:
    • Total volume for the day/week/month
    • Volume distribution in the busy hour
    • Peak performance for the day/week/month
    • Maximum number of unique subscribers
    MUR supports additional information breakdown by network characteristics. These include Application Category, Protocol Groups, IP Protocol, Device Group, RAT (Radio Access Type i.e 2G vs 3G), APN (Access Point Name), SGSN group, Service Profile, Roaming Partner, and Location Group. During its development, a device may have several TAC codes and there may be a need to report devices by broader device type such as "Blackberry" or "Smartphone". Device groups allow the operator to combine a range of TACs into a single named group for reporting purposes.
    Busy Hour Reporting: Busy Hour (BH) reporting is mainly useful for the users to monitor different traffic flows in their network during the busy hour. BH indicates the sliding 60-minute period during which occurs the maximum total traffic load in a given 24-hour period.
    Please note the following key points:
    • BH reporting is available ONLY on the GUI and not in xls format.
    • BH reporting is available only under the DPI tab.
    • BH radio button is available on the date panel.
    • BH reporting is available for a date, date range, week and month.
    • Busy hour reports are currently available ONLY at the NOC level.
    DSL Reports: The current release of MUR provides the following details for Digital Subscriber Line (DSL) traffic reports:
    • Traffic analysis — uplink DSL, downlink DSL and total DSL traffic including daily weekly, and monthly aggregation/distribution.
    • DSL traffic categorization — total P2P traffic over DSL, IP traffic, web traffic, etc.
    • Top N% DSL subscribers
    • Comparison of total DSL traffic versus total UMTS traffic
    For information on additional reports supported through DPI, see the Cisco Mobility Unified Reporting System Online Help documentation.
  • CF-RE Report: Content Filtering (CF) solution enables operators to filter HTTP and WAP requests from mobile subscribers based on the URLs in the requests, so that subscribers are inadvertently not exposed to universally unacceptable content and/or content inappropriate as per the subscribers’ preferences.
    The CF-RE report provides the summary of traffic over CF categories, CF actions, and CF ratings. The CF actions that can be taken on the URL are as follows:
    • allow
    • discard
    • redirect-url
    • content-insert
    • terminate-flow
    • reply-code-terminate-flow
    The CF ratings can be one of the following:
    • dynamic
    • static
    • blacklisted
    The CF-RE report also provides the list of top N subscribers and URLs based on their unique subscriber’s hit count and total usage.
  • HTTP Reports: The MUR application parses HTTP EDRs and then provides the following details for any specific day, week, month and date range:
    • Total traffic per HTTP group / host name and HTTP content type
    • URL hits per HTTP group / host name and HTTP content type
    • Unique subscriber count per HTTP group / host name
    Typically, MUR supports the following categories of HTTP reports:
    • Summary reports — Content type/subtype volume report available for daily, weekly, monthly, and date range
    • Top N reports (Daily/Weekly/Monthly)
      • HTTP Group Aggregation — TopN HTTP group by Volume; TopN HTTP group by Hit count; TopN HTTP group by Unique subscriber hits
      • Top N Referrer Group Aggregation by Hit count
      • TopN User Agent (UA) reports available for APN-TAC combination in addition to individual per APN, per TAC reports.
      • HTTP Services Aggregation — TopN HTTP Services by Volume; TopN HTTP Services by Hit count
    The top N referrers’ report provides details of the total hit count for top N referrers and their sub-domain wise traffic distribution.

    IMPORTANT:

    In the distributed model of MUR, the data received from RDP is populated and TopN referrer report is available only at NOC level.

    IMPORTANT:

    It is mandatory to configure http-url and http-referer fields in the EDR records for top N HTTP referrers report generation.

  • Top N Unknown Ports: This report highlights the top N ports for which traffic is classified as either unidentified or unknown. This report also lists the underlying IP protocol, downlink volume (in Megabytes), uplink volume (in Megabytes) and total volume (in Megabytes).
    The report on top N unknown ports can be viewed through the link Edr unknown port infos under the System menu.
  • Bulkstat Report: The Bulkstat report provides details of the processed bulk statistics from any application (PDSN, GGSN, SGSN, and so only) on the managed nodes in a timely manner.

    IMPORTANT:

    Make sure that you configure the bulkstats schemas through the GUI to generate bulkstats reports for any of the available gateways. For more information on schema configuration, refer to the Configuring Bulkstats Schemas Using GUI section in this guide and also Cisco Mobility Unified Reporting System Online Help documentation.

    The bulkstat data is sent from the gateway to the MUR server with GMT (UTC Time stamps). The bulkstat file processing is triggered by the MUR scheduler engine. The scheduler processes the bulkstat files line by line for each gateway, and gets the schema, timestamp, and key index. If the index does not exist, the parser creates index and inserts data into bulkstats data table. Once the processing is complete, this data file is moved to the archive directory. Summarization must happen as the user moves from gateway to higher levels.

    IMPORTANT:

    For Bulkstat, there is no support for distributed model and all the bulkstat input files will be parsed by master MUR system only.

    MUR supports generation of busy hour reports, top N Min/Max reports, performance aggregation reports i.e. daily, weekly and monthly summary reports.
    Please keep the following key points in mind for bulkstats reporting:
    • The gateway(s) and MUR server need to be NTP synced for accurate BS aggregation reports.
    • Hourly aggregation reports are triggered at 50th minute of every hour.
    • Daily reports are scheduled at 3:45 PM the next day.
    • Weekly reports are scheduled at 5:00 PM every Monday.
    • Monthly reports are scheduled at 06:15 PM on 1st of every month.
  • KPI Report: The KPI report provides details of the KPIs for each selected schema. KPIs are the formula-based calculations of selected bulk statistics counters. You can configure the MUR application to generate the reports for any of the available gateways. For a complete listing of supported KPIs and its associated formulas/descriptions, see the Cisco Mobility Unified Reporting System Online Help documentation.
  • KPI Canned Report: Canned report can be enabled/disabled for any of the available KPIs. This can be configured through the MUR GUI under System > Kpis menu. This will display hourly reports at NOC level. These KPI values will be pre-calculated and stored in the DB at the end of each day.
    Once a KPI is enabled/disabled, it will start generating the canned report from the immediate next day.

IMPORTANT:

Please note that the Bulkstats and KPI reports are displayed based on the gateway’s time zone.

IMPORTANT:

Please note that the subscriber’s private data like Mobile Station Integrated Services Digital Network (MSISDN) will appear encrypted in all the subscribers reporting. Users with administrative privilege can only decrypt the MSISDNs using a shell script utility. For information on how to use this script, refer to the MUR Administration and Management chapter in this guide. The MSISDN decryption can also be accomplished through Admin > Users menu in the GUI. For decryption through the GUI, see the Cisco Mobility Unified Reporting System Online Help documentation.

IMPORTANT:

Please note that the availability of any report is typically based on the date/date range configurations and purging interval. If you are trying to view a report beyond the configured purging interval, MUR system will display an error message indicating that the report is unavailable.

For more information on each of these reports, see the Cisco Mobility Unified Reporting System Online Help documentation.

Exporting Reports to Other File Formats

The MUR application supports exporting reports to the following file formats:
  • Microsoft Excel format: To export a report to Microsoft Excel format, use the get_excel_report script in the CLI. For more information about this script, refer to the Generating Reports in Excel Format section in the MUR Administration and Management chapter of this guide.
    Exporting of reports to Excel format is also possible through the GUI by clicking the excel icon present in the tabular view of each of the reports under HOME and DPI tabs.
  • Comma Separated Value (CSV) file format: To view reports in CSV format, in the HOME and DPI tabs, click the csv icon present in the tabular view of each of the reports.
  • PDF format: To export a report to PDF format, in the HOME and DPI tabs of the MUR GUI, click the PDF button. The PDF file is displayed in a new window and can be saved for future reference.
    If there is no data available for a report, the PDF button is disabled.
  • Text File format: This format is applicable only to HTTP User Agent (UA) reports. To export this report in a text file, click Export to Text button available in the HTTP UA reporting page.
    For more information, see the Cisco Mobility Unified Reporting System Online Help documentation.

License Requirements

The MUR system is a licensed Cisco product. Contact your Cisco account representative for detailed information on specific licensing requirements.

MUR Architecture

The MUR solution consists of two components — a server and a GUI client. The following figure shows a typical organization of the MUR solution.


Figure 1. Internal Architecture of MUR
The server components include:
  • DB Server: This is the standard PostGreSQL 8.3 database server. This is started at the time of application startup.
    MUR uses pgbouncer utility for postgres connection pooling. This utility gets started/stopped with Postgres Server.
  • Quartz Scheduling Engine: This is the core of the MUR reporting solution. It is used to schedule different tasks such as parsing of incoming data files (bulkstat, EDR, etc.), trigger various canned reports on a periodic basis, cleaning up of stored outdated data and files, and so on.
  • Generators: These are python based scripts that are used for parsing various CSV files. The files are parsed to an extent where generated files (or data in database) themselves represent meaningful data. This is a very powerful concept introduced for faster processing of information.
    The generators archive the files once they are parsed. In archival, the files are zipped and placed in the configured location.
  • KPI Parser: The KPI Alarm Generator uses the information stored by bulkstat parser in the database for KPI calculations and then, based on the calculations, generates the alarms that are subsequently sent to Network Node Manager (NNM).
  • Notif Server: This stands as a separate entity that collects information from the MUR system and generates alarms which are then sent to the NNM for further analysis.
  • Loggers: The MUR application uses various loggers so that application logs with various severities are made available for debugging purpose.
  • MUR Parser Server: This will be running as daemons, and it will be spawned at the time of serv start command. Parser server will keep running in background and will perform the parsing activity for all gateways.
    The following is a sample output of the serv status command:
    ---------------------------------------------------

    --------------- MUR
Process Status ------------

     PID            Process                  Status 

    ---------------------------------------------------

     4245          Process
Monitor           Running

     4256          Scheduling
server        Running

     4267          Postgres
Server         Running

     4289          Apache
Server           Running

     3249          Notif
Server           Running

     3243          Parser
Server           Running

     2430          Cache
Server           Running

    ---------------------------------------------------
    The following describes the sequential steps associated with the functioning of RPC parser daemons.
    1. For each configured gateway, RPC Parser daemon will check if the appropriate reporting (Flow/HTTP/CF) is enabled or not.
      If say, Flow-EDR reporting is enabled for GW1, RPC Parser daemon will check the Process Count configured for Flow-EDR under System menu.
    2. Depending on the number of processes configured, RPC Parser daemon will spawn those many RPC server instances for GW1. Also, it will update each RPC server URL in DB as shown below:

      Table 1. RPC Server Instances for Gateways
      ID
      Gateway ID
      Reporting Type
      RPC Server URL
      Process ID
      1
      1
      Flow-EDR
      http://localhost:8000
      7643
      2
      1
      Flow-EDR
      http://localhost:8001
      8756
      3
      1
      Flow-EDR
      http://localhost:8002
      9054
      4
      1
      Http-EDR
      http://localhost:8003
      5645
      5
      1
      Http-EDR
      http://localhost:8004
      6576
      6
      1
      Http-EDR
      http://localhost:8005
      8678


    3. Steps 1 through 3 are repeated for each configured gateway and reporting type.
    4. Normalization daemon will pick up the set of files to be parsed. Depending on the number of files to be parsed, it will get the corresponding RPC server information from DB from the above table.
    5. Depending on the number of files to be parsed, normalization daemon will spawn those many threads. Each thread will allocate its bunch of files to corresponding RPC server instance. The RPC server instance will parse and store the normalized data in DB and the corresponding thread will exit.
    6. If the Process count is increased/reduced, additional RPC server instances will be fired/closed as and when required.
    7. Both the normalization daemon and RPC Parser daemon will be continuously running in background.
    8. Normalization daemon will be spawned by the scheduler initially. RPC Parser daemon will be spawned through serv start command.

Some of the components at the client side include Django and Mod_python.

Distributed Architecture of MUR

MUR supports the distributed model to allow the deployment which enables network wide view or work load balancing. Newly introduced component, Remote Data Processor (RDP), plays the role of pre-processing the input files from gateways. One or more RDPs, installed separately on remote machines can be registered to a master MUR and one RDP can process files from one or more gateways.

RDP periodically sends the intermediate data to registered master MUR. The role of MUR in such deployments is mostly for report generation, report viewing, RDP management and optionally data processing.

IMPORTANT:

RDP installation and registration is required only for network wide deployments. For standalone installation no RDP is required. For information on how to install the RDP, refer to the Managing MUR Installation chapter of this guide.

IMPORTANT:

Make sure that you first install the master MUR system and then proceed with the RDP installation. Also, note that the RDP and MUR must be installed, upgraded, and uninstalled separately.

IMPORTANT:

Before registering RDP with the master MUR, ensure that the RDP is installed and running.

IMPORTANT:

The RDP management like configuration and removal is possible from MUR GUI only. For information on managing the RDPs, refer to the Cisco Mobility Unified Reporting System Online Help documentation.

IMPORTANT:

For Bulkstat, there is no support for distributed model and all the bulkstat input files will be parsed by master MUR only.

The following figure illustrates the distributed architecture of MUR.


Figure 2. Distributed Architecture of MUR

How RDP works with MUR

This section describes how the RDP works with the MUR application.

The RDP parses the raw data or EDR files from one or more GGSNs and populates the database for required reports. The RDP pre-processes the data and then periodically forwards them to the master MUR through SFTP for report generation.

IMPORTANT:

If the distributed model of MUR is used, then the SFTP user name and password should be the same as the MUR Administrator user’s login name and password provided during installation. For information on configuring SFTP details, see the Cisco Mobility Unified Reporting System Online Help documentation.

Each of the RDP and MUR will be assigned a unique ID during installation and will be used for identification of each RDP along with its gateway and data.


Figure 3. MUR with RDPs in Distributed Model

In 12.0 and earlier releases, each of the registered RDPs will form a new region. RDP region can be a child of the root of the MUR (NOC) or can be the child of another region. The gateways associated with a RDP will always be the children of RDP region.

Release 12.2 onwards, users can create individual regions and add RDPs to the regions. All the gateways must be associated with RDP(s) or NOC and not to a region directly.

IMPORTANT:

Only single MUR can communicate with an RDP simultaneously.

Scalable MUR

In case of achieving high throughput (more than 10 GBPS), one RDP is not sufficient to process data. Scalability feature enables load distribution, so that data processing can be performed at multiple RDPs to support high data rate.

Scalability is achieved with the help of clustering of RDP nodes which share a common storage. The gateway pushes the input files to the shared storage through one of the RDPs, and all the RDPs then pick up those files as per certain rules defined for parsing. The parsing of files is based on the filename pattern that is specified while configuring the gateway. The MUR parsers match regular expressions given in the file name pattern and accordingly pick up the files. For example, users can specify *flow_*1 to match all flow EDR files ending with one to be picked up for that gateway. This way, multiple nodes parse the files in parallel. In such a cluster, maximum 16 nodes can be operating in parallel.

RDPs pick up the files based on the gateways that are attached to them. In the scalability model, one main instance of the gateway is configured on one of the RDPs. For the rest of the RDPs, a 'pseudo' instance of the same gateway is configured. This means, while adding another instance of the same gateway on another RDP, this gateway is marked as pseudo (through the MUR GUI) of an existing gateway (gateway configuration on GUI asks for name of a gateway to which gateway being configured is a pseudo). This configuration informs MUR that while processing data for pseudo gateway, this will not be considered as a separate gateway, but as the original gateway only.

In order to enable the RDPs to pick up files distinctly from each other, the configuration 'File Name Pattern' on the gateway configuration GUI is used. User can specify certain patterns for the file names for gateway (e.g. edr_*[1,3,5,7,9] to pick up only odd files and edr_*[0,2,4,6,8] to pick up only even numbered files) during such configuration. So, in the case of two RDPs, the user can specify pattern matching odd numbered files for first gateway that is configured on first RDP, and pattern matching even numbered files for second (pseudo) gateway that is configured on second RDP.

While viewing reports, in order to make sense to users, the pseudo gateway is NOT shown in the gateway hierarchical tree. The gateway tree is typically available under DPI, HTTP, CF, and Bulkstats tabs. However, the pseudo gateway information will be available through the Admin tab.

Basic Scalability Model

This section highlights the basic system requirements for the scalability in master MUR and RDPs.

  • Master — Internal disk: OS, MUR (RAID-0), Postgres (RAID-5)
  • RDP(s) — Internal disk: OS, MUR (RAID-0), Postgres (RAID-5), Archive (archive can be shifted to shared disk based on the requirement and sizing)
  • Shared-disk — Only incoming files (RAID-0)

The following figure outlines the basic model of the scalability implementation in MUR.


Figure 4. Scalable MUR

All cluster nodes needs to be interconnected using switch and needs to be in same VLAN/ shared disk. After the cluster installation, the shared disk needs to be configured in all nodes. Check if the nodes are connected using multipath -ll command.

The following procedure describes the steps to be followed for creating and mounting the shared disk:

  1. Check if the disk is available using multipath -ll command.
  2. Use the following VCS command to see the status of the disk:
    vxdisk -o alldgs list
  3. To add shared disk group, use the command:
    vxdg -s init mur_dgA
disk=emc_clariion0_22
  4. Create volume using the following command:
    vxassist -g mur_dgA
make sharedVol1 4000g
  5. Create file system using the following command:
    mkfs -t vxfs -o bsize=4096,largefiles /dev/vx/rdsk/mur_dgA/sharedVol1
  6. Create the directory for shared disk using the following command:
    mkdir /shared_edr_files
  7. Create mount point using the following command:
    mount -o cluster -t
vxfs /dev/vx/dsk/mur_dgA/sharedVol1 /shared_edr_files

IMPORTANT:

After creating volume and sharing disk on the cluster nodes, directory and mount point should be created.

After completing these configurations, use the output of the command df-khT to verify if the shared disk directory is created and mounted properly.

Scalability Setup for New Deployments of MUR

The required setup for the scalable MUR will be typically as follows:
  1. Setup two or more RDP server nodes in Veritas Cluster with VxFS and Cluster Logical Volume Manager.
  2. Connect these RDP nodes to a common shared storage, for example, Sun StorageTek 2540 array.
  3. Mount a common partition with VxFS file system from all the nodes.
  4. Install MUR in RDP modes on all RDP nodes.
  5. While installing MUR, make sure that each instance of the MUR has same user group, same user ID and user name.
  6. Specify a path on the shared partition where files will be received from gateway. Create required directory structure. Make sure that when the gateway does FTP, it has appropriate permissions to write the files to specified directory structure.
  7. Make sure the final directory where the files will be received, has user ownership (chown), group ownership (chgrp) and all write (777) permissions for RDP's user and group. This would enable the individual MUR processes to create further temporary files under incoming EDR directories.
  8. Configure the gateway to push files to one of the RDP’s IP address, and the destination path being the above mentioned shared location.
  9. Install the MUR as Master on another node.
  10. As in the hierarchical model, add RDPs to the master through appropriate regions.

MUR Features

This section provides information on the basic features of MUR application and its implementation.

Clustering Support for High Availability

MUR application consists of important internal entities such as Apache, Postgres, scheduling, cache, parser, notif servers and process monitor which run on a machine and communicate with the external entities such as ASR 5000 chassis and in turn provide Web Reporting capability to operators.

Whenever the machine or MUR process gets crashed/stopped, there are chances of loss of communication between internal and external entities. To avoid downtime and ensure continuous availability of MUR application, High Availability (HA) support using Veritas Clustering has been provided.

Using Veritas Cluster, there will be two machines configured to run MUR application. In case of machine failure, MUR Server will failover (move on to) from the current machine (Active Node) to another machine (called Passive node in cluster terminology) and that node will handle further processing of data. Operator will not be aware of this failover except that he will be asked to re-login on MUR UI after failover. A floating IP (shared IP), which is common to both the nodes, will be used for accessing MUR GUI. High Availability is supported for both standalone as well as distributed architecture of MUR. So in case of distributed architecture, there will be extra nodes for Master and each RDP to support failover mechanism.

IMPORTANT:

High Availability mode installation is only supported on RHEL platform.

Operation

Veritas cluster continuously monitors the MUR Process Monitor to ensure application availability. The shared IP address is floated across the Cluster nodes, which will be used by chassis for sending the EDR or Bulkstat data files and also to invoke the MUR GUI. MUR application is data centric and will have to be installed on the shared storage. Shared storage will be mounted on active node that will host MUR application. So the cluster service has to make the IP address, shared storage and MUR processes highly available.

The resources monitored by Veritas cluster are:
  • NIC - Monitors a NIC (Network Interface Card)
  • IP - Monitors the shared IP address
  • Disk Group, Volume and Mount - for shared storage
  • MUR Application - comprising of all the MUR related processes

For information on minimum system requirements and MUR configuration for HA deployment, please see the Mobility Unified Reporting System Clustering Support for High Availability chapter of this guide.

HTTPS Access

Hypertext Transfer Protocol Secure (HTTPS) is a combination of the Hypertext Transfer Protocol (HTTP) with Secure Sockets Layer (SSL) / Transport Layer Security (TLS) protocol to provide encrypted communication and secure identification of a network Web server.

HTTPS is a URI scheme that is, aside from the scheme token, syntactically identical to the HTTP scheme used for normal HTTP connections, but which signals the browser to use an added encryption layer of SSL/TLS to protect the traffic. SSL is especially suited for HTTP since it can provide some protection even if only one side of the communication is authenticated. This is the case with HTTP transactions over the Internet, where typically only the server is authenticated (by the client examining the server's certificate).

In Release 14.0 and later, MUR supports HTTPS communication between MUR UI (client browser) and MUR server which will allow addressing the following important security considerations:
  • Authentication: During the initial attempt to communicate with a Web server over a secure connection, that server will present the Web browser with a set of credentials in the form of a server certificate. The purpose of the certificate is to verify that the site is who and what it claims to be. In some cases, the server may request a certificate that the client is who and what it claims to be (which is known as client authentication).
  • Confidentiality: When data is being passed between the MUR client and the MUR server on a network, third parties can view and intercept this data. SSL responses are encrypted so that the data cannot be deciphered by the third party and the data remains confidential.
  • Integrity: When data is being passed between the MUR client and the MUR server on a network, third parties can view and intercept this data. SSL helps guarantee that the data will not be modified in transit by that third party.

Apache's HTTPS capability will be leveraged for this. The SSL server certificate will be self generated. The certificate usually contains the server name, the trusted certificate authority (CA) and the server's public encryption key.

IMPORTANT:

To effectively use HTTPS support, users are encouraged to create their own custom certification. If they do so, there will not be any address mismatch for MUR GUI and hence no warning. However, if the user wants to use the default Cisco certificate/key, then the user should perform a one-time process of adding an exception like disabling mismatch warning in the Settings in all the Web browsers such as Mozilla, IE, and Chrome.

IMPORTANT:

During MUR upgrades, please make sure to upgrade Apache Server and Certificates if needed. For example, when upgrading from an MUR version with no HTTPS support to a new MUR version with HTTPS implementation support, you should copy the whole Apache server with HTTPS support and also the default self signed certificate/key to <MUR_install_dir>/starbi/certificate directory. If you are using your own custom certificates, please remember not to update the certificate directory.

Creation of Security Certificates

The user should create self signed certificate and key to authenticate the client. Certificate and key can be generated by OpenSSL (www.openssl.org). Use the following command to generate self signed certificate and key.

openssl req -new -x509 -nodes -out server.crt -keyout server.key

This command will ask some user inputs. For example:

Country Name (2 letter
code) [US]:IN

State or Province Name
(full name) [Some-State]:Maharashtra

Locality Name (eg,
city) []:Pune

Organization Name (eg,
company) [Unconfigured OpenSSL Installation]:Cisco Systems

Organizational Unit
Name (eg, section) []:MITG

Common Name (eg, YOUR
name) []: cisco.com

Email Address []:
(you can leave it blank)

IMPORTANT:

Once both the certificate and key are created, they will be populated and stored in the <MUR_install_dir>/starbi/certificate directory.

Enabling Certificates on Browser

This section describes the procedure to enable SSL certificate on different browsers.

To enable certificate on IE:

  1. Copy certificate file on Windows machine and open it with IE.
  2. Click Tools -> Internet Options -> Content -> Certificates -> Trusted Root Certification Authorities and click Import.
  3. Follow the wizard and import the server.crt into Trusted Root CA.
  4. Open new IE and access the page.

To enable certificate on Mozilla:

  1. Click Tools -> Options -> Advanced -> Encryption tab -> View Certificates -> Authorities. Click Import and browse to select server.crt file and click OK. In the window that appears, select “This certificate can identify websites”.
  2. Check and ensure that the selected certificate appears under the tab Authorities. Open new Mozilla and access the page.

To enable certificate on Chrome:

  1. Click Settings -> Under the Bonnet -> HTTPS/SSL -> Manage Certificates.
  2. Import the certificate in the Trusted Root Certification Authorities.

Implementation on RHEL

SSL is already enabled in Apache Server for RHEL. That means the required libraries are already present in the Apache Server. You should only configure HTTPS in the configurations files httpd.conf and httpd-ssl.conf in the respective directories <APACHE>/conf and <APACHE>/conf/extra.

  1. Edit the httpd.conf file in the <APACHE>/conf directory.
    Uncomment “Include conf/extra/httpd-ssl.conf”
  2. Edit the httpd-ssl.conf file in the <APACHE>/conf/extra directory.
    1. Listen to port 9443 (Change your HTTPS port)
    2. SSLSessionCache
      "shmcb:<MUR_install_dir>/starbi/apache2/logs/ssl_scache(512000)"
    3. <VirtualHost *:9443>
    4. ServerName cisco.com
    5. ServerSignature On
    6. SSLEngine on
    7. SSLProtocol all -SSLv2
    8. SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
    9. SSLCertificateFile “<MUR_install_dir>/starbi/certificate/server.crt” (Path of certificate file created above)
    10. SSLCertificateKeyFile “<MUR_install_dir>/starbi/certificate/server.key” (Path of key file created above)

IMPORTANT:

All the changes mentioned in steps 1 and 2 will be done by installer scripts.

Implementation on Solaris

The Solaris version of Apache does not have SSL enabled. That means the required libraries are not present in Apache Server.

To make Apache Server enabled, you should install openSSL from IPCentral. And then recompile the Apache Server. The following are the steps to be followed to perform this action:

  1. Compile and install OpenSSL.
    1. Get Open SSL from IPCentral. Download openssl-0.9.8i-9-2.tar.
    2. Run the command tar xvf openssl-0.9.8i-9-2.tar
    3. Run the command PREFIX=openssl-0.9.8i-9-2
    4. Run the command export LD_OPTIONS="-R/<INSTALL_DIR>/${PREFIX}/lib"
    5. Run the command cd openssl-0.9.8i
    6. Run the command ./Configure solaris-x86-gcc --prefix=<INSTALL_DIR>/${PREFIX} shared -R/<INSTALL_DIR>/${PREFIX}/lib
    7. Run the command make
    8. Run the command make install
    9. Create a link using the following commands:
      cd <INSTALL_DIR>
      ln –s openssl-0.9.8i ssl
  2. Compile and install the Apache Server.
    1. Get Apache2.2.14 from IPCentral. (httpd-2.2.14-5-2.tar)
    2. Run the command tar xvf httpd-2.2.14-5-2.tar
    3. Run the command cd httpd-2.2.21
    4. Run the command ./configure --prefix=<INSTALL_DIR>/apache2 --enable-ssl
    5. Run the command make
    6. Run the command make install

    IMPORTANT:

    The above steps (1 and 2) will be executed manually on Solaris system to get the Apache Server with SSL libraries.

    Now, you should configure HTTPS in the configurations files httpd.conf and httpd-ssl.conf in the respective directories <APACHE2>/conf and <APACHE2>/conf/extra.
  3. Edit the httpd.conf file in the <APACHE2>/conf directory.
    Uncomment “Include conf/extra/httpd-ssl.conf”
  4. Edit the httpd-ssl.conf file in the <APACHE2>/conf/extra directory.
    1. Listen to port 9443 (Change your HTTPS port)
    2. SSLSessionCache
      “shmcb:<MUR_install_dir>/starbi/apache2/logs/ssl_scache(512000)”
    3. <VirtualHost *:9443>
    4. ServerName cisco.com
    5. ServerSignature On
    6. SSLEngine on
    7. SSLProtocol all -SSLv2
    8. SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
    9. SSLCertificateFile “<MUR_install_dir>/starbi/certificate/server.crt”
    10. SSLCertificateKeyFile “<MUR_install_dir>/starbi/certificate/server.key” (Path of key file created above)

IMPORTANT:

All the changes mentioned in steps 3 and 4 will be done by installer scripts.

LDAP Authentication in MUR

The Lightweight Directory Access Protocol, known as LDAP, is based on the X.500 standard, but significantly simpler and more readily adapted to meet custom needs. Unlike X.500, LDAP supports TCP/IP, which is necessary for Internet access.

LDAP is used as a central repository for user information and as an authentication service. It can also be used to store the attribute based data and the role information for application users. The LDAP maintains data in a hierarchical structure wherein the entries are in a tree-like structure called Directory Information Tree (DIT).

Prior to Release 14.0, MUR authenticates users against the MUR local DB information. In Release 14.0 and later, users can be authenticated against the LDAP directory.

For this, user should configure the following parameters for communication with LDAP server:

  • LDAP server as authentication backend
  • LDAP server hostname, LDAP server port
  • The Base Distinguished Name (DN) to start the search for users
  • User's Relative Distinguished Name (RDN) to be used for search
  • Type of mapping to be used to assign a role to the LDAP user
  • Miscellaneous configuration based on the selected type

IMPORTANT:

For LDAP user, the Change password option will not be available in the MUR GUI.

The following procedure describes how to set up LDAP authentication in MUR.

  1. User can select LDAP server as authentication backend. If the user information does not exist in LDAP directory then it will be authenticated against local MUR DB.
  2. If the user selects LDAP as authentication backend then the above mentioned parameters need to be specified.
  3. If LDAP backend is selected then when the user tries to login the authentication request is sent to the LDAP server by forming appropriate LDAP URL from LDAP hostname and port configured by the user.
  4. MUR tries to bind LDAP server with the provided user credentials. A proper DN is formed from User DN and RDN and is used while binding to the LDAP server.
  5. If binding is successful (user authentication is successful) a success message is sent to MUR.
  6. Perform the authorization in either of the two ways:
    1. Attribute Based: The value of the attribute which is used to map the MUR role/privilege to the LDAP user is compared with already configured values for MUR administrator and operator roles.
      For example: In LDAP directory there is a user attribute title, if the value of title attribute equals 'admin' then this user will be mapped to administrator role in MUR.
      For customer information: Already existing attribute can be configured or a new attribute for MUR specific usage can be added in LDAP directory.
    2. Group Based: All users from an existing group from LDAP directory will be classified as MUR administrator or as MUR operator.
      For example: There is 'sysadmin' group in LDAP directory. All users from this 'sysadmin' group can login to MUR as administrator.
      If the authorization fails then this LDAP user will not be able to login to the MUR.
  7. If the authentication fails at LDAP server then MUR will authenticate the user against its local DB.
  8. If LDAP user logs into MUR then this user will be restricted for user administration activities in MUR (like user creation, modification and deletion activities).

Region-based Reporting

In MUR versions prior to 12.2, RDP is considered as region, hence all reports were based on RDP. Whenever an RDP is configured, internally MUR used to create corresponding region for the same. However, with the introduction and need of scalable MUR, one gateway's files would be processed by two or multiple RDPs. In that case, RDP does not stand as a region. So, reports would be required across all the RDPs under one particular region. Hence, reports would be available per region.

The following figure shows an example of scalable and region based reporting model. This example considers two regions, New York and Chicago, both of them having one gateway each. Each location has two RDPs.


Figure 5. Scalable Setup of MUR
The following procedure outlines the steps to be followed for configuring the scalable network model.
  1. Install MUR in RDP mode on four nodes NYRDP1, NYRDP2, CHRDP1, CHRDP2, and in Master mode on fifth node.
  2. Connect shared storage 1 to NYRDP1 and NYRDP2. Similarly, connect shared storage 2 to CHRDP1 and CHRDP2.
  3. After configuring mount point and permissions, configure GWNY1 to push files to NYRDP1 on the shared storage 1 and GWCH1 to push files to CHRDP1 on shared storage 2.

    IMPORTANT:

    Ensure to check if EDR push functionality is configured on the gateway to send files to the RDP and shared path.

  4. Configure two regions, New York and Chicago. To perform this, invoke System menu from MUR GUI and then click Regions.

    IMPORTANT:

    While configuring regions, select Parent as NOC.

  5. Configure the RDPs. For example, to configure NYRDP1, on the GUI select Admin tab, click RDP from the left navigation pane and then click Add RDP.
  6. Once all the RDPs are configured, add GWNY1 to NYRDP1 through the Admin tab. During configuration, select New York region and NYRDP1 for this gateway and make sure that path for incoming files is specified from the shared disk.
  7. Similarly, configure GWCH1 on Chicago region on CHRDP1. During the configuration, the pattern for file name is given such that it picks up only required set of files. This can be achieved using regular expressions in the file name pattern. That is, configure the Flow EDR Filename Pattern as edr_flow_*[1,3,5,7,9] or edr_flow_*[2,4,6,8] so that the gateway picks up all odd or even numbered files accordingly.
  8. Configure GWNY1's pseudo gateway on NYRDP2. During the configuration, enter NYRDP2 as RDP, region as New York, and mark this as pseudo with the check box. Similarly, configure a pseudo gateway for GWCH1.
  9. The configuration setup is now complete and will start to function as needed.

When user clicks on region, say, Chicago, reports will be shown for GWCH1 (aggregated from both the RDPs under it). When user clicks on NOC, reports will be seen in consolidate manner for all regions.

On gateway, apart from mandatory configuration for EDR generation, it is must to have the sequence numbers enabled for the file generation. This would help MUR split the files into different RDPs.

IMPORTANT:

In the gateway tree in DPI, HTTP, CF and Bulkstats tab, the pseudo gateway is NOT shown. This is because, there are no specific reports to the gateway, it is just a pseudo to original gateway and all the data is coming from the original gateway only.

If there are multiple RDPs parsing the traffic from same gateway, multiple pseudo gateways should be created for each RDP. While entering the file name pattern, user can use regular expressions as needed.

Load Distribution Based on Number of Files

Following are sample file pattern configurations that can be used to distribute load among configured RDPs.

Load distribution for 10-20 Gbps throughput — 50-50(%) files distribution for both flow/HTTP among two RDPs.

Gateways

HTTP Pattern

Flow Pattern

GW1

*http*[0-4].* or *http*[0,2,4,6,8].*

*flow*[0-4].* or *flow*[0,2,4,6,8].*

GW2(pseudo)

*http*[5-9].* or *http*[1,3,5,7,9].*

*flow*[5-9].* or *flow*[1,3,5,7,9].*


Load distribution for 20-30 Gbps throughput — 30-30-35(%) files distribution for both flow/HTTP among three RDPs.

Gateways

HTTP Pattern

Flow Pattern

GW1

*http*[0-6][0-4].*

*flow*[0-6][0-4].*

GW2(pseudo)

*http*[0-6][5-9].*

*flow*[0-6][5-9].*

GW3(pseudo)

*http*[7-9][0-9].*

*flow*[7-9][0-9].*


Load distribution for 30-40 Gbps throughput — 25-25-25-25(%) files distribution for both flow/HTTP among four RDPs.

Gateways

HTTP Pattern

Flow Pattern

GW1

*http*[0-4][0-4].*

*flow*[0-4][0-4].*

GW2(pseudo)

*http*[0-4][5-9].*

*flow*[0-4][5-9].*

GW3(pseudo)

*http*[5-9][0-4].*

*flow*[5-9][0-4].*

GW4(pseudo)

*http*[5-9][5-9].*

*flow*[5-9][5-9].*


Tethering Detection Feature

IMPORTANT:

The Tethering Detection feature has limitations that restrict its optimal use and is not supported in this release. It is available only for lab/testing purposes.

Tethering refers to the use of a mobile smartphone as a USB dongle/modem to provide Internet connectivity to PC devices (laptops, PDAs, tablets, and so on) running on the smartphone's data plan. Typically, for smartphone users, most operators have in place an unlimited data plan, the usage of which is intended to be from the smartphone as a mobile device. However, some subscribers use the low cost / unlimited usage data plan to provide Internet connectivity to their laptops in places where normal Internet connection via broadband/WiFi may be costly, unavailable, or insecure.

IMPORTANT:

In this release, the Tethering Detection feature is supported only on the GGSN, HA, and P-GW.

The Tethering Detection feature enables detection of subscriber data traffic originating from PC devices tethered to mobile smartphones, and also provides effective reporting to enable service providers take business decisions on how to manage such usage and to bill subscribers accordingly.

IMPORTANT:

Use of Smartphone tethering detection feature requires that a valid license key be installed. Contact your Cisco account representative for information on how to obtain a license.

For detailed information on this feature, refer to Enhanced Charging Services Administration Guide.

MUR Support for Tethering Detection

The ASR chassis works in conjunction with the MUR application to facilitate tethering detection on the chassis.

Upon enabling tethering detection feature through the GUI, MUR collects samples of HTTP and TCP signatures from live traffic to create a database of OS and UA signatures for assorted devices accessing the network through the gateways. For this, offline TAC-device mappings are fed to MUR, and MUR generates the signature databases based on EDRs generated by the chassis for various TAC groups.

MUR processes flow-EDR files containing OS signature and IMEI field, HTTP files containing OS signature, User Agent, and IMEI field, and populates the following set of data in the respective database files.
  • Laptop (USB Dongles device group) - User Agent data
  • Laptop (USB Dongles device group) - OS Signature data
  • Smartphone - TAC data

MUR is configured in such a way that the database files are pushed to the ASR chassis under the /hd-raid/databases/ directory.

For information on how to configure tethering detection feature, refer to Configuring Chassis for Mobility Unified Reporting System chapter in this guide.

Tethering Detection Databases

The Tethering Detection feature uses the OS signature, UA signature, and TAC databases.

These database files must be populated and loaded on to the chassis by the administrator. The procedure to load the databases is the same for all the three types of databases.

Before the database(s) can be loaded for the first time, tethering detection must be enabled using the tethering-database CLI command in the Active Charging Service Configuration Mode.

For all three databases, only a full upgrade of a database file is supported. Incremental upgrade is not supported. If, for any particular database, the upgrade procedure fails, the system will revert back to the previous working version of that database.

OS Signature Database

The OS signature database file is named “os-db”. The file contains OS fingerprint signatures that have been identified as non-smartphone signatures.

The OS fingerprint signature string is a null-terminated ASCII string of maximum 32 bytes in the following format:

<tlen>|<ttl>|<d>|<wlen>|<mss>|<wss>|STEN

Where:

  • tlen: Total IP Packet Length
  • ttl: Initial TTL
  • d: IP DF bit
  • wlen: TCP Window Length
  • mss: TCP Maximum Segment Size
  • wss: TCP option Window Size Scale
  • S: TCP option Selective ACK OK
  • T: TCP option Timestamp
  • E: TCP option EOL
  • N: TCP option NOP (count)

The maximum number of entries permitted in the os-db file is 16384.

The maximum size of the os-db file can be 524KB + 50 bytes for header and trailer.

In the 12.2 release, the file is in plain text format and contains one TCP signature in ASCII format, one entry per line.

The following is the content of a sample os-db file:

VERSION 1.1

BEGIN OS-DB

48|128|1|5840|1460|1|1112

44|128|0|5840|1460|1|1011

END OS-DB

UA Signature Database

The UA signature database file is named “ua-db”. The file contains UA signatures that have been identified as non-smartphone signatures.

The UA signatures are stored in plain text format in the database file so that manual modification of the database is possible.

The maximum number of entries permitted in the ua-db file is 16384.

The maximum size of the ua-db file can be 67MB + 50 bytes for header and trailer.

The following is the content of a sample ua-db file:

VERSION 1.1

BEGIN UA-DB

Mozilla/4.0
(compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0;
SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729;
Media Center PC 6.0; InfoPath.2)

END UA-DB

TAC Database

The TAC database file is named “tac-db”. The file contains smartphone TACs that are uploaded in MUR by the operator.

The maximum number of entries permitted in the tac-db file is 16384.

The maximum size of the tac-db file can be 147KB + 50 bytes for header and trailer.

The following is the content of a sample tac-db file:

VERSION 1.1

BEGIN TAC-DB

01194800

01194801

END TAC-DB

Loading and Upgrading Tethering Detection Databases

This section provides an overview of loading and upgrading the OS, UA, and TAC databases used in tethering detection.

The database files from MUR must be copied onto the chassis to the following directory path designated for storing the database files:

/hd-raid/databases/

Any further upgrades to the database files can be done by placing the file named new-filename in the designated directory path. ACS auto-detects the presence of files available for upgrade daily. When a new version of a file is found, the upgrade process is triggered. The upgrade can also be forced by running the upgrade command in the CLI. On a successful upgrade this file is renamed to filename.

MUR Deployment

The following figure illustrates how the MUR reporting server interacts with the gateways and generates the reports.


Figure 6. End-to-end Component Mapping

The chassis / gateway supports on board Hard Disk Drive (HDD) for extended storage of the xDR files such as EDR, UDR, CDR, and NBR. If the HDD is configured, then the gateway pushes the files to an external entity like External Storage Server (ESS) for short-term storage. In case of no HDD support on the gateway, the Local, short-term External Storage Server (L-ESS) has the capability of pulling the files from gateways via SFTP, and send it for report processing. For more information on L-ESS, refer to the ESS Installation and Administration Guide.

The MUR server collects the EDRs, and bulkstats from gateways or L-ESS server, and processes the incoming data files and presents reports on Web-based GUI. The MUR application can generate reports in Excel, CSV, and PDF formats, and present them to users on a request basis.

IMPORTANT:

L-ESS is NOT required as the ASR5K EDR 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.

For information on how to configure the chassis to push the xDRs, refer to the Configuring Chassis for Mobility Unified Reporting System chapter in this guide.

MUR System Requirements

This section identifies the minimum system requirements that are required for the deployment of MUR at the operator’s premises.

IMPORTANT:

The hardware required for MUR may vary depending on incoming EDR generation, subscriber count, and number of gateways.

Server Recommendations for Use in Solaris Environment

This section identifies the minimum system requirements recommended when installing the MUR application in Solaris environment.

NEBS Requirements:

The following are the server specifications for MUR when an additional external storage is required:
  • Sun Microsystems Netra™ X4270 server
    • Quad-Core two socket Intel Xeon L5518 processor
    • 32GB RAM
    • 2 * 300GB 10K RPM SAS disks
    • SATA DVD drive
    • 8 internal port SAS HBA
    • Choice of AC or DC power supplies
  • Sun StorageTek 2540 SAS Array, Rack-Ready Controller Tray
    • 12 * 300GB 15K RPM SAS drives
    • Two redundant AC power supplies
  • Operating system:
    • Sun Solaris 10 with latest patches installed

Non-NEBS Requirements:

The following are the server specifications with only the internal storage used:
  • Sun Fire X4270 server
    • Intel Xeon processor 5500 series
    • 32GB RAM
    • 16 * 300GB 10K RPM SAS disks
    • SATA DVD drive
  • Operating system:
    • Sun Solaris 10 with latest patches installed

IMPORTANT:

It is strongly recommended to update the Operating System with the latest security patches.

IMPORTANT:

The number of disks recommended is purely based on the throughput of the network and data retention configuration. Please contact Cisco Advanced Service Team for data sizing.

ZFS Pooling Recommendations:

This section provides information on the recommendations for ZFS pooling.
  • OS pool: This mirrored ZFS pool shall be created for Solaris OS installation.
  • MUR pool: This standard ZFS pool shall be created for MUR i.e. MUR installation, incoming data files.
  • Postgres pool: This standard ZFS pool shall be created for MUR postgres database.
  • Archive pool: This standard ZFS pool shall be created for retaining archived and data backed up files.

IMPORTANT:

ZFS pool shall NOT be created with RAID-Z since ZFS does not allow attaching an additional disk to an existing RAID-Z pool. Hence, this freezes the chances of data scaling.

Server Recommendations for Use in RHEL Environment

This section identifies the requirements of server recommended when installing the MUR application in RHEL environment.
  • UCS C460 M2 server
    • 4 x Intel® Xeon® E7-4860 @ 2.26 GHz, 130W 10 Core CPU / 24 MB Cache
    • 128GB RAM
    • 12 * 600 GB SAS 6G, 10K RPM
    • RAID Controller
    • 4Gb Dual port FC Host Bus Adapter

    IMPORTANT:

    The number of disks recommended is purely based on the throughput of the network and data retention configuration. Please contact Cisco Advanced Service Team for data sizing.

  • Operating System
    • Cisco UCS running OS version ‘Cisco MITG RHEL 5.5’
      For information related to OS installation, refer to the Cisco MITG RHEL OS v5.5 Application Note.

    IMPORTANT:

    The Cisco MITG RHEL v5.5 OS is a custom image that contains only those software packages required to support compatible Cisco MITG external software applications. Users must not install any other applications on servers running the Cisco MITG v5.5 OS. For detailed software compatibility information, refer to the Cisco MITG RHEL v5.5 OS Application Note.

    IMPORTANT:

    ZFS Pooling recommendations are applicable ONLY for Solaris hardware.

  • XFS/EXT-3 File System Volumes & RAID Recommendations

Storage RAID recommendation for MUR Application

CISCO UCS machine supports MegaRAID controller. This allows configuring the UCS hard disks into hardware RAID arrays (disk groups). The MegaRAID controller provides the BIOS utility for configuring the RAID.

The RAID recommendations for MUR are as follows:
  • Separate disk arrays for OS, MUR and postgres (data directory).
  • RAID Level - Combination of 5 and 0 depending upon the fault tolerance.
  • Stripe size should be 256KB
  • RAID Controller parameters —
    • Read Policy - Select Adaptive read ahead
    • Write Policy - Select Write Back
    • I/O Policy - Select Direct I/O

For information on configuring the RAID arrays using MegaRAID BIOS, refer to the Configuring Cisco UCS Servers for MUR System Application Note.

Storage Recommendation for MUR Application

This section provides the storage recommendations needed for the MUR application.
  • Separate storage (single disk or RAID array) for OS. (root and swap space partitions)
  • Two RAID arrays: RAID-0 for MUR application and RAID-5 for database (Postgres data directory).
  • LVM: Separate physical volume and volume groups for the three RAID array disk groups.
  • XFS file-system: block size 4 KB, s-unit in terms of RAID stripe size (256KB) and s-width in terms of span of disks in the RAID array.

For information on how to partition storage disk and configure XFS file system, refer to the Configuring Cisco UCS Servers for MUR System Application Note.

Hardware Requirements for Scalable Model of MUR

  • UCS 460 Server or Oracle x86 4270 Server
  • Sun StorageTek 2540 SAS Array
  • Other miscellaneous components such as cables, switches, etc same as mentioned in the previous sections of this guide.

Software Requirements for Scalable Model of MUR

  • Veritas Cluster 5.1
  • Veritas cluster suite
  • VxFS as cluster file system
  • Veritas Cluster Logical Volume Manager
NOTE: Solaris OS clustering is NOT recommended for the following reasons:
  • If there are any deployments that have a Solaris machine running Solaris OS (either as Master or as RDP or both), and if you want to upgrade to scalable model, following cases arise.
    • In a standalone installation —
      • Keep existing machine as master and have Linux machines as RDPs. If the RDPs are Linux, then Veritas cluster would do.
      • Another option is to add all Solaris machines with Solaris OS. This is not recommended as Solaris machine would be much more costlier than UCS.
    • If hierarchical installation exists —
      • Keep master as Solaris OS. For the RDP, there are two possibilities —
      • Add another RDP as Solaris OS and have Solaris cluster. This is not recommended as Solaris machine would be costlier than UCS.
      • If the existing Solaris machine is NOT Linux compatible (e.g. SPARC machine), it would be good to replace current Solaris machine with UCS and purchase another UCS for scalability purpose.
      • If the existing Solaris machine is Linux compatible (e.g. x86 architecture), it would be good to upgrade it to RHEL and have it as cluster.

MUR Ports

This section provides information on various ports and their corresponding port numbers used by the MUR application.

Various ports are used by the MUR for both client-server communication and communication with ASR chassis. If firewalls are used on these interfaces, these ports need to be opened.

The following table lists the ports that are used by MUR.


Table 2. Default Port Utilization

Port Name

Port Number

Usage

TCP Port

22

This port is used by MUR administrator to connect via SSH to UNIX command line on MUR servers for system administration.

This port is also used by gateway to upload files via SFTP to MUR servers (stand-alone master and RDPs), and also by RDPs to upload files to the master. In the case of pull model, the L-ESS process on the RDPs or stand-alone master will use SFTP to connect to this port on the gateway.

This port is also used between master MUR server and gateway to configure and upload bulkstat files.

TCP Port

25

This port is used to send e-mails to a mail server in case these are configured to deliver reports and alarms.

UDP Port

162

This port is used to send traps to the northbound network management system.

Postgres Port

5432

This port is used by the local processes to access the PostgreSQL server and can be restricted to prevent external access.

Apache Port

8080

For a standalone model:

This port is used for communication between client workstation and Apache Webserver on MUR via HTTP.

For distributed model:

This port is used for both Master to RDP and RDP to Master RPC communication.

IMPORTANT:

When firewall is used, Apache is the only port that should be kept opened.


Typically, MUR starts all its related services with non-root (i.e. muradmin) privileges.

Firewall Settings

When MUR is running on RHEL platform, Firewall is ON by default. In that case, user will NOT be able to get access to MUR GUI. The Firewall MUST be disabled with the following commands:

service iptables save

service iptables stop

chkconfig iptables off

Using Apache Port

This section provides information on how to configure the Apache port to use in conjunction with the MUR reporting server.

Using Apache in Solaris

In case the user wants to configure Apache port as 80 (i.e. < 1024), it is necessary to run the following command as root user so that muradmin can start the services on ports < 1024.

usermod -K defaultpriv=basic,net_privaddr <mur admin user>

Using Apache in RHEL

IMPORTANT:

Make sure that you disable Firewall before using the Apache port in the RHEL environment.

RHEL does not allow port 80 to be used by non-root users. However, Apache Web server requests made on port 80 can be redirected to a port >1024 defined by the operator, with the following two commands:

iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j REDIRECT --to-port <user defined port> 1024>

iptables -t nat -AOUTPUT -p tcp -d 127.0.0.1 --dport 80 -j REDIRECT --to-port <user defined port>  1024>

For example, to redirect requests made on port 80 to port 8080:

iptables -t nat -A PREROUTING -p tcp  --dport 80 -i eth0 -j REDIRECT --to-port 8080

iptables -t nat -AOUTPUT -p tcp -d 127.0.0.1 --dport 80 -j REDIRECT --to-port 8080

Once this is done, user will be able to access the MUR GUI directly, without specifying the port in the Web browser URL http://<serveripaddress>.