Configuring Global Settings

Configuring Global Settings

Once you have installed and performed initial configuration, you can configure a number of connection parameters, customizing your NetScaler to match the needs of your network and managed servers.

Configuring HTTP Traffic Ports

This option identifies Web server HTTP ports used by your managed servers and allows the NetScaler to perform request switching for any client request that has a destination port matching a configured port.

The following procedure includes HTTP port 8080 as an example of a port that can be added on the NetScaler. If your managed servers accept HTTP connections on port 8080, clients need to send requests to this port

To configure HTTP traffic ports

1. In the left pane, expand System and click Settings. The Settings page appears in the right pane.

2. Under Settings, click Change HTTP Parameters. The Configure HTTP Parameters dialog box appears.

3. In HTTP Port Information, in the HTTP Port text box, type the port number, for example, 8080.

4. Click Add and Click OK. The Configure HTTP Parameters dialog box appears.

Setting the Maximum Connections to Each Server

You can specify a maximum number of connections that a NetScaler is allowed to make to each managed server. For example, if you enter 500 and there are three servers managed by the NetScaler, it will open a maximum of 500 connections to each of these three servers. By default, the NetScaler can create an unlimited number of connections to any of the servers it manages.

To set maximum connections to each server

1. In the left pane, expand System, and click Settings. The Settings page appears in the right pane.

2. Under Settings, click Change HTTP Parameters. The Configure HTTP Parameters dialog box appears.

3. Under Limits, in the Max Connections text box, type the maximum number of connections, for example, 500.

4. Click OK.

Setting the Maximum Requests per Connection

You can set a maximum number of requests that a NetScaler is allowed to send to a managed server over each connection. To specify an unlimited number of requests, set this value to 0.

To set the maximum requests per connection

1. In the left pane, expand System, and click Settings. The Settings page appears in the right pane.

2. Under Settings, click Change HTTP Parameters. The Configure HTTP Parameters dialog box appears.

3. Under Limits, in Max Requests text box, type the maximum number of requests, for example, 500.

4. Click OK.

Configuring Client IP Address Insertion

When a Web server managed by a NetScaler receives a mapped IP address, the server identifies this mapped IP address as the client’s IP address. Some applications need the client’s IP address for logging purposes or to dynamically determine the content to be served by the web server.

You can enable insertion of the actual client IP address into the HTTP header request sent from the client to one, some, or all servers attached to a NetScaler. You can then access the inserted address through a minor modification to the server (using an Apache module, ISAPI interface, or NSAPI interface).

To enable client IP Address insertion

1. In the left pane, expand System, then click Settings. The Settings page appears in the right pane.

2. Under Global Settings click HTTP Parameters. The Configure HTTP Parameters dialog box appears.

3. Under Client IP Insertion, select Client IP.

4. Click OK.

Setting HTTP Cookie Version

A NetScaler sends its own cookie when COOKIEINSERT persistence is configured on a virtual server. The NetScaler can send either a version 0 or a version 1 HTTP cookie. By default, it uses HTTP cookie version 0, which is the most common type on the Internet. In the following example, you set the HTTP cookie to version 1.

To set HTTP cookie version 1

1. In the left pane, expand System, then click Settings. The Settings page appears in the right pane.

2. Under Settings, click Change HTTP Parameters. The Configure HTTP

Parameters dialog box appears.

3. Under Cookie Version, select Version 1.

4. Click OK.

Setting FTP Port Range

A NetScaler can be configured to open FTP connections on a controlled range of ports instead of ephemeral ports for data connections. This improves security, because opening all ports on the firewall is insecure. You can set the range anywhere from 1024 to 64000.

To set FTP port range

1. In the left pane, expand System, and click Settings. The Settings page appears in the right pane.

2. Under Settings, click Change HTTP Parameters. The Configure Global Settings dialog box appears.

3. Under FTP Port Range, in Start Port and End Port text box, type the lowest and highest port number, respectively, in the range you are specifying, for example, 5000 and 6000.

4. Click OK.

Load Balancing Works

Load Balancing Works

The load balancing feature distributes client requests across multiple servers to optimize resource utilization. In a real-world scenario with a limited number of servers providing service to a large number of clients, a server can become overloaded and degrade server performance. A NetScaler uses load balancing criteria to prevent bottlenecks by forwarding each client request to the server best suited to handle the request when it arrives.

To configure load balancing, you define a virtual server (vserver) to proxy multiple servers in a server farm and balance the load among them. When a client initiates a connection to the server, the vserver terminates the client connection and initiates a new connection with the selected server to perform load balancing. The load balancing feature provides traffic management from Layer 4 (TCP and UDP) through Layer 7 (FTP, HTTP, and HTTPS).

The NetScaler uses a number of algorithms, called load balancing methods, to determine how to distribute the load among the servers. The default load balancing method is the Least Connections method.

A typical load balancing deployment consists of the entities described in the following figure.

The entities that you must configure in a typical load balancing setup are:

• Vserver. An entity that is represented by an IP address, a port, and a protocol. The vserver IP address (VIP) is usually a public IP address. The client sends connection requests to this IP address. The vserver represents a bank of servers.

• Service. An entity that is represented by an IP address, a port, and a protocol. A service is a logical representation of a server or an application running on a server. The services are bound to the vservers. 

• Server object. An entity that is represented by an IP address. The server object is created when you create a service. The IP address of the service is taken as the name of the server object. You can also create a server object and then create services by using the server object.

• Monitor. An entity that tracks the health of the services. The NetScaler periodically probes the servers using the monitor bound to each service. If a server does not respond within a specified response timeout, and the specified number of probes fails, the service is marked DOWN. The NetScaler then performs load balancing among the remaining services.

To configure load balancing, you must first create services. Then, you must create vservers and bind services to the vservers. By default, the NetScaler binds a monitor to each service. You can also assign weights to a service. The load balancing method uses the assigned weight to select a service. You need to perform these tasks in the sequence illustrated in the following flow chart.

Understanding Persistence

You must configure persistence on a vserver if you want to maintain the states of connections on the servers represented by that vserver (for example, connections used in e-commerce). The NetScaler then uses the configured load balancing method for the initial selection of a server, but forwards to that same server all subsequent requests from the same client.

If persistence is configured, it overrides the load balancing methods once the server has been selected. If the configured persistence applies to a service that is down, the NetScaler uses the load balancing methods to select a new service, and the new service becomes persistent for subsequent requests from the client. If the selected service is in an Out Of Service state, it continues to serve the outstanding requests but does not accept new requests or connections. After the shutdown period elapses, no new requests or connections are directed to the service and the existing connections are closed. The following table lists the types of persistence that you can configure.

Persistence Type:

Source IP, SSL Session ID, Custom Server ID, Rule, DESTIP, SRCIPDESTIP

CookieInsert, URL passive

Persistent Connections:

250 K

Memory limit. In case of CookieInsert, if time out is not 0, any number of connections is allowed until limited by memory.

If the configured persistence cannot be maintained because of lack of resources on a NetScaler, the load balancing methods are used for server selection. Persistence is maintained for a configured period of time, depending on the persistence type. Some persistence types are specific to certain vservers.

You can also specify persistence for a group of vservers. When you enable persistence on the group, the client requests are directed to the same selected server regardless of which vserver in the group receives the client request. When the configured time for persistence elapses, any vserver in the group can be selected for incoming client requests.

Understanding Persistence Based on Cookies

