Bind policies using advanced policy
After defining a policy, you indicate when the policy is to be activated by binding the policy to a bind point. Then specify a priority level.
Bind a policy to only one bind point. A bind point can be global. The global bind point applies to the virtual servers that is configured. Or, a bind point can be specific to a particular virtual server; either a load balancing or a content switching virtual server. Not all bind points are available for all features.
The order in which policies are evaluated determines the order in which the policies are applied. The features typically evaluate various policy banks in a particular order.
Sometimes, other features can affect the order of evaluation within a policy bank. The order of evaluation depends on the values of parameters configured in the policies. Most features apply actions associated with policies whose evaluation results in a match with the data that is being processed. The integrated caching feature is an exception.
Feature-specific differences in policy bindings
You can bind policies to built-in, global bind points (or banks), to virtual servers, or to policy labels.
However, the NetScaler features differ for the types of bindings that are available. The following table summarizes how you use policy bindings in various 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. This modification is 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 in evaluating whether a URL must be altered. |
| NetScaler Gateway (clientless VPN functions only) | VPN server | Clientless Access policies | VPN Global, VPN server | To determine how the NetScaler Gateway does: 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 confirm that the policy is activated 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
- Request-time override. When a request flows through a feature, the NetScaler first evaluates request-time override policies for the feature.
- Request-time Load Balancing virtual server. If the policy evaluation is incomplete after the request-time override policy evaluation, the NetScaler processes request-time policies for load balancing virtual servers.
- Request-time Content Switching virtual server. If policy evaluation is incomplete after the request-time policies for load balancing virtual servers evaluation, the NetScaler processes request-time policies for content switching virtual servers.
- 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.
- Response-time override. At response time, the NetScaler starts with policies that are bound to the response-time override bind point.
- 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.
- Response-time Content Switching virtual server. If a policy evaluation is incomplete after the policy evaluation for load balancing virtual servers, the NetScaler process the response-time policies for content switching virtual servers.
- 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
If a policy is bound to a content switching virtual server. In-addition to the policy evaluation within a feature. The policies are evaluated before other policies.
Binding a policy to a content switching vserver 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 vserver is selected.
- If all content switching policies evaluate to FALSE, the default load balancing vserver under the content switching VIP is selected.
After a target load balancing vserver is selected by the content switching process, policies are evaluated in the following order:
- Policies that are bound to the global override bind point.
- Policies that are bound to the default load balancing vserver.
- Policies that are bound to the target content switching vserver.
- 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 vserver is not directly reachable from the outside; for example, the vserver IP address can be 0.0.0.0.
- To prevent exposing internal data on the load balancing default vserver, configure a policy to respond with a “503 Service Unavailable” status and bind it to the default load balancing vserver.
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.
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 named NOPOLICY. The NOPOLICY entry controls evaluation flow without processing a rule. | An integer. | Optional. Identifies the next policy in the bank to evaluate, or ends any further evaluation | Optional. Indicates that an external policy bank will be invoked. This 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. 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.
Evaluation order within a policy bank
Within a policy bank, the evaluation order depends on the following items:
-
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 points 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. The Policies are evaluated in priority order from lower numbered priority to higher numbered priority.
-
An integer.
If you supply an integer, it must match the priority level of another policy in the current policy bank.
-
END.
This 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.
This phrase can be used only if you are invoking an external policy bank. Entering this 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 vserver | 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 one of the following takes place:
-
A policy evaluates to TRUE and its Goto statement value is END.
No further policies or policy banks in this feature are 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 encountered 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).