Policy Tracing and Execution Analyzer
Cisco Policy Server comes with a set of utilities to actively monitor and trace policy execution. These utilities interact with the core policy server and the mongo database to trigger and store traces for specific conditions.
Architecture
The policy tracing and execution analyzer is 3-tier architecture:
-
Tier 1 — command line utilities to manage the policy trace generation and extract policy traces.
-
Tier 2 — policy server creation of policy traces using triggers defined in Tier 1.
-
Tier 3 — storage of the policy traces in a MongoDB.
Administering Policy Traces
All commands are
located on the Control Center virtual machine within
/var/qps/bin/control directory. There are two main
scripts which can be used for tracing:
trace_ids.sh
and
trace.sh
.
-
The
trace_ids.sh
script maintains all rules for activating and deactivating traces within the system. -
The
trace.sh
script allows for the real time or historical retrieval of traces.
Before running
trace_ids.sh
and
trace.sh
, confirm which database you are using for
traces. For more information, refer to
Policy Trace Database.
If no database has been configured, then by default the scripts connects to
primary database member of SPR-SET1.
Managing Trace Rules using trace_ids.sh
Running
trace_ids.sh
with
-h arguments produces a help text describing the
capabilities of the script.
/var/qps/bin/control/trace_ids.sh -h
Usage:
/var/qps/bin/control/trace_ids.sh -i <specific id> -d sessionmgr01:27719/policy_trace
/var/qps/bin/control/trace_ids.sh -i <specific id> -c <command code> -d sessionmgr01:27719/policy_trace
/var/qps/bin/control/trace_ids.sh -r <specific id> -d sessionmgr01:27719/policy_trace
/var/qps/bin/control/trace_ids.sh -x -d sessionmgr01:27719/policy_trace
/var/qps/bin/control/trace_ids.sh -l -d sessionmgr01:27719/policy_trace
Note |
By default , if -d option is not provided then the script connects to primary database member of SPR-SET1. If you are not using the SPR database, you need to find out the which database you are using. To find out which database you are using, refer to Policy Trace Database. Make sure to update the commands mentioned in Step 1 to Step 5 accordingly. |
This script starts a selective trace and outputs it to standard out.
Procedure
Step 1 |
Specific audit ID tracing:
|
Step 2 |
Specific audit ID tracing with specific command codes:
<command code> is case sensitive and is used to trace specific control command message. For example, Gx_CCR-I, Sh_UDR and so on. You can add multiple command code separated by comma. |
Step 3 |
Remove trace for specific audit ID:
|
Step 4 |
Remove trace for all IDs:
|
Step 5 |
List all IDs under trace:
Adding a specific audit ID for tracing requires running the command with the -i argument and passing in a specific ID. The policy server matches the incoming session with the ID provided and compares this against the following network session attributes:
If an exact match is found then the transaction are traced. Spaces and special characters are not supported in the audit ids.
|
Usage:
Usage with SPR-SET as database:
#./trace_ids.sh -l
MongoDB shell version: 2.6.3
connecting to: sessionmgr01:27720/policy_trace
112345
MongoDB shell version: 2.6.3
connecting to: sessionmgr01:27720/policy_trace
null
Usage with -d option:
#./trace_ids.sh -l -d sessionmgr01:27717/policy_trace
MongoDB shell version: 2.6.3
connecting to: sessionmgr01:27717/policy_trace
874838
MongoDB shell version: 2.6.3
connecting to: sessionmgr01:27717/policy_trace
null
Situations where traces are generated automatically
The following criteria cause the system to generate a trace regardless of whether the id is present in the trace database or not:
-
If there is an AVP with the code: audit_id, audit-id, auditid. In this case, the traces are stored in the database with the value of the AVP.
-
If there is a subscriber attribute (USuM AVP) with a code of audit-policy and a value of “true”. In this case, the traces are stored using the credentials stored for the subscriber.
-
If an error is triggered internally.
Note
An error is defined as an internal processing error (e.g. database failure or other failure) and is not a failure message code.
Managing Trace Results using trace.sh
Running
trace.sh
with
-h
arguments produce a help text describing the capabilities of the script:
/var/qps/bin/control/trace.sh
-h
Usage:
/var/qps/bin/control/trace.sh -i <specific id> -d sessionmgr01:27719/policy_trace
/var/qps/bin/control/trace.sh -x <specific id> -d sessionmgr01:27719/policy_trace
/var/qps/bin/control/trace.sh -a -d sessionmgr01:27719/policy_trace
/var/qps/bin/control/trace.sh -e -d sessionmgr01:27719/policy_trace
/var/qps/bin/control/trace.sh -f -d sessionmgr01:27719/policy_trace
/var/qps/bin/control/trace.sh -h
Note |
By default , if -d option is not provided then the script connects to primary database member of SPR-SET1. If you are not using the SPR database, you need to find out the which database you are using. To find out which database you are using, refer to Policy Trace Database. Make sure to update the commands mentioned in Step 1 to Step 4 accordingly. |
This script starts a selective trace and outputs it to standard out.
Procedure
Step 1 |
Specific audit ID tracing:
Specifying the -i argument for a specific ID causes a real time policy trace to be generated while the script is running. Users can redirect this to a specific output file using standard Linux commands. |
Step 2 |
Dump all traces for specific audit ID:
Specifying the -x argument with a specific ID, dumps all historical traces for a given ID. Users can redirect this to a specific output file using standard Linux commands. |
Step 3 |
Trace all:
Specifying the -a argument causes all traces to output in real time policy trace while the script is running. Users can redirect this to a specific output file using standard Linux commands. |
Step 4 |
Trace all errors:
Specifying the -e argument causes all traces triggered by an error to output in real time policy trace while the script is running. Users can redirect this to a specific output file using standard Linux commands. |
Step 5 |
Flush out the trace collection:
|
Policy Trace Database
The default location of the policy trace database is the administrative database and can be optionally specified in the trace database fields. These fields are defined at the cluster level in the system configurations.
Note |
Make sure to run all trace utility scripts from /var/qps/bin/control directory only. |
Configure Traces Database in Policy Builder
Procedure
Step 1 |
Log in to the Policy Builder. |
||||||||
Step 2 |
From left pane, open up the name of your system and select the required cluster. |
||||||||
Step 3 |
From right pane, select the check box for Trace Database. The following table provides the parameter descriptions under Trace Database check box:
|