When you enable persistence based on cookies, the NetScaler adds an HTTP cookie into the Set-Cookie header field of the HTTP response. The cookie contains information about the service to which the HTTP requests must be sent. The client stores the cookie and includes it in all subsequent requests, and the NetScaler uses it to select the service for those requests. You can use this type of persistence on vservers of type HTTP or HTTPS.

The NetScaler inserts the cookie NSC_XXXX= ServiceIP ServicePort where

• NSC_XXXX is the vserver ID that is derived from the vserver name.

• ServiceIP is the hexadecimal value of the IP address of the service.

• ServicePort is the hexadecimal value of the port of the service.

The NetScaler encrypts ServiceIP and ServicePort when it inserts a cookie, and decrypts them when it receives a cookie.

By default, the NetScaler sends HTTP cookie version 0, in compliance with the Netscape specification. It can also send version 1, in compliance with RFC 2109.

You can configure a timeout value for persistence that is based on HTTP cookies. Note the following:

• If HTTP cookie version 0 is used, the NetScaler inserts the absolute Coordinated Universal Time (GMT) of the cookie’s expiration (the expires attribute of the HTTP cookie), calculated as the sum of the current GMT time on a NetScaler, and the timeout value.

• If an HTTP cookie version 1 is used, the NetScaler inserts a relative expiration time (Max-Age attribute of the HTTP cookie). In this case, the client software calculates the actual expiration time.

If you set the timeout value to 0, the NetScaler does not specify the expiration time, regardless of the HTTP cookie version used. The expiration time then depends on the client software, and such cookies are not valid if that software is shut down. This persistence type does not consume any system resources. Therefore, it can accommodate an unlimited number of persistent clients.

Understanding Persistence Based on Server IDs in URLs

The NetScaler can maintain persistence based on the server IDs in the URLs. In a technique called URL passive persistence, the NetScaler extracts the server ID from the server response and embeds it in the URL query of the client request. The server ID is an IP address and port specified as a hexadecimal number. The NetScaler extracts the server ID from subsequent client requests and uses it to select the server.

URL passive persistence requires configuring either a payload expression or a policy infrastructure expression specifying the location of the server ID in the client requests. For more information about expressions, see the “Policies and Expressions” chapter in the Citrix NetScaler Policy Configuration and Reference Guide.

Example: Payload Expression

The expression, URLQUERY contains sid= configures the system to extract the server ID from the URL query of a client request, after matching token sid=. Thus, a request with the URL http://www.citrix.com/ index.asp?&sid=c0a864100050 is directed to the server with the IP address 10.102.29.10 and port 80.

The timeout value does not affect this type of persistence, which is maintained as long as the server ID can be extracted from the client requests. This persistence type does not consume any system resources, so it can accommodate an unlimited number of persistent clients.

Understanding URL Redirection

You can configure a redirect URL to communicate the status of the NetScaler in the event that a vserver of type HTTP or HTTPS is down or disabled. This URL can be a local or remote link. The NetScaler uses HTTP 302 redirect.

Redirects can be absolute URLs or relative URLs. If the configured redirect URL contains an absolute URL, the HTTP redirect is sent to the configured location, regardless of the URL specified in the incoming HTTP request. If the configured redirect URL contains only the domain name (relative URL), the HTTP redirect is sent to a location after appending the incoming URL to the domain configured in the redirect URL.

Understanding Backup Vservers

If the primary vserver is marked down or disabled, the NetScaler can direct the connections or client requests to a backup vserver that forwards the client traffic to the services. The NetScaler can also send a notification message to the client regarding the site outage or maintenance. The backup vserver is a proxy and is transparent to the client.

You can configure a backup vserver when you create a vserver or when you change the optional parameters of an existing vserver. You can also configure a backup vserver for an existing backup vserver, thus creating cascaded backup vservers. The maximum depth of cascading backup vservers is 10. The NetScaler searches for a backup vserver that is up and accesses that vserver to deliver the content.

You can configure URL redirection on the primary for use when the primary and the backup vservers are down or have reached their thresholds for handling requests.

Path Maximum Transmission Unit Discovery

Path Maximum Transmission Unit Discovery

Path maximum transmission unit (PMTU) discovery is a method for dynamically learning the maximum transmission unit of any Internet channel. The discovered PMTU is used by the TCP or UDP layer to create packets of an optimum size for that channel. This avoids fragmentation overhead on the routers in the path, and reassembly overhead on the receiving server.

PMTU discovery is an operational mode in the NetScaler. This mode enables the NetScaler to interoperate with other routers participating in PMTU discovery. In a typical topology, the NetScaler is deployed in front of the servers it manages, and either manages connections from clients on behalf of these servers (transparent mode), or manages connections with the servers and clients independently (endpoint mode).

The NetScaler in Transparent Mode

In transparent mode, if a managed server sets the DF bit and sends a datagram, and Path MTU is smaller than the size of the datagram, the NetScaler receives an ICMP error. When the NetScaler is operating in MIP mode, it adjusts the MTU to the MIP and updates the MTU database so that the lower MTU is used for subsequent connections. All packets subsequently sent via that connection have the DF bit unset.

In USIP mode, when an ICMP error message is received, the NetScaler translates it and sends it to the managed server. The managed server updates the MTU for that destination, and subsequent datagrams are sent with the lowered MTU. The MTU value for that client is also updated in the NetScaler. All new connections then use the lowered MTU.

The NetScaler in End-Point Mode

In end-point mode, the NetScaler separately manages connections to the servers it manages and connections to the clients that contact those servers.

For client connections, the NetScaler uses an Maximum Segment Size (MSS) of 1460 bytes. If the network contains a router that fragments the packet into multiple datagrams because of MTU mismatches, the router sends an ICMP error to the NetScaler. The NetScaler does not pass the error to the servers it manages,  but parses it and determines an MTU appropriate for that particular client. The NetScaler then updates the MTU database with the lower MTU. Thereafter, it uses the new MTU value for all new connections to that client.

Enabling or Disabling PMTU Discovery

The NetScaler does not participate in PMTU Discovery by default.

To enable or disable PMTU discovery using configuration utility

1. In the Navigation Pane, expand System, and then click Settings.

2. On the Settings page, under Modes & Features click Change modes.

3. In the Configure Modes dialog box, select the Path MTU Discovery check box to enable this feature, or clear the check box to disable it, and click OK

To enable or disable PMTU discovery using using the NetScaler command line

At the NetScaler command prompt, type:

enable ns mode PMTUD

or

disable ns mode PMTUD

Configuring TCP Window Scaling

The TCP window scaling option increases the TCP receive window size beyond its maximum value of 65,535 bytes. This TCP option is defined in RFC 1323. The window scaling option is required for efficient transfer of data over long fat networks (LFNs).

A TCP window determines the amount of outstanding (unacknowledged by the recipient) data a sender can send on a particular connection before receiving any acknowledgment from the receiver. The main purpose of the window is flow control.

The window size field in the TCP header is 16 bits, which limits the ability of the sender to advertise a window size larger than 65535 ( 2^16 - 1). The TCP window scale extension expands the definition of the TCP window to 30 bits by using a scale factor to carry this value in the 16 bit window field of the TCP header. In the NetScaler, the window scale expands the definition of the TCP window to 24 bits. The scale factor is carried in the new TCP window scale field. This field is sent only in a SYN packet (a segment with the SYN bit on).

The new window size is calculated by the receiver.

[right shifting the bits of the received window size by the scale factor value]

which is equivalent to

[(2^scale factor) * received window size]

Before configuring window scaling, make sure that:

• You do not set a high value for the Scale Factor, because this could have adverse effects on the NetScaler and the network.

• You have enabled SACK (selective acknowledgement).

• You do not configure window scaling unless you clearly know why you want to change the window size.

• Both hosts in the TCP connection send a window scale option during connection establishment. If only one side of a connection is sets this option, windows scaling will not be used for the connection.

• Each connection for same session (such as TCP session between Client and NetScaler and TCP session between NetScaler and Server having the same request/response) is an independent Window Scaling session. It is possible to have window scaling between the client and a Citrix NetScaler and not the a Citrix NetScaler and a server.

The Load Balancing Visualizer

The Load Balancing Visualizer

The Load Balancing Visualizer is a tool that you can use to view and modify the load balancing configuration in graphical format. Following is an example of the Visualizer display

You can use the visualizer to view the following:

a. The services and service groups that are bound to a virtual server.

b. The monitors that are bound to each service.

c. The policies that are bound to the virtual server.

d. The policy labels, if configured.

e. Configuration details of any displayed element.

f. Load balancing virtual server statistics.

g. Statistical information such as the number of requests received per second by the virtual server and the number of hits per second for rewrite, responder, and cache policies.

h. A comparative list of all the parameters whose values either differ or are not defined across service containers.

You can also use the Visualizer to add and bind new objects, modify existing ones, and enable or disable objects. Most configuration elements displayed in the Visualizer appear under the same names as in other parts of the configuration utility. However, unlike the rest of the configuration utility, the Visualizer groups services that have the same configuration details and monitor bindings into an entity called a service container.

A service container is set of similar services and service groups that are bound to a single load balancing virtual server. Next to the service container is a number that shows the number of services in the group. The services in the container have the same properties, with the exception of the name, IP address, and port, and their monitor bindings should have the same weight and binding state. When you bind a new service to a virtual server, it is placed into an existing container if its configuration and monitor bindings match those of other services; otherwise, it is placed in its own container.

The service container display can help you troubleshoot your configuration if something is not functioning as you expect. More than one container for a particular virtual server is an indication that something is wrong with the configuration of that virtual server and its services. To correct the problem, you must first identify the container that has the desired configuration. You can do so by using the Service Attributes Diff feature, described below. After you identify the container, you right-click the container and click Apply Configuration.

The following procedures provide only basic steps for using the Visualizer. Because the Visualizer duplicates functionality in other areas of the Load Balancing feature, other methods of viewing or configuring all of the settings that can be configured in the Visualizer are provided throughout the Load Balancing documentation.

To view load balancing virtual server properties by using the Visualizer

1. In the navigation pane, expand Load Balancing, and then click Virtual Servers.

2. In the details pane, select the virtual server that you want to view, and then click Visualizer.

3. In the Load Balancing Visualizer dialog box, you can adjust the viewable area as follows:

• Click the Zoom In and Zoom Out icons to increase or decrease the size of the viewed objects. You can click and drag the viewable area if an item that you want to see disappears from view after zooming in.

• Click the Best Fit icon to optimize the viewing area.

• Click the Save Image icon to save the graph as an image file.

• Click the image, hold down the mouse button, and drag the image to pan the view.

• In the Search in text field, begin typing the name of the item you are looking for. The item’s location is then highlighted. To restrict the search, click the dropdown menu and select the type of element that you want to search for

To view configuration details for services, service groups, and monitors by using the Visualizer

1. In the navigation pane, expand Load Balancing, and then click Virtual Servers.

2. In the details pane, select the virtual server that you want to view, and then click Visualizer.

3. In the Load Balancing Visualizer dialog box, to view configuration details for entities that are bound to this virtual server, you can do the following:

• To view a summary of bound services, position the cursor over the virtual server icon.

• To view services in a service container, click the icon for a service group, click the Related Tasks tab, click Show Member Services, and then click the service group name. To view additional details about the services click Open.

• To view common properties of services in a service group, click the icon for the service group, click the Related Tasks tab, and view the Details section of the tab.

• To view a comparative list of the parameters whose values either differ or are not defined across service containers, click the icon for a container, click the Related Tasks tab, and then click Service Attributes Diff. To view monitor binding details for the services in a container, in the Service Attributes Diff dialog box, in the Group column for the container, click Details.

• To view the details for a monitor, position the cursor over the icon or click the icon for the monitor. For additional details, click the icon, click the Related Tasks tab, and then click View Monitor.

• To view binding details of a monitor, click the connecting line between the monitor and its related service.

To view configuration details for policies and policy labels by using the Visualizer in the configuration utility

1. In the navigation pane, expand Load Balancing, and then click Virtual Servers.

2. In the details pane, select the virtual server that you want to view, and then click Visualizer.

3. In the Load Balancing Visualizer dialog box, to view configuration details for entities that are bound to this virtual server, you can do the following:

• To view policies that are bound to this virtual server, select one or more policy icons in the tool bar at the top of the dialog box. For example, you can select Compression, Filter, Rewrite, and Responder. If policy labels are configured, they appear in the main view area.

• For bound policies that appear in the view pane of the Visualizer, to view a policy’s expression and actions, position the cursor over the policy icon. To view binding details, position the cursor over the line that connects the policy to the virtual server. To view these details, click the policy. The details of the policy appear in the details pane.

To view statistical information by using the Visualizer

1. In the navigation pane, expand Load Balancing, and then click Virtual Servers.

2. In the details pane, select the virtual server that you want to view, and then click Visualizer.

3. In the Load Balancing Visualizer dialog box, to view statistical information, you can do the following:

• To view detailed statistics for the load balancing virtual server, click the icon for the virtual server, click the Related Tasks tab, and then click Statistics.

• To view the number of requests received per second at a given point in time by the load balancing virtual server and the number of hits per second at a given point in time for rewrite, responder, and cache policies, click Show Stats. The statistical information is displayed on the respective nodes in the Visualizer. This information is not updated in real time and has to be refreshed manually. To refresh this information, click Refresh Stats.

To save configuration properties for any entity by using the Visualizer

1. In the navigation pane, expand Load Balancing, and then click Virtual Servers.

2. In the details pane, select the virtual server that you want to view, and then click Visualizer.

3. To copy configuration details for an element to a document or spreadsheet, click the icon for that element, click Related Tasks.

4. In the Related Tasks tab, click Copy Properties and then paste the information into a document.

To bind a resource to a load balancing configuration by using the Visualizer

1. In the navigation pane, expand Load Balancing, and then click Virtual Servers.

2. In the details pane, select the virtual server for which you want to configure bindings (for example, Vserver-LB-1), and then click Visualizer.

3. In the Load Balancing Visualizer dialog box, click the Available Resources tab, select a resource type in the drop-down menu, and do one or more of the following:

• To bind a new monitor to a service, select Monitors, click a particular monitor, and then drag it to the service container icon. Use CONTROL + click to select multiple monitors and drag them to the service.

• To bind a service or service group, select Services or Service Groups, respectively, click a particular service or service group, and then drag it to the virtual server icon. To bind multiple services or service groups at one time, press CONTROL + click to select multiple services and drag them over the virtual server.

• To bind a policy, select one of the policy groups, click a particular policy, and then drag it to a virtual server. To bind multiple policies (classic policies only) at one time, press CONTROL + policies and drag them over the virtual server. For details on classic and advanced policies, see the Citrix NetScaler Policy Configuration and Reference Guide. For a link to the guide, see the Documentation Library.

To unbind a resource by using the Visualizer

1. In the navigation pane, expand Load Balancing, and then click Virtual Servers.

