Bind policies using advanced policy

Last published : Sep 22, 2026
After defining a policy, the policy can be invoked by binding the policy to a bind point and specifying a priority level. You can bind the policy to only one bind point. A bind point can be global (applying to all configured virtual servers) or bind point can be a specific virtual server (either a load balancing or a content switching virtual server).
The order in which policies are evaluated determines the order in which they are applied. ADC features typically evaluate various policy banks in a particular order. Sometimes, however, other features can affect the order of evaluation. Within a policy bank, the order of evaluation depends on parameter values configured in the policies. Most features apply all the actions associated with a policy if the evaluated result matches with the data being processed.
Note:
Integrated caching feature is an exception.
Related information

Feature-specific differences in policy bindings

You can bind policies to a built-in, global bind points (or banks), specific virtual servers, or policy labels.
However, the NetScaler features differ in the type of bindings that are available. The following table summarizes policy bindings in NetScaler features that use policies.
Feature Name Virtual Servers Configured in the Feature Policies Configured in the Feature Bind Points Configured for the Policies Use of Policies in the Feature
DNS none DNS policies Global To determine how to perform DNS resolution for requests.
Content Switching (Note: This feature can support Advanced policies, but not both.) Content Switching (CS) Content Switching policies Content switching or cache redirection virtual server; Policy label To determine what server or group of servers is responsible for serving responses, based on characteristics of an incoming request. Request characteristics include device type, language, cookies, HTTP method, content type, and associated cache server.
Integrated Caching none Caching policies Global override, Global default, Policy label, load balancing, content switching, or SSL offload virtual server To determine whether HTTP responses can be stored in, and served from, the NetScaler appliance's integrated cache.
Responder none Responder policies Global override, Global default, Policy label, load balancing, content switching, or SSL offload virtual server To configure the behavior of the Responder function.
Rewrite none Rewrite policies Global override, Global default, Policy label, load balancing, content switching, or SSL offload virtual server To identify HTTP data that you want to modify before serving. The policies provide rules for modifying the data. For example, you can modify HTTP data to redirect a request to a selected server based on the address of the incoming request, or to mask server information in a response for security purposes.
URL Transform function in the Rewrite feature none Transformation policies Global override, Global default, Policy label To identify URLs in HTTP transactions and text files for evaluating whether a URL should be altered.
NetScaler Gateway (clientless VPN functions only) VPN server Clientless Access policies VPN Global, VPN server To determine how the NetScaler Gateway performs authentication, authorization, auditing, and other functions, and to define rewrite rules for general Web access using the NetScaler Gateway.

Bind points and order of evaluation

For a policy to take effect, you must ensure that the policy is invoked at some point during processing. To do so, you associate the policy with a bind point. The collection of policies that is bound to a bind point is known as a policy bank.
Following are the bind points that the NetScaler evaluates, listed in the typical order of evaluation within a policy bank
  1. Request-time override. When a request flows through a feature, the NetScaler first evaluates request-time override policies for the feature.
  2. Request-time Load Balancing virtual server. If policy evaluation cannot be completed after all the request-time override policies have been evaluated, the NetScaler processes request-time policies for load balancing virtual servers.
  3. Request-time Content Switching virtual server. If policy evaluation cannot be completed after all the request-time policies for load balancing virtual servers have been evaluated, the NetScaler processes request-time policies for content switching virtual servers.
  4. Request-time default. If policy evaluation cannot be completed after all request-time, virtual server-specific policies have been evaluated, the NetScaler processes request-time Advanced policies.
  5. Response-time override. At response time, the NetScaler starts with policies that are bound to the response-time override bind point.
  6. Response-time Load Balancing virtual server. If policy evaluation cannot be completed after all response-time override policies have been evaluated, the NetScaler process the response-time policies for load balancing virtual servers.
  7. Response-time Content Switching virtual server. If policy evaluation cannot be completed after all policies have been evaluated for load balancing virtual servers, the NetScaler process the response-time policies for content switching virtual servers.
  8. Response-time default. If policy evaluation cannot be completed after all response-time, virtual-server-specific policies have been evaluated, the NetScaler processes response-time Advanced policies.

