Policy definition problems

If you do not see the expected results when defining policies, use the pasearch command to display policies (active or inactive) known by Policy Agent. Use this command to check whether policies are active or inactive and whether they contain the specifications that were expected.

Guidelines:

Policy rules with complex conditions (using CNF/DNF logic) are processed by Policy Agent to arrive at a "working" set of conditions. These are the only conditions displayed by default using pasearch (use the -o option to display the original set of conditions as specified).
The pasearch output displays overall time ranges and time of day ranges in UTC format, as well as the specified time zone, if other than UTC.

You can dynamically refresh Policy Agent so that it can pick up any changes made, including changes to policies on the LDAP server (or configuration file). Use the MODIFY procname, REFRESH command to restart Policy Agent from the beginning of its configuration files, or MODIFY procname, UPDATE command to re-read the configuration files.

To check whether QoS policies are being installed and used correctly, use the NETSTAT commands. Use the NETSTAT SLAP or netstat -j command to display active QoS policy statistics for QoS policies installed in the stack, as opposed to the policies in Policy Agent. The NETSTAT ALL or netstat -A command shows which QoS policy rule (if any) is mapped to active connections.

For further diagnosis of the following policy types, see the topics listed below:

Intrusion Detection Services (IDS) policy definition problems
See Diagnosing intrusion detection problems for more information about diagnosing IDS policy definition problems.
IPSec policy definition problems
See Diagnosing IP security and defensive filter problems for more information about diagnosing IPSec policy definition problems.
Application Transparent Transport Layer Security (AT-TLS) policy definition problems
See Diagnosing Application Transparent Transport Layer Security (AT-TLS) for more information about diagnosing AT-TLS policy definition problems.

You might encounter some of the policy definition problems listed in Table 1.