2. In the details pane, select the virtual server from which you want to unbind a service, policy, or monitor (for example, Vserver-LB-1), and then click Visualizer.

3. In the Load Balancing Visualizer dialog box, on the Visualizer image, click the connecting line between the resources that you want to unbind, and then click Unbind. For example, to unbind a monitor, you would click the link between the monitor and its bound service and click Unbind.

4. In the Unbind dialog box, click Yes.

To modify a resource in a load balancing configuration by using the Visualizer

1. In the navigation pane, expand Load Balancing, and then click Virtual Servers.

2. In the details pane, select the virtual server that you want to configure (for example, Vserver-LB-1), and then click Visualizer.

3. In the Load Balancing Visualizer dialog box, on the Visualizer image, double-click the resource that you want to modify.

4. In the modify dialog box, enter new settings for the resource.

To add, remove, or disable a resource in a load balancing configuration by using the Visualizer

1. In the navigation pane, expand Load Balancing, and then click Virtual Servers.

2. In the details pane, select the virtual server that you want to configure (for example, Vserver-LB-1), and then click Visualizer.

3. In the Load Balancing Visualizer dialog box, right-click the icon for the resource that you want to add, remove, or disable, and then select the corresponding option from the menu.

Accessing a Citrix NetScaler

Accessing a Citrix NetScaler

A NetScaler® appliance has both a command line interface (CLI) and a graphical user interface (GUI). The GUI includes a configuration utility for configuring the appliance and a statistical utility, called Dashboard. For initial access, all NetScaler appliances ship with the default NetScaler IP address (NSIP) of 192.168.100.1 and default subnet mask of 255.255.0.0. You can assign a new NSIP and an associated subnet mask during initial configuration.

Using the Command Line Interface

You can access the CLI either locally, by connecting a workstation to the console port, or remotely,

by connecting through secure shell (SSH) from any workstation on the same network. For more information about the features of the CLI, including SSH, see the Citrix NetScaler Command Reference Guide.

Logging on to the Command Line Interface through the Console Port

The NetScaler has a console port for connecting to a computer workstation. To log on to the

NetScaler, you need a serial crossover cable and a workstation with a terminal emulation program.

To log on to the CLI through the console port

1. Connect the console port to a serial port on the workstation, as described in “Connecting the

Console Cable” section in the Citrix Hardware Installation and Setup Guide.

2. On the workstation, start HyperTerminal or any other terminal emulation program. If the logon

prompt does not appear, you may need to press ENTER one or more times to display it.

3. Log on by using the administrator credentials. The command prompt (>) appears on the

workstation monitor.

Logging on to the Command Line Interface by using SSH

The SSH protocol is the preferred remote access method for accessing a NetScaler remotely from

any workstation on the same network. You can use either SSH version 1 (SSH1) or SSH version 2

(SSH2.)

To log on to a NetScaler by using an SSH client

1. On your workstation, start the SSH client.

2. For initial configuration, use the default NetScaler IP address (NSIP), which is 192.168.100.1.

For subsequent access, use the NSIP that was assigned during initial configuration. Select

either SSH1 or SSH2 as the protocol.

3. Log on by using the administrator credentials.

Using the Graphical User Interface

The graphical user interface includes a configuration utility and a statistical utility, called Dashboard,

either of which you access through a workstation connected to an Ethernet port on the NetScaler. If

your computer does not have a supported Java plugin installed, the utility prompts you to download

and install the plug-in the first time you log on. If automatic installation fails, you can install the plugin separately before you attempt to log on to the configuration utility or Dashboard.

The system requirements for the workstation running the GUI are as follows:

• For Windows-based workstations, a Pentium® 166 MHz or faster processor with at least

48 MB of RAM is recommended for applets running in a browser using a Java plugin product.

You should have 40 MB free disk space before installing the plug-in.

• For Linux-based workstations, a Pentium platform running Linux kernel v2.2.12 or above,

and glibc version 2.12-11 or later. A minimum of 32 MB RAM is required, and 48 MB RAM

is recommended. The workstation should support 16-bit color mode, KDE and KWM window

managers used in conjunction, with displays set to local hosts.

• For Solaris-based workstations, a Sun running either Solaris 2.6, Solaris 7, or Solaris 8, and

the Java 2 Runtime Environment, Standard Edition, version 1.6 or later.

Your workstation must have a supported web browser and version 1.6 or above of the Java® applet

plug-in installed to access the configuration utility and Dashboard.

Installing the Audit Server Files

Installing the Audit Server Files

This section describes the steps to install the audit server logging executable files on various operating systems. Copy the installation files from the product CD or download them from the site ftp.netscaler.com. Run the installations from the root user account.

The following table lists the minimum system requirements for configuring external audit server logging for Windows, Linux, and FreeBSD:

Operating System :

Windows

Linux

FreeBSD

For Windows / Linux / FreeBSD

Software Requirements :

• Windows XP Professional - Version 2002

• Windows 2003 server

• Windows 2000/NT

• Red Hat Enterprise Linux AS release 4 (Nahant) - Linux version 2.6.9-5.EL

• Red Hat 3.4.3-9.EL4 - Linux version 2.6.9-5.ELsmp

• Red Hat Linux 3.2.2-5 - Linux version 2.4.20-8

FreeBSD 4.9

Hardware Requirements :

• Processor - Intel x86 ~501MHz

• RAM - 512 MB

• Controller - SCSI

Installing Audit Server on the Linux Operating System

The following section describes the procedure to install the audit server  executable and other files on a system that runs Red Hat Linux.

To install on a Linux operating system

1. At a command prompt, type the following command to copy the NSauditserver.rpm file to a temporary directory:

cp <path_to_cd>/Utilities/auditserver/Linux/NSauditserver.rpm

/tmp

2. Type the following command to install the NSauditserver.rpm file:

rpm -i NSauditserver.rpm

This command extracts the files and installs them in:

• /usr/local/netscaler/etc

• /usr/local/netscaler/bin

• /usr/local/netscaler/samples

Uninstalling Audit Server on the Linux Operating System

This section describes the procedure to uninstall audit server logging on a server that runs on the Linux operating system.

To uninstall audit server logging

At a command prompt, type the following command to uninstall the audit server logging feature:

rpm -e NSauditserver

For more information about the NSauditserver RPM file, use the following command:

rpm -qpi *.rpm

To view the installed audit server files use the following command:

rpm -qpl *.rpm

*.rpm: Specifies the file name.

Installing Audit Server on the FreeBSD Operating System

This section describes the procedure to install the audit server executable and other files on the FreeBSD 4.4 operating system.

To install on a FreeBSD operating system

1. Copy the NSauditserver.tgz file to a <target directory> using the command:

cp <path_to_cd>/Utilities/auditserver/Freebsd/ NSauditserver.tgz /<target directory>

<path_to_cd>: Specifies the system path to the CD drive where the CD device is mounted.

<target directory>: Specifies the path to the directory to which the file should be copied.

2. Change to the <target directory>:

cd /<target directory>

3. Use the following command to install the package:

pkg_add NSauditserver.tgz

This command extracts the files and installs them in:

• /usr/local/netscaler/etc

• /usr/local/netscaler/bin

• /usr/local/netscaler/samples

4. At a command prompt, type the following command to check whether the package is installed:

pkg_info | grep NSauditserver

Uninstalling Audit Server on the FreeBSD Operating System

This section describes the procedure to uninstall audit server logging on a server that runs on the FreeBSD operating system.

To uninstall audit server logging

