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), and statistical trending support.
  • Exporting reports in Microsoft Excel, Adobe PDF, and CSV and XML formats.
  • Report scheduling, notification, and distribution. The report notification can be in the form of alarms/traps.
  • 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:
    • Filesharing
    • Web
    • IM
    • VOIP
    • Standard
    • Streaming
    • Tunnel
    • Gaming
    • Unclassified
    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.

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

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

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.

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, UDR, 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. The loggers provide the flexibility to change log levels without a need of restart.

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.

MUR Deployment

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


Figure 5. 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

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