Plug-in Configuration
Cisco Policy Builder provides core plug-ins for customizing and optimizing your installation.
-
Configurations set at the system level are system-wide except as noted in the bullet items below.
-
Configurations set at the cluster level apply to that cluster and the instances in it. A value set here overrides the same value set at the system level.
-
Configurations set at the instance level apply to the instance only and override the same value set at the cluster or system level.
Select the Create Child action in a Plug-in Configuration node in the Systems tree to define them. You can change any of the variables from the default, or choose not to use a plug-in, as necessary.
When you create a system from the example, the following configuration stubs appear at the cluster and instance level:

Threading Configuration
A threading configuration utility is provided for advanced users.
Click Threading Configuration in the right pane to add the threading configuration to the system. If you are planning to run the system with higher TPS, then you need to configure Threading Configuration. For further information, contact your Cisco Technical Representative.
The Threading Plug-in having thread pools controls the total number of threads in CPS vDRA that are executing at any given time. Each of these thread pools have a queue associated with it.
The following parameters can be configured under Threading Configuration:
|
Parameter |
Description |
|---|---|
|
Thread Pool Name |
Name of the thread pool. For more information on the thread pool names and recommended values that can be configured, refer to Threading Configuration section in the CPS vDRA Advanced Tuning Guide. |
|
Threads |
Number of threads to set in the thread pool. |
|
Queue Size |
Size of the queue before they are rejected. |
|
Scale By Cpu Core |
Select this check box to scale the maximum number of threads by the processor cores. |
Async Threading Configuration
Click Async Threading Configuration in the right pane to add the configuration in the system.
Use the default values for the Async Threading Plug-in. The Async configuration controls the number of asynchronous threads.
![]() Note |
Currently, CPS vDRA does not have any asynchronous threads. However, you must add “Async Threading Configuration” and keep this table empty. |
The following parameters can be configured under Async Threading Configuration.
|
Parameter |
Description |
|---|---|
|
Default Processing Threads |
The number of threads that are allocated to process actions based on priority. |
|
Default Action Priority |
The priority assigned to an action if it is not specified in the Action Configurations table. |
|
Default Action Threads |
The number of threads assigned to process the action if it is not specified in the Action Configurations table. |
|
Default Action Queue Size |
The number of actions that can be queued up for an action if it is not specified in the Action Configurations table. |
|
Default Action Drop |
DropOldestWhenFull: The oldest queued action is dropped from the queue when a new action is added to a full queue. Otherwise, the new action to add is ignored. DropWhenFull: A handler for rejected tasks that silently discards the rejected task. No execution for rejected tasks. DoNotDrop: A handler for rejected tasks that runs the rejected task directly in the calling thread of the execute method, unless the executor has been shut down, in which case the task is discarded. Default value is DropOldestWhenFull. |
|
Action Configurations Table |
|
|
Action Name |
The name of the action. This must match the implementation class name. |
|
Action Priority |
The priority of the action. Used by the default processing threads to determine which action to execute first. |
|
Action Threads |
The number of threads dedicated to processing this specific action. |
|
Action Queue Size |
The number of actions that can be queued up. |
|
Action Drop Oldest When Full |
For the specified action only: When checked, the oldest queued action is dropped from the queue when a new action is added to a full queue. Otherwise, the new action to add is ignored. |
Custom Reference Data Configuration
Configure your system, cluster, and instance for the first time to use Custom Reference Data Table plug-in. Then you can create as many tables as needed.
Click Custom Reference Data Configuration from right pane to add the configuration in the system.
-
HA example:
-
Primary Database Host/IP Address: sessionmgr01
-
Secondary Database Host/IP Address: sessionmgr02
-
Database Port: 27717
-
The following parameters can be configured under Custom Reference Data Configuration.
|
Parameter |
Description |
||
|---|---|---|---|
|
Primary Database Host/IP Address |
IP address or a host name of the sessionmgr database. For example, sessionmgr01. |
||
|
Secondary Database Host/IP Address |
(Optional) This field is the IP address or a host name of a secondary, backup, or failover sessionmgr database. For example, sessionmgr02. |
||
|
Database Port |
Port number of the sessionmgr.
Default value is 27717. |
||
|
Db Read Preference |
Describes how sessionmgr clients route read operations to members of a replica set. Select one of the following options from drop-down list:
Default value is Primary. For more information, see http://docs.mongodb.org/manual/core/read-preference/. |
||
|
Connection Per Host |
Number of connections that are allowed for each database host. Default value is 100. Connection Per Host is a performance tuning parameter and can be changed in case of a performance issue according to the call model and hardware. |
For more information on Custom Reference Data API Usage, see the CPS Operations Guide for this release.
DRA Configuration
Click DRA Configuration from the right pane in Policy Builder to add the configuration in the system.