At a command prompt, type the following command to uninstall the audit server logging package:

pkg_delete NSauditserver

Installing Audit Server on the Windows Operating System

This section describes the procedure to install the audit server executable and other files on the Windows operating system.

To install on a Windows operating system

1. Extract the audserver.exe file from the NSauditserver.zip compressed file into a temporary directory. When the files are extracted, the following directories are created:

• \NS\BIN

• \NS\ETC

• \NS\SAMPLES

2. To install audit server logging as a service, run the following command from \NS\BIN directory:

audserver -install -f <directorypath> \auditlog.conf

<directorypath>: Specifies the path where the auditlog.conf file is available.

Uninstalling Audit Server on the Windows Operating System

This section describes the procedure to uninstall audit server logging on a server that runs on the Windows operating system.

To uninstall audit server logging

1. At a command prompt, change to the following directory:

cd \NS\BIN

2. Type the following command to uninstall the audit server logging feature:

audserver -remove

Audit Server Options

The following table describes the options you can use with the audserver command to configure audit server options.:

Audit Server Options :

Audit Server Commands :

audserver -help

audserver -addns -f <path to configuration file>

audserver -verify -f <path to configuration file>

audserver -start -f <path to configuration file>

audserver -stop

audserver -install -f <path to configuration file>

audserver -startservice

audserver -stopservice

audserver -remove

Specifies :

Lists all the available Audit Server options data.

On execution of the command, you are prompted to enter the IP address of the system.

Enter the Userid and Password of the system.

Checks for syntax or semantic errors in the configuration file, for example, auditlog.conf file.

Starts audit server logging based on the configuration settings in the configuration file, for example, auditlog.conf file.

Linux only:

To start the audit server as a background process, type & at the end of the command.

Linux only:

Stops audit server logging when audit server is started as a background process. Alternatively, use the Ctrl+C key to stop audit server logging.

Windows Only:

Installs the audit server logging client as a service on Windows.

Windows Only

Starts the audit server logging service, when you enter this command at a command prompt.

You can also start audit server logging from Start > Control Panel > Services option.

Windows Only

Removes the audit server logging service from the registry.

Run the audserver command from the directory in which the audit server executable is present:

• On Windows: \ns\bin

• On Solaris and Linux: \usr\local\netscaler\bin

The audit server configuration files are present in the following directories:

• On Windows: \ns\etc

• On Linux: \usr\local\netscaler\etc

The audit server executable is started as ./auditserver in Linux and FreeBSD.

Installing the NSWL files on the Logging System

Installing the NSWL files on the Logging System

This describes the steps to install the NetScaler Web Server Logging executable files (NSWL) on various operating systems (logging systems). Copy the installation files from the product CD or download them from ftp.netscaler.com. Run the installations from a root user account. In the procedures described in the following subsections, <path_to_cd> defines the system path to the drive where the CD device is mounted.

Installing NSWL on a Solaris Operating System

Use the following procedure to install the nswl executable and other files on a computer running the Solaris operating system.

To install NSWL on a Solaris operating system

1. Copy the NSweblog.tar file into a temporary directory using the command:

cp <path_to_cd>/Utilities/weblog/Solaris/NSweblog.tar /tmp

2. Change to the temporary directory:

cd /tmp

3. Extract the files from the *.tar file with the following command:

tar xvf NSweblog.tar

A directory NSweblog is created in the temporary directory, and the files are extracted to the NSweblog directory.

4. Install the package with the following command:

pkgadd -d .

The list of available packages appears. In the following example, one NSweblog package is shown:

1 NSweblog NetScaler Weblogging

(SunOS,sparc) 7.0

5. You are prompted to select the packages. Select the package number of the NSweblog to be installed.

After you select the package number and press Enter, the files are extracted and installed in the following directories. (The dot indicates the current directory.)

• /usr/local/netscaler/etc

• /usr/local/netscaler/bin

• /usr/local/netscaler/samples

6. To verify that the package is installed, enter the following command:

pkginfo | grep NSweblog

Installing NSWL on a Linux Operating System

Use the following procedure to install the nswl executable and the other files on a computer running the Red Hat™ Linux® operating system.

To install NSWL on a Linux operating system

1. Copy the NSweblog.rpm file into a temporary directory:

cp <path_to_cd>/Utilities/weblog/Linux/NSweblog.rpm /tmp

2. To install the nswl executable, use the following command:

rpm -i NSweblog.rpm

This command extracts the files and installs them in the following directories. (The dot indicates the current directory.)

• /usr/local/netscaler/etc

• /usr/local/netscaler/bin

• /usr/local/netscaler/samples.

To uninstall web server logging, use the following command.

rpm -e NSweblog

To get more information on the NSweblog RPM file, use the following command.

rpm -qpi *.rpm.

To view the installed web server logging files, use the following command (*.rpm is the file name).

rpm -qpl *.rpm

Installing NSWL on a FreeBSD Operating System

Use the following procedure to install the nswl executable and the other files on a computer running the FreeBSD 4.4 operating system.

To install NSWL on a FreeBSD operating system

1. At a command prompt, copy the NSweblog.tgz file into a temporary directory:

cp <path_to_cd>/Utilities/weblog/Freebsd/NSweblog.tgz /tmp

2. Change to the temporary directory:

cd /tmp

3. Install the package using the following command:

pkg_add NSweblog.tgz

This command extracts the files and installs them in the following directories. (The dot indicates the current directory.)

• /usr/local/netscaler/etc

• /usr/local/netscaler/bin

• /usr/local/netscaler/samples

4. To verify that the package is installed, use the following command:

pkg_info | grep NSweblog

Installing NSWL on a MAC Operating System

Use the following procedure to install the nswl executable and the other files on a computer running the MAC operating system.

To install NSWL on a MAC operating system

1. At a command prompt, copy the NSweblog.tgz file into a temporary directory with the following command:

cp <path_to_cd>/Utilities/weblog/macos/NSweblog.tgz /tmp

2. Change to the temporary directory:

cd /tmp

3. To install the package, use the pkg_add command:

pkg_add NSweblog.tgz

This command extracts the files and installs them in the following directories. (The dot indicates the current directory.)

• /usr/local/netscaler/etc

• /usr/local/netscaler/bin

• /usr/local/netscaler/samples

4. To verify that the package is installed, use the follwoing command:

pkg_info | grep NSweblog

Installing NSWL on a Windows Operating System

Use the following procedure to install the nswl executable and the other files on a computer running the Windows operating system.

To install NSWL on a Windows operating system

1. Copy the NSweblog.exe file (winzip executable) into a temporary directory.

2. The extracted files are installed in the following directories. (The dot indicates the current directory.)

• \NS\BIN

• \NS\ETC

• \NS\SAMPLES

3. To install web server logging as a service, at a command prompt, run the following command from the \NS\BIN path:

nswl -install -f <directorypath> \log.conf

<directorypath> specifies the path where the log.conf file is available.

4. To uninstall the web server logging, run the following command from the \NS\BIN folder:

nswl -remove

Installing NSWL on an AIX Operating System

Use the following procedure to install the nswl executable and the other files on a computer running the AIX operating system.

To install NSWL on an AIX operating system

1. Copy the NSweblog.rpm file into a temporary directory:

cp <path_to_cd>/Utilities/weblog/AIX/NSweblog.rpm /tmp

2. To install the nswl executable, use the following command:

rpm -i NSweblog.rpm

This command extracts the files and installs them in the following directories. (The dot indicates the current directory.)

• /usr/local/netscaler/etc

