Basic Administration for Citrix NetScaler 9.2

Basic Administration for Citrix NetScaler 9.2

1. Introducing and Deploying Citrix NetScaler 1.1. Introduction to the NetScaler System NetScaler Functionality 1.2. Planning a NetScaler Deployment One-Arm Mode Two-Arm and Inline Mode 1.3. Deployment Scenarios Flex Tenancy Displacement New Technology 1.4. NetScaler Platform and Product Editions 1.5. Product Features Lower Total Cost of Ownership Application Acceleration Application Security Application Availability Simple Manageability Web 2.0 Optimization 1.6. Hardware Platforms NetScaler MPX 21500/19500/17500/ NetScaler MPX 15500/15000/12500/ NetScaler MPX 9500/ 9010 FIPS/MPX 7500/5500/VPX 10/200/ nCore NetScaler VPX 1.7. Hardware Components 1.8. NetScaler Architecture Overview 1.9. Initial NetScaler Access Basic Administration for Citrix NetScaler 9.2

2. Networking 2.1. NetScaler Architecture Overview Connection Separation Basic NetScaler System Networking Rules Multiplexing 2.2. NetScaler-Owned IP Addresses NetScaler IP Address Configure a NetScaler IP Address Subnet IP Address Mapped IP Address Virtual IP Address 2.3. NetScaler Modes Layer-3 Mode Layer-2 Mode MAC-Based Forwarding Mode Use Source IP Mode 2.4. Network Address Translation NetScaler Supported Network Address Translation Capabilities Inbound Network Address Translation Reverse Network Address Translation (RNAT) IP Addresses for RNAT Configuring Reverse Network Address Translation 2.5. Virtual Local Area Networks 2.6. Link Aggregation Basic Administration for Citrix NetScaler 9.2

3. Configuring High Availability 3.1. Introduction to High Availability High Availability Functionality 3.2. High Availability Node Configuration Pre-Configuration Checklist Virtual Media Access Control Address Configuring Primary and Secondary Nodes High-Availability Status 3.3. Propagation and Synchronization Disabling Command Propagation Automatic Configuration Synchronization Forced Synchronization Performing a Forced Failover 3.4. High Availability Management Upgrading a High Availability Pair Basic Administration for Citrix NetScaler 9.2

4. Securing the NetScaler System 4.1. NetScaler System Communication NetScaler Communication Types Security Parameter Components 4.2. Access Control Lists Simple Access Control Lists Matching Access Control List Entries Traffic Identification Access-Control-List Syntax Format and Precedence Access-Control-Lists Precedence IPv6-Based Access-Control-List Support 4.3. Access-Control-List Configuration Simple Access-Control-List Configuration (Command-Line Interface) Configuring Detailed Access Control Lists (Command-Line Interface) Creating and Removing Access Control Lists (Command-Line Interface) Applying Access Control Lists (Command-Line Interface) Viewing Access Control Lists (Command-Line Interface) Access-Control-List Priorities (Command-Line Interface) Removing Access Control Lists from the System (Command-Line Interface) Access-Control-List Syntax Format for Different NetScaler Versions Basic Administration for Citrix NetScaler 9.2

5. Configure Load Balancing 5.1. Load-Balancing Process 5.2. Entity Management Creating Servers Creating Services Creating Virtual Servers Binding Services Monitors 5.3. Load-Balancing Traffic Types 5.4. Service Monitoring Binding Monitors Default Monitors Monitor Parameters Creating Monitors HTTP Monitoring ECV Monitoring HTTP-ECV and TCP-ECV Monitoring Process HTTP-INLINE Parameters Reverse Condition Monitoring Setting Monitor Thresholds 5.5. Load-Balancing Topology 5.6. Load-Balancing Methods Service Weights Persistent Clients Session Persistence Non-Persistent Clients Persistence Methods Persistence Tables Basic Administration for Citrix NetScaler 9.2

5.7. Additional Load-Balancing Options 5.8. Advanced Load-Balancing Methods Token Hash Load-Balancing 5.9. Link Load Balancing Link Load-Balancing Policy Custom Load Load Monitor Process Load Monitor Parameters Binding Metrics Service and Virtual Server Management Service and Virtual Statistics Disabling Service and Virtual Servers Removing Services and Virtual Servers Monitoring Traffic Distribution Load Balancing Visualizer Basic Administration for Citrix NetScaler 9.2

6. Configuring SSL Offload 6.1. SSL and Digital Certificates 6.2. Important Concepts: SSL 6.3. SSL Offload Overview 6.4. Offload Performance Features and Benefits 6.5. SSL Administration Important Concepts: Certificates SSL Keys Generating a Certificate Signing Request SSL Certificates Generate a Certificate Certificate Key Pairs Adding a Certificate Key Binding a Certificate Key 6.6. SSL Offload SSL Termination Points 6.7. Deployment Scenarios Front-end SSL with Back-end HTTP Requirements Securing Traffic Between a Client and the NetScaler System Front-end SSL with Back-end SSL Requirements Securing Traffic Between the NetScaler and the Server Front-end SSL_TCP with Back-end TCP Requirements Securing TCP Traffic Between a Client and the NetScaler System SSL_Bridge SSL_Bridge Requirements 6.8. Configuring SSL Offload 6.9. Creating SSL Virtual Servers Binding an SSL Virtual Server Advanced SSL Settings Configuring Advanced Settings Basic Administration for Citrix NetScaler 9.2

7. Configuring Global Server Load Balancing 7.1. GSLB Concepts GSLB Conversation Process GSLB Entities 7.2. Metric Exchange Protocol Metric Information Types GSLB Monitoring Configuration 7.3. GSLB DNS Methods Authoritative DNS Service Name Servers DNS Request Scenarios Resource Records 7.4. GSLB Persistence 7.5. Configuring DNS Virtual Servers 7.6. GSLB Configurations 7.7. Implementing Traditional GSLB 7.8. Implementing Proximity-based GSLB Proximity-Based Load-Balancing Methods 7.9. Implementing GSLB Failover for Disaster Recovery Configuring GSLB Virtual Servers Configuring ADNS Synchronizing a GSLB Configuration Basic Administration for Citrix NetScaler 9.2

8. Management 8.1. Simple Network Management Protocol Managed devices SNMP Agents Managers Management Information Base Community Strings Traps Configuring SNMPv1 and SNMPv Configuring SNMP Managers Configuring MIB System Variables Configuring Community Strings SNMPv1 and SNMPv2 Communication Process Configuring SNMP Traps Configuring Alarms 8.2. SNMPv Dashboard System and Feature Counters Reporting and Monitoring Tools 8.4. Auditing and Logging 8.5. Configuring an Auditing Server 8.6. Global Auditing Parameters 8.7. Configuring Auditing Policies Binding Auditing Policy Audit Messages 8.8. Replacing a High-Availability Node 8.9. Upgrading as a Standalone NetScaler System Upgrading a High-Availability Pair Password Recovery Basic Administration for Citrix NetScaler 9.2

1. Introducing and Deploying Citrix NetScaler
Overview:- Citrix NetScaler is: An asymmetrical solution A complete traffic management platform for all types of traffic A highly effective solution for optimizing HTTP traffic A solution designed from the ground up for high speed and performance Objectives By the end of this module, you will be able to: Identify the NetScaler hardware components. Identify deployment scenarios. Identify deployment considerations. Basic Administration for Citrix NetScaler 9.2

1.1. Introduction to the NetScaler System
The NetScaler system is an integrated Web application delivery controller that slashes server and bandwidth requirements, cutting the costs of delivering enterprise applications in half. The NetScaler system gives IT managers the ability to instantly tap unrealized efficiency gains across all phases of the application lifecycle, without having to become application experts. The NetScaler system functions as an application accelerator through caching and HTTP compression, and provides advanced management through layer 4-7 load-balancing and content-switching functions. The NetScaler also includes application security using a Web application firewall, including PCI-DDS security mandated protections, and SSL VPN. The NetScaler system offloads application and Web servers to ensure application availability, increased security through SSL, and server consolidation. It reduces the total cost of ownership of Web application delivery and optimizing the user experience. Basic Administration for Citrix NetScaler 9.2

1.1.1. NetScaler Functionality
NetScaler content switching and load balancing dramatically improve the throughput and scalability of an Internet application infrastructure by decoupling each application request/response flow from the underlying transport. Content switching and load balancing ensure the most efficient use of transport protocols and resources, even in a scenario in which all of the content is encrypted or compressed. The NetScaler system manages the complete lifecycle of the request/response transaction. With this management, the NetScaler system is uniquely equipped to direct and control application requests most efficiently, from the client to the server and back again. Connection multiplexing (also known as connection reuse) allows the servers to handle significantly fewer connections than are received by the NetScaler system. The more efficient use of the HTTP specification provides a significant boost to the effective capacity of the server by reducing server CPU load. With this separation, the NetScaler system can use the TCP proxy architecture to multiplex and reuse the server-side TCP connection independently from a client-side connection. This reuse of established and idle server-side TCP connections reduces the TCP overhead on Web servers. Basic Administration for Citrix NetScaler 9.2

1.2. Planning a NetScaler Deployment
The NetScaler system can be deployed in the following network configurations: One-arm mode Two-arm mode Inline mode Basic Administration for Citrix NetScaler 9.2

One-Arm Mode The figure depicts a one-arm mode configuration. The client must access the server through a virtual IP (VIP) address configured on the NetScaler system. A one-arm mode configuration allows: A simple configuration with one physical interface and no risk of bridge loops One or many VLANs with 802.1q tagging Link aggregation to satisfy bandwidth requirements One-arm configurations are not recommended: When a server needs to see the actual IP address of the client and the default gateway of the server cannot be changed to an IP address on the NetScaler system When the servers are accessed directly and the default gateway has been changed to the NetScaler system, a situation that is sometimes addressed with the use of name-based services and explicit server definitions Basic Administration for Citrix NetScaler 9.2

1.2.2. Two-Arm and Inline Mode
Two-Arm Mode The figure depicts a two-arm mode configuration. The appliance is placed between two layer-2 switches, with one network interface on the appliance connected to the client network and another network interface connected to the server network. Two-arm mode has the following benefits: It allows layer-3 (routed) deployments with split subnets. It allows layer-2 (bridged) deployments with one subnet on each side. It supports transparent compression and SSL offload. It supports Use Source IP (USIP) address processing without server changes. Two-arm topologies work in some situations in which one-arm does not work. With two-arm mode, you can use the NetScaler system to route some traffic as well as to balance load. Inline Mode Inline mode is a special case of two-arm mode. In inline mode, multiple network interfaces are connected to different Ethernet segments and the NetScaler appliance is placed between the clients and the servers. The only route is through the NetScaler appliance. Basic Administration for Citrix NetScaler 9.2

1.3. Deployment Scenarios The NetScaler system can be integrated into any network either as a complement to existing load balancers, servers, caches or firewalls, or as a standalone solution capable of providing one or more of those functionalities. A successful NetScaler deployment requires planning for the correct deployment type, as well as a full migration of current network functions. NetScaler deployment options include: Flex tenancy Displacement New technology Basic Administration for Citrix NetScaler 9.2

Flex Tenancy The figure illustrates a flex tenancy deployment scenario. NetScaler physical and virtual appliances can be used together in a two-tier architecture--a flex-tenancy architecture--with each tier dedicated to managing specific actions. In the figure, the flex tenancy architecture segments Web application deployment delivery services into two tiers: share-network-service flex tier and application-specific tenant tier. The flex tier runs at the edge of the datacenter or an enterprise network. The flex tier performs application delivery services and associated policies that are common and applied to all applications. The tenant tier runs logically close to the applications, with each tenant getting its own NetScaler instance. The tenant tier isolates the application delivery needs that vary widely by application. Basic Administration for Citrix NetScaler 9.2

Displacement The figure illustrates a displacement scenario. In the figure, a NetScaler system (inserted in-line) replaces another traffic manager. The NetScaler system often provides superior performance and more compelling functionality compared to that offered by other traffic managers. NetScaler systems are deployed in many scenarios to replace other products. As with a new deployment, it is critical with displacement to analyze and decide how to replicate the current functions of the network before deployment. Doing so ensures network features are properly migrated to the new setup. New functionality is typically explored only after the existing functions are replicated. Basic Administration for Citrix NetScaler 9.2

New Technology The figure illustrates a new technology deployment scenario in a high-availability scenario. Before starting a new technology deployment, you should first map out the network architecture to maximize the placement of the NetScaler system. Part of this mapping should include an analysis of what the current network functions are and what additional NetScaler functions will be added. Basic Administration for Citrix NetScaler 9.2

1.4. NetScaler Platform and Product Editions
The NetScaler product line includes three produc editions that combine different software functionality into integrated solutions. The different editions within the product line include: NetScaler Platinum Edition: This edition provides a Web application delivery solution that reduces datacenter costs and accelerates application performance, while providing end-to-end visibility of application performance and advanced application security NetScaler Enterprise Edition: This edition provides Web application and advanced L4-7 traffic management, enabling enterprises to increase Web application performance and availability and reduce datacenter costs. NetScaler Standard Edition: This edition provides small- and medium enterprise comprehensive L4-7 traffic management, enabling increased Web application availability. Basic Administration for Citrix NetScaler 9.2