Table 1. Policy definition problems
Problem	Cause/action	Symptom
GSKCMS31 DLL not found	Policy Agent must have access to the GSKCMS31 DLL at run time. This is needed for IPSec KeyExchange policies. The IPSec policy being validated failed. Policy Agent accesses the GSKCMS31 DLL using the LIBPATH environment variable. Check that the LIBPATH environment variable is specified, and that it contains the directory in which the GSKCMS31 DLL resides. This is normally /usr/lib.	Policy Agent logs a system error message and object error message.
GSKSSL DLL not found	Policy Agent must have access to the GSKSSL DLL at run time. This is needed for AT-TLS policies. Policy Agent loads the AT-TLS policies into the TCP/IP stack, but because Policy Agent was unable to verify with System SSL that the configured cipher suites were valid, they are validated when the TLS/SSL environment is initialized for TCP/IP connections. If any values are not valid within the cipher suites, this could result in TCP/IP connections failing. Policy Agent accesses the GSKSSL DLL using the LIBPATH environment variable. Check that the LIBPATH environment variable is specified, and that it contains the directory in which the GSKSSL DLL resides. This is normally /usr/lib.	Policy Agent logs a system error message and warning message.
Version 1 QoS policies to version 2 QoS policies conversion Semantic differences exist between version 1 and version 2 policy definitions. Restriction: Currently only version 2 semantics are supported. When the policies are processed by Policy Agent, version 1 policy semantics are converted to version 2 semantics. See Note 1.	The following circumstances might lead to problems: When converting such policies to version 2, be sure to also swap the source and destination attributes when the version 1 Direction is Inbound. The specified interface is also related to Direction. In version 1 only a single interface is specified, while both inbound and outbound interfaces are specified in version 2. When migrating a version 1 policy, be sure to specify an InboundInterface for Direction Inbound, and an OutboundInterface for Direction Outbound. When converting version 1 rules with Direction Both specified, create two version 2 rules, one for each direction. Also, specify InboundInterface for the inbound rule and OutboundInterface for the outbound rule, if the version 1 rule specified both Interface and Direction Both. When converting policies with different PolicyScope values, be sure to logically merge the scopes in the version 2 policy action. Any such merge should always result in a PolicyScope value of Both.	Discrepancies between version 1 and version 2 policy definitions.
Policy groups or rules are discarded when defined on an LDAP server.	Policy groups and policy rules defined on an LDAP server can refer to other LDAP objects (such as policy actions or time periods). When any referenced object cannot be found on the LDAP server, the referencing object is discarded. Specify the correct reference Distinguished Names on LDAP objects that reference other objects.	Discarded policy groups or rules
Policies with complex conditions (using CNF or DNF) are not mapping correctly.	Because some conditions are logically ANDed, a result that is not valid can occur. For example, two or more distinct interfaces cannot be ANDed and still be true. Or two non-overlapping port ranges also cannot be ANDed. Policy Agent tries to detect these types of errors and discard the policy rules with an error message, but there are cases that cannot be detected (for example, logical ANDs between CNF/DNF levels, or when negated conditions are used). In these cases, a policy rule can be installed that can never be true. Similar problems could occur when ORing conditions. For example, a very broad condition might map much more traffic than was intended, simply because it is one of a set of conditions that is ORed together. Use the pasearch command to display policy rules with complex conditions. By default, the "working" set of conditions is displayed (after Policy Agent has attempted to collapse and summarize the complex conditions). This working set includes the summary of each condition level, as well as the overall "global" summary condition. Use the pasearch -o option to also display the original set of specified conditions. This helps to show how the working set was derived.	Difficultly configuring complex policy conditions using CNF or DNF.
Wrong policy being mapped to traffic	At times, two or more policy rules are logically mapped to the same set of traffic packets. When this happens, the rule with the highest weight is selected. The weight depends on two factors. When the policy rule priority is not specified, the weight depends on the number of attributes specified in the policy conditions. When policy rule priority is specified, the weight is the specified priority plus 100, which is always higher than the weight derived from counting the number of attributes. If more than one rule is found with the same weight, the first such rule is selected to be mapped. Be sure to specify priority in policy rules to better control situations where multiple rules map to the same set of traffic.	Policy rule priority settings are inadequate to control situations where multiple rules map to the same set of traffic.
Policies are not installed in the TCP/IP stack.	Perform the following actions, based on what caused the problem: The stack in which policies should be installed must be configured using a TcpImage statement in the Policy Agent configuration file. The time periods configured in the policies must be correct. Verify the specifications of the day of week and time of day are correct. Verify that the specified time zone is correct. For time zones other than local time, the specified time periods might not be currently active. If the stack was started or restarted after Policy Agent was started, check that the temporary file (/tmp/`tcpname`.Pagent.tmp) used by the stack to inform Policy Agent of restarts has not been deleted. Perform the following steps to diagnose QoS problems: Issue pasearch -q to see all QoS policies that are active in Policy Agent. See z/OS Communications Server: IP System Administrator's Commands for more information about the pasearch -q command. If you are running multiple stacks, ensure that pasearch is reporting on the stack you are interested in. Issue NETSTAT SLAP or netstat -j command to see how the stack mapped your QoS statement. See z/OS Communications Server: IP System Administrator's Commands for more information about the netstat command. If you are running multiple stacks, ensure that your resolver configuration correctly identifies the stack you are interested in. Ensure that your QoS policies are correctly defined. For more information about policy-based networking, see z/OS Communications Server: IP Configuration Guide. See Diagnosing intrusion detection problems for more information about diagnosing IDS policy definition problems. See Diagnosing IP security and defensive filter problems for more information about diagnosing IP security problems. See Diagnosing Application Transparent Transport Layer Security (AT-TLS) for more information about diagnosing AT-TLS policy definition problems.	Unexpected or missing set of policies.
QoS policies not mapping to the expected traffic	Incorrectly specified selection criteria on the PolicyRule statement for the policy. If you think data traffic should be mapped to certain policies, but is not, check to make sure you have specified the selection criteria correctly on the PolicyRule statement for the policy. For example, TCP policies are mapped on a per connection basis, whereas for UDP and RAW, the policy is mapped on a per packet basis. As an example of TCP traffic, consider an ftp GET request from a remote client. The connection request from the client is mapped as inbound data, while the data flow is mapped as outbound data. You can use either source or destination fields in the policy rule to map both traffic flows, but the definitions must be consistent with this way of mapping. Check that the policy is not unnecessarily restrictive in its specification of IP addresses and ports. For RSVP scoped policies, remember that the policy is only mapped to data traffic while an RSVP reservation is in effect.	A blank policy rule name is displayed for an active connection using the NETSTAT ALL or netstat -A command.
Timing windows when switching policies based on time	If policy rules are defined such that different sets of policies are activated at different times (for example at each shift), be aware of nonoverlapping vs. overlapping time specifications. For example, if Rule1 is active from 00:00 to 07:29, and Rule2 is active from 07:30 to 04:00, there is a one minute interval gap between these 2 rules. Because the minimum time resolution used by Policy Agent is one minute, there is a period of one minute when neither policy is active.	Different sets of policies are activated at different times (for example at each shift).
Policies defined in an MVS™ data set are not being installed.	When an MVS data set is used to define policies, ensure that sequence numbers are not part of the file, because these cause parsing errors. In ISPF, use the NUMBER OFF and UNNUM or NUMBER OFF or UNNUM commands to remove the sequence numbers.	Parsing errors occur.
Note 1. Be aware of the following processing behavior: In version 1, source always meant local, while destination always meant remote. In version 2, source and destination mean exactly what they imply. When version 1 policies specify Direction Inbound, the semantics for source and destination are opposite between the two versions. As a result, although the specified source and destination attributes are displayed as they are specified by the pasearch command, the attributes are swapped when the policies are installed in the stack. Similarly, when Direction Both is specified in a version 1 policy, the following policies are installed in the stack: Outbound direction with source and destination attributes intact Inbound direction with the attributes swapped PolicyScope values exist in both the policy rule and action in version 1, but only in the policy action in version 2. For any policies that specified different PolicyScope values for the rule and the associated action in version 1, the scope values are merged in the policy action. For example, if the rule specified PolicyScope Both, and the associated action specified PolicyScope DataTraffic, the resulting scope value in the policy action is Both.