• /usr/local/netscaler/bin

• /usr/local/netscaler/samples.

To uninstall web server logging, use the following command.

rpm -e NSweblog

To get more information on the NSweblog RPM file, use the following command.

rpm -qpi *.rpm.

To view the installed web server logging files, use the following command (*.rpm is the file name).

rpm -qpl *.rpm

NSWL Options

The following table describes the options that you can use with the nswl executable.

nswl Command:

nswl -help

nswl -addns -f <path to configuration file>

nswl -verify -f <path to configuration file>

nswl -start -f <path to configuration file>

nswl -stop

nswl -install -f <path to configuration file> (Windows only)

nswl -startservice (Windows only)

nswl -stopservice (Windows only)

nswl -remove

Specifies:

Display all available nswl options

The system that gathers the log transaction data. You are prompted to enter the IP address of the system. Enter a valid username and password.

Check for syntax or semantic errors in the configuration file (for example, log.conf).

Start web server logging based on the settings in the configuration file (for example, log.conf).

For Solaris and Linux: To start web server logging as a background process, use and at the end of the command..

Solaris and Linux only

Stop web server logging, if nswl was started as a background process; otherwise, use CTRL+C to stop web server logging.

Installs the web server logging client as a service in Windows.

Start web server logging , using the settings in the configuration file (for example, log.conf) specified in the nswl install option.

Web server logging can also be started from Start > Control Panel > Services.

Stop Web server logging.

Remove the web server logging service from the registry.

Run the following commands from the directory in which the nswl executable is located:

• Windows: \ns\bin

• Solaris and Linux: \usr\local\netscaler\bin

The web server logging configuration files are located in the following directory path:

• Windows: \ns\etc

• Solaris and Linux: \usr\local\netscaler\etc

The nswl executable is started as .\nswl in Linux and Solaris.

Installing the Citrix NetScaler Hardware

Installing the Citrix NetScaler Hardware

This chapter describes how to install the Citrix NetScaler hardware and then connect it to a network and the power source.

Reviewing the Pre-Installation Checklist

Before installing your NetScaler, you should prepare all equipment and materials required for installation. Completing this preparation in advance will help ensure a smooth installation, with minimal interruptions.

Review the following checklist to ensure that you have all the equipment required to complete the installation:

Hardware Requirements

Open the box that contains the NetScaler, and verify that it contains the following components and accessories:

• One NetScaler

• One RJ-45-to-RS-232 serial cable

• One RJ-45-to-DB-9 adapter

• One (with 7000 system) or two (with 9010/10010/12000/15000/17000

system) AC power cables (Make sure a power outlet is available for each cable.)

• One mounting rail kit

In addition to the items listed above, the following items may also be required:

• Ethernet cables

• Ethernet switch ports to connect to the NetScaler

• Management workstation (PC or laptop)

Rack Mounting a Citrix NetScaler

Most appliances can be installed in standard server racks. The appliances ship with a set of rails, which you must install before you mount the appliance. The only tool you will need to install an appliance is a Phillips screwdriver.

The 7000 appliance requires one rack unit. The 9010, 10010, 12000, MPX 15000, and MPX 17000 appliances each require two rack units. Each of these units ships with a mounting rail kit that contains two rail assemblies, one for the left side and the other for the right side of the appliance, and screws to attach the rails. You must install the assemblies before mounting the appliance in the rack.

To rack mount a Citrix NetScaler

1. Install the rear inner rails just behind the preinstalled front inner rails.

A. Starting with the right side of the chassis, align the two square holes on the rail against the hooks.

B. Attach the rail to the chassis with screws.

C. Repeat steps A and B to install the left rear inner rail.

2. Install the rack rails.

A. Determine where you want to place a NetScaler in the rack.

B. Position the chassis rail guides at the desired location in the rack, keeping the sliding rail guide facing inward.

C. Screw the assembly to the rack using the brackets provided.

D. Repeat steps B and C to attach the assembly to the other side of the rack. Be sure that both the rack rails are at same height and that the rail guides are facing inward.

3. Install the NetScaler in the rack.

A. Line up the rear inner rails with the rack rails.

B. Slide the chassis rails into the rack rails, keeping the pressure even on both sides. You may need to depress the locking tabs when inserting the chassis.

C. When the NetScaler is pushed completely into the rack, the locking tabs should "click."

D. Insert and tighten the thumbscrews to secure the front of the chassis to the rack.

Installing an SFP

A Small Form Factor Pluggable (SFP) is a compact transceiver that can operate at speeds of up to 1 gigabit per second and is available in both copper and fiber types. Inserting an SFP copper transceiver converts the SFP port to a 1000BASET port. Inserting an SFP fiber transceiver converts the SFP port to a 1000BASE-X port. Auto-negotiation is enabled by default on the SFP port into which you insert your SFP transceiver. As soon as a link between the port and the network is established, the speed and mode are matched on both ends of the cable.

Insert SFP transceivers into the SFP ports on the front panel of the appliance. Removing an SFP transceiver does not affect the functioning of the appliance, except that the port is no longer available for traffic. However, frequent installation and removal of transceivers shortens their life span. Follow the removal procedure carefully to avoid damaging the SFP transceiver or the appliance.

To install a copper SFP

1. Carefully remove a copper SFP module from the box.

2. Insert the copper SFP in the SFP slot, with the locking hinge in the DOWN position.

3. Push the copper SFP until it is in the locking position.

4. Move the locking hinge to the UP position and push the module into the slot.

To Install a fiber SFP

1. Carefully remove a fiber SFP module from the box.

2. Insert the fiber SFP in the SFP slot, with the locking hinge in the UP position.

3. Push the fiber SFP until it is in the locking position.

4. Move the locking hinge to the DOWN position.

5. Remove the fiber dust protector.

6. Move the locking hinge to the UP position and push the module into the slot.

Installing an XFP

A 10-Gigabit Small Form Factor Pluggable (XFP) is a compact optical transceiver that can operate at speeds of up to 10 gigabits per second. Autonegotiation is enabled by default on the XFP ports into which you insert your XFP transceiver. As soon as a link between the port and the network is established, the speed and mode are matched on both ends of the cable.

Insert the XFP transceivers into the XFP ports on the front panel of the appliance. Removing an XFP transceiver does not affect the functioning of the appliance, except that the port is no longer available for traffic. However, frequent installation and removal of transceivers shortens their life span. Follow the removal procedure carefully to avoid damaging the transceiver or the appliance.

To Install an XFP

1. Remove an XFP module carefully from the box.

2. Insert the XFP in the XFP slot, with the locking hinge in the UP position.

3. Push the XFP until it is in the locking position.

4. Move the locking hinge to the DOWN position.

5. Remove the fiber dust protector.

6. Move the locking hinge to the UP position and push the module into the slot.

Connecting a Citrix NetScaler to the Network

Connect the ports on a NetScaler to the network ports on the appropriate switches using the Ethernet/Fiber optic cables.

If your configuration does not require all of the available ports, you can use any of the ports. However, disabling the unused ports is advisable, and is mandatory in an HA configuration.

By default a NetScaler is configured to use auto negotiation. For a first-time installation, you should configure your switch to use auto negotiation for those ports that are connected to the NetScaler. After initial login and configuration, you can disable auto negotiation.

Connecting the Console Cable

Use the provided console cable when connecting the NetScaler to a PC or terminal. The PC or terminal must support VT100 terminal emulation and must be configured for 9600 baud, 8 data bits, 1 stop bit, and no parity.