1.5. Product Features The key feature sets of a NetScaler system include: Lower total cost of ownership Application acceleration Application security Application availability Simple manageability Feature accessibility depends on the hardware, licenses and software of the specific NetScaler system. Basic Administration for Citrix NetScaler 9.2

1.5.1. Lower Total Cost of Ownership
Citrix NetScaler Pay-as-You-Grow is a simple, on-demand licensing model that provides investment protection, avoids costly hardware upgrades and reduces total cost of ownership. Most networking systems require expensive hardware replacements to expand capacity and functionality, which forces companies to over-provision and pay for more than they need. Pay-as-You-Grow licensing enables companies to buy only what they need today, knowing they can easily scale up their network as demand grows with a simple software license upgrade. The flexible licensing applies to both high-performance NetScaler MPX hardware appliances and software-based NetScaler VPX virtual appliances. Pay-as-You-Grow licensing is particularly well suited to cloud-computing environments. It enables cloud providers to quickly and affordably expand their infrastructure as performance and capacity requirements dictate, without incurring the heavy fixed costs and service interruptions of hardware upgrades. The above table identifies the licenses supported by the NetScaler system for lower total cost of ownership. Basic Administration for Citrix NetScaler 9.2

1.5.2. Application Acceleration
The NetScaler system increases end-user performance by 5X or more, while saving on network bandwidth and making audio and video traffic usable over poor networks. This performance increase is achieved through: Advanced multilevel compression for 5X faster delivery of Web content Dynamic content caching to instantly deliver frequently requested content directly End-user experience monitor providing true, transparent, non-synthetic monitoring of application user performance Automated TCP optimizations that improve performance of all TCP-based applications The above table identifies the licenses supported by the NetScaler system for enhancing application acceleration. Basic Administration for Citrix NetScaler 9.2

Application Security The NetScaler system provides application security by utilizing an advanced Web application firewall to block application attacks and protect sensitive information from unauthorized access. Day-zero attack protection and integrated XML security prevents the loss of valuable corporate and customer data, and aids in compliance with regulations such as PCI-DSS. Comprehensive AAA capabilities, along with a powerful distributed denial of service (DDoS) shield, allow secure remote access and application security while preventing unauthorized access to sensitive information. The following table identifies the licenses supported by the NetScaler system for enhancing application security. X*: Optional feature Basic Administration for Citrix NetScaler 9.2

1.5.4. Application Availability
The NetScaler system is an all-in-one Web application delivery solution that makes applications 5X better by accelerating performance, ensuring application availability through advanced layer 4-7 traffic management, increasing security with an integrated application firewall and substantially lowering costs by offloading servers. The following table identifies the features supported by the NetScaler system for application availability. X*: Optional feature Basic Administration for Citrix NetScaler 9.2

Simple Manageability The NetScaler system provides key features for simple manageability AppExpert Visual Policy Builder: AppExpert Visual Policy Builder keeps policy development simple and policies supportable by eliminating complex scripts or programs from all NetScaler policies AppExpert Service Callouts: AppExpert Service Callouts obtain information from external applications. The call out policy sends an HTTP request to an external application. An agent deployed in front of the application formats the request for the application. When application returns a response, the agent formats the response for the NetScaler system, and the call out policy extracts data of interest from the response. AppExpert templates: AppExpert templates encapsulate the entire NetScaler configuration for a specific application into a logical view. Ongoing changes to configuration and policies can also be made from this view AppExpert templates can be imported and exported, enabling complete NetScaler configuration to be loaded for the optimization of specific applications. Import/export also makes it easy to share application-specific configuration within and between organizations and to move application- specific configurations between different systems AppExpert Visualizers: AppExpert Visualizers can display the following statistical information for content switching, load balancing, and application entities can be viewed in the Visualizer: Content switching and load balancing virtual servers - The number of requests received per second at a given point in time at content switching and load balancing virtual nodes is displayed on the virtual server node in the Visualizer. Rewrite, responder, and cache polices - The number of hits per second at given point for rewrite, responder, and cache policies is displayed on the rewrite, responder, and cache policy nodes in the Visualizer. Role based administration: Role based administration granularly segments administrative privilege on a NetScaler system. .. contd Basic Administration for Citrix NetScaler 9.2

.. contd AAA for Administration: The following Authentication, Authorozation, Auditing (AAA) features are enhanced in this release: (a) Forms-Based Single Sign-On (SSO): The NetScaler system now sipports forms-based single sign-on to all services. THis functionality allows administrators to configure policies for automatic submission of web forms by using user credentials used for logging into NetScaler or VPN. (b) Single Sign-On (SSO) Domain in Tomeout Session Paramater and Timeout Session Action: An SSO domain has been added in the timeout session parameter and the timeout session sction, to be used for form-based single sign-on. (c) SSO to services Support: The NetScaler system supports single sign-on (SSO) authentication for 401-based basic, digest, and NTLM authentication in AAA. Citrix Command Center: Citrix Command Center is a management and monitoring solution for Citrix application networking products that include Citrix NetScaler, Citrix Branch Repeater, and Citrix Repeater. The command center allows you to manage, monitor, and troubleshoot the entire global application delivery infrastructure from a single, unified console. Citrix EdgeSight for NetScaler: EdgeSight for NetScaler monitors web applications from the prespective of the client, providing real-time and historic visibility into Web application performance. EdgeSight for NetScaler: - Increase visibility into the user perception of Web application respond time - Tracks and reports Web application performance over time, comparing current performance to historical trends - Requires no agent or client software on user devices - Assists in troubleshooting bottlenecks - Uses HTML-injected data for measuring application performance Basic Administration for Citrix NetScaler 9.2

Web 2.0 Optimization NetScaler 9.2 introduces 64-bit shared-memory caching. High-end NetScaler MPX platforms can provide up to 24 GB of memory cache capacity, to cache large video files at the service provider edge, or to offload back-end servers. Delivery of Web 2.0 applications are optimized with new Fast XML XPath support which enables high-performance business logic routing using deep XML payload inspection. The following table identifies the licenses supported by the NetScaler system for Web 2.0 optimization. Basic Administration for Citrix NetScaler 9.2

1.6. Hardware Platforms The different hardware platforms currently within the Citrix NetScaler product line include: NetScaler MPX 21500 NetScaler MPX 19500 NetScaler MPX 17500 NetScaler MPX 17000 NetScaler MPX 15500 NetScaler MPX 15000 NetScaler MPX 12500 NetScaler MPX 10500 NetScaler MPX 9500 NetScaler MPX 9010 FIPS NetScaler MPX 7500 NetScaler MPX 5500 NetScaler VPX 10/200/1000 Each NetScaler platform has different measured capacities for system throughput, SSL throughput and compression throughput. The measured peak throughput for each model is based on an optimized configuration. Basic Administration for Citrix NetScaler 9.2

NetScaler MPX 21500/19500/17500/17000 The NetScaler MPX 21500/19500/17500/17000 platforms support the Platinum, Enterprise and Standard Editions. Basic Administration for Citrix NetScaler 9.2

NetScaler MPX 15500/15000/12500/10500 The NetScaler MPX 15500/15000/12500/10500 platforms support the Platinum and Enterprise Editions. Basic Administration for Citrix NetScaler 9.2

NetScaler MPX 9500/ 9010 FIPS/MPX 7500/5500/VPX 10/200/1000
The NetScaler MPX 9500/9010 FIPS/MPX 7500/5500/VPX 10/200/1000 platforms support the Platinum, Enterprise and Standard Editions. Basic Administration for Citrix NetScaler 9.2

nCore Citrix NetScaler nCore technology dramatically increases the performance and scalability of NetScaler at no additional cost. nCore technology breaks the single CPU performance barrier that limits the performance, scalability, and extensibility of most Web solutions. It is a true 64-bit architecture that is built from the ground up to intelligently distribute packet flows across multiple CPU cores for high-performance parallel processing. As Web applications become increasingly complex and demanding due to Web 2.0 trends and the proliferation of Rich Internet Applications (RIA), Web application delivery will be required to provide greater levels of Web application delivery controller solutions which provide: Layer 4-7 load balancing and content switching functions Caching Compression Application security SSL offloading Multigigabit speeds NetScaler nCore application accelerator technology delivers a 7X increase in performance and scalability and provides new levels of advanced Web application delivery controller performance for even the most challenging Web applications. Basic Administration for Citrix NetScaler 9.2

NetScaler VPX NetScaler VPX is a virtual application that provides the functionality of specialized, high-end network devices that can be easily and dynamically deployed on a single server or across entire cloud datacenters. The simplicity and flexibility of NetScaler VPX make it easy and cost effective to fully optimize every Web application and more effectively integrate networking services with application delivery. In addition to supporting datacenters relying upon virtualized server and application resources, NetScaler VPX enables Web application load balancing, acceleration, security, and offload to become virtualized services that can be easily deployed on-demand anywhere in the datacenter or cloud infrastructure. This enables combining NetScaler VPX with other virtualized networking solutions to deliver an end-to-end layer 2-7 virtual networking stack. Basic Administration for Citrix NetScaler 9.2

1.7. Hardware Components Each NetScaler appliance includes certain hardware components. Some of these components are easily accessible on the exterior of the appliance and should not be removed. You must be aware of what and where these components are when administering a NetScaler system. The file systems are vital for the NetScaler system operations. Network and Serial Interfaces On all NetScaler platforms, the network interfaces are located on the front of the appliance. The RS232 serial console port on the front of each NetScaler appliance provides a direct connection between the appliance and a workstation or laptop, allowing direct access to the appliance for initial configuration or troubleshooting. LCD Some basic information can be found directly on the front-mounted LCD screen. The LCD screen cycles through the screen options and displays the current system values. File System: Important data systems include: RAM Drive The RAM drive is mounted on the root or / file system. During operation, binaries are executed from the RAM drive. The running configuration files for BSD level tools will be used from the /etc file system residing on the RAM drive. Flash memory - The flash memory is mounted in the NetScaler system as /flash. During start up, the RAM drive is initially populated from a compressed build file residing on the flash drive, and then the configuration files needed for BSD-level processes are copied from the nsconfig directory on the flash drive into the /etc directory in the RAM drive. The /nsconfig directory is then linked to the /flash/nsconfig directory as a shortcut. When a save config command is executed, the running (in-memory) configuration is saved to this directory. - The flash drive is located on the back of the appliance and should not be removed. Hard Disk The NetScaler system hard disk is used to store log data and core files and is used as long-term storage for unused builds. The /var directory represents the physical hard disk. The hard disk is located on the back of the appliance and should not be removed Basic Administration for Citrix NetScaler 9.2

1.8. NetScaler Architecture Overview
The NetScaler design is based on a layered module between the NetScaler kernel and the BSD operating system as shown in the figure. BSD and the NetScaler system share memory management. The NetScaler kernel operates below the BSD kernel and controls many of the features, including: Time slicing for BSD Network packet processing SNMP and syslog processing SSL offload BSD manages several integral features of the NetScaler system, including: Boot process File system access Long-term logging Management processes Basic Administration for Citrix NetScaler 9.2

1.9. Initial NetScaler Access
The NetScaler administrator account is nsroot, and the default password is nsroot. The nsroot account is part of the default configuration. A best practice is to change the default password during installation. The NetScaler system is accessed using the GUI-based Configuration Utility or the command-line interface. In the Configuration Utility logon window, the start menu and timeout session can be configured. You can log on to the NetScaler system using the Configuration Utility when the system and software requirements for the workstation have been met. Basic Administration for Citrix NetScaler 9.2

2. Networking Overview Objectives At the end of this module, you will be able to: Deploy a NetScaler system as a network gateway device. Describe NetScaler networking. Explain routing support on the NetScaler system. Describe virtual local area networks (VLANs). Configure reverse network address translation. Use the Link Aggregation Control Protocol (LACP) Basic Administration for Citrix NetScaler 9.2

2.1. NetScaler Architecture Overview
The NetScaler system is fundamentally a TCP (layer 4) proxy that separates the client connections from the server connections and manages separate connection tables for client and server connections. The NetScaler system can provide great traffic optimization as a gateway device by multiplexing client connections to Web servers. As a TCP proxy device, the NetScaler system responds to client connections that are targeted at servers residing behind it, hiding the network topography. The NetScaler system can enforce traffic security by being the single gateway that clients use to access the network. The NetScaler system is not a UDP proxy. However, it still proxies the IP address, sourcing from a mapped IP address or subnet IP address as normal. This behavior can be turned on and off at a granular level Basic Administration for Citrix NetScaler 9.2