The following parameters can be configured under DRA Configuration:
|
Parameter |
Description |
||||
|---|---|---|---|---|---|
|
Stale Session Timer Minutes |
Indicates the time after which the audit RAR should be generated (in the subsequent audit RAR process cycle that runs every minute in CPS vDRA) for sessions that are stale. Default: 180 minutes (recommended value) Minimum: 10 minutes Maximum: 10080 minutes |
||||
|
Rate Limiter |
Indicates the number of audit RARs per second that should be sent out by CPS vDRA. Minimum: 1 Maximum: 1000 (maximum number of RAR messages per second from vDRA to PCEF) For information on recommended value, refer to Audit Rate Limiter section in the CPS vDRA Advanced Tuning Guide. |
||||
|
Stale Session Expiry Count |
Specifies the number of retries vDRA should do for a stale session if there is no response of audit RAR or if there is Result-Code in RAA (for audit RAR) other than 5002 or 2001. Default: 6 Minimum: 0 (Session deleted without sending RAR) Maximum: 10 For information on recommended value, refer to Audit Rate Limiter section in the CPS vDRA Advanced Tuning Guide. |
||||
|
Binding DB Read Preference |
Used to select the mode when reading from Binding DB. Use "nearest" mode for better performance of traffic that needs only read operation on Binding DB. Default: Nearest For information on recommended value, refer to Audit Rate Limiter section in the CPS vDRA Advanced Tuning Guide. |
||||
|
Stale Binding Expiry Minutes |
Duration after which a binding record is validated against a session record to see if the binding should be deleted because it is stale The timer is initialized when the session is created. The records are deleted when binding expiry time is reached and no active session is found. Otherwise, the timer is updated so the binding record can be audited after another Stale Binding Expiry Minutes. Default: 10080 minutes (168 hours or one week) (recommended value) Minimum: 10 minutes Maximum: 43200 minutes (28 days) |
||||
|
Stale Binding Refresh Minutes |
Duration for which the expiry time of the binding database records is refreshed. Default: 2880 minutes (48 hours or 2 days - recommended value). Minimum: 10 minutes Maximum: 10080 minutes (one week)
|
||||
|
Binding Creation, Primary Alternative System |
Name of vDRA system to retry Gx CCR-i When vDRA tries to route a Gx CCR-i request, but is unable to reach the database, the configured values of first the primary, then the secondary systems are used to route the Gx CCR-i to a different vDRA to try the database. The retry is stopped if that vDRA also cannot reach the database. |
||||
|
Binding Creation, Secondary Alternative System |
Name of secondary vDRA system to retry Gx CCR-i |
||||
|
Binding Routing, Primary Alternative System |
Name of vDRA system to retry Rx AAR When vDRA tries to route a Rx AAR request, but is unable to reach the database, the configured values of first the primary, then the secondary systems are used to route the Rx AAR to a different vDRA to try the database. The retry is stopped if that vDRA also cannot reach the database. |
||||
|
Binding Routing, Secondary Alternative System |
Name of secondary vDRA system to retry Rx AAR |
||||
|
Settings |
Refer to Settings. |
||||
|
Rate Limits |
Refer to Rate Limits. |
||||
|
DRA Feature |
Refer to DRA Feature. |
||||
|
DRA Inbound Endpoints |
Refer to DRA Inbound Endpoints. |
||||
|
Relay Endpoints |
Refer to Relay Endpoints. |
Settings
Click Settings check box to open the configuration pane.
The following parameters can be configured under Settings:
|
Parameter |
Description |
||
|---|---|---|---|
|
Stop Timeout Ms |
Determines how long the stack waits for all resources to stop. The delay is in milliseconds. Default: 10000 ms (recommended value) Minimum: 1000 ms Maximum: 60000 ms (one minute) |
||
|
Cea Timeout Ms |
Determines how long it takes for CER/CEA exchanges to timeout if there is no response. The delay is in milliseconds. Default: 10000 ms (recommended value) Minimum: 1000 ms Maximum: 60000 ms (one minute) |
||
|
Iac Timeout Ms |
Determines how long the stack waits before initiating a DWR message exchange on a peer connection from which no Diameter messages have been received. The timeout value is in milliseconds. Default: 5000 ms (recommended value) Minimum: 1000 ms Maximum: 30000 ms (30 seconds) |
||
|
Dwa Timeout Ms |
Determines how long the stack waits for a DWA message in response to a DWR message. If no Diameter message (DWA or other message) is received on the peer connection during the first timeout period, the stack counts a failure, sends another DWR message, and restarts the Dwa timer. If no Diameter messages are received during the second timeout period, the stack counts a second failure. After two consecutive failures, the stack considers the peer connection as failed, and closes the connection. The delay is in milliseconds. Default: 10000 ms (recommended value) Minimum: 1000 ms Maximum: 60000 ms (one minute) |
||
|
Dpa Timeout Ms |
Determines how long it takes for a DPR/DPA exchange to timeout if there is no response. The delay is in milliseconds. Default: 5000 ms (recommended value) Minimum: 1000 ms Maximum: 30000 ms (30 seconds) |
||
|
Rec Timeout Ms |
Determines how long it takes for the reconnection procedure to timeout. The delay is in milliseconds. Default: 10000 ms (recommended value) Minimum: 1000 ms Maximum: 60000 ms (one minute) |
||
|
Drain Timeout Ms |
Indicates the time that a peer connection remains open for responses to be sent to peers even if DPR is sent or received by vDRA. If a DPR is sent or received by vDRA, vDRA does not route requests to the disconnecting peer connection via any routing (Dest-Host, SRK, Binding, Table-Driven). However, responses and in-flight requests sent to the corresponding peers till the duration of Drain Timeout. This allows vDRA to gracefully shut down when any remote peer sends a DPR so as to minimize the diameter message loss. Default: 2000 ms Maximum: Must be less than Dpa timeout Ms
|
The following figure illustrates the timers in peer detection:
Binding DB Audit
The Binding DB Audit automatically deletes stale records from the binding DBs. When a Gx session record is created, binding records for the session binding keys are also created. When each binding record is created, the binding record expiry time is initialized to the sum of the session creation time and the Stale Binding Expiry Minutes (that you can configure in Policy Builder).
A binding record is deleted when the corresponding session record is deleted. A binding may become stale if it cannot be deleted when its associated session record is deleted (this occurs typically due to database communication failures). The binding records are audited using a binding audit background process. If the audit process finds a binding record with an expiry time in the past, the binding record is checked for staleness by checking the session database for the corresponding session record. If an active session record is found, the binding record expiry time is updated with sum of current time and the Stale Binding Expiry Minutes. If an active session is not found, the binding is considered stale and is deleted. Note that the binding audit process does not perform any Diameter signaling with the GW before deletion.
The following figures illustrate the working of binding DB:
Rate Limits
Rate limit per process instance on Policy Director (lb) VM can be managed using this configuration.
Default is unchecked, that is, no rate limits for Diameter traffic (recommended setting).
If enabled, the following parameters can be configured under Rate Limits:
|
Parameter |
Description |
||
|---|---|---|---|
|
Rate Limit per Instance on Policy Director |
Allowable TPS on a single instance of policy server (QNS) process running on the Policy Director. Minimum: 1 Maximum: 5000
|
||
|
Result-Code in Response |
Indicates the error code that must be used while rejecting requests, due to rate limits being reached. Default: 3004 |
||
|
Error Message in Response |
Select the check box to drop the rate-limited messages without sending error response. If the check box is not selected, then the rate limited message are dropped with error response as configured. |
||
|
Drop Requests Without Error Response |
Select the check box to drop rate limited messages without sending error response. If the check box is unchecked, then the rate limited messages are dropped with error response as configured. To accommodate configuration to either drop the request or send an error response, a column Discard Behavior can be added under Peer Rate Limit Profile. The column may have one of the two possible values:
Default: Unchecked (recommended setting) For more information, refer to Peer Rate Limit.
|
Here is the list of the available combinations for rate limiting:
|
Rate Limiting Type |
With Error Code |
With Error Code and Error Message |
Without Error Code (Drop) |
|---|---|---|---|
|
Instance Level |
Yes |
Yes |
Yes |
|
Peer Level Egress |
Yes |
Yes |
Yes |
|
Peer Level Egress with Message Level |
Yes |
Yes |
Yes |
|
Egress Message Level (No Peer Level RL) |
Yes |
Yes |
Yes |
|
Peer Level Ingress |
Yes |
Yes |
Yes |
|
Peer Level Ingress with Message Level |
Yes |
Yes |
Yes |
|
Ingress Message Level (No Peer Level RL) |
Yes |
Yes |
Yes |
DRA Feature
Click DRA Feature check box to open the configuration pane.
The following parameters can be configured under DRA Feature:
|
Parameter |
Description |
||
|---|---|---|---|
|
Gx Session Tear Down On5065 |
By default, Gx Session Tear Down On5065 flag is enabled (recommended setting). When the PCRF responds with a Experimental Result Code of 5065 in AAAnswer on Rx Interface, DRA deletes its internal binding and session created for the transaction.A RAR with appropriate Session-Release-Cause AVP will also be sent to the PCEF.
|
||
|
Update Time Stamp On Success R A A |
When this check box is selected, session timestamp will be updated on receipt of success RAA (Result-Code: 2001) from PCEF. 1 Default is checked (recommended setting).
|
DRA Inbound Endpoints
The following parameters can be configured under DRA Inbound Endpoints:
|
Parameter |
Description |
||
|---|---|---|---|
|
Vm Host Name |
Host Name of the VM that hosts this CPS vDRA endpoint. |
||
|
Ip Address |
Address on which this CPS vDRA endpoint should bind to. |
||
|
Realm |
Realm of the CPS vDRA endpoint. |
||
|
Fqdn |
Fully Qualified Domain Name of the CPS vDRA end point. |
||
|
Transport Protocol |
Allows you to select either TCP' or 'SCTP' for the selected DRA endpoint. Default value is TCP. If the DRA/relay endpoint is to be configured for SCTP, the Transport Protocol should be selected as SCTP for those endpoints. |
||
|
Multi-Homed IPs |
This is a comma separated list of IP addresses that CPS vDRA will use to start the diameter stack with multi-homing enabled for SCTP transport. Diameter stack with TCP transport will still use the existing 'Local Bind Ip' field to specify any specific IP address for TCP stack. CPS vDRA will use the 'Local Bind Ip' to bring up SCTP stack and use it along with the ‘Multi Homing Hosts' to start the SCTP transport with multi-homing support.
The configuration for multi-homing is validated by netstat command on lb01:
|
||
|
Application |
Refers to 3GPP Application ID of the interface. You can select multiple applications on a peer connection. For example, S6a and SLg on a single IPv4/SCTP Multi-homed peer connection. |
||
|
Enabled |
Check to enable the endpoint. |
||
|
Base Port |
Refers to the port on which the CPS vDRA listens for incoming connections. |
An example configuration is shown below:

Relay Endpoints
The following parameters can be configured under Relay Endpoints:
|
Parameter |
Description |
|---|---|
|
Vm Host Name |
Host Name of the VM that hosts this Relay endpoint. |
|
Instance Id |
Instance Identifier is the ID of the current Instance. |
|
Ip Address |
Address on which this DRA endpoint should bind to. |
|
Port |
Port is the listening port for this instance. |
|
Fqdn |
Fully Qualified Domain Name of the DRA end point. |
|
Enabled |
Check to enable endpoint. |
An example configuration is shown below:
































Feedback