basic administration for citrix netscaler 9.2. 1. introducing and deploying citrix netscaler 1.1....

of 247/247
Basic Administration for Citrix NetScaler 9.2 Basic Administration for Citrix NetScaler 9.2

Post on 14-Dec-2015

276 views

Category:

Documents

15 download

Embed Size (px)

TRANSCRIPT

  • Slide 1

Basic Administration for Citrix NetScaler 9.2 Slide 2 1. Introducing and Deploying Citrix NetScaler 1.1. Introduction to the NetScaler System 1.1.1. NetScaler Functionality 1.2. Planning a NetScaler Deployment 1.2.1. One-Arm Mode 1.2.2. Two-Arm and Inline Mode 1.3. Deployment Scenarios 1.3.1. Flex Tenancy 1.3.2. Displacement 1.3.3. New Technology 1.4. NetScaler Platform and Product Editions 1.5. Product Features 1.5.1. Lower Total Cost of Ownership 1.5.2. Application Acceleration 1.5.3. Application Security 1.5.4. Application Availability 1.5.5. Simple Manageability 1.5.6. Web 2.0 Optimization 1.6. Hardware Platforms 1.6.1. NetScaler MPX 21500/19500/17500/17000 1.6.2. NetScaler MPX 15500/15000/12500/10500 1.6.3. NetScaler MPX 9500/ 9010 FIPS/MPX 7500/5500/VPX 10/200/1000 1.6.4. nCore 1.6.6. NetScaler VPX 1.7. Hardware Components 1.8. NetScaler Architecture Overview 1.9. Initial NetScaler Access Basic Administration for Citrix NetScaler 9.2 Slide 3 2. Networking 2.1. NetScaler Architecture Overview 2.1.1. Connection Separation 2.1.2. Basic NetScaler System Networking Rules 2.1.3. Multiplexing 2.2. NetScaler-Owned IP Addresses 2.2.1. NetScaler IP Address 2.2.2. Configure a NetScaler IP Address 2.2.3. Subnet IP Address 2.2.4. Mapped IP Address 2.2.5. Virtual IP Address 2.3. NetScaler Modes 2.3.1. Layer-3 Mode 2.3.2. Layer-2 Mode 2.3.3. MAC-Based Forwarding Mode 2.3.4. Use Source IP Mode 2.4. Network Address Translation 2.4.1. NetScaler Supported Network Address Translation Capabilities 2.4.2. Inbound Network Address Translation 2.4.3. Reverse Network Address Translation (RNAT) 2.4.4. IP Addresses for RNAT 2.4.5. Configuring Reverse Network Address Translation 2.5. Virtual Local Area Networks 2.6. Link Aggregation Basic Administration for Citrix NetScaler 9.2 Slide 4 3. Configuring High Availability 3.1. Introduction to High Availability 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 3.2.3. Configuring Primary and Secondary Nodes 3.2.4. High-Availability Status 3.3. Propagation and Synchronization 3.3.1. Disabling Command Propagation 3.3.2. Automatic Configuration Synchronization 3.3.3. Forced Synchronization 3.3.4. Performing a Forced Failover 3.4. High Availability Management 3.4.1. Upgrading a High Availability Pair Basic Administration for Citrix NetScaler 9.2 Slide 5 4. Securing the NetScaler System 4.1. NetScaler System Communication 4.1.1. NetScaler Communication Types 4.1.2. Security Parameter Components 4.2. Access Control Lists 4.2.1. Simple Access Control Lists 4.2.2. Matching Access Control List Entries 4.2.3. Traffic Identification 4.2.4. Access-Control-List Syntax Format and Precedence 4.2.5. Access-Control-Lists Precedence 4.2.6. IPv6-Based Access-Control-List Support 4.3. Access-Control-List Configuration 4.3.1. Simple Access-Control-List Configuration (Command-Line Interface) 4.3.2. Configuring Detailed Access Control Lists (Command-Line Interface) 4.3.3. Creating and Removing Access Control Lists (Command-Line Interface) 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) 4.3.7. Removing Access Control Lists from the System (Command-Line Interface) 4.3.8. Access-Control-List Syntax Format for Different NetScaler Versions Basic Administration for Citrix NetScaler 9.2 Slide 6 5. Configure Load Balancing 5.1. Load-Balancing Process 5.2. Entity Management 5.2.1. Creating Servers 5.2.2. Creating Services 5.2.3. Creating Virtual Servers 5.2.4. Binding Services 5.2.5. Monitors 5.3. Load-Balancing Traffic Types 5.4. Service Monitoring 5.4.1. Binding Monitors 5.4.2 Default Monitors 5.4.3 Monitor Parameters 5.4.4. Creating Monitors 5.4.5. HTTP Monitoring 5.4.6. ECV Monitoring 5.4.7 HTTP-ECV and TCP-ECV Monitoring Process 5.4.8. HTTP-INLINE Parameters 5.4.9. Reverse Condition Monitoring 5.4.10. Setting Monitor Thresholds 5.5. Load-Balancing Topology 5.6. Load-Balancing Methods 5.6.1. Service Weights 5.6.2. Persistent Clients 5.6.3. Session Persistence 5.6.4. Non-Persistent Clients 5.6.5. Persistence Methods 5.6.6. Persistence Tables Basic Administration for Citrix NetScaler 9.2 Slide 7 5.7. Additional Load-Balancing Options 5.8. Advanced Load-Balancing Methods 5.8.1. Token 5.8.2. Hash Load-Balancing 5.9. Link Load Balancing 5.9.1. Link Load-Balancing Policy 5.10. Custom Load 5.11. Load Monitor Process 5.11.1. Load Monitor Parameters 5.11.2. Binding Metrics 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 Basic Administration for Citrix NetScaler 9.2 Slide 8 6. Configuring SSL Offload 6.1. SSL and Digital Certificates 6.2. Important Concepts: SSL 6.3. SSL Offload Overview 6.4. Offload Performance 6.4.1. Features and Benefits 6.5. SSL Administration 6.5.1. Important Concepts: Certificates 6.5.2. SSL Keys 6.5.3. Generating a Certificate Signing Request 6.5.4. SSL Certificates 6.5.5. Generate a Certificate 6.5.6. Certificate Key Pairs 6.5.7. Adding a Certificate Key 6.5.8. Binding a Certificate Key 6.6. SSL Offload 6.6.1. SSL Termination Points 6.7. Deployment Scenarios 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 6.7.8. SSL_Bridge 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 6.10.1. Configuring Advanced Settings Basic Administration for Citrix NetScaler 9.2 Slide 9 7. Configuring Global Server Load Balancing 7.1. GSLB Concepts 7.1.1. GSLB Conversation Process 7.1.2. GSLB Entities 7.2. Metric Exchange Protocol 7.2.1. Metric Information Types 7.2.2. GSLB Monitoring Configuration 7.3. GSLB DNS Methods 7.3.1. Authoritative DNS Service 7.3.2. Name Servers 7.3.3. DNS Request Scenarios 7.3.4. 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 7.8.1. Proximity-Based Load-Balancing Methods 7.9. Implementing GSLB Failover for Disaster Recovery 7.10. Configuring GSLB Virtual Servers 7.10.1. Configuring ADNS 7.10.2. Synchronizing a GSLB Configuration Basic Administration for Citrix NetScaler 9.2 Slide 10 8. Management 8.1. Simple Network Management Protocol 8.1.1. Managed devices 8.1.2. SNMP Agents 8.1.3. Managers 8.1.4. Management Information Base 8.1.5. Community Strings 8.1.6. Traps 8.1.7. Configuring SNMPv1 and SNMPv2 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 8.1.13. Configuring Alarms 8.2. SNMPv3 8.3. Dashboard 8.3.1. System and Feature Counters 8.3.2. 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 8.7.1. Binding Auditing Policy 8.7.2. Audit Messages 8.8. Replacing a High-Availability Node 8.9. Upgrading as a Standalone NetScaler System 8.9.1. Upgrading a High-Availability Pair 8.10. Password Recovery Basic Administration for Citrix NetScaler 9.2 Slide 11 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 Slide 12 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 Slide 13 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 Slide 14 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 Slide 15 1.2.1. 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 Slide 16 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 Slide 17 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 Slide 18 1.3.1. 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 Slide 19 1.3.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 Slide 20 1.3.3. 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 Slide 21 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 Slide 22 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 Slide 23 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 Slide 24 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 Slide 25 1.5.3. 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 Slide 26 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 Slide 27 1.5.5. 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 Slide 28 .. 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 Slide 29 1.5.6. 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 Slide 30 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 Slide 31 1.6.1. 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 Slide 32 1.6.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 Slide 33 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 Slide 34 1.6.4. 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 Slide 35 1.6.6. 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 Slide 36 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 Slide 37 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 Slide 38 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 Slide 39 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 Slide 40 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 Slide 41 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 Slide 42 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 Slide 43 Basic NetScaler System Networking Rules Basic Administration for Citrix NetScaler 9.2 Slide 44 2.1.3. 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 Slide 45 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 Slide 46 2.2.1. 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 192.168.100.1/16 (255.255.0.0). 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 Slide 47 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 Slide 48 2.2.3. 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 -type SNIP -mgmtAccess [Enabled | Disabled] Basic Administration for Citrix NetScaler 9.2 Slide 49 2.2.4. 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 -mgmtAccess [Enabled | Disabled] Basic Administration for Citrix NetScaler 9.2 Slide 50 2.2.5. 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 Slide 51 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 Slide 52 2.3.1. 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 Slide 53 2.3.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 Slide 54 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 Slide 55 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 Slide 56 2.3.3. MAC-Based Forwarding Mode Basic Administration for Citrix NetScaler 9.2 Slide 57 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 Slide 58 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 Slide 59 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 Slide 60 2.3.4. 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 Slide 61 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 Slide 62 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 Slide 63 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 Slide 64 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 Slide 65 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 Slide 66 2.4.3. Reverse Network Address Translation (RNAT) Basic Administration for Citrix NetScaler 9.2 Slide 67 2.4.4. 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 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 Slide 68 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 Slide 69 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 4094. 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 Slide 70 Tagged VLANs Basic Administration for Citrix NetScaler 9.2 Slide 71 VLANs and Tagging with NetScaler VPX Basic Administration for Citrix NetScaler 9.2 Slide 72 Configuring VLANs Basic Administration for Citrix NetScaler 9.2 Slide 73 2.6. Link Aggregation Basic Administration for Citrix NetScaler 9.2 Slide 74 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 Slide 75 Configuring LACP Manually Basic Administration for Citrix NetScaler 9.2 Slide 76 LACP..contd.. Basic Administration for Citrix NetScaler 9.2 Slide 77 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 Slide 78 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 Slide 79 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 Slide 80 3.1.1. High Availability Functionality Basic Administration for Citrix NetScaler 9.2 Slide 81 3.2. High Availability Node Configuration Basic Administration for Citrix NetScaler 9.2 Slide 82 3.2.1. Pre-Configuration Checklist Basic Administration for Citrix NetScaler 9.2 Slide 83 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 Slide 84 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 Slide 85 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 Slide 86 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 Slide 87 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 Slide 88 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 Slide 89 3.3.3. Forced Synchronization Basic Administration for Citrix NetScaler 9.2 Slide 90 3.3.4. Performing a Forced Failover Basic Administration for Citrix NetScaler 9.2 Slide 91 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 Slide 92 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 Slide 93 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 Slide 94 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 Slide 95 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 3011. 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 3011. 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 3008. 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 Slide 96 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 Slide 97 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 Slide 98 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 Slide 99 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 Slide 100 4.2.3. Traffic Identification Basic Administration for Citrix NetScaler 9.2 Slide 101 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.Command Reference Guide Basic Administration for Citrix NetScaler 9.2 Slide 102 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 Slide 103 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 Slide 104 4.3. Access-Control-List Configuration Basic Administration for Citrix NetScaler 9.2 Slide 105 4.3.1. Simple Access-Control-List Configuration (Command-Line Interface) Basic Administration for Citrix NetScaler 9.2 Slide 106 4.3.2. Configuring Detailed Access Control Lists (Command-Line Interface) Basic Administration for Citrix NetScaler 9.2 Slide 107 4.3.3. Creating and Removing Access Control Lists (Command-Line Interface) Basic Administration for Citrix NetScaler 9.2 Slide 108 4.3.4. Applying Access Control Lists (Command-Line Interface) Basic Administration for Citrix NetScaler 9.2 Slide 109 4.3.5. Viewing Access Control Lists (Command-Line Interface) Basic Administration for Citrix NetScaler 9.2 Slide 110 4.3.6. Access-Control-List Priorities (Command-Line Interface) Basic Administration for Citrix NetScaler 9.2 Slide 111 4.3.7. Removing Access Control Lists from the System (Command-Line Interface) Basic Administration for Citrix NetScaler 9.2 Slide 112 4.3.8. 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 Slide 113 Access-Control-List Example Basic Administration for Citrix NetScaler 9.2 Slide 114 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 Slide 115 5.1. Load-Balancing Process Basic Administration for Citrix NetScaler 9.2 Slide 116 5.2. Entity Management Basic Administration for Citrix NetScaler 9.2 Slide 117 Entity Management.. Contd.. Basic Administration for Citrix NetScaler 9.2 Slide 118 5.2.1. Creating Servers Basic Administration for Citrix NetScaler 9.2 Slide 119 5.2.2. Creating Services Basic Administration for Citrix NetScaler 9.2 Slide 120 5.2.3. Creating Virtual Servers Basic Administration for Citrix NetScaler 9.2 Slide 121 5.2.4. Binding Services Basic Administration for Citrix NetScaler 9.2 Slide 122 5.2.5. 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 Slide 123 5.3. Load-Balancing Traffic Types Basic Administration for Citrix NetScaler 9.2 Slide 124 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 Slide 125 5.4.1. Binding Monitors Basic Administration for Citrix NetScaler 9.2 Slide 126 5.4.2 Default Monitors Basic Administration for Citrix NetScaler 9.2 Slide 127 5.4.3 Monitor Parameters Basic Administration for Citrix NetScaler 9.2 Slide 128 Monitor parameters.. Contd.. Basic Administration for Cit