2.1.1. Connection Separation
The figure illustrates the NetScaler system configured to act as a virtual server. The client connects to the virtual IP address on the NetScaler system. The NetScaler system then uses either its Mapped IP (MIP) address or a subnet IP (SNIP) address on the back-end subnet to connect to the server. Even though the client connection terminates at the NetScaler system, the client request is forwarded by the NetScaler system to the servers. In this scenario, the NetScaler system is transparent to the client. No client-side configuration is required, making the NetScaler system a transparent proxy. Basic Administration for Citrix NetScaler 9.2

2.1.2. Basic NetScaler System Networking Rules
The NetScaler system sends and responds to address resolution protocol (ARP) requests for all IP addresses on all interfaces. With the binding of a VLAN to an interface, all IP addresses continue to be answered on the interface if a proper ARP request is generated outside the NetScaler system. ARP can be restricted on a given VLAN by binding a SNIP address to a VLAN with an IP address. The interfaces on a NetScaler appliance are not marked and do not have assigned IP addresses. This open architecture allows any connection to the NetScaler system to be created from any port. A best practice is to control and limit this behavior with the use of VLANs. The figure shows a network endpoint device and a NetScaler system. Typical network hosts have a one-to-one mapping of the MAC address to an IP address. On the NetScaler system, IP addresses are not bound to a particular network interface. Any physical interface can send and receive data for any NetScaler system-owned IP address. This behavior becomes significant when the NetScaler system operates in an environment using VLANs. Basic Administration for Citrix NetScaler 9.2

Basic NetScaler System Networking Rules Basic Administration for Citrix NetScaler 9.2

Multiplexing The NetScaler system attempts to reuse TCP connections it creates to back-end servers to optimize HTTP traffic. It does this by proxying the IP (layer 3) address of the client that the server sees. This behavior is determined by the service type. The HTTP service type enables TCP offload, multiplexing, and connection reuse on top of this layer-4 proxying. HTTP processing includes further capabilities including: Compression Integrated caching Layer 7 content switching Layer 7 GET-flood protection By default, the NetScaler system translates the client IP address to either a MIP address or a SNIP address to maintain a single connection to the server and multiplexes all client connections to it. This means that the back-end servers do not see individual clients, since all the traffic appears to come from the NetScaler system. Note: In certain circumstances, the IP address cannot be proxied for HTTP services. When the IP address is not proxied for HTTP, connection reuse benefits are lost across different IP addresses. Basic Administration for Citrix NetScaler 9.2

2.2. NetScaler-Owned IP Addresses
The NetScaler system uses different types of IP addresses for management and proxying connections to the server. These IP addresses are: NetScaler IP addresses (NSIP) Subnet IP addresses (SNIP) Mapped IP addresses (MIP) Virtual IP addresses (VIP) Basic Administration for Citrix NetScaler 9.2

NetScaler IP Address The NetScaler IP address (NSIP) is the primary address for management and general system access. The NetScaler IP address is a unique IP address. When NetScaler systems participate in a high-availability configuration, the NSIP address is used for primary communication between members of the high-availability configuration and the NSIP is the only active IP address on the secondary member in a high-availability pair. The NSIP can be accessed from any enabled interface on the NetScaler system. An NSIP address must be configured on a new NetScaler system. The default IP address and netmask is /16 ( ). Configuring an initial NSIP address or changing the NSIP address or subnet mask requires a restart of the NetScaler system. When configuring changes using the command-line interface, save the configuration first, change the NSIP address, and then restart the NetScaler system. Basic Administration for Citrix NetScaler 9.2

2.2.2. Configure a NetScaler IP Address
Configure NSIP addresses through the setup wizard or through the command-line interface. Configuration Utility locationThe NSIP can only be changed by running the Setup Wizard: System > Setup Wizard. Command-line syntax config ns This will start the text-driven utility that will allow you to configure and save the NSIP address/subnet. Authentication traffic, such as LDAP and RADIUS, also uses the NSIP address. Basic Administration for Citrix NetScaler 9.2

Subnet IP Address The subnet IP (SNIP) address is used in connection management and server monitoring. A SNIP address provides the NetScaler system with an ARP presence in subnets to which the system may not be directly connected. A NetScaler system should have a SNIP address configured for every directly connected subnet. When a SNIP is added to a NetScaler system, a static route entry is automatically added to the NetScaler system routing table; this route identifies the SNIP address as the default gateway on the NetScaler system for the corresponding subnet. The Use Subnet IP (USNIP) mode can affect how the SNIP address is used by the NetScaler system to communicate with servers. USNIP mode is enabled by default. When USNIP mode is enabled, the SNIP address functions as a proxy IP and is used by the NetScaler system for NetScaler-system-to-server communication. In this mode, the server will see the SNIP address as the source IP in packets received from the NetScaler system. If USNIP mode is disabled, the SNIP address is not used to send traffic from the NetScaler system to the servers. Instead a mapped IP address must be available. In most environments, USNIP mode is left enabled. Individual SNIP addresses can be enabled to allow management access. When management access is enabled, connections to the NetScaler command-line interface over SSH and connections to the Web-based Configuration Utility can be made using the SNIP address (as if it were a NSIP address). Using management enabled SNIP addresses allow you to connect to the NetScaler system from a subnet other than the one where the NSIP is located. It also simplifies managing NetScaler systems in a high-availability configuration, since only the primary unit will respond to the SNIP. Management access is not enabled by default. Unlike the NSIP address (but like every other type of IP address), SNIP addresses are only active on the primary unit of a high-availability pair and show as passive on the secondary unit. If multiple SNIP addresses are present on a subnet, the NetScaler will alternate between the SNIP addresses in round-robin manner when communicating with servers. Configure SNIP addresses by defining an IP address and a subnet mask: Configuration Utility location Under the Network > IPs node Command-line syntax add ns ip <IP address> <Subnet Mask> -type SNIP -mgmtAccess [Enabled | Disabled] Basic Administration for Citrix NetScaler 9.2

Mapped IP Address A mapped IP (MIP) address is used for external connections from the NetScaler system. MIP addresses are used for connectivity in the absence of a SNIP address. For example, the MIP address is the proxy IP address of last resort. MIP addresses, like SNIP addresses, are used as the proxy address for NetScaler system-to-server communication. MIP addresses are still used even when the USNIP mode is globally disabled. A best practice is to have at least one MIP address configured in the same subnet as the NSIP address. However, MIP addresses are not required. The MIP address should be available across all subnets and should never be bound to a VLAN. It is only active on the primary unit of a high-availability pair, like every other IP address on the system other than the NSIP address, and shows as passive on the secondary unit. When both a MIP address and a SNIP address are configured on the same subnet, the NetScaler system will use the SNIP address to communicate with servers by default (since USNIP mode is enabled). If USNIP mode is disabled, the MIP address will be used. If multiple MIP addresses are present on a subnet, the NetScaler will use the MIP addresses in a round-robin fashion. Configure MIP addresses by defining an IP address and a subnet mask: Configuration Utility location Under the Network > IPs node Command-line syntax add ns ip <IP address> <Subnet Mask> -mgmtAccess [Enabled | Disabled] Basic Administration for Citrix NetScaler 9.2

Virtual IP Address Virtual IP (VIP) addresses are used for client-to-NetScaler-system communication. Virtual IP addresses are assigned to virtual servers on the NetScaler system. VIP addresses are generally presented to the clients as a logical abstraction of a physical server behind the NetScaler system. When the VIP address is a public IP address, it usually corresponds to the DNS entry for a domain. A VIP address is automatically created when a virtual server is added. A virtual server is identified as a unique IP/port combination. A virtual server could be configured using an IP address (VIP1) on port 80 (HTTP), and a second virtual server could be configure using the same IP address (VIP1) on port 3389 (RDP). A single VIP address can support a maximum number of 64,000 available TCP ports, corresponding to a maximum of 64,000 separate virtual servers (distinct ports) on a single VIP address. Changing the status of a VIP address, such as disabling it, will affect all virtual servers that use the VIP address. Basic Administration for Citrix NetScaler 9.2

2.3. NetScaler Modes Modes on the NetScaler system are global settings that control NetScaler behavior. Most of the modes modify networking behavior. Unlike features, modes are generally not configurable; modes are either enabled or disabled. Most modes control a global setting across the NetScaler system. A few settings such as USIP mode, Client Keep-Alive, and TCP Buffering can be managed globally or on a per-service basis. Two modes specifically address the packet forwarding behavior of the NetScaler: layer-2 mode and layer-3 mode. This section will specifically discuss: Layer-2 mode Layer-3 mode MAC-based forwarding mode Use Source IP (USIP) mode Basic Administration for Citrix NetScaler 9.2

Layer-3 Mode The base behavior of the NetScaler system is to process the packet of any traffic sent to NetScaler-owned IP addresses. This means that any packet sent to an NSIP address, MIP address, SNIP address, configured service, or virtual server will be processed by the NetScaler system. The layer-2 and layer-3 modes determine how the NetScaler system handles packets that are sent to an IP address that it does NOT own. These modes determine whether the NetScaler system should act as a switch and bridge the packets (layer-2 mode) and whether the NetScaler system should act as a router and forward the packets (layer-3 mode). In the default configuration, layer-3 mode is enabled and layer-2 mode is disabled. These two modes are not exclusive. Configuring Layer-3 Mode With layer-3 mode enabled, the NetScaler system will perform packet forwarding (routing) of any packet that is not sent to an IP address it owns. If layer-3 mode is disabled, the NetScaler will drop the packet. Typically, layer-3 mode is left enabled. However, layer-3 mode can be disabled if the NetScaler system should not be performing routing functions. Configure the NetScaler mode in: Configuration Utility dialog Under the System > Settings node: Configure modes Command-line syntax enable ns mode L3 disable ns mode L3 If both layer-2 and layer-3 modes are enabled, layer-2 mode decisions (based on MAC addresses) will be processed first. Basic Administration for Citrix NetScaler 9.2

Layer-2 Mode By default, the NetScaler system functions as a layer-3 network device. However, it can be configured to function as a layer-2 device. With layer-2 mode enabled, the NetScaler system functions as a bridge. Decisions are based on the MAC address of the packet (layer 2). If the packet contains a destination MAC address that belongs to the NetScaler system, the NetScaler system will then look at the IP address destination to determine how to handle the traffic. The layer-2 mode setting determines how the NetScaler system handles packets whose destination MAC address does not correspond to a NetScaler-owned MAC address. If layer-2 mode is disabled (default configuration), the NetScaler system drops any packet that is not destined for a NetScaler-owned MAC address. If layer-2 mode is enabled, then the NetScaler system determines whether to process the packet or bridge the packet. The NetScaler system will process the packet if the destination IP address corresponds to a NSIP/MIP/SNIP address, configured service, or virtual server. Otherwise, the NetScaler system will bridge the packet, acting like a switch. With layer-2 mode enabled, traffic that is not destined for the NetScaler system will be bridged to the networks that the NetScaler system is connected to. Exceptions to this behavior are: Broadcasts that are received on a NetScaler interface assigned to a VLAN are NOT forwarded to interfaces that are not assigned to a VLAN. ICMP and UDP traffic will be dropped if it exceeds the packet rate filters on the NetScaler. The NetScaler system will not bridge the excess traffic requests. Basic Administration for Citrix NetScaler 9.2

3.2.2.1. Layer-2 Mode Considerations
Layer-2 mode is typically not needed in most environments and should be left disabled unless there is a specific networking need in the environment. The NetScaler system does not support Spanning Tree Protocol (STP) and drops STP packets. Spanning Tree Protocol is used on bridged networks to detect bridging loops, meaning: Two interfaces on the NetScaler system cannot connect to the same broadcast domain. If a NetScaler system is installed in parallel to a layer-2 device, layer-2 mode must be disabled on the NetScaler system to prevent creating a bridging loop. A scenario where layer-2 mode might be needed is when servers are connected directly to the NetScaler system or if the NetScaler system is being used as a transparent bridge. However, both scenarios are not typical and should not be used without considering the impacts. One last consideration is due to the way that layer-2 mode functions, it can present some conflicts with security requirements in the environment. Access control lists (ACLs) are usually configured to help prevent traffic from reaching specific destinations. However, ACLs are based on the IP address information in the packet (layer 3) and not the MAC address information in the packet (layer 2). As a result, if layer-2 mode is enabled, layer-2 bridging decisions are made before IP-based ACLs are processed. Having layer-2 mode enabled can result in the bypassing of any ACLs in place and therefore the bypassing of security. Configuring Layer 2 Mode Configure the NetScaler mode in: Configuration Utility dialog location Under the System > Settings node: Configure modes Command-line syntax enable ns mode L2 disable ns mode L2 Basic Administration for Citrix NetScaler 9.2

3.2.2.2. Layer-2 Mode with Layer-3 Mode
Layer-2 and layer-3 modes can be enabled or disabled independently of each other. The NetScaler system makes packet processing decisions by looking at the MAC address first and then the IP address. Keep in mind that the layer-2 and layer-3 mode behaviors only apply to traffic that is not being sent to a NetScaler MAC address or a NetScaler-owned IP address. A best practice is to leave layer-3 mode enabled and layer-2 mode disabled, unless there are specific networking conditions that require it. Packets destined for a NetScaler-owned IP address are always PROCESSED, regardless of the MAC address. Packets destined for a non NetScaler-owned MAC address are: DROPPED if layer-2 mode is disabled BRIDGED if layer-2 mode is enabled Packets destined for a non NetScaler-owned IP address are: DROPPED if layer-3 mode is disabled FORWARDED (Routed) if layer-3 mode is enabled Basic Administration for Citrix NetScaler 9.2

