-
Getting Started with NetScaler
-
Solutions for Telecom Service Providers
-
Load Balance Control-Plane Traffic that is based on Diameter, SIP, and SMPP Protocols
-
Provide Subscriber Load Distribution Using GSLB Across Core-Networks of a Telecom Service Provider
-
Authentication, authorization, and auditing application traffic
-
Basic components of authentication, authorization, and auditing configuration
-
-
Web proxy support for outbound calls to IDP or third party endpoints
-
Web Application Firewall protection for VPN virtual servers and authentication virtual servers
-
On-premises NetScaler Gateway as an identity provider to Citrix Cloud™
-
Authentication, authorization, and auditing configuration for commonly used protocols
-
Troubleshoot authentication and authorization related issues
-
Troubleshoot authentication, authorization and auditing issues
-
Configure EULA as an authentication factor in NetScaler nFactor system
-
Configure periodic Endpoint Analysis scan as a factor in nFactor authentication
-
Configure post-authentication Endpoint Analysis scan as a factor in NetScaler nFactor authentication
-
Configure pre-authentication Endpoint Analysis scan as a factor in nFactor authentication
-
Configure pre-auth and post-auth EPA scan as a factor in nFactor authentication
-
Configure prefill user name from certificate in NetScaler nFactor authentication
-
Configure protected user as an authentication factor in NetScaler nFactor authentication
-
Localize error messages generated by NetScaler nFactor system
-
Configure NetScaler Gateway preauthentication EPA scan for the domain check
-
-
-
-
-
-
-
Configure DNS resource records
-
Configure NetScaler as a non-validating security aware stub-resolver
-
Jumbo frames support for DNS to handle responses of large sizes
-
Caching of EDNS0 client subnet data when the NetScaler appliance is in proxy mode
-
Use case - configure the automatic DNSSEC key management feature
-
Use Case - configure the automatic DNSSEC key management on GSLB deployment
-
-
-
Source IP address whitelisting for GSLB communication channels
-
Use case: Deployment of domain name based autoscale service group
-
Use case: Deployment of IP address based autoscale service group
-
-
Persistence and persistent connections
-
Advanced load balancing settings
-
Gradually stepping up the load on a new service with virtual server–level slow start
-
Protect applications on protected servers against traffic surges
-
Retrieve location details from user IP address using geolocation database
-
Use source IP address of the client when connecting to the server
-
Use client source IP address for backend communication in a v4-v6 load balancing configuration
-
Set a limit on number of requests per connection to the server
-
Configure automatic state transition based on percentage health of bound services
-
-
Use case 2: Configure rule based persistence based on a name-value pair in a TCP byte stream
-
Use case 3: Configure load balancing in direct server return mode
-
Use case 6: Configure load balancing in DSR mode for IPv6 networks by using the TOS field
-
Use case 7: Configure load balancing in DSR mode by using IP Over IP
-
Use case 10: Load balancing of intrusion detection system servers
-
Use case 11: Isolating network traffic using listen policies
-
Use case 12: Configure Citrix Virtual Desktops for load balancing
-
Use case 13: Configure Citrix Virtual Apps and Desktops for load balancing
-
Use case 14: ShareFile wizard for load balancing Citrix ShareFile
-
Use case 15: Configure layer 4 load balancing on the NetScaler appliance
-
-
-
-
Support for hybrid Post Quantum cryptography on the frontend
-
-
Create a certificate signing request and use SSL certificates on a NetScaler appliance
-
Configure SSL acceleration with HTTP on the front end and SSL on the back end
-
Export certificates used on a NetScaler appliance as PFX file
-
Configure SSL monitoring when client authentication is enabled on the back-end service
-
Configure SSL action to forward client traffic if a cipher is not supported on the ADC
-
Configure synchronization of files in a high availability setup
-
-
-
Authentication and authorization for System Users
-
-
-
Configuring a CloudBridge Connector Tunnel between two Datacenters
-
Configuring CloudBridge Connector between Datacenter and AWS Cloud
-
Configuring a CloudBridge Connector Tunnel Between a Datacenter and Azure Cloud
-
Configuring CloudBridge Connector Tunnel between Datacenter and SoftLayer Enterprise Cloud
-
Configuring a CloudBridge Connector Tunnel Between a NetScaler Appliance and Cisco IOS Device
-
CloudBridge Connector Tunnel Diagnostics and Troubleshooting
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
Functions
Functions are a basic building block of programming – they are a convenient and powerful way to group statements that perform a task. They are the interface between the NetScaler appliance and extension code. For policies, you define policy extension functions. For protocols, you implement callback functions for the protocol behaviors. Functions consist of function definitions that specify what values are passed into and out of the function and what statements are run for the function, and function calls, which run functions with specific input data and get results from the function.
Protocol behavior callback functions
The TCP client behavior consists of a callback function (on_data) that processes TCP client data stream events. To implement Message Based Load Balancing (MBLB) for a TCP based protocol, you can add code for this callback function to process the TCP data stream from the client and parse the byte stream into protocol messages.
The callback functions in a behavior are called with a context, which is the processing module state. The context is the instance of the processing module. For example, the TCP client behavior callbacks are called with different contexts for different client TCP connections.
In addition to the context, the behavior callbacks can have other arguments. Usually the rest of the arguments are passed as payload, which is the collection of all the arguments. So, the programmable processing module instances can be seen as a combination of instance state plus event callback functions, that is, the context plus behavior. And the traffic flows through the pipeline as event payload.
Prototype of TCP client callback function:
Function client on_data (ctxt, payload)
//.code
end
<!--NeedCopy-->
Where,
- ctxt - TCP client processing context
- payload – event payload
- payload.data - TCP data received, available as a stream of bytes
Policy extension functions
Since the NetScaler® policy expression language is typed, the definition of an extension function must specify the types of its inputs and its return value. The Lua function definition has been extended to include these types:
function self-type: function-name(parameter1: parameter1-type, and so on): return-type
statements
end
<!--NeedCopy-->
Where,
The types are NSTEXT, NSNUM, NSBOOL, or NSDOUBLE.
Self-type is the type of the implicit self-parameter that is passed into the function. When the extension function is used in a NetScaler policy expression, this is the value generated by the expression to the left of the function. Another way to view this is that the function extends that type in the NetScaler policy language.
The parameter-types are the types of each parameter specified in the extension function call in the policy expression. An extension function can have zero or more parameters.
Return-type is the type of the value returned by the extension function call. It is the input to the part of the policy expression, if any, to the right of the function, or else is the value of the expression result.
Example:
function NSTEXT:COMBINE_HEADERS() : NSTEXT
Use of the extension function in a policy expression:
HTTP.REQ.FULL_HEADER.AFTER_STR("HTTP/1.1\r\n").COMBINE_HEADERS()
Here the self-parameter is the result of HTTP.REQ.FULL_HEADER.AFTER_STR("HTTP/1.1\r\n"), which is a text value. The result of the COMBINE_HEADERS() call is text, and since there is nothing to the right of this call, the result of the entire expression is text.
Local function definition
Besides extension functions, no global functions can be defined in an extension file. But local functions can be defined within extension functions using the normal Lua function statement. This declares the name of the function and the names of its parameters (also known as arguments), and like all declarations in Lua, does not specify any types. The syntax for this is:
local function function-name(parameter1-name, parameter2-name, and so on)
statements
end
<!--NeedCopy-->
The function and parameter names are all identifiers. (The function name is actually a variable and the function statement is shorthand for local function-name = function(parameter1, and so on), but you don’t have to understand this subtlety to use functions.)
Note that and so on is used here for continuation of the pattern of parameter names instead of the usual … . This is because … itself actually means a variable parameter list, which will not be discussed here.
Function body and return
The block of statements between the function and end statements is the function body. In the function body, the function parameters act like local variables, with values supplied by the function calls, as described previously.
The return statement supplies values to be returned to the caller of the function. It must appear at the end of a block (in a function, if then, for loop, and so on. It can be in its own block do return … end). It specifies no, one, or more than one return values:
return -- returns nil
return expression -- one return value
return expression1, expression2, ... -- multiple return values
<!--NeedCopy-->
Examples:
local function fsum(a)
local sum = 0
for i = 1, #a do
sum = sum + a[i]
end
return sum
end
Local function fsum_and_average(a)
local sum = 0
for i = 1, #a do
sum = sum + a[i]
end
return sum, sum/#a
end
<!--NeedCopy-->
Function calls
A function call runs the body of a function, supplying values for its parameters, and receiving results. The syntax for a function call is function-name(expression1, expression2, and so on), where the function parameters are set to the corresponding expressions. The number of expressions and parameters need not be the same. If there are fewer expressions than parameters, the remaining parameters are set to nil. So you can make one or more parameters at the end of the call optional, and your function can check if they are specified by checking if they are not nil. A common way to do this is with the OR operation:
function f(p1, p2) -- p2 is optional
p2 = p2 or 0 -- if p2 is nil, set to a default of 0
. . .
end
<!--NeedCopy-->
If there are more expressions than parameters, the remaining expression values are ignored.
As noted previously, functions can return multiple values. These returns can be used in a multiple assignment statement. Example:
local my_array = {1, 2, 3, 4}
local my_sum, my_ave = sum_and_average(my_array)
<!--NeedCopy-->
Iterator functions and generic for loops
Now that we have introduced functions, we can talk about generic for loops. The syntax for the generic for loop (with one variable) is:
for variable in iterator(parameter1, parameter2, and so on) do
statements in the for loop body
end
<!--NeedCopy-->
Where iterator() is a function with zero or more parameters that provide a value for a variable on each iteration of the loop body. The iterator function keeps track of where it is in the iteration using a technique called closure, which you don’t have to worry about here. It signals the end of the iteration by returning nil. Iterator functions can return more than one value, for use in a multiple assignment.
Writing an iterator function is beyond the scope of this paper, but there are few useful built-in iterators that illustrate the concept. One is the pairs() iterator, which iterates through the entries in a table and returns two values, the key and the value of the next entry.
Example:
local t = {k1 = "v1", k2 = "v2", k3 = "v3"}
local a = {} -- array to accumulate key-value pairs
local n = 0 -- number of key-value pairs
for key, value in pairs(t) do
n = n + 1
a[n] = key.. " = ".. Value -- add key-value pair to the array
end
local s = table.concat(a, ";") -- concatenate all key-value pairs into one string
<!--NeedCopy-->
Another useful iterator is the string.gmatch() function, which is used in the following COMBINE_HEADERS() example.
Share
Share
This Preview product documentation is Cloud Software Group Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Cloud Software Group Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Cloud Software Group product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.