Connecting a Citrix NetScaler to the Power Source

The 7000 system has one power supply. The 9010, 10010, 12010, 15000, and 17000 systems each have two power supplies but can operate with a single power supply. The extra power supply is a backup.

To connect the 7000 system to the power source

1. Plug the power cord into the inlet receptacle on the back of the chassis.

2. Plug the other end of the power cord into a standard 110V/220V power outlet.

3. Turn the NetScaler on by pressing the ON/OFF switch on the back of the chassis. The LCD on the front should appear backlit once the NetScaler is operational.

To connect the 9010/10010/12000 system to the power source

1. Plug the power cord to the inlet receptacle on the back of the chassis.

2. Plug the other end of the power cord into a standard 110V/220V power outlet.

3. Repeat steps 1 and 2 to connect the other power inlet to a standard 110V/ 220V power outlet using another power cord.

4. Turn the NetScaler on by pressing the ON/OFF switch on the back of the chassis. The green LED on the back begins to glow, indicating that the NetScaler is powered on. The LCD on the front appears backlit once the NetScaler is operational.

The 9010/10010/12000 systems emit a high pitched alert if one power supply fails or if you connect only one power cord to the chassis. To silence the alarm, press the small red button on the back of the chassis.

Understanding the Citrix NetScaler

Understanding the Citrix NetScaler

What Is a Citrix NetScaler?

optimizes, and secures Layer 4-Layer 7 (L4-L7) network traffic for Web applications. Features include load balancing, compression, Secure Sockets Layer (SSL) offload, a built-in application firewall, and dynamic content caching.

A NetScaler performs application-specific traffic analysis to provide a more effective implementation of the features. For example, a NetScaler makes load balancing decisions on individual HTTP requests rather than on the basis of longlived TCP connections, so that the failure or slowdown of a server is managed much more quickly and with less disruption to clients. Other features can be used to reduce load and simplify server-farm management, and to accelerate end-user performance.

Switching Features

Its switching features enable a NetScaler to manage application traffic in anefficient manner. When deployed in front of application servers, a NetScaler ensures optimal distribution of traffic by the way in which it directs client requests. Administrators can segment application traffic according to information in the body of an HTTP or TCP request, and on the basis of L4-L7 header information such as URL, application data type, or cookie. Numerous loadbalancing algorithms and extensive server health checks provide greater application availability by ensuring that client requests are directed to the appropriate servers.

Security and Protection Features

Security and protection features help block the theft and leakage of data by protecting Web applications from application-layer attacks. A NetScaler allows legitimate client requests and can block malicious requests. It provides built-in defenses against denial of service (DoS) attacks and supports features that protect the application against legitimate surges in application traffic that would otherwise overwhelm the servers. An available built-in firewall protects Web applications from application-layer attacks, including buffer overflow exploits, SQL injection attempts, cross-site scripting attacks, and more. In addition, the firewall provides identity theft protection by securing confidential corporate information and sensitive customer data.

Optimization Features

Optimization features offload resource-intensive operations such as Secure Sockets Layer (SSL) processing, data compression, and the caching of static and dynamic content from servers. This improves the performance of the servers in the server farm and therefore speeds up applications. A NetScaler supports several transparent TCP optimizations, which mitigate problems caused by high latency and congested network links, accelerating the delivery of applications while requiring no configuration changes to clients or servers.

Where Does a Citrix NetScaler Fit in the Network?

A NetScaler resides between the clients and the servers, so that client requests and server responses pass through it. In a typical installation, virtual servers (vservers) configured on the NetScaler provide connection points that clients use to access the applications behind the NetScaler. In this case, the NetScaler owns public IP addresses that are associated with its vservers, while the real servers are isolated in a private network. It is also possible to operate the NetScaler in a transparent mode as an L2 bridge or L3 router, or even to combine aspects of these and other modes.

Physical Deployment Modes

A NetScaler logically residing between clients and servers can be deployed in either of two physical modes: inline and one-arm.

In the normal inline mode, multiple network interfaces are connected to different Ethernet segments and the NetScaler is placed between the clients and the servers. The NetScaler has a separate network interface to each client network and a separate network interface to each server network. The NetScaler and the servers can exist on different subnets in this configuration. It is possible for the servers to be in a public network and the clients to directly access the servers through the NetScaler, with the NetScaler transparently applying the L4-L7 features. Usually, vservers (described later) are configured to provide an abstraction of the real servers. The following diagram illustrates a typical inline deployment.

                                    Inline Deployment

In a less common version of one-arm mode, only one network interface of the NetScaler is connected to an Ethernet segment. The NetScaler in this case does not isolate the client and server sides of the network, but provides access to applications through configured vservers. This version of one-arm mode can simplify network changes needed for NetScaler installation in some environments.

Citrix NetScaler as an L2 Device

A NetScaler functioning as an L2 device is said to operate in L2 mode. In L2 mode, the NetScaler forwards packets between network interfaces when all of the following conditions are met:

1. The packets are destined to another device's media access control (MAC) address.

2. The destination MAC address is on a different network interface.

3. The network interface is a member of the same virtual LAN (VLAN).

By default all network interfaces are members of a pre-defined VLAN, VLAN 1. Address Resolution Protocol (ARP) requests and responses are forwarded to all network interfaces that are members of the same VLAN. To avoid bridging loops, L2 mode must be disabled if another L2 device is working in parallel with the NetScaler.

Citrix NetScaler as a Packet Forwarding Device

A NetScaler can function as a packet forwarding device, and this mode of operation is called L3 mode. When a NetScaler in L3 mode receives, on its MAC address, unicast packets that are destined for an unknown IP address, it forwards them if there is a proper route to the destination. A NetScaler can also route packets between VLANs.

In both modes of operation, L2 and L3, a NetScaler generally drops packets that are in:

1. Multicast frames

2. Unknown protocol frames destined for a NetScaler's MAC address (non-IP and non-ARP)

3. Spanning Tree protocol

How a Citrix NetScaler Communicates with Clients and Servers

A NetScaler is usually deployed in front of a server farm and functions as a transparent TCP proxy between clients and servers, without requiring any clientside configuration. This basic mode of operation is called Request Switching technology and is the core of NetScaler functionality. Request Switching enables a NetScaler to multiplex and offload the TCP connections, maintain persistent connections, and manage traffic at the request (application layer) level. This is possible because the NetScaler can separate the HTTP request from the TCP connection on which the request is delivered.

Depending on the configuration, a NetScaler may process the traffic before forwarding the request to a server. For example, if the client attempts to access a secure application on the server, the NetScaler might perform the necessary SSL processing before sending traffic to the server. To facilitate efficient and secure access to server resources, a NetScaler uses a set of IP addresses collectively known as NetScaler-owned IP addresses.

Understanding NetScaler-owned IP Addresses

To function as a proxy, a NetScaler a uses a variety of IP addresses. The key NetScaler-owned IP addresses are:

1. Mapped IP address (MIP). The MIP is used for server-side connections. It is not the IP address of the NetScaler. In most cases, when the NetScaler receives a packet, it replaces the source IP address with the MIP before sending the packet to the server. With the servers abstracted from the clients, the NetScaler manages connections more efficiently.

2. Virtual server IP address (VIP). A VIP is the IP address associated with a vserver. It is the public IP address to which clients connect. A NetScaler managing a wide range of traffic may have many VIPs configured.

3. NetScaler IP address (NSIP). The NSIP is the IP address for general system and management access to the NetScaler itself.