2.3.3. MAC-Based Forwarding Mode
Basic Administration for Citrix NetScaler 9.2

Sending a Client IP Address to Servers
The NetScaler system usually functions in a transparent proxy configuration. Clients initiate connections to the NetScaler system using a VIP address. The NetScaler system terminates the connection from the client, processes the packet, and then initiates a connection to the appropriate server on behalf of the client. The default behavior of the NetScaler system is to change the source and destination IP address of a packet received from a client before sending it to the server. The originating packet from the client contains the source IP address as the client IP address and the destination IP address as the virtual server IP address (the VIP on the NetScaler system). The NetScaler system then changes the packet before sending it on to the server so that the source IP address becomes the NetScaler MIP/SNIP address and a destination IP address becomes the physical IP address of the server. As a result of proxying the connection, the server is unable to see the IP address of the client that originated the connection; the server can see only the NetScaler MIP or SNIP address. Since some applications require the client IP address for proper logging or functionality, the NetScaler system has two ways of providing this information to the server: Client-IP HTTP header insertion Use Source IP mode Basic Administration for Citrix NetScaler 9.2

Client-IP HTTP Header Insertion
When a back-end server needs to identify or track the client that originated a request, it generally looks at the source IP address field of the packet header. However, when the connection is being proxied by the NetScaler system, the packet details do not yield the desired information. Use Source IP mode can be enabled so that the IP address of the client that originated the request is left intact in the packet; however, there are several drawbacks to this solution, which will be covered in the User Source IP section. Applications that need this information can usually be configured to retrieve the information from an HTTP header instead of from the packet. The applications just need to know the name of the header from which to retrieve the value. The NetScaler system can perform this client IP header insertion for the HTTP traffic it is proxying. Applications can still retrieve the originating client IP address, and the NetScaler system maintains all of the connection multiplexing and proxying benefits while leaving USIP mode disabled. Note: Client-IP header insertion is the preferred method to use to pass the client IP address to back-end servers and applications. Basic Administration for Citrix NetScaler 9.2

Enabling Client-IP HTTP Header Insertion
Client-IP header insertion can be enabled in multiple ways on the NetScaler system. Some methods apply globally or across a feature set. Others apply to specific services or traffic criteria based on policies. As a result, there are several ways to set the specific header name that an application is configured to look form, including: Configuring globally, updating the HTTP Parameters (System > Settings), and enabling/disabling client IP header insertion. Configuring on a per-service basis, updating the service properties, and enabling/disabling client IP header insertion. The service-level setting overrides the global setting. Specifying the logging header name within the Application Firewall engine settings. This header insertion supplies the client IP address in the designated header. The Application Firewall setting applies globally to the Application Firewall feature and affects any traffic processed by an Application Firewall policy. Configuring a rewrite policy to selectively affect specific traffic criteria. In most of these options, the HTTP header insertion behavior is already defined and you just need to specify the header name. If working with the rewrite feature, you can use the custom header insertion feature to perform the same behavior; this feature will be discussed in more detail in Module 10. Basic Administration for Citrix NetScaler 9.2

Use Source IP Mode Use Source IP (USIP) mode is a networking mode in which the NetScaler system uses the actual client IP address to connect to the server and does not replace the source IP address in packets sent to the server with a MIP or SNIP address. The server will see the originating client IP address within the source IP field of the packet. While USIP mode will allow back-end resources to see and log the client IP addresses, there are several side effects and considerations when USIP mode is enabled. By default, when proxying the connection, the NetScaler system manages the connections to the server. For HTTP protocols, connection reuse and multiplexing result in improved efficiencies and performance. USIP mode severely limits multiplexing opportunities as each client will require its own connection to the server. Connection reuse, WAN latency optimizations, and denial-of-service (SYN) attack prevention are also limited. Basic Administration for Citrix NetScaler 9.2

Source IP Mode Considerations and Limitations
Considerations and limitations when activating the Source IP mode feature include: USIP mode should not be enabled for NetScaler systems deployed in a one-arm configuration. Concurrent HTTP connection limits may be more of a factor since connections are not reused with USIP mode enabled. If HTTP connections will exceed 64,000 concurrent connections, USIP mode should be disabled. Multiplexing is only used for connections between the NetScaler and the server originating from the same source IP address, causing significantly more sessions to be established between the NetScaler system and the server. This behavior is inefficient for the NetScaler system and creates more overhead for the server. Surge protection is unable to function in a USIP mode environment, as the NetScaler system will be in a constant surge mode. The surge protection feature should be disabled if USIP is enabled. USIP mode requires routing in the environment to direct all of the server response traffic bound for the client IP address through the NetScaler system. Note: USIP mode does not eliminate connection reuse completely. The benefits of connection reuse are simply diminished. Connections from the same source IP address are reused. They are just a small fraction of the traffic the NetScaler system could be reusing. If an application requires the original source IP address, then USIP mode can be enabled on a service-by-service basis. Basic Administration for Citrix NetScaler 9.2

Configuring USIP Mode USIP mode can be enabled or disabled globally (as a NetScaler mode) or it can be enabled or disabled on a per-service basis. At the service level, the USIP setting is a global-override. Enabling or disabling the setting on an individual service overrides the global setting. Whenever the global mode is changed, existing services are not modified; they retain their existing global-override setting. New services that are created will inherit the USIP setting from the global setting unless the value is explicitly overridden when configuring the service. As a result, you may enable USIP mode broadly across all services or enable it specifically only for those services that require it. As a best practice, if an application requires a client IP address for logging or functional purposes, rely on client IP header insertion. If client IP header insertion is not suitable, enable USIP mode only on the specific service or services that require it. Keep the use of USIP mode as limited as possible. Because of the limitations and considerations, do not enable USIP mode unless it is absolutely necessary. Basic Administration for Citrix NetScaler 9.2

2.4. Network Address Translation
Network address translation (NAT) involves modifying: The source IP address The destination IP address The TCP or UDP port numbers Enabling NAT enhances the security of a private network and protects it from a public network, such as the Internet, by modifying the source IP address when data passes through the NetScaler system. With NAT entries, an entire private network can be represented using a small number of shared public IP addresses. Therefore, by using NAT on the NetScaler system, you are better equipped to handle security and administration issues, as well as a shortage of IPv4 addresses. Basic Administration for Citrix NetScaler 9.2

2.4.1. NetScaler Supported Network Address Translation Capabilities
The NetScaler system supports the following network address translation capabilities: Inbound NAT (INAT) The NetScaler system replaces the destination IP address in the packets generated by the client with the private IP address of the server. Reverse NAT (RNAT) The NetScaler system replaces the source IP address in the packets generated by the servers with the public NAT IP address.The NetScaler system is also an IP address proxy for reverse network address translation (RNAT) and for virtual servers. Network Address Translation cannot be implemented without a virtual server. Basic Administration for Citrix NetScaler 9.2

2.4.2. Inbound Network Address Translation
When a client sends a packet to a NetScaler system that is configured for inbound network address translation (INAT), the NetScaler system translates the public destination IP address of the packets to a private destination IP address and then forwards the packets to the server at that address. When the server returns the packets, the NetScaler system translates the source IP address of the packets to the public source IP address and then sends the packets back to the client. Basic Administration for Citrix NetScaler 9.2

2.4.3. Reverse Network Address Translation (RNAT)

IP Addresses for RNAT You can configure a non-wildcard virtual IP address as an RNAT IP address. RNAT can be configured to use a VIP address for address translation. RNAT is configured using the following command: set ns rnat network -NATIP <IP_Address> The address provided as the value for the argument can be a MIP address, SNIP address or virtual IP address. A wildcard virtual IP address is not a valid selection for the -NATIP argument. A SNIP or MIP address can be supplied as the NAT IP address when -NATIP is configured. The NetScaler system round-robins between the SNIP addresses. If there are no SNIP addresses, then the NetScaler system round-robins between MIP addresses. In an RNAT configuration, the NetScaler system replaces the source IP addresses of the packets generated by the servers with a NAT IP address, which is a public IP address. The default NAT IP address is a MIP address. The NetScaler system can be configured to use other NetScaler-owned IP addresses. Basic Administration for Citrix NetScaler 9.2

2.4.5. Configuring Reverse Network Address Translation
Configure RNAT and the ACL and NAT IP address information as necessary. Configuration Utility location Under the Network > Routing node, in the RNAT tab of the Routing pane Command-line syntax set rnat network netmask The NetScaler system hides the IP address of all packets originating in that network. View RNAT statistics pertaining to RNAT and the NAT IP address by defining a particular NAT IP address. Statistics include: Bytes received Bytes sent Packets received Not specifying a particular NAT IP address will return global RNAT statistics. Basic Administration for Citrix NetScaler 9.2

2.5. Virtual Local Area Networks
Unlike a typical network host, the NetScaler system does not have a one-to-one mapping of MAC addresses to IP addresses. As a result, any of the NetScaler interfaces can send and receive data for any type of NetScaler-owned IP addresses. This behavior can be modified through the use of VLANs. All interfaces on a NetScaler system are automatically members of the default VLAN (VLAN 1), also referred to as the native VLAN. Like a switch, the NetScaler system does not natively bind IP addresses to interfaces. In a situation where a NetScaler system is connected to multiple subnets, you may want to enforce separation of the subnets so that only the interfaces connected to the subnet will respond to IP addresses on that subnet. This subnet separation can be accomplished by configuring one or more VLANs on the NetScaler system. An interface and an IP address can be associated with the VLAN once one is created. The desired separation in subnets is created when a MAC address (interface) and an IP address are associated with the VLAN. Each VLAN is identified by a VLAN ID, which is an integer from 1 to The VLAN created is empty (without members). However, the VLAN is not active until interfaces are bound to it with an IP address. VLAN 1 is created by default and cannot be deleted. By default, all interfaces belong to VLAN 1. When an interface is added to a new VLAN, it is automatically removed from VLAN 1. When a VLAN to which an interface is bound is deleted, the interface is returned to VLAN 1. VLANs can be created on the NetScaler system to correspond with the VLANs in use within the network. The NetScaler supports layer-2 port and IEEE 802.1q tagged VLANs. When a VLAN is bound to an IP subnet, the NetScaler will perform IP forwarding between the VLANs when configured as the default router for the hosts on the subnets. The VLAN feature of the NetScaler system is an implementation option in the following environments: Single subnet Multiple subnets Single LAN VLANs with no tagging VLANs with 802.1Q tagging Basic Administration for Citrix NetScaler 9.2

Tagged VLANs Basic Administration for Citrix NetScaler 9.2

VLANs and Tagging with NetScaler VPX

Configuring VLANs Basic Administration for Citrix NetScaler 9.2

2.6. Link Aggregation Basic Administration for Citrix NetScaler 9.2

Adding Channels Manually
The add channel command creates the virtual interface. Physical interfaces are added to the channel as part of the add command or through the use of the bind channel command after the interface is created. A single link aggregation channel can contain from two to four physical interfaces. If these interfaces are of differing speeds, they function at the lowest common speed when aggregated. When two or more interfaces are aggregated, they create a channel. The channel can be configured or bound to VLANs just like an individual interface. Link aggregation on the NetScaler system can be configured in two ways: manually (without LACP) or automatically (with LACP). Channels that are configured manually must be managed manually (at the channel level). Channels that are configured automatically using LACP must be managed at the interface level through the LACP properties. When a new channel is created (either manually or through LACP), any VLAN settings configured on the member interfaces are lost, and the channel joins VLAN 1 by default. Once a new channel has been created, you must reconfigure any VLAN settings on the channel instead of on the member interfaces. The same happens when a channel is removed; member interfaces return to VLAN 1 and any required tagged VLAN settings must be reconfigured. Basic Administration for Citrix NetScaler 9.2

Configuring LACP Manually

LACP ..contd .. Basic Administration for Citrix NetScaler 9.2

Internet Control Message Protocol Internet Control Message Protocol (ICMP) messages are handled in a unique manner on the NetScaler system. As a result of the specialized role that the NetScaler system plays in the network, it does not respond in traditional ways to most ICMP messages. The NetScaler system often ignores or drops ICMP error message traffic and forwards ICMP packets addressed to its MAC address. In addition, the NetScaler system ignores ICMP packets beyond the 200 packets for every second threshold. Dynamic Routing Support and Route Health Injection The NetScaler system supports both dynamic and static routing. Because simple routing is not the primary role of a NetScaler system, the main objective of running dynamic routing protocols is to enable route health injection (RHI) so that an upstream router can choose the best route among multiple routes to a topographically distributed virtual server. The NetScaler system supports the following dynamic routing protocols: Routing Information Protocol (RIP) Border Gateway Protocol (BGP) Open Shortest Path First (OSPF) Route Health Injection (RHI): Supports dynamic routing with RIP, BGP and OSPF Advertises only active entities Advertises virtual IP addresses based on virtual server status Basic Administration for Citrix NetScaler 9.2