Policy evaluation across features

In addition to evaluate policies within a feature, if you bind policies to a content switching virtual server, it is important that these policies are evaluated before other policies. Binding a policy to a content switching virtual server produces a different result in NetScaler versions 9.0.x and later than in 8.x versions. In NetScaler 9.0 and later versions, evaluation occurs as follows:
  • Content switching policies are evaluated before other policies. If a content switching policy evaluates to TRUE, the target load balancing virtual server is selected.
  • If all content switching policies evaluate to FALSE, the default load balancing virtual server under the content switching VIP is selected.
After a target load balancing virtual server is selected by the content switching process, policies are evaluated in the following order:
  1. Policies that are bound to the global override bind point.
  2. Policies that are bound to the default load balancing virtual server.
  3. Policies that are bound to the target content switching virtual server.
  4. Policies that are bound to the global default bind point.
To be sure that the policies are evaluated in the intended order, follow these guidelines:
  • Make sure that the default load balancing virtual server is not directly reachable from the outside; for example, the virtual server IP address can be 0.0.0.0.
  • To prevent exposing internal data on the load balancing default virtual server, configure a policy to respond with a "503 Service Unavailable" status and bind it to the default load balancing virtual server.

Entries in a policy bank

Each entry in a policy bank has, at minimum, a policy and a priority level. You can also configure entries that change the priority-based evaluation order, and you can configure entries that invoke external policy banks. Policy bank is the group of policies which are bound at a particular bind point and which can be evaluated for some traffic. If some policies are bound to LB vserver of an HTTP protocol type, then LB vserver is a policy bank. And the policies bound to this policy bank can be evaluated for the HTTP traffic. If some rewrite policies are bound to rewrite global at DNS_REQ_OVERRIDE bindpoint, then DNS_REQ_OVERRIDE bindpoit will be a policy bank where some policies are bound.
Since, in policy label we can bind number of policies, so policy label is also a policy bank.
The policy banks are differentiated based on the protocols, conditions, and priorities. Suppose, you have 2 LB virtual server. One is of type HTTP and another is of type DNS. And, different policies are bound to these virtual servers. So, both virtual servers are the policy banks, but policies bound to one of the policy bank are evaluated for HTTP traffic. The policies bound to another policy bank are evaluated for DNS traffic. For each policy evaluation, a rule is evaluated. For NOPOLICY also, a rule true is evaluated. If a user wants to invoke a policy label for all the traffic, then the user can use NOPOLICY as its rule true.
The following table summarizes each entry in a policy bank.
Policy Name Priority Goto Expression Invocation Type Policy Bank to Be Invoked
The policy name, or a "dummy" policy. An integer. Optional. If not configured, ADC takes the default gotoPriorityExpression value. It identifies the next policy to be evaluated if the current policy is evaluated to true, or ends any further evaluation Optional. Indicates that an external policy bank is invoked. The field restricts the choices to a global policy label or a virtual server. Optional. Used with Invocation Type. This is the label for a policy bank or a virtual server name. The NetScaler returns to the current bank after processing the external bank.
If the policy evaluates to TRUE, the NetScaler stores the action that is associated with the policy. Add evaluate next policy based on the gotoPriorityExpression field value. If the policy evaluates to FALSE, the NetScaler evaluates the next policy. If the policy is neither TRUE nor FALSE, the NetScaler uses the associated Undef (undefined) action. Invocation type designates a policy bank type. The value can be one of the following:
  • Request Vserver: Invokes request-time policies that are associated with a virtual server.
  • Response Vserver: Invokes response-time policies that are associated with a virtual server.
  • Policy label: Invokes another policy bank, as identified by the policy label for the bank. GotoPriorityExpression field values:
  • Goto NEXT - Go to the policy with the next higher priority
  • Goto END - End evaluation
  • Goto # - An expression that produces the priority number of the next policy to be evaluated. The Goto can only proceed forward in a policy bank.
  • Goto USE_INVOCATION_RESULT – Applicable if this policy invokes another policy label. If the final goto in the invoked policy label has a value of END, the evaluation stops. If the final goto is anything other than END, the current policy label performs a NEXT. If you omit the Goto expression, it is the same as specifying END. Example of a Policy bank that uses Goto expression:
Policy Name Priority Goto Invocation Policy Bank to be Invoked
ClientCertificatePolicy 100 300 None None
SubnetPolicy 200 Next None None
NOPOLICY 300 USE INVOCATION RESULT Request Server My_Request_VServer
NOPOLICY 350 USE INVOCATION RESULT Policy Label My_Policy_Label
WorkingHoursPolicy 400 END None None

Evaluation order within a policy bank

Within a policy bank, the evaluation order depends on the following parameters:
  • A priority.
    The most minimal amount of information about evaluation order is a numeric priority level. The lower the number, the higher the priority.
  • A Goto expression.
    If supplied, the Goto expression indicates the next policy to be evaluated, typically within the same policy bank. Goto expressions can only proceed forward in a bank. To prevent looping, a policy bank configuration is not valid if a Goto statement point backwards in the bank.
  • Invocation of other policy banks.
    Any entry can invoke an external policy bank. The NetScaler provides a built-in entity named NOPOLICY that does not have a rule. You can add a NOPOLICY entry in a policy bank when you want to invoke another policy bank, but do not want to process any other rules prior to the invocation. You can have multiple NOPOLICY entries in multiple policy banks.
Values for a Goto expression are as follows:
  • NEXT.
    This keyword selects the policy with the next higher priority level in the current policy bank.
  • An integer.
    If you supply an integer, it must match the priority level of another policy in the current policy bank.
  • END.
    The keyword stops evaluation after processing the current policy, and no additional policies in this bank are processed.
  • Blank.
    If the Goto expression is empty, it is the same as specifying END.
  • A numeric expression.
    This is an advanced policy expression that resolves to a priority number for another policy in the current bank.
  • USE_INVOCATION_RESULT.
    The phrase can be used only if you are invoking an external policy bank. Entering the phrase causes the NetScaler to perform one of the following actions:
    • If the final Goto in the invoked policy bank has a value of END or is empty, the invocation result is END, and evaluation stops.
    • If the final Goto expression in the invoked policy bank is anything other than END, the NetScaler performs a NEXT.
The following table illustrates a policy bank that uses Goto statements and policy bank invocations.
Policy Name Priority Goto Invocation Policy Bank to Be Invoked --- -------- ---- ---- ----
ClientCertificatePolicy (rule: does the request contain a client certificate?) 100 300 None None
SubnetPolicy (rule: is the client from a private subnet?) 200 NEXT None None NOPOLICY 300 USE INVOCATION RESULT Request virtual server My_Request_VServer NOPOLICY 350 USE INVOCATION RESULT Policy Label My_Policy_Label
WorkingHoursPolicy (rule: is it working hours?) 400 END None None
Table 3. Example of a Policy Bank That Uses Gotos and External Bank Invocations

How policy evaluation ends

Evaluation of a policy bank ends when the NetScaler appliance runs one of the following steps:
  • If a policy evaluation is "TRUE," it invokes an external policy bank and its Goto statement value is "USE_INVOCATION_RESULT," and if another policy in the external policy bank also evaluates "TRUE" and Goto statement value is "END," then after returning from the external policy bank, no further policy will be evaluated.
  • An external policy bank is invoked, its evaluation returns an END, and the Goto statement uses a value of USE_INVOCATION_RESULT or END. Evaluation continues with the next policy bank for this feature. For example, if the current bank is the request-time override bank, the NetScaler next evaluates request-time policy banks for the virtual servers.
  • The NetScaler has walked through all the policy banks in this feature, but has not found an END.
If this is the last entry to be evaluated in this policy bank, the NetScaler proceeds to the next feature.

How features use actions after policy evaluation

After evaluating all relevant policies for a particular data point (for example, an HTTP request), the NetScaler stores all the actions that are associated with any policy that matched the data.
For most features, all the actions from matching policies are applied to a traffic packet as it leaves the NetScaler. The Integrated Caching feature only applies one action: CACHE or NOCACHE. This action is associated with the policy with the lowest priority value in the "highest priority" policy bank (for example, request-time override policies are applied before virtual server-specific policies).