Product Documentation

Bind Points for a Policy

Oct 28, 2013

You can bind the policy to one of the following bind points:

  • A global policy bank. These are the request-time default, request-time override, response-time default, and response-time override policy banks, as described in "Order of Policy Evaluation."
  • A virtual server. Policies that you bind to a virtual server are processed after the global override policies and before the global default policies, as described in "Order of Policy Evaluation." Note that when binding a policy to a virtual server, you bind it to either request-time or response-time processing.
  • An ad-hoc policy label. A policy label is a name assigned to a policy bank. In addition to the global labels, the integrated cache has two built-in custom policy labels:
    • _reqBuiltinDefaults. This policy label, by default, is invoked from the request-time default policy bank.
    • _resBuiltinDefaults. This policy label, by default, is invoked from the response-time default policy bank.

    You can also define new policy labels. Policies bound to a user-defined policy label must be invoked from within a policy bank for one of the built-in bind points. For more information about creating a policy label, see "Configuring a Policy Label in the Integrated Cache." For more information about policy label invocation, see "Configuring a Policy Bank for Caching."

Important: You should bind a policy with an INVAL action to a request-time override or a response-time override bind point. To delete a policy, you must first unbind it.

Order of Policy Evaluation

For an advanced policy to take effect, you must ensure that the policy is invoked at some point during the NetScaler appliance’s processing of traffic. To specify the invocation time, you associate the policy with a bind point. The following are the bind points, listed in order of evaluation:

  • Request-time override. If a request matches a request-time override policy, by default request-time policy evaluation ends and the NetScaler appliance stores the action that is associated with the matching policy.
  • Request-time load balancing virtual server. If policy evaluation cannot be completed after all the request-time override policies are evaluated, the NetScaler appliance processes request-time policies that are bound to load balancing virtual servers. If the request matches one of these policies, evaluation ends and the NetScaler appliance stores the action that is associated with the matching policy.
  • Request-time content switching virtual server. Policies that are bound to this bind point are evaluated after request-time policies that are bound to load balancing virtual servers.
  • Request-time default. If policy evaluation cannot be completed after all request-time, virtual server-specific policies are evaluated, the NetScaler appliance processes request-time default policies. If the request matches a request-time default policy, by default request-time policy evaluation ends and the NetScaler appliance stores the action that is associated with the matching policy.
  • Response-time override. Similar to request-time override policy evaluation.
  • Response-time load balancing virtual server. Similar to request-time virtual server policy evaluation.
  • Response-time content switching virtual server. Similar to request-time virtual server policy evaluation.
  • Response-time default. Similar to request-time default policy evaluation.

You can associate multiple policies with each bind point. To control the order of evaluation of the policies associated with the bind point you configure a priority level. In the absence of any other flow control information, policies are evaluated according to priority level, starting with the lowest numeric priority value.

After all integrated caching policies have been evaluated, if there are conflicting actions specified in request-time and response-time policies, the NetScaler appliance determines the final action as specified in the table, "Actions That You Can Associate with an Integrated Caching Policy."

Note: Request-time policies for POST data or cookie headers must be invoked during request-time override evaluation, because the built-in request-time policies in the integrated cache return a NOCACHE action for POST requests and a MAY_NOCACHE action for requests with cookies. Note that you would associate MAY_CACHE or MAY_NOCACHE actions with a request-time policy that points to a parameterized content group. The response time policy determines whether the transaction is stored in the cache.