3. Configuring High Availability
Overview When two NetScaler systems are deployed in an environment as a cluster, they are referred to as a high-availability pair. Using a high-availability pair deployment ensures that NetScaler-provided services are always available even if one system fails. Objectives At the end of this module, you will be able to: Create a high-availability pair. Disable interfaces. Enable high-availability monitoring. Assign node IDs. Verify high-availability status. Perform synchronization. Perform a forced failover. Upgrade a high-availability pair. Basic Administration for Citrix NetScaler 9.2

3.1. Introduction to High Availability
In a high-availability pair configuration, only one system is active. This system, which is known as the primary, actively accepts connections and manages servers. All shared IP addresses are active on the primary system only. The secondary system monitors the health of the primary system. If the secondary system is in a healthy state, it is ready to actively accept connections if the primary system is experiencing issues. This process prevents downtime and ensures that the services provided by the NetScaler system remains available even if one system ceases to function. The terms primary and secondary refer to the current state of a node, which can change as network conditions change. A way to specify a preference for primary status on either node, also known as preemption, does not exist. Basic Administration for Citrix NetScaler 9.2

3.1.1. High Availability Functionality

3.2. High Availability Node Configuration

3.2.1. Pre-Configuration Checklist

3.2.2. Virtual Media Access Control Address
The primary and secondary nodes in a high-availability setup share the same virtual media access control (VMAC) address. The primary node owns floating IP addresses, such as the MIP, SNIP and VIP addresses, and responds to address resolution protocol (ARP) requests with its own MAC address. Therefore, the ARP table of an external device, such as an upstream router, is updated with the floating IP address and the MAC address of the primary node. The VMAC must be configured on both nodes of a high-availability pair with both nodes having identical MAC addresses. When a failover occurs, the MAC address of the secondary node remains unchanged, and the ARP tables on the external devices do not need to be updated. When a failover occurs and the secondary node takes over as the new primary node, it uses the gratuitous address resolution protocol (GARP) to advertise the floating IP addresses that it learns from the primary node. The MAC address that the new primary node advertises is the MAC address of its own network interface. Because some devices do not accept GARP messages, the external devices retain the IP address-to-MAC address mapping that the old primary node formerly advertised, which may result in a GSLB site becoming unavailable for those networks. Basic Administration for Citrix NetScaler 9.2

3.2.3. Configuring Primary and Secondary Nodes
You can use the following procedure to configure the primary and secondary nodes using the Configuration Utility or the command-line interface: 1. Disable the interfaces that are not connected or being used for traffic. 2. Disable monitoring for the interfaces whose failure should not cause a high-availability mode failover. 3. Assign a node ID to each NetScaler system. 4. Save the configuration.Before two nodes are able to function in a high-availability pair, they must first be made aware of each other. You join a new NetScaler system with an existing system to form a high-availability pair because it is a best practice to enable stay secondary status on the new system. If stay secondary status is not enabled during high-availability configuration, the new system may be elected to become the primary node, and the configuration settings on the existing system are replaced with the settings (typically a blank configuration) on the new system. When stay secondary status is enabled on the new system, the existing system becomes the primary node if it passes its health checks and its configuration settings are synchronized with the new system. Basic Administration for Citrix NetScaler 9.2

3.2.4. High-Availability Status
After two NetScaler systems in a high-availability pair have been configured, it is important to verify the status of each node to ensure that the system is prepared in case of failover. For each node, the node state should be UP and the master state should be either primary or secondary, as appropriate. You should check that the sync state shows success on the secondary node because it verifies the successful completion of the configuration synchronization process. Verifying Status on the Appliance In addition to checking the master status of a node remotely using either the Configuration Utility or the command-line interface, you can refer to the NetScaler appliance, which displays the status on the Configuration Display on the LCD, as shown in the figure. Basic Administration for Citrix NetScaler 9.2

3.3. Propagation and Synchronization
Command propagation, enabled by default, causes any command issued on the primary node to execute on the secondary node. Consequently, you can test if high availability is working by making configuration changes to the primary node and then testing to see if the changes have propagated to the secondary node. Configuration synchronization occurs when a node comes up for the first time in a secondary state. The secondary node pulls the configuration from the primary node and overwrites its existing configuration. In addition to automatic configuration synchronization, forced synchronization between two nodes is also supported. Forced synchronization is used whenever you want to ensure that changes made to a NetScaler configuration are transferred from the primary to the secondary system. For example, if a network interruption occurs and the systems are unable to communicate, a forced synchronization ensures that any changes made during the interruption are present on both systems. If the nodes in a high-availability pair are running different versions of the NetScaler operating system, the node running the newest software version goes into listen mode as of release 8.0 and later. When a node is in listen mode, neither command propagation nor configuration synchronization occurs. Changes made using the config ns command in the command-line interface are not propagated. Any configurations made using this command must be performed on each node separately. High-availability configuration synchronization occurs on TCP port 3010. Command propagation between the primary and secondary occurs on TCP port 3011. The heartbeat messages are UDP packets sent to port 3003 of the other node in a high-availability pair. Secure high-availability configuration synchronization occurs on TCP port 3008. Basic Administration for Citrix NetScaler 9.2

3.3.1. Disabling Command Propagation
In some cases, command propagation may not be desired. For example, if you make changes to the system configuration that causes problems, the changes are also made to the secondary node if command propagation is enabled. When command propagation is disabled, you can first make changes on the primary node. Once the configuration is completed and is verified to be functioning properly, you can use the force ha sync command to ensure that the changes propagate to the secondary node. Basic Administration for Citrix NetScaler 9.2

3.3.2. Automatic Configuration Synchronization
By default, configuration synchronization between the systems in a high-availability pair occurs automatically. Configuration synchronization occurs when: A node first comes up in the secondary state. A failover event occurs. A forced synchronization is issued. When a save configuration is issued on the primary system, the running configuration on both systems is saved from memory to the ns.conf file on the flash drive. In some cases, automatic synchronization may not be desired. For example, if you are testing two different configurations in a high-availability pair, the changes are also made to the secondary node if configuration synchronization is enabled. When configuration synchronization is disabled, you can first make changes on the primary node and then make changes on the secondary node. You can still failover to the secondary node with the original configuration on the primary node. Once the configuration is completed and is functioning properly, you can use the force ha sync command to ensure that the changes synchronize to the secondary node. Basic Administration for Citrix NetScaler 9.2

3.3.3. Forced Synchronization

3.3.4. Performing a Forced Failover

3.4. High Availability Management
While a high-availability pair can be managed using the unique NSIP addresses assigned to each node during initial configuration, a best practice is to manage the pair using either a MIP or SNIP address. When a shared IP address is used to connect to either the command-line interface or the Configuration Utility, the connection is made to the primary node in the pair. If a failover occurs, the secondary node becomes primary, and the same MIP or SNIP address then connects to the new primary node. Using a MIP or SNIP address is also helpful when you need to perform configurations from a subnet different from that of the high-availability pair. Every NetScaler system is assigned a MIP address or a range of MIP addresses during initial configuration; however, management access must be enabled on the MIP or SNIP address before it can be used to manage a high-availability pair. A best practice is to secure management access in the NetScaler system. Basic Administration for Citrix NetScaler 9.2

3.4.1. Upgrading a High Availability Pair
When the nodes of a high-availability pair are running different versions of the system software, the node running the newest version goes into listen mode. When a node is in listen mode, neither propagation nor synchronization occurs. Listen mode is used if you want to test the newest software version on one node before upgrading the second node. To conduct such a test, you perform a forced failover on the upgraded system, causing it to take over as the primary node. When a forced failover occurs, neither propagation nor synchronization occurs, and all connections need to be re-established. Basic Administration for Citrix NetScaler 9.2

4. Securing the NetScaler System
Overview Securing access to the NetScaler system requires a detailed understanding of NetScaler internal and external communications. Regulating those communications along with system access can be done through the use of access control lists. Objectives At the end of this module, you will be able to: Design access control lists to secure NetScaler communications. Secure internal and external NetScaler communications. Secure access to the NetScaler system through authentication, authorization, and auditing. Basic Administration for Citrix NetScaler 9.2

4.1. NetScaler System Communication
To secure NetScaler system communication, you must first understand the external and the internal communication that occurs when the NetScaler system is deployed. Inline Topology You need to consider both the topology of the network and the communication that needs to take place on the NetScaler system before communication can be secured.Inline topology deployment is a best practice for securing the NetScaler system. It is important to consider Virtual Local Area Network (VLAN) creation when securing a NetScaler system. NetScaler Operation LayerNetScaler communication types and layers must be secured. The NetScaler system uses layer 2 for internal, external, and management communication. Access control lists also communicate on layer 2, layer 3, and layer 4. Basic Administration for Citrix NetScaler 9.2

4.1.1. NetScaler Communication Types
Typical communication types include: System-to-system communication High availability is a type of system-to-system communication. High-availability communication occurs by default on TCP port 3010 and High-availability communication is secure on TCP port 3008 and 3009 and is used for command synchronization and command propagation. UDP port 3003 is used for the high-availability heartbeat and is a health-check industry standard.GSLB is a type of system-to-system communication that occurs by default on TCP port GSLB communication is secure on TCP port 3009 and is used for GSLB metric exchange protocol communication. Management communication The command-line interface is a type of management communication involving SSH on TCP port 22 (Secure Telnet). The command-line interface is accessed through Telnet on TCP port 23, which is not secure and is disabled by default.The Configuration Utility and GUI are a type of management communication that includes the front-end and the Java applet. The front-end is on TCP port 80, which is the default port. It is secure on TCP port 443. The Java applet is on TCP port 3010, which is the default port. It is secure on TCP port SNMP request and response traffic communication SNMP request and response traffic (polling) is a type of communication that occurs on UDP port 161. SOAP XML API occurs on TCP port 80 using HTTP, and it is secure on TCP port 443 using HTTPS Basic Administration for Citrix NetScaler 9.2

4.1.2. Security Parameter Components
The components that are necessary when configuring security parameters on a NetScaler system are access, authentication, authorization, and accounting. Access Limits, by network, the ability to access the devices by protocol Authentication Verifies that a user has the proper credentials Authorization Verifies that each user has the authority to perform various actions Accounting Logs what actions were taken and by whom Basic Administration for Citrix NetScaler 9.2

4.2. Access Control Lists Access control lists can be configured on the NetScaler system. The NetScaler system compares incoming packets against the access control lists. If a packet matches an access control list rule, the action specified in the rule is applied to the packet. All access control lists are enabled by default. The NetScaler system compares incoming packets against all the access control lists. If an access control list is not required as part of the lookup table but is retained in the configuration, then it should be disabled before applying the access control lists. Once the access control lists have been applied, the system does not compare incoming packets against disabled access control lists. Basic Administration for Citrix NetScaler 9.2

4.2.1. Simple Access Control Lists
You can configure simple access control list packet filters based on only the source IP address and the port. If both simple and standard access control lists are configured, simple access control lists are applied first. If the simple access control list returns a DENY, then the configured action is taken. If the simple access control list returns an ALLOW, then the standard access control list is applied, and the return value determines the action. The NetScaler system allows 100,000 simple access control lists to be configured. The standard access control list limit is 1024, but simple access control lists can be created as memory allows. Basic Administration for Citrix NetScaler 9.2

4.2.2. Matching Access Control List Entries
The NetScaler system can implement IP address-based traffic control on data that it handles using access control lists. This functionality is inherent to the NetScaler system, and it does not need to be enabled. The ways in which traffic can be handled once it is matched are: Allowed Traffic is allowed and is processed by the NetScaler system. Bridged Traffic is forwarded through the NetScaler system but is not processed. Denied Traffic is dropped Basic Administration for Citrix NetScaler 9.2

4.2.3. Traffic Identification

4.2.4. Access-Control-List Syntax Format and Precedence
The access-control-list syntax format of the add ns acl command is virtually the same for NetScaler 7.0 and above editions. Both versions support the use of the same eight packet attributes for defining access control lists. Refer to the appropriate Command Reference Guide for the NetScaler version in use for more detailed information on parameters and options. Basic Administration for Citrix NetScaler 9.2

4.2.5. Access-Control-Lists Precedence
Access-control-list precedence is determined according to the following rules: The most specific access control list takes priority unless the priority is assigned. The destination takes priority over the source when there is no priority assigned. The first access control list that matches determines how the packet is processed. The packet is only affected by a single access control list or no access control lists if there is no match Basic Administration for Citrix NetScaler 9.2

