Feature Summary and Revision History

Feature Description

In vDRA, Docker engine is configured with journald logging driver on every VM. The journald logging driver sends container's logs to journal deamon.

Use the journalctl command, through journal API, or use the docker logs command to systemd journal to retrieve the log entries.

As part of the logging enhancements, vDRA supports retaining of journalctl logs for longer duration around 10 days on all VMs. This helps in debugging any issues even though journal logs gets rolled over early.

All the logs are captured through automated cron job at daily basis on nonpeak time and cronjob timings are configurable through cron job file. The collected logs are stored under /data/journal-logs directory on each VM and also stored at remote server. You can configure the size of the logs folder and days of retention in the configuration file.

On every VM, log collection happens based on disk size of the /data/journal-logs folder, Default /data/journal-logs directory size is 10GB. If the /data/journal-logs directory size is less than 10GB it will collect the logs and it will copy to the Control VM and remote server, If the /data/journal-logs directory size exceeds to 10 GB , journal.sh script deletes files beyond 2 days to free up the disk space on the VM. This parameter is also configurable from cps-journal.conf file.

You can configure the retention days and size of log storage folder on /etc/cps/cps-journal.conf file. And copying journal logs to Control VM works with static and Virtual VIP IP.

While copying the journal logs to a control VM, journal.sh script checks the / disk usage on control VM. If the disk size is less than 60 % it copies files to the control VM, otherwise it won't copy and these log files are stored on same VM based on the retention period. This disk usage value for Control VM is configuration through cps-journal.conf file.

For the CPU usage optimization, this script is limited to execute with only 50 % of the system CPU.

For more information, see Retaining journalctl Logs in DRA section in the CPS vDRA Operations Guide.

Feature Summary and Revision History

Feature Description

In 21.2.0 and later releases, support is added to recover single/multiple/all shards nd metadata database using CLI.

The following new CLI commands are added to recover shards:

• database repair <clustername> <shardname>

• database repair <clustername> <shardname1> <shardname2> <shardname3>

• database repair <clustername> All

• database repair <clustername> sharddb

For more information, see the following sections:

• database repair in the CPS vDRA Operations Guide

• Recovery Using database repair Command in the CPS vDRA Troubleshooting Guide

Feature Summary and Revision History

Feature Description

In CPS Diameter Routing Agent (DRA), you can query the database in Mongo Sharding with the help of Mongo router VM. In case, the VM is removed as a part of App sharding, the capability to query all shards for specific conditions is lost. To overcome this situation, DRA supports new orchestrator CLI for App sharding queries..

If the database record count is less than or equal to 5, then the record is displayed as CLI output, otherwise it is saved to a file. For the required number of records provide maximum value and find corresponding records in /data/config/Query.log. All database queries runs on Secondary DB instances to avoid major performance impact.

For more information, see database query section in the CLI Commands chapter in CPS vDRA Operations Guide.

Feature Summary and Revision History

Feature Description

CRD, Metadata DB connectivity, and Consul failures lead to improper processing of the Diameter messages in the Worker node. To enhance product resiliency in the Worker CRD failure, Worker Metadata DB, and Worker consul readiness scenarios, vDRA supports health checks to ensure that all prerequisites are met before Diameter messages are processed by that node.

The following validations are done during Binding/Diameter application initialization.

• CRD validation for Diameter and binding initiation

• Metadata DB access check from binding node

• Consul health check during Binding/Diameter application initialization

For more information, see DRA Health Checks section in the CPS vDRA Administration Guide.

The following new statistics are added to track the DRA health checks:

• app_service_health_status

• metadata_db_status

• topology_update_msg_sent_total

For more information on statistics, see Statistics/KPI Additions or Changes.

The following new alarms are added to track the DRA health checks:

• APP_SERVICE_HEALTH_STATUS_CRD

• APP_SERVICE_HEALTH_STATUS_METADATA_DB

For more information, see the following tables in the CPS vDRA SNMP and Alarms Guide.

• Application Notifications

• Sample Alert Rules

Feature Summary and Revision History

Feature Description

DRA distributor rebalances the existing active connections across all available directors through CLI commands. The rebalancing allows:

• Equal distribution of connections on all available directors

• Recommendation of number of peers that are disconnected from each director where there are more active connections.

• Ensures graceful disconnect of peers on directors with more connections and on reconnect, same peers gets distributed to other directors that has less number of connections.

Distributor connection balancing uses the following CLIs:

• dra-distributor balance connection cluster-name service-name

• dra-distributor balance connection cluster-name service-name audit

For more information, see the following:

• Balancing Distributor Connections section in the CPS vDRA Administration Guide

