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.

Traffic Management Building Blocks

Traffic Management Building Blocks

The configuration of a NetScaler is 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 figure shows the concepts covered in this section.

A Simple Load Balancing Configuration

In the example shown in the following figure, 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 a vserver. That is, you must create services for

every server and bind the services to a 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.

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 IP address to the same server.

Understanding Policies and Expressions

A policy defines specific details of traffic filtering and management on a NetScaler. It consists of two

parts: the expression and the action. The expression defines the types of requests that the policy

matches. The action tells the NetScaler what to do when a request matches the expression. As

an example, the expression might be to match a specific URL pattern to a type of security attack,

with the action being to drop or reset the connection. Each policy has a priority, and the priorities

determine the order in which the policies are evaluated.

When a NetScaler receives traffic, the appropriate policy list determines how to process the traffic.

Each policy on the list contains one or more expressions, which together define the criteria that a

connection must meet to match the policy.

For all policy types except Rewrite policies, a NetScaler implements only the first policy that a request matches, not any additional policies that it might also match. For Rewrite policies, the NetScaler evaluates the policies in order and, in the case of multiple matches, performs the

associated actions in that order. Policy priority is important for getting the results you want.

Accelerating Load Balanced Traffic by Using Compression

Compression is a popular means of optimizing bandwidth usage, and all modern web browsers

support compressed data. If you enable the AppCompress feature, the Citrix NetScaler intercepts

requests from clients and determines whether the client can accept compressed content. After

receiving the HTTP response from the server, the NetScaler examines the content to determine

whether it is compressible. If the content is compressible, the NetScaler compresses it, modifies

the response header to indicate the type of compression performed, and forwards the compressed

content to the client.

NetScaler compression is a policy-based feature. A policy filters requests and responses to identify

responses to be compressed, and specifies the type of compression to apply to each response. The NetScaler provides several built-in policies to compress common MIME types such as text/ html, text/ plain, text/xml, text/css, text/rtf, application/msword, application/vnd.ms-excel, and application/vnd.mspowerpoint.

You can also create custom policies. The NetScaler does not compress compressed MIME types

such as application/octet-stream, binary, bytes, and compressed image formats such as GIF and

JPEG.

To configure compression, you must enable it globally and on each service that will provide responses that you want compressed. If you have configured vservers for load balancing or content

switching, you should bind the polices to the vservers. Otherwise, the policies apply to all traffic that

passes through the NetScaler.

Network Topology

Where Does a NetScaler Fit in the Network?

NetScaler resides in front of web and applications servers, so that client requests and server responses pass through it. In a typical installation, virtual servers (vservers) configured on the NetScaler provide connection/termination points that clients use to access the applications delivered by 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

NetScaler can be deployed in either of two physical modes: inline and one-arm. In inline mode, ultiple 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 are configured to provide an abstraction of the real servers.

The following figure shows a typical inline deployment.

In 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. 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:

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

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

• 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. With L3 mode enabled, the NetScaler forwards any received unicast packets that are

destined for an IP address that it does not have internally configured, if there is a 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:

• Multicast frames

• Unknown protocol frames destined for a NetScaler’s MAC address (non-IP and non-ARP)

• Spanning Tree protocol (unless BridgeBPDUs is ON)

How a NetScaler Communicates with Clients and Servers

A NetScaler appliance is usually deployed in front of a server farm and functions as a transparent

TCP proxy between clients and servers, without requiring any client-side 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. To manage your network traffic, you assign NetScaler-owned IP addresses to virtual entities that become the building blocks of your configuration. For example, to configure load balancing, you create virtual servers (vservers) to receive client requests and distribute them to services, which are entities representing the applications on your servers.