4.2.6. IPv6-Based Access-Control-List Support
Access control lists based on Internet Protocol version 6 (IPv6) are configured in the Configuration Utility. To create an IPv6 access control list, create an extended access control list and select the appropriate IPv6 protocol. The NetScaler system extends its IPv6 support to server-side implementation. End-to-end IPv6 support enables the use of IPv6 addresses for SNIP addresses, virtual servers, services and servers. IPv6 management utilities can also be used, such as Ping6 and Traceroute6. IPv6 support also extends to OSPFv3. Static routes can be: Configured using IPv6 addresses to any destination Assigned values for distance and cost Enabled in the advertising of static routes to IPv6 routing protocols Basic Administration for Citrix NetScaler 9.2

4.3. Access-Control-List Configuration

Simple Access-Control-List Configuration (Command-Line Interface) Basic Administration for Citrix NetScaler 9.2

Configuring Detailed Access Control Lists (Command-Line Interface) Basic Administration for Citrix NetScaler 9.2

Creating and Removing Access Control Lists (Command-Line Interface) Basic Administration for Citrix NetScaler 9.2

4.3.4. Applying Access Control Lists (Command-Line Interface)

4.3.5. Viewing Access Control Lists (Command-Line Interface)

4.3.6. Access-Control-List Priorities (Command-Line Interface)

Removing Access Control Lists from the System (Command-Line Interface) Basic Administration for Citrix NetScaler 9.2

Access-Control-List Syntax Format for Different NetScaler Versions The NetScaler system supports other access-control-list commands, including: Enable Disable Add Remove Set Unset Apply Clear Renumber Show Stat Basic Administration for Citrix NetScaler 9.2

Access-Control-List Example

5. Configure Load Balancing
Overview Load balancing allows the NetScaler system to distribute client requests across multiple servers to optimize resource utilization. Load balancing improves server fault tolerance and user response time. Server performance can degrade in a real-world scenario in which a limited number of servers provide service to a large number of clients. The NetScaler system uses load-balancing criteria to prevent bottlenecks by forwarding the client requests to the server best suited to handle them. Objectives At the end of this module, you will be able to: Create and configure system entities. Configure service monitoring. Create load-balancing virtual servers. Configure advanced load-balancing options and methods. Manage services and virtual servers. Basic Administration for Citrix NetScaler 9.2

5.1. Load-Balancing Process

5.2. Entity Management Basic Administration for Citrix NetScaler 9.2

Entity Management .. Contd ..

Creating Servers Basic Administration for Citrix NetScaler 9.2

Creating Services Basic Administration for Citrix NetScaler 9.2

5.2.3. Creating Virtual Servers

Binding Services Basic Administration for Citrix NetScaler 9.2

Monitors Monitoring of a service will not take place until the monitor is bound to a service. The NetScaler system supports multiple monitors for any given service. When a service is bound to multiple monitors, the status of the service is based on the results sent by all the monitors. For example, a service is marked as UP only if all monitors associated with that service return an UP status after probing. If any monitor returns a DOWN status, the service is marked as DOWN. Additionally, monitor weights and thresholds can be configured for a service, which specifies that some but not all the monitors must pass a health-check probe for a service to be marked as UP. Monitors are associated with every service to verify that the service is UP and available. Depending on the type of service, different kinds of monitoring may be required. Basic Administration for Citrix NetScaler 9.2

5.3. Load-Balancing Traffic Types

5.4. Service Monitoring The purpose of service monitoring is to check the state of the services periodically. Monitors specify the types of requests sent to a service and the expected response from the service; this probe is known as a health check. If a service responds appropriately to the health check within the specified period of time, the state is marked as UP and that service continues to have requests directed to it. If, however, a service fails a health check, the state is marked as DOWN, and it no longer receives requests. Each service defined on the NetScaler system requires some form of monitoring to ensure that requests are not sent to an unavailable service. Depending on the type of service, different kinds of monitoring may be required. Each monitor type requires its own set of parameters. The function of a particular service must be considered when defining monitors. Is a completed 3-way handshake enough to verify that the service is running? Does the service rely on other services in the enterprise to function? While the default monitors facilitate simple deployments, many environments are better served with the additional types of monitors available in the system. The state of a service is maintained across high-availability pairs. Basic Administration for Citrix NetScaler 9.2

Binding Monitors Basic Administration for Citrix NetScaler 9.2

5.4.2 Default Monitors Basic Administration for Citrix NetScaler 9.2

5.4.3 Monitor Parameters Basic Administration for Citrix NetScaler 9.2

Monitor parameters .. Contd ..

Creating Monitors Basic Administration for Citrix NetScaler 9.2

HTTP Monitoring Basic Administration for Citrix NetScaler 9.2

ECV Monitoring Extended content verification (ECV) monitors are used for verifying content in HTTP, TCP, and UDP payload. ECV monitors are considered kernel monitors because they are basic, high-performance probes that originate from the BSD kernel. General limitations of ECV monitors include: Having one request/response Having 127 characters in the probe request Having only the first 24 KB of the probe response parsed For HTTP and TCP services, predefined Extended Content Verification (ECV) monitors are available. For ECV monitors, it is not enough to see that a TCP connection was accepted; some particular reply in the connection is required to mark the service as UP. For these monitors, a request string is configured along with an expected reply string. If the reply string received by the monitor matches the expected string, then the service is marked as UP. Basic Administration for Citrix NetScaler 9.2

5.4.7 HTTP-ECV and TCP-ECV Monitoring Process

5.4.8. HTTP-INLINE Parameters

5.4.9. Reverse Condition Monitoring
The reverse parameter specifies whether 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. In normal conditions, a probe will fail when the conditions of a monitor are not met. For 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. The reverse parameter is disabled by default. Basic Administration for Citrix NetScaler 9.2

5.4.10. Setting Monitor Thresholds

5.5. Load-Balancing Topology

5.6. Load-Balancing Methods

Service Weights Basic Administration for Citrix NetScaler 9.2

Persistent Clients A load-balancing determination is made when the NetScaler system receives the first RTSP packet from the client. The subsequent requests on that connection are forwarded to the same server regardless of the RTSP session to which it is referring. Multiple SETUP requests that belong to two different RTSP sessions can arrive on a single TCP connection. A load-balancing determination is made per TCP connection, not for each RTSP session. RTSP sessions can switch TCP connections, which complicates the connection management in the NetScaler system. A session can switch to another TCP connection that is being handled by the same virtual server but that is being handled by a different back-end server. This session leads to multiple server connections per client connection and is not supported. Once the server and client side connections are linked, the NetScaler system does not validate the session, and the request or response is parsed and forwarded to the back-end server. Basic Administration for Citrix NetScaler 9.2

Session Persistence Basic Administration for Citrix NetScaler 9.2

5.6.4. Non-Persistent Clients
An RTSP session can spread across multiple TCP connections (non-persistent cases), which can be easily addressed because the server IP address and port are encoded in the session ID or through session entries maintained on the NetScaler system Basic Administration for Citrix NetScaler 9.2

Persistence Methods Persistence methods are determined based on the method assigned to the service Basic Administration for Citrix NetScaler 9.2

Persistence Tables Basic Administration for Citrix NetScaler 9.2

5.7. Additional Load-Balancing Options

5.8. Advanced Load-Balancing Methods
Three advanced load-balancing methods that are available on the NetScaler system are least-response-time based on monitoring, token-based load balancing, and hash load balancing. The least-response-time method chooses the service with the minimum average response time. Token load balancing is based on matching a token with the request or TCP payload. Hash load balancing includes several methods that use a hash value of some aspect of the client request to determine where to forward the request. The NetScaler hashing types include: URL hashing Domain-name hashing Source-IP-address hashing Destination-IP-address hashing Source/destination IP hashing Basic Administration for Citrix NetScaler 9.2

Token A token is created based on the client request, and the request is forwarded to a service based on the results of that token. The exact choice of variables and token configuration are user configurable. An advantage of this kind of load-balancing method is that it works across different virtual servers. For example, it ensures that requests for HTTP and FTP are served from the same physical server, even though they are advertised through two different virtual servers. Basic Administration for Citrix NetScaler 9.2

Hash Load-Balancing Basic Administration for Citrix NetScaler 9.2

5.9. Link Load Balancing Link load balancing transparently load balances inbound and outbound traffic across multiple Internet connections. An example of link load balancing in use is an organization connecting to the Internet through multiple service providers. The link load-balancing feature enables enterprises that have more than one link to the Internet or a private network to monitor and control traffic so users are routed over the best available Internet link. This is accomplished by monitoring routers. Basic Administration for Citrix NetScaler 9.2

5.9.1. Link Load-Balancing Policy
You should be aware of the following considerations when configuring a link load-balancing policy: A load-balancing decision is applied whenever the packet is routed through the load-balancing route. The load-balancing feature gets its input from the virtual IP address associated with the load-balancing route. The preferred IP address and preferred port parameters are valid only if the persistence feature is enabled. The server statistics update and link load balancing on the NetScaler system returns the server structure for the selected router if the preferred router is up. The ideal router is selected based on the load-balancing policy from the server list of the virtual IP address if the preferred server is not available. Link load balancing supports the following load-balancing methods: Round robin Least bandwidth Least packet Destination-IP-address hash Basic Administration for Citrix NetScaler 9.2

5.10. Custom Load The custom load-balancing method calculates load by using metrics that have been created and bound to a metric table. Once a metric has been created and bound, the metric table is then associated with a load monitor. Metrics can then be bound to the monitor from the pool of available metrics that reside in the metric table. The custom load-balancing method distributes traffic based on the load calculations made by load monitors. The service with the least load value, as calculated by the monitors, is chosen to handle the client requests. Note 1: All services bound to a virtual server for which the load-balancing method is custom load must have load monitors bound to them. If no load monitors are bound, the virtual server will use the round-robin load-balancing method. Note 2: The local metric table is implicitly bound to the monitor and no additional binding operation is required. Basic Administration for Citrix NetScaler 9.2

5.11. Load Monitor Process A load monitor performs load balancing based on server parameters such as CPU or memory usage. While other NetScaler monitors perform health checks that determine whether to include the service in load balancing, load monitors calculate the load on a service to distribute the traffic appropriately between the services. Note: A load monitor is used strictly for load balancing and, unlike service monitors, does not determine the state of the service to which it is bound. A load monitor uses the following process when calculating the load on a service: The load monitor sends an SNMP request for load metrics to a specified server. The server returns an SNMP response with the requested metrics. The load monitor calculates the load for the service to which it is bound based on the SNMP response received from the server. When the load monitor is configured, it can contain up to ten SNMP OIDs (object identifiers) for the query. Each OID can have its own weight and threshold levels configured, which are then used in calculating the load when the SNMP response is received. Based on the results of the calculation, the service is included in or excluded from the load-balancing decision. Basic Administration for Citrix NetScaler 9.2

5.11.1. Load Monitor Parameters

Binding Metrics Basic Administration for Citrix NetScaler 9.2

5.12. Service and Virtual Server Management

5.12.1. Service and Virtual Statistics

5.12.2. Disabling Service and Virtual Servers

5.12.3. Removing Services and Virtual Servers

5.12.4. Monitoring Traffic Distribution

5.13. Load Balancing Visualizer
The Load Balancing Visualizer can be used to view and modify load-balancing configurations in graphical format. Using the Load Balancing Visualizer, you can: View a summary of all services and service groups that are bound to a particular virtual server and all of the monitors that are bound to the services. View the configuration details of any displayed element. View policies (for example, rewrite policies) that are bound to the virtual server. View the type of traffic that will be directed to the load-balancing virtual server. Detect a mismatch in service configuration. Simultaneously bind multiple entities to another entity using a drag-and-drop operation. Modify an existing configuration. Bind and configure entities in the Configuration Utility under Load Balancing > Virtual Servers > Visualizer. Basic Administration for Citrix NetScaler 9.2

6. Configuring SSL Offload
Overview The need for organizations to maintain privacy while transmitting private data over public networks was the primary impetus behind the development of the SSL protocol and digital certificates. SSL offloading on the NetScaler system can be used to optimize traffic, while maintain the security of the private data. Obectives By the end of this module, you will be able to: Identify SSL certificate requirements. Identify common virtual SSL server deployments. Create and upload an SSL certificate. Bind an SSL certificate key. Create appropriate servers, services and virtual servers. Configure advanced SSL options. Basic Administration for Citrix NetScaler 9.2

6.1. SSL and Digital Certificates
Unfortunately, the processing of SSL transactions by a Web server is CPU-intensive enough to negatively affect Web application performance. Configuring SSL offload on the NetScaler system can free the Web servers from handling the SSL encryption/decryption tasks, while maintaining security without degrading Web server performance. SSL SSL is a session-layer encryption and authentication protocol used with HTTP and other protocols to secure communication between clients and servers. SSL, which is widely used to support e-commerce sites, specifies a method for a client and a server to exchange cryptographic information and to build a secure channel through which to send requests and responses. However, SSL can be used to secure other types of traffic— nothing in SSL relies on HTTP being sent through the encrypted channel. Transport Layer Security (TLS) is a descendant of SSL that abstracts the security protocol from any specific underlying service. Key Encryption SSL and TLS make use of public and private key cryptography to verify the identities of the server and client and to set up the initial secure channel for the communication. Public-private key encryption is a form of asymmetric encryption, meaning that two separate but related keys are required. A message encrypted by one key can only be decrypted by the related key. Public-private key encryption is a resource-intensive process. Basic Administration for Citrix NetScaler 9.2