• dra-distributor balance connection and dra-distributor balance traffic sections in the CPS vDRA Operations Guide

Feature Summary and Revision History

Feature Description

CPS vDRA traces the flow of a message from a single subscriber, including Policy Builder STG lookup, CRD tables and route rules used, VM/containers, systems traversed, DB lookups performed with results, and so on to show the successful (or failed) transmissions. In the CPS 21.2.0 release, vDRA monitors live logs for single subscriber activities based on IMSI/MSISDN/IPv6.

For more information, refer to the Monitoring Single Subscriber Activity section in the CPS vDRA Administration Guide.

Feature Summary and Revision History

Feature Description

Overload conditions on binding databases occurs when CCR-I or CCR-T bursts over one or more peer connections, thereby destabilizing the system. vDRA supports the following mechanisms to protect the system from such an overload condition:

• Dynamically vary peer message rate limits (CCR-I/T) based on DB CPU load to enable better utilization of available DB capacity.

• Selectively throttle peer connections with traffic burst and continue processing of messages for peers with BAU traffic.

Configure Message Rate Limit profile to throttle messages on the Director and rate limits for each message type in the profile. Dynamic rate limiting allows you to:

• Determine the available DB capacity and dynamically derive the rate limits.

• Configure preferred rate limits and apply dynamic throttling on configured values.

For more information, see Dynamic Peer Rate Limit based on DB VM CPU Usage section in the CPS vDRA Configuration Guide

The following new statistics are added:

• peer_dynamic_rate_limit_throttling

• dra_db_cpu_message_ published_total

• db_cpu_control_ message_fail

• processed_db_cpu_control_ message_total

For more information on statistics, see Statistics/KPI Additions or Changes.

The following new alarms are added:

• PEER_DYNAMIC_RATE_LIMIT_THROTTLING

• NO_DB_CPU_THRESHOLD_STATUS

For more information, see the following tables in the CPS vDRA SNMP and Alarms Guide.

• Application Notifications

• Sample Alert Rules

Feature Summary and Revision History

Feature Description

vDRA is enhanced to send WPS/non-WPS IPv6 binding queries to PCRF with different DSCP value and receive SRK information to route the Rx AAR messages.

vDRA allows the following functionalities:

• Separate REST API endpoint configurations to support WPS IPv6 binding queries.

• WPS REST API endpoints selection to query IPv6 binding for all WPS messages and non-WPS messages.

• PCRF session query for WPS Rx AAR messages is set with configured DSCP value as 47.

• PCRF session query for non-WPS RX AAR messages is set with configured DSCP value as 32.

• Attribute class:wps set up to the payload for all WPS PCRF session queries.

• Fallback to non-WPS PCRF REST API endpoints. This is to get session route key information for WPS Rx AAR messages when there is any issue in sending query with WPS PCRF REST API endpoints or WPS PCRF REST API endpoints not configured.

For more information, see PCRF Session Query for WPS Messages section in the CPS vDRA Configuration Guide.

The following statistics are modified:

• pcrf_binding_query_total

• pcrf_api_request_duration_ms

• pcrf_api_request_send_total

For more information on statistics, see Statistics/KPI Additions or Changes.

Feature Summary and Revision History

Feature Description

In 21.2.0 and later releases, support is added to trigger an alarm to notify the user when application has stopped logging consolidated-qns logs unexpectedly.

The following new alarm is added:

• QNS_LOGGING_STOPPED

Note	If there is no activity on the system, and an alarm is raised, it is expected and is resolved automatically when application activity starts.

For more information, see the following tables in the CPS vDRA SNMP and Alarms Guide.

• Application Notifications

• Sample Alert Rules

Feature Summary and Revision History

Feature Description

CPS vDRA stores audit logs based on modules. If you enable the debug or trace logging function, CPS vDRA stores detailed logs for all the subscribers and modules which fills the logs and rotates it quickly. In order to avoid this filling of logs, vDRA is enhanced to support tracing function of incoming and outgoing messages for a single subscriber.

The main functions are:

• vDRA captures diameter request and response messages across all vDRA sites for a single subscriber and stores all messages in configured DB in PCAP format.

• Captures Request and Answer messages as received from the peer and as sent to the peer on ingress and egress director, respectively.

• Starts or stops the trace by getting the subscriber identity, which is IMSI/MSISDN/IPv6.

• Retrieves the PCAP based on the subscriber identity. By default, vDRA stores the PCAP in admin-db.

• vDRA allows you to configure any other MongoDB URI to store the PCAP.

For more information, refer to the Tracing and Monitoring Single Subscriber Activities section in the CPS vDRA Administration Guide.