Traffic Management
NetScaler Operations
Legacy Switching Architectures
4
App1
App2
1
3
Internet
Legacy L4-7 Switch
2
1) Receive incoming requests
2) Determine content requirements
3) Switch traffic (and inherent attacks) to servers
4) Traffic may bypass legacy switch entirely
© 2012 Citrix | Confidential – Do Not Distribute
App3
Unique Request Switching
App1
App2
2
‘Gap’
1
4
Internet
Layer 7 Packet Engine
App3
3
1) Receive + terminate connections
2) Decrypt / authenticate / analyze every request
3) Queue + dispatch valid requests
4) Switch requests + multiplex over persistent connections
© 2012 Citrix | Confidential – Do Not Distribute
Transaction without NetScaler
Client
SYN
SYN+ACK
ACK
GET
Data
Data
Data
FIN
ACK
FIN
ACK
© 2012 Citrix | Confidential – Do Not Distribute
Server
Server allocates storage for
connection
Server sees eleven packets
Server de-allocates storage for
the connection
Transaction with NetScaler
Client
SYN
NetScaler
Server
SYN+ACK
ACK
GET
GET
Data
Data
Data
FIN
ACK
FIN
ACK
© 2012 Citrix | Confidential – Do Not Distribute
Data
Data
Data
Server sees
four packets
Connection Multiplexing
• Multiple clients use single connection to server
ᵒ Sequentially - not simultaneously
• Benefits
ᵒ Optimal reuse of each server connection
• TCP Slowstart vs. Citrix NetScaler Fast Ramp
ᵒ Optimal use of each client connection
• HTTP/1.1
• Client Keep-Alive
• Requires TCP connection manipulation
ᵒ Connection Proxy
ᵒ Connection Termination
© 2012 Citrix | Confidential – Do Not Distribute
Connection Multiplexing
• Full Traffic Optimization and Traffic Security Feature Sets
ᵒ
ᵒ
ᵒ
ᵒ
ᵒ
ᵒ
IP address and port mapping
Attack prevention
Content Filtering
SSL offload
Compression
Caching
• SSL Offload and Compression features require full connection termination
ᵒ No additional configuration of TCP functionality required
© 2012 Citrix | Confidential – Do Not Distribute
Virtual Servers
• Proxy Mode
ᵒ Client sees “virtual server”
ᵒ Server see “virtual client”
• As opposed to Transparent Mode
ᵒ Client and server unaware of NetScaler
Citrix NetScaler
Virtual
Server
Service
Client
Monitor
© 2012 Citrix | Confidential – Do Not Distribute
Server
Static
IP Mapping
• VIP represents a collection of servers to a client
ᵒ For any given transaction, VIP is mapped into a single server IP
ᵒ Usually clients do not need to know the true server IP address
• MIP/SNIP represents a collection of clients to a server
ᵒ For any given transaction, MIP/SNIP is mapped into a single client IP
ᵒ Usually servers do not need to know the true client IP address
ᵒ Options exist for those servers which do need to know
• enable ns mode USIP
© 2012 Citrix | Confidential – Do Not Distribute
NetScaler Virtual Server Tree
Client
Internet
LB VSVR
Dynamic
Content
LB VSVR
Static
Content
LB VSVR
Dynamic
Content
LB VSVR
Static
Content
LB VSVR
Dept
Servers
LB VSVR
Dept
Servers
CSW VSVR
© 2012 Citrix | Confidential – Do Not Distribute
NetScaler Virtual Server Tree
CSW VSVR
Client
CSW VSVR
Internet
LB VSVR
Dynamic
Content
LB VSVR
Static
Content
LB VSVR
Dynamic
Content
LB VSVR
Static
Content
CRD VSVR
© 2012 Citrix | Confidential – Do Not Distribute
Dynamically
Recognized
LB VSVR
Cache
Servers
LB VSVR
Cache
Servers
Load Balancing
Configure Basic Load Balancing
Configurations for HTTP and SSL
• Review the basic concepts of load balancing
• Create an HTTP Load Balancing vserver and associated services
• Test Load Balancing & learn how to view HTTP headers
• Create an SSL LB vserver and self signed certificate
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing
Overview: Service and Vserver
• The overall purpose of load balancing is to accept traffic as if it was destined to
one server, and split the load to many servers
• The fundamental object types used within the NetScaler to define the load
balancing relationships are the service and the vserver
ᵒ The service represents the target server’s ip, port and protocol
ᵒ The vserver represents the virtual server’s ip, port and protocol
• Additional optional objects are associated with these two object types, but
these two are required
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing
Service and Vserver Relationship
• The flow of traffic is dictated by the vserver and
service relationship, which is called “binding.”
ᵒ A request comes from a user.
ᵒ It is received by the vserver object and is processed
based on the vserver attributes.
ᵒ When a load-balancing decision occurs, the request is
passed to the appropriate service object.
ᵒ Based on the service attributes, the request is sent to a
server’s IP and port.
© 2012 Citrix | Confidential – Do Not Distribute
User’s
Request
Vserver Object
Vserver
IP:port+
protocol
LB Processing
Service Objects
Service 1
Ip:port+
protocol
Service 2
IP:port+
protocol
Server 1
IP:port
Server 2
IP:port
Load Balancing
Overview: Load Balancing Methods
• Depending on the application type, there are different ways of splitting the load
between services, the most commonly used being
ᵒ
ᵒ
ᵒ
ᵒ
ᵒ
ᵒ
Round Robin
Least Response Time
Least Connections (default)
Least Bandwidth
URL Hashing
Source and/or Destination IP hashing
If in doubt, use Round Robin. It is the safest and prevents a single
malfunctioning server serving “500” errors from taking all the traffic.
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing
HTTP Load Balancing Example: Round Robin
1. The NetScaler system opens idle server connections.
2. Clients then initiate their TCP connections.
3. Once connected, requests are balanced in the order they are received,
sharing server TCP connections.
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing
Example: HTTP Load Balancing With Round Robin
SYN
SYN-ACK
ACK
TIME
GET /A HTTP/1.1
200 OK
DATA
ACK
User 2
Server 1
SYN
SYN
SYN-ACK
SYN-ACK
ACK
ACK
SYN
SYN-ACK
ACK
GET /B HTTP/1.1
200 OK
DATA
GET /A HTTP/1.1
200 OK
DATA
ACK
ACK
GET /D HTTP/1.1
200 OK
DATA
ACK
© 2012 Citrix | Confidential – Do Not Distribute
Server 2
GET /B HTTP/1.1
200 OK
DATA
ACK
GET /C HTTP/1.1
GET /C HTTP/1.1
200 OK
200 OK
DATA
DATA
ACK
ACK
GET /D HTTP/1.1
200 OK
DATA
ACK
Pre-opened server
connections
User 1
Load Balancing
Overview: Persistence Methods
• Most application servers depend on an individual user persist to one back-end
server. As such, vservers have persistence methods including
ᵒ HTTP Cookie insertion
ᵒ Source IP
ᵒ SSL Session ID (useful for Access Gateway Balancing)
• When balancing HTTP or doing SSL offload, cookie insertion is recommended
if persistence is needed
• When balancing other protocols like SMTP or LDAP, Source IP persistence is
generally your best bet
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing
HTTP Load Balancing Example: Cookie Persistence
1.
The server and clients open their TCP connections.
2.
With the first response, a cookie is sent to the client.
3.
With each new request, the client sends the cookie, and the NetScaler
system sends request to the same server.
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing
Wizard
In order to simplify the creation of lb vservers, the NetScaler GUI provides an LB
creation wizard, which can be access via the Load Balancing tab
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing
LB Wizard, Service Creation
• Set the name
• Set the server
• Set the protocol
• Set the port
• Repeat as needed
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing
LB Wizard, Vserver Creation
The next step is to create a vserver and bind services
Set the name
Set the vserver ip
Set the protocol
Set the port
Set the LB Method
Select service(s)
Click “add” to bind
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing
LB Wizard, Vserver Advanced Options
• If persistence or other advanced options are needed, this can be configure
from the Method and Persistence tab under the vserver properties
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing
LB Wizard, Configuration Summary
• Once the next button is selected in the create vserver window, a summary of
the vserver configuration will be presented. To create the vserver, click finish
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing
Verifying Service and Vserver State
Once services and vservers are created, verify that they are up by going to the
service and vserver tabs under Load Balancing.
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing
Creating an SSL Vserver
To create an SSL vserver using a self signed certificate we will use the LB wizard
again, but in the vserver window
Select protocol SSL
Select port 443
Select add for cert
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing Quick Review
• Load Balancing consists of the following components:
• Servers
• Services
• Service Groups
• Virtual Servers
• Monitors
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing Traffic Types
Supported Protocols
Session Protocols
• HTTP
• TCP
• TCP
• UDP
• FTP
• SSL_TCP
• DNS
General Traffic Types
• NNTP
• SSL_BRIDGE
• SSL (HTTPS)
• ANY
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing Methods
LB Methods
LB Methods
• Least connections (default)
• Source IP hash
• Round robin and
weighted round robin
• Destination IP hash
• Least response time
• Call ID hash
• Least bandwidth
• Least response time monitoring (LTRM)
• Least packets
• CustomLoad LB using SNMP
• Token
• SASP Support for Dynamic Weight
Calculation
• URL hash
• Domain name hash
© 2012 Citrix | Confidential – Do Not Distribute
• Source/Dest IP hash
Load Balancing Weighted Services
• Weighting is available only on certain LB methods
ᵒ
ᵒ
ᵒ
ᵒ
ᵒ
ᵒ
Least Connections
Round Robin
Least Response Time
Least Bandwidth
Least Packets
LTRM (least response time monitoring)
• A number of load balancing methods allow for particular services to be
weighted differently from each other. This can be done to direct more traffic to
a newer server in a cluster
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing – CLI Configuration
• > help add service
ᵒ Usage: add service <name>@ (<IP>@ | <serverName>@) <serviceType> <port>
[-clearTextPort <port>] [-cacheType <cacheType>]
[-maxClient <positive_integer>] [-maxReq <positive_integer>]
[-cacheable ( YES | NO )] [-cip ( ENABLED | DISABLED ) [<cipHeader>]]
[-usip ( YES | NO )] [-sc ( ON | OFF )] [-sp ( ON | OFF )]
[-cltTimeout <secs>] [-svrTimeout <secs>]
[-serverID <positive_integer>] [-CKA ( YES | NO )] [-TCPB ( YES | NO )]
[-CMP ( YES | NO )] [-maxBandwidth <positive_integer>]
[-accessDown ( YES | NO )] [-monThreshold <positive_integer>]
[-state ( ENABLED | DISABLED )] [-downStateFlush ( ENABLED | DISABLED)]
ᵒ where:
<serviceType> = ( HTTP | FTP | TCP | UDP | SSL | SSL_BRIDGE | SSL_TCP |
NNTP | RPCSVR | DNS | ADNS | SNMP | DHCPRA | ANY | SIP_UDP )
<cacheType> = ( TRANSPARENT | REVERSE | FORWARD )
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing – CLI Configuration
• > help add lb vserver
ᵒ Usage: add lb vserver <name>@ <serviceType> [<IPAddress>@ <port>
[-range <positive_integer>]] [-persistenceType <persistenceType>]
[-persistenceBackup ( SOURCEIP | NONE )] [-lbMethod <lbMethod>
[-hashLength <positive_integer>]
[-netmask <netmask>] ]
[-rule <expression>] [-persistMask <netmask>] [-pq ( ON | OFF )]
[-sc ( ON | OFF )] [-m ( IP | MAC )] [-dataLength <positive_integer>]
[-dataOffset <positive_integer>] [-sessionless ( ENABLED | DISABLED )]
[-state ( ENABLED | DISABLED )] [-timeout <mins>]
[-connfailover ( ENABLED | DISABLED )] [-redirectURL <URL>]
[-cacheable ( YES | NO )] [-cltTimeout <secs>] [-soMethod <soMethod>]
[-soPersistence ( ENABLED | DISABLED )]
[-soPersistenceTimeOut <positive_integer>]
[-soThreshold <positive_integer>]
[-redirectPortRewrite ( ENABLED | DISABLED )]
[-downStateFlush ( ENABLED | DISABLED )]
[-insertVserverIPPort ( ON | OFF ) [<vipHeader>]]
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing – CLI Configuration
•
help add lb vserver (Contd.)
ᵒ where:
<serviceType> = ( HTTP | FTP | TCP | UDP | SSL | SSL_BRIDGE | SSL_TCP | NNTP
| DNS | DHCPRA | ANY | SIP_UDP )
<persistenceType> = ( SOURCEIP | COOKIEINSERT | SSLSESSION | RULE |
URLPASSIVE | CUSTOMSERVERID | DESTIP | SRCIPDESTIP | CALLID | NONE )
<lbMethod> = ( ROUNDROBIN | LEASTCONNECTION | LEASTRESPONSETIME | URLHASH |
DOMAINHASH | DESTINATIONIPHASH | SOURCEIPHASH | SRCIPDESTIPHASH |
LEASTBANDWIDTH | LEASTPACKETS | TOKEN | SRCIPSRCPORTHASH | LRTM |
CALLIDHASH )
<soMethod> = ( CONNECTION | DYNAMICCONNECTION | NONE|BANDWIDTH )
© 2012 Citrix | Confidential – Do Not Distribute
LB Configuration – Service Groups
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing - Monitoring
• Monitoring allows the NetScaler to determine the health of the backend
services, monitoring information can be used to take a service UP/DOWN or
can even influence the load balancing decision.
• Common monitors are:
ᵒ
ᵒ
ᵒ
ᵒ
ᵒ
ᵒ
ᵒ
ICMP ping for all services
TCP SYN for any TCP services
LOAD
HTTP
HTTP-ECV
TCP-ECV
DNS
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing - Monitoring
• Inline Health Monitoring
ᵒ Inbound monitors track backend servers by analyzing their responses to requests from
clients
ᵒ Instead of sending probes, they look for specific response codes in traffic originating
from the backend servers
• If the response code is received a preconfigured number of times, the inbound monitor either
changes the state of the monitor or logs the event.
ᵒ Can be configured to track the event without taking any action
• Scriptable Monitoring
ᵒ Extends the scope of custom monitors that you can create by tracking the health of
customized applications and protocols that are not natively supported by the NetScaler
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing - Monitoring
To create a new monitor: add lb monitor <monitorName> <type>
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing – Monitoring
Standard Monitoring Configuration Parameters
• These apply to any monitor regardless of type:
• Retries
• Response Timeout
• Down Time
• Interval
• Reverse
• Secure
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing – Monitoring
Standard Monitoring Configuration Parameters
Retries
• The retries parameter specifies the number of consecutive health check probe
failures after which the system marks the service as DOWN.
• The default value is 3.
Response Timeout
• The response timeout parameter specifies the interval of time for which the
system waits before it marks the health check probe as FAILED.
• The default value is two seconds, except for LDNS monitors, which have a
default value of three seconds.
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing – Monitoring
Standard Monitoring Configuration Parameters
• Downtime parameter specifies the duration for which the system waits before
making the next health check probe once a service is marked as DOWN.
• The default value is 30 seconds, except for LDNS monitors, which have a
default value of 20 seconds.
• Interval parameter specifies the frequency at which the health check probe is
sent to a service.
• The default value is 5 seconds, except for LDNS monitors, which have a
default value of 6 seconds.
• The interval period should be greater than the amount of time configured for
the response timeout parameter.
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing – Monitoring
Standard Monitoring Configuration Parameters
• Reverse
• Disabled by default
• The reverse parameter specifies whether or not a monitor is configured for
reverse conditions.
• When the reverse parameter is set to YES, a health check probe will fail if the
condition of the monitor is satisfied.
• Example: An HTTP-ECV monitor is configured with a send string of GET /FILE, a receive string
of ERROR and the reverse parameter is set to YES. If the NetScaler system sends a probe that
returns a response with the string ERROR, the probe will fail. If the response does not match
ERROR, the probe is successful.
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing – Monitoring
Standard Monitoring Configuration Parameters
• Secure
• Disabled by default
• The secure parameter allows the NetScaler system to monitor SSL services
• When the state of the parameter is set to YES, the NetScaler system
establishes a TCP connection with the destination of the monitor and then
performs an SSL handshake with the server
© 2012 Citrix | Confidential – Do Not Distribute
Response Timeout Threshold
• SNMP trap is generated if the monitoring response time is greater than a
configured threshold
ᵒ Example
• set lb monitor https HTTP
-resptimeout 5
-resptimeoutthresh 80
-interval 6
• This is applicable to all monitors
© 2012 Citrix | Confidential – Do Not Distribute
The LOAD Monitor
• The LOAD monitor sends configured SNMP queries to service
• The NetScaler then uses the values received in the responses to perform a
calculation of the corresponding system’s load
• If the CustomLoad LB method is selected for a virtual server, the NetScaler can
use this load value from each service to adjust the distribution of the traffic
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing - Monitoring
Extended Content Verification Monitors
• Extended Content Verification (ECV) monitors are used when a response
from a service is matched against an expected response string
• Limitations of ECV monitors in general include:
ᵒ
ᵒ
ᵒ
One request/response
127 characters in probe request
Only the first 24k of probe response is parsed
© 2012 Citrix | Confidential – Do Not Distribute
Load Balancing – ECV Monitoring
Extended Content Verification Monitors
• TCP-ECV
ᵒ
ᵒ
ᵒ
ᵒ
TCP connection
SSL handshake
Data sent to a server is encrypted
Success criteria: Successful TCP connection establishment, successful SSL handshake, expected
TCP data, received from the server
• HTTP-ECV
ᵒ
ᵒ
ᵒ
ᵒ
TCP connection
SSL handshake
Encrypted HTTP request
Success criteria: Successful TCP connection establishment, successful SSL handshake, expected
HTTP data, received from the server
© 2012 Citrix | Confidential – Do Not Distribute
LB– HTTP-ECV Monitoring
Extended Content Verification Monitors Process
1. The NetScaler system establishes a TCP connection with the service destination
specified by the monitor.
2. The NetScaler system sends HTTP data specified in the send string parameter to
the service.
3. The NetScaler system compares the HTTP response received by the service to the
expected response specified by the receive string parameter.
4. If the response matches the data in the receive string parameter, the probe is a
success. If the response does not match, the probe fails.
5. If the receive string parameter is left empty, any response from the service will be
considered a match. The NetScaler system looks for matching responses in the first
24K bytes of data in the body of the response.
© 2012 Citrix | Confidential – Do Not Distribute
LB– HTTP-ECV Monitoring
Extended Content Verification Monitors configuration parameters
Parameter
Description
Send string
The send string parameter specifies the HTTP data that will be sent to
the service bound to the monitor.
Receive string
Default value: GET /
The receive string parameter specifies the expected HTTP response
data from the service bound to the monitor.
Default value: none
© 2012 Citrix | Confidential – Do Not Distribute
LB– TCP-ECV Monitoring
Extended Content Verification Monitors Process
1. The NetScaler system establishes a TCP connection with the service
destination specified by the monitor
2. The NetScaler system sends data specified by the send string parameter
to the service
3. The NetScaler system compares the data received by the service to the
expected response data specified by the receive string parameter
4. If the response matches the data in the receive string parameter, the probe
is a success. If the response does not match, the probe fails
© 2012 Citrix | Confidential – Do Not Distribute
LB– TCP-ECV Monitoring
Extended Content Verification Monitors configuration parameters
Parameter
Description
Send string
The send string parameter specifies the data that will be sent to the
service bound to the monitor.
Receive string
Default value: none
The receive string parameter specifies the expected HTTP response
data from the service bound to the monitor.
Default value: none
© 2012 Citrix | Confidential – Do Not Distribute
LB–Secure ECV Monitors
Secure Extended Content Verification Monitors
• Both HTTP-ECV and TCP-ECV monitors can be run over SSL. In these cases
the completed SSL handshake and session establishment are added to the
monitoring conditions.
• If the SSL connection fails but the other monitoring criteria are successful, the
service will be marked as DOWN.
• The parameters for HTTPS-ECV and TCPS-ECV monitors are the same as
those used for non-SSL transactions.
© 2012 Citrix | Confidential – Do Not Distribute
Monitoring for Reverse Conditions
Condition (HTTP-ECV Monitors)
Direct
Reverse
Fail
Fail
Success
Fail
Fail
Fail
Direct
Reverse
Success
Fail
Fail
Fail
Success
Fail
Response does not match configured receive string
Fail
Success
Probe timed out
Fail
Fail
Connection is not established
HTTP Response matches configured receive string
Probe timed out
Condition (TCP-ECV Monitors)
Connection is established (Send string is empty)
Connection not established
Response matches configured receive string
© 2012 Citrix | Confidential – Do Not Distribute
XenApp and XenDesktop Monitors
• Component monitors are used to monitor various Citrix services
ᵒ XML-Service
ᵒ Web Interface
ᵒ DDC
© 2012 Citrix | Confidential – Do Not Distribute
Health Checking the Web Interface
• For WI a monitor should verify that the code behind the web
application is functioning correctly
• One way to accomplish this for Web Interface is to verify that the
Set-Cookie header is being returned
ᵒ This implies that the web server has correctly processed the request and has
successfully initiated the web application code that prepares the Web Interface for a
new user session
© 2012 Citrix | Confidential – Do Not Distribute
XML Service Monitor
• Built-in Monitor:
ᵒ Sends XML Request for chosen application
ᵒ Healthy Response Contains:
• <TicketTag>, Host ID of LLS
ᵒ Implies XenApp health because multiple actions must succeed to fulfill request
© 2012 Citrix | Confidential – Do Not Distribute
USER Monitor
• USER monitors are an addition to custom monitors
ᵒ
ᵒ
ᵒ
ᵒ
ᵒ
Can be used to track the health of a custom application
Customers can write their own PERL scripts to monitor a specific application
USER monitors are BSD PERL scripts working on layer 7
Several USER monitors exist in the /nsconfig/Monitor directory
User monitors can be configured using the CLI or the GUI
© 2012 Citrix | Confidential – Do Not Distribute
USER Monitor
• USER type monitors residing on the NetScaler device
ᵒ When the dispatcher resides on the NetScaler device
ᵒ It is a process listening on the loopback address on port 3013
• USER type monitors residing on an external device
ᵒ The external dispatcher is configured via
• -dispatcherIP [IP address]
• -dispatcherport [port where the dispatcher is listening on for incoming requests]
© 2012 Citrix | Confidential – Do Not Distribute
USER Monitor configuration example
• Configure an LDAP monitor
ᵒ add lb monitor LDAP USER –scriptName nsldap-kas.pl
• Provide the arguments necessary to make the LDAP query:
ᵒ set lb monitor LDAP USER –destip [destip] -destport [389/3268] –scriptargs
“base=cn=adminisrator,cn=Users,dc=apac,dc=lab;bdn=administrator@network.lab;pas
sword=people”
© 2012 Citrix | Confidential – Do Not Distribute
Monitor Configuration in GUI
© 2012 Citrix | Confidential – Do Not Distribute
Backup Persistence
• If first configured method fails, use the backup persistence method
ᵒ For example: If Cookie persistence is enabled, but client browser refuses to set
cookies
• Configured with “set lb vserver” or “set group”
• Currently, only SOURCEIP persistence can be configured for backup
ᵒ Default is NONE
© 2012 Citrix | Confidential – Do Not Distribute
Vserver Group Persistence
• Allows persistence across different protocols
• Created with “bind lb group” command
• Allowed persistence types:
ᵒ Source IP
ᵒ Cookie Insert
© 2012 Citrix | Confidential – Do Not Distribute
LAB – Module 2 – Exercise 1
To continue with the lab, return back to:
http://training.mycitrixcloud.net/geoilt
Enter you business email and this session code:
NETSCALER-WORKSHOP
© 2012 Citrix | Confidential – Do Not Distribute
Policies
Overview
Topics in this module include:
• Advanced Policy Expression Syntax
• Actions
• Policy Bindings
• Identifying Packet Process Flow
• Basic Configuration: Policies and Actions
© 2012 Citrix | Confidential – Do Not Distribute
XML...SOAP...HTTP...WSDL...JSON...REST...RSS...AJAX...end-user
experience…Mashup...RelTag...SOA...Application Availability...Data
theft...RIA...Wiki...Enterprise 2.0
AppExpert
Users
Policy Framework
Router
Switch
Firewall
MAC address...Source IP...Destination IP...Source port...Destination
port...Ping…OSPF...RIP...BGP...ACL...DNS...Subnet...802.XX...ARP...ICMP...RTT...SYN...A
CK…Keepalive...SNMP...SSH...SSL...MTBF...Latency...
© 2012 Citrix | Confidential – Do Not Distribute
Apps
NetScaler System Architecture
NetScaler Functional Modules
Acceleration
Availability
Security
Application Switching Engine
Flow
AppExpertTM
Users
Policy Engine
Application Delivery Networking Platform
© 2012 Citrix | Confidential – Do Not Distribute
SmartAccessTM
Client
Access GatewayTM
Application Security
Content Rewrite
GSLB
Load Balancing
Content Switching
SSL Acceleration
AppCacheTM
EdgeSightTM
AppCompressTM
AppExpert Policy Framework
AppExpert
Visual Policy
Builder
Server
Flow
AppExpert
APIs
Apps
What NetScaler Features use Policies?
• Content switching (CS)
• Cache Redirection (CR)
• Compression (CMP)
• Priority Queuing (PQ)
• Content Filtering (CF)
• SureConnect (SC)
• Integrated Caching (IC)
• SSL VPN
• Responder
• URL Rewrite
© 2012 Citrix | Confidential – Do Not Distribute
Policy Framework
• Defines application-aware policy
expressions
• Logically combines multiple policy
expressions
• Provides policy execution structure
and flow control
© 2012 Citrix | Confidential – Do Not Distribute
Policy
Expressions
Compound Expressions
Policy Banks
Understanding Packet Processing Flow
• As traffic through the NetScaler is evaluated by the feature sets, logging
matching policy actions
• The NetScaler system typically applies all matching actions after processing is
complete, with integrated caching as one exception
• Some policies affect the outcome of other policies
• Advanced policy evaluation occurs in a particular order
© 2012 Citrix | Confidential – Do Not Distribute
Packet Processing Flow Diagram
1. HTTP Request
App
Firewall
Client
Responder
Caching
Caching
NS Body
Transformer
Content
Switching
Load
Balancing
Apply
Rewrite
2. HTTP Response
© 2012 Citrix | Confidential – Do Not Distribute
Response
Rewrite
CF+HDOSP
SC+PQ
CF+CMP
+CKA
Request
Rewrite
Server
Understanding Policies
• Policies:
ᵒ Evaluate user specified conditions
ᵒ Define the actions to be taken if conditions are met
• Expressions return boolean, numeric or string values
• Defined actions are always feature specific
• Priorities are required for advanced policy expressions; if a priority is assigned,
policies are evaluated in the order of their assigned priority
• Policy evaluation outcomes include:
ᵒ True
ᵒ False
ᵒ Undefined
© 2012 Citrix | Confidential – Do Not Distribute
Policy Process Evaluation Flow
No
Incoming
Connection
Is Policy
bound?
Undef Action
Checks for
untested policies
in the policy list
Performs the rulespecific or default
undefAction
Outgoing
Connection
Done
Yes
Log
Logs actions
Undefined
Evaluation
Evaluates the
policy
expressions for a
match
False
Next Policy
Action
Goes to the next
policy in the
policy list
Executes the
action assigned
to the policy
True
© 2012 Citrix | Confidential – Do Not Distribute
Components of a NetScaler Policy
• Numerous features of the NetScaler are controlled using policies
ᵒ For example-compression policy defines conditions for compressing content
• A policy consists of expression and action
POLICY
EXPRESSION
© 2012 Citrix | Confidential – Do Not Distribute
ACTION
What Are Expressions?
• An expression is the most fundamental component of a policy.
• Expressions are a common pool of conditions that can be applied to content
entering the Citrix NetScaler system
ᵒ For example; source IP address or browser type
• Expressions be "named" or "inline"
© 2012 Citrix | Confidential – Do Not Distribute
What Are Expressions?
• Policy expression syntax is universal and shared among NetScaler features
• Expressions referenced as a "rule" by NetScaler feature sets
• Expressions can be unary or compound
• The expression (or condition that is evaluated) does not change the content, but
the configured action can change the content
© 2012 Citrix | Confidential – Do Not Distribute
Structure of Basic Expressions
• In the Policy Engine, a basic expression is a composition of object-level
operations
• Basic expressions consist of a top level starter object followed by various
operations or parameters
HTTP.REQ.HEADER (advanced), or
REQ.HTTP.HEADER (classic)
© 2012 Citrix | Confidential – Do Not Distribute
Identifying Advanced Policy Expressions
The advanced expression language:
• Is object-oriented
• Includes basic expressions and compound expressions
© 2012 Citrix | Confidential – Do Not Distribute
Advanced Policy Expression Syntax
• Advanced policy expression syntax reads from left to right
• Possible top-level (leftmost) values include:
ᵒ
ᵒ
ᵒ
ᵒ
ᵒ
ᵒ
ᵒ
ᵒ
CLIENT
HTTP
SERVER
SYS
TARGET
TEXT
URL
VPN
• Advanced policy expression examples include:
ᵒ CLIENT.IP.SRC.IN_SUBNET (“10.60.1.0/24”)
ᵒ “HTTP.REQ.HEADER (“Referer”).BEFORE_STR (\”//”\)”
© 2012 Citrix | Confidential – Do Not Distribute
Advanced Policy Expression Objects
OPERATORS
TOP LEVEL OBJECT
PROTOCOL
PROTOCOL
METHOD
STRUCTURED
UNSTRUCTURED
CLIENT
ETHER
List
After RegEx
SERVER
INTERFACE
Name-value list
Before RegEx
HTTP
IP
Date and time
After string
SYS
TCP
IP address
Before string
Varies by protocol
TARGET
VLAN
HTTP URL
Contains
TEXT
REQ
HTTP Version
Contains any
URL
RES
DNS Domain Name
Equals
VPN
TIME
More…
More…
© 2012 Citrix | Confidential – Do Not Distribute
Policy Expressions
STARTER
OBJECT
PROTOCOL
PROTOCOL
METHOD
OPERATORS
STRUCTURED
UNSTRUCTURED
CLIENT
ETHER
List
After RegEx
SERVER
INTERFACE
Name-value list
Before RegEx
HTTP
IP
Date and time
After string
SYS
TCP
IP address
Before string
VLAN
HTTP URL
Contains
REQ
HTTP Version
Contains any
RES
More…
More…
© 2012 Citrix | Confidential – Do Not Distribute
Varies by protocol
Defining Advanced Expressions
Advanced Syntax Starter
Object
CLIENT
HTTP
Description
Provides operations on client side data
Operates on HTTP protocol data
SERVER
Provides operations on server side data
SYSTEM
Provides operations on system wide data
URL
will operate on the URL portion of an HTTP request
TEXT
will operate on any text string
TARGET
VPN
© 2012 Citrix | Confidential – Do Not Distribute
will operate on an HTTP request target
will operate on VPN data
Defining Classic Expressions
Classic Syntax Starter
Object
REQUEST
RESPONSE
© 2012 Citrix | Confidential – Do Not Distribute
Description
Operates on an incoming client request traffic
Operates on server response traffic
AppExpert Policy Expressions
STARTER
OBJECT
PROTOCOL
PROTOCOL
METHOD
OPERATORS
STRUCTURED
UNSTRUCTURED
CLIENT
ETHER
List
After RegEx
SERVER
INTERFACE
Name-value list
Before RegEx
HTTP
IP
Date and time
After string
SYS
TCP
IP address
Before string
VLAN
HTTP URL
Contains
REQ
HTTP Version
Contains any
RES
More…
More…
© 2012 Citrix | Confidential – Do Not Distribute
Varies by protocol
Understanding Expression Types
Expressions can return one of the following:
• A BOOLEAN TRUE or FALSE (used in all Policy types)
Example: “HTTP.REQ.IS_VALID”
• A STRING (Used in Rewrite Actions)
Example:
add rewrite action INSERT_CLIENT_IP insert_http_header “Client-ip”
“CLIENT.IP.SRC”
© 2012 Citrix | Confidential – Do Not Distribute
Actions
An action:
• Is owned by individual NetScaler features
• Is bound to or activated by policies
• Cannot depend on results of other actions
• Is applied at the end of the policy evaluation process
A single HTTP header cannot be modified by multiple actions
© 2012 Citrix | Confidential – Do Not Distribute
Action Syntax
Action Name
Rewrite Action
add rewrite action ClientIP INSERT_HTTP_HEADER
Client-ip CLIENT.IP.SRC
HTTP Header
Name
© 2012 Citrix | Confidential – Do Not Distribute
Value: Individual Client IP
address
Actions Example
© 2012 Citrix | Confidential – Do Not Distribute
How NetScaler Modules Use Policies
Module Name
Filters
Content Switching
Cache Redirection
Rewrite
URL Transformer
AppFW
Access Gateway
How policies are used in modules
To configure behavior of the Content Filtering, SureConnect, and Priority
Queuing functions
Determine what server or group of servers will serve responses based on
the characteristics of incoming request.
To determine whether responses are served from cache or origin
infrastructure.
Identify what HTTP data needs to be modified before serving, and the
rules for modifying the data.
Identify URL’s in HTTP transactions and text files for the purpose of
evaluating whether a URL should be transformed.
Identify characteristics of traffic and data that should or should not be
admitted through the Firewall
Authentication and Authorization Functions
© 2012 Citrix | Confidential – Do Not Distribute
How NetScaler Modules Use Policies
Module Name
How policies are used in modules
For Authentication functions, policies contain authentication schemes
System
for different authentication methods. This also applies to auditing
functions.
DNS
Determines how to perform DNS resolution for requests
To determine when to apply and encryption function and add
SSL
certificate information to clear text. Provides end-to-end security after
message is decrypted, the SSL module re-encrypts clear text and uses
SSL to communicate with Origin Servers.
Compression
To determine what type of traffic is compressed
Integrated Caching
To determine whether HTTP responses are cacheable
Responder
© 2012 Citrix | Confidential – Do Not Distribute
Policy Bindings
• Policies remain inactive until they are bound or activated
• Policies are bound or activated either globally or to specific bind points
• Available specific bind points vary by feature set
© 2012 Citrix | Confidential – Do Not Distribute
Policy Bindings
For a policy to be evaluated on the NetScaler, it must be bound.
• In Classic Policy Engine - we already have the concept of bind points –
basically a name to which policies are bound. These names can implicit (like
global) or names of other user configured entities like vservers, users or
groups.
• For advanced syntax we can use Policy labels (banks). These are a
generalization of the classic bind point concept. A policy label is a name to
which advanced policies can be bound
© 2012 Citrix | Confidential – Do Not Distribute
Understanding Bind Points
• Global bind points:
ᵒ Policies bound to the default label are evaluated after virtual server specific evaluation
ᵒ Policies bound to the override label are evaluated before virtual server specific
evaluation
• User-defined bind points:
ᵒ Policies can be created and bound to policy label bind points
ᵒ Policies bound are evaluated only on invoke
• Invoking bind points:
ᵒ Named subroutine similarity
ᵒ Policies can be invoked
ᵒ Global bind points are not invokable
© 2012 Citrix | Confidential – Do Not Distribute
Using the Policy Manager
• The policy manager dialog provides an easy interface for managing bind points
and policy banks
• The most commonly used bind point levels are:
ᵒ Global
ᵒ Load-balancing virtual server
ᵒ Content-switching virtual server
© 2012 Citrix | Confidential – Do Not Distribute
Create Policy Manager Dialog
© 2012 Citrix | Confidential – Do Not Distribute
Understanding Policy Labels
• A policy label is a user-defined point to which policies can be bound
• Using a policy label, an administrator can logically group policies and define
the order in which they are evaluated
• Policy labels are invoked from other policies
© 2012 Citrix | Confidential – Do Not Distribute
Configuring Policy Labels
© 2012 Citrix | Confidential – Do Not Distribute
Compound Policies
• Individual policies can be combined into a larger compound policy
• Supported compounding operators
ᵒ
ᵒ
ᵒ
ᵒ
ᵒ
ᵒ
ᵒ
ᵒ
ᵒ
ᵒ
ᵒ
TRUE, FALSE constants
|| or
&& and
! not
() for grouping
== equal-to
> greater than
>= greater than or equal to
< lesser than
>= lesser than or equal to
!= not equal-to
© 2012 Citrix | Confidential – Do Not Distribute
Evaluation Order for Advanced
• Request-time global override
• Request-time virtual server specific (one bind point per virtual server)
• Request-time global default
• Response-time global override
• Response-time virtual server specific
• Response-time global default
© 2012 Citrix | Confidential – Do Not Distribute
Content Switching
Content Switching: Overview
• Content Switching allows traffic to be redirected to vserver(s) based upon
configured policies.
• Example: Dynamic ASP and PHP pages may be redirected to a different server
farm while static content is redirected to another set of servers.
• Example: Users with specific source IP’s or host headers may be redirected to
different servers.
© 2012 Citrix | Confidential – Do Not Distribute
Content Switching: Use Case
• What happens if not all servers in the farm have the same content?
• Specialized servers for
ᵒ Shopping cart
ᵒ Product catalog
ᵒ Database front-ends
• Need to be able to direct traffic to certain backend resources
© 2012 Citrix | Confidential – Do Not Distribute
Content Switching: Advantages
• Boost in Performance
ᵒ Content Switching can redirect requests to servers best suited to handle each type of
request allowing for overall boost in performance.
• Management Flexibility
ᵒ Content Switching allows for flexibility via content switching policies that allows for
content redirection based on client requests. This allow for scalability within a single
domain without creating multiple domains and sub domains.
© 2012 Citrix | Confidential – Do Not Distribute
Content Switching: Advantages
• Public gets a single IP address view of a site
• Responsive to:
ᵒ
ᵒ
ᵒ
ᵒ
Client characteristics
HTTP Method: Post, GET
URL
Hide internal complexity from the clients
• Separate management of app from app
• Organizational independence
ᵒ Distinct parts of a large organization can control their own servers
© 2012 Citrix | Confidential – Do Not Distribute
Content Switching VIP: Evaluation
• Request comes to Content Switching VIP
• Expression bound to CS Policy is hit (incremented)
• How Do we check this (> show policy expression)
• Content Switching Policy is Evaluated.
• Content is redirected to Lb VServer that is bound to CS Policy.
• If a Content Switching Policy is not hit, traffic is redirected to the Lb
VServer bound to default CS policy.
© 2012 Citrix | Confidential – Do Not Distribute
Content Switching: Diagram
Client
Internet
LB VSVR
Dynamic
Content
LB VSVR
Static
Content
LB VSVR
Dynamic
Content
LB VSVR
Static
Content
LB VSVR
.jpg
Servers
LB VSVR
.gif
Servers
CSW VSVR
NetScaler
© 2012 Citrix | Confidential – Do Not Distribute
Content Switching: Components
• Content Switching Virtual Server
• Load Balancing Virtual server
ᵒ Services
ᵒ Servers
• Content Switching Policy
ᵒ Expressions
© 2012 Citrix | Confidential – Do Not Distribute
Content Switching: Components
• Content Switching Virtual Server
ᵒ IP Address, Port, SSL offloading
• Load Balancing Virtual Servers
ᵒ Not directly addressable (no IP Address, Port)
ᵒ Services
• Bound to load balancing virtual server
ᵒ Servers
• Bound to services
• Policy
ᵒ Policies bind load balancing vserver to the content switching vserver
© 2012 Citrix | Confidential – Do Not Distribute
Content Switching: Command Syntax
#
>
>
>
create
add cs
add lb
add lb
the virtual servers
vserver csw_vip HTTP 65.219.20.33 80
vserver base_vip HTTP
vserver second_vip HTTP
# create the policy
> add cs policy match_good –rule good_stuff
# bind the lb vserver and policy to cs vserver
> bind cs vserver csw_vip base_vip
> bind cs vserver csw_vip second_vip –policyName match_good
© 2012 Citrix | Confidential – Do Not Distribute
CS - Rule Precedence
> bind cs vserver cswvip lbvip1 -policy cs_policy_a
> bind cs vserver cswvip lbvip2 -policy cs_policy_b
> bind cs vserver cswvip lbvip3 -policy cs_policy_c
Evaluation Order:
cs_policy_a  cs_policy_b  cs_policy_c
© 2012 Citrix | Confidential – Do Not Distribute
CS - Rule Precedence
> bind cs vserver cswvip lbvip3 -policy cs_policy_a priority 10
> bind cs vserver cswvip lbvip2 -policy cs_policy_b priority 20
> bind cs vserver cswvip lbvip3 -policy cs_policy_c priority 15
Evaluation Order:
cs_policy_a  cs_policy_c  cs_policy_b
© 2012 Citrix | Confidential – Do Not Distribute
Content Switching: Command Sequence
1)
Create a CS vserver
ᵒ
Must do SSL offload at CS vserver
2)
Create several LB vservers
3)
Create expressions
4)
Create CS policies
ᵒ
ᵒ
5)
Combine expressions
Avoid using URLs
Bind LB vservers to Content Switching vserver, with selection based on
which policy is bound with each vserver
© 2012 Citrix | Confidential – Do Not Distribute
Content Switching: Command Syntax
# create the virtual servers
> add cs vserver csw_vip HTTP 65.219.20.33 80
> add lb vserver default_vip HTTP
> add lb vserver specialized_vip HTTP
# create the policy
> add cs policy specialized_traffic –rule named_exp_special
# bind the lb vserver and policy to cs vserver
> bind cs vserver csw_vip default_vip
> bind cs vserver csw_vip specialized_vip –policyName
specialized_traffic
© 2012 Citrix | Confidential – Do Not Distribute
Content Switching CLI Configuration
add cs vserver cs_ftp ftp 10.102.32.68 21
add cs policy pol_subnet32 -rule "CLIENT.IP.SRC.IN_SUBNET(10.102.32.0/24)"
add cs policy pol_subnet130 -rule
"CLIENT.IP.SRC.IN_SUBNET(10.102.130.0/24)"
bind cs vserver cs_ftp lb_ftp_default
bind cs vserver cs_ftp lb_ftp_32subnet -policyName pol_subnet32 -priority 10
bind cs vserver cs_ftp lb_ftp_130subnet -policyName pol_subnet130 -priority 20
© 2012 Citrix | Confidential – Do Not Distribute
Example: CS Policies in CLI
• A policy that is looking for the HTTP method POST and sends requests to the
configured LB Vserver.
• Example #1 – Policy based on HTTP Method
1.
add cs policy
2.
Bind the content switching vserver to the target LB vserver using the policy
previously created.
© 2012 Citrix | Confidential – Do Not Distribute
Example: CS Policies in CLI
This example illustrates the creation of a simple rule-based policy that checks for
requests with a particular string in the hostname.
The policy checks for requests with the string "dave" in the hostname. The policy
is bound to an LB vserver. When a request with "dave" in the hostname is
received, it is sent to the LB vserver.
Example #2 – Policy based on Hostname
1.
Add cs policy named dom_contains looking for the string “dave”
2.
bind cs vserver ADV_CS to LB_Dave with policy dom_contains
© 2012 Citrix | Confidential – Do Not Distribute
Example: CS Policies in CLI
This example illustrates the creation of a compound rule-based policy that
checks for requests with a particular combination of prefix and suffix.
The policy checks for requests with the prefix "/security" and the suffix "asp". The
policy is bound to an LB vserver, lb_secure. When such a request is received,
it is sent to lb_secure.
Example #3 – Compound Policy
1.
Add cs policy cspol_security with the expression:
2.
Bind cs vserver ADV_CS to lb_secure with the policy cspol_security
© 2012 Citrix | Confidential – Do Not Distribute
Example: CS Policies in the CLI
GoTo expressions are used to invoke other policies based on priority value.
In this example, the CS decision will be based on the value of the query
argument passed in the URL www.yahoo.com/app?arg=1.
In the URL, “arg” can take the values 1,2,3. The GoTo expression will use this
value to derive the priority of the policy that will be invoked.
© 2012 Citrix | Confidential – Do Not Distribute
LAB – Module 3 – Exercise 1
To continue with the lab, browse to:
http://training.mycitrixcloud.net/geoilt
Enter you business email and this session code:
NETSCALER-WORKSHOP
© 2012 Citrix | Confidential – Do Not Distribute
Work better. Live better.