6.2. Important Concepts: SSL
- SSL is a protocol used to secure TCP traffic - Keys are strings of bits used to encrypt and decrypt mesages. The NetScaler system supports: 1. RSA keys, which use public PGP encryption 2. DSA keys, which use FIPS-standard digital signature algorithms - Public-key encryption is a method of encrypting mesages that pairs a public key and a private key. Messages encrypted with the public can only be decrypted with the private key. In turn, mesages encrypted with the private key can be decrypted only using the public key - The Diffie-Hellman key exchange protocol permits two users to swap a confidential key over an unprotected medium without any previous secrets Basic Administration for Citrix NetScaler 9.2

6.3. SSL Offload Overview Basic Administration for Citrix NetScaler 9.2

6.4. Offload Performance The NetScaler system supports extremely high-performance SSL encryption and session creation. For example, the NetScaler MPX platforms support: 6 Gbps of bulk encryption 48,000 new SSL handshakes per second The NetScaler system can offload a significant portion of the total application load from the servers it supports as well as switch the resulting SSL traffic. This offload cannot be done efficiently by traffic management systems. If the traffic management system is not decrypting the data, it is unable to make load-balancing decisions based on application data, such as HTTP header information or cookies. Instead, legacy traffic management systems must treat all of the traffic like raw IP traffic and make decisions based on source and destination IP addresses. By decrypting the traffic as it enters the NetScaler system, SSL processing can be offloaded from application servers, allowing the robust traffic management functionality of the NetScaler system to come into play. The NetScaler system can also provide protection against encrypted attacks by terminating and offloading SSL. By terminating the SSL, the NetScaler system can inspect and protect all traffic going to the servers in addition to switching it intelligently. Without this benefit, attacks can be wrapped in SSL and delivered securely to the server. Basic Administration for Citrix NetScaler 9.2

Features and Benefits Basic Administration for Citrix NetScaler 9.2

6.5. SSL Administration Basic Administration for Citrix NetScaler 9.2

6.5.1. Important Concepts: Certificates

SSL Keys Basic Administration for Citrix NetScaler 9.2

6.5.3. Generating a Certificate Signing Request

SSL Certificates Basic Administration for Citrix NetScaler 9.2

6.5.5. Generate a Certificate

Certificate Key Pairs For SSL processing to occur, an SSL key file must be bound to the virtual server. An SSL key file is an integral element of the SSL encryption and decryption process, which is used during the SSL handshake to determine the cipher that will be used for SSL processing and also to establish the identity of the SSL server. Before a client certificate can be used for SSL processing, it must be paired with its corresponding key file which resides on the NetScaler system. This certkey pair is then bound to the client connection for SSL processing. Note: A certificate key pair is used on a per connection basis. Each client connection requires a unique certificate key pair. Basic Administration for Citrix NetScaler 9.2

6.5.7. Adding a Certificate Key

6.5.8. Binding a Certificate Key

6.6. SSL Offload The SSL offload feature ensures the secure delivery of Web applications without degrading user performance. The NetScaler system intercepts SSL transactions on behalf of back-end Web servers. The NetScaler system then processes these transactions, applies system policies and relays the transactions to the servers in either plain text or encrypted mode. The following components and settings are required in order to properly configure SSL offload: A defined SSL termination point A server certificate installed on the NetScaler system Root, intermediate and client certificates installed on the client, depending on environmental needs Appropriate servers, services and virtual servers configured on the NetScaler system Basic Administration for Citrix NetScaler 9.2

6.6.1. SSL Termination Points

6.7. Deployment Scenarios The SSL requirements for a particular environment depend on how SSL will be deployed. The following scenarios are the most common: Front-end SSL with Back-end HTTP Front-end SSL with back-end HTTP refers to a network configuration that allows the NetScaler system to offload SSL encryption and decryption, and pass traffic to Web servers in plain text. Front-end SSL with Back-end SSL Front-end SSL with back-end SSL refers to a network configuration that allows the NetScaler system to pass traffic to Web servers in encrypted mode. Although the NetScaler system does not fully offload SSL processing, it can provide a benefit through SSL connection multiplexing or the use of a smaller cipher. Front-end TCP over SSL with Back-end TCP Front-end TCP over SSL with back-end TCP refers to a network configuration that allows the NetScaler system to offload SSL encryption and decryption for client connections, as well as pass any TCP traffic to servers in plain text. An example of this type of deployment scenario is providing secure access for LDAP directories. Basic Administration for Citrix NetScaler 9.2

6.7.1. Front-end SSL with Back-end HTTP Requirements

6.7.2. Securing Traffic Between a Client and the NetScaler System

6.7.3. Front-end SSL with Back-end SSL Requirements

6.7.4. Securing Traffic Between the NetScaler and the Server

6.7.5. Front-end SSL_TCP with Back-end TCP Requirements

6.7.6. Securing TCP Traffic Between a Client and the NetScaler System

SSL_Bridge The SSL_BRIDGE functionality allows all secure traffic to be transparently bridged directly to the back-end Web server. The system does not terminate or offload this traffic. In this scenario, the Web server must handle all SSL-related processing. Note: This configuration should be used only if an acceleration unit (for example, a PCI-based SSL accelerator card) is installed in the Web server to handle the SSL processing overhead. In an SSL_BRIDGE setup, the system is configured to load balance and maintain server persistency for secure requests using the SSL Session-ID. Other features, such as content switching, Sure Connect and cache redirection, do not work because the traffic passing through the NetScaler system is encrypted. Because the system does not carry out any SSL processing in an SSL_BRIDGE setup, there is no need to bind a certkey to the SSL_BRIDGE virtual server. Basic Administration for Citrix NetScaler 9.2

6.7.9. SSL_Bridge Requirements

6.8. Configuring SSL Offload

6.9. Creating SSL Virtual Servers

6.9.1. Binding an SSL Virtual Server

6.10. Advanced SSL Settings Basic Administration for Citrix NetScaler 9.2

6.10.1. Configuring Advanced Settings

7. Configuring Global Server Load Balancing
Overview Global Server Load Balancing (GSLB) enables the NetScaler system to make intelligent traffic direction decisions. For example, if a site fails, the NetScaler system detects the failure and directs traffic to another available site. This feature prevents client requests from being sent to a site that is unavailable or overloaded. Objectives By the end of this module, you will be able to: Describe GSLB architecture. Identify core DNS concepts. Identify core GSLB concepts. Describe traditional GSLB. Describe proximity-based GSLB. Basic Administration for Citrix NetScaler 9.2

7.1. GSLB Concepts GSLB is a DNS-based solution that load balances services between geographically distributed locations. GSLB operates under many of the same general principles as load balancing, but it relies on DNS for directing client requests. A major benefit of GSLB is the reduction of application latency. Typical uses of GSLB include: Network traffic distribution across multiple sites Server load distribution across multiple sites Disaster recovery GSLB Hierarchy GSLB networks have a maximum of 32 sites. NetScaler systems can be deployed in Hierarchy mode for scenarios that require additional units Basic Administration for Citrix NetScaler 9.2

7.1.1. GSLB Conversation Process

GSLB Entities Basic Administration for Citrix NetScaler 9.2

7.2. Metric Exchange Protocol
The NetScaler system uses the proprietary metric exchange protocol (MEP) to exchange site metrics, network metrics and persistence information between sites. A single, long-lived connection between two sites is used to exchange all metric information. The site with the lower GSLB site IP address initiates the connection with the site with the higher GSLB site IP address. By default, this connection is made from the NSIP address to the GSLB site IP address. However, you can configure the NetScaler system to use an IP address other than the NSIP address. Performing user authentication before metric information is exchanged provides controlled access. All sites taking part in metric exchange should have the same nsroot user ID and password. The communication process is accomplished between each GSLB site on TCP port 3011 or port 3009 if secure. You must open the correct port on any firewalls between the NetScaler systems. The public IP address of the site needs to be allowed on any blocking firewall. When MEP is disabled, GSLB methods are limited to round-robin, static-proximity and source-IP-address hash. All other methods revert to round robin when MEP is disabled. Basic Administration for Citrix NetScaler 9.2

7.2.1. Metric Information Types
The GSLB site metric exchange interval is one second. Metric information types include: Site Site information consists of the current number of connections and current packet rate for a load-balancing virtual server. Network GSLB sites exchange RTT information about the learned DNS of the clients when dynamic proximity-based GSLB is enabled. This information is exchanged every five seconds. Persistence GSLB site information is exchanged every five seconds. Basic Administration for Citrix NetScaler 9.2

7.2.2. GSLB Monitoring Configuration

7.3. GSLB DNS Methods The NetScaler system can be configured to respond to DNS queries in the following ways: Authoritative Domain Name Server (ADNS) The NetScaler system in ADNS mode is the authority for a domain and all the records within that domain. It resolves the domain name received in the client DNS query to one or more IP addresses. It does not support zone transfers. This method: Occurs when the NetScaler system is assigned and is authoritative for a domain Is typically used for GSLB internal-facing deployments Presents challenges with Active Directory Domain Name Server (DNS) ProxyAs a proxy to an external DNS server, the NetScaler system caches the DNS responses sent by the external name server. This method: Occurs when the NetScaler system forwards or proxies DNS requests to a DNS server Does not have an internal DNS on the NetScaler system DNS sub-delegation DNS sub-delegation occurs when the DNS server assigns the responsibility for a subdomain to a NetScaler system. The DNS server redirects DNS requests to the NetScaler system that resolves the IP address. This method: Occurs when the DNS server assigns the responsibility for a subdomain to a NetScaler system Has the DNS server redirecting DNS requests to the NetScaler that resolves the IP address Basic Administration for Citrix NetScaler 9.2

7.3.1. Authoritative DNS Service
The NetScaler system can be configured with single or with multiple instances of an Authoritative DNS server, where each instance listens on a different IP address, and all instances reference the same name table. The ADNS service is a local service type listening for incoming DNS requests on UDP port 53. In an authoritative configuration, the NetScaler system answers the DNS query. In this configuration, the NetScaler system: Is locally configured as Start of Authority (SOA) for the GSLB domainThis configuration creates similar DNS records for each site in the configuration. Can be configured for a maximum of 32 sites Does not support zone transfers or recursive query Can be set to participate as authoritative Basic Administration for Citrix NetScaler 9.2

Name Servers Name servers store information about one or more zones. The following list contains descriptions of name servers that can be added internally on the NetScaler system: IP address-based The user has to specify the IP address of the name server to contact. Virtual server-based The user has to specify the name of the DNS virtual server configured in the NetScaler system. Basic Administration for Citrix NetScaler 9.2

DNS Request Scenarios The NetScaler system uses existing virtual server and service functionality when responding to DNS requests. The NetScaler system uses a MIP address or SNIP address as the source IP address for queries. The DNS server responses are cached on the NetScaler system until the time to live (TTL) expires. For clients making DNS requests, two different scenarios exist: Local DNSA local DNS server is created on the NetScaler system. The local DNS is an authoritative DNS server for the zone configured. The local DNS listens on an IP address provided in the configuration. Clients can configure their local TCP/IP stack to forward queries to this IP address. Load-balancing DNSA DNS load-balancing virtual server is created and provides an IP address. The services are added to redirect traffic to DNS servers. The clients configure the load balancing virtual server IP address as their DNS server IP address. Basic Administration for Citrix NetScaler 9.2

Resource Records On the NetScaler system, DNS records contain DNS data. The following DNS records are supported on the NetScaler system: Address (A) records Canonical Name (CNAME) Mail Exchange (MX) Name Server (NS) Start of Authority (SOA) Service Record (SRV) Pointer Record (PTR) Authentication, Authorization, Accounting and Access (AAAA) Basic Administration for Citrix NetScaler 9.2

7.4. GSLB Persistence Basic Administration for Citrix NetScaler 9.2

7.5. Configuring DNS Virtual Servers

7.6. GSLB Configurations Basic Administration for Citrix NetScaler 9.2

7.7. Implementing Traditional GSLB
When the DNS request from the resolver of the client is received by the NetScaler system, the load-balancing and the site fault-tolerance decision is made based on the health status and the load of the participating sites. When the host name of the URL is resolved, all traffic from the client is sent directly to the resolved site. When the DNS request from the resolver of the client is received by the NetScaler system, the site load information is exchanged between the GSLB sites. When the host name of the URL is resolved, all traffic from the client is sent directly to the resolved site. For GSLB to work as defined, either the MEP should be enabled, or explicit monitors should be bound to remote services. MEP Failover If the MEP fails for any of the participating sites because of external factors, then the default method, round robin, is used instead of least-response time, least connections, least bandwidth and least packets. If the remote service belonging to the site for which MEP has failed has an explicit monitor bound to it, and its state is UP, then it is included in the round-robin rotation; otherwise, it is not. Basic Administration for Citrix NetScaler 9.2