4. Subnet IP address (SNIP). When the NetScaler is attached to multiple subnets, SNIPs may be configured for use as MIPs providing access to those subnets.

How Traffic Flows Are Managed

Because a NetScaler functions as a TCP proxy, it translates IP addresses before sending packets to a server. When you configure a vserver, clients connect to a VIP on the NetScaler instead of directly connecting to a server. Based on the settings on the vserver, the NetScaler selects an appropriate server and sends the client's request to that server. By default, the NetScaler uses the MIP to establish connections with the server, as illustrated in the following diagram.

                       Vserver-based connections

In the absence of a vserver, when a NetScaler receives a request, it transparently forwards the request to the server. This is called the transparent mode of operation. When operating in transparent mode, a NetScaler translates the source IP addresses of incoming client requests to the MIP but does not change the destination IP address. For this mode to work, L2 or L3 mode needs to be configured appropriately.

For cases in which the servers need the actual client IP address, the NetScaler can be configured to modify the HTTP header by inserting the client IP address as an additional field, or configured to use the client IP address instead of the MIP for connections to the servers.

Traffic Management Building Blocks

The configuration of a NetScaleris typically built up with a series of virtual entities that serve as building blocks for traffic management. The building block approach helps separate traffic flows. Virtual entities are abstractions, typically representing IP addresses, ports, and protocol handlers for processing traffic. Clients access applications and resources through these virtual entities. The most commonly used entities are vservers and services. Vservers represent groups of servers in a server farm or remote network, and services represent specific applications on each server.

Most features and traffic settings are enabled through virtual entities. For example, you can configure a NetScaler to compress all server responses to a client that is connected to the server farm through a particular vserver. To configure the NetScaler for a particular environment, you need to identify the appropriate features and then choose the right mix of virtual entities to deliver them. Most features are delivered through a cascade of virtual entities that are bound to each other. In this case, the virtual entities are like blocks being assembled into the final structure of a delivered application. You can add, remove, modify, bind, enable, and disable the virtual entities to configure the features.The following diagram illustrates the concepts covered in this section.

            How traffic management building blocks work

A Simple Load Balancing Configuration

In the example shown in the diagram, the NetScaler is configured to function as a load balancer. For this configuration, you need to configure virtual entities specific to load balancing and bind them in a specific order. As a load balancer, a NetScaler distributes client requests across several servers and thus optimizes the utilization of resources.

The basic building blocks of a typical load balancing configuration are services and load balancing vservers. The services represent the applications on the servers. The vservers abstract the servers by providing a single IP address to which the clients connect. To ensure that client requests are sent to a server, you need to bind each service to the vserver. That is, you must create services for every server and bind the services to the vserver. Clients use the VIP to connect to a NetScaler. When the NetScaler receives client requests on the VIP, it sends them to a server determined by the load balancing algorithm. Load balancing uses a virtual entity called a monitor to track whether a specific configured service (server plus application) is available to receive requests.

          Load Balancing vserver, services, and monitor

In addition to configuring the load balancing algorithm, you can configure several parameters that affect the behavior and performance of the load balancing configuration. For example, you can configure the vserver to maintain persistence based on source IP address. The NetScaler then directs all requests from any specific client to the same server.

Understanding Virtual Servers

A vserver represents one or more applications in a server farm. The vserver is a named NetScaler entity that external clients can use to access applications hosted on the servers. It is represented by an alphanumeric name, virtual IP address  (VIP), port, and protocol. The name of the vserver is only of local significance and is designed to make the vserver easier to identify. When a client attempts to access applications on a server, it sends a request to the VIP instead of the IP address of the physical server. When the NetScaler receives a request on the VIP, it terminates the connection at the vserver and uses its own connection with the server on behalf of the client. The port and protocol settings of the vserver determine the applications that the vserver represents. For example, a Web server can be represented by a vserver and a service whose port and protocol are set to 80 and HTTP, respectively. Multiple vservers can use the same VIP but different protocols and ports.

Vservers are points for delivering features. Most features, like compression, caching, and SSL offload, are normally enabled on a vserver. When the NetScaler receives a request on a VIP, it chooses the appropriate vserver by the port on which the request was received and its protocol. The NetScaler then processes the request as appropriate for the features configured on the vserver.

Setting up a High Availability Pair

Setting up a High Availability Pair

You can deploy two NetScalers in a high availability configuration, where one unit actively accepts connections and manages servers while the secondary unit monitors the first. The NetScaler that is actively accepting connections and managing the servers is called a primary unit and the other one is called a secondary unit in a high availability configuration. If there is a failure in the primary unit, the secondary unit becomes the primary and begins actively accepting connections.

Each NetScaler in a high availability pair monitors the other by sending periodic messages, called heartbeat messages or health checks, to determine the health or state of the peer node. If a health check for a primary unit fails, the secondary unit retries the connection for a specific time period. (For more information about time intervals, see the “High Availability” chapter in the Citrix NetScaler Networking Guide.) If a retry does not succeed for the specific time period, the secondary unit takes over for the primary unit in a process called failover. The following diagram shows two high availability configurations, one with NetScalers deployed in one-arm mode and the other with NetScalers deployed in two-arm mode.

High availability in one-arm mode and high availability in two-arm mode

In one-arm configuration, both NS1 and NS2 and servers S1, S2, and S3 are connected to the switch.

In two-arm configuration, both NS1 and NS2 are connected to two switches. The servers S1, S2, and S3 are connected to the second switch. The traffic between client and the servers passes through either NS1 or NS2.

Configuring a High Availability Pair for the First Time

To steps to set up a high availability environment, configure one NetScaler as primary and another as secondary. Perform the following tasks on each of the NetScalers:

• Add a node.

• Disable high availability monitoring for unused interfaces.

Adding a Node

A node is a logical representation of a peer NetScaler. It identifies the peer unit using a unique ID and its NSIP. A NetScaler uses these parameters to communicate with the peer and track its state. When you add a node, the primary and secondary units exchange heartbeat messages asynchronously. The node ID is an integer that must not be greater than 64.

To add a node using the configuration utility

1. In the navigation pane, expand System and click High Availability. The High Availability page appears in the details pane.

2. Click the Nodes tab. The Nodes page appears in the details pane.

3. Click Add. The Add Node dialog box appears.

4. In the ID text box, type an ID, for example, 3.

5. In the IP Address text box, type an IP Address, for example, 10.102.29.170.

6. Click Create. The node you created appears in the Nodes page.

To add a node using the NetScaler command line

At a NetScaler command prompt, type:

add HA node 3 10.102.29.170

Disabling High Availability Monitoring for Unused Interfaces

The high availability monitor is a virtual entity that monitors an interface. You must disable the monitor for the interfaces that are not connected or being used for traffic. When the monitor is enabled on one of the interfaces and the status of this interface is DOWN, the state of the node becomes NOT UP. In a high availability configuration, a primary node entering a NOT UP state might cause a high availability failover. An interface is marked DOWN under the following conditions:

• The interface is not connected.

• The interface is not working properly.

• The cable connecting the interface is not working properly.

To disable the high availability monitor for an unused interface using the configuration utility

1. In the navigation pane, expand Network and click Interfaces. The Interfaces page appears in the details pane.

2. Select the interface for which the monitor must be disabled.

3. Click Open. The Modify Interface dialog box appears.

4. In HA Monitoring, select the OFF option.

5. Click OK. The Modify Interface dialog box appears.

To disable the high availability monitor for an unused interface using the NetScaler command line

At a NetScaler command prompt, type:

set interface 1/8 haMonitor OFF