7.8. Implementing Proximity-based GSLB
When enabled, the proximity-based GSLB method allows the NetScaler system to make load-balancing decisions based on the proximity of the local DNS server (LDNS) of the client in relation to different sites. Proximity can be measured both statically and dynamically. The dynamic determination of proximity is based on the current network status, while the static determination of proximity is based on the geographic location of the LDNS of the client and the sites the client is accessing. The main benefit of the proximity-based GSLB method is faster response time resulting from the selection of the closest available site. Proximity methods require a specific license for NetScaler versions prior to 8.0. Basic Administration for Citrix NetScaler 9.2

7.8.1. Proximity-Based Load-Balancing Methods
Proximity-based load-balancing methods include: Dynamic network proximity Round Trip Time (RTT) Static proximity Dynamic Network Proximity Network proximity is a measure of how far a user is from a data resource in terms of network distance or time. The GSLB feature monitors the real-time status of the network and directs the request of the client to the best site. GSLB uses a smoothed RTT metric to measure network proximity. Using the smoothed RTT metric could result in network congestion. The RTT between the LDNS of the client and each of the participating sites is measured. The system then uses this metric to make its load-balancing decision. The DNS response generated by the system carries the IP address of the site closest to the LDNS of the client in terms of RTT. The GSLB solution uses its proprietary MEP to exchange metrics between participating sites. Using this protocol, the system learns the network metric information RTT of the LDNS of the client. When the LDNS of a client accesses the GSLB site for the first time, the RTT information is not available with the system. In such cases, the GSLB virtual IP address selects a site using the round-robin method and directs the client to this site. The system then starts calculating the RTT between the site and the LDNS. The system deployed at the participating site begins to calculate the RTT between the LDNS and the GSLB site. Periodically, the system participating in GSLB reports the RTT to other participating systems. When the DNS query is sent the next time, the system selects the best site using the network metrics. The NetScaler system uses different mechanisms, such as ICMP echo request/reply (ping), UDP (DNS) and TCP, to probe the RTT metrics between the LDNS and the sites participating in the GSLB domain. First, a ping probe is performed to obtain the RTT. If the ping probe fails, the DNS probe is performed to calculate the RTT. If the DNS probe also fails, the TCP probe is performed. Static Proximity The static proximity feature uses an IP-address-based static location database. The database used to implement the static proximity method often contains all of the GSLB site locations. The NetScaler system uses this database to determine the proximity between the LDNS of the client and the GSLB sites. The NetScaler system responds with the IP address of the closest site that matches the proximity criteria. The locations in the static GSLB database consist of an IP address range and up to six qualifiers for this range. The custom database is stored in ns.conf, and a static third-party or NetScaler system database is stored in the /var/netscaler/locdb directory by default. Basic Administration for Citrix NetScaler 9.2

7.9. Implementing GSLB Failover for Disaster Recovery

7.10. Configuring GSLB Virtual Servers
Create a GSLB load balancing virtual server by specifying the name of the virtual server: Configuration Utility location Under the GSLB > Virtual Server node Command-line syntax add gslb vserver vserverName serviceType Basic Administration for Citrix NetScaler 9.2

Configuring ADNS Basic Administration for Citrix NetScaler 9.2

7.10.2. Synchronizing a GSLB Configuration

8. Management Overview The NetScaler system can be monitored with the following tools: Simple Network Management Protocol (SNMP) Dashboard Monitoring tool The NetScaler system has the following auditing and logging features: Support for syslog and nslog auditing Log access and management Objectives By the end of this module, you will be able to: Configure monitoring with SNMPv1 and SNMPv2 on the NetScaler system. Monitor the NetScaler system with the Dashboard. Monitor the NetScaler system with the Monitoring tool. Configure syslog and nslog logging. Access and manage NetScaler logs. Basic Administration for Citrix NetScaler 9.2

8.1. Simple Network Management Protocol
Simple Network Management Protocol (SNMP) is an application-layer protocol that provides a method for network devices to communicate status and configuration information to a management station. By default, SNMP uses UDP on port 161 for queries and port 162 for traps. You can perform the following SNMP configurations on the NetScaler system: Specify system information that can be displayed using the NetScaler SNMP MIB. Specify SNMP traps that track various parameters, such as usage and interface status. A NetScaler system supports SNMPv1, SNMPv2 and SNMPv3. SNMPv1 and SNMP v2 use a simple and non-secure authentication feature called community strings. SNMPv3 adds security with authentication, privacy and access control. SNMPv3 is not a replacement for previous versions; it defines a security capability to be used in conjunction with SNMPv1 or SNMPv2. SNMPv1 and SNMPv2 consist of the following components: Managed devices Agents Managers Management Information Base (MIB) Community Strings Traps Basic Administration for Citrix NetScaler 9.2

Managed devices Managed devices are network nodes that reside in a managed network. Managed devices collect and store management information and make this information available to a network management system (NMS) using SNMP. Managed devices are sometimes called network elements and can be routers, access servers, switches and bridges, hubs, computer hosts, or printers. The NetScaler system is an example of a managed device. Basic Administration for Citrix NetScaler 9.2

SNMP Agents Agents are software modules that reside on managed devices. Agents listen on port 161 for request packets from managers and respond to requests for information and actions. In addition to the protocol and application layers, agents must also communicate with the operating system kernel. Typically, SNMP uses UDP port 161 for the agent and port 162 for the manager communications. The manager may send requests from any available port (source port) to port 161 for the agent (destination port). The agent response will be sent back to the source port, and the manager will receive traps on port 162. The agent may generate traps from any available port Note: The NetScaler system allows traps to be sent to a different port other than 162 if needed. Basic Administration for Citrix NetScaler 9.2

Managers Managers are devices that poll agents for information. Managers can perform a passive statistics-gathering function, or they can attempt to manage the network actively by setting new values in read-write variables on some hosts. SNMPv1 managers (programs on other servers that request SNMP information from the NetScaler system) use the NS-MIB-smiv1.mib file when processing SNMP queries. SNMPv2 managers use the NS-MIB-smiv2.mib file. Management systems tested with the NetScaler system include:OpenView WhatsUp Gold Net-SNMP (Linux) MGSoft (Windows) Basic Administration for Citrix NetScaler 9.2

8.1.4. Management Information Base

Community Strings A community string is a type of authentication that allows access to managed devices. The manager and agent must be in the same community. If a manager sends a request with the correct community string, the device responds with the requested information in accordance with the allowed level of access for that community string. If the community string is incorrect, the device simply discards the request and does not respond. Community string types include: Read-only community string Read-write community string Trap community string The default community string on the NetScaler system is public. The default community string should be changed to read-only, read-write, or trap. Basic Administration for Citrix NetScaler 9.2

Traps The only type of communication initiated from the agent to the manager is a trap. A trap is an alert or auto-fire event sent when some event or threshold is reached. A trap that is supported by almost all SNMP agents is the Authentication trap. This alert is raised whenever an unknown manager attempts a query on the agent. The NetScaler system supports SNMPv1 and SNMPv2 traps, but not SNMPv3 traps. Note: All SNMP traps are logged in syslog. Basic Administration for Citrix NetScaler 9.2

8.1.7. Configuring SNMPv1 and SNMPv2
You can use the following procedure to configure SNMPv1 and SNMPv2 on the NetScaler system. 1. Set access privileges for the network management application by configuring a manager. Configure a manager by specifying the IP address and subnet mask: Configuration Utility location Under the System > SNMP node Command-line syntax add snmp manager IPAddress[-netmask netmask 2. Set access privileges for the network management application user by configuring the community string. Configure the community string by specifying the SNMP community string and permissions: add snmp community communityName permissions 3. Set the MIB variable by specifying the contact, name, location, and custom ID: add snmp mib [-contact string] [-name string] [-location string] [-customID string] 4. Configure a trap by specifying: Trap type Trap version Destination IP address Destination port Source IP address Minimum severity (this is only applicable to NetScaler-specific traps) Community name 5. Configuration Utility location add snmp trap TrapClass TrapDestination [-version (V1 | V2)] -destPort port -communityName string [-srcIP IPAddress] -severity severity 5. Set a trap threshold. Configure an alarm by enabling the alarm, and specifying the severity level and current state of the alarm: Configuration Utility locationUnder the System > SNMP node Command-line syntax: set snmp alarm TrapName [-state ENABLED | DISABLED] Basic Administration for Citrix NetScaler 9.2

8.1.8. Configuring SNMP Managers

8.1.9. Configuring MIB System Variables

8.1.10. Configuring Community Strings

8.1.11. SNMPv1 and SNMPv2 Communication Process

8.1.12. Configuring SNMP Traps

Configuring Alarms Basic Administration for Citrix NetScaler 9.2

8.2. SNMPv3 SNMPv3 is based on the structure and architecture of SNMPv1 and SNMPv2 and uses the same protocol operations implemented by SNMPv1 and SNMPv2. SNMPv3, however, enhances the basic architecture to incorporate administration and security capabilities, such as authorization, access control, data integrity checking, data origin verification, message timeliness checking, and data confidentiality. SNMPv3 configuration packets (views, groups, users, and engineID) are sent to the SNMP daemon on the same UDP port 161 with source number IP address and destination number IP address of the loopback address ( ) to distinguish them from protocol data units. SNMPv3 provides security features, such as message-level security and access control. To implement these features, SNMPv3 introduces the following models: User-based Security Model (USM) USM provides message-level security. It enables you to configure users and security parameters at the agent and the manager to ensure: Data integrity, protecting messages from being modified during transmission through the network Data origin verification, authenticating the user who sent the message requests Message timeliness, protecting against message delays or replays Data confidentiality, protecting the content of messages from being disclosed to unauthorized entities or individuals View-based Access Control Model (VACM) VACM allows the configuration of access rights to a specific subtree of the MIB based on various parameters, such as security level, security model, user name, and view type. It enables the configuration of agents to provide different levels of access to the MIB to different managers. Basic Administration for Citrix NetScaler 9.2

8.3. Dashboard Basic Administration for Citrix NetScaler 9.2

8.3.1. System and Feature Counters

8.3.2. Reporting and Monitoring Tools

8.4. Auditing and Logging Auditing is a feature that is available on the NetScaler system that provides a log of system events. The NetScaler system allows you to customize the logging of system events according to the need of a site. Events can be recorded either to files on the NetScaler system or to external log servers. The NetScaler system supports two logging formats: Syslog Nslog By default, the NetScaler system records system events in syslog format to /var/log/ns.log using local0 and records SSL VPN events to /var/log/nsvpn.log using local1. Logging of these events is enabled by default. Syslog uses UDP over port 514, and syslog traffic is sent in clear text. The NetScaler kernel controls syslog processing. Nslog is a proprietary binary format, which records more detailed event information than the syslog format. Syslog and nslog events can be logged to either a local file on the NetScaler system or to a remote server. Basic Administration for Citrix NetScaler 9.2

8.5. Configuring an Auditing Server

8.6. Global Auditing Parameters

8.7. Configuring Auditing Policies

8.7.1. Binding Auditing Policy

Audit Messages Basic Administration for Citrix NetScaler 9.2

8.8. Replacing a High-Availability Node
When one node in a high-availability pair fails, the secondary node is the only NetScaler system accepting incoming traffic. A new node must be added to complete the high-availability pair. The configuration of the primary node is propagated to the new replacement node after it has been added. Use the following process to replace a failed node in a high-availability pair: Configure the active node to stay primary. Specify the NSIP address on the new system and restart. Copy all the necessary files, such as certificate files, key files, and custom monitors from the primary node. Turn off all unused interfaces on the new system. Create a new high-availability pair on the new system. Force synchronization on the new system. Enable high availability on the primary node. Basic Administration for Citrix NetScaler 9.2

8.9. Upgrading as a Standalone NetScaler System
The two different options for upgrading the NetScaler system are upgrading as a standalone, or upgrading a high-availability pair. Upgrading as a Standalone NetScaler System Use the following process to upgrade a standalone NetScaler system using the command-line interface: Create a backup copy of the ns.conf file. Create a release number nsinstall subdirectory in the /var/nsinstall directory. Create a build folder subdirectory in the /var/nsinstall/release number directory. Download and extract the contents of the installation package to the /var/nsinstall/release number/build folder. Run the installns script to install the new version. Restart the NetScaler system. Basic Administration for Citrix NetScaler 9.2

8.9.1. Upgrading a High-Availability Pair

8.10. Password Recovery The NetScaler system default user account is nsroot. The password for this account should be changed prior to saving your initial NetScaler configuration. It is also best practice to create a back-door super-user account. In the event that the passwords for both accounts cannot be located, the password for the nsroot default account can be recovered. Basic Administration for Citrix NetScaler 9.2

Basic Administration for Citrix NetScaler 9.2

Similar presentations

Presentation on theme: "Basic Administration for Citrix NetScaler 9.2"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Basic Administration for Citrix NetScaler 9.2

Similar presentations

Presentation on theme: "Basic Administration for Citrix NetScaler 9.2"— Presentation transcript:

Similar presentations

About project

Feedback