Citrix Branch Repeater User Guide

Citrix Branch Repeater Family Installation and Users Guide
Release 6.0
Citrix Systems, Inc.
CITRIX SYSTEMS, INC., 2011. ALL RIGHTS RESERVED. NO PART OF THIS DOCUMENT MAY BE REPRODUCED OR TRANSMITTED IN ANY FORM OR BY ANY MEANS OR USED TO MAKE DERIVATIVE WORK (SUCH AS TRANSLATION, TRANSFORMATION, OR ADAPTATION) WITHOUT THE EXPRESS WRITTEN PERMISSION OF CITRIX SYSTEMS, INC. Citrix, Citrix Systems, Repeater, Branch Repeater, WANScaler, Orbital Data, Orbital 5500, Orbital 6500, Orbital 6800, TotalTransport, AutoOptimizer Engine, and Adaptive Rate Control are trademarks of Citrix Corporation Citrix Systems assumes no responsibility for errors in this document, and retains the right to make changes at any time, without notice.
Portions licensed under the Apache License, Version 2.0 http://www.apache.org/ licenses/LICENSE-2.0. Portions licensed under the Gnu Public License, http://www.gnu.org/copyleft/gpl.html, including xmlrpc++, glibc, rpm-libs, beecrypt. Portions licensed under the Gnu Public License with product-specific clauses, including the Linux kernel (http://www.kernel.org/pub/linux/kernel/COPYING), libstdc++, and libgcc. Portions are free software with vendor-specific licensing, including zlib (http:// www.gzip.org/zlib/zlib_license.html), net-snmp (http://www.net-snmp.org/about/ license.html), openssl (http://www.openssl.org/source/license.html), krb5-libs (http:/ /web.mit.edu/kerberos/krb5-1.3/krb5-1.3.6/doc/krb5-install.html), tcp_wrappers (ftp://ftp.porcupine.org/pub/security/tcp_wrappers_license), bzip2-libs (http:// sources.redhat.com/bzip2/), popt (http://directory.fsf.org/libs/COPYING.DOC). Elfutils-libelf is licensed under the OSL 1.0 license, http://www.opensource.org. JPGraph licensed under the terms given in http://www.aditus.nu/jpgraph/ proversion.php LZS licensed from Hifn corporation, http://www.hifn.com. Iperf licensed under the terms given in http://dast.nlanr.net/Projects/Iperf/ ui_license.html. This product includes PHP, freely available from http://www.php.net/.
Need help? Contact Citrix Support. See Section 10.1.
Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1.1 - Branch Repeater Product Line . . . . . . . . . . 1.2 - Who Should Read This Guide . . . . . . . . . . . 1.3 - What Is In This Guide . . . . . . . . . . . . . . . . 1.4 - Terminology . . . . . . . . . . . . . . . . . . . . . . 1.5 - Note About Screen Captures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1 . . . . . . . . . . . . . . . . .1-2 . . . . . . . . . . . . . . . . .1-3 . . . . . . . . . . . . . . . . .1-3 . . . . . . . . . . . . . . . . .1-3 . . . . . . . . . . . . . . . . .1-3
2 Appliance Deployment Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1 2.1 - Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1 2.2 - Product Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-2 2.3 - Selecting a Deployment Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-3 2.3.1 - Use Inline Mode When Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-3 2.3.2 - WAN-Router-Based Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-4 2.3.3 - Deployment Mode Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-5 2.3.3.1 - Forwarding Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-5 2.3.3.2 - High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-7 2.3.3.3 - Acceleration Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-7 2.4 - Forwarding Loop Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-7 2.5 - Guidelines for Sites With Multiple WAN Routers . . . . . . . . . . . . . . . . . . . . .2-8 2.5.1 - Solving the Problem With Appliances . . . . . . . . . . . . . . . . . . . . . . . . . .2-8 2.5.2 - Mixing Modes Within a Single Appliance . . . . . . . . . . . . . . . . . . . . . . . 2-10 2.5.3 - Solving the Problem in the Router . . . . . . . . . . . . . . . . . . . . . . . . . . .2-11 2.6 - Deploying to Support VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12 2.6.1 - Supporting Repeater Plug-in With Citrix Access Gateway VPNs . . . . . . . 2-13 2.6.1.1 - Configuring Access Gateway Standard Edition Support . . . . . . . . . .2-13 2.7 - Supporting Repeater Plug-in With One-Armed Redirector Mode (Not Recommended) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15 3 Installing the Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1 3.1 - Installation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1 3.2 - Pre-Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1 3.3 - Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3 3.3.1 - Install the Appliance Into the Rack . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3 3.3.2 - Install Ethernet Cables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3 3.3.3 - Turn on the Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-7 3.3.4 - Perform Initial Configuration Via the Front Panel . . . . . . . . . . . . . . . . . .3-7 3.3.5 - Browser-Based Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8 3.3.6 - Quick Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-9 3.3.7 - Configure the High-Availability Pair . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11 3.3.8 - Set Hardboost Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12 3.3.9 - Check Service Class Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13 3.3.10 - Configure Repeater Plug-in Support . . . . . . . . . . . . . . . . . . . . . . . . . 3-14 3.3.11 - (WCCP Only) Enable WCCP Mode and Configure Router . . . . . . . . . . . 3-15 3.3.12 - (Virtual Inline Only) Enable Virtual Inline Mode and Configure Router . 3-15 3.3.13 - Security: Change the Admin Password . . . . . . . . . . . . . . . . . . . . . . . 3-15 3.3.14 - Disable Encryption on Outlook 2007 Clients . . . . . . . . . . . . . . . . . . . 3-15 3.4 - Testing the Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16 3.5 - Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17
Branch Repeater Family Installation and Users Guide i
3.5.1 - Cabling and Duplexing Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17 3.5.2 - Cant Connect in Virtual Inline Mode . . . . . . . . . . . . . . . . . . . . . . . . . 3-18 3.5.3 - Compressed Throughput is No Greater than Uncompressed Throughput 3-18 3.5.4 - No Transfers are Accelerated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18 3.5.4.1 - TCP Option Usage and Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18 3.5.5 - Windows Filesystem (CIFS) Transfers Are Not Accelerated . . . . . . . . . . 3-19 3.5.6 - Accelerated Connections Run, then Hang . . . . . . . . . . . . . . . . . . . . . . 3-20 3.5.7 - Contact Us . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-20 3.6 - Licensing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20 3.6.1 - Log Into My Citrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21 3.6.2 - Exchanging Licenses From Pre-Release-5.02.0 Appliances . . . . . . . . . .3-21 3.6.3 - Obtaining a License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23 3.6.4 - Licensing Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-24 3.7 - Check Converted Service Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24 4 Theory of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1 4.1 - In This Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1 4.2 - How Acceleration Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1 4.2.1 - Virtual Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1 4.2.2 - Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2 4.2.3 - Lossless, Transparent Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2 4.2.4 - Fair Queuing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3 4.2.5 - WAN Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4 4.2.5.1 - Transactional Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5 4.3 - Acceleration Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6 4.3.1 - Bandwidth Management Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6 4.3.2 - How the Appliance Allocates Bandwidth . . . . . . . . . . . . . . . . . . . . . . . .4-6 4.3.3 - An Appliance Should Become The Bottleneck Gateway. . . . . . . . . . . . . .4-7 4.3.4 - Performance Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-8 4.4 - Link Definitions and Traffic Shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-8 4.4.1 - Comparison with Release 5.x QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9 4.4.2 - Traffic Shaping Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9 4.4.3 - Configuring Traffic Shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10 4.4.4 - Defining a Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11 4.4.4.1 - What is a Link?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-12 4.4.4.2 - Information Needed to Define a Link. . . . . . . . . . . . . . . . . . . . . . . 4-12 4.4.4.3 - Defining a Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-13 4.4.4.4 - Example: Simple Inline Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14 4.4.4.5 - Example: Inline Deployment with Dual Bridges . . . . . . . . . . . . . . . 4-16 4.4.4.6 - Example: Using IP Addresses in Link Definitions. . . . . . . . . . . . . . . 4-17 4.4.4.7 - Example: WCCP and Virtual Inline Modes . . . . . . . . . . . . . . . . . . . 4-18 4.4.4.8 - Example: Inline with One Bridge and Two WAN Links . . . . . . . . . . . 4-18 4.5 - Service Class Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20 4.5.0.1 - Differences Between Acceleration Policies and Traffic Shaping Policies . . 4-20 4.5.0.2 - Using Service Class Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21 4.6 - Traffic Shaping Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-22 4.6.1 - XenApp/XenDesktop Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23 4.7 - Application Classifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-25 4.8 - Ethernet Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26 4.8.1 - Bridged Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-27
ii June 26, 2011
4.8.2 - Motherboard Ports . . . . . . . . . . . . . . . . . . . . . . . 4.8.3 - Port Parameters . . . . . . . . . . . . . . . . . . . . . . . . 4.8.4 - The Primary Port . . . . . . . . . . . . . . . . . . . . . . . . 4.8.5 - The Aux1 Port . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8.6 - Using Multiple Bridges . . . . . . . . . . . . . . . . . . . . 4.9 - Autodiscovery and Autoconfiguration . . . . . . . . . . . . 4.9.1 - Firewall Considerations . . . . . . . . . . . . . . . . . . . 4.10 - Forwarding Modes . . . . . . . . . . . . . . . . . . . . . . . . 4.11 - Inline Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11.1 - Accelerating an Entire WAN . . . . . . . . . . . . . . . 4.11.2 - Accelerating Some Systems But Not Others . . . . 4.12 - Redirector Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12.1 - How it Works . . . . . . . . . . . . . . . . . . . . . . . . . 4.12.2 - Configuring Redirector Mode . . . . . . . . . . . . . . . 4.13 - WCCP Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13.1 - How it Works . . . . . . . . . . . . . . . . . . . . . . . . . 4.13.2 - Performance . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13.3 - Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13.4 - Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . 4.13.5 - Router Support for WCCP . . . . . . . . . . . . . . . . . 4.13.6 - Redirection Strategies . . . . . . . . . . . . . . . . . . . 4.13.7 - Router Configuration . . . . . . . . . . . . . . . . . . . . 4.13.8 - Appliance Configuration . . . . . . . . . . . . . . . . . . 4.13.9 - Service Group Configuration Details. . . . . . . . . . 4.13.10 - Testing and Troubleshooting . . . . . . . . . . . . . . 4.14 - Virtual Inline Mode . . . . . . . . . . . . . . . . . . . . . . . . 4.14.1 - How Virtual Inline Mode Works . . . . . . . . . . . . . 4.14.1.1 - Example . . . . . . . . . . . . . . . . . . . . . . . . . . 4.14.2 - Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 4.14.2.1 - How the Appliance Forwards Packets. . . . . . . 4.14.3 - The Need for Policy-Based Rules . . . . . . . . . . . . 4.14.4 - Health Monitoring . . . . . . . . . . . . . . . . . . . . . . 4.14.5 - Routing Examples . . . . . . . . . . . . . . . . . . . . . . 4.14.6 - Virtual Inline Mode For Multi-WAN Environments . 4.14.7 - Virtual Inline Mode and High Availability. . . . . . . 4.15 - Group Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.15.1 - When to Use Group Mode . . . . . . . . . . . . . . . . . 4.15.1.1 - Alternatives to Group Mode . . . . . . . . . . . . . 4.15.2 - How Group Mode Works . . . . . . . . . . . . . . . . . . 4.15.3 - Owner Selection . . . . . . . . . . . . . . . . . . . . . . . 4.15.3.1 - IP-Based Ownership Rules . . . . . . . . . . . . . . 4.15.3.2 - Failure Modes . . . . . . . . . . . . . . . . . . . . . . . 4.15.4 - Setting the Bandwidth Limit . . . . . . . . . . . . . . . 4.15.5 - Enabling Group Mode . . . . . . . . . . . . . . . . . . . . 4.15.6 - Setting Forwarding Rules . . . . . . . . . . . . . . . . . 4.16 - Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.16.1 - XenApp/XenDesktop Acceleration . . . . . . . . . . . 4.16.2 - How Compression Works . . . . . . . . . . . . . . . . . 4.16.2.1 - Memory-Based Compression . . . . . . . . . . . . 4.16.2.2 - Disk-Based Compression . . . . . . . . . . . . . . . 4.16.3 - Enabling/Disabling Compression . . . . . . . . . . . .
Branch Repeater Family Installation and Users Guide
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.4-27 . 4-27 . 4-28 . 4-28 . 4-28 . 4-29 . 4-29 . 4-30 . 4-32 . 4-33 . 4-33 . 4-34 . 4-34 . 4-35 . 4-36 . 4-36 . 4-37 . 4-37 . 4-37 . 4-38 .4-38 .4-38 .4-39 . 4-40 . 4-41 . 4-42 . 4-42 . 4-43 . 4-43 . 4-43 . 4-44 .4-44 . 4-46 .4-48 . 4-48 . 4-49 . 4-50 . 4-50 . 4-51 . 4-52 . 4-53 .4-53 . 4-53 . 4-54 .4-55 .4-56 . 4-57 .4-59 . 4-59 . 4-59 . 4-60
iii
4.16.4 - Measuring Disk-Based Compression Performance . . 4.16.4.1 - Testing LAN performance with Iperf . . . . . . . . . 4.16.4.2 - Using FTP for initial testing . . . . . . . . . . . . . . . 4.17 - CIFS (Windows Filesystem) Acceleration . . . . . . . . . . . 4.17.1 - CIFS Security and Acceleration . . . . . . . . . . . . . . . 4.17.2 - Interpreting CIFS Statistics. . . . . . . . . . . . . . . . . . 4.17.3 - CIFS Management Summary. . . . . . . . . . . . . . . . . 4.18 - Microsoft Outlook (MAPI) Acceleration . . . . . . . . . . . . 4.18.1 - Supported Outlook/Exchange Versions and Modes . . 4.18.2 - Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.18.2.1 - Disabling Encryption on Outlook 2007 . . . . . . . . 4.18.2.2 - Performance Note . . . . . . . . . . . . . . . . . . . . . . 4.19 - Joining a Windows Domain (CIFS/MAPI Enhancements) 4.19.1 - Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.19.2 - Joining the Windows Domain . . . . . . . . . . . . . . . . 4.20 - SSL Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.20.1 - How SSL Compression Works . . . . . . . . . . . . . . . . 4.20.2 - SSL Transparent Proxy and Split Proxy Modes. . . . . 4.20.2.1 - SSL Split Proxy. . . . . . . . . . . . . . . . . . . . . . . . 4.20.2.2 - SSL Transparent Proxy . . . . . . . . . . . . . . . . . . 4.20.3 - Generating Security Keys and Certificates . . . . . . . 4.20.4 - Configuring SSL Compression . . . . . . . . . . . . . . . . 4.20.4.1 - Configuring the Appliance . . . . . . . . . . . . . . . . 4.20.5 - Using SSL Compression on the Repeater Plug-in . . . 4.21 - Additional Features. . . . . . . . . . . . . . . . . . . . . . . . . . 4.22 - Proxy Mode (Legacy Feature). . . . . . . . . . . . . . . . . . . 4.22.0.1 - Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.22.0.2 - Proxy Mode Topologies . . . . . . . . . . . . . . . . . . 4.22.0.3 - VIP-to-VIP Proxies . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 4-61 .4-62 . 4-62 .4-63 . 4-64 .4-66 . 4-67 . 4-67 . 4-67 . 4-67 . 4-68 . 4-68 . 4-70 . 4-70 . 4-70 . 4-72 . 4-73 . 4-73 . 4-73 . 4-74 . 4-75 . 4-75 . 4-75 .4-82 . 4-82 . 4-83 . 4-83 . 4-86 . 4-87
5 The Repeater Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1 5.1 - About the Repeater Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1 5.1.1 - Acceleration Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2 5.1.2 - Supported Plug-in Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2 5.1.3 - Theory of Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3 5.1.4 - Detailed Description of Transparent Mode . . . . . . . . . . . . . . . . . . . . . .5-4 5.1.4.1 - Packet Flow in Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . .5-6 5.1.5 - Detailed Description of Redirector Mode . . . . . . . . . . . . . . . . . . . . . . . .5-7 5.1.6 - How the Plug-in Selects an Appliance . . . . . . . . . . . . . . . . . . . . . . . . .5-8 5.2 - Deploying Appliances for Use With Plug-ins . . . . . . . . . . . . . . . . . . . . . . . .5-9 5.2.1 - Use a Dedicated Appliance Where Practical. . . . . . . . . . . . . . . . . . . . . .5-9 5.2.2 - Use Inline Mode When Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-9 5.2.3 - Put the Appliances in a Secure Part of your Network . . . . . . . . . . . . . . 5-10 5.2.4 - Avoid NAT Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10 5.2.5 - Select Softboost Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10 5.2.6 - Define Plug-in Acceleration Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10 5.2.6.1 - Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11 5.2.7 - Port Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-12 5.2.8 - TCP Option Usage and Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12 5.2.9 - Compatibility Issue with Pre-Release-4.3 Appliances . . . . . . . . . . . . . . 5-12 5.3 - Deploying Plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
iv June 26, 2011
5.3.1 - Customizing the Plug-in MSI File . . . . . 5.3.2 - Using Customized Plug-in Software . . . 5.3.3 - Installation . . . . . . . . . . . . . . . . . . . . 5.3.4 - Installation Troubleshooting . . . . . . . . 5.3.5 - Running the Plug-in For the First Time . 5.4 - Testing the Installation . . . . . . . . . . . . . . 5.5 - Troubleshooting Plug-ins . . . . . . . . . . . . . 5.6 - Repeater Plug-in Command Reference . . . 5.6.1 - Configuration Tab . . . . . . . . . . . . . . . 5.6.2 - Performance Tab . . . . . . . . . . . . . . . . 5.6.3 - Diagnostics Tab. . . . . . . . . . . . . . . . . 5.6.4 - Certificates Tab . . . . . . . . . . . . . . . 5.6.5 - Uninstalling the Repeater Plug-in . . . . 5.6.6 - Updating the Repeater Plug-in . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. 5-13 . 5-16 . 5-17 . 5-18 . 5-20 . 5-22 . 5-22 . 5-23 . 5-23 . 5-25 . 5-26 . 5-28 . 5-29 . 5-29
6 Branch Repeater VPX . . . . . . . . . . . . . . . . . . . . . . . 6.1 - About Branch Repeater VPX . . . . . . . . . . . . . . . . . 6.1.1 - Uses For Branch Repeater VPX . . . . . . . . . . . . . 6.1.2 - Other Branch Repeater VPX Features . . . . . . . . . 6.2 - Differences Between VPX and Repeater . . . . . . . . . 6.3 - System Requirements and Provisioning. . . . . . . . . . 6.3.1 - Supported Configurations . . . . . . . . . . . . . . . . . 6.3.1.1 - Minimum Resource Requirements . . . . . . . . . 6.3.1.2 - Maximum Resources . . . . . . . . . . . . . . . . . . 6.3.2 - Resource Usage Notes . . . . . . . . . . . . . . . . . . . 6.4 - Virtual Ethernet Ports . . . . . . . . . . . . . . . . . . . . . . 6.5 - Upgrading a Previous Installation . . . . . . . . . . . . . . 6.6 - Initial Installation, XenServer . . . . . . . . . . . . . . . . 6.6.1 - Install XenServer and XenCenter. . . . . . . . . . . . 6.6.2 - Install Licenses on the Citrix License Server . . . . 6.6.3 - Install the Branch Repeater VPX Virtual Machine . 6.7 - Initial Installation, VMware vSphere . . . . . . . . . . . . 6.7.1 - Configuring Advanced VMware Features . . . . . . . 6.7.1.1 - VLAN Support . . . . . . . . . . . . . . . . . . . . . . 6.7.1.2 - Larger Disks . . . . . . . . . . . . . . . . . . . . . . . 6.7.1.3 - VMware Guest Customization . . . . . . . . . . . . 6.7.2 - VMware Guest Customization Procedure. . . . . . . 6.8 - Additional Configuration . . . . . . . . . . . . . . . . . . . . 7 Cabling and Physical Deployment. . . . . . . . . . . . 7.1 - Power On/Off. . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 - Ethernet Issues . . . . . . . . . . . . . . . . . . . . . . . . 7.2.1 - Gigabit Ethernet Networks . . . . . . . . . . . . . . 7.2.2 - Fast Ethernet (100 Mbps) Networks. . . . . . . . 7.2.2.1 - Connector Polarity and Cross-Over Cables . 7.2.2.2 - Fast Ethernet Auto-Negotiation Failures . . 7.2.2.3 - Older Fast Ethernet Equipment. . . . . . . . . 7.2.3 - 10BaseT (10 Mbps) Ethernet . . . . . . . . . . . . 7.2.4 - Ethernet Bypass . . . . . . . . . . . . . . . . . . . . . 7.3 - VLAN Support . . . . . . . . . . . . . . . . . . . . . . . . . 7.4 - What Happens if the Appliance Fails . . . . . . . . . .
. . . . . . . . . . . . . . . .6-1 . . . . . . . . . . . . . . . .6-1 . . . . . . . . . . . . . . . .6-1 . . . . . . . . . . . . . . . .6-4 . . . . . . . . . . . . . . . .6-5 . . . . . . . . . . . . . . . .6-6 . . . . . . . . . . . . . . . .6-6 . . . . . . . . . . . . . . . .6-6 . . . . . . . . . . . . . . . .6-7 . . . . . . . . . . . . . . . .6-7 . . . . . . . . . . . . . . . .6-8 . . . . . . . . . . . . . . . .6-8 . . . . . . . . . . . . . . . .6-9 . . . . . . . . . . . . . . . .6-9 . . . . . . . . . . . . . . . .6-9 . . . . . . . . . . . . . . . .6-9 . . . . . . . . . . . . . . . 6-18 . . . . . . . . . . . . . . . 6-36 . . . . . . . . . . . . . . . 6-36 . . . . . . . . . . . . . . . 6-38 . . . . . . . . . . . . . . . 6-40 . . . . . . . . . . . . . . . 6-41 . . . . . . . . . . . . . . . 6-44 . . . . . . . . . . . . . . . .7-1 . . . . . . . . . . . . . . . .7-1 . . . . . . . . . . . . . . . .7-1 . . . . . . . . . . . . . . . .7-1 . . . . . . . . . . . . . . . .7-1 . . . . . . . . . . . . . . . .7-1 . . . . . . . . . . . . . . . .7-2 . . . . . . . . . . . . . . . .7-3 . . . . . . . . . . . . . . . .7-3 . . . . . . . . . . . . . . . .7-3 . . . . . . . . . . . . . . . .7-4 . . . . . . . . . . . . . . . .7-4
v
. . . . . . . . . . . .
. . . . . . . . . . . .
7.4.1 - Inline Mode . . . . . . . . . . . . . . . . . . . . . . . . 7.4.2 - WCCP Mode . . . . . . . . . . . . . . . . . . . . . . . . 7.4.3 - Virtual Inline Mode . . . . . . . . . . . . . . . . . . . 7.4.4 - Group Mode . . . . . . . . . . . . . . . . . . . . . . . . 7.4.5 - High-Availability Mode . . . . . . . . . . . . . . . . . 7.4.6 - Redirector Mode . . . . . . . . . . . . . . . . . . . . . 7.5 - High-Availability Mode . . . . . . . . . . . . . . . . . . . 7.5.1 - Requirements . . . . . . . . . . . . . . . . . . . . . . . 7.5.2 - How High Availability Works . . . . . . . . . . . . . 7.5.3 - HA Virtual Address . . . . . . . . . . . . . . . . . . . 7.5.4 - Enabling/Disabling High-Availability Mode . . . 7.5.5 - Updating Software for a High-Availability Pair . 7.5.6 - Saving/Restoring Parameters in the HA Pair . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
.7-4 .7-4 .7-4 .7-5 .7-5 .7-5 .7-5 .7-6 .7-6 .7-7 .7-7 .7-7 .7-7
8 Configuration Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1 8.1 - Logging Into the UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1 8.2 - Command Menu Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2 8.2.1 - Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2 8.2.1.1 - Aggregate Link Throughput Graph . . . . . . . . . . . . . . . . . . . . . . . .8-2 8.2.1.2 - Appliance Status Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3 8.2.1.3 - Top Applications by WAN Volume Graph . . . . . . . . . . . . . . . . . . . .8-3 8.2.1.4 - Top Service Classes by Compression Ratio Graph . . . . . . . . . . . . .8-3 8.2.1.5 - Top ICA/CGP Applications by WAN Volume Graph . . . . . . . . . . . . .8-3 8.2.1.6 - Traffic Shaping: WAN Throughput Graph . . . . . . . . . . . . . . . . . . .8-3 8.2.2 - Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4 8.2.2.1 - Traffic Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4 8.2.2.2 - Traffic Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4 8.2.2.3 - Traffic Shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4 8.2.2.4 - CIFS Protocol Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4 8.2.2.5 - Group Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4 8.2.2.6 - High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-5 8.2.2.7 - ICA Multi-Stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-5 8.2.2.8 - MAPI Cross-Protocol Optimization . . . . . . . . . . . . . . . . . . . . . . . . . .8-5 8.2.2.9 - SCPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-5 8.2.2.10 - Secure Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-5 8.2.2.11 - SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-5 8.2.2.12 - SSH Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-5 8.2.2.13 - SSL Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-5 8.2.2.14 - Syslog Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-6 8.2.2.15 - User Data Store Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-6 8.2.2.16 - WCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-6 8.2.3 - Quick Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-6 8.2.4 - Logout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-8 8.3 - Monitoring Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-8 8.3.1 - Monitoring: Citrix (ICA/CGP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-8 8.3.1.1 - ICA Connections Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-8 8.3.1.2 - ICA Statistics Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-9 8.3.1.3 - Acceleration Graphs Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10 8.3.2 - Monitoring: Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-11 8.3.3 - Monitoring: Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-12 8.3.3.1 - Selecting Which Accelerated Connections to Show . . . . . . . . . . . . . 8-13
vi June 26, 2011
8.3.3.2 - Unaccelerated Connections Tab . . . . . 8.3.3.3 - Connection Details Page . . . . . . . . . . . 8.3.3.4 - Flow Information . . . . . . . . . . . . . . . . 8.3.4 - Monitoring: Filesystem (CIFS/SMB). . . . . 8.3.4.1 - Acceleration Graphs Tab . . . . . . . . . . 8.3.4.2 - Connections Tab . . . . . . . . . . . . . . . 8.3.5 - Monitoring: Logging . . . . . . . . . . . . . . . 8.3.6 - Monitoring: Outlook (MAPI) . . . . . . . . . . 8.3.6.1 - Acceleration Graphs . . . . . . . . . . . . . . 8.3.6.2 - Accelerated Sessions . . . . . . . . . . . . . 8.3.6.3 - Unaccelerated Sessions . . . . . . . . . . . . 8.3.7 - Monitoring: Repeater Plug-ins . . . . . . . . 8.3.8 - Monitoring: Secure Partners. . . . . . . . . . 8.3.9 - Monitoring: Usage Graph . . . . . . . . . . . . 8.3.10 - Monitoring: WCCP . . . . . . . . . . . . . . . . 8.4 - Configuration Pages . . . . . . . . . . . . . . . . . . 8.4.1 - Configuration: Administrator Interface . . 8.4.1.1 - Web Access Tab. . . . . . . . . . . . . . . . 8.4.1.2 - HTTPS Certificate Tab . . . . . . . . . . . . 8.4.1.3 - User Accounts Tab . . . . . . . . . . . . . . 8.4.1.4 - RADIUS and TACACS+ Tabs . . . . . . 8.4.1.5 - SSH Access Tab . . . . . . . . . . . . . . . . 8.4.1.6 - Graphing Tab . . . . . . . . . . . . . . . . . 8.4.1.7 - Miscellaneous Tab . . . . . . . . . . . . . . 8.4.2 - Configuration: Advanced Deployments . . 8.4.2.1 - WCCP Configuration Tab . . . . . . . . . . 8.4.2.2 - High Availability (HA) Tab . . . . . . . . . 8.4.2.3 - HA Partner Info Tab . . . . . . . . . . . . . 8.4.2.4 - HA VIP Address Tab . . . . . . . . . . . . . 8.4.2.5 - Group Mode Tab . . . . . . . . . . . . . . . 8.4.2.6 - HA/Group Mode SSL Certificates Tab . 8.4.2.7 - Proxy Tab . . . . . . . . . . . . . . . . . . . . 8.4.3 - Configuration: Application Classifiers. . . . 8.4.4 - Configuration: Licensing . . . . . . . . . . . . 8.4.4.1 - License Information Tab . . . . . . . . . . 8.4.4.2 - License Server Tab. . . . . . . . . . . . . . 8.4.4.3 - Local Licenses Tab . . . . . . . . . . . . . . 8.4.4.4 - Licensed Features Tab . . . . . . . . . . . 8.4.5 - Configuration: Links . . . . . . . . . . . . . . . 8.4.5.1 - Link Definition Tab . . . . . . . . . . . . . . 8.4.5.2 - The Create Link and Edit Link Forms 8.4.5.3 - Hardboost/Softboost Tab . . . . . . . . . 8.4.5.4 - Traffic Shaping Tab . . . . . . . . . . . . . 8.4.6 - Configuration: Network Adapters . . . . . . 8.4.6.1 - IP Addresses Tab . . . . . . . . . . . . . . . 8.4.6.2 - Accelerated Pairs . . . . . . . . . . . . . . . . 8.4.6.3 - Address Formats . . . . . . . . . . . . . . . . 8.4.6.4 - HA Virtual IP Addresses. . . . . . . . . . . . 8.4.6.5 - Web Management Access . . . . . . . . . . 8.4.6.6 - VLAN Settings . . . . . . . . . . . . . . . . . . 8.4.6.7 - Ethernet Tab . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 8-14 . 8-15 . 8-18 . 8-20 . 8-20 . 8-21 . 8-22 . 8-22 . 8-22 . 8-23 . 8-24 . 8-24 .8-25 .8-26 . 8-28 .8-29 . 8-29 . 8-30 . 8-30 . 8-31 . 8-32 . 8-33 . 8-33 . 8-34 . 8-35 . 8-35 . 8-37 . 8-38 . 8-38 . 8-39 .8-40 . 8-40 . 8-45 .8-46 . 8-47 . 8-47 . 8-48 . 8-49 . 8-49 . 8-49 . 8-50 . 8-51 . 8-51 . 8-52 . 8-52 . 8-52 . 8-53 . 8-53 . 8-53 . 8-53 .8-54
vii
8.4.6.8 - Detailed Adapter Information . . . . . . . 8.4.7 - Configuration: Logging/Monitoring . . . . 8.4.7.1 - Log Options Tab. . . . . . . . . . . . . . . 8.4.7.2 - Log Extraction Tab . . . . . . . . . . . . . 8.4.7.3 - Log Statistics Tab . . . . . . . . . . . . . 8.4.7.4 - Log Removal Tab . . . . . . . . . . . . . . 8.4.7.5 - Alert Options Tab . . . . . . . . . . . . . . 8.4.7.6 - Syslog Server Tab . . . . . . . . . . . . . 8.4.7.7 - SNMP Tab . . . . . . . . . . . . . . . . . . . 8.4.7.8 - Installing the SNMP MIB Files. . . . . . . 8.4.8 - Configuration: Repeater Plug-ins . . . . . 8.4.8.1 - Signaling Channel Configuration Tab 8.4.8.2 - Acceleration Rules Tab . . . . . . . . . . 8.4.8.3 - Best Practices With Acceleration Rules 8.4.8.4 - General Configuration Tab . . . . . . . 8.4.9 - Configuration: Secure Partners. . . . . . . 8.4.10 - Configuration: Service Classes . . . . . . 8.4.10.1 - Service Class Definition Tab . . . . . 8.4.10.2 - Traffic Shaping Tab . . . . . . . . . . . 8.4.11 - Configuration: SSL Acceleration . . . . . 8.4.12 - Configuration: SSL Encryption . . . . . . 8.4.13 - Configuration: Traffic Shaping Policies . 8.4.13.1 - Creating and Editing Policies . . . . . . 8.4.14 - Configuration: Tuning . . . . . . . . . . . . 8.4.14.1 - Window Settings. . . . . . . . . . . . . . . 8.4.14.2 - Connection Timeout . . . . . . . . . . . . 8.4.14.3 - Special Ports . . . . . . . . . . . . . . . . . 8.4.14.4 - Privileged Ephemeral Ports . . . . . . . 8.4.14.5 - Virtual Inline . . . . . . . . . . . . . . . . . 8.4.14.6 - Daisy-Chain . . . . . . . . . . . . . . . . . . 8.4.14.7 - TCP Maximum Segment Size (MSS) . 8.4.14.8 - Forwarding Loop Prevention . . . . . . . 8.4.14.9 - Legacy CIFS Protocol Filtering . . . . . 8.4.14.10 - Generic Settings . . . . . . . . . . . . . . 8.4.15 - Configuration: Windows Domain . . . . . 8.5 - Reports Pages . . . . . . . . . . . . . . . . . . . . . 8.5.1 - Reports: Compression . . . . . . . . . . . . . 8.5.1.1 - Compression Graphs Tab . . . . . . . . 8.5.1.2 - Compression Status Tab . . . . . . . . . 8.5.2 - Reports: LAN vs. WAN. . . . . . . . . . . . . 8.5.3 - Reports: Link Usage . . . . . . . . . . . . . . 8.5.4 - Reports: Service Classes . . . . . . . . . . . 8.5.5 - Reports: Top Applications . . . . . . . . . . 8.5.5.1 - Historical Graphs . . . . . . . . . . . . . . . 8.5.5.2 - Active Applications Tab . . . . . . . . . . 8.5.6 - Reports: Traffic Shaping . . . . . . . . . . . 8.6 - System Maintenance Pages. . . . . . . . . . . . 8.6.1 - System Maintenance: Backup/Restore. . 8.6.2 - System Maintenance: Clear Statistics . . 8.6.3 - System Maintenance: Date/Time . . . . . 8.6.4 - System Maintenance: Diagnostics. . . . .
viii
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 8-54 . 8-56 . 8-57 . 8-58 . 8-58 . 8-59 . 8-59 . 8-61 . 8-62 .8-63 . 8-63 .8-64 . 8-65 .8-65 . 8-66 . 8-67 . 8-68 . 8-68 .8-71 . 8-71 . 8-72 . 8-73 . 8-74 . 8-75 . 8-76 . 8-76 . 8-76 .8-77 . 8-77 . 8-77 .8-78 . 8-78 . 8-78 . 8-78 . 8-79 . 8-80 . 8-80 . 8-80 . 8-81 . 8-82 . 8-83 . 8-84 . 8-85 . 8-85 . 8-86 .8-87 . 8-88 . 8-88 . 8-88 . 8-89 . 8-90
June 26, 2011
8.6.4.1 - Tracing Tab . . . . . . . . . . . . . . . . . . 8.6.4.2 - Bypass Card Test Tab . . . . . . . . . . . 8.6.4.3 - Retrieve Cores Tab. . . . . . . . . . . . . 8.6.4.4 - Line Tester Tab . . . . . . . . . . . . . . . 8.6.4.5 - Ping and Traceroute Tabs . . . . . . . 8.6.4.6 - System Info Tab . . . . . . . . . . . . . . 8.6.5 - System Maintenance: Restart System . . 8.6.6 - System Maintenance: Update Software . 8.6.6.1 - Upgrading to a New Release . . . . . . . 8.6.6.2 - Downgrading to a Prior Release . . . . . 8.6.6.3 - Changing the Version Type . . . . . . . . 9 Command Line Interface . . . . . . . . . . . . . . . 9.1 - SSH Access . . . . . . . . . . . . . . . . . . . . . . . . 9.2 - RS-232 Access. . . . . . . . . . . . . . . . . . . . . . 9.3 - SFTP Access . . . . . . . . . . . . . . . . . . . . . . . 9.3.1 - Enabling file transfer . . . . . . . . . . . . . . . 9.3.2 - Transferring Files . . . . . . . . . . . . . . . . . 9.4 - Command Description. . . . . . . . . . . . . . . . . 9.4.0.1 - quit. . . . . . . . . . . . . . . . . . . . . . . . . 9.4.1 - CLI Navigation . . . . . . . . . . . . . . . . . . . 9.4.1.1 - exit. . . . . . . . . . . . . . . . . . . . . . . . . 9.4.1.2 - quit. . . . . . . . . . . . . . . . . . . . . . . . . 9.4.2 - System Tools . . . . . . . . . . . . . . . . . . . . 9.4.2.1 - show config-script . . . . . . . . . . . . . . 9.4.2.2 - list config-script-files. . . . . . . . . . . . . 9.4.2.3 - save settings . . . . . . . . . . . . . . . . . . 9.4.2.4 - restore settings . . . . . . . . . . . . . . . . 9.4.2.5 - list settings-files . . . . . . . . . . . . . . . . 9.4.2.6 - reset settings . . . . . . . . . . . . . . . . . . 9.4.2.7 - restart. . . . . . . . . . . . . . . . . . . . . . . 9.4.2.8 - what . . . . . . . . . . . . . . . . . . . . . . . . 9.4.2.9 - show software . . . . . . . . . . . . . . . . . 9.4.2.10 - verify software . . . . . . . . . . . . . . . . 9.4.2.11 - install software . . . . . . . . . . . . . . . . 9.4.2.12 - list software-files . . . . . . . . . . . . . . 9.4.2.13 - restore software . . . . . . . . . . . . . . . 9.4.2.14 - set software . . . . . . . . . . . . . . . . . . 9.4.3 - licenses . . . . . . . . . . . . . . . . . . . . . . . . 9.4.3.1 - add local-license. . . . . . . . . . . . . . . . 9.4.3.2 - list license-files . . . . . . . . . . . . . . . . 9.4.3.3 - remove local-license . . . . . . . . . . . . . 9.4.3.4 - rename local-license . . . . . . . . . . . . . 9.4.3.5 - show license-models . . . . . . . . . . . . . 9.4.3.6 - show license . . . . . . . . . . . . . . . . . . 9.4.3.7 - show local-license. . . . . . . . . . . . . . . 9.4.3.8 - set license-server . . . . . . . . . . . . . . . 9.4.4 - Security . . . . . . . . . . . . . . . . . . . . . . . . 9.4.4.1 - show user . . . . . . . . . . . . . . . . . . . . 9.4.4.2 - add user . . . . . . . . . . . . . . . . . . . . . 9.4.4.3 - set user. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. 8-90 . 8-90 . 8-91 . 8-92 . 8-92 . 8-93 . 8-94 . 8-94 .8-94 . 8-95 . 8-96
. . . . . . . . . . . . . . . .9-1 . . . . . . . . . . . . . . . .9-1 . . . . . . . . . . . . . . . .9-1 . . . . . . . . . . . . . . . .9-2 . . . . . . . . . . . . . . . .9-2 . . . . . . . . . . . . . . . .9-2 . . . . . . . . . . . . . . . .9-2 . . . . . . . . . . . . . . . .9-2 . . . . . . . . . . . . . . . .9-2 . . . . . . . . . . . . . . . .9-2 . . . . . . . . . . . . . . . .9-2 . . . . . . . . . . . . . . . .9-2 . . . . . . . . . . . . . . . .9-2 . . . . . . . . . . . . . . . .9-3 . . . . . . . . . . . . . . . .9-3 . . . . . . . . . . . . . . . .9-3 . . . . . . . . . . . . . . . .9-3 . . . . . . . . . . . . . . . .9-3 . . . . . . . . . . . . . . . .9-3 . . . . . . . . . . . . . . . .9-4 . . . . . . . . . . . . . . . .9-4 . . . . . . . . . . . . . . . .9-4 . . . . . . . . . . . . . . . .9-4 . . . . . . . . . . . . . . . .9-4 . . . . . . . . . . . . . . . .9-4 . . . . . . . . . . . . . . . .9-5 . . . . . . . . . . . . . . . .9-5 . . . . . . . . . . . . . . . .9-5 . . . . . . . . . . . . . . . .9-5 . . . . . . . . . . . . . . . .9-5 . . . . . . . . . . . . . . . .9-5 . . . . . . . . . . . . . . . .9-5 . . . . . . . . . . . . . . . .9-5 . . . . . . . . . . . . . . . .9-6 . . . . . . . . . . . . . . . .9-6 . . . . . . . . . . . . . . . .9-6 . . . . . . . . . . . . . . . .9-6 . . . . . . . . . . . . . . . .9-6 . . . . . . . . . . . . . . . .9-6
ix
9.4.4.4 - remove user . . . . . . . . . . . 9.4.4.5 - show access. . . . . . . . . . . . 9.4.4.6 - enable access. . . . . . . . . . . 9.4.4.7 - disable access . . . . . . . . . . 9.4.4.8 - set access . . . . . . . . . . . . . 9.4.4.9 - list certificate-files . . . . . . . 9.4.5 - System Status . . . . . . . . . . . . 9.4.5.1 - enable unit . . . . . . . . . . . . 9.4.5.2 - disable unit . . . . . . . . . . . . 9.4.5.3 - enable acceleration . . . . . . . 9.4.5.4 - disable acceleration . . . . . . 9.4.5.5 - enable traffic-shaping . . . . . 9.4.5.6 - disable traffic-shaping . . . . . 9.4.5.7 - enable ica-multi-stream . . . 9.4.5.8 - disable ica-multi-stream . . . 9.4.5.9 - show system-status . . . . . . 9.4.6 - IP Address Configuration . . . . . 9.4.6.1 - show dns-server. . . . . . . . . 9.4.6.2 - set dns-server . . . . . . . . . . 9.4.6.3 - show hostname . . . . . . . . . 9.4.6.4 - set hostname . . . . . . . . . . . 9.4.6.5 - show adapter . . . . . . . . . . . 9.4.6.6 - set adapter . . . . . . . . . . . . 9.4.7 - Ethernet Configuration . . . . . . . 9.4.7.1 - set interface . . . . . . . . . . . 9.4.7.2 - show interface . . . . . . . . . . 9.4.8 - Bandwidth Configuration . . . . . 9.4.8.1 - show bandwidth . . . . . . . . . 9.4.8.2 - set bandwidth . . . . . . . . . . 9.4.9 - Link Configuration . . . . . . . . . . 9.4.9.1 - show links . . . . . . . . . . . . . 9.4.9.2 - show link . . . . . . . . . . . . . . 9.4.9.3 - rename link . . . . . . . . . . . . 9.4.9.4 - remove link . . . . . . . . . . . . 9.4.9.5 - remove link-filter . . . . . . . . 9.4.9.6 - move link . . . . . . . . . . . . . 9.4.9.7 - add link . . . . . . . . . . . . . . . 9.4.9.8 - add link-filter . . . . . . . . . . . 9.4.9.9 - set link . . . . . . . . . . . . . . . 9.4.9.10 - set link-filter . . . . . . . . . . 9.4.10 - Service Class Configuration. . . 9.4.10.1 - show service-classes . . . . . 9.4.10.2 - show service-class . . . . . . 9.4.10.3 - enable service-class . . . . . 9.4.10.4 - disable service-class . . . . . 9.4.10.5 - rename service-class. . . . . 9.4.10.6 - remove service-class. . . . . 9.4.10.7 - remove service-class-filter . 9.4.10.8 - move service-class . . . . . . 9.4.10.9 - add service-class . . . . . . . 9.4.10.10 - add service-class-filter. . .
x
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .9-7 . .9-7 . .9-7 . .9-7 . .9-7 . .9-8 . .9-8 . .9-8 . .9-8 . .9-8 . .9-8 . .9-9 . .9-9 . .9-9 . .9-9 . .9-9 . .9-9 . .9-9 . .9-9 . .9-9 . .9-9 . .9-9 . 9-10 . 9-10 . 9-10 .9-10 . 9-10 . 9-10 . 9-11 .9-11 . 9-11 . 9-11 . 9-11 . 9-11 . 9-11 . 9-12 . 9-12 . 9-13 .9-13 .9-14 . 9-14 . 9-14 . 9-14 . 9-15 . 9-15 . 9-15 . 9-15 . 9-15 . 9-15 . 9-16 . 9-16
June 26, 2011
9.4.10.11 - set service-class . . . . . . . . . . . 9.4.10.12 - set service-class-filter . . . . . . . 9.4.11 - Traffic Shaping Configuration . . . . . 9.4.11.1 - show traffic-shaping-policies . . . 9.4.11.2 - show traffic-shaping-policy . . . . 9.4.11.3 - add traffic-shaping-policy . . . . . 9.4.11.4 - set traffic-shaping-policy . . . . . . 9.4.11.5 - rename traffic-shaping-policy . . . 9.4.12 - remove traffic-shaping-policy . . . . . 9.4.12.1 - clear traffic-shaping-policy-stats. 9.4.13 - SNMP Configuration . . . . . . . . . . . . 9.4.13.1 - show snmp . . . . . . . . . . . . . . . 9.4.13.2 - enable snmp . . . . . . . . . . . . . . 9.4.13.3 - disable snmp . . . . . . . . . . . . . . 9.4.13.4 - show snmp-system-mib . . . . . . 9.4.13.5 - set snmp-system-mib . . . . . . . . 9.4.13.6 - show snmp-manager. . . . . . . . . 9.4.13.7 - add snmp-manager. . . . . . . . . . 9.4.13.8 - remove snmp-manager . . . . . . . 9.4.13.9 - show snmp-trapdest . . . . . . . . . 9.4.13.10 - add snmp-trapdest . . . . . . . . . 9.4.13.11 - remove snmp-trapdest . . . . . . 9.4.14 - Alert Configuration . . . . . . . . . . . . 9.4.14.1 - show alert-configuration . . . . . . 9.4.14.2 - set alert-configuration . . . . . . . . 9.4.14.3 - reset alert-configuration . . . . . . 9.4.15 - Alert Management . . . . . . . . . . . . . 9.4.15.1 - clear alert . . . . . . . . . . . . . . . . 9.4.15.2 - show alerts . . . . . . . . . . . . . . . 9.4.16 - WCCP Configuration. . . . . . . . . . . . 9.4.16.1 - show wccp . . . . . . . . . . . . . . . . 9.4.16.2 - enable wccp . . . . . . . . . . . . . . . 9.4.16.3 - disable wccp . . . . . . . . . . . . . . 9.4.16.4 - add wccp . . . . . . . . . . . . . . . . . 9.4.16.5 - set wccp . . . . . . . . . . . . . . . . . 9.4.16.6 - remove wccp . . . . . . . . . . . . . . 9.4.17 - Logging . . . . . . . . . . . . . . . . . . . . 9.4.17.1 - show syslog . . . . . . . . . . . . . . . 9.4.17.2 - set syslog . . . . . . . . . . . . . . . . 9.4.17.3 - enable syslog . . . . . . . . . . . . . . 9.4.17.4 - disable syslog. . . . . . . . . . . . . . 9.4.17.5 - show log . . . . . . . . . . . . . . . . . 9.4.17.6 - set log. . . . . . . . . . . . . . . . . . . 9.4.17.7 - extract log . . . . . . . . . . . . . . . . 9.4.17.8 - clear logs. . . . . . . . . . . . . . . . . 9.4.17.9 - list log-extracted-files . . . . . . . . 9.4.18 - Proxy Configuration . . . . . . . . . . . . 9.4.18.1 - show proxy . . . . . . . . . . . . . . . 9.4.18.2 - add proxy . . . . . . . . . . . . . . . . 9.4.18.3 - remove proxy. . . . . . . . . . . . . . 9.4.19 - Client Configuration . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 9-17 . 9-17 . 9-18 . 9-18 . 9-18 . 9-18 . 9-19 .9-20 . 9-20 . 9-20 . 9-20 . 9-20 . 9-20 . 9-20 . 9-20 . 9-20 . 9-21 . 9-21 . 9-21 . 9-21 . 9-21 . 9-22 . 9-22 . 9-22 . 9-22 . 9-22 . 9-22 . 9-22 . 9-23 . 9-23 . 9-23 . 9-23 . 9-23 . 9-23 . 9-24 . 9-25 . 9-25 . 9-25 . 9-25 .9-25 .9-25 . 9-26 . 9-26 . 9-26 . 9-27 . 9-27 . 9-27 . 9-27 . 9-27 .9-27 . 9-28
xi
9.4.19.1 - show client-rule . . . . . . . . . . . . . . . . . . . . . . 9.4.19.2 - add client-rule . . . . . . . . . . . . . . . . . . . . . . . 9.4.19.3 - remove client-rule . . . . . . . . . . . . . . . . . . . . 9.4.19.4 - show signaling-channel . . . . . . . . . . . . . . . . . 9.4.19.5 - enable signaling-channel . . . . . . . . . . . . . . . . 9.4.19.6 - disable signaling-channel . . . . . . . . . . . . . . . . 9.4.19.7 - set signaling-channel . . . . . . . . . . . . . . . . . . 9.4.19.8 - show client-settings . . . . . . . . . . . . . . . . . . . 9.4.19.9 - set client-settings . . . . . . . . . . . . . . . . . . . . . 9.4.20 - Group Mode Configuration . . . . . . . . . . . . . . . . . 9.4.20.1 - show group-mode. . . . . . . . . . . . . . . . . . . . . 9.4.20.2 - enable group-mode. . . . . . . . . . . . . . . . . . . . 9.4.20.3 - disable group-mode . . . . . . . . . . . . . . . . . . . 9.4.20.4 - set group-mode . . . . . . . . . . . . . . . . . . . . . . 9.4.20.5 - add group-mode . . . . . . . . . . . . . . . . . . . . . . 9.4.20.6 - remove group-mode . . . . . . . . . . . . . . . . . . . 9.4.21 - SSL Configuration . . . . . . . . . . . . . . . . . . . . . . . 9.4.21.1 - add ssl-profile . . . . . . . . . . . . . . . . . . . . . . . 9.4.21.2 - set ssl-profile . . . . . . . . . . . . . . . . . . . . . . . . 9.4.21.3 - show ssl-profiles. . . . . . . . . . . . . . . . . . . . . . 9.4.21.4 - show ssl-profile . . . . . . . . . . . . . . . . . . . . . . 9.4.21.5 - remove ssl-profile . . . . . . . . . . . . . . . . . . . . . 9.4.21.6 - rename ssl-profile. . . . . . . . . . . . . . . . . . . . . 9.4.21.7 - show ssl-optimization . . . . . . . . . . . . . . . . . . 9.4.21.8 - enable ssl-optimization . . . . . . . . . . . . . . . . . 9.4.21.9 - disable ssl-optimization . . . . . . . . . . . . . . . . . 9.4.21.10 - show ssl-secure-peer-connections. . . . . . . . . 9.4.21.11 - show ssl-ca-store . . . . . . . . . . . . . . . . . . . . 9.4.21.12 - show ssl-ca-stores . . . . . . . . . . . . . . . . . . . 9.4.21.13 - show ssl-cert-key-pair . . . . . . . . . . . . . . . . . 9.4.21.14 - show ssl-cert-key-pairs . . . . . . . . . . . . . . . . 9.4.21.15 - show ssl-disk-encryption . . . . . . . . . . . . . . . 9.4.21.16 - show ssl-keystore . . . . . . . . . . . . . . . . . . . . 9.4.21.17 - show ssl-peer-auto-discovery . . . . . . . . . . . . 9.4.21.18 - show ssl-peer-connect-to. . . . . . . . . . . . . . . 9.4.21.19 - show ssl-peer-listen-on . . . . . . . . . . . . . . . . 9.4.21.20 - add ssl-ca-store . . . . . . . . . . . . . . . . . . . . . 9.4.21.21 - remove ssl-ca-store . . . . . . . . . . . . . . . . . . 9.4.21.22 - add ssl-cert-key-pair . . . . . . . . . . . . . . . . . . 9.4.21.23 - remove ssl-cert-key-pair . . . . . . . . . . . . . . . 9.4.21.24 - add ssl-peer-auto-discovery-publish-item . . . 9.4.21.25 - remove ssl-peer-auto-discovery-publish-item. 9.4.21.26 - add ssl-peer-connect-to-item . . . . . . . . . . . . 9.4.21.27 - remove ssl-peer-connect-to-item . . . . . . . . . 9.4.21.28 - add ssl-peer-listen-on-item . . . . . . . . . . . . . 9.4.21.29 - remove ssl-peer-listen-on-item. . . . . . . . . . . 9.4.21.30 - add ssl-secure-peer-connections-item . . . . . . 9.4.21.31 - remove ssl-secure-peer-connections-item . . . 9.4.21.32 - set ssl-cert-key-pair . . . . . . . . . . . . . . . . . . 9.4.21.33 - set ssl-keystore . . . . . . . . . . . . . . . . . . . . . 9.4.21.34 - set ssl-secure-peer-connections . . . . . . . . . .
xii
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 9-28 . 9-28 . 9-28 . 9-28 . 9-28 . 9-28 .9-28 . 9-29 . 9-29 . 9-29 . 9-29 . 9-29 . 9-30 . 9-30 . 9-30 .9-31 . 9-31 . 9-31 .9-32 . 9-33 . 9-33 . 9-33 . 9-33 .9-34 . 9-34 . 9-34 . 9-34 . 9-34 . 9-34 . 9-34 . 9-34 . 9-34 . 9-35 . 9-35 . 9-35 . 9-35 . 9-35 .9-35 . 9-35 . 9-36 . 9-36 . 9-36 . 9-36 . 9-36 . 9-36 . 9-36 . 9-36 . 9-37 .9-37 . 9-37 . 9-37
June 26, 2011
9.4.22 - Test Mode commands . . . . . 9.4.22.1 - clear compression-stats. . 9.4.22.2 - clear compression-history 9.4.22.3 - show object . . . . . . . . . . 9.4.22.4 - set object . . . . . . . . . . . 9.4.23 - Alert Configuration . . . . . . . 9.4.23.1 - clear application-counters 9.4.23.2 - show applications . . . . . . 9.4.23.3 - show application . . . . . . . 9.4.23.4 - add application . . . . . . . . 9.4.23.5 - rename application . . . . . 9.4.23.6 - remove application . . . . . 9.4.23.7 - set application . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. 9-38 . 9-38 . 9-38 . 9-38 . 9-38 . 9-39 . 9-39 . 9-39 . 9-39 . 9-39 . 9-39 . 9-39 . 9-39
10 Specifications and Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-1 10.1 - Contact Us. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
xiii
xiv
June 26, 2011
Chapter1
Introduction
Repeater Appliances optimize your WAN links, giving your users maximum responsiveness and throughput at any distance, and providing that locally connected experience to remote users. Obviously, cutting down on the time users spend waiting is the same thing as increased productivity and user satisfaction. These Appliances are easy to deploy because they work transparently. A twentyminute installation accelerates your WAN traffic with no other configuration required: there is no need to touch your applications, servers, clients, or network infrastructure. And this benefit continues after the installation, since changes in your datacenters or remote sites can be made without regard to the Appliances, and your traffic will still be accelerated. The Appliances need reconfiguration only when your WAN links change.
Repeater 8500 Series Appliance
Repeater 8800 Series Appliance
Branch Repeater Family Installation and Users Guide, rel. 6.0
1-1
1.1 Branch Repeater Product Line
The Appliances support a full range of optimizations, including: Multi-session compression with compression ratios up to 10,000:1. Protocol acceleration for Windows network filesystems (CIFS), XenApp (ICA and CGP), Microsoft Outlook (MAPI), and SSL, giving protocol optimizations that reduce transaction time (and thus user waiting) and bring all the benefits of multi-session compression. Traffic shaping to ensure that high-priority and interactive traffic takes precedence over low-priority or bulk traffic. Advanced TCP protocol acceleration, which reduces delays on congested or high-latency links, making our benefits tenacious under difficult conditions.
1.1
Branch Repeater Product Line
The Branch Repeater product line contains several products, all of which interoperate with each other (with the exception of the Repeater Plug-in, which is compatible with the Repeater Appliances and Branch Repeater VPX, but not Branch Repeater or Branch Repeater with Windows Server). Repeater Appliances. These are the flagship Appliances, providing acceleration for datacenters and high-speed links. There are two Repeater product lines: the 8500 Series, which has a 1U form factor and is suitable for links up to 45 mbps, and the 8800 Series, a 2U form-factor accelerator suitable for links up to 500 mbps. Branch Repeater Appliances. These are smaller, half-sized 1U Appliances for branch offices, available in speeds up to 10 mbps. Branch Repeater Appliances have two versions: Branch Repeater and Branch Repeater with Windows Server. Branch Repeater VPX. Starting with Release 5.6, the Branch Repeater software is available as a Xen or VMware vSphere virtual machine. This product combines the flexibility of virtual machines with the functionality of Repeater appliances, allowing you to use your choice of hardware and combine the VPX with the right combination of other server or appliance virtual machines for your needs. Repeater Plug-in. The Repeater Plug-in has the same acceleration features as the Repeater and Branch Repeater Appliances, but is a software application that provides client-side acceleration on your Windows desktops and laptops.
Note: The name Branch Repeater applies both to the entire acceleration product line and to the smaller, branch-office appliances. The branch-office Appliances are further subdivided into a line of stand-alone Appliances (Branch Repeater) and a line of Windows-Server-based Appliances (Branch Repeater with Windows Server.) This latter product line is not documented here. See the Branch Repeater with Windows Server Installation and Users Guide.
1-2
June 26, 2011
Chapter 1. Introduction
1.2
Who Should Read This Guide
This document describes the installation and operation of the Plug-in and Appliance. It assumes that the reader is a network administrator with prior experience in installing Windows software, rack-mount equipment, IP networking, and Ethernet networking.
1.3

What Is In This Guide
Chapter 2 describes how to deploy your Appliance to match your network. Chapter 3 is a step-by-step installation procedure for the Appliance. Chapter 4 gives the theory of operation. Chapter 5 covers the Repeater Plug-in. Chapter 6 describes the Repeater VPX. Chapter 7 discusses cabling and physical deployment issues. Chapter 8 tells how to use the management interface for configuration and ongoing management. Chapter 9 describes the command-line interface. Chapter 10 provides product specifications.
1.4
Terminology
Series. The 8500 Series or 8500 refers to all models with a number of 8500-8599. This is also true of the 8800 Series, etc. Acceleration Unit. A Repeater Appliance, Repeater Plug-in, Branch Repeater Appliance, or Branch Repeater VPX virtual machine Flow. This term means all connections passing between the same pair of Acceleration units. (This is different from the usual meaning of flow in networking.) Accelerated. Any TCP connection which is undergoing TCP acceleration. It may also be undergoing additional optimizations such as compression or CIFS acceleration. Appliance. Any Repeater, Branch Repeater, Branch Repeater VPX, or Branch Repeater with Windows Server unit. Repeater Plug-in. A software-only implementation of Citrix acceleration technology that runs on Windows PCs. Citrix Accelerator or Citrix Acceleration Plug-in. The Repeater Plug-in.
1.5
Note About Screen Captures
The screen images shown in this manual were not captured exclusively from your exact product or release. There will be slight variations between the UI in this manual and the one that you see on the product. These variations are normal and should be ignored.
1-3
1.5 Note About Screen Captures
1-4
June 26, 2011
Chapter2
ApplianceDeploymentGuide
Note: Plug-in deployment is covered in Chapter 5 Note: Repeater VPX deployment is covered both here and in Chapter 6. Note: Read this whole chapter before installing your Appliances!
2.1
Introduction
Appliance theory of operation is discussed in detail in Chapter 4. For the purposes of this Chapter, the main point is that acceleration works on TCP/IP connections that meet these criteria: All packets in the TCP connection must pass through a supported combination of two acceleration units: Any combination of Repeater, Branch Repeater, and Branch Repeater VPX Appliances. One Repeater Appliance and one Repeater Plug-in. One Branch Repeater VPX Appliance and one Repeater Plug-in.
Traffic in both directions must pass through both Acceleration units.
Once these criteria are met, acceleration is automatic. Deploying Appliances successfully is not difficult, but improper deployments can cause trouble and will give inadequate acceleration. Follow the guidelines in this chapter for best results.
Figure 2-1 Acceleration enhances performance when traffic passes through two Appliances.
NETWORK A WAN WAN Router Appliance WAN Router NETWORK B
WAN Link
Transparent, AutoOptimized Acceleration LAN Link LAN Link
Appliance
2-1
2.2 Product Selection
2.2

Product Selection
Citrix offers the following acceleration products: Repeater Appliance. Used in datacenters, large offices, high-volume links, and mission-critical links. Branch Repeater Appliance. A smaller appliance for branch offices. Branch Repeater With Windows Server. A smaller appliance for branch offices, that includes Windows Server. See the Branch Repeater With Windows Server Installation and Users Guide for more information. Branch Repeater VPX. An Appliance in the form of a virtual machine for Citrix XenServer or VMware vSphere. See Chapter 6 for more information. Repeater Plug-in. Installs on desktop or laptop PCs for users who work on the road, from home, or in offices too small to warrant the purchase of an Appliance. See Chapter 5 for more information.
In addition to the considerations listed above, Appliances vary in maximum bandwidth, disk size, and high-uptime features. Licensed Bandwidth Limit This determines the maximum WAN speed that is supported by the Appliance. Best Practices: Specify an Appliance with a licensed bandwidth limit greater than or equal to the speed of your WAN. If a single Appliance is servicing multiple WANs, its licensed bandwidth limit should be equal to the aggregate speed of the WANs.
Figure 2-2 Licensed bandwidth limits by product line
Product Repeater Plug-in Branch Repeater, Branch Repeater with Windows Server Branch Repeater VPX Repeater 8500 Series Repeater 8800 Series Licensed Bandwidth Limit Range N/A 1-10 mbps 1-45 mbps 5-45 mbps 45-500 mbps
Disk Size The 8800 Series offer more disk capacity than the other Appliances (roughly 600 GB vs. roughly 200 GB for the Repeater 8500, Branch Repeater, and Branch Repeater with Windows Server). Branch Repeater VPX has a disk capacity of 100-500 GB. Disk capacity is important for disk-based compression. Ideally, an Appliance will have disk space equal to at least several days WAN traffic. (A 1 mbps link can transfer about 10 GB per day at full speed.)
2-2
June 26, 2011
Chapter 2. Appliance Deployment Guide
Best Practices: Use an 8800-Series Appliance for link speeds above 45 mbps or when the expected data lifetime with another Appliance would be less than three days.
Figure 2-3 Examples of disk data lifetime.
Appliance Model Link Speed 1 mbps 10 mbps 100 mbps
Data lifetime at 33% link utilization Repeater 8800 Repeater 8500 180 days 60 days 18 days 6 days 43 hours 14 hours
Data lifetime at 100% link utilization Repeater 8800 Repeater 8500 60 days 20 days 6 days 2 days 14 hours 5 hours
Ethernet Bypass card An Ethernet bypass card has a relay that closes if the Appliance fails, allowing packets to pass through the Appliance even if power is removed from it. This provides enhanced uptime and is recommended for all datacenter and large-office deployments. Without the Ethernet bypass card, network connectivity can be lost if the Appliance fails. An Ethernet bypass card is standard equipment on all 8800 and 8500 Series Appliances, and is optional on Branch Repeater Appliances. Best Practices: An Ethernet bypass card is recommended for inline and virtual inline deployments. Redundancy The Repeater 8800 Series Appliances have dual power supplies. The Repeater 8800 and 8500 Series Appliances have redundant disk drives. Appliances can be used in high-availability mode (two redundant Appliances with automatic failover).
Best Practices: Your redundancy decision should be consistent with those used for your WAN routers and network servers.
2.3
2.3.1
Selecting a Deployment Mode

Use Inline Mode When Possible
As implied in Figure 2-1, the Appliance can be placed inline with your WAN link. The Appliance uses an accelerated bridge (two Ethernet ports) for inline mode; packets enter one Ethernet port and exit through the other. This allows the Acceleration unit to be placed between your WAN router and your LAN. As far as the rest of the network is concerned, it is as if the Appliance werent there at all; its operation is completely transparent.
2-3
2.3 Selecting a Deployment Mode
Inline mode has the following advantages over the other deployment modes: It provides maximum performance. It can be installed by people who are not IT professionals. It requires no reconfiguration of your other network equipment.
Other modes (WCCP, virtual inline, redirector) are less convenient to set up, generally requiring that you reconfigure your router, and have lower performance.
2.3.2
WAN-Router-Based Guidelines
The main issue in deployment is to allow the Appliance to work in harmony with your WAN router. This is shown in Figure 2-4.Compare your router cabling to this diagram to find the supported modes. If you have multiple WAN routers, be sure to read Section 2.5 as well. Note: The configurations for which we recommend WCCP mode can all use virtual inline mode instead, but virtual inline is less flexible, has fewer features, and much less instrumentation than WCCP, and should be used as a mode of last resort only. See Figure 2-4 as you read this list: A. Single LAN, Single WAN: Inline mode. The router has a single active LAN interface and a single active WAN interface. The recommended mode for this case is inline mode, which gives the simplest installation, the most features, and the highest performance of any mode. (The difference between hardboost and softboost, and inline, virtual inline, WCCP, and group mode will be discussed in Section 2.3.3.) B. Single LAN, Redundant WANs: Inline mode. Inline mode is best for this configuration as well. Softboost is recommended because of the available bandwidth is uncertain (since it depends on whether the main link, the backup link, or both links are active). In cases where only one link is active at any given time, and both have the same bandwidth, hardboost can be used. C. Single LAN, Multiple WANs: Inline or WCCP. This topology falls into two categories: hub-and-spoke or multi-hop. If the deployment is hub-and-spoke, with most traffic terminating on the spoke site, then an inline deployment is preferable. If it is multi-hop, where traffic typically comes in on one WAN link and exits through the other, then WCCP (or virtual inline) will allow this pass-through traffic to be sent through the Acceleration unit before leaving the site. This is desirable only when one link has an Appliance on the other end and the other does not. D. Dual LANs, single WAN: Inline (with dual bridges) or WCCP. This mode is supported by dual accelerated bridges, WCCP or virtual inline. Either softboost or hardboost can be used with this configuration. E. Multiple LANs, multiple WANs: Inline (dual bridges) or WCCP. This is a slightly complicated version of Case C. Figure 2-5 shows the options supported by each configuration.
2-4
June 26, 2011
Figure 2-4 Recommended deployment modes, based on WAN router topology.

A. Single LAN, Single WAN LAN WAN LAN
Inline WAN
B. Single LAN, Redundant WANs LAN Redundant WANs to Site X LAN
Inline
Redundant WANs to Site X
C. Single LAN, WANs to Two or More Sites LAN WAN to Site X LAN WAN to Site Y Inline LAN WCCP
WAN to Site X WAN to Site Y
D. Dual LANs, Single WAN LAN LAN WAN LAN LAN WCCP E. Multiple LANs, Multiple WANs LAN LAN WAN to Site X WAN to Site Y WCCP LAN LAN WAN
2.3.3
Deployment Mode Summary
2.3.3.1 Forwarding Modes

Inline mode. Highest-performance, most transparent mode. Data flows in one accelerated Ethernet port and out the other. Requires no router reconfiguration of any kind. Inline with dual bridges. Same as inline, but two independent accelerated bridges are used. WCCP mode. WCCP is recommended when inline mode is not practical. Supported by most routers. Requires only three lines of router configuration. To use WCCP mode on a Cisco router, it should be running at least IOS version 12.0(11)S
2-5
2.3 Selecting a Deployment Mode
Figure 2-5 Options supported for each router topology

Appliances WITH Ethernet Bypass Cards Config. A. B. C1. C2. D. D2. E. E2. Mode Inline WCCP WCCP Inline WCCP Inline, Dual Bridges WCCP Inline, Dual Bridges Softboost Yes Yes Yes Yes Yes Yes Yes Yes Hardboost Yes No No No No No No No Group Mode Yes Yes No Yes No No No No High Availability Yes Yes Yes Yes Yes Yes Yes Yes
Appliances WITHOUT Ethernet Bypass Cards Config. A. B. C1. C2. D. D2. E. E2. Mode Inline WCCP WCCP Inline WCCP Inline, Dual Bridges WCCP Inline, Dual Bridges Softboost Yes Yes Yes Yes Yes No Yes No Hardboost Yes No No No No No No No Group Mode No No No No No No No No High Availability No No No No No No No No
or 12.1(3)T. (WCCP stands for Web Cache Communications Protocol, but the protocol was greatly expanded with version 2.0 to support a wide variety of network devices.) Virtual Inline mode. Similar to WCCP mode. Uses policy-based routing. Generally requires a dedicated LAN port on the router. Not recommended on units without an Ethernet bypass card. To use virtual inline mode on a Cisco router, it should be running IOS version 12.3(4)T or above.
2-6
June 26, 2011
Redirector mode (not recommended). Used by the Repeater Plug-in to forward traffic to the Appliance. Can be used as a stand-alone mode or combined with one of the other deployments. Requires no router configuration. Group mode. Used when two or more inline Appliances are used, one per link, within a site. Recommended only when multiple bridges, WCCP, and virtual inline modes are all impractical.
2.3.3.2 High Availability

High-availability mode. High-availability mode transparently combines two inline or virtual inline Appliances into a primary/secondary pair. The primary Appliance handles all the traffic. If it fails, the secondary Appliance takes over. Requires no router configuration. Bypass card. Appliances use a bypass card that connects the two bridged Ethernet ports together in case of a hardware, software, or power failure. This allows the link to be used without acceleration when the Acceleration unit is not running.
2.3.3.3 Acceleration Modes

Hardboost mode. A highly aggressive, bandwidth-limited TCP variant useful for high-speed links, intercontinental links, satellite links, and other fixed-speed links for which achieving full link speed is difficult. Hardboost is recommended for fixed-speed, point-to-point links and fixed-speed hub-and-spoke links where the hub bandwidth is at least as large as the sum of the spoke bandwidths. Softboost mode. A high-performance TCP variant that is recommended for most links. While it gives less performance than hardboost, it will work with any deplyment. Acts like normal TCP, only faster.
2.4
Forwarding Loop Prevention
The Forwarding Loop Prevention option allows the same packet to traverse Appliances twice without causing trouble. In most deployments, this does not happen, but sometimes it is unavoidable, such as in datacenters with multiple routers and complex topologies. Passing the same packet through the same Appliance multiple times, or through more than one Appliance in the same group, can cause problems. The forwarding loop prevention option adds a TCP option to the header of each accelerable packet passing through the unit, allowing the unit to detect packets that it has seen before. The option increases the length of each accelerated packet. This decreases performance slightly, and it is possible that adding an additional option to each packet will cause problems with particularly fussy firewalls, so the option is disabled by default.
2-7
2.5 Guidelines for Sites With Multiple WAN Routers
2.5
Guidelines for Sites With Multiple WAN Routers
When a site has more than one WAN router, it raises the possibility of asymmetric routing. Normally, IP networks dont care what path the packets take, so long as they arrive at their destination. However, the Appliance relies on seeing every packet in the connection. This means that end-around packets are not acceptable. In a site with only one WAN router, this is not a problem, since the Appliance can be placed so all traffic into or out of the router also passes through the Appliance. There is only one path into or out of the site. But with two WAN routers, it can become an issue. Asymmetric routing problems can appear during installation or later, as a result of failover to a secondary link, or other forms of dynamic routing and load-balancing. Figure 2-6 shows an example of a site that may suffer from asymmetric routing. If sites C and D always use the direct paths C-D or D-C when sending traffic to each other, everything is fine, but packets that take the longer paths C-E-D or D-E-C will bypass the Appliances, causing new connections to be non-accelerated and causing existing connections to hang.
Figure 2-6 Asymmetric routing can take place if packets travel via C-E-D instead of C-D.
2.5.1
Solving the Problem With Appliances
This problem can be addressed using either Appliance configuration or router configuration. If the Appliance is positioned after the point where all the WAN streams are combined, asymmetry can be avoided. This is shown in Figure 2-7. Some forwarding modes can deal with asymmetric routing (see also Figure 2-8): Multiple Bridges. An Appliance with two accelerated bridges or accelerated pairs (for example, apA and apB), allows two links to be accelerated in inline mode. The two links can be fully independent, load-balanced, or primary/backup links. WCCP mode allows a single Appliance to be shared between multiple WAN routers, allowing it to see all the WAN traffic regardless of the link it arrived on. Virtual inline mode allows a single Appliance to be shared between multiple WAN routers, allowing it to see all the WAN traffic regardless of the link it arrived on.
June 26, 2011
2-8
Figure 2-7 By placing the Appliance at the point where all the WAN traffic comes together at
the WAN-LAN boundary, asymmetric routing can be avoided. All paths between site C and site D are accelerated.
Group mode allows two or more inline Appliances to share traffic with each other, ensuring that traffic that arrives on the wrong link is handed off properly. Since group mode requires multiple Appliances, it is an expensive solution that is best suited to installations where the accelerated links have wide physical separation, making the other alternatives difficult. For example, when the two WAN links are on different offices in the same city (but the campuses are connected by a LAN-speed link), then group mode may be the only choice.
Figure 2-8 By covering all links with either group mode or virtual inline mode, asymmetric routing ceases to be a problem.
Keep in mind that sites with only one WAN link do not participate in asymmetric routing and are not a problem. This is shown in Figure 2-9.
2-9
2.5 Guidelines for Sites With Multiple WAN Routers
Figure 2-9 Links leading to sites with only one WAN link cannot create asymmetric routing problems; only sites with multiple links can mis-route packets.
Mix and Match. As shown in Figure 2-9, one end of the link can use virtual inline mode while the other end uses group mode. This is true in general: the two ends of a link do not have to use the same forwarding mode.
2.5.2
Mixing Modes Within a Single Appliance
In general, all modes are simultaneously active. However, some combinations should not be used together. See Figure 2-10
Figure 2-10 Combinations of forwarding modes within a single Appliance
Supported Combinations, Units WITH Ethernet Bypass Cards Config. Repeater Plug-in Inline Virtual Inline WCCPGRE WCCPL2 Multiple Bridges High Avail. Inline Y Y Virtual Inline Y N Y WCCPGRE Y N Y Y WCCPL2 Y N Y Y Y Multiple Bridges Y Y Y Y Y Y High Avail. Y Y Y Y Y Y Y Group Mode N Y N N N N Y
2-10
June 26, 2011
Figure 2-10 Combinations of forwarding modes within a single Appliance

Supported Combinations, Units WITHOUT Ethernet Bypass Cards Config. Repeater Plug-in Inline Virtual Inline WCCPGRE WCCPL2 Multiple Bridges High Avail. Y = Yes, supported. N = Not supported. Inline N Y Virtual Inline N N Y WCCPGRE N N Y Y WCCPL2 N N Y Y Y Multiple Bridges N N N N N N High Avail. N N N N N N N Group Mode N N N N N Y N
2.5.3
Solving the Problem in the Router
Router configuration to eliminate asymmetric routing involves disabling any kind of dynamic or load-balanced routing for the link, and substituting a static route. This does not mean that the alternate path cannot be used as a failover, but it should not be used unless the accelerated link fails. WCCP and policy-based routing with health-checking both lend themselves to this. The main thing is to prevent the accelerated link from participating in load-balancing and dynamic routing.
2-11
2.6 Deploying to Support VPNs
2.6
Deploying to Support VPNs
VPN support is simply a matter of putting the Appliance on the LAN side of the VPN, as shown below. This ensures that the Appliance sees the decapsulated, decrypted, plaintext version of the link traffic, allowing compression and application acceleration to work. (Application acceleration and compression have no effect on encrypted traffic. However, TCP protocol acceleration works on encrypted traffic.)
Figure 2-11 VPN cabling for an inline VPN. The Appliance sees all the LAN-side VPN traffic
and can accelerate it. Non-VPN traffic on the same link can also be accelerated.
Figure 2-12 One option for accelerating one-armed VPNs. The Appliance is on the server
side of the VPN. All VPN traffic with a local destination will be accelerated. VPN traffic with a remote destination will not be accelerated. Non-VPN traffic can also be accelerated.
2-12
June 26, 2011
Figure 2-13 Alternate method of accelerating one-armed VPN traffic. Non-VPN traffic
bypasses the Appliance and will not be accelerated.
For acceleration to be effective, the VPN must preserve TCP header options. This is true of most VPNs.
2.6.1
Supporting Repeater Plug-in With Citrix Access Gateway VPNs
The Repeater Plug-in is supported by Access Gateway VPNs. See the Branch Repeater Release Notes for a list of supported Access Gateway releases.
2.6.1.1 Configuring Access Gateway Standard Edition Support

(For other VPNs, see your VPN documentation.) The Access Gateway Standard Edition VPN supports Repeater Plug-in acceleration. Configure Repeater support using the Access Gateway Administration Tool: 1. Go to the Global Cluster Policies page and check the Advanced Option checkbox that says, Enable TCP optimization with Repeater Plug-in. 2. Make sure that the IP addresses used by the Repeater (redirector IP and management IP) have access enabled on the Network Resources section on the Access Policy Manager page.
2-13
2.6 Deploying to Support VPNs
3. For each of these addresses, enable all protocols (TCP, UDP, ICMP) and enable Preserve TCP Options.
2-14
June 26, 2011
4. Make sure that these same addresses are included under User Groups: Default: Network Policies on the Access Policy Manager page.
2.7
Supporting Repeater Plug-in With One-Armed Redirector Mode (Not Recommended)
Appliances that are to support Repeater Plug-in can be deployed in the usual way. In addition, one-armed redirector-mode deployments can be used if necessary. This is a special Plug-in-only deployment that can be used if the Appliance is going to be used solely for use with Repeater Plug-in, no Appliance-to-Appliance acceleration is expected, and the QoS benefits of having the Appliance along the path of all link traffic are not desired. This redirector-only mode is supported but is not recommended. This involves placing the Appliance at any convenient point on the LAN that is accessible to the servers being accelerated. This deployment is convenient for testing, since it requires no reconfiguration of the router or network and doesnt cause even a momentary disruption of network service. The only traffic passing through the Appliance is Repeater Plug-in traffic. Other network traffic is totally unaffected. In addition, there is no concern about asymmetric routing, because the Repeater Plug-in traffic is addressed specifically to the Appliance.
2-15
2.7 Supporting Repeater Plug-in With One-Armed Redirector Mode (Not Recommended)
Figure 2-14 Basic cabling, redirector mode. This mode is supported but is not recommended. Do not attempt to use this mode with Citrix Access Gateway products.
The disadvantages of this deployment are: It supports client traffic only. Most deployments involve multiple Appliances and require support for Appliance-to-Appliance traffic. By not passing all the WAN traffic through the Repeater, traffic shaping is not effective. Any need to protect non-accelerated traffic will have to be dealt with in the router.
A compromise approach is to use the redirector-mode-only deployment at first, but to be prepared to shift to the topology recommended earlier in this chapter once Appliance-to-Appliance acceleration becomes desirable. In many cases this requires nothing more than enabling WCCP on the Appliance and in your router, without recabling the Appliance.
2-16
June 26, 2011
Chapter3
InstallingtheAppliance
The procedures in this section will get your Appliance up and running. Branch Repeater VPX users should read Chapter 6 first. Repeater Plug-in Installation is covered in Chapter 5.
3.1
Installation Overview
The Appliance accelerates TCP connections passing through two Appliances: one on the sending side, and one on the receiving side. A functional installation thus requires as least two units at different sites. Data that travels through just one Appliance will be passed through unmodified. Each unit can talk to any number of other units simultaneously, so acceleration normally requires one Appliance per site, not two per link. The Appliance requires AC power and an Ethernet connection to your LAN or WAN.
3.2
Pre-Installation
Before beginning the actual installation, perform the following steps to gather appropriate resources and information, and to make basic decisions about the installation: 1. 2. Required: Review Chapter 2 before installing the Appliance. Recommended: Read this document through Chapter 4 before beginning. Choose a mounting location for the 1U Appliance, which requires either 2U of height (Repeater 8800 Series) or 1U (all others). Appliances are rack-mount devices that can be installed into two-post relay racks and four-post EIA-310 server racks. Verify that the Appliance is compatible with your rack. High-availability pairs require twice as much rack space. Optionally, the Appliance can be mounted outside a rack; a set of rubber feet is provided for this purpose. Verify that adequate power is available. Branch Repeater has a 200 W power supply (100-240 V, 50-60 Hz). The Repeater 8500 Series have a 280W power supply (100-240 VAC, 50-60 Hz); the Repeater 8800 Series has a 700W power supply. High-availability pairs require twice as much power. Select your basic operating configuration based on the guidelines in Chapter 2: inline, WCCP, or virtual inline.
3.
4.
3-1
3.2 Pre-Installation
5.
Determine whether your installation will use hardboost or softboost acceleration. Answer the following questions to determine the correct mode: a. b. Have already determined that softboost doesnt give the speed you require in your point-to-point network? Are you accelerating a fixed-speed, point-to-point WAN link or a hub-and-spoke network with fixed-speed links, where the hub bandwidth is equal or greater than the sum of the spoke bandwidths? If you answered Yes to all these questions, you can try hardboost.
d.
Note: Hardboost and softboost are mutually incompatible. The same Appliance cannot use hardboost with some partners and softboost with others. Sometimes it is necessary to dedicate an Appliance for hardboost over a particularly difficult link, but use softboost for the rest. 6. 7. Identify your cabling needs and acquire appropriate cables. Use the provided cables if possible. See Section 7.2. Allocate a management IP address to the Appliance. This address should be on the same subnet as the WAN router port that the Appliance is connected to. The management IP address (and signaling IP address, if used), should be on the same subnet as other devices on the same LAN segment. Management IP Address: ______________ This management address will be used to communicate with the browser-based management pages. If you are using the Repeater Plug-in, you must also assign a signaling IP address to the Appliance. Signaling IP Address: ________________ The signaling address is used by Repeater Plug-in to communicate with the Appliance. See Figure 3-1. Tip: Ping these addresses first to make sure they are not already in use.
Figure 3-1 Assigning IP addresses
3-2
June 26, 2011
Chapter 3. Installing the Appliance
8.
(Virtual inline mode only) Identify an unused Ethernet port on your router, and make sure that you understand how to configure policy-based routing (see Section 4.13). If you are installing two units as a high-availability pair, you will need rack space, power, cables, and a management IP address: _______________ for the second unit as well. You will also need a virtual IP address (VIP): _____________ that is used to manage the two Appliances as a single unit. All three addresses must be on the same subnet. (See Section 7.5.)
9.
3.3
3.3.1
10.
Installation
Install the Appliance Into the Rack
Install the Appliance into the rack. Do not install the power cord. The unit will start as soon as the cord is installed. We do not want to power up the unit yet.
Figure 3-2 Appliance connectors.
3.3.2
11.
Install Ethernet Cables

Install the Ethernet cable(s) in the ports marked Accelerated Pair A in Figure 3-2. The Appliance uses Gigabit Ethernet ports that auto-configure for Gigabit, 100 Mbps, or 10 Mbps networks. These ports are on an add-in card, and on newer units are labeled Accelerated LAN/WAN Ports.
3-3
3.3 Installation
Figure 3-3 Basic cabling, inline mode
Figure 3-4 Basic cabling, inline high-availability pairs
Starting with release 4.1, units can be shipped with more than one pair of accelerated LAN/WAN ports. See Section 4.8 for information on using multiple accelerated bridges. When you have multiple pairs, you should assign the Management IP address and the Redirector IP address to the subnet attached to Accelerated Pair A. Motherboard Ethernet ports are not accelerated, and are shipped with plugs to prevent cables from being installed into them accidentally. These ports can be used for other purposes. See Section 4.8. a. You can use either port of an accelerated pair as the WAN-facing port, but when you define your links, you need to know which port that is. Refer to Figure 3-5 for the individual port names. A good convention is to use apA.1 as the LAN port and apA.2 as the WAN port. If only one port is used (WCCP or virtual inline installations), use apA.1.
3-4
June 26, 2011
Figure 3-5 Ethernet port locations on the appliance.
Rear of Appliance, Branch Repeater Primary Aux1 apB.1 apB.2 (optional) apA.1 apA.2
Rear of Appliance, Branch Repeater 8500 Series Primary Aux1 apB.2 apB.1 (optional) apA.2 apA.1
Rear of Appliance, Branch Repeater 8800 Series
apA.2 Primary Aux1 apA.1
apB.2 apB.1 (Optional)
b. The choice of straight-through or cross-over cables depends on the type of unit attached to the Appliance. Straight-through cables are used with switches; crossover cables are used with routers and computers. See Figure 3-3. Cabling errors are a major source of installation problems. Use straight-through or cross-over cables as indicated. The only exception is an installation where all devices connected to the Appliance use Gigabit Ethernet, which automatically detects and compensates for the type of cable. c. If you are installing a high-availability pair, the two units are connected in parallel, as shown in Figure 3-4. High availability pairs must have one cable disconnected initially, to prevent data loops. This cable will be installed after HA configuration.
3-5
3.3 Installation
d. (Virtual Inline and WCCP Installations.) Install the units as shown in Figure 3-6 and Figure 3-7. Plug the cable into either one of the two ports of the Acceleration units accelerated pair (marked Accelerated LAN/WAN Ports) Virtual inline installations are always connected directly to a router port. WCCP installations must also be on an isolated subnet but this isolation can be achieved using methods other than a dedicated router port, such as with a VLAN.
Figure 3-6 Basic cabling, virtual inline and WCCP modes.
Figure 3-7 Basic cabling, virtual inline or WCCP high-availability pair
12.
(Inline units with bypass cards only) With the Appliance still powered down, test the cabling by attempting to connect to a system on the far side of the unit(s), using ping, ftp, or another convenient program. Units without bypass cards will block traffic, so this step should be skipped. Troubleshooting. Problems at this stage are caused by: Simple cabling errors (cables left disconnected or plugged into the wrong port on one end or the other). Inspect your cabling. Note that many Appliances have two unused Ethernet ports. Make sure you are using the Accelerated Pair. (10/100 Ethernet) The use of a cross-over cable where a straight-through cable is needed, or vice versa. Compare your cabling to the diagrams above.
13.
3-6
June 26, 2011
(10/100 Ethernet) A cable plugged into the Uplink port of a switch when it should use a regular port, or vice versa. Inspect your cabling. (10/100 Ethernet) If all else fails, replacing either of the cables with that of the opposite type should work (that is, replace a straight-through cable with a cross-over cable, or vice versa).
3.3.3
14.
Turn on the Unit

Plug the power cord into the unit. If installing a high-availability pair, power up both units. Wait for the unit to become responsive to front-panel commands.
3.3.4
Perform Initial Configuration Via the Front Panel
The front-panel interface has a two-line LCD display and five buttons. These allow the IP address, netmask, and gateway to be set. Further configuration is done through the browser-based management interface. Note: Two interfaces are shown: Accelerated Pair A and Primary. In most installations, the Primary port should be ignored and only Accelerated Pair A (apA) should be configured. 15. When the front-panel interface becomes active, set the IP address (from Step 7), netmask, and gateway address through the front-panel interface as shown (if you are setting up an HA pair, follow these steps for both units):
Default display while the system boots. The five buttons are shown on the right. This display appears after the system is initialized. The top line gives the current accelerated bandwidth limit. The bottom line is a performance bar graph (which will be invisible if no accelerated transfers are underway). Pressing the down button displays the hostname. This cannot be set from the front panel. The accelerated interface (called apA starting in release 4.1, and unlabeled in earlier releases) should be on by default. Pressing the down button again displays the VLAN tagging status. This defaults to off. If your network does not require a VLAN id to reach the Appliances UI, skip to step 15h.
Figure 3-8 Front-panel configuration (Sheet 1 of 2)

15a.
15b.
15c.
15d.
15e.
3-7
3.3 Installation
Figure 3-8 Front-panel configuration (Sheet 2 of 2)

If your network requires VLAN tagging: Press the center button to enter the VLAN tagging menu. Press the up button to turn tagging on. Use the right button to move the cursor to different digits of the decimal VLAN number, and the up/down arrows to change the values of the digits. Finally, press the center button to submit the VLAN number, and press it again to verify that you wish to keep it. Pressing the down button again displays the IP address. Enter the Management IP address from Step 7. Pressing the middle button allows you to edit the IP address. The left and right buttons move the cursor. The up and down buttons increment and decrement the IP address. Pressing the middle button saves the address. Pressing the down button once more displays the netmask. Press the middle button to edit the netmask. The button definitions are the same as when changing the IP address. Press the middle button to stop editing. Pressing the down button displays the gateway address. Edit as with the IP address. Ignore Primary port entries. The Primary port was introduced in release 4.1. Do not configure it now. Press the down button until you see the Restart? screen. Pressing the down button displays the restart screen. Changes do not take effect until you restart. Press the middle button to restart.
15f.
15g.
15h.
15i.
15j.
15k.
15l.
15m.
3.3.5
16.
Browser-Based Configuration
(Virtual Inline Units) Configure your router to allow access to the Appliances management IP address.
3-8
June 26, 2011
17.
Using a Web browser, go to the Appliance management page with the URL: http://xx.xx.xx.xx, where xx.xx.xx.xx is the management IP address you assigned in Step 7. You will be prompted for a username and password. The factory default values are Admin and password. (You will change the Admin password in Step 24.)
Note: Some older browsers are not supported. In particular, Chrome and Internet Explorer versions before 6.x are not supported.
3.3.6
Quick Installation
Figure 3-9 Quick Installation page.
The quick installation page serves a a complete installation for simple inline deployments, and as mostly-complete installation for others. Follow this procedure: 18. 19. In the browser-based UI, click on the Quick Installation link. Verify that the information in the Management Access section is correct.
3-9
3.3 Installation
20.
Update the System Services section. a. Add your secondary DNS server, if any. b. Either add your NTP time server (recommended), or manually update the date and time. c. Set the time zone.
21.
Install a license. a. Most licenses are network licenses. On the Citrix License Type entry, select a model number for which your license server has a license, and put the license servers IP address or hostname (for example, 172.16.0.1 or license-server.example.com) in the License Server Address field. This address must be accessible from the Appliance via both ping and a TCP connection on the licensing port. Leave the Licensing Service Port at the default unless you know that it uses a non-standard address. b. If you are using a local license, you will have to add it later. See Section on acquiring local licenses, and Section 8.4.4.3 on installing them.
22.
Define the WAN link. a. For the Receive (Download) Speed field, enter 95% of the links nominal download speed. (Most links are specified a few percent higher than their actual throughput due to link-management overhead). Be sure to get the unit of measurement right (kbps or mbps). b. For the Send (Upload) Speed field, enter 95% of the links nominal upload speed. c. For the WAN-Side Adapter field, select either apA.1 or apA.2, depending on which port you plugged WAN-side cable into during Step 11.
23. 24.
Press the Install button. The system will restart. For security, the Admin password should be changed from its default value after the Appliance restarts. In the browser-based UI, go to the Configuration: Administrator Interface: User Accounts tab. Press the Modify button for the Admin account, check the Change box, enter the new password: _____________ twice, and press the Update button. For a simple inline deployment, basic installation is complete. You must do additional configuration if: Your Appliance is not inline, or is serving multiple WAN links (Section 4.4.4). You will be using the Repeater Plug-in (Section 3.3.10). You are using any of the following deployment modes: High-availability (Section 3.3.7), group mode (Section 4.15), or WCCP (Section 4.13).
June 26, 2011
25.
3-10
You are upgrading from release 5.x and you defined non-standard service classes. These are converted automatically, but may require adjustment. See Figure 3.7 You wish to use any of the following features: hardboost (Section 3.3.8), SSL acceleration (Section 4.15), signed SMB (Windows file system) acceleration (Section 4.20), or encrypted MAPI (Outlook) acceleration (Section 4.19).
26. 27.
To test your installation, go to Step 38. Installation is complete.
3.3.7
28.
Configure the High-Availability Pair

If you are configuring a high-availability pair, set up the HA functionality first, then finish the configuration using the virtual IP address that controls both units together. This procedure also works when creating an HA pair by adding a second unit to an existing installation. a. On the Features page of the first Appliance, disable Traffic Processing. This will disable acceleration until the HA pair is configured. b. Repeat for the second Appliance. c. On the first Appliance, go to the Configuration: Advanced Deployments: High Availability tab. See Figure 3-10. d. Check the Enabled box. e. Follow the Configure HA Virtual IP Address link and assign the virtual IP address you selected in Step 9. to the apA interface. This address will be used later to control both units together. f. Returning to the High Availability page, assign a VRRP ID to the pair and enter it in the VRRP VRID field. This defaults to zero, but valid numbers are in the range of 1-255. The actual value doesnt matter, so long as it doesnt collide with other VRRP devices on your network. g. Fill in the other units SSL Common Name (from the other units Configuration: Advanced Deployments: High Availability tab) in the Partner SSL Common Name field. h. Press the Update button. i. Repeat steps c-h on the second Appliance. Remember that one Ethernet cable was left disconnected on this Appliance, which may prevent you from connecting to it with your browser. If so, plug it back in and unplug the one on the first Appliance.
3-11
3.3 Installation
j. With your browser, navigate to the virtual IP address of the HA pair. Enable Traffic Processing on the Features page. The rest of the installation will be performed from this virtual address. k. Plug in the cable that was left disconnected.
Figure 3-10 High-availability configuration page.
3.3.8
Set Hardboost Mode
Figure 3-11 Hardboost bandwidth setup.
29.
Follow this procedure only if you selected hardboost mode in Step 5. Click the Bandwidth Management link. This will show you the bandwidth page. a. Make sure the acceleration mode (hardboost or softboost) matches the one you selected in Step 5. b. For now, set the WAN Bandwidth Send Limit and WAN Bandwidth Receive Limit to 95% of the link bandwidth in both the sending and receiving directions (note that your link may have different speeds for each direction). This should match the send/receive speeds you used when defining your WAN link. Press the Update button.
3-12
June 26, 2011
3.3.9
Check Service Class Settings
Figure 3-12 Service Class Policies page.
30.
On the Configure: Service Classes page, check the following: a. HTTP Settings. If the Appliance is being used only with Repeater Plug-in, or the path between users and the Internet passes through two Appliances, then go to the Web (Internet) service class policy. Select the Accelerate checkbox and set compression to Disk. See Figure 3-12. b. HTTPS Settings. If the Appliance is being used only with Repeater Plug-in, or the path between users and the Internet passes through two Appliances, then go to the Web (Internet-Secure) service class policy. Select the Accelerate checkbox and set compression to None. c. Press the Apply button to save your changes.
3-13
3.3 Installation
3.3.10 Configure Repeater Plug-in Support

Figure 3-13 Repeater Plug-in Support.
31.
Follow these steps only if you will use the Appliance with the Repeater Plug-in.Go to the Appliances Configuration: Repeater Plug-ins: Signaling Channel Configuration tab. (See Figure 3-13.) a. Enter the Signaling IP from Step 7 in the Signaling IP field. b. Leave the Signaling Port and Connection Mode at their default values. These will be updated later. c. Press Update
32.
On the Configuration: Repeater Plug-ins: Acceleration Rules tab: Add an Accelerated rule for each local LAN subnet that can be reached by the Appliance. That is, press the ADD button, specify Accelerate, and type in the subnet IP/mask. Repeat for each subnet that is local to the Appliance. If you wish to exclude some portion of the included range, add an Exclude rule and move it above the more general rule. For example, 10.217.1.99 looks like a local address but is really the local end of a VPN unit, create an Exclude rule for it on a line above the Accelerate rule for 10.217.1.0/24. If you wish to use acceleration only for a single port (not recommended), such as port 80 for HTTP, replace the wildcard in the Ports field with this value. To support more than one port, add additional rules, one per port. In general, narrow rules (usually exceptions) should be listed first, then general rules.
3-14
June 26, 2011
Press the Save link. Changes will not be saved if you navigate away from this page without saving.
The default action is to not accelerate; only addresses/ports that match an Accelerated rule (before matching an Excluded rule) are accelerated.
Figure 3-14 Setting Plug-in rules on the Appliance
3.3.11 (WCCP Only) Enable WCCP Mode and Configure Router

33. WCCP was introduced in release 3.0. To configure your Appliance for WCCP, follow the procedures in Section 4.13.
3.3.12 (Virtual Inline Only) Enable Virtual Inline Mode and Configure Router
34. 35. Go to the Tuning page and select the Return to Ethernet Sender button if it is not already selected. (See Section 4.14.) Reconfigure your router to forward inbound and outbound WAN traffic to the Appliance, using policy-based routing based on the ingress port to prevent routing loops. The basic technique is: Route inbound traffic from the WAN interface to the Appliance. Route outbound traffic from the WAN interface to the Appliance.
3.3.13 Security: Change the Admin Password

36. On the Configuration: Administrator Interface: User Accounts tab, press the Modify button and change the admin user password. Press the Update button when done.
3.3.14 Disable Encryption on Outlook 2007 Clients

37. To get the benefits of Microsoft Outlook (MAPI) acceleration on Outlook 2007, encryption must be disabled on the users systems. See Section 4.18.2.
3-15
3.4 Testing the Installation
Figure 3-15 Using the Tuning page for virtual inline modes.
3.4
38. 39.
Testing the Installation

Ping the remote Appliance at its management address to make sure it is running. On your local Appliances management page, click the Dashboard link to see the traffic passing through the Appliance. The graphs will be updated periodically (by default, once per minute). Open a connection to an Appliance-equipped remote site, using FTP or some other convenient bulk-transfer program. (In this manual, we always use FTP as our example program, but the Appliance accelerates all TCP-based connections, including ssh, rsync, iperf, HTTP, SMTP, and so on.) Start a data transfer. Once the transfer starts, the throughput graph should show Accelerated bandwidth at the bandwidth limit of either the local or the remote Appliance, whichever is less. Compression will usually yield a throughput in the range of 1:1 to 10:1, depending on the compressibility of the test file.
40.
41.
3-16
June 26, 2011
Send the file a second time. This should yield a compression ratio of at least 100:1, and the throughput should be considerably faster than the WAN link. (If not, you may have gotten apA.1 and apA.2 reversed in your link definitions. This can be fixed on the Configuration: Links page. Compression ratios can be read on the Monitoring: Connections page (on the Accelerated Connections tab. By default, only open connections are displayed, but if you change the Connection State filter to Any, the data will persist for about a minute after the connection closes. 42. Check for CIFS acceleration: a. Reboot a convenient PC or workstation and mount all the CIFS (Windows) file systems that are normally accessed over the WAN. This should ensure that it will open new CIFS connections, which will be accelerated. b. Look at the Monitoring: Filesystem (CIFS/SMB) page. Your connections to CIFS file servers should be listed under Accelerated CIFS Connections. If they are listed under Non-Accelerated CIFS Connections with Reason 3: Security Settings, you need to disable CIFS Signing on your server. See Section 4.17.1. If the connections are not listed at all, you have a routing or setup problem. 43. Your installation is up and running! Additional configuration you may wish to perform includes: a. Bandwidth tuning (Section 4.3.4). b. Adding user accounts (Section 8.4.1.3). c. Altering traffic-shaping policies if the default ones prove to be inadequate for some reason. (Section 4.6.)
3.5
3.5.1
Troubleshooting
Cabling and Duplexing Problems
Note: On Branch Repeater VPX, the VPX virtual machine cannot discover the speed and duplex mode of the physical Ethernet ports, so troubleshooting must be done with the aid of the hypervisor. Ethernet cabling errors and full-duplex/half-duplex issues are the most common sources of installation problems. This is particularly true of 10/100 Mbps Ethernet links. The two biggest sources of trouble are: The incorrect use of straight-through vs. cross-over cables, which causes a total loss of connectivity on 10/100 Mbps links.
3-17
3.5 Troubleshooting
Links where one side is forced to 100 Mbps full-duplex, and the other is set to Auto-negotiate. A flaw in the Fast Ethernet standard results in the Auto side choosing 100 Mbps HALF-duplex in this case. The link works, but at greatly reduced performance. This can happen at the actual link to the Appliance, but long-standing cases are often discovered elsewhere in existing networks, where they have gone unnoticed because past performance expectations have been low.
See Section 7.2 for additional information. Start by verifying that you can connect to the local Appliance at its management IP address (using pings or browsing to the Management interface). In inline mode, verify that you can connect through the Appliance to outside systems.
3.5.2
Cant Connect in Virtual Inline Mode
If LAN-to-WAN connectivity is lost in a virtual inline installation, check for the following causes: Cabling errors (see above). Router misconfiguration. Router loops or other configuration problems may be preventing connections from succeeding.
3.5.3
Compressed Throughput is No Greater than Uncompressed Throughput
This generally happens if the LAN and WAN ports are reversed on the Configuration: Links page.
3.5.4
No Transfers are Accelerated
If the transfer succeeds, but is not accelerated (the Monitoring: Usage Graph page doesnt show the bandwidth as Accelerated bandwidth or shows no bandwidth usage at all) then: Inline mode: If the bandwidth is not shown as accelerated bandwidth, one or both of the Appliances is not enabled, or the remote Appliance is not installed, or at least one unit is not on the path taken by the data. If no bandwidth usage is shown at all, the local Appliance is not on the path taken by the data (check your cabling and routing tables). Virtual inline and WCCP modes: If the traffic doesnt appear at all on the Appliances usage graph, then the router isnt routing the traffic through the Appliance. Check your configuration. General: Your firewall or router may be overly aggressive about blocking connections, and is rejecting accelerated traffic because it has unusual TCP options. See
3.5.4.1 TCP Option Usage and Firewalls

Acceleration parameters are sent via TCP options. These may occur in any packet, and are guaranteed to be present in the SYN and SYN-ACK packets that establish the connection. Your firewall must not block TCP options in the range of 24-31 (decimal), or acceleration cannot take place, and accelerated connections will be blocked.
3-18
June 26, 2011
Most firewalls do not block these options. However, Cisco ASA and PIX firewalls (and perhaps others) with release 7.x firmware may do so by default. (The Acceleration unit will detect this and stop trying to accelerate connections for the offending source/dest IP combination, at which point connections will be established normally, but will not be accelerated. The detection process can take anywhere from 20 seconds to several minutes, causing annoying delays in addition to the lack of acceleration.) In general, programming your firewall to accept TCP options in the range of 24-31 will solve this problem. The firewalls at both ends of the link should be examined, since both may be permitting options on outgoing connections but blocking them on incoming ones. The following example should work with Cisco ASA 55x0 firewalls using 7.x firmware. Because it globally allows options in the range of 24-31, there is no customized per-interface or per-unit configuration:
==================================================================== CONFIGURATION FOR CISCO ASA 55X0 WITH 7.X CODE TO ALLOW TCP OPTIONS ==================================================================== hostname(config)# tcp-map WSOptions hostname(config-tcp-map)# tcp-options range 24 31 allow hostname(config-tcp-map)# class-map WSOptions-class hostname(config-cmap)# match any hostname(config-cmap)# policy-map WSOptions hostname(config-pmap)# class WSOptions-Class hostname(config-pmap-c)# set connection advanced-options WSOptions hostname(config-pmap-c)# service-policy WSOptions global
Configuration for a PIX firewall is similar:

===================================================== POLICY MAP TO ALLOW APPLIANCE TCP OPTIONS TO PASS (PIX 7.x) ===================================================== pixfirewall(config)#access-list tcpmap extended permit tcp any any pixfirewall(config)# tcp-map tcpmap pixfirewall(config-tcp-map)# tcp-opt range 24 31 allow pixfirewall(config-tcp-map)# exit pixfirewall(config)# class-map tcpmap pixfirewall(config-cmap)# match access-list tcpmap pixfirewall(config-cmap)# exit pixfirewall(config)# policy-map global_policy pixfirewall(config-pmap)# class tcpmap pixfirewall(config-pmap-c)# set connection advanced-options tcpmap
3.5.5
Windows Filesystem (CIFS) Transfers Are Not Accelerated
A lack of acceleration on Windows filesystem (CIFS) transfers is usually caused by one of the following: Persistent connections. Only connections that are started after Acceleration is enabled are accelerated. CIFS connections are very persistent, and it is usually necessary to dismount and remount the filesystem on the client (or reboot) before acceleration will be seen. To see the full effects of acceleration, restarting the file
3-19
3.6 Licensing
server is the quickest method of guaranteeing that all the old connections have closed, though this is disruptive in a production environment. Security signing. A Windows server option called signing adds authentication data to CIFS transfers. Signing prevents the CIFS protocol from being optimized (unless the Appliance has joined a Windows domain. See Section 4.19.2), though it does not interfere with compression or flow control. See Section 4.17.1. A log message is created when this happens:
CIFS Session from client <ip> to server <ip> cannot be accelerated for CIFS due to: server security settings.
3.5.6
Accelerated Connections Run, then Hang
This is typically a problem when a VPN adds so much additional header/trailer data to the packets that they become fragmented. Many networks have broken or poorly functioning fragmentation machinery, and the connection hangs after a series of full-sized packets is fragmented. This happens on a per-connection basis, and non-bulk-transfer connections (such as ssh terminal sessions) are often not affected. The log of the receiver-side Acceleration unit may contain large numbers of TCP Checksum Error messages. The Acceleration unit already uses a reduced MSS to make room for its own headers and those of other equipment, but this needs to be reduced further if these problems are seen. To fix this problem, two packet-size parameters need to be reduced. In most cases, reducing DefaultMss and MaximumMss to 1340 bytes (from their default of 1380) will fix the VPN fragmentation problem. The MSS value can be changed on the Configuration: Tuning page. Setting DefaultMss to 1340 and MaximumMss to 1340 should solve the VPN hang problem.
3.5.7
Contact Us
Need help? Contact Citrix Support. See Section 10.1.
3.6
Licensing
Starting with Release 6.0, Citrix network licensing is the normal method of obtaining licenses for Appliances. On the Quick Installation page, specifying a license server, and a Repeater/Branch Repeater model number for which licenses are available on that server, are all that is required to license the Appliance. Obviously, for the Appliance to acquire a network license, it must be able to open a connection to the network license server. The network license server must also respond to ping requests. To obtain these licenses, follow the procedure below.
3-20
June 26, 2011
3.6.1
Log Into My Citrix
Figure 3-16 Login page at http://www.MyCitrix.com.
Licenses are obtained from http://www.MyCitrix.com. You will need a login and a password. If you do not have a My Citrix account, contact your Citrix representative.
3.6.2

Exchanging Licenses From Pre-Release-5.02.0 Appliances
You need the model number of your existing Appliance for this step. You will need its host ID as well, but not yet. Select My Tools: Product Upgrade/Fulfillment. On the Product Upgrade/Fulfillment page, select Upgrade Eligible Products.
3-21
3.6 Licensing
Your existing pool of Appliances and Client licenses will be listed.
Figure 3-17 Navigating to the Product Upgrades/Fulfillment page.
Select your product line and model number on two dropdown menus and press Submit
Figure 3-18 The Upgrade Eligible Products tool.
Follow the prompts to convert the desired number of licenses to release 5.0 or later. This will generate a license entitlement on My Citrix. You will receive an email containing a license code for this entitlement. When this email arrives, go to the next procedure.
3-22
June 26, 2011
3.6.3

Obtaining a License
This step uses the Activation System/Manage Licenses tool, which is reached from the My Tools: Activation System/Manage Licenses dropdown. Select Activate/Allocate from the Current Tool dropdown. Enter the license code from the email into the License Code field. You will asked for the host ID of your license server. This can be discovered running lmhostid. Typically, this is done from the command line:
cd \Program Files\Citrix\Licensing\LS lmhostid
Follow the prompts to the end of the procedure.
Figure 3-19 Entering the license code.
At the end of this process, you will generate a license file. Download this file to your computer. You will add this to your license server in the usual way. If your Appliance supports the Repeater Plug-in (Repeater and Branch Repeater VPX Appliances do: Branch Repeater and Branch Repeater with Windows Server Appliances do not), repeat the procedure to convert Client concurrent user entitlements into a concurrent user license for the license server. If you use high-availability pairs or Appliances at disaster recovery sites, you can return and reallocate your Repeater Plug-in licenses from the first Appliance for use on a second one without losing their functionality on the first Appliance. This allows client licenses to be active in two places at once. Use the Activation System/Manage Licenses tool on My Citrix to return and reallocate the licenses. Reallocation can be done a fixed number of times (determined by Citrix). Only one copy of a license is allowed to be in use at any given time.
3-23
3.7 Check Converted Service Classes
3.6.4

Licensing Notes
If you are a Citrix Partner, you can receive Not for Resale licenses via the Partner Toolbox on My Citrix. You can find additional information at the following locations: Licensing README: http://support.citrix.com/proddocs/topic/licensing/ lic-readme.html Citrix Licensing: http://support.citrix.com/pages/licensing Obtaining License Files from My Citrix: http://support.citrix.com/proddocs/ index.jsp?topic=/licensing/lic-obtaining-your-license-files.html Citrix License Server for Windows Software and Documentation: https:// www.citrix.com/English/ss/downloads/results.asp?productID=186 Citrix WANScaler Software and Documentation: https://www.citrix.com/ English/ss/downloads/results.asp?productID=33886 Citrix Branch Repeater Software and Documentation: https://www.citrix.com/ English/ss/downloads/results.asp?productID=1350184
3.7
Check Converted Service Classes
Read this section if you are converting an Appliance from release 5.x and you defined non-default service classes. The Configuration: Service Classes page maps applications to acceleration and traffic-shaping policies. When upgrading from release 5.x, the service class definitions and policies are updated to their release 6.0 equivalents when possible, and are translated into release 6.0 otherwise. If for some reason the definition cannot be translated, the service class is disabled and flagged as shown in Figure 3-20. Possible issues include: Service classes which contained no rules. This was allowed in release 5.x, but in release 6.0 such definitions are disabled automatically. Service classes that specified a wide range of port numbers, such as 33000-34000. These can fail because they overlap the ports in an existing application definition. If a service class includes a port list or port range that includes any port from a release 6.0 application, the entire application (and thus all its ports) will be included in the updated rules. Go to the Configuration: Service Classes page and scan the definitions for ones with the red icon indicating that they are disabled. Reimplement the service classes as necessary. This may require creating new application definitions, since port ranges have been shifted from the Service Classes page to the Application Classifiers page. Scan the Traffic Shaping Policy column to ensure that the policies for the service classes are appropriate. In general: VoIP and interactive applications like the XenApp (ICA and CGP) are given higher priorities, background bulk-transfer applications are given lower priorities,
3-24 June 26, 2011
When examining service class policies:
Figure 3-20 Checking for untranslatable service classes.
and most applications are given the default priority. It is best to change as few policies as possible from their defaults until performance has been monitored for some time and a baseline has been established.
For more information on service classes, see Section 4.5.
3-25
3-26
June 26, 2011
Chapter4
TheoryofOperation
4.1

In This Section
How Acceleration Works (Section 4.2). Bandwidth Control (Section 4.3). Link Definition (Section 4.4). Service Classes and Traffic-Shaping Policies (Section 4.4). Ethernet Ports (Section 4.8). Autodiscovery and Autoconfiguration (Section 4.9). Forwarding Modes (Section 4.10-4.15). Compression (Section 4.16). CIFS (Windows Filesystem) Acceleration (Section 4.17). Microsoft Outlook (MAPI) Acceleration (Section 4.18). SSL Compression (Section 4.20). Other Features (Section 4.21). Proxy Mode (Section 4.22).
4.2
How Acceleration Works
Ordinary WANs have very poor responsiveness at high link utilization and increasing distances. This makes it impossible to use expensive WAN bandwidth efficiently. Citrix acceleration technology solves these problems through a variety of intelligent link control methods.
4.2.1
Virtual Gateway
Appliances become virtual gateways that control the TCP traffic on the link. Ordinary TCP is controlled on a per-connection basis by the endpoint device. The individual connections have almost no visibility into the state of the link or the amount of competing traffic, and this is what makes TCP sub-optimal over WAN links. A gateway, on the other hand, is in an ideal position to monitor and control link traffic. Ordinary gateways squander this opportunity. Citrix acceleration technology adds the intelligence that is missing in the network equipment and the TCP connections alike. The results is greatly improved WAN performance, even under harsh conditions such as high loss or extreme distance. The Appliance is configured as a virtual gateway with a single parameter: the bandwidth limit, which configures the link speed.
4-1
4.2 How Acceleration Works
4.2.2
Optimizations
Optimization techniques fall into these interrelated categories: 1. Lossless, transparent flow control. 2. Fair Queuing 3. WAN Optimizations 4. Compression (Section 4.16) 5. Windows Filesystem (CIFS) acceleration Section 4.17)
4.2.3
Lossless, Transparent Flow Control
Figure 4-1 Acceleration enhances performance transparently.

NETWORK A WAN WAN Router Appliance WAN Router NETWORK B
WAN Link
Transparent, AutoOptimized Acceleration LAN Link LAN Link
Appliance
One of the main benefits of Acceleration is flow control. A widely used rule of thumb for WAN links is that, once link utilization reaches 40%, its time to add more bandwidth, because performance and reliability will have degraded to the point where the link is largely unusable. Interactive performance suffers, making it hard for people to get work done, and connections frequently time out. Accelerated links dont have this problem; a link with 95% utilization is still perfectly usable. Acceleration operates on any TCP connection passing between two Appliances (one at the sending site and one at the receiving site), or a Repeater Appliance and a Repeater Plug-in. Though the figure shows a network of two Appliances, any Appliance can accelerate connections between any number of other Appliance-equipped sites simultaneously. This allows a single Appliance to be used per site, rather than two per link. Like any gateway, the Appliance meters packets onto the link. Unlike ordinary gateways, however, it imposes transparent, lossless flow control on each link segment: 1. the LAN segment between the sender and the sending Appliance, 2. the WAN segment between the sending and receiving Appliances, 3. and the LAN segment between the receiving Appliance and the receiver.
4-2
June 26, 2011
Chapter 4. Theory of Operation
By splitting the link into three parts, flow control can be managed independently for each of these three segments. By partly decoupling the segments, each can have its speed controlled independently. This is important when a connections speed needs to be ramped up or down quickly to its fair bandwidth share, and is also important as a means of supporting enhanced WAN algorithms and compression, as we shall see. The TCP protocol is greedy for bandwidth: every TCP connection continually attempts to increase its bandwidth usage. However, the link bandwidth is limited. Flow control keeps the TCP connections flowing at just the right speed. The link is never overrun, which means that queuing latency and packet losses are minimized. This bandwidth hunger of TCP connections means that long-running connections (which have had time to seize all the bandwidth) tend to squeeze out short-running connections. This ruins interactive responsiveness. Flow control keeps such greedy bulk-transfer connections from getting out of hand. Flow control is a standard feature on all Appliances.
4.2.4
Fair Queuing
The bottleneck gateway determines the queuing discipline used on the link. This is true because data in the non-bottleneck gateways doesnt back up, and without pending data in the queues, the queuing protocol doesnt matter. Most IP networks use deep FIFO queues. If traffic arrives faster than the bottleneck speed, the queues fill up and all packets suffer increased queuing times. Sometimes the traffic is divided into a few different classes with separate FIFOs, but the problem remains. A single connection sending too fast can cause large delays, packet losses, or both for all the other connections in its class. The acceleration technology uses fair queuing, which provides a separate queue for each connection. With fair queuing, a too-fast connection can only overflow its own queue. It has no effect on other connections. But with lossless flow control, there is no such thing as a too-fast connection, and queues do not overflow. The result is that each connection has its traffic metered into the link in a fair manner, and the link as a whole shows an optimal bandwidth and latency profile. Figure 4-2 shows the effect of fair queuing. Connections that want less than their fair share of bandwidth (the bottom connection) get all the bandwidth they want. In addition, they see very little queuing latency. Connections that want more than their fair share get their fair share, plus any bandwidth left over from connections that used less than their fair share. The optimal latency profile means that users of interactive and transactional applications see ideal performance, even when they are sharing the link with multiple bulk transfers. The combination of lossless, transparent flow control and fair queuing means that you can combine all kinds of traffic over the same link safely and transparently. Fair queuing relies on the link definitions (Section 4.4) and the traffic-shaping policies (Section 4.6), which allow weighted fair queuing, so some traffic can be given a higher priority than others.
4-3
4.2 How Acceleration Works
Figure 4-2 Fair queuing in action.

Data Streams
DATA ACK
Per-Connection Queues
DATA ACK
Scheduler
DATA ACK
4.2.5
WAN Optimizations
Most TCP implementations do not perform well over WAN links. To name just two problems, the standard TCP retransmission algorithms (Selective Acknowledgments and TCP Fast Recovery) are inadequate for links with high loss rates, and do not consider the needs of short-lived transactional connections. Acceleration technology implements a broad spectrum of WAN optimizations to keep the data flowing under all kinds of adverse conditions. These work transparently to ensure that the data arrives at its destination as quickly as possible. WAN optimization operates transparently and requires no configuration. WAN optimization is a standard feature on all Appliances. Figure 4-3 shows transfer speeds possible with and without acceleration. The diagonal line separates what connection speeds are possible without acceleration from those that require it. For example, gigabit throughputs are possible within a radius of a few miles, 100 Mbps is attainable to less than 100 miles, and throughput on a worldwide connection is limited to less than 1 Mbps, regardless of the actual speed of the link. With Acceleration, the area above the line in Figure 4-3 becomes available to applications. Distance is no longer a limiting factor. Transfer performance is approximately equal to the link bandwidth. The transfer speed is not only higher than with unaccelerated TCP, but is much more constant in the face of changing network conditions. The effect is to make distant connections behave as if they were local. User-perceived responsiveness remains constant regardless of link utilization. Unlike normal TCP, where a WAN operating at 90% utilization is useless for interactive tasks, an accelerated link will have the same responsiveness at 90% link utilization as at 10%. With short-haul connections (ones that fall below the line in Figure 4-3), little or no acceleration will be seen under good network conditions, but if the network becomes degraded, performance will drop off much more slowly than with ordinary TCP. Non-TCP traffic, such as UDP, is not accelerated. It is still managed by the traffic shaper, however.
4-4 June 26, 2011
Figure 4-3 Non-accelerated TCP performance plummets with distance

One-Way Distance (Miles) 100,000 ADSL T1 10 Mb/s T3 Cross-City (MAN) 10,000
Dialup
Worldwide Cross-Country Cross-State
Long-Haul (Limited by TCP)
1,000
Short-Haul (Limited by Line Speed)
100 Mb/s OC-3 OC-12 1Gb/s OC-48 OC192 10 Gb/s
100
10
Cross-Campus
0.01
0.1
1.0
10 100 Connection Speed (Mb/s)
1,000
0.1 10,000
Without Citrix acceleration, TCP throughput is inversely proportional to distance, making it impossible to extract the full bandwidth of long-distance, high-speed links. With Acceleration, the distance factor disappears, and the full speed of a link can be used at any distance. (Chart based on model by Mathis, et al, Pittsburgh Supercomputer Center.)
4.2.5.1 Transactional Mode

One retransmission optimization is called transactional mode. A peculiarity of TCP is that, if the last packet in a transaction is dropped, its loss will not be noticed by the sender until a receiver timeout (RTO) period has elapsed. This delay is always at least one second long, and is often longer. This is the cause of the multi-second delays seen on lossy links delays that make interactive sessions unpleasant or impossible. Transactional mode solves this problem by retransmitting the final packet of a transaction after a brief delay. This means that an RTO will not happen unless both copies are dropped; an unlikely event. Since the average packet is part of a bulk transfer, and a bulk transfer is basically a single enormous transaction, the bandwidth demands of this optimization are modest, consuming as little as one packet per file. However, interactive traffic, such as keypresses or mouse movements, often consists of a single undersized packet per transaction, and this traffic (such as it is) can be doubled. In effect, transactional mode provides forward error correction (FEC) on interactive traffic, and gives end-of-transaction RTO protection to other traffic.
4-5
4.3 Acceleration Modes
4.3
4.3.1
Acceleration Modes
Bandwidth Management Modes
There are two bandwidth management modes: softboost and hardboost. Softboost uses a rate-based sender that sends accelerated traffic at speeds up to the links bandwidth limit. If the bandwidth limit is set slightly lower than the link speed, packet loss and latency will be minimized, while maximizing link utilization. This means that interactive applications see fast response times while bulk-transfer applications see high bandwidth. Softboost will share the network with other applications in any topology and will also interoperate with third-party QoS systems. Hardboost is more aggressive than softboost. By ignoring packet losses and other so-called congestion signals, it performs very well on links plagued with heavy, non-congestion-related losses, such as satellite links. It is also excellent on low-quality, long-haul links with a high background packet loss, such as are seen in many overseas links. Hardboost is recommended only for point-to-point links that do not achieve adequate performance with softboost. Note: Hardboost should be used only on fixed-speed point-to-point links or hub-and-spoke deployments where the hub bandwidth is equal to (or at least close to) the sum of the spoke bandwidths. Note: Softboost and hardboost are mutually exclusive, which means that all the Appliances that must communicate with each other must be set the same. If one unit is set to hardboost and the other is set to softboost, no acceleration will take place.
4.3.2
How the Appliance Allocates Bandwidth
The Appliance uses a rate-based sender for WAN traffic, sending packets based on a bandwidth limit that is set manually for each link. The rate at which an Appliance sends accelerated data depends on several parameters: The bandwidth limit, set on the Configuration: Links page of the management interface. This value limits the maximum rate at which both accelerated and non-accelerated traffic will be sent or received on any individual link. Separate limits are placed on sending and receiving, to accommodate asymmetric links For hardboost, a second bandwidth limit is also used, that limits accelerated bandwidth (only) independently of the link speed. Normally, these two limits are the same. This is set on the Hardboost/Softboost tab on the Configuration: Links page. The licensed bandwidth limit, which is the highest value that can be entered in the sending BW limit field. This is controlled by the Appliances license. The receiving limit is unconstrained. The license key is preinstalled into your unit. Updated keys can be installed through the management interface. See Section 8.4.4.
4-6
June 26, 2011
4.3.3
An Appliance Should Become The Bottleneck Gateway
The fair queuing algorithm used by Appliances traffic shaper is more sophisticated than typical router-based QoS. To take advantage of this, the bandwidth limit of the Appliance should be set slightly lower than the link speed, when possible. By injecting packets into the network slightly slower than the link speed, they never back up in the router, which minimizes queueing. Normally a setting of approximately 95% of the link speed gives optimum results. For variable-speed links, the bandwidth limit should be set to 95% of the maximum expected speed. Note: Hardboost is recommended for fixed-speed links only. If used with a variable-speed link, the bandwidth limit must not exceed that of the guaranteed bandwidth (committed information rate). Example 1: On a 1.5 mbps point-to-point link with a bit rate of 1.54 mbps, set the sending and receiving bandwidth limits to 95% of 1.54 mbps, or 1463 kbps. Either hardboost or softboost can be used. Example 2: Suppose you have a simple hub-and-spoke deployment. Site 1 has two T1 links, one terminating at Site 2 and one terminating at Site 3. If all three sites have Appliances, then the hub Appliance would have its bandwidth limits set to 95% of the aggregate bandwidth (twice the value in Example 1, or 2926 kbps). The Appliances at the two spokes would set their bandwidth limits as in Example 1 (1463 kbps). Either hardboost or softboost can be used Note: Set the bandwidth limits to match the speed of its local link, without regard to the speed at the other end of the WAN. This simplifies configuration and allows each unit to be installed with knowledge of the local links only. (The only exception is when there is an intermediate bottleneck that is slower than either endpoint link. This rare situation is dealt with by using the intermediate bottleneck speed on affected Appliance, instead of the local speed.) Example 4: Suppose you have a three-site deployment, but instead of hub-and-spoke, each site connects to a network cloud with a 1.5 mbps link. This is no longer hub-and-spoke, but a mesh. Each site would have the same bandwidth limits (95% of a t1s 1.54 mbps, or 1453 kbps). Hardboost works poorly in mesh deployments, so softboost should be used. Example 6: A link which has a guaranteed data rate of 2.0 mbps and a peak data rate of 5.0 mbps should receive a softboost bandwidth limit of 90-95% of 5.0 mbps, or 4500-4750 kbps, but a hardboost bandwidth limit of 90-95% of 2.0 mbps, or 1800-1900 kbps. Example 7. Suppose a central office has a site-to-site VPN running at 45 mbps, and a certain branch office has a DSL link with a 6 mbps download speed and a 384 kbps upload speed. The central office Appliance should be set for 95% of 45 mbps, or 42750 kbps, while the branch-office Appliance should have its sending speed set for 95% of 384 kbps (365 kbps) and its receiving speed set for 95% of 6 mbps (5700 kbps). If the sum of all the branch-office Appliances does not exceed 45 mbps in either direction, hardboost can be used. Otherwise, softboost should be used.
Branch Repeater Family Installation and Users Guide, rel. 6.0 4-7
4.4 Link Definitions and Traffic Shaping
4.3.4
Performance Tuning
For initial testing, a value of 95% of the link bandwidth is a good starting point. One simple method of setting the bandwidth limit is: 1. Create enough accelerated bulk-transfer traffic to fill the link at the current bandwidth limit (using FTP, iperf, or some other transfer program). 2. Monitor transfer bandwidth in the Appliance UI -- preferably on the receiver-side Appliance -- using the Monitoring: Usage Graph page. 3. In a separate window, run ping continuously, using a site on the far side of the link as a target (the remote Appliance will do). Under Linux, the ping command issues one ping per second until stopped, by default. Under Windows, use the ping -t hostname command. 4. Adjust the bandwidth limit on the Appliances. As the bandwidth limit increases, you will reach a point where ping time start to go up but throughput remains flat or declines. The bandwidth should be set at a point where the ping time is near its minimum but the throughput is near the maximum. This is usually, but not always, between 90% and 100% of the nominal link speed. With hardboost, setting the bandwidth limit even slightly higher than the link bandwidth will degrade performance. This problem often occurs when the link does not actually support 100% of its nominal rate. This phenomenon is very obvious in hardboost, since it leads to heavy packet losses. In softboost, it merely causes latency to become uncontrolled.
4.4
Link Definitions and Traffic Shaping
Release 6.0 introduces a new traffic-shaping engine that manages all the traffic on your WAN links, in both the incoming and outgoing directions. It replaces the previous system, Repeater QoS, which operated only on accelerated traffic and in the sending direction only. Note: When upgrading an Appliance from release 5.x to release 6.x, any Repeater QoS definitions will be converted to traffic-shaping policies automatically. For example, if a QoS category of Queue A was assigned 30% of the link in release 5.x, this will be converted into a traffic-shaping policy called Queue A with a priority of 30. For the release 5.x default case, where 100% of the link was assigned to Queue A, no conversion is done, and the release 6.0 defaults are used instead. The Repeater traffic shaper is an easy-to-use solution for link congestion. For a simple inline installation, configuring it requires just four parameters: LAN port, WAN port, link upload bandwidth, and link download bandwidth. While highly configurable for sites with special needs, the default traffic-shaping settings are fine for most installations, providing these benefits:
4-8
Quick response times for interactive traffic such as XenApp and XenDesktop. Protection of latency- and jitter-sensitive VoIP traffic.
June 26, 2011
Eliminates hitting the wall during peak periods, providing usable performance even under extreme load. Allows bulk transfers to fill the link with whatever bandwidth is left over from interactive tasks. Extends the benefits of fair queuing to all traffic, when in previous releases it was available only to accelerated traffic.
4.4.1
Comparison with Release 5.x QoS
Release 6.0s traffic shaping replaces the Repeater QoS function of release 5.x. Traffic shaping works on different principles than Repeater 5.x QoS and any settings cannot be migrated when you upgrade to release 6.0. Advantages of traffic shaping over the old system include: All link traffic is shaped, not just accelerated connections. The old system of having five queues has been replaced with a single queue using per-connection weighted fair queuing. The improved application classifier allows more fine-grained control over traffic shaping.
4.4.2
Traffic Shaping Basics
Like previous releases of Repeater, the traffic shaper is based on bandwidth-limited fair queuing, meaning that every data stream gets its fair share of the link bandwidth. If the link is idle, any connection can use the entire link. Once there are multiple connections that compete for the link bandwidth, each gets its fair share of the link bandwidth in a controlled way. Some highlights of the traffic shaper: All WAN traffic is subject to traffic shaping: accelerated connections, non-accelerated connections, and non-TCP traffic such as UDP flows, GRE streams, etc. The algorithm is weighted fair queuing, where every connection is assigned a weighted priority based on the appliances policies. A connection with a weighted priority of 100 will get twice the bandwidth as a connection with a weighted priority of 50. The range of connection weights is from 1 to 256. See Figure 4-4. Weighted priorities give each connection its fair share of the link bandwidth, since priorities are applied to the actual WAN data transferred, after compression. This means that, if you have two data steams with the same priority, one achieving 10:1 compression and the other achieving 2:1 compression, the two data streams will transfer equal amounts of data over the WAN, but the data as seen by the user will be ten times this amount for the 10:1 stream and twice this amount for the 2:1 stream. In practice, this disparity is desirable, since WAN bandwidth, and not application bandwidth, is the scarce resource that needs to be managed. The weighted priority is based on the network protocol or application, which is detected by the classifier and used to select the traffic-shaping policy. (The classifier is also used for generating reports.) Traffic shaping applied to the WAN link in both the sending and receiving directions, to both accelerated and non-accelerated traffic. This prevents congestion and increased latency even when the other side of the link is not equipped with Branch Repeater. For example, it will prioritize and manage Internet downloads.
4-9
In addition so shaping the traffic directly, the traffic shaper can affect it indirectly by setting the DSCP (differentiated services code point) field to inform downstream routers about the type of traffic shaping each packet requires.
Figure 4-4 Weighted fair queuing.
Per-Connection Queues Weight = 3
Weight = 2 Traffic Shaper Weight = 1
Output Data Stream
4.4.3
Configuring Traffic Shaping

Acceleration Parameters
Figure 4-5 Control flow for acceleration and packet shaping.
Packet Data
Classifier
Application
Service Class Policies

Traffic Shaping Parameters
Acceleration Engine Traffic Shaper
Application Definitions
Service Class Definitions
Traffic Shaping Policies
Traffic shaping is controlled by four sets of parameters: 1. Link definitions, which tell the traffic shaper which WAN link the packet is using. In a site with multiple link, each link has its own bandwidth limits and is managed independently. 2. Application definitions, which tell the classifier which protocol or application the traffic belongs to. 3. Traffic-shaping policies, which tell the traffic shaper what weighted priority and other parameters to use. 4. Service class rules, which map applications, IP addresses, etc. to acceleration and traffic-shaping policies.
4-10 June 26, 2011
In a typical installation, only the link definitions must be configured. The others can be left at their default values, and only changed if a problem arises and new definitions are needed. This is the recommended method of deploying the product. All parameters are described in Chapter 8.
4.4.4
Defining a Link
Figure 4-6 Link definition tab, collapsed (top) and expanded (bottom)
Traffic shaping relies on an accurate link definition, which tells the appliance which traffic is LAN traffic and which is WAN traffic. The Configuration: Links page shows the currently defined links, either as a listing (collapsed) or in summary form (expanded). By default, the following links are defined but not configured: 1. apA.1, one of the two ports on the accelerated bridge. 2. apA.2, the other port on the accelerated bridge. 3. If the system has dual accelerated bridges, apB.1 and apB.2 also exist. 4. All Other Traffic, which is not a true link, but is a catch-all for traffic that doesnt match any actual link definitions.
4-11
The two motherboard ports, Primary and Aux1, can also be defined as links, but doing so rarely serves any purpose, since they are used for management and as a back-channel for high-availability and group modes rather than WAN traffic. Allowing their traffic to fall under the All Other Traffic category is usually best.
4.4.4.1 What is a Link?

For our purposes, a link is a physical link, typically a cable that leaves the building. It is an actual, physical link with its own capacity: A VLAN is not a link. A virtual link is not a link. A VPN tunnel is not a link. Other tunnel arent links, either.
4.4.4.2 Information Needed to Define a Link

The Links list is pre-populated with the apA.1 and apA.2 placeholder links, which are not fully defined by default and will require editing. The traffic shaper needs the following information if a link is to be managed: 1. The speed of the link in both the send and receive directions. 2. Whether the link is a WAN link or a LAN network. 3. A way of distinguishing link traffic from other traffic. All of these are defined on the Create/Edit Link page, which is reached from the Configuration: Links: Link Definition tab. Link Speed. When talking about link speed, we always mean the speed of the physical WAN segment that terminates in the building with the Repeater. The speed of the other end of the link is not considered. This is shown in Figure 4-7, which shows a network of four appliances. Each appliance has its incoming and outgoing bandwidths set to 95% of the speed of its own, local WAN segment, without regard to the speed of the other appliances. This is a general rule with Repeater configuration: configuration considers only local conditions, not the conditions at the remote sites.
Figure 4-7 Local bandwidth limits track local link speeds.
2 mbps 10 mbps 2 mbps 1 mbps
Configured for 2 mbps Configured for 2 mbps Configured for 1 mbps
Configured for 10 mbps
The reason the bandwidth limits are set to 95% of the link speed instead of 100% is to allow for link overhead (few links can carry data at 100% of their published speeds) and to ensure that the appliance is slightly slower than the link, so that it becomes a slight bottleneck. Traffic shaping is not effective unless the traffic shaper is itself the bottleneck, so it must be set slightly slower than the actual link throughput.
4-12 June 26, 2011
Telling a WAN Link From a LAN Network. In each link definition, the user declares whether the definition is a WAN link or LAN network. This is used to categorize traffic, as described below. Distinguishing Link Traffic From Other Traffic. The traffic shaper needs to know whether a packet is traveling on the WAN, and, if so, in what direction. For simple inline deployments, this is done by declaring that one port of the accelerated bridge belongs to the WAN link and that the other port belongs to the LAN. In other deployment modes, this is done by examining IP addresses, MAC addresses, VLANs, or WCCP service groups. When a site has multiple WANs, then the link definitions must have rules that allow the appliance to tell traffic from different WANs apart.
4.4.4.3 Defining a Link

Ordered Lists of Links, Ordered Lists of Rules. The link definitions arranged in an ordered list, one entry per link, which are tested from top to bottom. The first matching rule is used. Within each link definition is an ordered list of rules, which is also tested from top to bottom. Each packet is compared to these rules, and if it matches one of them, then the packet is considered to be traveling over that link. Within a rule, the fields are all ANDed together, so all specified values have to match. All fields default to Any, a wildcard entry that always matches. When a field consists of a list, such as a list of IP subnets, these are ORed together: that is, if any element matches, then the list as a whole is considered to be a match.
Figure 4-8 Link definition rules.
4-13
4.4.4.4 Example: Simple Inline Link

Figure 4-9 Simple inline link example.
Branch Repeater
apA.2
172.16.0.0/24
apA.1
ADSL 1.0 mbps send
Internet
6.0 mbps receive

Incoming BW = 0.95 x 6.0 mbps Outgoing BW = 0.95 x 1.0 mbps
In this example, all traffic passing through the accelerated bridge is assumed to be WAN traffic. The link is an ADSL link with different send and receive speeds (6.0 mbps down, 1.0 mbps up). The WAN is connected to accelerated bridge port apA.1, and the LAN is connected accelerated bridge port apA.2. See Figure 4-9. This link is very easy to specify on the Edit Links page. See Figure 4-10. The tasks on the WAN link (apA.1) are: 1. Give the WAN a descriptive name, such as WAN to Headquarters (apA.1). 2. Set the type to WAN. 3. Set the incoming and outgoing bandwidth limits to 95% of the nominal link speed. 4. Verify that a rule has been defined that specifies the WAN Ethernet adapter, which in this example is apA.1 5. Press Save. The tasks on the LAN link (apA.2) are similar: 1. Give it a descriptive name, such as Local LAN (apA.2). 2. Set the type to LAN. 3. Set the incoming and outgoing bandwidth limits to 95% of the nominal Ethernet speed (95 mbps or 950 mbps). 4. Verify that a rule exists that specifies the LAN Ethernet adapter, which in this example is apA.2. 5. Press Save.
4-14
June 26, 2011
Figure 4-10 WAN definition (top) and LAN definition (bottom).
4-15
4.4.4.5 Example: Inline Deployment with Dual Bridges

Figure 4-11 Inline, dual-bridge link example.
Repeater
apA.2 apB.2 apA.1 apB.1
6/1 mbps
Internet
1.5/1.5 mbps 172.16.0.0/24 10.0.0.0/8
WAN
This example is similar to the previous one, but the site has a second link, a T1 link to the corporate WAN, in addition to the ADSL Internet link. The Repeater has two accelerated bridges, one for each WAN link. Configuration is almost as simple as the single-bridge case, with the following additional steps: 1. Edit a second WAN link on apB, which in this case is apB.1. Set the type to LAN. The link bandwidth is set to 95% of the 1.5 mbps T1 speed, and the link is given a new name, such as WAN to HQ. 2. Add a rule specifying apB.2 to the LAN definition and delete the default link definition for apB.2. (Alternatively, you can edit the default link definition for apB.2 to specify it as a LAN link, as was done for apA.2.)
4-16
June 26, 2011
4.4.4.6 Example: Using IP Addresses in Link Definitions

Figure 4-12 Simple inline LAN definition using IP-based rules.
Branch Repeater
apA.2
172.16.0.0/24
apA.1
ADSL 1.0 mbps send
Internet
6.0 mbps receive

Incoming BW = 0.95 x 6.0 mbps Outgoing BW = 0.95 x 1.0 mbps
You can use IP subnets instead of bridge ports to distinguish LAN traffic from WAN traffic. This is essential in one-armed (non-inline) deployments, where only a single bridge port is used. IP subnets are sometimes useful for inline deployments as well. The traffic classifier uses the Src IP and Dst IP fields in a specialized way: The Src IP field is only examined on packets entering the appliance. The Dst IP is only examined on packets exiting the appliance.
This convention allows the direction of packet travel to be implicitly considered as part of the definition. In the example in Figure 4-12, the LAN can be defined without specifying apA.2, and instead specifying a Src IP of 172.16.0.0/24 and a Dst IP of 172.16.0.0/24 as two separate rules. Packets entering the appliance from the LAN will have a src IP matching the local subnet of 172.16.0.0/24. This be compared against the Src IP field, and will match. Packets leaving the appliance and entering the LAN will be compared against the Dst IP field and will also match. On the WAN side, however, packets entering the appliance from the WAN will be compared against the Src IP field and will not match (their src IP will be from some other subnet), and packet leaving the appliance onto the WAN will be compared against the Dst IP field and will also not match. It takes two rules to define the link because putting 172.16.0.0/24 in both the Src IP and the Dst IP fields of a single rule would match only the traffic that met both criteria, which is not what we want. (Statements in a single filter rule are ANDed together.)
4-17
4.4.4.7 Example: WCCP and Virtual Inline Modes

Figure 4-13 WCCP or virtual inline deployment using IP-based rules.
LAN
172.16.0.0/24 10.0.0.0/8
WAN
Configuration of this WCCP link is identical to the previous example, because IP-based definitions are indifferent to considerations such as the bridge port in use. The local LAN is defined by the local subnet (172.16.0.0/24), and the LAN definition is placed at the top of the Links list. The WAN is defined with an empty filter rule, which matches all traffic that does not match the LAN. While the link definition itself is indifferent to whether the deployment mode is inline or WCCP, WCCP mode still requires configuration in your router and on the Configuration: Advanced Deployments page. This same link definition would also work for virtual inline mode.
4.4.4.8 Example: Inline with One Bridge and Two WAN Links
This dual-link example uses a single bridge. The two WAN links can be differentiated by their addresses: one serves the corporate WAN at 10.0.0.0/8, and the other serves the Internet as a whole. The second WAN needs to be defined and placed above the Internet link in the ordered list. (In general, rules need to be ordered with the most specific definitions at the top and the most general ones at the bottom.) The corporate WAN link is defined as follows:
4-18 June 26, 2011
Figure 4-14 Inline, dual-link example.
Repeater
apA.2 apA.1
6/1 mbps
Internet
172.16.0.0/24
1.5/1.5 mbps 10.0.0.0/8
WAN
Configuration is almost as simple as the single-bridge case, with the following steps: 1. Start by creating the configuration from Section 4.4.4.4. 2. Create a new link with the Create button. 3. Set the type to WAN. 4. Set the incoming and outgoing bandwidth limits to 1425 kbps (95% of the nominal link speed). 5. Create two rules that specify the WAN Ethernet adapter, which in this example is apA.1 and the IP address range of 10.0.0.0/8. This address range is put in the Src IP field of one rule and the Dst IP field of the other rule. 6. Press Save. 7. When you expand the definitions on the Link Definition page, they should match those in Figure 4-14.
4-19
4.5 Service Class Policies
4.5
Service Class Policies
Service classes determine traffic-shaping policies and acceleration policies. In previous releases, service-class policies mapped protocols and applications solely to acceleration decisions, and acceleration decisions applied only to accelerated connections. Release 6.0 expands service classes to select a traffic-shaping policy in addition to an acceleration policy: Traffic-shaping policies apply equally to both accelerated and non-accelerated traffic. This means that an accelerated XenApp connection and a non-accelerated one both receive traffic shaping, so both can receive an elevated priority compared to bulk traffic. Traffic-shaping policies control non-TCP traffic as well as TCP traffic, meaning that sensitive real-time traffic like VoIP (which uses the UDP protocol), can be expedited. Service classes can now be based on a greatly expanded list of parameters, including: applications, protocols, URLs, Citrix published applications, IP or VLAN addresses, DSCP bits, and SSL profiles.
The traffic policy for a service class can be specified on a per-link basis if desired.
The default service-class policies are recommended as a starting point. Modify them if they prove inadequate for your link. As in previous releases, the service classes are an ordered list, and the first matching policy is used. See Figure 4-15.
4.5.0.1 Differences Between Acceleration Policies and Traffic Shaping Policies

Acceleration policies are applied based on the contents of the initial SYN packet of a TCP connection. Once applied, the acceleration policy lasts for the duration of the connection. This means that, to be effective, an acceleration policy has to be based on a test (or filter rule) that applies to the initial SYN packet. This means that virtually all service classes intended for accelerated traffic are defined in terms of well-known port numbers, such as port 80 for HTTP. Tests based on IP addresses also work. The traffic-shaping policy is not a permanent decision, since it can be based on deep packet inspection, which may not return a definitive answer on the first packet of the data flow. So the traffic-shaping category may change from the initial decision, based on the first packet, to the later, more definitive one.
4-20
June 26, 2011
Figure 4-15 Default service-class list.
For example, an http connection to http://www.google.com opens with connection is a SYN packet that contains a header but no payload. The header will have an IP destination port of 80, and this will match the HTTP: Internet service class definition. The accelerator will base its acceleration decision (in this case, No acceleration) on this service class. The traffic shaper will use the traffic-shaping policy from the HTTP: Internet service-class policy temporarily. However, when the first payload packet is seen by the classifier, it will contain the string GET http://www.google.com, and this URL will match the Google application definition. If there is a service class definition that uses the Google application, the traffic shaper will start using that service class. Regardless of the service class policy, the reporting will track the usage of the Google application.
Remember: all traffic has an application and a service class, and all service classes have a traffic shaping policy. Only TCP connections have an acceleration policy.
4.5.0.2 Using Service Class Policies

The more specific policies must be above more general ones on the service-class page. For example: Service classes based on URLs must be above the HTTP service classes in the service-class list.
4-21
4.6 Traffic Shaping Policies
Service classes based on ICA (XenApp/XenDesktop) published applications must be above the ICA service class.
This is because the first matching rule is used, and since all URL-based rules will match the HTTP service class, putting the HTTP service class above them will mean that the URL-based rules or published application-based rules would never be used.
4.6
Traffic Shaping Policies
The service class policy selects a traffic-shaping policy from the list, and the traffic-shaping policy sets the following parameters for the traffic: Weighted Priority (1-256). Higher weighted priorities mean more bandwidth. A connection with a weighted priority of 256 are entitled to 256x the bandwidth of a connection with a weighted priority of 1. (In practice, these bandwidth ratios will only be seen in bulk-transfer traffic where the traffic shaper is the dominant bottleneck. Protocols that are RTT-limited, interactive, or contain their own bandwidth managers Citrix XenApp falls into all three categories will show different ratios, because other factors besides the traffic shaper are also affecting the traffic.) ICA priorities. Usually used only on the Citrix policy. This declares a mapping between the four XenApp/XenDesktop priority bits and traffic shaper weighted priorities. See Section 4.6.1. Optimize for Voice. Handle with care. This option gives the traffic a weighted priority of infinity, meaning that it will monopolize the link if there is enough traffic to do so. Use only for VoIP data traffic (not VoIP control traffic) Always use a maximum bandwidth policy with this feature, such as 75% of link speed. Never use this feature for TCP traffic.
Set Diffserv/TOS. Sets the DSCP bits on output packets to the selected value. Used to control downstream routers. For ICA (XenApp/XenDesktop) traffic, each of the four ICA priority values can be tagged with a different DSCP value. This is particularly valuable with the new Multistream ICA feature, where the XenApp or XenDesktop client uses different connections for different priority levels. Limit Bandwidth. Prevents the traffic using this policy from exceeding the specified bandwidth, stated either as a percentage of link speed (preferred) or as an absolute value. Percentages are recommended so that the same definitions can apply to links of different speeds. This feature will leave bandwidth on the table. For example, if you have a policy set to 50% of link speed, it will not allow the affected traffic to use more than 50% of the link, even if the link is otherwise idle. Throttling traffic in this way is inconsistent with maximum performance, so this feature is rarely used except with VoIP traffic using the Maximize for Voice setting.
4-22
June 26, 2011
The default policies span a broad range of priorities, with each policy separated by its neighbors by a factor of two in priority. Note that, with the exception of the Default Traffic Shaping policy, the default policies cannot be edited or deleted, to ensure that they have the same meaning on all appliances. To make changes, create a new traffic-shaping policy with the new parameters and change the appropriate service-class policies to refer to the new traffic-shaping policy. See Figure 4-16.
Figure 4-16 Creating a new traffic-shaping policy
4.6.1
XenApp/XenDesktop Policies
The two-bit ICA priority field in the Citrix ICA and CGP protocols used by XenApp and XenDesktop can be used to assign different traffic-shaping priorities to different XenApp/XenDesktop traffic. (The controls for this are on the Configuration: Traffic Shaping Policies: Create Policy page, but are hidden by default. Press the Show All Advanced Options button to show these options. (See Section 8.4.13 for more information on this page.) These options support both single-connection and multi-connection ICA/CGP streams. In single-connection streams (the traditional ICA/CGP implementation) all four priorities are multiplexed in a single connection. The newer multi-connection option uses different connections for different priority levels. ICA priorities can be mapped to DSCP values in the IP header, informing the downstream routers about the kind of handling each packet requires. Note that, if you change the state of the Set ICA Priorities checkbox for a traffic-shaping policy, existing connections under that policy will be reclassified as Other TCP traffic for the rest of their lifetimes. They cannot be transferred from one ICA traffic-shaping state to another.
4-23
4.6 Traffic Shaping Policies
Figure 4-17 Creating an ICA traffic-shaping policy that specifies per-priority DSCP values.
4-24
June 26, 2011
4.7
Application Classifiers
The classifier uses application definitions to divide the traffic into protocols and applications. This is used to create reports and by the service-class mechanism. Many applications are already defined, and you can define more as needed. The following top-level classifications are available: Ethertype List Citrix Published Application Name IP Protocol Number List TCP Port List UDP Port List Web Address (URL)
See the Create Application page in Figure 4-18.

Figure 4-18 Defining a new application
The application classifier uses the official protocol and port specifications from the IANA (Internet Assigned Numbers Authority), http://www.iana.org. Sometimes applications other than the official ones will use a port. The classifier generally cant tell when this happens. When your network uses such applications, this problem can generally be resolved going to the application classifier and renaming the application from its official name to its actual name. Applications must not have overlapping definitions. For example, if you had one application that uses TCP ports 3120 and 3128, and another application that uses port 3120 only, you cannot specify port 3120 in both definitions.
4-25
4.8 Ethernet Ports
4.8
Ethernet Ports
A typical Appliance will have four Ethernet ports: two bridge ports with a bypass (fail-to-wire) relay, and two motherboard ports. The bridged ports provide acceleration. The motherboard ports can be used for secondary purposes. Most installations use only the bridged ports. Note: Acceleration is supported only on Accelerated Pairs. The Primary and Aux1 ports are for UI and group-mode backchannel access. Some Branch Repeater units will have only the motherboard ports. In this case, the two motherboard ports are bridged.
Figure 4-19 Ethernet ports.
4-26
June 26, 2011
The ports are named as follows:

Figure 4-20 Ethernet port names.
Motherboard port 1 Motherboard port 2 Bridge #1 Bridge #2 Primary (or apA.1 if no bypass card is present) Auxiliary1 or Aux1 (or apA.2 if no bypass card is present) Accelerated Pair A (apA, with ports apA.1 and apA.2) Accelerated Pair B (apB, with ports apB.1 and apB.2)
4.8.1
Bridged Ports
Bridges can act in inline mode, where they act as a transparent bridge, as if they were an Ethernet switch. Packets flow in one port and out the other. Bridges can also act in single-ended mode, where packets flow in one port and back out the same port. Bypass card (optional). If the Appliance loses power or fails in some other way, an internal relay closes and the two bridged ports are connected electrically. This maintains network continuity but makes the bridge ports inaccessible.
4.8.2
Motherboard Ports
While the Ethernet ports on a bypass card are inaccessible when the bypass relay is closed, the motherboard ports remain active. You can sometimes access a failed Appliance from the motherboard ports when the bridged ports are inaccessible.
4.8.3

Port Parameters
Each bridge and motherboard port can be: Enabled or disabled Assigned an IP address and netmask Assigned a default gateway Assigned to a VLAN Set to 1000 mbps, 100 mbps, or 10 mbps at full or half duplex
All of these parameters except the speed/duplex setting are set on the Configure Settings: IP Address page. The speed/duplex settings are set on the Configure Settings: Interface page. Notes about parameters: Disabled ports will not respond to any traffic. The browser-based UI can be enabled or disabled independently on all ports. To secure the UI on ports with IP addresses, select HTTPS rather than HTTP on the UI page. Inline mode works even if a bridge has no IP address; all other modes require that an IP address be assigned to the port. Traffic is not routed between interfaces. For example, a connection on bridge apA will not cross over to the Primary or Aux1 ports, but will remain on bridge apA. The entire issue of routing is left to your routers.
4-27
4.8 Ethernet Ports
4.8.4
The Primary Port
If the Primary port is enabled and has an IP address assigned to it, the Appliance takes its identity from it. That is, UI displays on other units will report this IP address. When the Primary port is not enabled, the IP address of Accelerated Pair A is used. The Primary port is used for: Administration via the Web-based UI. A backchannel for group mode (See Section 4.15). A backchannel for high-availability mode (See Section 7.5).
4.8.5
The Aux1 Port
The Aux1 port is identical to the primary port. If the Aux1 port is enabled and the Primary port is not, the Appliance takes its identity from the Aux1 ports IP address. If both are enabled, the Primary port sets the units identity.
4.8.6
Using Multiple Bridges
When two or more accelerated bridges are present, they can be used to accelerate two different links. These links can either be fully independent or they can be redundant links, connecting to the same site. Redundant links can be either load-balanced or main-link/failover-link pairs.
Figure 4-21 Using dual bridges
LAN LAN Two Accelerated Bridges
LAN LAN Two Accelerated Bridges LAN LAN HA Pair
Load-Balanced WAN Links
WAN WAN
To handle load-balanced links, the bridges use the following algorithm: when it is time to send a packet for a given connection, it is sent out whichever bridge has received the most recent input packet. Thus, the Appliance honors whatever link decisions was
4-28
June 26, 2011
made by the router, and automatically tracks the load-balancing or main-link/ failover-link algorithm in real time. For non-load-balanced links, this same algorithm also ensures that packets will always use the correct bridge. WCCP and Virtual Inline Modes. Multiple bridges are supported with both WCCP and virtual inline modes (not shown). Usage is the same as the single-bridge case, except that WCCP has the additional limitation that all traffic for a given WCCP service group must arrive on the same bridge. Only One Bandwidth Limit. A system with two accelerated pairs still has only one bandwidth limit. If the pairs are attached to different WAN links, there is no way of specifying a per-link bandwidth limit. In the deployments shown above, this is not an issue; both accelerated pairs service the same link. In cases where this is not the case, softboost mode must be used, since hardboost mode cannot tolerate any ambiguity about link speed. High Availability with Multiple Bridges. Two units with multiple bridges can be used in a high-availability pair. Simply match up the bridges so that all links pass through both Appliances. (See Section 7.5 for more about high availability mode.)
4.9
Autodiscovery and Autoconfiguration
Acceleration units detect each others presence automatically, in a patent-pending process called autodiscovery. This is done by attaching TCP header options to the first packets in each connection -- the SYN packet (sent by the client to the server to open the connection), and the SYN-ACK packet (sent by the server to the client to indicate that the connection has been accepted). By tagging the SYN packets and listening for tagged SYN and SYN-ACK packets, the Appliances can detect each others presence in real time, on a connection-by-connection basis. The autodiscovery process is shown in Figure 4-22. The main benefit of autodiscovery is that you do not have to reconfigure all your Appliances every time you add a new one to your network; they find each other automatically. In addition, the same process allows autoconfiguration. The two Appliances use the TCP header options to exchange operating parameters, including the bandwidth limits (in both the sending and receiving directions), the basic acceleration mode (hardboost or softboost), and the acceptable compression modes (disk, memory, or none). Everything an Appliance needs to know about its partner is exchanged with each connection, allowing per-connection variations; for example, per-service-class variations in the allowable compression types.
4.9.1
Firewall Considerations
The use of TCP options puts accelerated traffic at risk from firewalls that are overly enthusiastic about denying service to connections using uncommon TCP options. The most usual firewall action is to strip off the unknown options and then forward the packet. This prevents acceleration but does not impair connectivity. A small fraction of Web sites deny service to connections with unknown options. That is, the Appliance-tagged SYN packets are dropped. The Appliance notices when connection attempts have failed repeatedly and will retry without the options. This restores connectivity after a delay of variable length, but usually in the range of 20-60 seconds.This behavior has not been seen on ordinary commercial firewalls.
4.10 Forwarding Modes
Figure 4-22 How autodiscovery works.
Client 1 SYN
Appliance Tagged SYN
Appliance
Server
3 5 Tagged SYN-ACK
SYN 4
SYN-ACK 7
SYN-ACK
1. The client opens a TCP connection to the server as usual by sending it a TCP SYN packet. 2. The first Appliance passes the SYN packet through after attaching a set of Appliance-specific TCP header options to it and adjusting its window size. 3. The second Appliance reads the TCP options, removes them from the packet, and forwards them to the server. 4. The server accepts the connection by responding as usual with a TCP SYN-ACK packet. 5. The second Appliance remembers that this connection is a candidate for acceleration and attaches its own acceleration options to the SYN-ACK header. 6. The first Appliance reads the options added by the second Appliance, strips them from the packet header, and forwards the packet to the client. The connection is now accelerated. Both Appliances know this, and the necessary parameters have been exchanged through the option values. 7. The remainder of the connection will be accelerated. The client, server, routers, and firewalls are all unaware of this; it happens transparently.
Such firewalls need to be reconfigured to allow TCP options in the range of 24-31 (decimal). Examples for two common Cisco firewalls are given in Section 3.5.4.1. The basic procedure will be similar for other firewalls.
4.10
Forwarding Modes
An Appliance acts as a virtual gateway. It is neither a TCP sender nor a router. Like any gateway, its job is to buffer incoming packets and put them onto the link at the right speed.
4-30
June 26, 2011
This packet forwarding can be done in different ways, such as inline mode, virtual inline mode, and WCCP mode. While these methods are called modes, all are active simultaneously. (However, they have different cabling and deployment requirements that prevents inline mode from being used simultaneously with the others.) The Appliance can tell the different modes apart by the destination IP address and destination Ethernet MAC, as shown in Figure 4-23. For example, in inline mode, the Appliance is acting as a bridge, and the packets contain neither the Appliances IP address nor the Appliances Etherenet MAC address.
Figure 4-23 How Ethernet and IP addresses determine the forwarding mode.
Destination IP Addr. Not Appliance Not Appliance Appliance Appliance (VIP) Appliance (WCCP GRE Packet) Appliance (Redirector IP) Dest. Ethernet Addr. Not Appliance Appliance Appliance Appliance Appliance Appliance Mode Inline or Pass-through Virtual Inline or L2 WCCP Direct (UI access, etc.) Proxy Mode or High-Availability VIP WCCP GRE Mode Redirector Mode (Repeater Plug-in)
All modes can be active simultaneously. The mode used for a given packet is determined by the Ethernet and IP headers.
The forwarding modes are: 1. Inline mode, where the Appliance transparently accelerates traffic flowing between its two Ethernet ports (see Figure 4-24). In this mode, the Appliance appears (to the rest of the network) to be an Ethernet bridge. This mode is explained in Section 4.11. Inline mode is the recommended mode, as it requires the least configuration. 2. WCCP mode, which uses the WCCP v. 2.0 protocol to communicate with the router. It is easy to configure on most routers. With older routers and high-speed links, it may not be as fast as virtual inine. 3. Virtual inline mode, where a router sends WAN traffic to the Appliance and the Appliance returns it to the router. In this mode, the Appliance appears to be a router, but in fact it has no routing tables and sends its output packets to the real router. Virtual inline mode is recommended when inline mode and high-speed WCCP operation are not practical. 4. Proxy mode, where Appliance performs address translation according to tables set up by the administrator. In this mode, the Appliance appears to be a host. Proxy mode is not recommended for new installations; it is a legacy mode. Proxy mode does not support CIFS acceleration. 5. Redirector mode, where a Repeater Plug-in sends traffic to an Appliances redirector IP address. The Appliance replaces the source address of the packet with its true destination and forwards it to the server. 6. Pass-through mode, which includes all non-accelerated traffic. Non-accelerated packets are simply passed on without modification. They are not subject to the
4.11 Inline Mode
bandwidth limit, which means that they are not throttled. Acceleration has the unique characteristic of achieving acceleration without throttling. The unit can thus be put inline with LAN segments if desired, and LAN-to-LAN traffic will not be affected. Only traffic passing through two Appliances is Appliances support all three configurations simultaneously.
4.11
Inline Mode
Figure 4-24 Inline mode, used to accelerated all the traffic on a WAN.
NETWORK A
WAN
NETWORK B
Appliance
TCP/IP traffic passing through two appliances is accelerated
Appliance
Any TCP-based traffic passing through both units will be accelerated. No address translation, proxying or per-site setup is required. Inline mode is auto-detecting and auto-configuring.
In inline mode, traffic passes into one of the Appliances Ethernet ports and out of the other. When two sites with inline Appliances communicate, every TCP connection passing between them is accelerated. All other traffic is passed through transparently, as if the Appliance were not there. Management is minimized with inline mode. You do not need to keep track of which remote systems have Appliances installed, since inline mode is auto-sensing and auto-configuring. As soon as an Appliance is installed on a remote network, all your connections that pass through it will be accelerated. Ethernet Bypass. Most Appliance models include a fail-to-wire (Ethernet bypass) feature for inline mode. This feature is standard. If power fails, a relay closes and the input and output ports become electrically connected, allowing the Ethernet signal to pass through from one port to the other as if the Appliance were not there. In fail-to-wire mode, the Appliance looks like a cross-over cable connecting the two ports. A watchdog feature ensures that any failure of the Appliance hardware or software will also close the relay. When the Appliance is restarted, the bypass relay remains closed until the Appliance is fully initialized, maintaining network continuity at all times. This feature is automatic and requires no user configuration.
4-32
June 26, 2011
Link-Down Propagation. If carrier is lost on one of the bridge ports, the carrier will be dropped briefly on the other bridge port to ensure that the carrier-down condition is propagated to the device on the far side of the Appliance. Units that monitor link state (such as routers) are thus notified of conditions on the far side of the bridge.
4.11.1 Accelerating an Entire WAN

Figure 4-24 shows a typical configuration for inline mode. For both sites, the Appliances are placed between the LAN and the WAN, so all WAN traffic that can be accelerated will be accelerated. This is the simplest method of using Acceleration, and should be used when practical. Because all the link traffic is flowing through the Appliances, the benefits of fair queuing and flow control prevent the link from being overrun. In IP networks, the bottleneck gateway determines the queuing behavior for the entire link. By becoming the bottleneck gateway, the Appliance gains control of the link and can manage it intelligently. This is done by setting the bandwidth limit slightly lower than the link speed. When this is done, link performance is ideal, with minimal latency and loss even at full link utilization.
4.11.2 Accelerating Some Systems But Not Others

To reserve the Appliances accelerated bandwidth for a particular group of systems, such as remote backup servers, you can install the Appliance on a branch network that includes only these systems. This is shown in Figure 4-25.
Figure 4-25 Inline mode accelerating selected systems only.
NETWORK A
WAN
Appliance
Accelerated
Non-Accelerated
At first glance, it might seem that this would not work, since the Appliance is not in a position to throttle unaccelerated traffic to clear the way for accelerated connections. However, the Appliance does not use bandwidth throttling.
4-33
4.12 Redirector Mode
However, because it does not control all the traffic on the link, the full benefits of transparent flow control and fair queuing will not be achieved. In practice, this means that the accelerated applications will achieve the desired bandwidth, but latency control is up to the bottleneck gateway, and interactive responsiveness may suffer.
4.12
Redirector Mode
Redirector mode is a proxying mode used by the Repeater Plug-in system. Each client acquires a list of Appliances and the subnets they accelerate, and forwards matching traffic to the indicated Appliances.
4.12.1 How it Works

Accelerated connections are passed from the Repeater Plug-in to the Appliance, which in turn passes them to the server. In other words, the Appliance acts as a proxy. Acceleration information between the Repeater Plug-in and Appliance uses TCP option headers, and doesnt require a control connection.
Figure 4-26 Repeater packet flow, showing the address changes used by Redirector mode.
1 The user's application opens a TCP
Src: 10.0.0.50, Dst: 10.200.0.10 connection to the server, sending a TCP SYN packet.
The Repeater Plug-in looks up the dst address and decides to redirect the connection to the appliance at 10.200.0.201. Src: 10.0.0.50, Dst: 10.200.0.201 (10.200.0.10 is preserved in a TCP option field. Options 24-31 are used for various parameters.)
Repeater Plug-in 10.0.0.50 1 2
Repeater Appliance 10.200.0.201
Server 10.200.0.10
3 4 5 6
The appliance accepts the connection and forwards the packet to the server (using the dst address from the TCP options field), and giving itself as the src. Src: 10.200.0.201, Dst: 10.200.0.10
4 The server accepts the connection
and responds with a TCP SYN-ACK packet. Src: 10.200.0.10, Dst: 10.200.0.201
The appliance rewrites the addresses and forwards the packet to the Plugin (placing the server address in an option field). Src: 10.200.0.201, Dst: 10.0.0.50
6 The connection is now fully open. The client and server send packets
back and forth via the appliance. While the addresses are altered in Redirector mode, the destination port numbers are not (though the ephemeral port number may be). The data is not encapsulated. Redirector mode is a proxy, not a tunnel. There is no 1:1 relationship between packets (though in the end, the data received is always identical to the data sent). Compression may reduce many input packets into a single output packet. CIFS acceleration will perform speculative read-ahead and write-behind operations. Also, if packets are dropped between appliance and the Repeater Plug-in, the retransmission is handled by the appliance, not the server, using advanced recovery algorithms.
4-34
June 26, 2011
Figure 4-26 shows the packet flow and address mapping in redirector mode used by Repeater system. Redirector mode is a proxy mode that is transparent to applications on the client: The client application thinks it is talking directly to the server. For this reason, applications do not need to be reconfigured. (Redirector mode is thus an intercepting proxy.) The Repeater Plug-in software redirects the packets to the Appliance. The Appliance once again redirects the packets to the server. Thus, from the servers point of view, the connection originates at the Appliance. The port numbers are not changed, so network monitoring applications can still classify the traffic.
Unlike inline mode, redirector mode is an explicit, non-transparent proxy. The packets are explicitly addressed to the Appliance, with the address of the endpoint server indicated by TCP option fields. In addition, redirector mode is an asymmetric mode. Repeater Plug-in initiate redirector-mode connections to Appliances, but Appliances do not initiate connections to Repeater Plug-in. Because of the explicit addressing, redirector mode never suffers from asymmetric routing, which makes it simple to deploy.
4.12.2 Configuring Redirector Mode

Redirector modes method of operation requires only one Ethernet port, but redirector mode can be combined with inline mode (which requires two ports) or other deployment modes: virtual inline, WCCP, etc. See Figure 2-10.
Figure 4-27 Basic cabling, redirector mode
Switch Router
To LAN
To WAN
Appliance in Redirector Mode
Redirector mode is configured on the Configure Settings: Repeater Plug-in menu of the UI. The main requirements are as follows: The Repeater Plug-in must be able to open a signaling connection to the Appliance on the Appliances signaling port, which is also port 443 by default. The Repeater Plug-in must be able to open a data connection on the Appliance, using the same port that would be used for a direct, non-accelerated connection to the server. The Appliance must be able to open a data connection on the server.
These steps generally work out of the box if the Appliance is placed on the network at a point with full access to the servers.
4.13 WCCP Mode
4.13
WCCP Mode
Switch Router
Figure 4-28 Basic cabling, WCCP mode
To LAN
To WAN
Appliance in WCCP Mode
WCCP mode was introduced in release 3.0 and was greatly expanded in release 4.2.17 and again in 4.3. WCCP mode is an alternative to inline mode, and is the simplest way of dealing with installations where inline operation is impractical. It is also useful where asymmetric routing occurs: that is, when packets from the same connection arrive over different WAN links. In WCCP mode, the routers use the WCCP 2.0 protocol to divert traffic through the Appliance, either using a tunnel or, if the Appliance is on the same Ethernet segment as the router, direct L2 forwarding. Such traffic is treated by the Appliance as if it were received in inline mode. A WCCP-mode Appliance requires only a single attached Ethernet port. It should be deployed either on a dedicated router port (or WCCP-capable switch port) or isolated from other traffic through a VLAN. Do not mix inline and WCCP modes.
4.13.1 How it Works

WCCP 2.0 has two transport mechanisms: GRE encapsulation and L2 forwarding. Starting with release 4.2.17, the Appliance supports both methods, and chooses the fastest available method by default. Earlier releases supported GRE encapsulation only. GRE encapsulation (WCCP-GRE), as the name implies, creates a GRE tunnel between the router and Appliance. The Appliance decapsulates the traffic from the tunnel, operates upon it, and sends the resulting packets back through the tunnel. The Appliance behaves as if the traffic were inline. L2 forwarding (WCCP-L2) operates at the Ethernet level. The router sends packets to the Appliance without altering their IP headers, and the Appliance send packets back to the router. L2 forwarding works only if the Appliance is on the same Ethernet segment as the router. WCCP provides a heartbeat mechanism. When the heartbeat mechanism shows the Appliance is active, the router sends its WAN traffic to the Appliance. If the Appliances heartbeat is lost, the router bypasses the Appliance until the heartbeat is re-established. This heartbeat repeats every ten seconds. If the router sees thirty seconds of failed Here I Am/I See You dialogs, it times out and stops using the Appliance until contact is re-established.
4-36
June 26, 2011
When WCCP is used with high-availability mode, the primary Appliance contacts the router using its own apA or apB management IP, not the virtual address of the HA pair. On failover, the new primary Appliance contacts the router automatically, reestablishing the WCCP channel. In most cases the WCCP timeout period and the HA failover time will overlap, meaning that the network outage is less than the sum of the two delays. Only a single Appliance is allowed in a WCCP service group. This is enforced by the Appliance. When a new Appliance attempts to contact the router, it will discover that the other Appliance is handling the service group and cause an Alert. It will periodically check whether the service group is still active with the other Appliance, and will handle the service group when the other Appliance becomes inactive. Multiple service groups can be used with WCCP. For example, the traffic from one WAN link can be sent to the Appliance under service group 51, and the traffic from another link can be sent under service group 52. The Appliance is indifferent to which service group is used. It will track service-group usage as follows: if a packet arrives on one service group, output packets for the same connection will be sent on the same service group. If packets arrive for the same connection on multiple service groups, output packets will track the most recently seen service group for that connection. The Appliance also supports multiple routers. The Appliance is indifferent to whether all the routers use the same service group or whether different routers use different service groups.
4.13.2 Performance
WCCP-L2 is a high-performance mode and can be as fast as inline mode. WCCP-GRE has somewhat lower performance than inline mode. The encapsulation/ decapsulation and checksum operations have some overhead, especially on the router. Usually, the router is the limiting factor in WCCP-GRE performance. With modern routers, performance in excess of 155 mbps is readily achieved.
4.13.3 Limitations
Do not mix inline and WCCP traffic on the same Appliance. On Appliances with more than one accelerated pair, all the traffic for a given WCCP service group must arrive on the same accelerated pair.
4.13.4 Best Practices

For sites with a single WAN router, use WCCP whenever inline mode is not practical. For sites with multiple WAN routers serviced by the same Appliance, WCCP can be used to support one, some, or all of your WAN routers. Other routers can use virtual inline mode.
4-37
4.13 WCCP Mode
4.13.5 Router Support for WCCP

Configuring the router for WCCP is very simple. WCCP version 2 support is included in all modern routers, having been added to the Cisco IOS at release 12.0(11)S and 12.1(3)T.
4.13.6 Redirection Strategies

There are two basic approaches to redirecting traffic from the router to the appliance: 1. On the WAN port only, add a wccp redirect in statement and a wccp redirect out statement. 2. On every port on the router, add a wccp redirect in statement (except for ports that are isolated from the WAN). The first method redirects only WAN traffic to the appliance, while the second method redirects all router traffic to the appliance, whether it is WAN-related or not. (If a port is known to never carry WAN-bound traffic, such as an isolated internal subnet, it doesnt need a redirect statement.) On a router with several LAN ports and a lot of LAN-to-LAN traffic, sending all traffic to the appliance can overload its LAN segment and burden the appliance with a substantial, unnecessary load. If GRE is used, the unnecessary traffic can load down the router as well. Some routers and WCCP-capable switches do not support wccp redirect out, so the second method must be used. In this case, it is best to avoid routing large numbers of ports through the appliance, perhaps using two routers, one for WAN routing and one for LAN-to-LAN routing. In general, method 1 is preferable in practice, because it isolates the appliance-centric configuration to the WAN ports and avoids sending traffic to the appliance unnecessarily. On some routers, the redirect in path is faster and puts less of a load on the routers CPU than the redirect out path. This can be determined by direct experiment on your router: try both redirection methods under full network load to see which gives the highest transfer rates.
4.13.7 Router Configuration

The Appliance negotiates WCCP-GRE or WCCP-L2 automatically. The main choice is between unicast operation (where the Appliance is configured with the IP address of each router), or multicast operation (where both the Appliance and the routers are configured with the multicast address.)
4-38
June 26, 2011
Normal (Unicast) operation. The procedure is to declare WCCP version 2 and the WCCP group ID for the router as a whole, then enable redirection on each WAN interface. The following is a Cisco IOS example:
config term ip wccp version 2 ip wccp 51 ! Repeat the following three lines for each WAN interface ! you wish to accelerate: interface your_wan_interface ip wccp 51 redirect out ip wccp 51 redirect in ! If the Appliance is inline with one of the router interfaces ! (NOT RECOMMENDED), add the following line for that interface ! to prevent loops: ip wccp redirect exclude in ^Z
If multiple routers are to use the same Appliance, then each is configured as shown above. Multicast operation. The routers and the Appliance are each given a multicast address to use. Configuration is slightly different:
config term ip wccp version 2 ip wccp 51 group-address 225.0.0.1 ! Repeat the following three lines for each WAN interface ! you wish to accelerate: interface your_wan_interface ip wccp 51 redirect out ip wccp 51 redirect in ! ! The following line is needed only on the interface facing the other router, ! if there is another router participating in this service group. ip wccp 51 group-listen !If the Appliance is inline with one of the router interfaces, !(which is supported but not recommended), add !the following line for that interface to prevent loops: ip wccp redirect exclude in ^Z
4.13.8 Appliance Configuration

Configuration takes place on the Configure Settings: WCCP page (See Section 8.2.2.16 for details on this UI page): 1. Press the New WCCP Service Group button. 2. In the New Service Group box, select between Unicast and Multicast, then add a unicast or multicast IP address in the box below.
4.13 WCCP Mode
3. The default Service Group number (51), WCCP priority (0) and Time-to-Live (1) generally do not need to be changed, but if they do, put new values in the boxes provided. 4. Press Create. 5. Press the Enable button at the top of the page. 6. Go to the Monitoring: WCCP Status page. The Status field should change to Connected within 60 seconds. (See Section 8.3.10 for more information about this UI page.) 7. Send traffic over the link and verify from the Usage Graph or Accelerated Connections pages that connections are being accelerated.
4.13.9 Service Group Configuration Details

There are three communication attributes negotiated between a WCCP router and an Appliance (WCCP Cache in WCCP terminology) in a service group. The router advertises its capabilities in the I See You message. The three attributes are: 1. Forwarding Method: GRE or Level-2 2. Packet Return Method (multicast only): GRE or Level-2 3. Assignment Method: Hash or Mask The Appliance examines these capabilities. If there is an incompatibility, the Appliance triggers an Alert. The Appliance may be incompatible due to a specific attribute of a service group (such as GRE or Level-2), or, in a multicast service group, when the Auto selection caused a particular attribute to be selected with the first router connected, but which is incompatible with a subsequent router. The basic rules for these capabilities (attributes) within the WS are listed below. Router Forwarding 1. When Auto is selected, the preference is for Level-2 because it is more efficient for both router and Appliance. 2. Routers in a unicast service group can negotiate different methods negotiated if Auto is selected. 3. Routers in a multicast service group must all use the same method, whether forced with GRE or Level-2, or, with Auto, as determined by the first router in the service group to connect. 4. The incompatibility alert will announce that the router has incompatible router forwarding. Router Packet Return 1. When Auto is selected, the preference is for Level-2 because it is more efficient for both router and Appliance. 2. Routers in a unicast service group can negotiate different methods if Auto is selected. 3. Routers in a multicast service group must all use the same method, whether forced with GRE or Level-2, or, with Auto, as determined by the first router in the service group to connect. 4. The incompatibility alerts will announce, no multicast routers discovered or
4-40 June 26, 2011
router has incompatible packet return method. Router Assignment 1. The default is Hash. 2. When Auto is selected, the preference is for Hash, as it is the original and most common method. 3. All routers in a service group must use the same assignment method. 4. For any service group, when this attribute is configured as Auto, then Hash or Mask is selected when the first router is connected. Hash is chosen if the router supports it, otherwise Mask is selected. Subsequent routers may be incompatible with the auto-selected method. This can be minimized manually by manually selecting a method common to all routers in the service group. 5. The incompatibility alert will announce that the router has incompatible router assignment method. 6. With either method, the single appliance in the service instructs all the routers in the service group to direct all TCP packets to the appliance. Routers can modify this with access lists or by selecting which interfaces to redirect to the service group. 7. For the Mask method, the appliance negotiates the source IP address mask. We do not provide any mechanism to select destination IP address or the ports for either source or destination. The source IP mask does not specifically identify any specific IP address or range. The protocol does not provide a means to specify a specific IP address.
4.13.10 Testing and Troubleshooting

Status: WCCP Page. The Status: WCCP page reports on the current state of the WCCP link, and reports most problems. See Section 8.3.10. Log Entries. The Monitoring: Logging page will have an entry when WCCP mode is established or lost.
Figure 4-29 Log entry when WCCP mode is enabled.
4-41
4.14 Virtual Inline Mode
Router Status. On the router, the show ip wccp command will also show the status of the WCCP link:
Router>enable Password: Router#show ip wccp Global WCCP information: Router information: Router Identifier: Protocol Version: Service Identifier: 51 Number of Cache Engines: Number of routers: Total Packets Redirected: Redirect access-list: Total Packets Denied Redirect: Total Packets Unassigned: Group access-list: Total Messages Denied to Group: Total Authentication failures:
172.16.2.4 2.0
0 0 19951 -none0 0 -none0 0
4.14
Virtual Inline Mode
Note: Virtual inline mode is inferior to inline mode and WCCP, and should only be used when both of these two modes are impractical. Note: Do not mix inline and virtual inline modes. Virtual inline and WCCP modes may be mixed freely. The Appliance can be deployed in a virtual inline mode where selected traffic is redirected to the Appliance by a router using simple routing policies. This mode allows zero rewiring and zero downtime. In addition, virtual inline mode also provides an elegant solution for asymmetric routing issues faced when two or more WAN links are used. Note that the fail-to-wire feature is effective only for inline mode. In virtual inline mode, maintaining packet flow in the face of Appliance failure can be achieved with high-availability pairs.
4.14.1 How Virtual Inline Mode Works

In virtual inline mode, the Appliance receives packets from a router, operates on them, and then forwards output packets in one of two ways: 1. By sending them to the default gateway. 2. By sending them to the Ethernet address they came from. Where a single router is involved, the two methods are equivalent. Method 2 allows multiple routers to share an Appliance, with each router receiving its own packets back.
4-42
June 26, 2011
Virtual inline mode allows a router to send packets to Appliances in a way that is completely transparent to the rest of the network. The Appliance determines the forwarding method on a packet-by-packet basis, meaning that inline, virtual inline, and proxy modes can be mixed in the same unit.
4.14.1.1 Example
Figure 4-30 shows a simple network where all traffic destined for the remote site is sent to the gateway router.
Figure 4-30 Virtual inline example. Appliances are at 192.168.1.200 and 192.168.2.200.
Local Network 10.10.10.0/24 Router
FE 0/0 FE 0/1
Local Site
Remote Site
Remote Network 20.20.20.0/24 Router
FE 0/1 FE 0/0 FE 1/0
FE 1/0
Appliance 192.168.1.200
Appliance 192.168.2.200
The router redirects WAN traffic to the Appliance so that it can be accelerated. This is accomplished with policy-based routing (PBR) rules.
4.14.2 Configuration
The following are some configuration details for the example network: Endpoint systems have their gateways set to the local router (this is already true). Appliances have their default gateway set to the local router (on the Configuration: Network Adapters page). Virtual Inline settings are on the Configuration: Tuning menu. Routers are configured to redirect both incoming and outgoing WAN traffic to the Appliance.
4.14.2.1 How the Appliance Forwards Packets

There are two packet-forwarding options on the Virtual Inline section: 1. Send to Gateway (used with a single WAN router). Virtual inline output packets are forwarded to the default gateway for delivery. (This is true even of packets destined for hosts on the local subnet.) This mode is usually less desirable than the Return to Ethernet Sender option, since it add an easily forgotten element of complexity to your routing structure.
2. Return to Ethernet Sender (used with multiple WAN routers). This allows multiple routers to share an Appliance. The Appliance forwards virtual inline output packets to where they came from, based on the Ethernet address of the incoming packet. This way, if two routers share a single Appliance, each will get its own traffic back, but not the traffic from the other router. This mode also works when the unit is attached to a single router.
4.14.3 The Need for Policy-Based Rules

Both forwarding methods will create routing loops if the routing rules do not distinguish between a packet that has been forwarded by the Appliance and one which has not. Any method that distinguishes between the two cases will work. A typical method involves dedicating one of the routers Ethernet ports to the Appliance, then writing routing rules that are based on the Ethernet port on which packets arrive. Packets that arrive on the interface connected to the Appliance are never forwarded back to the Appliance; others can be. The basic routing algorithm to be used is: Dont forward packets from the Appliance back to the Appliance. If packet arrived from the WAN, forward to the Appliance. If packet is destined for the WAN, forward to the Appliance. LAN-to-LAN traffic should not be forwarded to the Appliance. Traffic shaping is not effective unless all WAN traffic through the Appliance. Note: When considering routing options, keep in mind that returning data must flow through the Appliance -- not just outgoing data. For example, placing the Appliance on the local subnet and designating it as the default router for local systems will not work as a virtual inline deployment. Outgoing data will flow through the Appliance, but incoming data will bypass it. To force data through the Appliance without router reconfiguration, place the Appliance inline, along the only path between the WAN and the systems to be accelerated.
4.14.4 Health Monitoring

If the Appliance fails, data should not be routed to it. By default, Cisco policy-based routing does no health monitoring, but this can be enabled with the verify-availability option of the set ip next-hop command. If the unit is not available, the route will not be applied, and the Appliance will be bypassed. Note: The health-monitoring feature is relatively new. It became available in Cisco IOS release 12.3(4)T. Many routers that support policy-based routing do not support health-checking. We do not recommend virtual inline mode on routers that do not support health-checking unless two Appliances are installed as a high-availability pair. Even then, health-checking is highly desirable.
4-44
June 26, 2011
A rule must be defined to test the availability of the unit, as shown in the example below:
! Use a ping (ICMP echo) to see if Appliance is connected track 123 rtr 1 reachability ! rtr 1 type echo protocol IpIcmpecho 192.168.1.200 schedule 1 life forever start-time now
This rule pings the Appliance at 192.168.1.200 periodically. We can test against 123 to see if the unit is up.
4-45
4.14.5 Routing Examples

The following configuration performs the routing into the Appliance. It conforms to the Cisco IOS CLI, and may not be applicable to routers from other vendors. Local Site, Health-Checking Enabled:
! ! For health-checking to work, dont forget to start ! the monitoring process (see previous section). ! ! If health monitoring is not desired, use the ! commented-out versions of the set ip next-hop commands. ! ! Original configuration is in normal type. ! Appliance-specific configuration is in bold. ! ip cef ! interface FastEthernet0/0 ip address 10.10.10.5 255.255.255.0 ip policy route-map client_side_map ! interface FastEthernet0/1 ip address 172.68.1.5 255.255.255.0 ip policy route-map wan_side_map ! interface FastEthernet1/0 ip address 192.168.1.5 255.255.255.0 ! ip classless ip route 0.0.0.0 0.0.0.0 171.68.1.1 ! ip access-list extended client_side permit ip 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255 ip access-list extended wan_side permit ip 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255 ! route-map wan_side_map permit 20 match ip address wan_side !- Now set the Appliance as the next hop, if its up. set ip next-hop verify-availability 192.168.1.200 20 track 123 ! route-map client_side_map permit 10 match ip address client_side set ip next-hop verify-availability 192.168.1.200 10 track 123
4-46
June 26, 2011
Remote Side (No Health Checking):

! This example does not use health-checking. ! Remember, health-checking is always recommended, ! so this is a configuration of last resort. ! ! ip cef ! interface FastEthernet0/0 ip address 20.20.20.5 255.255.255.0 ip policy route-map client_side_map ! interface FastEthernet0/1 ip address 171.68.2.5 255.255.255.0 ip policy route-map wan_side_map ! interface FastEthernet1/0 ip address 192.168.2.5 255.255.255.0 ! ip classless ip route 0.0.0.0 0.0.0.0 171.68.2.1 ! ip access-list extended client_side permit ip 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255 ip access-list extended wan_side permit ip 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255 ! route-map wan_side_map permit 20 match ip address wan_side set ip next-hop 192.168.2.200 ! route-map client_side_map permit 10 match ip address client_side set ip next-hop 192.168.2.200 !
In the two examples above, an access list has been applied to a route-map, which is in turn attached to an appropriate interface. The access lists identify all traffic originating at one accelerated site and terminating at the other (A source IP of 10.10.10.0/24 and destination of 20.20.20.0/24 or vice versa). See your routers documentation details about access lists and route-maps. This configuration redirects all matching IP traffic to the Appliances. If you wish to redirect only TCP traffic, the access-list configuration may be changed as follows (only the remote sides configuration is reproduced here):
! ip access-list extended client_side permit tcp 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255 ip access-list extended wan_side permit tcp 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255 !
4-47
Note that, for access lists, ordinary masks are not used. The masks are wildcard masks; when reading a wildcard mask in binary, note that 1 is considered a dont care bit.
4.14.6 Virtual Inline Mode For Multi-WAN Environments

Figure 4-31 Asymmetric routing example, with redundant links at the local site.
Local Site
Local Network: 10.10.10.0/24 Routers FE 0/1 FE 0/0 FE 1/0 Router FE 0/1
Remote Site
Remote Network: 20.20.20.0/24 FE 0/0
FE 1/0 FE 1/0 FE 0/1
FE 0/0
192.168.1.200
192.168.2.200
Enterprises with multiple WAN links often have asymmetric routing policies, which can require that an inline Appliance be in two places at once. Virtual inline mode solves the asymmetric routing problem using the routers, which are configured to send all WAN traffic through the Appliance, regardless of the WAN link used. A simple multi-WAN link deployment example is shown in Figure 4-31. The two local-side routers redirect traffic to the local Appliance. The fe0/0 ports for both routers are on the same broadcast domain as the Appliance. The Appliance can forward packets to its default router, or to return packets to their Ethernet origin (the router they came from). In this example, the latter option is preferred. In a more hierarchical network, one router might be preferred over the other, and would be configured as the Appliances default router.
4.14.7 Virtual Inline Mode and High Availability

Virtual Inline and High Availability can be used together. A simple high-availability deployment is shown in Figure 4-32. In virtual inline mode, a pair of Appliances act as one virtual appliance. Router configuration is the same for an HA pair as with a single Appliance, except that the Virtual IP address of the HA pair is used in the router configuration tables, rather than the IP address of an individual appliance. See Section 7.5 for a complete description of High Availability mode.
4-48
June 26, 2011
Figure 4-32 High-availability example.
Local Site
Local Network: 10.10.10.0/24 Routers FE 0/1 FE 0/0 FE 1/0 Router FE 0/1
Remote Site
Remote Network: 20.20.20.0/24 FE 0/0
FE 1/0 FE 1/0 FE 0/1
FE 0/0
VIP: 192.168.1.200
Appliance 192.168.2.200
Appliance 192.168.1.201
Appliance 192.168.1.202
4.15
Group Mode
Group mode was introduced in release 3.1. It allows two or more Appliances to be grouped into a single virtual Appliance. Its main use is multi-link/multi-Appliance installations where packets for a given connection will not always pass through the same Appliance. Group mode is one solution to the problem of asymmetric routing, which is defined as any case where some packets in a given connection pass through a given Appliance, but others do not. A limitation of the Appliance architecture is that acceleration cannot take place unless all of the packets in a given connection pass through the same two Appliances. Group mode can be used with multiple or redundant links without reconfiguring your routers. Group mode applies only to the Appliances on one side of the WAN link; the local Appliances neither know nor care whether the remote Appliances are using group mode.
Figure 4-33 Group mode over redundant links
WAN
WAN Group Mode Group Mode
4-49
4.15 Group Mode
Figure 4-34 Group mode over non-redundant links with possible asymmetric routing
WAN
WAN
WAN Group Mode
Figure 4-35 Group mode to connect multiple nearby sites.
Campus A Rest of Network
High-Speed MAN Link
WAN
Campus B Group Mode Two nearby sites can have Appliances that are part of the same group-mode group. This is used when dynamic routing allows WAN packets to take the alternate route via the other nearby site, bypassing the local Appliance. The high-speed link connects the group members. It needs to have higher speed and lower latency than the WAN links.
Group mode uses a heartbeat mechanism to verify that other members of the group are active. Packets are only forwarded to active group members.
4.15.1 When to Use Group Mode

1. You have multiple WAN links, and 2. There is a chance of asymmetric routing (a packet on a given connection might travel over either link), and 3. Group mode seems simpler and more practical than the alternatives that use a single appliance (WCCP, virtual inline, multiple bridges).
4.15.1.1 Alternatives to Group Mode

Group mode is one of several alternative approaches to dealing with multiple links, any of which may carry traffic for a given connection. The other approaches are: WCCP mode, where traffic from two or more links are sent to the same Appliance by WAN routers, via the WCCP protocol.
June 26, 2011
4-50
Virtual inline mode, where your routers send traffic from two or more links through the same Appliance (or high-availability pair). Multiple bridges, where each link passes through a different accelerated bridge in the same appliance. LAN-level aggregation, where an Appliance (or high-availability pair) is placed closer to the LAN, before the point where WAN traffic has been split into two or more paths.
4.15.2 How Group Mode Works

In group mode, the Appliances that are part of the group each take ownership for a portion of the groups connections. If a given Appliance is the owner of a connection, it makes all the acceleration decisions about that connection, and is responsible for compression, flow control, packet retransmission, etc. If an Appliance receives a packet for a connection for which it is not the owner, it forwards it to the Appliance that is the owner. The owner examines the packet, makes the appropriate acceleration decisions, and forwards any output packets back to the non-owning Appliance. This preserves the link selection made by the router, while allowing all packets in the connection to be managed by the owning Appliance. See Figure 4-36. The result is that, from the routers point of view, the introduction of the Appliances has no routing consequences at all, and the routers do not need to be reconfigured in any way. In addition, the Appliances do not need to understand the routing mechanism, and simply accept the routers forwarding decisions.
Figure 4-36 Sending-side traffic flow in group mode. Traffic is returned to its original path for
delivery.
Group Mode (Sending Side) Does Not Disturb Original Routing Path 4
WAN
2 3
WAN
Legend 1. Traffic arrives at non-owning unit 2. Traffic is forwared to owning unit 3. Owning unit accelerates traffic and returns it 4. Accelerated traffic is delivered
4-51
4.15 Group Mode
Figure 4-37 Receiving-side traffic flow in group mode. Traffic is returned to its original path
for delivery.
Group Mode (Receiving Side) Does Not Disturb Original Routing Path 1
WAN
2 3
WAN
Legend 1. Traffic arrives at non-owning unit. 2. Traffic is forwared to owning unit 3. Owning unit accelerates traffic and returns it 4. Accelerated traffic is delivered
4.15.3 Owner Selection

Figure 4-38 Using IP-based selection in a primary/backup link topology
Set to handle all traffic (sending none to partner)
Primary Link
WAN
Appliance selection matches route selection
WAN
Backup Link Set to send all traffic to partner
By default, the owner of a group-mode connection is set by default according to a hash of the source and destination IP addresses. Each Appliance in the group uses the same algorithm to determine which group member owns a given connection.
4-52
June 26, 2011
The owner can optionally be set according to specific IP/port-based rules. These rules must be identical on all Appliances in the group. Each member of the group verifies that its group-mode configuration is identical to the others; if this is not true, all of them will refuse to enter group mode. If traffic arrives first at the owning Appliance, it is accelerated and forwarded normally. If it arrives first at a non-owning Appliance, it is forwarded to its owner over a GRE tunnel, which accelerates it and returns it to the original Appliance for forwarding. In this way, group mode leaves the routers link selection unchanged. Because the group-mode hash isnt identical to that used by load balancers, about half the traffic will tend to be forwarded to the owning Appliance in a two-Appliance group. (If three units are used, two-thirds of the traffic will be forwarded on average.) In the worst case, forwarding causes the load on the LAN-side interface to be doubled, which halves the Appliances peak forwarding rate for actual WAN traffic. This speed penalty can be eliminated if the Primary or Aux1 Ethernet ports are used for traffic between group members. For example, if you have a group of two Appliances, you can use a patch cable to connect the two units Primary ports, then specify the Primary ports on the Group Mode page on each unit.
4.15.3.1 IP-Based Ownership Rules

Using explicit IP-based rules can reduce the amount of group-mode forwarding. This is especially useful in primary-link/backup-link scenarios, where each link handles a particular range of IP addresses, but can act as a backup when the other link is down.
4.15.3.2 Failure Modes

There are two user-selectable failure modes in Group Mode. These control how the group members interact with each other after one of them fails, and also determines whether their bypass cards fail in the open state (blocking traffic through the Appliance) or the closed state (allowing traffic to pass through. Continue to accelerate. If a group member fails, its bypass card is opened and no traffic passes through the failed Appliance. This will presumably trigger a fail-over if redundant links are used. Otherwise, the link is simply inaccessible. The other Appliances in the group continue to accelerate. The usual hashing algorithm is used to handle the changed conditions. (That is, the old hashing algorithm is used, and if the failed unit is indicated as the owner, a hashing algorithm based on the new, smaller group is applied. This preserves as many older connections as possible.) Do not accelerate. If a group member fails, its bypass card closes, allowing traffic to pass through (though without acceleration). Because a non-accelerated path will introduce asymmetric routing, the other members of the group will also go into pass-through mode when they detect the failure.
4.15.4 Setting the Bandwidth Limit

In group mode, the WAN bandwidth of a connection comes out of the bandwidth limit of the unit that owns it, even when it is sent over a different link. This raises the possibility that a link may have more traffic sent over it than its actual capacity, especially if the links are of different sizes. This can be dealt with in two ways:
4-53
4.15 Group Mode
1. By using softboost mode, which is well-behaved in the face of uncertain bandwidth conditions. Set the bandwidth limit as usual (to 90%-95% of the speed of the link the unit is inline with). 2. By using hardboost, but setting the bandwidth limit far enough below the link speed that worst-case behavior does not overrun the link. This sometimes occurs by default on very fast links that the Appliances cannot fill in any event (such as a pair of 155 mbps Appliances on a 1 gbps link).
4.15.5 Enabling Group Mode

Figure 4-39
Group mode page.
Group mode requires that two or more Appliances be added to the group. An Appliance can only be a member of one group. Group members are identified by IP address and the serial number given in the Appliance license. All group mode parameters are on the Settings: Group Mode page, in the Configure Settings: Group Mode table. To enable group mode: 1. Select the address to use for group communication. This is on the top line in the Configure Settings: Group Mode table. The Member VIP entry shows the management address of the port used to communicate with other group members. Use the pull-down menu to select the correct address, (for example, if you want to use the Aux1 port, select the IP address you assigned to the Aux1 port). Press the Change VIP button. 2. Add at least one more group member to the list. A group needs at least two members (groups of three or more are supported but are rarely used). Type the other group members IP address in the Member VIP field. This is the IP address of the port used by the other Appliance for group-mode communication.
4-54
June 26, 2011
3. Enter the other group members SSL common name in the SSL common name column. (The SSL common name is listed on the other Appliances Configure: High Availability page.) If the group member is not part of a high-availability pair, the entry under HA Secondary SSL Common Name will be blank. If the other group member is a high-availability pair rather than an individual Appliance, give the SSL Common Name of its HA partner in the HA Secondary SSL Common Name column. 4. Press the Add button. 5. Repeat for any additional Appliances or high-availability pairs in the group. 6. There are three buttons below the list of group members. Since they are toggles, the are labeled according to the opposite of their current settings: a. The top button reads either, Do not accelerate when member failure is detected or Continue to accelerate when member failure is detected. The Do not accelerate... setting always works and doesnt block traffic, but any member failure causes a complete loss of acceleration, since it causes the others to go into bypass mode. The Continue to accelerate option will cause the failing Appliance to fail with its bridge open-circuited, causing a link failure. This is appropriate if the WAN router will notice this and cause a failover. Open connections owned by the surviving Appliances will be maintained, and new connections will be accelerated. b. The bottom button should read, Disable Group Mode. If it does not, enable group mode by pressing the button. 7. Refresh the screen. The top of the page should list the group mode partners, but complain about their status. 8. Repeat this procedure with the other members of the group. Within 20 seconds after enabling the last member of the group, the Group Mode Status should to go NORMAL, and the other group mode members should be listed with Status: On-Line and Configuration: OK.
4.15.6 Setting Forwarding Rules

By default, group mode apportions connections between members by applying a hash to the source and dest addresses. This is unlikely to match the traffic patterns arriving over the WAN. When a group member receives a packet for a connection that doesnt belong to it, it forwards it to the correct group member. This forwarding creates overhead that, worst-case, can double the load on the LAN-side ports of a two-unit group, which can cut peak throughput in half. This can be avoided by setting forwarding rules to ensure that group members only handle their natural traffic. In many installations, where traffic is usually routed over its normal link and only rarely crosses the other one, these rules not only reduce overhead, but allow the bandwidth limit to be applied more precisely to the Rules are evaluated in order, and the first matching rule is used. Rules are matched against an optional IP address/mask pair (which is compared against both source and destination addresses), and against an optional port range.
4-55
4.16 Compression
In the example below, member 172.16.1.102 is the owner of all traffic to or from its own subnet (172.16.1.0/24), while member 172.16.0.184 is the owner of all other traffic. If a packet arrives at unit 172.16.1.102, and it is not addressed to/from net 172.16.1.0/24, it will be forwarded to 172.16.0.184. If unit 172.16.0.184 fails, however, unit 172.16.1.102 will no longer forward packets, and will attempt to handle the traffic itself. This behavior can be inhibited by pressing the Do NOT Accelerate When Member Failure Detected button. On a setup with a primary link and a backup link, the forwarding rules would send all traffic to the Appliance on the primary link. If the primary link failed, but the primary unit did not,
Figure 4-40 Forwarding rules
4.16
Compression
Repeater compression uses breakthrough technology to provide transparent multi-level compression. Repeater compression is true compression that acts on arbitrary byte streams. It is not application-aware, is indifferent to connection boundaries, and can compress a string optimally the second time it appears in the data. It supports compression at any link speed. The compression engine is very fast, allowing the speedup factor for compression to approach the compression ratio. For example, a bulk transfer monopolizing a 1.5 mbps T1 link achieving a 100:1 compression ration can deliver a speedup ratio of almost 100x, or 150 mbps. This works so long as the WAN bandwidth is the only bottleneck in the transfer. If the server hardware, the client hardware, the LAN, or the application are also bottlenecks, throughput will necessarily be reduced to the speed of the slowest element in the chain. Protocols that spend time waiting for application-level handshaking will also see speedup factors lower than the compression ratio, since the compressor can reduce the size of data but cant do anything about the pauses between data.
4-56 June 26, 2011
Unlike most compression methods, Repeater compression history is shared between connections, meaning that data sent earlier by connection A can be referred to later by connection B in lieu of retransmitting the data. This gives much higher performance than can be achieved by conventional methods. Large-history, multi-session compression technology erases the distinction between compressible and uncompressible data. For example, a JPEG image is normally considered uncompressible, but if it is sent twice by two different connections, the second occurrence may be compressed by over 200:1. The entire image will be replaced by a pointer referring to the data in the receiving Appliances compression history. Only payload data is compressed. However, headers are compressed indirectly. For example, if a connection achieves 4:1 compression, only one full-sized output packet will be emitted for every four full-sized input packets. Thus, the amount of header data is also reduced by 4:1. Compression makes good use of lossless flow control. A run of compressible data might reduce 200 input packets to one output packet. This might be followed by data that is not compressed successfully, and is sent as literal data. With flow control, the TCP sender (the origin host) can be told to speed up or slow down by 200:1 almost instantly. Ordinary TCP speeds up and slows down on a much coarser timescale, making compression relatively useless. Neither the compressed connection nor any other connection can speed up quickly enough to take advantage of the intermittently reduced bandwidth load created by compression. Citrix flow control can and does. Like most acceleration features, compression has virtually no configuration. It can be enabled or disabled (on a global, per-port, or per-address basis), but there are no actual compression parameters to configure. Compression self-adjusts to the current traffic load. Compression can use the Appliances disk as well as memory, providing up to 600 GB of compression history.
4.16.1 XenApp/XenDesktop Acceleration

Note: For the purposes of this section, XenApp means XenApp and XenDesktop and refers to the ICA and CGP protocol streams. XenApp/XenDesktop (ICA/CGP) acceleration has three components: 1. Compression. The Appliance cooperates with XenApp clients and servers to compress XenApp data streams for interactive data (keyboard/mouse/display/audio) and batch data (printing and file transfers). This takes place transparently and requires no configuration on the Appliance. A small amount of configuration, described below, is required on the XenApp server. 2. Multi-stream ICA. In addition to compression, Branch Repeater supports the new Multi-stream ICA protocol, in which up to four connections are used for the different ICA priorities, rather than multiplexing all priorities over the same connection. This gives interactive tasks greater responsiveness, especially when combined with Branch Repeaters traffic shaping. Note: Multi-stream ICA is disabled by default. It can be enabled on the Features page.
4.16 Compression
3. Traffic shaping. Branch Repeaters traffic shaper uses the priority bits in the XenApp data protocols to modulate the connections priority in real time, matching the bandwidth share of each connection to what its doing at the moment. XenApp acceleration applies to both the ICA and CGP protocols within XenApp. The Repeater appliances, XenApp servers, and XenApp clients provide cooperative acceleration of XenApp connections, giving substantial speedup compared to XenApp alone. This cooperation requires up-to-date versions of all three components. Enabling XenApp Acceleration: 1. Check the ICA service class policy on Appliances that have been upgraded to Branch Repeater 6.x from prior releases. On the Configuration: Service Classes page, the ICA service class should show disk in the Acceleration column and ICA Priorities in the Traffic Shaping column. If not, the service class definition needs to be edited to correct this. (See Section 8.4.10.) 2. Update XenApp 4.x servers and clients. (Not necessary on XenApp 5.0 and above). Use Presentation Server 4.5 with Hotfix Rollup Pack PSE450W2K3R03 (Beta) or later. This release includes the following server and client software, both of which must be installed for XenApp compression: c. Server package PSE450R03W2K3WS.msp or later. d. Client version 11.0.0.5357 or later. 3. Update XenDesktop servers and clients to release 4.0 or above. 4. Verify XenApp server registry settings. (Not necessary on XenApp 5.0 and above.) On the XenApp servers, verify these settings and correct or create them as necessary:
HKLM\System\CurrentControlSet\Control\Citrix\WanScaler\EnableForSecureIca = 1 HKLM\System\CurrentControlSet\Control\Citrix\WanScaler\EnableWanScalerOptimization = 1 HKLM\System\CurrentControlSet\Control\Citrix\WanScaler\UchBehavior = 2
These are all DWORD values. 5. Open and use XenApp connections between updated XenApp clients and servers, that pass through the updated Repeaters. Both CGP and ICA connections will be accelerated. By default these sessions will use CGP. For ICA, uncheck the following option on the client under Citrix Program Neighborhood->Custom ICA Connections. Right-click a connection icon and then uncheck Properties-> Options->Enable Session Reliability. 6. Verify acceleration. Start XenApp sessions over the accelerated link. On the Monitoring: Active Connections page on the Appliances, accelerated ICA connections should appear. A compression ratio of greater than 1:1 indicates that compression is taking place. XenApp compression dynamically switches between memory-based compression for interactive tasks (mouse/keyboard/video, etc.) and disk-based compression for bulk tasks (file transfer, printing, etc.). Compression ratios should increase as compression history fills, increasing the amount of previously seen data that can be matched against new data. XenApp compression provides several times as much data reduction as unassisted XenApp, often exceeding 50:1 on repetitive bulk transfers, such as printing or saving successive versions of the same document. XenApp compression prevents users from interfering with each other, allowing high link utilization without congestion.
4-58 June 26, 2011
4.16.2 How Compression Works

4.16.2.1 Memory-Based Compression
An Appliance can transparently compress all of the accelerated sessions passing between two compression-enabled Appliances. A very large compression history is used to provide high compression ratios. This history is kept in RAM for high performance, allowing excellent compression at high link rates. This persistence of data also blurs the distinction between compressible and uncompressible data. The only data that is technically uncompressible is data that will never recur over the lifetime of the compression history. Such data includes one-time encrypted data such as SSH data streams, but not precompressed files such as JPEG images and ZIP files. So long as a bit stream is sent more than once over the lifetime of the compression history (which is more than a gigabyte on most Appliances), the second and subsequent occurrences will be compressed. Other than enabling and disabling disk or memory compression on the Configuration: Service Classes page, there are no parameters. Additional parameters would be superfluous, as much better results are obtained through dynamic self-adjustment than could be attained through static configuration. Some benefit can be obtained by disabling compression on ports that are known to carry encrypted data streams, such as HTTPS and SSH. The default service-class definitions do this. Compression involves pointers to previously encountered runs of data, interspersed with runs of data that hasnt been seen before, which is sent as literal data. The pointers to previously encountered data are quite small, no more than a few bytes. Reducing long runs of data to a few bytes is what allows compression to reduce the amount of data on the WAN. Ordinary TCP is ill-suited to compression because it cannot speed up or slow down quickly enough to take full advantage of compression. Branch Repeater flow control eliminates this problem. The link generally runs at full capacity with compression enabled, provided that the endpoint senders and receivers can keep up. On runs of compressed data, compression ratios of 200:1 are not unusual. This gives a T1 link an effective speed of 300 Mbps for the duration of the compression hit, which may be megabytes in length. This is higher than the sustainable I/O rate of many endpoint systems! A compression-enabled Appliance can communicate with any number of other Appliances simultaneously. These Acceleration Partners can support compression or not in any combination.
4.16.2.2 Disk-Based Compression

Disk-based compression allows redundant data strings of virtually any length to be recognized and reduced to a handful of bytes. Compression history varies by Appliance model, from a minimum of 128 GB on Branch Repeater to a maximum of 600 GB on the Repeater 8800.
4-59
4.16 Compression
For example, if a user were to download a set of Linux distribution disks over an accelerated T1 link, and another user re-downloaded them days, weeks or even months later, the second copy would still be in the Appliances compression history and would download at several hundred megabits per second. Disk-based compression is not caching, which can serve up stale, out-of-date data, but is true compression, fetched on demand from the endpoint server. Disk-based compression saves selected data streams to disk on both the sending and receiving Appliances. Fingerprints of this data (based on a hashing function) are retained in memory. These fingerprints also identify potential matches with data already on the disk. Such data is fetched from the disk and verified byte-for-byte with the incoming data stream by the sending Appliance. Identical strings are reduced to tokens containing the disk identifier, offset, and length of the match. The receiving Appliance retrieves this data from the matching copy its own disk. (Some compression schemes assume that identical fingerprints indicate identical data, but this is not always true. The Appliance always verifies every byte of a potential match.) Everything is Compressible (Except Encrypted Streams). The enormous size of disk-based compression history eliminates the distinction between compressible and uncompressible data. For example, if a 100 GB database is copied from one office to another at weekly intervals, and the average week shows a 1% change to the data, disk-based compression can easily reduce this 100 GB transfer to 1 GB (transferring only the differences), and probably less than 1 GB if the differences are not completely random. The only exception is data that is essentially random and will never recur. Encrypted data streams and live, compressed video streams are the only common examples of this. The combination of AutoOptimization and everything is compressible means that there are almost no user-accessible compression options. You can select between no compression, memory compression only, and disk+memory compression in the Service Class Rules, but you can leave disk+memory compression enabled for all streams that arent encrypted.
4.16.3 Enabling/Disabling Compression

Compression is enabled on a per-service-class basis on the Configuration: Service Classes page. There is a pull-down menu for each service class, with the following options: Disk, meaning both disk-based and memory-based compression are enabled. (If the unit is not licensed or configured for disk-based compression, memory-based compression will be used instead.) This option should be selected unless you have a specific reason for disabling it. Memory, meaning that memory-based compression is enabled but disk-based compression is not. This setting is rarely used.
4-60
June 26, 2011
Flow-Control Only, which disables compression but enables flow-control acceleration. This should be selected for services that are always encrypted, plus the FTP Control channel None, meaning that compression and flow-control are both disabled..
Figure 4-41 Using service class policies to alter compression settings.
4.16.4 Measuring Disk-Based Compression Performance

Compression performance varies with a number of factors, including the amount of redundancy in the data stream and, to a lesser extent, the structure of the data protocol. Some applications, such as FTP, send pure data streams; the TCP connection payload is always byte-for-byte identical. Others, such as CIFS or NFS, do not send pure data streams, but the compression engine knows how to distinguish headers from payload. Such data streams can easily produce compression ratios between 100:1 and 10,000:1 on the second pass. Average compression ratios for the link will depend on the relative prevalence of long matches, short matches, and no matches. This is dependent on the traffic and is difficult to predict in practice. Maximum compression performance will not be achieved until the disk storage of the disk-based compression unit has filled, giving it a maximum amount of prior data to match with new data.
4.16 Compression
The Compression Status page reports the system compression performance since the system was started or the Clear button was used to reset the statistics. Compression for individual connections is reported in the connection close messages in the log:
Neither of these methods distinguishes between disk-based and memory-based compression, as it is the performance of the multi-level compression system as a whole, and not of a given subsystem, that is generally of interest. Testing disk-based compression is further complicated by the fact that memory-based compression is large (up to 5 GB on some models) and highly effective. Ideally, a test suite should transfer more data than this on each pass if the intention is to judge disk-based compression in isolation, rather than multi-level compression. In a perfect world, testing would not conclude until the disks on the unit had not only filled, but had turned over at least once. However, few admins have this much representative data at their disposal. Another difficulty is that Acceleration often exposes weak links in the network, and these are sometimes misdiagnosed as disappointing acceleration performance.
4.16.4.1 Testing LAN performance with Iperf

Iperf is useful for preliminary testing. Iperf is extremely compressible (even on the first pass) and uses relatively little CPU and no disk resources on the two endpoint systems. Compressed performance with Iperf should be over 200 mbps over a T1 link if the LANs on both sides use Gigabit Ethernet, or slightly less than 100 mbps if there is any Fast Ethernet equipment on the LAN paths between endpoints and Appliances. Iperf is pre-installed on the Appliances (under the Diagnostics menu) and is available from http://dast.nlanr.net/Projects/Iperf/. Ideally, it should be installed and run from the endpoint systems, so the network is tested from end to end, not just from Appliance to Appliance.
4.16.4.2 Using FTP for initial testing

FTP is useful for more realistic testing than iperf. FTP is simple and familiar, and its results are easy to interpret. Second-pass performance should be roughly the same as with iperf. If not, the limiting factor will probably turn out to be the disk subsystem on one of the endpoint systems. To test the disk-based compression system, use the following procedure: 1. Transfer a multi-gigabyte data stream between two units with disk-based compression enabled. Note the compression achieved during this transfer. Depending on the nature of the data, considerable compression may be seen on the first pass. 2. (Optional) Restart one of the units, thus clearing the memory-based compression history. You may find this too disruptive on a production network. 3. Transfer the data stream a second time and note the effect on compression.
4-62
June 26, 2011
4.17
CIFS (Windows Filesystem) Acceleration
The CIFS acceleration feature provides a suite of protocol-specific performance enhancements to CIFS-based (Windows and Samba) file transfer and directory browsing, including both enhancements to CIFS transport and to related protocols such as DCERPC. Both the SMB1 and SMB2 versions of CIFS are supported. CIFS acceleration is supported on all models. CIFS is a TCP-based protocol and benefits from flow control. However, CIFS is implemented in a way that is highly suboptimal for long-haul networks, requiring an excessive number of round-trips to complete an operation. Because the protocol is very sensitive to link latency, full acceleration must be protocol-aware. CIFS acceleration reduces the number of round-trips through a variety of techniques. The pattern of requests from the client is analyzed and its next action is predicted. In many cases, it is safe to act upon the prediction even if it is wrong, and these safe operations are the basis of many optimizations. For example, SMB1 clients issue sequential file reads in a non-overlapping fashion, waiting for each 64KB read complete before issuing the next one. By implementing read-ahead, the Appliance can safely deliver up to 10x acceleration by prefetching the anticipated data. Additional techniques accelerate directory browsing and small-file operations. Acceleration is applied not only to CIFS operations, but to the related RPC operations as well. Not every CIFS implementation uses request patterns that are recognized by the Appliance. These unsupported versions will not achieve acceleration in the full range of cases. See Figure 4-42. The modes of CIFS acceleration are: Large file reads and writes Small file reads and writes Directory browsing. Metadata caching.
Large file reads and writes. These SMB1 optimizations are for file transfers of at least 640 KB in size. Safe read-ahead and write-behind techniques are used to stream the data without pauses for every transfer (a transfer is 64 KB or less). These optimizations are enabled only if the transfer is has a BATCH or EXCLUSIVE lock and is simple. File copies are always simple; files opened through applications may or may not be, depending on how they are performed within the application. Speedup ratios of 10x are readily obtainable with CIFS acceleration, provided your link and disks are fast enough to allow ten times your current transfer speeds. 50x speedup can be obtained if necessary. This is not normally enabled due to memory consumption. See your Citrix representative if 10x is not sufficient. Small file reads and writes. Small-file enhancements center more around metadata (directory) optimizations than data streaming. Native CIFS does not combine metadata requests in an efficient way; CIFS acceleration does. As with large-file acceleration, these optimizations are not performed unless they are safe; for exam-
4-63
4.17 CIFS (Windows Filesystem) Acceleration
Figure 4-42 CIFS server/client support.

Product Windows Server 2008 Windows 7 Windows Vista Windows Server 2003 Windows XP Windows 2000 NetApp Samba Windows NT Windows ME and earlier Others Server Yes Yes Yes Yes Yes Yes Yes Yes Yes No See Note Client Yes Yes Yes Yes Yes Yes N/A No No No
Note: Most third-party CIFS implementations emulate one of the servers or clients listed above. To the extent that the emulation is successful, it will be accelerated or not, according to the table above. If the emulation behaves differently from what the CIFS accelerator expects, it will terminate CIFS acceleration for that connection. The behavior of CIFS acceleration with a given CIFS implementation cannot be known for certain until it has been tested.
ple, they will not be performed if the CIFS client was not granted an exclusive lock on the directory. When the SMB2 protocol is used, file metadata is cached locally for even greater improvements. Directory Browsing. Standard CIFS clients perform directory browsing in an extremely inefficient way, requiring an enormous number of round-trips to open a remote folder. CIFS acceleration reduces this to 2-3 round-trips. When the SMB2 protocol is used, directory data is cached locally for even greater improvements.
4.17.1 CIFS Security and Acceleration

Windows file servers have two security modes, signing and sealing. Sealing prevents CIFS acceleration altogether. Signing prevents it unless the server-side Appliance has joined a Windows domain (See Section 4.19) and the two Appliances have established a secure peer relationship (See Section 4.20).
To accelerate signed CIFS traffic, see Sections 4.19 and 4.20. Otherwise, signing must be disabled (if it is not disabled already), as described below.
4-64
June 26, 2011
Figure 4-43 Windows Server security options, Windows Server 2003 and Windows Server
2008.
By default, Windows file servers offer signing but do not require it, except for domain servers, which require it by default. To achieve CIFS acceleration with systems that currently require signing, you must change the system security settings to disable this requirement. This is done from local security settings on the file server or in group policies. In the following examples, the local settings will be shown. The group-policy changes are, of course, almost identical. Windows Server 2003 and Windows Server 2008 (see Figure 4-43): In Local Security Settings: Set Domain member: Digitally encrypt or sign secure channel data (always) to Disabled Set Microsoft network client: Digitally sign communications (always) to Disabled Set Microsoft network server: Digitally sign communications (always) to Disabled
Windows 2000 Server (see Figure 4-44):

4.17 CIFS (Windows Filesystem) Acceleration
Figure 4-44 Windows 2000 security options.
Set Digitally sign server communication (always) to Disabled Set Digitally sign client communication (always) to Disabled
Another option, sealing, encrypts the data stream, which prevents CIFS acceleration. Sealing is not enabled by default on Windows file servers. If sealing has been enabled on your systems, it can be disabled by setting the options on Secure channel: Digitally encrypt secure channel data options (on the same page as the signing options) to Disabled. In either case, the issue can be detected through the log file on the client-side Acceleration unit:
CIFS Session from client <ip> to server <ip> cannot be accelerated for CIFS due to: server security settings.
4.17.2 Interpreting CIFS Statistics

The Monitoring: Filesystem (CIFS/SMB) page shows a list of accelerated CIFS connections. These connections are divided into optimized and non-optimized connections. Since all these connections are accelerated (with flow control and compression), optimized connections have CIFS optimizations added in addition to flow control and compression, while non-optimized connections have flow control and compression only.
4-66 June 26, 2011
4.17.3 CIFS Management Summary

1. CIFS acceleration will show significant improvement even at relatively short link distances. 2. CIFS acceleration begins when a filesystem is first accessed by the client. If acceleration is enabled with the fileserver and client already up and running, no acceleration will be seen for many minutes, until the pre-existing CIFS connections are fully closed. CIFS connections are very persistent and last a long time before closing themselves, even when idle. This is annoying during test, but has little importance in normal deployment. 3. Dismounting and remounting a filesystem in Windows does not have the desired effect, because Windows doesnt really dismount the filesystem fully. Rebooting the client or server will work. For a less invasive measure, use the NET USE devicename /DELETE command from the Windows command line to fully dismount the volume. In Linux, smbmount and umount will fully dismount the volume. 4. Disabling and then reenabling CIFS read and write optimizations in the Appliance raises similar issues; existing connections will not become accelerated when CIFS is enabled, and the number of protocol errors detected on the Monitoring: Filesystem (CIFS/SMB) page will increase briefly. 5. Only the Appliance furthest from the fileserver recognizes CIFS acceleration; the other unit sees it as ordinary Acceleration. This is frequently confusing. 6. CIFS acceleration is not supported in proxy mode. 7. If CIFS acceleration does not take place with a Windows server, check its security settings.
4.18
Microsoft Outlook (MAPI) Acceleration
Microsoft Outlook acceleration provides improved performance on traffic between Microsoft Outlook clients and Microsoft Exchange Servers, increasing throughput with a variety of optimizations, including data prefetching and compression. This feature is also called MAPI acceleration, after the MAPI protocol used between Outlook and Exchange Server.
4.18.1 Supported Outlook/Exchange Versions and Modes

Microsoft Outlook 2003-2010. Exchange Server 2003-2010. Any combination of supported clients and servers is supported. Outlook must connect to the Exchange Server normally, using the MAPI protocol (no HTTP or HTTPS proxy or Outlook Anywhere). If the server-side Appliance has joined a Windows domain, connections with MAPI encryption will be accelerated. Otherwise, they will not be, and encryption should be disabled in the Outlook clients.
4.18.2 Configuration
Outlook acceleration is a zero-configuration feature that is enabled by default. (If desired, it can be disabled by disabling acceleration on the MAPI service class on the
4.18 Microsoft Outlook (MAPI) Acceleration
Configure Settings: Service Class Policy page.) Outlook acceleration will take place automatically if the following conditions are met: There is an Appliance at the Exchange Server end of the WAN. There is an Appliance at the Outlook end of the WAN, OR the system running Outlook is also running the Repeater Plug-in. All Outlook/Exchange traffic passes through the appliances. Either the Exchange Server or the Outlook are restarted (acceleration does not begin until existing MAPI connections are closed). Encryption is disabled on Outlook OR the server-side Appliance belongs to the Windows domain and has a secure peer relationship with the client-side Appliance (or Repeater Plug-in).
4.18.2.1 Disabling Encryption on Outlook 2007

Unless the server-side Appliance has joined the Windows domain and has a secure peer relationship with the client-side Appliance (or Repeater Plug-in), encryption between Outlook and Exchange Server must be disabled for acceleration to take place. (For more on joining the Windows domain, see Section 4.19.) Encryption was disabled by default before Outlook 2007. Starting with Outlook 2007, encryption is enabled by default, so action must be taken to disable encryption. To disable encryption manually on a single Outlook 2007 client, go to the menu shown in Figure 4-45 and uncheck the box, Encrypt data between Microsoft Office Outlook and Microsoft Exchange. To disable encryption for multiple users via group policies, follow the instructions at http://support.microsoft.com/default.aspx/kb/924617. Change the Properties for Enable RPC Encryption to Disabled under User Configuration: Administrative Templates: Microsoft Office Outlook 2007: Tools: Advanced Settings: Exchange.
4.18.2.2 Performance Note

MAPI uses a different data format from other protocols. This prevents cross-protocol compression from being effective. That is, a file that was first transferred via FTP and then as an email attachment will not receive a compression advantage on the second transfer. If the same data is sent twice via MAPI, the second transfer will receive full compression.
4-68
June 26, 2011
Figure 4-45 Disabling Encryption on Outlook 2007.
4-69
4.19 Joining a Windows Domain (CIFS/MAPI Enhancements)
4.19
Joining a Windows Domain (CIFS/MAPI Enhancements)
Release 6.0 allows the appliance to join a Windows domain, giving the following new capabilities: Acceleration of Signed Windows Filesystem (CIFS) traffic. Before, signed traffic could not be accelerated, and the signing feature (which was enabled by default), had to be disabled on fileservers. By joining the same Windows domain as the server, the server-side appliance can handle signed traffic. This feature works with servers using either the older SMB1 protocol (Windows 2003, Windows XP) and the newer SMB2 protocol (Windows 2008, Windows Vista, Windows 7). Acceleration of encrypted Outlook/Exchange (MAPI) traffic. Before, encrypted Outlook/Exchange traffic could not be accelerated. Since encryption was enabled by default on Outlook clients, acceleration required global policy changes. By joining the same Windows domain as the Exchange server, the server-side appliance becomes part of the security infrastructure and can accelerate encrypted MAPI traffic, and the mail clients can run with default settings.
4.19.1 Requirements
To benefit from joining a domain, the following must be true: Both the client-side and server-side appliances must have established a secure peer relationship, as with Repeater SSL compression. See Section 4.20. The Windows Domain controller must support NTLM version 1, which is disabled by default. Once this is enabled (on the Domain controller only), signed CIFS and encrypted MAPI will work with all the servers in the domain.
4.19.2 Joining the Windows Domain

Go to the Configuration: Windows Domain page and press the Join Domain button. Enter the domain administration credentials. The appliance will join the domain, which involves exchanging a shared secret with the domain controller, allowing the appliance to remain part of the domain indefinitely. (The domain administration credentials are not saved on the appliance.)
4-70
June 26, 2011
Figure 4-46 Joining a Windows domain.
4-71
4.20 SSL Compression
4.20
SSL Compression
SSL compression allows SSL connections (HTTPS traffic, for example) to be compressed using Branch Repeaters multi-session compression, giving compression ratios of up to 10,000:1. Encryption is maintained from end to end by splitting the connection into three encrypted segments: client to client-side Appliance, client-side Appliance to server-side Appliance, and server-side Appliance to server.
Figure 4-47 SSL Compression.
Ordinary SSL Connection
SSL Connection
Accelerated SSL Connection
Client-Side SSL Connection
WAN SSL Tunnel
Server-Side SSL Connection
Note: SSL Compression decrypts the encrypted data stream and, unless the User Data Encryption option is used, it leaves a persistent cleartext record of the decrypted data in the compression histories of both acceleration units. Verify that your deployment and settings are consistent with your organizations security policies. Note: When you enable SSL compression, the Appliance will stop attempting compression with units for which SSL compression is not enabled, and with non-authenticated units (whether Repeater, Branch Repeater, or Repeater Plugin). This feature is thus best-suited for networks where all units are configured for SSL compression. Note: When you enable SSL compression, you must manually type in the Key Store password each time the Appliance is restarted.
4-72
June 26, 2011
4.20.1 How SSL Compression Works

SSL compression allows you to accelerate encrypted traffic to your servers. SSL compression has access to the cleartext data of the connection because the sever-side Appliance acts as a security delegate of the endpoint servers. This is possible because the server-side Appliance is configured with copies of the servers security credentials (private keys and certificates), allowing it to act on the servers behalf. To the client, this is equivalent to communicating directly with the endpoint server. Because the Appliance is working as a security delegate of the server, most configuration is on the server-side Appliance. The client-side Appliance (or Plug-in) acts as a satellite of the server-side Appliance and doesnt require per-server configuration. The server-side and client-side units share session status through an SSL signaling connection. All accelerated connections between the two units are sent over SSL data connections, whether the original connections were encrypted or not. Note: This is not the same thing as encrypting all link traffic. Traffic that was originally encrypted will remain encrypted, but non-encrypted traffic will not always be encrypted. The Appliances do not attempt to encrypt non-accelerated traffic. Since there is no absolute guarantee that any given connection will be accelerated (various failures will prevent this), there is no guarantee that a given non-encrypted connection will be encrypted by the Appliances.
4.20.2 SSL Transparent Proxy and Split Proxy Modes

There are two SSL compression modes: transparent proxy and split proxy. They support slightly different SSL features, and the selection between the two modes is made according to the features a given application requires. Otherwise they are quite similar to each other.
4.20.2.1 SSL Split Proxy

Figure 4-48 SSL split proxy mode.
SSL Signaling Connection
Servers Credential
SSL Data Connection
Servers
SSL split proxy mode will be used in most instances, since it supports Temp RSA and Diffie-Hellman, which are required by many applications. In SSL split proxy mode, the server-side Appliance masquerades as a server to the client, and as a client to the server. You install server credentials (a certificate/key pair) on the server-side
Appliance to allow it to act on the servers behalf. You can also install optional client credentials, which are used when the application requires client authentication. Because the server-side Appliance is masquerading as a client, true client authentication is not supported in this mode (that is, the server cannot authenticate the actual endpoint client). If the server-side Appliance is not configured with client credentials, attempts at client authentication will fail. If the server-side Appliance is configured with client credentials, it will respond to client authentication with these credentials, regardless of the identity of the actual client. No configuration is required on the client-side Appliance (other than configuring a peer relationship with the server-side Appliance), and no configuration is required on the client, which sees the connection as if it were talking to the server directly. The server credentials on the server-side Appliance are not installed on the client-side Appliance. To support multiple servers, multiple private key/cert pairs can be installed on the Appliance, one per SSL profile. Special SSL rules in the service class definitions match up servers to SSL profiles, and thus SSL profiles to credentials. Due to the nature of a split proxy, the key/cert pairs and CA certificates do not actually have to match those of the servers. They can be any credentials that the client application will accept (valid credentials issued by a trusted authority). Note that, in the case of HTTPS connections, Web browsers will issue a warning if the common name does not match the domain name in the URL. In general, using copies of the servers credentials is the more trouble-free option.
4.20.2.2 SSL Transparent Proxy

Figure 4-49 SSL transparent proxy mode.
SSL Signaling Connection
Servers Private Keys
SSL Data Connection
SSL transparent proxy mode (not to be confused with transparent mode on the Repeater Plug-in), uses the server-side Appliance to masquerade as the server. The servers credentials (certificate/key pair) are installed on the server-side Appliance so it can act on the servers behalf. The server-side Appliance then configures the client-side Appliance to handle its end of the connection. The servers credentials are not installed on the client-side Appliance.
4-74 June 26, 2011
True client authentication is supported in this mode, but Temp RSA and Diffie-Hellman are not. SSL transparent proxy mode is suited for applications that require client authentication if the following features are not required: Diffie-Hellman, Temp RSA, TLS session tickets, SSL version 2. Also, session renegotiation must not be attempted, or the connection will terminate. No configuration is required on the client-side Appliance (other than configuring a peer relationship with the server-side Appliance), and no configuration is required on the client, which sees the connection exactly as if it were talking to the server directly. To support multiple servers, multiple private keys can be installed on the Appliance, one per SSL profile. Special SSL rules in the service class definitions match up servers to SSL profiles, and thus SSL profiles to private keys.
4.20.3 Generating Security Keys and Certificates

The software is shipped without the required keys and certificates for the SSL signaling tunnel. You must generate them yourself. This can be done through your normal process for generating credentials, or with the openssl package from http:// www.openssl.org. For testing purposes, a self-signed X509 certificate based on the private key (which you will also generate) can be used. In production, you would use certificates that referred to a trusted certifying authority, for proper authentication. The following example generates a private key (my.key) and self-signed certificate (my.crt):
# Generate a 2048-bit private key openssl genrsa -out my.key 2048 # Now create a Certificate Signing Request openssl req -new -key my.key -out my.csr # Finally, create a self-signed certificate with a 365-day expiration openssl x509 -req -days 365 -in my.csr -signkey my.key -out my.crt
For production use, consult your organizations security policies.
4.20.4 Configuring SSL Compression

4.20.4.1 Configuring the Appliance
The following procedure uses the Configuration: SSL Encryption, Configuration: Secure Partners, and Configuration: SSL Encryption pages. This pages are described in full in Sections 8.4.9, 8.4.11, and 8.4.12. Note: The Configuration: SSL Acceleration page has an unusual structure. It is divided into five tabs, but instead of having tab icons at the top, it has buttons at the bottom. The five tabs are: Profiles, Manage CAs, Manage Keys, Import SSL, and Export SSL.
4-75
Follow this procedure to set up SSL compression: 1. Hide the Configure SSL Connection Guide. These online instructions are less comprehensive than the ones you are reading now and should be ignored. Press the Hide Guide link at the upper right-hand corner of the online help block. 2. Install a crypto license. Without a crypto license, SSL Compression and User Data Encryption are not available, and you will see a yellow warning message to this effect on the Configuration: SSL Acceleration page. a. Order a crypto license from Citrix. b. Install the license via the System Settings: License Management: License Server tab if you are using a network license server, or the Configuration: Licensing: Local Licenses tab otherwise (see Section 8.4.4.3). c. Verify successful installation on the Licensed Features tab of the Configuration: Licensing page. The Crypto License heading should appear in the Licensed Features table and the crypto license expiration date should be in the feature. 3. Set a key store password, then open the key store. On the Configuration: SSL Encryption page, open the key store and assign a password to it. (You will have to re-enter this password after every restart, so dont forget it.) 4. (Recommended, but optional) Encrypt disk data by pressing the Enable Encryption button. This will prevent disk-based compression history from being read in case the unit is stolen or returned to the factory. The security of this feature relies on the key store password not being compromised. This feature uses AES-256 encryption. Note: If you use User Data Encryption, you will have to re-enter the key store password after every restart, even if SSL compression is disabled. 5. Enable SSL compression (under SSL Optimization) by pressing the Enable button. (However, compression will not take place until further configuration is done.) 6. Install credentials for the SSL signaling connection. The Appliances will use these credentials to authenticate each other, and to encrypt communications between each other. On each Appliance, acquire a CA certificate and certificate/ key pair for the SSL signaling connection. See the examples of certificate and key generation in Section 4.20.3. When using self-signed certificates, the same certificate can be used for the certificate and the CA certificate. When using proper certificates, these two would be different, and their use would be the same as in your other secure devices. a. Install the CA Certificate. On the Configuration: SSL Acceleration page, click the Manage CAs button at the bottom of the page, then press the Add button. Create a name for your CA certificate in the Name field. Us the Input Method field to select whether you would like to upload the CA certificate as a file or paste it into a text box, then install your CA certificate. Finally, press the Add button again. See Figure 4-50. (See also Section 8.4.11.) b. Install the Cert/Key Pair. This process is nearly identical to inserting the CA Certificate. Press the Manage Keys button at the bottom of the page, then press the Add button. Cert/key pairs are sometimes generated as a single
4-76 June 26, 2011
Figure 4-50 Installing certificates.
file and sometimes as two files. This page supports both formats. Choose the one that fits your cert/key pair, add the cert/key pair, and press the Add button again. 7. .Set up the SSL signaling connection on the Appliance. See Figure 4-51.
Figure 4-51 Configuring peer communication.
4-77
a. Enable Peer Connections. Select Enabled under Peer State. b. Select Cert/key and CA for Signaling Connection. On the Configuration: Secure Partners page, specifying the certificate/key pair and CA certificate store you installed in the previous step. c. Select Peer Authentication Method. Under Certificate Validation, select how authorized peers are identified. Signature/Expiration is the default: that is, the credentials are examined for authenticity based on their signature and expiration date. Other options include Signature/Expiration/Common Name White List, where the common name on the certificate must be present in a whitelist (which appears below the radio button when this option is selected); Signature/Expiration/Common Name Black List, where the common name must not appear in the blacklist (which appears below the radio button when this option is selected); and None. Note: When Certificate Validation: None is selected, the Appliance will attempt to perform SSL compression with any partner unit, regardless of identity. Since this will result in a record of encrypted connections being retained in the disk-based compression history of the partner Appliance, and encryption of this history can be disabled at the option of the remote Appliances administrator. It leaves open the possibility of automatic third-party interception and decryption of your encrypted traffic. This option should be used with caution. d. SSL Cipher Specification. This uses the OpenSSL syntax for specifying acceptable ciphers for the signaling connection. The signaling connection carries key information and should use a cipher specification suitable for this task, according to the standards used by your organization. You can create a new specification by clicking the link to the right of the text box. e. Auto-Discovery. Peers are selected either by auto-discovery or through the optional list of known peer IP addresses on the Connect To list. Select one method or the other. f. Publish Network Address Translation Addresses to Peers. If your network uses NAT and your Appliance cannot be reached at its signaling address, enter the address/port combination at which it can actually be reached here.
g. Listen On: This list specifies the addresses and ports on which the Appliance will listen for signaling connections. If already defined, the Repeater Plug-in signaling connection is the default. Otherwise, specify the address/port combination here. The address needs to be on the same subnet as the accelerated bridge, but different from the management IP on that subnet. Port 443 and 2312 are preferred. h. Connect To: A list of IP:port pairs of remote hosts. This can be used in addition to or instead of auto-discovery for identifying peers. i. Press Save. This should allow the Appliances to open secure SSL signaling connections with each other. (In fact, only one connection is needed, and it does not matter which Appliance succeeds in opening this connection. But configure both directions anyway.) This should happen after the next accelerated connection alerts the Appliance that a remote Appliance is available for an SSL signaling connection. At this point, the remote Appliance should appear on the Monitoring: Peer Status page. If accelerated connections are being established but the SSL signaling connection is not, check your settings.
June 26, 2011
4-78
8. Install credentials from your SSL server. Acquire copies of your servers certificate/private key pair and CA certificate and install them on the server-side Appliance, using the Cert/Key pairs and CA Certificates tabs on the Configuration: SSL Acceleration page. The procedure is the same as adding cert/key pairs and CA certificates for the signaling connection. 9. Set up a split-proxy SSL Profile for your SSL server. See Figure 4-52. (See the next step for transparent proxy.)
Figure 4-52 Configuring split proxy.
4-79
a. Go to the server-side Appliance only, go to the Configuration: SSL Acceleration page. b. Click the Add button to add a new profile. c. Profile Name. Type a profile name, usually the name of the server. d. Profile Enabled. Check the Profile Enabled box. e. Proxy Type. Select Split. f. Virtual Host Name. If your SSL server uses more than one virtual hostname, type the virtual hostname that matches the server credentials you supplied in the Virtual Host Name field. Otherwise, you can leave it blank. (To support multiple virtual hosts, you will create one SSL profile per hostname.) This option is only effective with TLS.
g. CA Certificate Store, Certificate/Private Key. Select the credentials you installed in the previous step for the CA Certificate Store and Certificate/Private Key fields. h. Build Certificate Chain. Causes the SSL certificate chain to be built by the server-side Appliance. Enabled by default. i. Certificate Verification. This option is the same as for peer verification. For example, if Signature/Expiration is chosen, the CA certificate store and key/ cert pair you installed must have a valid signature and be unexpired, or this profile will not be used. Server-Side Proxy Configuration. Selects the protocols that are allowed when talking to the server and specifies the ciphers.
j.
k. Authentication required. If checked, the servers credentials must match the credentials used in this profile. l. Renegotiation type. Allows SSL session renegotiation if checked. Disabled by default because of the possibility of renegotiation exploits.
m. Client-Side Proxy Configuration. Selects the protocols, ciphers, and renegotiation settings that are allowed when talking to the client-side unit. 10. (Optional) Create an SSL Transparent Proxy for your SSL server. SSL transparent proxy is less commonly used because its strict requirements are matched by fewer applications under their default configurations. However, Appliance configuration is simple. On the server-side Appliance only, go to the Profiles tab of the Configuration: SSL Acceleration page and create a profile: a. Click the Add button to add a new profile. b. Profile Name. Select a profile name for the Profile Name field. c. Profile Enabled. Check the Profile Enabled box. d. Proxy Type. Select Transparent. e. Virtual Host Name (optional). If your SSL server uses more than one virtual hostname, type the virtual hostname that matches the server credentials you supplied in the Virtual Host Name field. Otherwise, you can leave it blank. This option is effective only for TLS. To support multiple virtual host names, create multiple SSL Profiles. f. SSL Servers Private Key. Select your servers private key that you installed in step 8 for Private Key field.
g. Press the Add button.

4-80 June 26, 2011
11. Create an SSL service class. On the server-side Appliance, go to the Configuration: Service Classes page and create a new service class with appropriate SSL rules. We will take the example of an HTTPS server at 172.16.0.1:
Figure 4-53 SSL service class rules.
a. Create the Service Class. On the Configuration: Service Classes page, press the Create button. Type in a name for the new service class (for example, Accelerated HTTPS) and press the Create button. The new service class will appear at the top of the service class list. b. Enable Acceleration. Set the acceleration policy to Disk or Memory. c. Create a Rule. Click on the service classs name and press the New SSL Rule button. Specify the servers IP address in the SSL Server IP/Mask field (in this case, 172.16.0.1 or, equivalently, 172.16.0.1/32). In the SSL Server Port Range fields, specify a destination IP address of 172.16.0.1 and a port address of 443 in the first field of the Port Range section. d. Toggle the Bidirectional Icon (between the Src IP and Dst IP columns) to make the rule unidirectional. SSL rules do not work with bidirectional mode set. e. Attach the Rule to an SSL Profile. Each SSL rule is attached to one or more SSL profiles. Press the Add button and select the profile you created for this server, then press the Add button. f. Save the Rule. Press the Save button. g. Set service classes on the client-side Appliance. SSL traffic will not be compressed unless it falls into a service class on the client-side appliance that enables acceleration and compression. This can be an ordinary service-class rule, not an SSL rule (only the server-side appliance needs SSL rules), but it must enable acceleration and compression. The traffic will fall into an existing service class, such as HTTPS or Other TCP Traffic, and if this classs policy enables acceleration and compression, no additional configuration is needed. 12. Verify operation. SSL connections matching the SSL service class rules should now be compressed. To see if they are, look at the Monitoring: Connections list and click on the info balloon on the Details column for the connection. It will report the connections service class on the Detailed Connection Information
4.21 Additional Features
table. If this matches your SSL service class, SSL compression is taking place.
4.20.5 Using SSL Compression on the Repeater Plug-in

The Repeater Plug-in is always used as the client-side unit and thus requires no additional SSL configuration besides installing credentials for the SSL signaling connection. The main difference between SSL compression on the Plug-in and the Appliance is that no facility is provided to encrypt the user data in disk-based compression history. Note: Because disk-based compression history on the Plug-in is not encrypted, it retains a cleartext record of potentially sensitive and ephemeral encrypted communications. This is potentially dangerous on computers for which physical access is not controlled. Therefore, we recommend that you follow these best practices: Do not use Certificate Validation: None on your Appliances. Install certificates only on systems that can be verified to meet your organizations requirements for physical or data security (for example, laptops that are using full-disk encryption). Note that, in this case, the Appliance will refuse to allow compression with Plug-ins that do not have an appropriate certificate.
The Repeater Plug-in supports both SSL split proxy and SSL transparent proxy. The Plug-in ships without certificate/key pairs for the SSL signaling connection. If desired, the same credentials can be used by all Plug-ins, or each Plug-in can have its own credentials. The Plug-in will not attempt SSL compression unless credentials have been installed. The Plug-in inherits its crypto license from the Appliance. See Section 5.6.4 for instructions on installing SSL signaling connection credentials.
4.21
Additional Features
The following list gives, in brief, additional features that are not further elaborated in this section. Configuration details for these features are given in Chapter 8. SCPS support. Repeater supports the SCPS (Space Communications Protocol Standard) TCP variant starting with release 4.3. SCPS is widely used for satellite communication. See Section 8.2.2.9 for more information on the SCPS implementation. See http://www.scps.org for general SCPS information. SNMP support. See Section 8.4.7.7. Performance monitoring. Summary performance graphs are shown on the Dashboard page of the browser-based interface. Detailed performance information is given on additional pages in the Monitoring pages (Section 8.3) and the Reporting pages (Section 8.5). Debugging support. The Appliance detects many potential problems and reports them via the browser-based interface. An Alert feature warns the user whenever
4-82
June 26, 2011
a potential problem has been detected. Extensive log files are also kept. See Section 8.3.5. Remote software updates. The browser-based interface allows the administrator to install new version of the software. Previous versions are retained by the system, and it is possible to revert to an older version. See Section 8.6.6. Remote license upgrades. Each unit has a licensed bandwidth limit. This can be increased by installing a new license key using the browser-based interface. See Section 8.6.6. Two levels of user accounts are supported: Admin and Viewer. See Section 8.4.1.3. A serial interface allows access to the command-line interface. See Chapter 9.
4.22
Proxy Mode (Legacy Feature)
Note: Proxy mode is maintained as a legacy mode only. Its use in new installations is not recommended. CIFS acceleration is not supported under proxy mode. Proxy mode does not forward non-IP traffic, which causes trouble with some applications. Proxy mode allow the Appliance to accelerate connections when it is not in line with the data traffic. This make acceleration independent of network topology. For compatibility with other sites, proxying can also be used by inline Appliances.
4.22.0.1 Overview
For a connection to be accelerated, its data must pass through an Appliance at each end. This happens automatically in inline mode, since the Appliances are between the WAN and the target systems, and all data passing between these two systems must pass through the two Appliances. When the Appliance is not inline with the path between the two systems, packets must be addressed to it explicitly. The mechanism for this is to assign a virtual IP address (or VIP) to the Appliance. Applications use the virtual IP address instead the real IP address of the target system. For example, ftp Alpha-proxy is used instead of ftp Alpha. The local Appliance responds to the virtual IP address and forwards packets to the remote Appliance, which in turn forwards it to system Alpha. A proxy-mode Appliance can be anywhere; it does not have to be between the WAN and the systems to be accelerated. Proxy mode makes it easier to reserve an Appliance for specific, mission-critical uses, rather than using it for all traffic (important or otherwise) passing between two Repeater-equipped systems. Only those commands addressed to virtual IP addresses will be accelerated. Figure 4-54 shows how proxy mode accelerates connections between two networks. Any connection addressed to VIP address Beta-Proxy will create an accelerated connection with system Beta.
4-83
4.22 Proxy Mode (Legacy Feature)
Figure 4-54 Proxy mode connection from system Alpha to Beta.

Network A Network B
Appliance-A
VIP: "Beta-Proxy"
VIP: "Beta-Proxy-A"
Appliance-B
System "Alpha"
System "Beta"
1. User types command: ftp Beta-Proxy-A 2. Beta-Proxy-A is a VIP address on Appliance A. Appliance A changes the address from Beta-Proxy-A to Beta-Proxy, which is yet another VIP address, this time hosted on Appliance B. 3. Appliance B forwards the traffic to system Beta. 4. Returning packets follow this path in reverse. Only traffic sent through two Appliances is accelerated. This configuration allows systems on Network A to open accelerated connections with system Beta. The user must remember to use a virtual IP address rather than the actual IP address of the target system. For example, when initiating a connection from site Alpha: ftp Beta# Not accelerated (does not go through the Appliances) ftp Beta-Proxy# Accelerated (goes through the Appliances)
Once the connection is opened, data flowing in the reverse direction is also accelerated. That is, an ftp Beta-Proxy session will accelerate both get and put commands. However, the proxy in Figure 4-54 does not allow systems on Network B to open new accelerated connections with systems on Network A, since have not yet defined a VIP address that will serve as a proxy for a system on Network A. Figure 4-55 shows a reverse connection that allows systems to open accelerated connections with Alpha by addressing VIP Alpha-proxy. A single Appliance can have any number of virtual IP addresses, limited only by the number of unused IP addresses on its subnet.
4-84
June 26, 2011
Figure 4-55 Proxy mode connections from system Beta to Alpha.

Network A Network B
Appliance-A
VIP: "Beta-Proxy"
VIP: "Beta-Proxy-A"
Appliance-B
System "Alpha"
System "Beta"
Proxy Mode. When initiating a connection from site Beta: ftp Alpha# Not accelerated (does not go through the Appliances) ftp Alpha-Proxy# Accelerated (goes through Appliances)
4-85
4.22.0.2 Proxy Mode Topologies

Figure 4-56 Combinations of inline and proxy mode
Case 1. Inline Mode Server Network Case 2. Full Proxy Mode Server Client Network Network
Client Network
Server Case 3. Full Proxy Mode Server Client Network Network
Server Case 4. Full Proxy Mode Server Client Network Network
Server
Server
Client Side Case 1 2 3 4 Mode Inline Proxy Inline Proxy VIP Points To Server Server VIP (on server-side Appliance)
Server Side Mode Inline Inline Proxy Proxy VIP Points To Server Server
Proxy mode is shown in Figure 4-56. In proxy mode, there are only two parameters to configure: a VIP address and a server address. The server can be either a local server or a remote server. This section explains how full proxies work. See Section 8.4.2.7 for a description of the proxies page in the management interface. A proxy connection can be used with the units either inline or out-of-line. In fact, one end of the connection can be in inline mode and the other in proxy mode. The inline unit requires no configuration at all. This allows the simplicity of inline operation at remote offices, while allowing proxy mode (with its greater control) in central offices. All four case of inline vs. out-of-line units are supported by proxy mode, as shown in Figure 4-56.
4-86
June 26, 2011
Case 1 is inline mode. The servers actual IP address is used by the client. This requires no configuration and no proxies. All traffic that can be accelerated will be accelerated. The lack of configuration makes Case 1 desirable whenever the network topology favors it and the desire is to accelerate all traffic between Appliance-equipped sites. Case 2 shows the client operating in proxy mode, while the server uses inline mode. No configuration is required on the server network. On the client side, the proxy configuration defines a VIP on the local network whose target is the server on the remote network. Applications use the local VIP instead of the servers real address. To the application on the client network, the server appears to be on the local network. This mode provides targeted acceleration on the client network, since only commands using a VIP will be accelerated. It also allows the client-side Appliance to be placed anywhere, not just inline with the clients. The server network accelerates all traffic that can be accelerated. Case 3 shows the client running in inline mode, while the server uses proxy mode. On the server side, a VIP is defined that points to the server. Applications use this VIP instead of the servers real address. To the application on the client network, the server still appears to be on the remote network, but at its virtual address, not its real one. This configuration is especially useful for remote offices, because of the lack of configuration at the client site, while the proxy configuration is restricted to the home office, where there are presumably more IT resources. Proxy mode becomes necessary if an important server cannot be placed inline with an Appliance, for whatever reason. With proxy mode, the server can be anywhere. Case 4 shows both units operating in proxy mode. The server side is identical to case 3. On the client side, a VIP is defined that points to the server-side VIP (not to the server itself). This VIP-to-VIP proxy ensures that the packets will pass through both Appliances. To the application, the server appears to be on the local network. This configuration combines the advantages and disadvantages of proxies on the client and server sides. Any connections addressed to the client-side VIP, from any source, will receive acceleration. The client doesnt have to be on the same network as the client-side Appliance; it can be anywhere. Similarly, the server doesnt have to be on the same network as the server-side Appliance.
4.22.0.3 VIP-to-VIP Proxies

In Case 4, we used a VIP-to-VIP proxy. To access a remote server, the local Appliance had a proxy whose VIP pointed not to the server, but to a VIP on the remote network. Why was this done? For acceleration to take place, the data must pass through both Appliances. When a unit is not inline, data from a new connection reaches it in one of two ways: either because the client addressed the data to it (by using a VIP) or because the other Appliance forwarded the data to it.
4-87
In Case 4, the VIP used by the application got the data into the client-side Appliance. Now it must be forwarded to the server-side unit. This can be done using the server-side VIP that we used in Case 3. Thus, a VIP-to-VIP proxy provides a handoff between two non-inlined units. This is shown in Figure 4-57.
Figure 4-57 Proxy mode, showing VIP-to-VIP proxying.
Network A
WAN
Network B
VIP: "B-Beta-Proxy" VIP: "A-Beta-Proxy"
"Alpha" "Beta"
To systems on Network A, Beta appears to be a local system at address A-Beta-Proxy.
Points to keep in mind about proxy mode: Either, both, or neither Appliance may be inlined. Inlined units do not require configuration to communicate with full-proxy units; simply using the full-proxy VIP address (as in ftp Alpha-proxy) is sufficient. Either of the two Ethernet ports can be used. When the local VIP address points to a local system, it enables accelerated access to the local system. When the local VIP address points to a remote address, it enables accelerated access to a remote system. The virtual IP address will only function for accelerated TCP connections. The virtual IP address will not respond to remote non-TCP traffic or unaccelerated TCP connections (that is, connections that did not pass through another Appliance). One virtual IP address is used per local server, plus another per remote server when the remote server is not inlined. The number of virtual IP addresses is limited by the number of free IP addresses on the subnet containing the full-proxy Appliance. Because proxy mode performs packet forwarding, fail-to-wire mode is not available.
See Section 8.4.2.7 for a description of the Configuration: Advanced Deployments: Proxy configuration page.
4-88
June 26, 2011
Chapter5
TheRepeaterPlugin
5.1 About the Repeater Plug-in
Large Branch Office Servers
Figure 5-1 Repeater allows accelerated communications from clients worldwide.
Repeater 8500 Central Office Repeater 8800 Servers
Ordinary PCs
Small Branch Office (WAN Connected)
Repeater Plug-in
Private WAN Repeater 8800 Small Branch Office (Internet/VPN Connected)
VPN
Firewall Internet Firewall
Repeater Plug-in
Repeater Plug-in
Ordinary PCs
Home-Office VPN Users with Repeater Plug-in
Mobile VPN Users with Repeater Plug-in
Note: The Repeater Plug-In is not supported in the initial 6.0 Release. This chapter has been left here for reference.
5-1
Repeater accelerates communication between clients and servers: On the client side, the Repeater Plug-in is a software-based network accelerator that runs on end-users computers. On the server side, the Appliance is a rack-mount unit that accelerates the traffic from any number of servers. The Repeater 8500 Series, 8800 Series, and Branch Repeater VPX currently support Repeater Plug-in deployments. The Plug-in is supported by Citrix Receiver 1.2 and up, and can be distributed and managed by Citrix Receiver.
5.1.1
Acceleration Features
Acceleration is achieved primarily through these features: Persistent, disk-based compression. Traditional compression has no long-term memory; it cannot find repeated data patterns that happened more than a few kilobytes in the past. Repeater compression spans gigabytes of past traffic, allowing better compression (and far higher throughput) than be achieved with conventional methods. Under moderately favorable conditions, LAN data rates can be achieved over DSL and even dial-up connections. Compression ratios can run as high as 10,000:1. Transport acceleration, giving superior performance on congested, high-latency links. CIFS acceleration, providing vastly improved performance when using Windows file servers and other servers following the CIFS (Common Internet File System) standard. Microsoft Outlook (MAPI) acceleration, increasing performance when Outlook is used with Exchange Server. XenApp and XenDesktop (ICA and CGP) acceleration, enhancing the user experience of Citrix products.
These optimizations build upon one another. For example, CIFS transfers undergo not only CIFS acceleration, but transport acceleration and disk-based compression as well.
5.1.2
Supported Plug-in Platforms
The Repeater Plug-in is supported on desktop and laptop systems, but not on netbooks or thin clients. It is supported on the following operating systems: Windows XP Home Windows XP Professional Windows Vista (all 32-bit versions of Home Basic, Home Premium, Business, Enterprise, and Ultimate) Windows 7 (all 32-bit and 64-bit versions of Home Basic, Home Premium, Professional, Enterprise, and Ultimate). Pentium 4-class CPU 2 GB of RAM 2 GB of free disk space
June 26, 2011
Recommended hardware requirements are:

5-2
Chapter 5. The Repeater Plug-in
Minimum hardware requirements are: 1.0 GHz CPU 1 GB RAM 350 MB free disk space
5.1.3
Theory of Operation
Repeater uses your existing WAN/VPN infrastructure. Plug-in systems continue to access the LAN, WAN, and Internet as they always have. No changes are required to VPN software, routing tables, network settings, client applications, or server applications. Citrix AG-SE and AG-AE VPNs requires a small amount of Repeater-specific configuration (see Section 2.6.) Accelerated connections are passed from the Repeater Plug-in to the Appliance, which in turn passes them to the server. In other words, the Appliance acts as a proxy. In general, the Repeater Plug-in behaves like the Appliance, as described in Chapter 4. The rest of this section deals with Plug-in-specific behavior. Transparent vs. Redirector Mode. There are two variations on the way connections are handled by the Plug-in and Appliance: transparent mode and redirector mode. Transparent mode for Plug-in-to-Appliance acceleration is very similar to Appliance-to-Appliance acceleration. The Appliance must be on the path taken by the packets when traveling between the Plug-in and the server. As with Appliance-to-Appliance acceleration, transparent mode operates as a transparent proxy, preserving the source and destination IP address and port numbers from one end of the connection to the other. Redirector mode (not recommended) uses an explicit proxy. The Plug-in re-addresses outgoing packets to the Appliances redirector IP address. The Appliance in turn re-addresses the packets to the server, while changing the return address to point to itself rather than the Plug-in. In this mode, the Appliance does not have to be physically inline with the path between the WAN interface and the server (though this is the ideal deployment). Best practices: Use transparent mode when you can, and redirector mode when you must.
5-3
5.1.4
Detailed Description of Transparent Mode

Large Branch Office B Ordinary PCs Servers
Figure 5-2 Transparent mode, showing three of the possible acceleration paths.
Repeater B (8500) Central Office A
ACCELERATED
Repeater A2 (8800)
ACCELERATED
Repeater Plug-in
Servers
Repeater A1 (8800)
Private WAN Small Branch Office (Internet/VPN Connected)
VPN
Firewall Internet
Firewall
Repeater Plug-in
Repeater Plug-in
Ordinary PCs
ACCELERATED
Notes on transparent mode: Traffic flow. Transparent mode will accelerate connections between a Repeater Plug-in and a Plug-in-enabled Appliance. Licensing. Not all Appliances are licensed for use with the Plug-in, but existing 8000-Series Repeater Appliances can be upgraded. In the diagram, Repeater A2 does not need to be licensed for Plug-in acceleration, since Repeater A1 provides the Plug-in acceleration for site A. Daisy-chaining. If the connection passes through multiple Appliances on the way to the target Appliance, the Appliances in the middle must have daisy-chaining enabled, or acceleration will be blocked. In the diagram, traffic from home-office and mobile VPN users that is destined for Large Branch Office B is accelerated by Repeater B. For this to work, Repeaters A1 and A2 must have daisy-chaining enabled.
In transparent mode, the packets for accelerated connections must pass through the target Appliance, much as they do in Appliance-to-Appliance acceleration.
5-4 June 26, 2011
In transparent mode, the Plug-in is configured with a list of Appliances to use. It attempts to contact each Appliance, opening a signaling connection. If the signaling connection is successful, the Plug-in downloads the acceleration rules from the Appliances, which tell it which destination addresses the Appliance is willing to accelerate. When the Plug-in opens a new connection, it consults the acceleration rules. If the destination address matches any of the rules, the Plug-in attempts to accelerate the connection by attaching acceleration options to the initial packet in the connection (the SYN packet). If any Appliance known to the Plug-in attaches acceleration options to the SYN-ACK response packet, then the connection will be accelerated via that appliance. The application and server are unaware that this has happened; only the Plug-in software and the Appliance know that acceleration is taking place. Transparent mode resembles Appliance-to-Appliance acceleration, but is not identical to it. The differences are these: 1. Client-initiated connections only. Transparent mode accepts connections initiated by the Plug-in-equipped system only. If you use a Plug-in-equipped system as a server, server connections will not be accelerated. Appliance-to-Appliance acceleration, on the other hand, does not care which side has the client and which has the server. (Active-mode FTP is treated as a special case, since the connection initiating the data transfer requested by the Plug-in is opened by the server.) 2. Signaling connection. Transparent mode uses a signaling connection between the Plug-in and Appliance for the transmission of status information. Appliance-to-Appliance acceleration does not use a signaling connection. If the Plug-in cannot open a signaling connection, it will not attempt to accelerate connections through the Appliance. 3. Daisy-chaining. Appliances that might be in the middle, between a Plug-in and its selected target Appliance, need to enable daisy-chaining on the Tuning menu. Transparent mode is often combined with VPN usage, as shown in Figure 5-2. The Repeater Plug-in is compatible with most IPSec, and PPTP VPNs, and with Citrix AG-SE and AG-AE SSLVPNs.
5-5
5.1.4.1 Packet Flow in Transparent Mode

Packet flow in transparent mode is shown in Figure 5-3. It is almost identical to Appliance-to-Appliance acceleration, except that the decision of whether or not to attempt to accelerate the connection is based on acceleration rules downloaded over the signaling connection.
Figure 5-3 Packet flow in transparent mode.
The Repeater Plug-in looks up the destination address and sees that it matches a subnet accelerated by the appliance. It attaches Repeater options to the TCP header of the SYN packet. No addresses are changed. Src: 10.0.0.50, Dst: 10.200.0.10
Server 10.200.0.10
3 4 5 6
3 and recognizes that this is an
The appliance notes the SYN options accelerable connection. It strips the options from the packet and allows it to pass through to the server. No addresses are changed. Src: 10.0.0.50, Dst: 10.200.0.10
The server accepts the connection and responds with a TCP SYN-ACK packet. Src: 10.200.0.10, Dst: 10.0.0.50
The appliance tags the SYN-ACK packet with a TCP header option that shows that acceleration will take place. Src: 10.200.0.201, Dst: 10.0.0.50
6 The Repeater Plug-in receives the SYN-ACK packet. The
options in the packet headers indicate that the connection is accelerated. The Plug-in strips the options and passes the SYN-ACK packet to the application. The connection is now fully open and accelerated.
5-6
June 26, 2011
5.1.5
Detailed Description of Redirector Mode

Large Branch Office Servers
Figure 5-4 Redirector mode, showing one possible acceleration path.
Repeater 8500 Central Office Repeater 8800 Servers
Ordinary PCs
Repeater Plug-in
Private WAN Repeater 8800 Small Branch Office (Internet/VPN Connected)
ACCELERATED CONNECTION
Internet
VPN
Firewall Firewall
Repeater Plug-in
Repeater Plug-in
Ordinary PCs
Figure 5-4 shows the packet flow and address mapping in redirector mode. Redirector mode works differently from transparent mode: The Repeater Plug-in software redirects the packets by addressing them explicitly to the Appliance. This means that, unlike transparent mode, the redirector-mode Appliance does not have to transparently intercept all of the WAN link traffic. Because accelerated connections are addressed to it directly, it can be placed anywhere, so long as it can be reached by both the Plug-in and the server. The Appliance performs its optimizations, then redirects the output packets to the server, giving itself as the source of the packets. Thus, from the servers point of view, the connection originates at the Appliance. Return traffic from the server is addressed to the Appliance, which performs optimizations in the return direction and forwards the output packets to the Plug-in. The destination port numbers are not changed, so network monitoring applications can still classify the traffic.
5-7
Figure 5-5 Packet flow in redirector mode.

The Repeater Plug-in looks up the dst address and decides to redirect the connection to the appliance at 10.200.0.201. Src: 10.0.0.50, Dst: 10.200.0.201 (10.200.0.10 is preserved in a TCP option field. Options 24-31 are used for various parameters.)
Server 10.200.0.10
3 4 5 6
The appliance accepts the connection and forwards the packet to the server (using the dst address from the TCP options field), and giving itself as the src. Src: 10.200.0.201, Dst: 10.200.0.10
4 The server accepts the connection
and responds with a TCP SYN-ACK packet. Src: 10.200.0.10, Dst: 10.200.0.201
The appliance rewrites the addresses and forwards the packet to the Plugin (placing the server address in an option field). Src: 10.200.0.201, Dst: 10.0.0.50
6 The connection is now fully open. The client and server send packets
back and forth via the appliance. While the addresses are altered in Redirector mode, the destination port numbers are not (though the ephemeral port number may be). The data is not encapsulated. Redirector mode is a proxy, not a tunnel. There is no 1:1 relationship between packets (though in the end, the data received is always identical to the data sent). Compression may reduce many input packets into a single output packet. CIFS acceleration will perform speculative read-ahead and write-behind operations. Also, if packets are dropped between appliance and the Repeater Plug-in, the retransmission is handled by the appliance, not the server, using advanced recovery algorithms.
5.1.6
How the Plug-in Selects an Appliance
Each Plug-in is configured with a list of Appliances that it know about. When possible, it will accelerate connections using one of these Appliances. Note: Lists containing multiple Appliances are not recommended. The typical use case for the Repeater Plug-in is as a VPN accelerator, and the recommended deployment for a VPN accelerator is to place a Repeater Appliance inline with the VPN unit. This is the only Appliance that the Repeater Plug-in should attempt to communicate with. The Appliances each have a list of acceleration rules that are a list of target addresses or ports that the Appliance is willing to accelerate. The Plug-in downloads these rules from the Appliances and matches the destination address and port of each connection with each Appliances rule set. If only one Appliance offers to accelerate a given connection, then the selection is easy. If more than one Appliance offers to accelerate the connection, then the Plug-in must choose one of these Appliances.
5-8 June 26, 2011
The rules for this are as follows: 1. If all the Appliances offering to accelerate the connection are redirector-mode Appliances, then the leftmost Appliance on the Plug-ins Appliance list is selected. (If the Appliances were specified as DNS addresses, and the DNS record has multiple IP addresses, these too are scanned from left to right.) 2. If some of the Appliances offering to accelerate the connection use redirector mode and some use transparent mode, the transparent-mode Appliances are ignored and the selection is made from the redirector-mode Appliances. 3. If all of the Appliances offering to accelerate the connection use transparent mode, then no Appliance selection is made, per se. The connection is initiated with Repeater SYN options, and whichever candidate Appliance attaches appropriate options to the returning SYN-ACK packet is used. This allows the Appliance that is actually inline with the traffic to identify itself to the Plug-in. The Plug-in must have an open signaling connection with the responding Appliance, however, or acceleration will not take place. 4. Concept of a Primary Appliance. 5. Some configuration information is considered to be global. This configuration information is taken from the leftmost Appliance in
5.2
Deploying Appliances for Use With Plug-ins
Note: You must read all of Chapter 2 in addition to this section.
5.2.1
Use a Dedicated Appliance Where Practical
Attempting to use the same Appliance for both Plug-in acceleration and link acceleration is often difficult, as the two uses sometimes call for the Appliance to be at different points in the datacenter and the two uses can call for different service-class rules. In addition, a single appliance can serve as an endpoint for Plug-in acceleration or as an endpoint for site-to-site acceleration, but cannot serve both purposes for the same connection at the same time. This means that when you use an Appliance for both Plug-in acceleration for your VPN and for site-to-site acceleration to a remote datacenter, Plug-in users will not receive site-to-site acceleration. The seriousness of this problem depends on how much of the data used by Plug-in users comes from remote sites. Finally, a dedicated Appliances resources are not divided between Plug-in and site-to-site demands, giving more resources and thus higher performance to each Plug-in user.
5.2.2
Use Inline Mode When Possible
An Appliance should be deployed on the same site as the VPN unit it supports. Typically, the two units are inline with each other. An inline deployment gives the simplest configuration, the most features, and the highest performance. For best results, the Appliance should be directly inline with the VPN unit, as shown in Figure 2-11.
5-9
5.2 Deploying Appliances for Use With Plug-ins
However, Appliances can use any of the deployment modes described in Chapter 2, with the exception of group mode. These modes are suitable for both Appliance-to-Appliance and client-to-Appliance acceleration, and can be used for either redirector or transparent mode.
5.2.3
Put the Appliances in a Secure Part of your Network
The Appliance is not a security device and depends on your existing security infrastructure in the same way that your servers do. It should be placed on the same side of the firewall (and VPN unit, if used) as the servers.
5.2.4
Avoid NAT Problems
Network address translation (NAT) at the Plug-in side is handled transparently and is not a concern. At the Appliance side, NAT can be troublesome. Use these guidelines to ensure a smooth deployment: Put the Appliance in the same address space as the servers, so that whatever address modifications are used to reach the servers are applied to the Appliance as well. Never access the Appliance using an address that the Appliance does not associate with itself. The Appliance needs to be able to access the servers using the same IP addresses that the Plug-in uses to access the same servers. In short, do not apply NAT to the addresses of servers or Appliances.
5.2.5
Select Softboost Mode
On the Configure Settings: Bandwidth Management page, select Softboost mode. Softboost is the only supported mode with the Repeater Plug-in.
5.2.6
Define Plug-in Acceleration Rules
The client rules tell the clients which Appliances to send their traffic to. Each rule specifies an address or subnet and a port range that the Appliance can accelerate. What to Accelerate. The choice of what traffic to accelerate depends on the use the Appliance is being put to: VPN accelerator. If the Appliance is being used as a VPN accelerator, with all VPN traffic passing through the Appliance, then all TCP traffic should be accelerated, regardless of destination. Redirector mode. Unlike transparent mode, Redirector mode is an explicit proxy, causing the Plug-in to forward its traffic to the Redirector-mode Appliance even when this is a bad idea. Acceleration can be harmful if the client forwards traffic to an Appliance that is distant from the server, especially if this triangle route introduces a slow or unreliable link. Thus, we recommend that acceleration rules be configured to allow a given Appliance to accelerate its own site only. Other Uses. Acceleration is most effective when the Plug-in and the Appliance are at the opposite ends of the bottleneck link In the VPN accelerator case discussed above, the bottleneck link is assumed to be the end-users Internet connection. When used in a non-VPN WAN environment, it depends on the topology. One soluJune 26, 2011
5-10
tion is to put the Appliance in the same datacenter as the endpoint servers, to ensure that no bottleneck link can exist between the Appliance and the servers. Setting Acceleration Rules. This task is performed on Appliance via the Configure Settings: Repeater Plug-in: Acceleration Rules tab. Rules are evaluated in order, and the action (Accelerate or Exclude) from the first matching rule is taken. For a connection to be accelerated, it must match an Accelerate rule. Otherwise, the connection is made directly with the target server.
Figure 5-6 Setting Plug-in rules on the Appliance
5.2.6.1 Procedure
On the Configure Settings: Repeater Plug-in: Acceleration Rules tab: Add an Accelerated rule for each local LAN subnet that can be reached by the Appliance. That is, press the ADD button, specify Accelerate, and type in the subnet IP/mask. Repeat for each subnet that is local to the Appliance.
If you need to exclude some portion of the included range, add an Exclude rule and move it above the more general rule. For example, 10.217.1.99 looks like a local address but is really the local endpoint of a VPN unit, create an Exclude rule for it on a line above the Accelerate rule for 10.217.1.0/24. If you wish to use acceleration only for a single port (not recommended), such as port 80 for HTTP, replace the wildcard in the Ports field with this value. To support more than one port, add additional rules, one per port. In general, narrow rules (usually exceptions) should be listed first, then general rules. Press the Save link. Changes will not be saved if you navigate away from this page without saving. The default action is to not accelerate; only addresses/ports that match an Accelerated rule (before matching an Excluded rule) are accelerated.
5-11
5.3 Deploying Plug-ins
5.2.7
Port Usage
Ports used for communication with Repeater Plug-in. The Plug-in maintains a dialog with the Appliance over a signaling connection, which by default on port 443 (HTTPS), which is allowed through most firewalls. Ports used for communication with servers. Communication between the Repeater Plug-in and the Appliance uses the original ports (the same ports that would be used if the Plug-in and Appliance were not present). That is, when a client opens an HTTP connection on port 80, it connects to the Appliance on port 80. The Appliance in turn contacts the server on port 80. In redirector mode, only the well-known port is preserved (that is, the destination port on the TCP SYN packet). The ephemeral port is not preserved. In transparent mode, both ports are preserved. The Appliance assumes that it will be able to communicate with the server on any port requested by the client, and the client assumes that it can communicate with the Appliance on any desired port. This works well if Appliance is subject to the same firewall rules as the servers. When this is the case, any connection that would succeed in a direct connection will also succeed in an accelerated connection.
5.2.8
TCP Option Usage and Firewalls
Repeater parameters are sent via TCP options. These may occur in any packet, and are guaranteed to be present in the SYN and SYN-ACK packets that establish the connection. Your firewall must not block TCP options in the range of 24-31 (decimal), or acceleration cannot take place, and accelerated connections will be blocked. Most firewalls do not block these options. However, Cisco PIX and ASA firewalls with release 7.x firmware may do so by default. See Section 3.5.4.1 for more information.
5.2.9
Compatibility Issue with Pre-Release-4.3 Appliances
The presence of another Appliance between the target Appliance and the Repeater Plug-in will prevent the connection from opening if it is running release 3.x or below. Workaround: Upgrade the offending Appliance to release 4.3 or higher.
5.3
Deploying Plug-ins
The Repeater Plug-in is an executable MSI (Microsoft installer) file that is downloaded and installed as with any other Web-distributed program. This file is obtained from the MyCitrix section of the Citrix.com Website. Note: On the Repeater Plug-in user interface, it refers to itself as Citrix Acceleration Manager, rather than Repeater Plug-in.
5-12
June 26, 2011
There is very little Plug-in configuration. The Plug-in software is distributed as an executable file in.MSI (MicroSoft Installer) format, which is downloaded or otherwise copied onto the Plug-in PC as with any other software. Executing this file walks the user through the installation process. A reboot is required before the Plug-in becomes active. The only configuration needed by the Plug-in is the list of Appliance addresses. This list can consists of a comma-separated list of IP or DNS address. The two forms can be mixed. You can customize the distribution file so that this points to your Appliances by default. If you do this, the user does not need to enter any configuration information at all. Otherwise, the user must enter the IP address of the Appliances. If you define a DNS address that returns multiple IP addresses (which is a standard practice), then you can define a single DNS address that will return the addresses of all your Plug-in-capable Appliances. This allows you to add, remove, or move Appliances without reconfiguring the Plug-ins. Once installed, operation is transparent. Traffic to accelerated subnets is sent through an appropriate Appliance; all other traffic is sent directly to the server. The user application is unaware that any of this has happened.
5.3.1
Customizing the Plug-in MSI File
Customization involves changing parameters in the Repeater Plug-in distribution file. This requires the use of an MSI editor. Note: The altered parameters in your edited.MSI file are only used on new installations. When existing Plug-in users update to a new release, their existing settings are retained. Thus, after changing the parameters, you should advise your users to uninstall the old version before installing the new one. Best Practices: Create a DNS entry that resolves to the nearest Plug-in-enabled Appliance. For example, define Repeater.mycompany.com and have it resolve to your Appliance (if you have only one Appliance) or one of your five Appliances (if you have five Appliances), based on the location of the DNS server. Build this address into your Plug-in binary with Orca. When you add, move, or remove Appliances, changing this single DNS definition on your DNS server will update the Appliance list on your Plug-ins automatically. You can also have the DNS entry resolve to multiple Appliances, but this is undesirable unless all Appliances are configured identically, because the Plug-in takes some of it characteristics from the leftmost appliance in the list and applies them globally (including SSL compression characteristics). This can lead to undesirable and confusing results, especially if the DNS server rotates the order of IPs on each request. Installing Orca. There are many MSI editors. We will use Microsofts Orca MSI editor, which is part of Microsofts free Platform SDK, which can be downloaded from: http://www.microsoft.com/downloads/details.aspx?FamilyID=0baf2b35-c656-4969-ace8-e4c0c0716adb&DisplayLang=en
5-13
Download the PSDK-x86.exe version of the SDK and execute it. Follow the installation instructions. Once the SDK is installed, the Orca editor must be installed. It will be under Microsoft Platform SDK\Bin\Orca.Msi. Launch Orca.msi to install the actual Orca editor (orca.exe). Running Orca. The Orca documentation can be read at http://support.microsoft.com/kb/255905. We will discuss only the steps needed to edit the most important Plug-in parameters. Launch Orca with Start -> All Programs -> Orca. This will give you a blank Orca window. Open the Repeater Plug-in MSI file with File -> Open.., as shown in Figure 5-7.
Figure 5-7 Using Orca.
On the Tables menu, click Property. This page will list all the editable properties of the .MSI file. We are only interested in the two parameters shown in Figure 5-8 To edit a parameter, double-click on its value, type the new value, and press Enter, as shown in Figure 5-9. When done, use the File -> Save As.. command to save your edited file with a new filename; for example, test.msi.
5-14
June 26, 2011
Figure 5-8 Plug-in parameters.
Parameter WSAPPLIANCES
Description List of Appliances
DBCMINSIZE
Minimum amount of disk space to use for compression, in megabytes
PRIVATEKEYPEM
Private key for the Plug-in. Part of the certificate/key pair used with SSL compression
Default Comments None Enter the IP or DNS addresses of your Appliances here. Comma-separated list in the form of { Appliance1, Appliance2, Appliance3 }. If the port used for signaling connections is different from the default (443), specify this in the form Appliance1:port_number. 250 Changing this to a larger value (for example, 2000) will improve compression performance, but will prevent installation if there is not enough disk space. The Plug-in will not install unless there is at least DBCMINSIZE + 100 MB of free disk space. None Use Orcas Paste Cell command, as the normal Paste function does not preserve the keys format. Should be a private key in PEM format (starting with -----BEGIN RSA PRIVATE KEY-----) Use Orcas Paste Cell command, as the normal Paste function does not preserve the keys format. Should be a certificate in PEM format (starting with -----BEGIN CERTIFICATE -----) Use Orcas Paste Cell command, as the normal Paste function does not preserve the keys format. Should be a certificate in PEM format (starting with -----BEGIN CERTIFICATE -----)
X509CERTPEM Certificate for the None Plug-in. Part of the certificate/key pair used with SSL compression CACERTPEM Certification Authority Certificate for the Plug-in. Used with SSL compression None
5-15
Figure 5-9 Editing parameters in Orca.
Your Plug-in software has now been customized. Note: Some users have seen a bug in orca that causes it to truncate files to 1 MB. Check the size of the saved file. If it has been truncated, make a copy of the original file and use the Save command to overwrite the original.
5.3.2
Using Customized Plug-in Software
Once you have customized the Appliance list with Orca and distribute the customized MSI file to your users, the user does not need to type in any configuration information when installing the software. The basic method of performing this is to use an MSI file editor. The details are given in Section 5.3.1.
5-16
June 26, 2011
6. 7.
Obtain the Repeater Plug-in software (a file in the form of Repeater*.msi) from your Citrix representative. Copy the file to the client system by some convenient means (shared filesystem, FTP server, Web download, etc.)
5.3.3
Installation
Initial installation screen.
Figure 5-10
Note: he steps below are for an interactive installation. A silent installation can be performed with the command:
msiexec /i client_msi_file /qn
8.
The Repeater*.msi file is an installation file. Close all applications and open windows, then launch the installer it in the usual way (double-click on it in a file window, or use the Run command). The installation program will ask you where to install the software. This directory will be used for both the client software and the disk-based compression history. Together, they require a minimum of 350 MB of disk space.
9.
5-17
10.
Once the installer finishes, you it may ask you to restart the system. After restarting, the Repeater Plug-in will start automatically. Final installation screen.
Figure 5-11
5.3.4
Installation Troubleshooting
Deterministic Network Enhancer locking error. On rare occasions you will see following error message twice (after rebooting as instructed the first time):
Deterministic Network Enhancer installation requires a reboot first, to free locked resources. Please run this install again after restarting the computer.
If this occurs, do the following: Go to Add/Remove Programs and remove the Repeater Plug-in, if present. Go to Control Panel: Network Adapters: Local Area Connection: Properties, find the entry for Deterministic Network Enhancer, uncheck its entry, and press OK. (Your network adapter may be called by some other name than Local Area Connection.) Open a command window and go to c:\windows\inf (or the equivalent directory if you have installed Windows in a non-standard place).
5-18 June 26, 2011
Type the command:

find dne2000.cat oem*.inf
Find the highest-numbered oem*.inf file that returned a matching line (it will read, CatalogFile= dne2000.cat) and edit it. For example:
notepad oem13.inf
Delete everything except the three lines at the top that start with semicolons. Save the file. Retry the installation. Other installation problems. If you have any difficulty with the installation step, the problem is usually that existing networking, firewall, or antivirus software is interfering with the installation. Usually, once the installation is complete, there are no further problems. If the installation fails, try these steps: Make sure the Plug-in installation file has been copied to your local system. Disconnect any active VPN/remote networking clients. Disable any firewall and antivirus software temporarily. If some of this is difficult, do what you can. Reinstall the Repeater Plug-in. If this doesnt work, reboot the system and try again.
5-19
5.3.5
11.
Running the Plug-in For the First Time

Right-click the Accelerator icon in the task bar and select Manage Acceleration to launch the Citrix Accelerator Manager. Citrix Accelerator Manager, initial (performance) tab.
Figure 5-12
12.
Press the Configuration tab. Set the following parameters: (This step can be skipped if the .MSI file was customized for your users.) Enter the signaling IP address of your Appliance in the Appliances: Signaling Addresses field. If you have more than one Plug-in-enabled Appliance, list them all, separated by commas. Either IP or DNS addresses are acceptable. Select an amount of disk space to use for compression, via Disk Usage: Used by Compression.More is better. 10 GB is not too much, if you have this much disk space available. Press the Save button.
5-20
June 26, 2011
Figure 5-13
Citrix Accelerator Manager, configuration tab
13.
The Repeater accelerator is now running. All future connections to accelerated subnets will be accelerated
5-21
5.4 Testing the Installation
5.4
14.
Testing the Installation

On the Plug-ins Configuration tab, the Acceleration Rules table should show each Appliance as Connected and each Appliances accelerated subnets as Accelerated. If not, check the Signaling Addresses IP field and your network connectivity in general.
5.5

Troubleshooting Plug-ins
If you fail to reboot the system when requested, the Repeater Plug-in will not run properly. A highly fragmented disk can result in poor compression performance. However, once the Repeater disk-based compression file is defragmented, it will remain defragmented forever. A failure of acceleration (with no accelerated connections listed in the Diagnostics tab usually indicates that something is preventing communication with the Appliance. Check the Configuration: Acceleration Rules listing on the Plug-in, to make sure that the Appliance is being contacted successfully and that the target address is included in one of the acceleration rules. Typical causes of connection failures are: The Appliance is not running, or acceleration has been disabled. A firewall is stripping Repeater TCP options at some point between the Plug-in and Appliance (see Section 3.5.4.1. The Plug-in is using an unsupported VPN.
5-22
June 26, 2011
5.6
5.6.1
Repeater Plug-in Command Reference

Configuration Tab
Citrix Accelerator Manager, configuration tab
Figure 5-14
The Configuration page contains the user-settable commands. These consist of: Accelerator Appliances (Must be set): The Signaling Addresses field specifies the IP address of each Appliance that will be used by the Plug-in. If you have more than one Appliance, this can be a comma-separated list (though this is not the recommended configuration). This is an ordered list, with the leftmost Appliances having precedence over the others. Acceleration will be attempted with the leftmost Appliance for which a signaling connection can be established. Both DNS addresses and IP addresses can be used. Examples: 10.200.33.200, ws.mycompany.com, ws2.mycompany.com Disk Usage: Allows the user to select the amount of disk space used by compression. More is better. 10 GB is not too much. Show SSL Configuration: Makes the Certificates tab visible.
5-23
5.6 Repeater Plug-in Command Reference
Acceleration Rules: Gives an abbreviated list of the acceleration rules downloaded from the Appliances. The Appliances signaling address and port are shown, the acceleration mode (redirector or transparent), and its connection state, followed by a summary of the Appliances rules. Save: If changes are made, they do not take effect until the Save button is pressed. Saved changes are persistent across reboots. Enable Citrix Accelerator: Enables the Repeater service, if it is stopped. The enabling process takes several seconds. The enable/disable choice is persistent across system restarts. Disable Citrix Accelerator: The reverse case from the Enable button. Accelerated connections will be reset. Status Line: The status line at the bottom of the page gives the current operational status and the revision number of the Plug-in.
5-24
June 26, 2011
5.6.2
Performance Tab
Citrix Accelerator Manager, performance tab.
Figure 5-15
The Performance page gives the current performance of accelerated connections, as seen by the application. Accelerated Traffic. This is a second-by-second performance graph, giving the data delivered to or received from applications in any given second. This may be higher than the link speed, since compression increases the effective link bandwidth. Only accelerated traffic is shown. Bytes Before Compression. This is the amount of data accepted from applications or delivered to them, counting only accelerated connections. Bytes After Compression. This is the amount of data actually send over the WAN link, counting only accelerated connections. Bytes Non-Accelerated. This is the amount of other data send and received, counting both WAN and LAN connections. Compression Ratio. This is the ratio of bytes before compression divided by bytes after compression. This is a cumulative measurement of the compression results since the last system reboot (or the last time the Repeater server process
5-25
was started). It is dependent on the amount of repetition seen in the accelerated data. Individual connections vary between 1:1 and 10,000:1 compression.
5.6.3
Diagnostics Tab
Citrix Accelerator Manager, diagnostics tab
Figure 5-16
The Diagnostics page reports the number of connections in different categories, and other useful information. Accelerated Connections: The number of open connections between the Repeater Plug-in and Appliances. This includes one signaling connection per Appliance but does not include accelerated CIFS connections. Pressing More will pop up a window with a brief summary of each connection. The field are: Plug-in IP and port, server IP and port, and amount of data transferred. (All of the More buttons allow you to copy the information in the window to the clipboard, if you want to share it with Support.) Accelerated CIFS Connections: The number of open, accelerated connections with CIFS (Windows filesystem) servers. This is usually the same as the number of mounted network filesystems. Pressing More gives the same information as with
June 26, 2011
5-26
Figure 5-17
Detailed connection display from a More.. button.
accelerated connections, plus a status field that reports Active if the CIFS connection is running with our special CIFS optimizations. Unaccelerated Connections: Open connections that are not being accelerated. If you press the More button, you will see a brief description of why this connection was not accelerated. Typically, this is because no Appliance accelerates the destination address, which is reported as Service policy rule. Opening/Closing Connections: Connections that are not fully open, but are in the process of opening or closing (TCP half-open or half-closed connections). The More button will provide more (but cryptic) details. Alerts: The number of current active Plug-in alert messages. Alerts are significant error or warning messages. These can be listed by pressing the More.. button or cleared with the Erase.. button. Memory Dumps. On certain errors, the Plug-in will exit and leave a core dump behind. The Perform Full Dumps option allows core dumps to be long or short. Full dumps are preferred by Support. Plug-in Name: The name of this Plug-in system as seen by the Appliances. Usually the same as the Windows hostname of the client system. Start Tracing/Stop Tracing. Your Citrix representative may ask you to make a connection trace to help pinpoint problems. This button starts and stops the trace. When you stop tracing, a window pops up showing the trace files. These should be sent to your Citrix representative by the means they recommend. Clear Compression History. This feature should not be used. Clear Statistics. Pressing this button will clear the statistics on the Performance tab. Console. A scrollable window with recent status messages, mostly connection open/connection close messages, but also error and miscellaneous status messages. Open in Notepad. Allows you to view the status messages in a larger window, or, if necessary, send them to Support.
5-27
5.6.4
Certificates Tab
This tab allows you to install security credentials for the SSL compression feature. The purpose of these security credentials is to allow the Appliance to verify whether the Plug-in is a trusted client or not. See Section 4.20 for more information on SSL Compression. Note: This tab is hidden until the Show SSL Configuration checkbox is checked on the Configuration tab. This tab is hidden by default. To enable it, you must first configure the Plug-in to connect to an Appliance with SSL compression enabled. Once the signaling connection is active, the Show SSL Configuration checkbox on the Configuration tab becomes accessible. Check this box and press Save.
Figure 5-18 Enabling the Certificates tab (left). The Certificates tab (right).
Once the Certificates tab becomes visible, you can upload CA certificates and certificate/key pairs (called client certificates on the tab). To upload the CA certificate and certificate/key pair: 1. Click the CA Certificate Management radio button. 2. Press the Import button. 3. Upload a CA certificate. The certificate file must use one of the supported file types (.pem, .crt., .cer, or .spc. The examples given in Section 4.20.3 are in PEM format.) A dialog box may ask you to Select the certificate store you want to use, presenting you with a list of keywords. Select the first keyword on the list. 4. Click the Client Certificate Management radio button.
5-28 June 26, 2011
5. Press the Import button. 6. Select the format of the certificate/key pair (either PKCS12 or PEM/DER). a. In the case of PEM/DER, there are separate upload boxes for certificate and key. If your cert/key pair is combined in a single file, specify the file twice, once for each box. b. Press the Submit button.
5.6.5
Uninstalling the Repeater Plug-in
To uninstall the Repeater Plug-in, use the Add/Remove Programs utility under Control Panel. The Repeater Plug-in is listed as Citrix Acceleration Plug-in in the list of currently installed programs. Select it and press the Remove button. You must restart the system to finish uninstalling the client.
5.6.6
Updating the Repeater Plug-in
To install a newer version of the Repeater Plug-in, follow the same procedure you used when installing the Plug-in for the first time.
5-29
5-30
June 26, 2011
Chapter 6
Branch Repeater VPX
6.1
About Branch Repeater VPX
Branch Repeater VPX is software product that acts a virtualized Repeater Appliance, roughly equivalent in functionality to the Repeater 8500 Series. Because it is a virtual machine, you can deploy it using your choice of hardware, exactly where you need it, and combined it with other virtual machines -- servers, VPN units, or other appliances -- to create a unit that precisely suits your needs. Branch Repeater VPX software is available as a Xen virtual machine running under XenServer 5.5 and later, or as a VMware vSphere virtual machine running under ESX/ ESXi 4.1.
6.1.1
Uses For Branch Repeater VPX
1. Branch-office accelerator. Branch Repeater VPX can be installed on the server of your choice and deployed just like any other Branch Repeater Appliance, as shown below. With the exception of group mode and high-availability mode (which are not supported), Branch Repeater VPX has the same functionality as the Branch Repeater appliance, plus additional features provided by virtualization.
Figure 6-1 VPX use case #1: Branch-office accelerator
2. Accelerated branch-office server. If you take the previous configuration and add another virtual machine, you have an accelerated branch-office server, as shown below. Simply assign the virtual networks within the machine so that the path to the WAN passes through Branch Repeater VPX, and all WAN traffic will be accelerated automatically.
6-1
6.1 About Branch Repeater VPX
The virtual environment allows you to add whatever functionality you like to the server unit, with your choice of operating system and features. Whatever you install, Branch Repeater VPX will accelerate its WAN traffic network filesystem access, Web traffic, backups, remote applications, database queries, and so on. More than that, it will accelerate all the WAN traffic from every system in the branch office. You can even deploy multiple virtual servers on the same machine, consolidating your branch-office rack down to a single unit running multiple virtual machines.
Figure 6-2 VPX use case #2: Accelerated branch-office server
3. Accelerated datacenter servers. By installing Branch Repeater VPX in every server in the datacenter, you have a solution that scales perfectly as you add server capacity, while minimizing the number of servers by adding acceleration to the servers themselves. Once you have more than a few accelerated servers, the aggregate acceleration provided by multiple Branch Repeater VPX instances will exceed anything that can be provided with a single Appliance. Branch Repeater VPX will accelerate all kinds of network applications, including XenApp, XenDesktop, Citrix Merchandising Server, network filesystems, databases, Web server, and more.
6-2
June 26, 2011
Chapter 6. Branch Repeater VPX
Figure 6-3 VPX use case #3: Accelerated Endpoint Servers
4. VPN accelerator. By installing the VPN of your choice with Repeater VPX, you have an accelerated VPN. (Note that, unlike the other configurations, the VPN virtual machine is on the WAN side and Branch Repeater VPX is on the LAN side, because Branch Repeater VPX needs to see the decrypted VPN traffic to achieve compression and application acceleration).
Figure 6-4 VPX use case #4: VPN accelerator
6-3
6.1 About Branch Repeater VPX
5. Multiple Branch Repeater VPX Instances. By putting multiple instances of Branch Repeater VPX on the same server, you can create different types or levels of acceleration services within the same unit. One VPX instance might be dedicated to a critical application, or each instance dedicated to an individual remote site or customer.
Figure 6-5 VPX use case #5: Multiple instances for dedicated acceleration resources, using VLAN switches to direct traffic to the appropriate Branch Repeater VPX
6. WCCP deployment. The previous examples all used inline mode. Single-ended modes can also be used. Traffic is sent to Branch Repeater VPX by the WAN router. WCCP is the recommended mode for single-ended deployments.
Figure 6-6 VPX use case #6: WCCP deployment
6.1.2

Other Branch Repeater VPX Features
Support of Citrix Command Center 4.0 and up. Support of Branch Repeater VPX Express licenses, which support a maximum accelerated sending rate of 512 kbps, 10 accelerated connections, and 5 Repeater Plug-ins.
6-4
June 26, 2011
VPX for XenServer: XenServer Essentials Support XenMotion Live Migration XenServer High Availability Workload Balancing Performance Monitoring and Alerts VMWare vCenter Server (remote management). VMWare vSphere HA (high availability). VMWare vSphere vMotion (migrate Branch Repeater VPX to a different server with identical processors). VMWare Guest Customization (replicate VPX with different per-instance parameters).
VPX for VMware vSphere (See Note, below):
6.2
Differences Between VPX and Repeater
In general, Branch Repeater VPX resembles a Repeater 8500-Series Appliance, including support for the Repeater Plug-in and links up to 45 mbps. As such, most of the material in this Users Guide applies equally to Repeater and Branch Repeater VPX appliances. As you read this Users Guide, keep in mind the following differences between VPX and Repeater: Licensing via remote license servers is now mandatory for retail (production) licenses. Local licensing is still available for non-retail licenses, such as evaluation and VPX Express licenses. Branch Repeater VPX also obtains its Repeater Plug-in licenses from the remote license server. Plug-ins connecting to multiple VPX Appliances will consume only a single Plug-in license, not one license per Appliance, provided that all Appliances use the same license server. The Repeater LCD front-panel display is not supported. The RS-232 serial command interface is not supported. Multiple accelerated bridges are not supported. Ethernet bypass cards are not supported. Group mode is not supported. Repeater High-availability mode is not supported. (XenServer HA and vSphere HA are supported.)
In cases where an Ethernet bypass card is desirable, using WCCP instead of inline mode will provide an effective failover mechanism.
6-5
6.3 System Requirements and Provisioning
6.3
System Requirements and Provisioning
Branch Repeater VPX runs under XenServer 5.5 and VMware vSphere ESX/ESXi 4.1. Branch Repeater VPX supports four configurations, from 2-8 GB of RAM and 100-500 GB of disk. The intermediate, 4 GB RAM/250 GB disk configuration is similar to the Repeater 8500 Series appliance.
6.3.1
Supported Configurations
Note: The configurations below are the only supported configurations.

Figure 6-7 Production configurations, XenServer and VMware vSphere.
Type
2 GB production config. 4 GB production config. 4 GB production config.* 8 GB production config. * With 45mbps license
vCPUs
2 2 2 4
RAM
2 GB 4 GB 4 GB 8 GB
Disk
100 GB 250 GB 250 GB 500 GB
Max. WAN Speed

2 mbps 10 mbps 45 mbps 45 mbps
Max. Accel. Conn.

1,000 10,000 15,000 25,000
Max. Repeater Plug-Ins

50 250 400 500
Figure 6-8 Other configurations (not for production networks).

Type
VPX Express Min. evaluation config.
vCPUs
2 2
RAM
1 GB 1 GB
Disk
60 GB 60 GB
Max. WAN Speed

512 kbps 2 mbps
Max. Accel. Conn.

10 1,000
Max. Repeater Plug-Ins

5 50
6.3.1.1 Minimum Resource Requirements

For production environments, the Branch Repeater VPX virtual machine requires a minimum of: 2 virtual CPUs. 2 GB RAM 100 GB disk (local disks will give maximum performance) 2 virtual NICs (Ethernet ports)
The server hosting Branch Repeater VPX needs RAM and disk resources greater than those required by the VPX virtual machine. (VPX does not support VMware hardware over-commit.) It is not absolutely necessary to have as many physical Ethernet ports as virtual ones, however, if one of Branch Repeater VPXs Ethernet ports is connected to another virtual machine on the same server. Possible Ethernet options include: Mapping Branch Repeater VPXs two virtual ports to two physical ports, rendering its operation equivalent to a stand-alone branch repeater.
6-6
June 26, 2011
Mapping one of Branch Repeater VPXs virtual port to a physical port, and the other to a virtual network containing one or more virtual machines on the same server, thus creating an accelerated server. Mapping each of Branch Repeater VPXs virtual ports to a virtual network, thus chaining Branch Repeater VPX between two sets of virtual machines on the same server.
6.3.1.2 Maximum Resources

The maximum amount of resources that a single Branch Repeater VPX virtual machine can use effectively are: 4 virtual CPUs 8 GB RAM 500 GB disk 4 virtual NICs
6.3.2
Resource Usage Notes
Disk and RAM As the amount of RAM and disk are increased, the additional resources are allocated primarily to the compression subsystem. More memory also allows more connections and acceleration partners to be supported. The Branch Repeater compression system makes heavy demands on the disk subsystem. Local disk storage will outperform network disk storage and reduce resource contention on both the LAN and the network disk. The relationship between disk/memory resources and link speed is indirect. Memory and disk sizes have no effect in the ability to handle high link speeds as such. Providing more memory and disk space improves compression performance by increasing the amount of compression history that can be used for pattern matching.
CPU Performance does not scale linearly with additional CPUs. Four virtual CPUs are the maximum recommended number.
Network Two virtual network interfaces are required. These will be bridged and used for both acceleration and the browser-based user interface.These interfaces must be attached to different virtual networks. Note that, for single-ended operation, the second interface can be a stub, attached only to Branch Repeater VPX. If a third virtual network interface is added, it provides an independent interface to Branch Repeater VPX, and is the equivalent to the Primary port. It can be used for the browser-based interface, but not for acceleration.
Other Virtual Machines Server resources beyond those allocated to Branch Repeater VPX are available for other virtual machines on the same server.
6-7
6.4 Virtual Ethernet Ports
Resource usage by other virtual machines will affect Branch Repeater VPX performance, and vice versa. Acceleration makes intensive use of CPU, memory, disk, and network.
6.4
Virtual Ethernet Ports
The server machine must have at least two virtual Ethernet ports, which will be bridged by the Branch Repeater VPX. Branch Repeater VPX can be used in single-ended deployments for traffic that terminates on another virtual machine on the same XenServer. Only one physical port is required in this case, but both virtual ports are used, as shown in Figure 6-9.
Figure 6-9 Ethernet (Network) port assignments, single-ended operation
Routing. Virtual network routing can be used to connect other virtual machines on the server to Branch Repeater VPX, but the simplest method of connecting such virtual machines is to attach them to the servers LAN-side Ethernet port. WAN-bound packets then will pass through the Branch Repeater VPXs bridge and be accelerated automatically, whether they originate inside or outside the server hosting VPX.
Figure 6-10 An inline deployment that accelerates external traffic and traffic from local VMs.
6.5
Upgrading a Previous Installation
The software upgrade mechanism built into Branch Repeater is also supported with Branch Repeater VPX. Alternatively, you can install a new virtual machine containing the desired release.
6-8
June 26, 2011
6.6
Initial Installation, XenServer
(This section covers installation for XenServer. VMware vSphere installation is covered in Section 6.7.) Branch Repeater VPX is a standard virtual machine in XenServer XVA format. It is downloaded from MyCitrix in the usual way. It is distributed as a ZIP archive to reduce download time.
6.6.1
Install XenServer and XenCenter
These instructions assume that you have already installed XenServer 5.5 on the server on which you will run Branch Repeater VPX, and have installed XenCenter on a Windows PC. If not, go to Citrix.com and follow the instructions to download and install the software: http://www.citrix.com/English/ps2/products/feature.asp?contentID=1686939
6.6.2
Install Licenses on the Citrix License Server
Note: Free licenses (such as Evaluation licenses, VPX Express, NFR, and IOUL licenses) can be installed locally, without the License server, allowing this step to be skipped. Local licenses are installed via the Local Licenses tab on the Configuration: Licensing page of the Branch Repeater VPX user interface, using the procedure in Section 3.6. Branch Repeater VPX uses network licenses that are served remotely by the Citrix License Server. You can use your existing license server or install a new one. The Citrix License Server runs on Windows 2003 Server and Windows 2008 Server, and requires a Web server (IIS or Apache) for the License Manager Console. Citrix License Server is a free download, available at: http://www.citrix.com/english/ss/downloads/ details.asp?downloadId=1688507&productId=186 Note: The License Manager Console is not installed by default, but you will need it. You should select it as part of the installation process. You will receive a license file from your Citrix representative. Install this on your license server in the usual way. For more information, see: http://support.citrix.com/article/CTX114695
6.6.3
Install the Branch Repeater VPX Virtual Machine
1. Download and unzip the Branch Repeater VPX distribution from the location provided to you by your Citrix representative. 2. From XenCenter, use File: Import VM.. to import the Branch Repeater VPX virtual machine. 3. Select the server on which you want to run Branch Repeater, then allocate the desired amount of disk storage on that server to the virtual machine (See
6.6 Initial Installation, XenServer
Figure 6-11 through Figure 6-13. Local disk storage will give maximum performance and reduce contention for disk and network resources.
Figure 6-11 Importing the Branch Repeater VPX virtual machine.
Figure 6-12 Select the server.
6-10
June 26, 2011
Figure 6-13 Configure storage
4. Attach virtual network interfaces interface 0 and interface 1to the two different virtual adapters (called Networks on this page). These two interfaces will be used as Branch Repeater VPXs accelerated bridge. Do not attach both virtual adapters to the same network, or forwarding loops will be created and network outages may be caused. In addition, do not attach the two physical Ethernet ports associated with Branch Repeater VPX to the same Ethernet switch. See Figure 6-14.
6-11
Figure 6-14 Configure virtual network interfaces
5. If virtual network interface interface 2 exists, it can be assigned as well, and used as a management interface (equivalent to the Primary port). 6. Uncheck the Start the VM after Import box (we will do some additional configuration that requires that the VM be halted), then press Finish to complete the initial installation. See Figure 6-15.
Figure 6-15 Complete the import
6-12
June 26, 2011
7. The newly created virtual machine will appear under the server. Select the icon for the Branch Repeater VPX virtual machine. Go to the Storage tab and select Properties. Adjust the disk allocation to the desired level. See Figure 6-16. Note: If you change the disk allocation on the Branch Repeater VPX virtual machine, the compression history will be resized and reinitialized. Its prior contents will be lost. Note: Do not attempt to change resource allocation while VPX is running. Stop VPX first. Note: Do not use the Force Shutdown or Force Reboot commands, as they may not work and can cause problems. Use the Shutdown and Reboot commands instead.
Figure 6-16 Setting the disk allocation
8. Right-click the Branch Repeater VPX icon and select Properties. Under CPU and Memory, select 1-2 VCPUs and an amount of VM corresponding to a supported configuration. Use the table in Figure 6-7 as a guide.
6-13
Figure 6-17 Setting the virtual CPU and memory allocations
9. Click on Startup Options, check the Auto-start on server boot checkbox. (The OS Boot Parameters are not used).
6-14
June 26, 2011
Figure 6-18 Setting the start-on-server-boot option
10. After the virtual machine starts, go to the virtual machine console and log into the command-line interpreter and set the IP parameters for the accelerated bridge, using the following example as a guide:
Login: admin Password: password admin> set adapter apa -ip 172.16.0.213 -netmask 255.255.255.0 -gateway 172.16.0.1 admin> restart
6-15
Figure 6-19 Setting the IP parameters for the accelerated bridge
11. After Branch Repeater VPX has restarted, log into the browser-based UI (login: admin, password: password) using the IP address you assigned to apA, for example: https://172.16.0.213 12. On the Configure Settings: IP Address page, set the DNS address and hostname and press Update. Wait for VPX to restart. 13. On the Monitoring: System Status page, enable bridging with the Enable Bridging button. This will pop up a warning dialog box to remind you that if the two accelerated bridge ports are both connected to the same virtual or physical Ethernet segment, network loops will be created which may bring down your entire network. Check the network assignments in XenCenter, and if the two network devices are connected to different Networks, press OK. Otherwise, shut down the Branch Repeater VPX virtual machine and fix the network assignments first.
6-16
June 26, 2011
Figure 6-20 Double-checking network assignments in XenCenter
14. (When using local licenses: Branch Repeater VPX Express only) License the Branch Repeater VPX by going to the Local Licenses tab on the Configuration: Licensing page and uploading the license file. 15. (When licensing via a central license server) License the Branch Repeater VPX by going to the Configuration: Licensing page and setting the following parameters (See Figure 6-19): License Server Location: Remote. Remote License Server Address: Enter the IP address of your license server. Remote License Server Port: The default will work unless you chose a non-standard port for your license server Model: match the selection to the BW limit in your license, that is Citrix Branch Repeater V10 refers to a 10 mbps license. Press the Apply button and wait for the clock icon to count down to zero. Verify your license parameters on the License Information tab. (See Figure 6-22.)
6-17
6.7 Initial Installation, VMware vSphere
16. Complete the configuration as you would with any Branch Repeater installation.
Figure 6-21 License parameters on the Branch Repeater VPX
Figure 6-22 License information
6.7
Initial Installation, VMware vSphere
(This section covers installation for VMware vSphere. For XenServer installation, see Section 6.6.) Note: These instructions assume that you have a basic familiarity with VMware vSphere. Most of this procedure uses the vSphere Client, and details of its operation may vary with new releases of the vSphere software. The VMware documentation should be considered definitive in this regard; the procedure below shows the desired results and one example of achieving them. These instructions assume that you have a basic familiarity with VMware vSphere. Most of this procedure uses the vSphere Client, and details of its operation may vary with new releases of the vSphere software. The VMware documentation should be considered definitive in this regard; the procedure below shows the desired results and one example of achieving them. The Branch Repeater VPX base image is a VMware virtual machine in OVA format, which is typically downloaded from MyCitrix. It is distributed as a ZIP archive to reduce download time.
6-18
June 26, 2011
1.
Install VMware ESX 4.1 or ESXi 4.1on the selected server and the vSphere Client on a system from which you can manage the server. These can be downloaded from http://downloads.VMware.com. In VMware vSphere Client, log onto your VMware server to configure networking. Branch Repeater VPX requires non-default networking options. Among other things, you will create two new virtual switches (vswitch1 and vswitch2) for the accelerated bridge, which must be assigned to two different virtual switches: a. On virtual switch vswitch0, enable Promiscuous Mode (Configuration: Networking: Virtual Switch vswitch0: Properties: VM Network: Edit: Security: Promiscuous Mode: Accept). See Figure 6-23 through Figure 6-27.
2.
Figure 6-23 Configuring vSwitch0.
Figure 6-24 Configuring vSwitch0, continued.
6-19
Figure 6-26 Configuring vSwitch0: setting promiscuous mode.
6-20
June 26, 2011
b.
Create virtual switch vswitch1. (Configuration: Networking: Add Networking: Virtual Machine: Next: Create a virtual switch). Select one of the vmnic ports offered under create a virtual switch. This should be the port attached to the LAN side of your network. Do not select Use vSwitch0, because this will cause routing loops. Press Next. See Figure 6-28 through Figure 6-31.
Figure 6-28 Configuring vSwitch1
6-21
Figure 6-29 Creating vSwitch1, continued.
6-22
June 26, 2011
c.
Label the new virtual switch apA-1 (a standard Branch Repeater port name). Press Next and Finish. See Figure 6-33.
Figure 6-32 Naming vSwitch1
6-23
d.
Enable promiscuous mode on vSwitch1, as in Step 2a. See Figure 6-33
Figure 6-33 Enabling promiscuous mode on vSwitch1
e.
Create a third virtual switch, vSwitch2, as in Steps 2b-2c above, but attaching it to the port on the WAN side of your network and naming it apA-2. See Figure 6-34 through Figure 6-38.
Figure 6-34 Creating vSwitch2
6-24
June 26, 2011
Figure 6-35 Selecting the vSwitch2 connection type
Figure 6-36 Selecting the vSwitch2 port
6-25
Figure 6-37 Naming vSwitch2
Figure 6-38 Creating vSwitch2, continued
f.
Enable promiscuous mode on vSwitch2, as you did on the other ports (see Step 2a).
6-26
June 26, 2011
3.
Install the virtual machine. a. Go to File: Deploy OVF Template: Deploy from file: Browse and select the Branch Repeater VPX OVA file. Press Next. See Figure 6-39 through Figure 6-41.
Figure 6-39 Installing the Branch Repeater VPX virtual machine
Figure 6-40 Installing the Branch Repeater VPX virtual machine, continued.
6-27
b.
Change the name of the virtual machine if desired. Press Next. See Figure 6-42.
6-28
June 26, 2011
c.
Attach the ports on the virtual machine to the ports you have previously defined: LAN-apA1 to apA-1, and WAN-apA2 to apA-2. Press Next. See Figure 6-43.
Note: Always assign the two Branch Repeater bridge ports (accelerated pair ports) to different virtual and physical Ethernet segments. If you assign both Branch Repeater bridge (accelerated pair) ports to the same virtual or physical Ethernet port or switch, you will cause network loops. These network loops can make managing Branch Repeater impossible and can bring down the entire Ethernet segment. For example, you will cause network loops if you assign both Branch Repeater ports to vmnic0. This will also happen if you assign the Branch Repeater ports to different physical Ethernet interfaces, but plug both Ethernet interfaces into the same physical switch.
Figure 6-43 Mapping network interfaces to Branch Repeater VPX
d. e. 4.
Verify that the mapping looks correct and press Finish. Wait for the import process to finish. There will be a Deployment Completed Successfully dialog box.
(Optional) Add a Primary Ethernet port. a. Go to Branch Repeater VPX: Edit Settings: Add: Ethernet Adapter: Next. Select VMXNET 3 as the adapter type. Select VM Network as the network label. Click Finish and OK. See Figure 6-44 through Figure 6-47.
6-29
Figure 6-44 Installing the Primary Interface
Figure 6-45 Installing the Primary interface, continued.
6-30
June 26, 2011
6-31
5.
If desired, change the memory and hard disk parameters assigned to the Branch Repeater VPX virtual machine to match one of the supported, non-default configurations listed in Figure 6-7.These parameters are adjusted on the screen. See Figure 6-48.
Figure 6-48 Adjusting memory and disk allocation.
6.
Start and configure VPX. a. Go to the Branch Repeater VPX console. Press the start button. See Figure 6-49.
Figure 6-49 Starting the Branch Repeater VPX virtual machine
b.
When prompted for a login (in the console window), log in with login admin and password password.
June 26, 2011
6-32
c.
Set the accelerated bridge (apA) IP parameters using the following command (your IP/netmask values will vary): set adapter apa -ip 172.16.0.213 -gateway 172.16.0.1 -netmask 255.255.255.0 If the Primary port is used, set its IP parameters with the command (your IP/netmask parameters will vary). This IP must be different from the one assigned to apA: set adapter primary -ip 172.16.1.222 -gateway 172.16.1.1 -netmask 255.255.255.0
d.
Note: In systems with a Primary port, do not specify -gateway on both the Primary and apA ports. Choose one or the other. e. restart the virtual machine to allow the parameters to take effect with the command: restart
7.
Continue configuration from the Web UI using the URL of either apA or Primary IP. For example (your address will vary): https://172.16.0.213
6-33
Log in with username admin and password password

Figure 6-50 Using the Web UI.
8.
Enable bridging from the Monitoring: System Status page, using the Enable Bridging button. This will pop up a warning dialog box to remind you that if the two accelerated bridge ports are both connected to the same virtual or physical Ethernet switch, network loops will be created which may bring down your entire network. Check your network assignments and cabling, and if the two network devices are connected to different switches, press OK. Otherwise, shut down the Branch Repeater VPX virtual machine and fix the network assignments first.
17. (When using local licenses: Branch Repeater VPX Express only) License the Branch Repeater VPX by going to the Local Licenses tab on the Configuration: Licensing page and uploading the license file. 18. (When licensing via a central license server) License the Branch Repeater VPX by going to the Configuration: Licensing page and setting the following parameters (See Figure 6-19): License Server Location: Remote. Remote License Server Address: Enter the IP address of your license server.
6-34
June 26, 2011
9.
Remote License Server Port: The default will work unless you chose a non-standard port for your license server Model: match the selection to the BW limit in your license, that is Citrix Branch Repeater V10 refers to a 10 mbps license. Press the Apply button and wait for the clock icon to count down to zero. Verify your license parameters on the License Information tab. (See Figure 6-22.) Complete the installation based on the instructions in the Chapter 3, steps 31 and up.
6-35
6.7.1
Configuring Advanced VMware Features
Note: These instructions assume that you have a basic familiarity with VMware vSphere. Most of this procedure uses the vSphere Client, and details of its operation may vary with new releases of the vSphere software. The VMware documentation should be considered definitive in this regard; the procedure below shows the desired results and one example of achieving them.
6.7.1.1 VLAN Support

Branch Repeater VPX accelerates VLAN traffic automatically, without special configuration, and is thus compatible with VLAN trunking. To use VLAN trunking in a VPX deployment, the VMware server needs to have VLAN trunking enabled on the two apA bridge ports (apA.1 and apA.2), whose VLAN IDs need to be set to All(4095). This can be done in the vSphere Client. Highlights of this process are shown below.
Figure 6-51 Enabling VLAN trunking.
6-36
June 26, 2011
Figure 6-52 Enabling VLAN trunking, continued.
Figure 6-53 Enabling VLAN trunking, continued.
6-37
Figure 6-54 Enabling VLAN trunking, continued. Both apA bridge ports need to support
trunking with the All(4095) option.
6.7.1.2 Larger Disks

To support the 500 GB Branch Repeater VPX configuration, the datastore must be configured to support a maximum file size of 512 GB or more. This requires that the datastore have a block size of 2 MB or greater. In VMware ESXi 4.1, this is done by: 1. Deleting any existing virtual machines on the server using vSphere Client. 2. Delete the existing datastore (see Figure 6-55). 3. Creating a new datastore with a block size of 2 MB or greater (see Figure 6-56 and Figure 6-57. 4. Creating a 500 GB virtual disk (see Figure 6-58).
Figure 6-55 Deleting the default datastore
6-38
June 26, 2011
Figure 6-56 Adding a new datastore.
Figure 6-57 Setting the datastore block size.
Figure 6-58 Creating a 500 GB virtual disk.
In ESX 4.1, the procedure is done manually, as follows: 1. Boot the ESX 4.1 installation DVD.
6-39
2. 3. 4. 5. 6.
Select the ESX installation as Install ESX in graphical mode After getting the ESX Installer welcome screen, Press Ctrl+Alt+F2 to switch to the shell. Run the command: ps | grep Xorg Kill the Xorg process. For example, if the PID of Xorg is 582, run: kill 582 After killing the Xorg process you will get the message Press <return> to reboot, Instead, press Ctrl+Alt+F3 to go to another console and continue working without rebooting. Run the command: cd /usr/lib/vmware/weasel Edit fsset.py with the command (these instructions assume you are familiar with vi): vi fsset.py Search for class vmfs3FileSystem(FileSystemType): Change the blockSizeMB parameter to 2 (default should be shown as 1) Save the file and exit vi. Go to the root directors and run weasel: cd / /bin/weasel
7. 8.
9. 10. 11. 12.
13. 14.
Proceed with the normal installation process Now you should be able to create virtual disk size of 500GB, as shown in Figure 6-58.
6.7.1.3 VMware Guest Customization

VMware guest customization is supported for some Branch Repeater parameters, but not all. Supported parameters: Hostname Primary adapter network settings Primary DNS configuration Accelerated bridge (apA) networks settings Domain name, Area, Location, Secondary DNS, Tertiary DNS, and DNS search path Branch Repeater-specific parameters such as bandwidth limits.
Not supported
6-40
June 26, 2011
6.7.2
1.
VMware Guest Customization Procedure

Start with a Branch Repeater VPX virtual machine that has been configured to include the Primary port as well as apA. Verify that the Ethernet port configuration matches that in Figure 6-59.
Figure 6-59 Verify Ethernet port assignments.
2.
Convert the VPX virtual machine into a template, as shown in Figure 6-60
Figure 6-60 Convert to template
6-41
3.
Deploy a new virtual machine from the template, as shown in Figure 6-62.
Figure 6-61
4.
On the Deploy Template screens, name the new VPX virtual machine, select Thick Format for virtual disks, and select Customize using the Customization Wizard.
6-42
June 26, 2011
5.
In the Customization Wizard, enter a hostname and a dummy domain name for the new VPX virtual machine, as shown in Figure 6-62.
Figure 6-62 Customization wizard.
6. 7.
The value on the Time Zone screen is ignored by Branch Repeater. Accept the default and go on to the next screen. On the Network screen, select Custom Settings if you need to change the Primary port IP address from the one in the template. You will assign this address (plus a subnet mask and default gateway) to NIC3. Do not change NIC1 or NIC2.
6-43
6.8 Additional Configuration
8.
On the DNS and Domain Settings screen, enter the DNS address used by Branch Repeater VPX in the Primary DNS field. Leave the Secondary DNS and Tertiary DNS paths blank. Add a dummy domain such as test.com to the DNS Search Path. See Figure 6-63.
Figure 6-63
9. 10. 11.
Click Next and Finish to exit the Guest Customization Wizard. In the Deploy Template Wizard, uncheck the Power on the virtual machine after creation box. Double-check network assignments before powering up the virtual machine. Attaching both apA ports to the same virtual or real switch will cause network loops. Start the virtual machine and continue configuration from Step 6 in Section 6.7.
12.
6.8
Additional Configuration
For additional configuration instructions, see the other chapters in this users guide.
6-44
June 26, 2011
Chapter7
CablingandPhysicalDeployment
7.1 Power On/Off
The power switch on the unit is disabled (and on most units it is inaccessible). To power the unit on, plug in the power cord. To turn it off, remove the power cord. No special start-up/shutdown procedure is required.
7.2
Ethernet Issues
The Appliance uses standard (copper) Gigabit Ethernet (GigE, also called 1000BaseT), which is also backward-compatible with Fast Ethernet (100 Mbps) and standard Ethernet (10 Mbps). There is also an optional two-port Gigabit Fiber Ethernet card
7.2.1
Gigabit Ethernet Networks
Gigabit Ethernet is recommended for all installations, because it offers higher performance and is easier to work with than Fast Ethernet. Gigabit Ethernet is indifferent to whether cables are straight-through or cross-over. For convenience, we recommend that installations be wired as if they used Fast Ethernet anyway, so that legacy Fast Ethernet equipment will be accommodated as a matter of course. Only cables marked Category 5e or Category 6 should be used with Gigabit Ethernet.
7.2.2
Fast Ethernet (100 Mbps) Networks
When the Appliance is connected to a Fast Ethernet (100 Mbps, 100BaseT) device, the cabling rules for Fast Ethernet apply. Fast Ethernet cabling issues and auto-negotiation failures are the leading causes of installation problems. In addition, Compression will deliver higher performance if your LAN is running at gigabit speeds. Thus, its a good practice to upgrade to Gigabit Ethernet when installing an Appliance.
7.2.2.1 Connector Polarity and Cross-Over Cables

Fast Ethernet has two connector polarities: computer and switch, comparable to DCE and DTE in RS-232. When connecting a computer to a switch, a straight-through cable is used. When connecting a computer to a computer or a switch to a switch, a cross-over cable is used (analogous to a null modem cable in RS-232). Routers generally, but not always, use the same connector polarity as computers.
7-1
7.2 Ethernet Issues
Both Ethernet ports on the Appliance are wired as computer ports. Therefore: When an Appliance port is plugged into a switch, use a straight-through cable. When an Appliance port is plugged into a computer or router, use a cross-over cable.
The uplink port on a switch can be thought of as having a built-in cross-over cable.
7.2.2.2 Fast Ethernet Auto-Negotiation Failures

The Fast Ethernet specification has a flaw that leads to auto-negotiation failures when one end of a connection is set to Auto and the other is forced to 100 Mbps full-duplex. The Auto connection will generally set itself to 100 Mbps half-duplex. This mismatched connection will function at low network loads but will behave erratically at high loads. This problem is built into the Fast Ethernet standard and is not a Appliance bug. To avoid this problem, both ends of a link should be set the same way: either both Auto or both forced to the same mode. Citrix Appliances default to Auto. This can be changed over the management interface in the Configuration: Network Adapters page. (See Section 8.4.6.) In a fail-to-wire installation, the issue extends to both Appliance ports plus the ports they connect to. All four ports should be set to Auto, or all four should be forced to the same mode. The auto-negotiation problem may occur anywhere along the path between LAN and WAN, not necessarily on the connection to the Appliance itself. It is not unusual to discover long-standing cases of this problem in installations where past performance
7-2
June 26, 2011
Chapter 7. Cabling and Physical Deployment
expectations have been low. It should be suspected when the Alerts page reports high packet losses. (See Section 8.4.7.5.) If the mismatch occurs on a link directly connected to the Appliance, the Alerts section will report a half-duplex connection.
Figure 7-1 Basic cabling, inline mode
Switch or Other Device (see below) Router or Other Device (see below) WAN or Internet
LAN
Use Existing Cabling
See Below Appliance
See Below
Use Existing Cabling
Detail: LAN-Side Cabling

Straight-Through Blue Switch
Detail: WAN-Side Cabling

Cross-Over Orange WAN Router
Cross-Over Straight-Through Orange Internal Router Blue Switch Cross-Over Orange Server, Client Straight-Through Blue DSL or Cable Modem
Figure 7-2 Basic cabling, inline high-availability pairs
7.2.2.3 Older Fast Ethernet Equipment

Older Fast Ethernet products did not support full-duplex operation at all. Older equipment is often less reliable at auto-negotiation as well.
7.2.3
10BaseT (10 Mbps) Ethernet
The Appliance is compatible with 10 Mbps (10BaseT) Ethernet, but such equipment is generally half-duplex only. The maximum performance that can be supported on such a network is quite low. 10BaseT Ethernet should be avoided or replaced when possible. Cabling is the same as with Fast Ethernet.
7.2.4
Ethernet Bypass
Many models include a factory-installed Ethernet Bypass card, which contains a relay that connects the two bridge ports together if the Appliance stops running or if the power fails. This allows a network operating in inline mode to continue functioning even if the Appliance fails.
7.3 VLAN Support
The optional Fiber Ethernet card also supports bypassing. The bypass feature is wired as if there were a cross-over cable between the two ports, which is the correct behavior in properly wired installations. Bypass Installations Must Be Tested. Improper cabling may work in normal operation but not in bypass mode. The Ethernet ports are tolerant of improper cabling and will often silently adjust to it. Bypass mode is hard-wired and has no such adaptability. The bottom line is that inline installations should be tested with the Appliance turned off to verify that the cabling is correct for bypass mode.
7.3
VLAN Support
Branch Repeater supports VLAN trunking. This means that any combination of VLAN tags can be present on accelerated traffic, and it will be handled and accelerated correctly. This works in all forwarding modes (inline, WCCP, virtual inline, and group mode). For example, if one connection passing through the bridge is addressed to 10.0.0.1, VLAN 100, and another connection is addressed to 10.0.0.1, VLAN 111, Branch Repeater knows that these are two distinct destinations.
7.4
7.4.1
What Happens if the Appliance Fails

Inline Mode
Appliances maintain network continuity if a unit fails, whether through hardware, software, or power failure. If present, the bypass relay in the Appliance closes if power is lost or the unit fails in some other way. Inline units without a bypass card will usually block traffic in the event of a serious failure, but will continue to forward traffic under some conditions: namely when the network stack is running but the acceleration software has been disabled or has shut itself down due to persistent errors. Existing accelerated connections will usually hang after a failure, and will eventually be terminated by the application or the network stack by one endpoint system or the other. Some accelerated connections may continue as non-accelerated connections after the failure. New connections will run in unaccelerated mode. When the Appliance comes back online, existing connections will continue as non-accelerated connections. New connections will be accelerated in the usual way.
7.4.2
WCCP Mode
The WCCP protocol has integral health-checking, and the router will bypass the Appliance if it stops responding, and will reattach to it when it begins responding again. In practice, this gives the same effect as the bypass relay on an inline unit.
7.4.3
Virtual Inline Mode
If the verify-availability option is used with virtual inline mode, the router behaves like it does with WCCP mode, bypassing the unit when it is not available and reattaching when it is. If verify-availability is not used, all packets forwarded to the Appliance will be dropped if the Appliance isnt available.
7-4 June 26, 2011
7.4.4
Group Mode
Group mode has selectable failure behaviors, described in Section 4.15.3.2. The failed unit will fail open (bridging disabled) or closed (bridging or bypass relay enabled).
7.4.5 7.4.6
High-Availability Mode Redirector Mode
See Section 7.5 below. Individual HA units always fail open (bridging disabled).
The Repeater Plug-in performs health-checking on redirector-mode Appliances and bypasses unresponsive Appliances, sending traffic directly to endpoint servers instead.
7.5
High-Availability Mode
Two identical Appliances on the same subnet can be combined as a high-availability pair. The units each monitor the others status using the standard VRRP (Virtual Router Redundancy Protocol) heartbeat mechanism. If the primary unit fails, the secondary unit takes over. Failover takes approximately five seconds. High availability mode is a standard feature. The two units are installed onto the same subnet in either a parallel arrangement or a one-armed arrangement. Inline deployment is shown in Figure 7-3. Random switch arrangements are not supported. Each of the switches must be either a single, monolithic switch, a single logical switch, or part of the same chassis. Do not break the topology shown in Figure 7-3 with additional switches. The spanning-tree protocol is not supported, and must be turned off on router ports connected to the Appliances.
Figure 7-3 High-availability pairs can be deployed with inline (top), WCCP, or virtual inline
(bottom) topologies.
Switch Switch
TO LAN
Blue StraightThrough Cables HA Pair Blue StraightThrough Cables
TO WAN
Router
Switch
TO LAN
Blue StraightThrough Cables HA Pair
TO WAN
7-5
7.5 High-Availability Mode
7.5.1

Requirements
To use HA, the two Appliances must meet the following criteria: They must use identical hardware, as given on the System Hardware entry on the Monitoring: System Status page. They must both run the exact same software release. They must both be equipped with appropriate fail-to-wire (FTW) cards. To determine what is installed in your units, see the Monitoring: System Status page.
Units that do not support HA or which do not have an appropriate license will show a warning on the Configure Settings: High Availability page.
7.5.2
How High Availability Works
Status monitoring. Once High Availability is enabled, the primary unit sends a heartbeat signal once per second. This heartbeat signal is compatible with the VRRP (Virtual Router Redundancy Protocol) standard. In addition, the primary monitors the carrier status of its two Ethernet ports. The loss of carrier on a previously active port implies a loss of connectivity. Fail-over. If the heartbeat signal of the primary unit should fail, or if the primary unit loses carrier for five seconds on any previously active Ethernet port, the secondary unit will take over, becoming the primary. When the failed unit restarts, it becomes the secondary. The new primary announces itself on the network with an ARP broadcast. MAC spoofing is not used. Ethernet bridging is disabled on the secondary unit, leaving the primary unit as the only path for inline traffic. Fail-to-wire is inhibited on both units to prevent loops. WARNING: The Ethernet bypass function is disabled in HA mode. If both units in an inline HA pair lose power, connectivity will be lost. If there is a backup power source, at least one Appliance should be attached to it if WAN connectivity is desired during power outages. Primary/secondary assignment. If both units are restarted, the first one to fully initialize itself will become the primary. That is, the units have no assigned roles, and the first one to become available takes over as the primary. The IP address is used as a tie-breaker if both become available at the same time. Connection termination during fail-over. TCP connections are terminated as a side effect of fail-over. This includes both accelerated and non-accelerated sessions. Non-TCP sessions are not affected, other than the delay caused by the brief period (several seconds) between the failure of the primary unit and the fail-over to the secondary unit. To the users, the symptoms of failover will be the closing of open connections, but their attempts to start new connections will succeed. Configuration synchronization. The two units synchronize their settings to ensure that the secondary is ready to take over for the primary. If the configuration of the pair is changed through the browser-based interface, the primary unit updates the secondary unit immediately. Both units must be running the same software release, or HA cannot be enabled.
7-6
June 26, 2011
HA in WCCP mode. When WCCP is used with an HA pair, the primary Appliance establishes communication with the router. The Appliance uses its management IP address on apA or apB for this, not its virtual IP address. On failover, the new primary Appliance will establish WCCP communication with the router.
7.5.3
HA Virtual Address
You must assign a new IP address for the high-availability pair. This HA Virtual Address is used to manage the two as if they were a single unit. Once high-availability mode is enabled, managing the secondary unit through its IP address is mostly disabled, with most parameters greyed out. A warning message is displayed on every page giving the reason. The secondary unit can have its HA state disabled from its management UI, however.
7.5.4
Enabling/Disabling High-Availability Mode
Follow the procedure in Section 3.3.7. Note: pressing the Update button will terminate all open TCP connections
7.5.5
Updating Software for a High-Availability Pair
Updating an HA pair will cause a failover at one point, and all open accelerated connections will be reset. 1. Log into both Appliances. 2. On the secondary Appliance, update the software and reboot. When the Appliance reboots, it will still be the secondary. Verify that the installation succeeded. The primary unit should show that the secondary unit exists but that automatic parameter synchronization is not working due to a version mismatch. 3. On the primary Appliance, update the software, and reboot. This will cause a failover and the secondary unit will become the primary. 4. When the reboot is completed, HA should become fully established, since both units are running the same software.
7.5.6
Saving/Restoring Parameters in the HA Pair
The System Maintenance: Backup/Restore function can be used to save and restore parameters of HA pairs as follows: To back up the parameters, simply use the Backup feature as usual, logging into the GUI on the VIP address (as is normal when managing the HA pair). To restore the parameters: 1. Disable HA on both Appliances. 2. Restore the parameters on one Appliance (this will require a restart, which will re-enable HA). 3. Wait for this Appliance to restart. It will become the Primary. 4. Log into the GUI on the second Appliance and re-enable HA. The Appliance will get its parameters from the Primary. 5. Both Appliances are now restored and synchronized.
7.5 High-Availability Mode
7-8
June 26, 2011
Chapter8
ConfigurationReference
This chapter describes the browser-based user interface of the Citrix Repeater and Branch Repeater Appliances. Different Citrix acceleration products have different user interfaces: Repeater Appliances and Branch Repeater Appliances use the same browser-based interface, documented in this chapter. Branch Repeater with Windows Server has its own MMC (Microsoft Management Console) user interface, described in the Branch Repeater With Windows Server Installation and Users Guide. The Repeater Plug-in has its own simplified user interface, which is covered in Section 5.6.
8.1
Logging Into the UI
The browser-based interface has it root URL at the Appliances management address. For example, if your management address is 10.2.0.2, the URL is:
http://10.2.0.2
The initial page is the Dashboard page (see Section 8.2.1). You will be prompted for a user name and a password. The Admin account is always present. You can add additional accounts, as described in Section 8.4.1.3. Link bar. The left edge of this page (and every other page) contains links to the other pages. The link bar is divided into five categories: 1. an unlabeled top-level category (Section 8.2). 2. Monitoring (Section 8.3). 3. Configuration (Section 8.4). 4. Reports (Section 8.5). 5. System Maintenance (Section 8.6). These categories can be expanded to show the links to individual pages, or collapsed. An Alert(s) link also appears on the top row if warnings or errors have been detected by the system. This link takes you to the Alerts page (see Section ).
8-1
8.2 Command Menu Pages
8.2
8.2.1
Command Menu Pages

Dashboard
Figure 8-1 Dashboard page
The dashboard shows you the status of the entire appliance at a glance. It has graphs for incoming and outgoing traffic, top applications by WAN volume, top service classes by compression ratio, WAN throughput by traffic-shaping policy, and more. By default, the page updates every minute, but this can be changed by pressing the Customize button. Most features of the dashboard are disabled until you define your appliances links.
8.2.1.1 Aggregate Link Throughput Graph

This graph shows the incoming traffic (WAN to LAN) and outgoing traffic LAN to WAN). The LAN-side and WAN-side traffic are shown in different colors. When on compression, caching, or application acceleration is going on, the LAN-side traffic and the WAN-side traffic are essentially identical, because the appliance is not modifying the data as it passes through. Compression and caching reduce the amount of WAN-side traffic.
8-2 June 26, 2011
Chapter 8. Configuration Reference
8.2.1.2 Appliance Status Table

This table gives a grab bag of information about the appliance. We recommend that you minimize this table in normal use, because the graphs are generally more useful. The statistics in this table are self-explanatory.
8.2.1.3 Top Applications by WAN Volume Graph

This graph shows the top ten applications, ranked by WAN data volume, measured over the last hour.
8.2.1.4 Top Service Classes by Compression Ratio Graph

This graph shows the top compressed service classes, ranked by compression ratio. Note that service classes are not identical to applications. (There are hundreds of applications and only about 20 service classes by default.) The compression ratio is dependent on the amount of long-term redundancy in the data streams, and tends to increase over time as the appliances compression history fills.
8.2.1.5 Top ICA/CGP Applications by WAN Volume Graph

This graph is similar to the Top Applications graph but considers only Citrix XenApp/ XenDesktop published application data over the last hour.
8.2.1.6 Traffic Shaping: WAN Throughput Graph

This graph shows the predominant traffic-shaping policies being applied to the WAN traffic in the last hour. There are separate graphs for incoming (WAN to LAN) and outgoing (LAN to WAN) traffic.
8-3
8.2.2
Features
Figure 8-2 Part of the Features page
This page has enable/disable toggles for the appliances features, plus a master enable/disable toggle called Traffic Processing. In normal use, this page is helpful mostly for disabling features, since many features require more configuration than simply toggling their state from disabled to enabled. Most features should be enabled on the relevant page under the Configuration menu.
8.2.2.1 Traffic Processing

This is the master enable/disable toggle. When disabled, all features of the Appliance are disabled and all traffic passes through without modification or traffic shaping.
8.2.2.2 Traffic Acceleration

This toggle enables and disables the acceleration engine.
8.2.2.3 Traffic Shaping

This toggle enables and disables the traffic-shaping engine.
8.2.2.4 CIFS Protocol Optimization

Sets the CIFS/SMB/Windows Filesystem acceleration mode. Options are Enabled for all CIFS, allowing full acceleration, Enabled for SMB1 Only, which accelerates the SMB1 protocol (used through Windows XP and Windows Server 2003), Enabled for SMB2 Only, which accelerates the newer SMB2 protocol (Vista/Windows 7/Windows Server 2008), or Disabled.
8.2.2.5 Group Mode

Can be used to disable group mode, if enabled. See Section 8.2.2.5 for group-mode configuration.
8-4 June 26, 2011
8.2.2.6 High Availability

Can be used to disable high-availability mode, if enabled. See Section 8.2.2.6 for high-availability configuration.
8.2.2.7 ICA Multi-Stream

Enables ICA multi-stream acceleration support. If enabled, multi-stream ICA sessions will be negotiated when both the client and server are multi-stream-enabled. Otherwise, single-stream ICA sessions will be used. If multi-stream, multi-port ICA is enabled on your XenApp servers, you must also modify the ICA service class to include the additional ports you have defined for multi-port mode.
8.2.2.8 MAPI Cross-Protocol Optimization

Allows MAPI session data to match non-MAPI session data in the compressor.
8.2.2.9 SCPS
SCPS is a TCP variant used in satellite communication and similar applications. The Appliance can accelerate SCPS connections if this option is selected. The main practical difference between SCPS and the default Appliance behavior is that SCPS-style selective negative acknowledgements (SNACKs) are used instead of standard selective acknowledgements (SACKs). These two methods of enhancing data retransmissions are mutually exclusive, so if the Appliance on one end of the connection has SCPS enabled and one does not, retransmission performance will suffer. This condition will cause an SCPS Mode Mismatch alert. We recommend that, if you must mix SCPS-enabled Appliances with non-SCPSenabled Appliances, that you deploy them in such a way that mismatches do not occur. This can be done with IP-based service class rules or by always deploying the Appliances so that accelerated paths contain matched pairs rather than odd numbers of units.
8.2.2.10 Secure Partner

Duplicates the functionality of the Partner State toggle on the Configuration: Secure Partners page. See Section 8.4.9.
8.2.2.11 SNMP
Duplicates the functionality of the SNMP Status button on the Logging/Monitoring: SNMP tab. See Section 8.4.7.7.
8.2.2.12 SSH Access

Duplicates the functionality of the SSH Access Enable/Disable button on the Configuration: Administrator Interface: SSH Access page. See Section 8.4.1.5.
8.2.2.13 SSL Optimization

Duplicates the functionality of the SSL Optimization Enable/Disable button on the SSL Encryption page. See Section 8.4.12.
8-5
8.2.2.14 Syslog Support

Duplicates the functionality of the Send to Syslog Server checkbox on the Configuration: Logging/Monitoring: Syslog Server tab. See Section 8.4.7.6.
8.2.2.15 User Data Store Encryption

Duplicates the functionality of the Enable Encryption button on the Configuration: SSL Encryption page. See Section 8.4.12.
8.2.2.16 WCCP
Duplicates the functionality of the Enable button on the Configuration: Advanced Deployments: WCCP tab. See Section 8.4.2.1.
8.2.3
Quick Installation
Figure 8-3 Quick Installation page
The Quick Installation page allows a complete single-page installation of many appliances, and a partial installation for most other appliances.
8-6
June 26, 2011
Additional configuration will be required if any of the following are true: The appliance is not using inline mode. Your appliance has dual accelerated bridges (apA and apB). The appliance is part of a high-availability or group-mode pair. You plan to use SSL acceleration or hardboost. You need to make changes to the default traffic-shaping policies.
The fields in the quick installation are: 1. Adapter. For most appliances, this is apA, the accelerated bridge. Dual-bridge systems will allow you to select apB instead. 2. IP Address, Gateway, Netmask. These will already be configured (from the LCD front-panel installation step), but you can change them if desired. 3. Primary/Secondary DNS IP Address. Lets you specify a primary and backup DNS server. 4. NTP Time Server. Allows you to specify an NTP time server to keep your appliances clock synchronized. Highly recommended. 5. Date/Time. If you cannot use an NTP time server, the date and time can be set manually here. 6. Local Time Zone. Specify your time zone here. 7. Citrix License Type. Gives you a choice between Local License and a network license that matches your hardware. Legacy (release 5.x) licenses are local licenses; new licenses are generally network licenses. 8. License Server Address. You must specify a license server when using network licenses. You can use either an IP address (such as 172.16.0.44) or a hostname (such as license_server.example.com). 9. Licensing Service Port. If your license server uses a port different from the default value of 27000, specify it here. 10. Receive (Download) Speed. Use 95% of your nominal WAN receive rate. 11. Send (Upload) Speed. Use 95% of your nominal WAN send rate. 12. WAN-side Adapter. This will be either apA.1 or apA.2, depending on which port the Ethernet cable to your WAN is plugged into. (Dual-bridge systems might use apB.1 or apB.2.) 13. Perform Quick Install. Press the Install button to perform the installation. 14. Wait for System to Restart. After the system restarts, continue with your configuration if necessary. Otherwise, your appliance is configured and operational.
8-7
8.3 Monitoring Pages
8.2.4
Logout
Figure 8-4 Logout dialog
Clicking the logout link will pop up a dialog box asking if you want to end your session. If you end your session.
8.3
8.3.1
Monitoring Pages
Monitoring: Citrix (ICA/CGP)
This page allows you to monitor total ICA traffic (in the sending direction only) and the list of ICA connections.
8.3.1.1 ICA Connections Tab

Figure 8-5 ICA Connections Tab.
The ICA Connections tab lists all the currently open Citrix (ICA/CGP) connections, including with the client computers name and the name of the XenApp published application or XenDesktop desktop. The ICA connection list is similar to the main Connections list (Section 8.3.3) and can be filtered or sorted in the same way.
8-8
June 26, 2011
8.3.1.2 ICA Statistics Tab

Figure 8-6 ICA Statistics Tab.
The ICA Statistics tab summarizes XenApp/XenDesktop statistics: by ICA packet priority, by protocol type, by stream type, and by ICA virtual channel.
8-9
8.3.1.3 Acceleration Graphs Tabs

Figure 8-7 Accelerated Graphs Tab.
The Acceleration Graphs tab shows the sender-side behavior of accelerated XenApp/ XenDesktop traffic. Non-accelerated traffic is not shown. Timescales for these graphs are selectable between 60 seconds and one month. The real-time effect of compression can be estimated by comparing the WAN-side throughput to the LAN-side throughput. (Compression reduces the WAN-side data volume.)
8-10
June 26, 2011
8.3.2
Monitoring: Compression
Figure 8-8 Monitoring: Compression page.
The Monitoring: Compression page gives a real-time view of the multi-level compression engine, which automatically selects the optimum compression engine for the data being compressed.This graph can span one minute, one hour, one day, one week, or one month. The compression engine dynamically selects between several algorithm. Each algorithm is called a matcher. The smallest compression engines have a relatively small compression history, and can match strings within a few thousand or tens of thousands of bytes of the current data. The big matcher can handle matches between 100 MB and several gigabytes in size, depending on the appliance model. Finally, the disk matcher can handle matches of almost arbitrary size. Each matcher is color-coded. The graph is similar to the usage graph (Section 8.3.9), except only compressed traffic is shown. The vertical axis gives the effective throughput of the compressed data, which can be many times greater than the WAN data rate. Compression and decompression are shown separately. Raw data is not compressed at all. It has a compression ratio of 1:1. The micro matcher and little matcher have compression ratios that typically fall in the range of 1:1 to 10:1. The big matcher usually gives memory-based compression ratios in excess of 10:1, and sometimes in excess of 200:1. The disk matcher can give compression ratios up to 10,000:1. First-pass data (data that does not match anything already in compression memory) gives compression ratios anywhere between 1:1 (typical for compressed binary data) and 10:1 or even more (where there is significant internal redundancy, which often occurs in source code, Microsoft Office documents, etc.) Second-pass data generally gives compression ratios in excess of 10:1 and often in excess of 100:1.
8-11
Other compression points:
If enough data has gone by, the first-pass copy will no longer be in compression history when the object is sent again, and second-pass compression ratios will not be seen. This depends on the size of the compression history and the number of partner Appliances. The total amount of disk-matcher compression history is 100 GB or more on all models of Appliance. If the Appliance is communicating with many different Acceleration Partners, this limits the amount of compression history that any one unit can have.
8.3.3
Monitoring: Connections
Figure 8-9 Monitoring: Connections page (accelerated connections).
This page consists of a list of accelerated connections and a filter specification. The list of accelerated connections identifies the IP and port numbers for the two endpoint systems, gives information about the duration and data transferred in the connection so far, and identifies the other Appliance (or Repeater Plug-in) in the connection. Clicking on the IP address of a Acceleration Partner Appliance takes you to the management interface of that Appliance.
8-12
June 26, 2011
8.3.3.1 Selecting Which Accelerated Connections to Show

In a busy system, with hundreds or thousands of connections, it can be difficult to find the information you are looking for. You have two methods of dealing with this information: Sorting. Clicking on the column headers will sort the connections by the value in that column, in ascending order. Clicking the header again will sort the columns in descending order. Filtering. The filter at the top of the page can be used to hide all connections that do not pass the stated tests. Filtering can be performed on: Source IP and port range Destination IP and port range Connection duration Bytes transferred Connection state: opening (half-open), open, closing (half-closed) closed, all. Note: Half-open and half-closed connections may be listed as accelerated connections. The accelerated vs. non-accelerated status of a connection is generally not known until the connection is fully open (that is, until the SYN-ACK packet is received by the system that sent the SYN packet). Half-open connections can be identified because they have a Acceleration Partner of None and a Bytes Transferred of 0. Half-open and half-closed connections can be filtered out of the list with the Connection State filter at the top of the page. Selecting Open will show only fully open connections.
8-13
8.3.3.2 Unaccelerated Connections Tab

You can choose to display either accelerated or unaccelerated connections. The display format similar in either case. However, the unaccelerated connections display shows an Unaccelerated Reason code in the left-most column. Placing the mouse pointer over this code will display an explanation of what the code means, and why the connection was unaccelerated.
Figure 8-10 Unaccelerated connections.
Common reasons for non-acceleration are:

Figure 8-11 Non-acceleration reasons (Sheet 1 of 2).
Code UR:1. UR:2 UR:3 UR:4 UR:5 UR:6 UR:7 UR:8 UR:9 UR:10 UR:11 UR:12 UR:13 Description Reason is unknown No partner Acceleration unit was detected Routing asymmetry: the SYN packet did not pass through this unit. Routing asymmetry: the SYN-ACK packet did not pass through this unit. No room in TCP SYN or SYN-ACK header for acceleration options. Service policy rule forbids acceleration on this connection. Not used. Not used. One unit is configured for hardboost and the other for softboost. Maximum number of accelerated connections has been reached. Connection failed both with and without acceleration options (destination not responding or responds with TCP reset). Connection failed when acceleration options were attached, but succeeded without acceleration (firewall problem). This unit is between two other units and daisy-chaining is enabled.
8-14
June 26, 2011
Figure 8-11 Non-acceleration reasons (Sheet 2 of 2).

UR:14: UR:15 UR:16 UR:17 UR:18 UR:19 UR:20 UR:21 UR:22 UR:23 UR:24 UR:25 UR:26 UR:27 Maximum number of simultaneous partner Appliances has been reached. Connection matches an invalid proxy-mode entry. Not used. Not used. Bad proxy configuration detected on the Acceleration Partner. Not used. Proxy loop detected. Too many proxy connections, cannot allocate any new connections. No initial TCP handshake seen (often seen after a Acceleration unit is enabled and there are many pre-existing non-accelerated connections). Group mode connection is accelerated by a different group member. Auto-discovery is disabled. Group mode connection, but group-mode acceleration has been disabled. Plug-in connection is using invalid Signaling/Redirector IP address. Cannot establish a signaling connection to partner.
8.3.3.3 Connection Details Page

The left-most column in the Accelerated Connection table is the Details column, containing links to per-connection information, as shown in Figure 8-10 through Figure 8-9. The connection details start with WAN and LAN traffic graphs, continues with a table giving overall status of the connection, and concludes with a longer table giving detailed information about the connection.
8-15
WAN/LAN graphs. These show only the traffic for the selected connection. Otherwise, they are the same as the usual throughput graph.
Figure 8-12 Connection Details page. Top portion: graphs.
Detailed Connection Information table. See Figure 8-13. This table reports: Creation Time: the date and time when the connection was opened. Uncompressed Bytes Transmitted: the amount of data transferred in the connection so far (in both directions, before compression) Compressed Bytes Transmitted: the amount of data transferred in the connection so far (in both directions, after compression) Effective Compression Ratio: the number of uncompressed bytes divided by the number of compressed bytes. The value in parenthesis is 1/(compression ratio). Duration: the elapsed time since the connection was opened. Idle Time: the elapsed time since the last data transfer. Status: The state of the TCP connection (Open, Closing, Closed, etc.). The code after this state is for use by Support and is not documented here. Acceleration Partner: The IP address of the partner Appliance, as reported by the Acceleration Partner itself.
8-16
June 26, 2011
Figure 8-13 Connection Details page, Detailed Connection Information table.
Detailed Per-Endpoint Information table. See Figure 8-14. This table is primarily for the use of Support and is not fully documented here. Some of the reported values are not always accurate. In particular, the RTT value uses a counter-intuitive smoothing algorithm and may give unexpected results. The table reports values for both the local and remote sides of the flow, labeled LAN Endpoint and WAN Endpoint, respectively. Some of the more interesting values include: Send Rate Setting. The bandwidth limit in the sending direction. Send Rate Setting Constrained: The bandwidth limit as constrained by the Acceleration Partner, which may have a lower bandwidth limit or may be dividing its bandwidth between multiple partners. Receive Rate Setting/Receive Rate Setting Constrained: As above, but in the receiving direction. Smoothed Round-Trip Time: Do not use this value. This uses the standard TCP RTT calculation, which behaves differently from what one would expect. Largest Receive Window: The largest advertised window used so far in the connection. This is typically much larger on the WAN side than the LAN side, since the long RTT of a WAN link requires a larger amount of in-flight data. This value tends to grow as needed. (The default maximum is 8 MB on the WAN side and 64 KB on the LAN side.) Total Wire Bytes Transmitted/Transmitted Good: The amount of data send, with headers, payload, and retransmissions all counted equally. The loss rate can be calculated from the difference between transmitted and transmitted good. Total Wire Bytes Received/Received Good: As above, but in the opposite direction. (Note: Do not calculate loss rates by subtracting data received from data sent, since that does not account for data still in flight.)
8-17
Total Payload Bytes: As above, but with headers and retransmissions removed from the calculation.
Figure 8-14 Connection Details page, Detailed Per-Endpoint Information table.
8.3.3.4 Flow Information

A flow consists of all the traffic flowing between a pair of Appliances. Clicking on the i link marked Flow will give information for the flow as a whole, as shown in Figure 8-15. The entries should be self-explanatory.
8-18
June 26, 2011
Figure 8-15 Flow information page.
8-19
8.3.4
Monitoring: Filesystem (CIFS/SMB)
8.3.4.1 Acceleration Graphs Tab

Figure 8-16 CIFS acceleration graphs
The Acceleration Graphs tab shows four graphs: 1. CIFS Accelerated Read Traffic, the total bandwidth from accelerated CIFS read requests. (Note that read vs. write is based on whether the CIFS command was a read or write command, and has nothing to do with the send/receive direction as seen by the Appliance.) 2. CIFS Accelerated Write Traffic, the total bandwidth from accelerated CIFS write requests. 3. CIFS Saved Requests, the difference in bandwidth between the accelerated throughput and the throughput that would have been achieved without acceleration. 4. CIFS (SMB2) Requests Responded Locally, the bandwidth of requests serviced locally rather than passed on to the endpoint server, such as the bandwidth savings from metadata caching.
8-20
June 26, 2011
8.3.4.2 Connections Tab

Figure 8-17 Connections tab.
Connections. Clicking the Connections tab at the top of the page will cause a table of CIFS connections to be displayed. These are divided into accelerated and non-accelerated connections. Clicking the icon in the Details column will give detailed information about this CIFS connection. File Details and Read/Write counters. When the Appliance is on the server side of the link, the File Details entry always reads Not Available and the read and write counters always read zero. Information about the connection can be obtained from the client-side Appliance. The Signed column. Reports whether CIFS signing is in effect. The Reason column. For so-called non-accelerated connections, a Reason column gives a code specifying why CIFS optimizations were not used. The reasons are one of these: 1. The connection uses the Vista SMB 2.0 format, and SMB 2.0 acceleration is not enabled. 2. CIFS optimizations are disabled on the Appliance. 3. Security settings on the connection prevent optimization. 4. The connection requires CIFS signing, which prevents optimization. 5. CIFS optimization is disabled or not supported on the remote Acceleration unit. 6. The CIFS dialect level is not supported. 7. The connection is not using the negotiated protocol.
8-21
8.3.5
Monitoring: Logging
Figure 8-18 Monitoring: Logging page.
The logging page shows system activity, including configuration changes and boot progress messages. See Figure 8-18. Status reports are logged every minute, including system status, adapter status, connection status, and flow status. Events, including the opening or closing of an accelerated connection, are also logged. Unaccelerated connections are not logged. Traffic shaping and classification are not logged. Additional detail about acceleration is available by clicking the link in the left column of the entry. For example, if you click on the System Status entry, you get a System Status report that gives a second-by-second throughput graph and a table of other status data for the same minute. Status reports for the system, flows, connections, and adapters are all similar, with performance graphs at the top and tables of related system objects and their status below. Arrows to the left and right of the graphs will give a report for one minute previously or one minute later, respectively.
8.3.6
Monitoring: Outlook (MAPI)
The Monitoring: MAPI Status page has three tabs: Acceleration Graphs, Accelerated Connections, and Unaccelerated Connections.
8.3.6.1 Acceleration Graphs

The Acceleration Graphs tab shows the accelerated MAPI traffic for the last 60 seconds. The two graphs are Read-Ahead Throughput, showing the performance of traffic traveling from the Exchange Server to the Outlook client, and Write-Behind Traffic, showing traffic from the Outlook client to the Exchange server. These graphs will look different on the two Appliances, and different from the main usage graphs as well, since they show movement into and out of the MAPI engine, not actual traffic on the WAN. The differences are caused by buffering.
8-22 June 26, 2011
Figure 8-19 Acceleration Graphs tab.
8.3.6.2 Accelerated Sessions

This tab shows the status of open accelerated MAPI sessions, including the IP addresses of the two endpoints, user name, number of connections (MAPI uses multiple connections per user), and total traffic.
Figure 8-20 Accelerated Sessions tab.
8-23
8.3.6.3 Unaccelerated Sessions

This tab shows the status of unaccelerated MAPI sessions, including the reason why the connection was not accelerated, the two endpoints, and the number of connections.
Figure 8-21 Unaccelerated Sessions tab.
8.3.7
Monitoring: Repeater Plug-ins
Figure 8-22 Monitoring Repeater Plug-in.
This page reports on the Repeater Plug-in currently connected to the Appliance. The list is similar to the Active Connection list and can be filtered and sorted in similar ways. Pressing the Details link shows client connection details similar to that in Figure 8-23.
8-24
June 26, 2011
Figure 8-23 Detailed Plug-in Information
8.3.8
Monitoring: Secure Partners
Figure 8-24 Peer Status command.
This page reports the SSL signaling connection status of peer Appliances or Repeater Plug-ins that have been detected since the last restart. By default, only currently connected peers are displayed, but this can be changed with the Connection Status pull-down in the Filter table. In the Peer table, each peer is listed by name and its IP address (not the signaling address used by its SSL tunnel, which is not reported). Its connection status, length
of connection, and time since last contact are also reported. These all refer to the secure signaling connection, which the units use to exchange security information, not data connections. Click on the Details column for more information about a given peers signaling connection Note: The true/false status in the Secure column means that a secure signaling connection has been established and that new accelerated connections will be encrypted. It does not mean that all traffic passing through the unit is encrypted, because non-accelerated traffic is never encrypted by the Appliance.
8.3.9
Monitoring: Usage Graph
Figure 8-25 Monitoring: Usage Graph page
Tabs at the top of the page allow you to select a timescale to display: the last minute, hour, day, week or month. Accelerated Line Usage (light blue): Total accelerated line usage, including headers, ACK packets, and retransmitted packets. Accelerated Goodput (dark blue): Payload data, excluding retransmissions and headers. Non-Accelerated (orange): Non-accelerated TCP traffic (including data and overhead) Non-TCP traffic is not included in the graph.) Compression is taking place during periods when the LAN traffic is higher than the WAN traffic. In the diagram above, a data stream of 250-300 mbps has been reduced by more than 500:1, to around 400 kbps.
The Monitoring: Usage Graph page shows real-time throughput graphs for the WAN and LAN sides of the Appliances acceleration engine. The graph defaults to a static display, but an auto-refresh mode can be selected by clicking the Toggle link. Clicking the left-arrow icon next to the graph shows information for one period further back in time; clicking the right arrow, if present, moves the display one period forward in time. See Figure 8-26.
8-26
June 26, 2011
The amount of time covered by the display varies from one minute to one month. The shorter timescales are useful when setting parameters such as bandwidth limits or service class rules; the longer timescales are useful for general monitoring. Restarting the Appliance will cause all the graph data to be lost. The graph shows the traffic as seen by the acceleration engine. This means that only TCP traffic is shown, and it is not segregated by link; it shows global TCP traffic through the Appliance. Dark blue indicates accelerated goodput, or payload data. Light blue indicates the overhead of accelerated connections: packet headers, acknowledgement packets (ACKs), and retransmissions. Orange indicates non-accelerated traffic. The graphs are stacked, so the topmost point on the graph shows total accelerated traffic (LAN-side graph) or total line usage (WAN-side graph).
The Graph Settings link takes you to the Configuration: Administrator Interface page, which allows you so change the graphing features, including the frequency of update and whether separate graphs are shown for the sending and receiving directions. See Section 8.4.1.6. Clicking Popup Graph will create a new window containing a similar auto-refreshing throughput graph. See Figure 8-26.
Figure 8-26 Popup performance graph
8-27
8.3.10 Monitoring: WCCP

Figure 8-27 Monitoring: WCCP page
The Monitoring: WCCP page reports on the status of the Appliances WCCP interface. For each configured WCCP service group, it reports the accelerated pair used by that service group, the routers identified for that service group, the type of partner assignment (Hash or Mask), the connection mode (GRE or L2) used by the router, last contact time, connection status, and packets in and out. The page is auto-updating and lags the actual state of the interface by only a few seconds. Most of the fields are self-explanatory except for the Status field, which is described below:
Figure 8-28 WCCP status messages (Sheet 1 of 2)
Text Unknown error Undefined interface Bad configuration Disable interface Bad subnet for interface Internal problem Service Group is disabled Acceleration is disabled WCCP is disabled Contacting router Connecting to router Description WCCP interface is not working for an unknown reason. The defined interface for the service group does not exist. The service group configuration does not make sense. The accelerated interface defined for the service group has been disabled. The accelerated interface has a network definition that contains no subnet portion (subnet works out to 0.0.0.0, usually due to the subnet field not being defined). Internal software error. The service group has been manually disabled on the WCCP Configuration page. The service group does not operate when acceleration is disabled. WCCP itself is disabled. No response has been received yet from the router. At least one packet has been received from the router, and WCCP protocol negotiations are underway.
June 26, 2011
8-28
Figure 8-28 WCCP status messages (Sheet 2 of 2)

Connected to router Disconnecting from router No response from router Routers forward or return capability mismatch Multicast discovering Multicast failed to discover Multicast shutdown Routers view has other cache Negotiation is complete and the WCCP interface is fully active. The Appliance is terminating its connection to the router, probably due to a user-initiated configuration change. The router has been completely unresponsive for at least five minutes Cannot communicate with the router because the specified mode is not available. Usually means that the Appliance is configured for WCCP-L2, but the router does not support this mode. Attempting to find multicast service group partners. No multicast group partners were found in the last five minutes. The multicast service group is no longer attempting to discover partners. There is another WCCP device, such as another Appliance, using the same service group. We do not allow this. There is a mismatch between the configured router assignment and the actual capabilities of the router. For example, if Auto is selected, and communication with the first connected router caused the Hash method to be selected, if a subsequent router does not support Hash, this status message will be given. Packet forwarding cannot take place because the appliances gateway is invalid (not on the same subnet as the appliance). Internal software error. Please report this event to Support.
Router assignment capability mismatch
Router is off-net and appliances gateway is invalid Service group had socket send error
8.4
8.4.1
Configuration Pages
Configuration: Administrator Interface
This page has a range of options relating to the browser-based and LCD front-panel interfaces It is divided into four eight tabs: Web Access, HTTPS Certificate, User Accounts, Radius, TACACS+, SSH Access, Graphing, and Miscellaneous.
8-29
8.4 Configuration Pages
8.4.1.1 Web Access Tab

Figure 8-29 Web Access Tab
Web Access Protocol. Selects between HTTP and secure HTTP (HTTPS).HTTPS is the default HTTP/HTTPS Ports. Sets the port used for each protocol. The non-selected protocol is greyed out. To access it, select the protocol, press Update, and then change the port number. Setting the port numbers to zero will disable browser-based access (re-enabling browser-based access will require the use of the serial interface or the command-line interface). HTTP Forwarding to HTTPS. If HTTPS is the selected protocol, attempts to reach the interface via HTTP will result in an redirect to the correct protocol and port.
8.4.1.2 HTTPS Certificate Tab

Figure 8-30 Configure Settings: UI page, HTTPS Certificate tab
HTTPS SSL Certificate, HTTPS SSL Private Key. These boxes allow you to paste in your own certificate and private key for SSL security, which is used by HTTPS. The Appliance is delivered with a default SSL key and certificate, which is not particularly
8-30 June 26, 2011
secure. To replace it with your own key and certificate, generate these using your organizations standard procedure, then paste them into the boxes on the UI page and press the Update button.
8.4.1.3 User Accounts Tab

Figure 8-31 User Accounts Tab
These users accounts are maintained locally by the Appliance. There are two types of accounts: Admin and Viewer. Admin accounts allow the user to view all pages and modify all settings. Viewer accounts allow the user to see only the Main page and pop-up performance graphs. You can create as many accounts as you like. The menu page is self-explanatory. Changes take effect as soon as the Update, Delete, or Add buttons are pressed.
8-31
8.4.1.4 RADIUS and TACACS+ Tabs

Figure 8-32 RADIUS Authentication Tab
Figure 8-33 TACACS+ Authentication Tab
RADIUS and TACACS+ authentication are also supported. The user interface for the two are similar. Enter the IP address of the authentication server, verify the port number (the default is usually correct), enter the shared secret and press the Update button. Notes on RADIUS authentication. Radius authentication will succeeds if the RADIUS server returns an Accept-Access packet with an appropriate Service-Type attribute. If Service-Type is Login, then the user is granted viewer access. If it is Administrative, then the user is granted admin access. Otherwise, access is denied. Note: For accounts that exist locally on the Appliance, the locally defined password continues to work after Radius or TACACS+ authentication are enabled; the remote server is queried only if the password fails to match the locally stored value.
8-32
June 26, 2011
8.4.1.5 SSH Access Tab

Figure 8-34 Security: Manage Users page
Two methods of accessing the unit are enabled by default, but can be disabled if desired. One is SSH access, which must be running for the CLI feature to work (see Chapter 9). It also allows Support access to the Appliance if necessary. The other is Web Access, access to the browser-based user interface. The two functions have Disable/Enable buttons. However, if you disable web access, you will of course not be able to access the button to re-enable it. To re-enable the browser-based user interface, use the RS-232 or CLI interface.
8.4.1.6 Graphing Tab

Figure 8-35 Graphing tab
This tab controls the graphing functions of the acceleration engine, which covers the graphs on the Monitoring pages but not those on the Reports pages or the Dashboard, which are configured separately. Display WAN Side Graph/Display LAN Side Graph. The data flow is not identical on the LAN side of the Appliance and the WAN side. The differences between the two flows can provide useful information. For example, the difference between accelerated line usage and goodput should be very low on the LAN side, because LANs usually (but not always) have a low packet-loss rate. But if there is a problem with the local LAN (a failing switch, for example, or a port accidentally configured to half-duplex), losses may be high. By default, both graphs are shown. Combine Send/Recv Graphs. By default, send and receive traffic are added together, but they can be displayed separately. This is useful on busy systems with traffic moving in both directions. Autoscale Graphs. By default, bandwidth graphs are scaled automatically, but they can be scaled to user-specified limits.
Graph Refresh Rate. The data displayed on the graphs covers 60 seconds of activity and is collected at one-second intervals. The default refresh rate is ten seconds. Sensible values for the refresh interval are between 1 and 60 seconds. Autorefresh Graph. Unchecking this box means that the reload browser button must be pressed to see an up-to-date graph.
8.4.1.7 Miscellaneous Tab

Figure 8-36 Configure Settings: UI page, Miscellaneous tab
Lock Changes via LCD. Checking this box prevents system settings from being updated via the front-panel interface. By default, the front-panel is not locked. Max Connections Shown on Connection Page. A busy system may have thousands of open connections. The default is to show the first 800. This may be set to any value desired. GUI Session Timeout. If the Web interface is idle for more than this time (in minutes), you will have to log in again. Setting the value to zero will disable session timeouts. CLI Session Timeout. If the command-line interface is idle for more than this time (in minutes), you will have to log in again. Setting the value to zero will disable session timeouts.
8-34 June 26, 2011
Login Failure Limit. If an invalid password is given more than this many times in a row, you will not be able to login until the login failure lockout period has expired. Login Failure Lockout Period. Logins are disabled by this many seconds if the login failure limit has been exceeded. Show SSL Connection Help Guide. Enables some online help text at the bottom of SSL-acceleration related pages. Disabled by default. Because this Users Guide has much more comprehensive procedures, this help guide is not recommended.
8.4.2
Configuration: Advanced Deployments
This page has the configuration for advanced deployment modes: WCCP, high-availability, group mode, and proxy mode.
8.4.2.1 WCCP Configuration Tab

Figure 8-37 WCCP Configuration tab
This page allows WCCP mode to be configured. In WCCP mode, the router sends data to the Appliance, which returns it after processing to the router. Both L2 and GRE transport are supported. See Section 4.13 for the procedure for setting up your router and Appliance for use with WCCP. A single Appliance can be shared by in WCCP mode, which is convenient for sites with asymmetrically routed links. These routers can all be in a single service class or in different service classes. A given service class supports either multicast or unicast operation, but not both. The parameters on this page are as follows: Enable/Disable. Enables or disables WCCP functionality. If an active WCCP interface is disabled, the router will notice this after a timeout period (less than 60 sec-
8-35
onds) and stop sending packets to the Appliance. Instead, it will send them directly to the next-hop router. New WCCP Service Group. Opens a dialog box on the right-hand edge of the screen. Id. This is the service group number, which is also used by the router. Must not conflict with other WCCP devices on the local network. The default value of 51 is usually adequate. Enabled. This allows individual service groups to be enabled or disabled, in addition to the master enable/disable button at the top of the page. Priority. This is the WCCP protocol priority. This should be left at the default value of 0. Router Assignment. Can be Hash, Mask, or Auto. The default is Hash, which is used by most routers. Some programmable switches support only the Mask method. Router Forwarding/Router Packet Return. Can be GRE, Level-2, or Auto. The default is Auto, which means that the Appliance uses GRE if it must and L2 (which is faster) if it can. This capability is negotiated with the router in each direction. The only reason not to use Auto is if a bug in your router prevents negotiation from succeeding. Router Communication. Multicast or Unicast. The default is Multicast, which requires that you set up a multicast address in your routers and at the Appliance. With Unicast, the Appliance must be given the routers address, but the router does not need to know the Appliances address. Although Multicast is the default, Unicast is the more flexible mode and requires less configuration, so it is recommended. Multicast Address. if Multicast is selected, this gives the multicast address used by your routers and Appliances for this purpose. Time To Live [1-15]. The TTL value for packets sent by multicast. Some routers insist that this be set to 1, meaning that the packet cannot be forwarded beyond the current subnet. This makes multicast operation more restrictive than unicast operation. Router Addressing. One or more addresses for your routers. If you specify more than one routers IP address, the Appliance will work with multiple routers within the same service group. Alternatively, you can assign different routers to different service groups. The results are functionally equivalent. Create. Dont forget to press the Create button before leaving the page.
8-36
June 26, 2011
8.4.2.2 High Availability (HA) Tab

Figure 8-38 Configure Settings: High Availability page
Note: pressing the Update button will terminate all open TCP connections. This page allows you to set up Appliances as high-availability pairs, so that if one unit fails, the other will take over. High Availability Status: One of Standalone, Primary, or Secondary. A standalone unit is not part of an HA pair. A primary unit is actively handling accelerated connections. A secondary unit is idle, ready to take over if the primary unit fails. Partner High Availability Status: Status of the HA partner, if present. SSL Common Name: Also called the serial number, it uniquely identifies this Appliance. You type this string into the Partner SSL Common Name field on your HA partner Appliance. Virtual VIP Configuration: The virtual IP address used to manage the pair as a unit is not set here, but on the Configure Settings: UI page. A link is provided here. VRRP VRID: This identifies the HA pair according to the VRRP (Virtual Router Redundancy Protocol) as defined in RFC 2338. The default value of 0 is not a valid VRRP VRID, which must be in the range of 1-255. If there are no other VRRP devices on the subnet containing the Appliance, the choice of a VRRP ID is arbitrary. Note that, while the Appliance uses a VRRP ID (which is designed primarily for routers), the Appliance is not a router. Partner SSL Common Name: Copy this from the Acceleration Partners SSL Common Name field. Enabled: Turns high-availability functionality on or off. You will be warned that enabling or disabling high availability will terminate all open connections.
8-37
8.4.2.3 HA Partner Info Tab

Figure 8-39 HA Partner Info Tab.
Lists information about the HA partner unit, if configured
8.4.2.4 HA VIP Address Tab

Figure 8-40 HA VIP Address Tab.
Repeats the VIP information from the Configure Settings: Network Adapters: IP Addresses tab.
8-38
June 26, 2011
8.4.2.5 Group Mode Tab

Figure 8-41 Group mode tab.
Group mode is a means for allowing two or more redundant links to be shared by two or more inline Appliances, with no requirement that all the packets for a given connection pass through the same Appliance. Group mode and the fields on the Group Mode page are fully explained in Section 4.15.
8-39
8.4.2.6 HA/Group Mode SSL Certificates Tab

Figure 8-42 HA/Group Mode SSL Certificates tab.
When an Appliance is a member of a high-availability pair or group-mode group, these certificates and keys are used to authenticate each other. Private keys and certificates are factory-installed, but can be replaced, if desired. Press the Edit button, and paste the new certificates and key in the boxes provided, replacing the old ones, then press Update.
8.4.2.7 Proxy Tab

Figure 8-43 Proxies page.
In proxy mode, the Appliance masquerades locally as the remote system. Traffic for the remote system is then forwarded to a remote Appliance and then to the remote system itself.
8-40
June 26, 2011
Proxying involves address translation. The addresses are entered in the Proxy Configuration page. With a proxy connection, one end of the connection may be left in inline mode. When this is done, the inlined Appliance requires no configuration. When you enter a new proxy definition, the Appliance pings the target address when you press the Add button. If the ping is unsuccessful, a warning icon is displayed and the target address is shown in red. However, the proxy entry is still active. On paths where pings are blocked but TCP traffic is not, the proxy definition will work in spite of the warning icon. See Figure 8-44.
Figure 8-44 The warning symbol means that the target does not respond to pings, but the
proxy entry is still active. If pings are being blocked, this warning means nothing.
A proxy entry requires two IP addresses: the IP address of the server and the local VIP address that you assign to the server. Figure 8-45. shows a configuration that allows users of Network B to access two servers on Network A: Alpha and Anvil. This corresponds to Case 2 in Section 4.22.0.2. This takes care of connections initiated by the inline site. But the reverse connection ftp Beta requires its own configuration, since the packets will not flow through the Appliance-A unless they are sent to it via a virtual IP address. Another virtual IP entry must be configured, this time pointing to the server on the remote network. This is shown in Figure 8-46, and corresponds to Case 3 in Section 4.22.0.2, and illustrates a general point about proxies, which is that the target system does not have to be on the same network as the Appliance. See Figure 4-54. The final example, in Figure 8-47, shows proxy configuration where neither unit is inline. This corresponds to Case 4 in Section 4.22.0.2.
8-41
Figure 8-45 Proxy configuration, allowing Network B to access Alpha and Anvil.
Network A: 10.0.0.x
Network B: 172.16.0.x
WAN
Appliance Mgmt Addr: "Appliance-B" 172.16.0.200 Appliance Mgmt Addr: "Appliance-A" 10.0.0.150 VIP Addr: "Alpha-Proxy" 10.0.0.152 VIP Addr: "Anvil-Proxy" 10.0.0.153
System "Alpha" System "Anvil" 10.0.0.51 10.0.0.60
System "Beta" 172.16.0.1
To access Anvil in accelerated mode, a user would type ftp Anvil-Proxy ftp Anvil would access Anvil in unaccelerated mode. ftp Alpha-Proxy would access Alpha.
8-42
June 26, 2011
Figure 8-46 Proxy configuration, allowing Network A to access Beta.

Network A: 10.0.0.x Network B: 172.16.0.x
Appliance Mgmt Addr: "Appliance-B" 172.16.0.200 VIP Addr: "Beta-Proxy" 172.16.0.201 Appliance Mgmt Addr: "Appliance-A" 10.0.0.150 VIP Addr: "Beta-Proxy-A" 10.0.0.154
System "Alpha" System "Anvil" 10.0.0.51 10.0.0.60
To access Beta in accelerated mode, a user on Network A would type ftp Beta-Full-Proxy-A. Appliance-A will forward packets to Beta.
8-43
Figure 8-47 Proxy configuration with neither site inline.

Network A: 10.0.0.x Network B: 172.16.0.x
Appliance Mgmt Addr: "Appliance-B" 172.16.0.200 VIP Addr: "Beta-Proxy" 172.16.0.201 VIP Addr: "Alpha-Proxy-B" 172.16.0.202 VIP Addr: "Anvil-Proxy-B" 172.16.0.203 Appliance Mgmt Addr: "Appliance-A" 10.0.0.150 VIP Addr: "Alpha-Proxy" 10.0.0.152 VIP Addr: "Anvil-Proxy" 10.0.0.153 VIP Addr: "Beta-Proxy-A" 10.0.0.154
System "Alpha" 10.0.0.51
System "Anvil" 10.0.0.60
Figure 8-48 Appliance-A configuration. The third entry is the first part of a VIP-to-VIP proxy
between Appliance-A and Appliance-B.
8-44
June 26, 2011
Figure 8-49 Appliance-B configuration. Additional VIP addresses have been defined for Alpha
and Anvil.
8.4.3
Configuration: Application Classifiers
Figure 8-50 Part of the Configuration: Application Classifiers page.
The Configuration: Application Classifiers page defines all the applications recognized by the Branch Repeater classifier. The classifier uses application definitions to divide the traffic into protocols and applications. This is used to create reports and to set traffic-shaping policies through the service-class mechanism. A great many applications are already defined, and you can define more as needed. Application Group pull-down menu. Applications are divided into groups, and by selecting one from the Application Group pull-down menu, you can restrict the display to the members of the selected group.
Only show user modified settings checkbox. This checkbox allows you to show only applications that differ from the defaults, whether by being added or modified. Auto-discover Citrix published applications checkbox. This option allows any Citrix published applications seen in the data stream to be added to the application list automatically. Once discovered, they will show up in reports and can be used for traffic-shaping policies. Expand All/Collapse All buttons. In the collapsed state, just the application names are displayed. Otherwise, their definitions are shown as well. Create button. Used to create a new application.See Figure 8-51. The procedure for creating a new application is described in Section 4.7.
Figure 8-51 Defining a new application
Edit button. Allows an existing application to be altered. This process is essentially the same as creating a new application. Delete button. Deletes an application. Note: Use caution when editing or deleting applications, since there is no way to reset the definitions to their defaults without resetting the entire Appliance to its factory defaults.
8.4.4
Configuration: Licensing
A license file must be installed before your Appliance will accelerate connections. License files are generally obtained on MyCitrix. See the release notes for more information.
8-46
June 26, 2011
8.4.4.1 License Information Tab

Figure 8-52 License Information tab.
The License Information tab gives the information needed for the creation of a license for your Appliance, or to match up a pre-generated license with the correct Appliance. If a license has been successfully installed, the Required Action field will say, None. The format of the License Information tab is different if no license has been installed. The Required Action field will report that only a legacy license is installed. A link is provided to go to the My Citrix and obtain another.
8.4.4.2 License Server Tab

Figure 8-53 License Server tab.
This tab specifies whether licenses will be obtained locally or remotely. If local licenses are used, they are installed using the Local Licenses tab. With remote licensing, the license file is installed on a Citrix License Server running on the machine of your choice. Remote licenses were introduced in release 5.6. If remote licenses are used, the Remote License Server address must be supplied, plus the Remote License Server Port (the default value will almost always be correct). Also, the type of license must be specified in the Model pull-down menu.
8-47
These licenses specify the maximum supported bandwidth. The remote license server needs to have a license available for the model selected, or no license will be acquired. If SSL acceleration, MAPI acceleration, or signed SMB acceleration are required, then a crypto license must also be installed. Checking the Crypto License Requested box will acquire a crypto license, if available.
8.4.4.3 Local Licenses Tab

Figure 8-54 License Configuration tab on the Configuration: Licensing page.
This tab is where you install the license itself. Most Appliances with local licenses will have 1-3 active licenses: for acceleration, for the Repeater Plug-in, and for SSL acceleration (the crypto license). The steps for installing a license are: 1. Add a new license by pressing the Add button. 2. Type a name into the License Name Field. This name can be anything, but it cannot be blank. 3. Upload the license you obtained from Citrix via the Add box. 4. Press the Install button. 5. After a delay, the license should install successfully.
8-48
June 26, 2011
8.4.4.4 Licensed Features Tab

Figure 8-55 Configuration: Licensing page.
This tab reports the features that have been licensed for this Appliance.
8.4.5
Configuration: Links
The Configuration: Links page is where your WAN and LAN links are defined. Defining links enables the Appliances reporting and traffic shaping.
8.4.5.1 Link Definition Tab

Figure 8-56 Link Definition tab.
This tab is the entry point for defining and modifying links. New links are defined by pressing the Create button. Existing links are modified by pressing the Edit button. Both these actions take you to a similar form that allows you to specify link-definition rules. See Figure 8-57. The order in which the links are shown on this is significant. When deciding which link a packet belongs to, the Appliance tests the links in order, and the first matching link is selected. This means that overlapping definitions are allowed, and the last definition in the link can match all traffic, serving as a default link. The Order buttons can move a link up or down the list. The Expand All button will show the expanded form of the display, summarizing the link definitions instead of displaying only the names of the link.
8.4.5.2 The Create Link and Edit Link Forms

Figure 8-57 Edit Link form.
A link definition has a set of send/receive bandwidth limits and a list of rules that define which traffic belongs to the link. Within a rule, the fields are all ANDed together, so all specified values have to match. All fields default to Any, a wildcard entry that matches all traffic. When a field consists of a list, such as a list of IP subnets, these are ORed together: that is, if any element matches, then the list as a whole is considered to be a match.
Figure 8-58 Link definition rules.
Links can be based on the Ethernet adapter associated with the traffic, the source and destination IP addresses, VLAN tag, WCCP service group (for WCCP-GRE only), and the source and destination Ethernet MAC address. A simple inline deployment might identify only the LAN-side and WAN-side accelerated bridge ports (apA.1 and apA.2), while a complex datacenter deployment might need to use most of the features provided on the form to disambiguate traffic. See Section 4.4 for a complete description of link definition. The traffic classifier uses the Src IP and Dest IP fields in a specialized way (the same applies to Src MAC and Dst MAC): The Src field is only examined on packets entering the appliance. The Dst is only examined on packets exiting the appliance.
This convention allows the direction of packet travel to be implicitly considered as part of the definition.
8-50
June 26, 2011
8.4.5.3 Hardboost/Softboost Tab

Figure 8-59 Hardboost/Softboost tab.
This tab allows you to select between hardboost and softboost modes. If hardboost is selected, the hardboost bandwidth limit must be set. This number represents the speed at which the acceleration engine will attempt to send and receive data and must be no faster than the WAN link on which the hardboost partner is reached. When softboost is selected, these bandwidth limits are not in effect and are not shown.
8.4.5.4 Traffic Shaping Tab

Figure 8-60 Traffic Shaping tab.
This tab shows all the service-class traffic-shaping policies sorted by link, making it easier to do per-link policy selection.
8-51
8.4.6
Configuration: Network Adapters
8.4.6.1 IP Addresses Tab

Figure 8-61 IP Addresses tab.
This tab allows you to configure the IP address, netmask, gateway, HA virtual address, and VLAN of each interface, as well as enabling or disabling the interface. For complete information on port usage, see Section 4.8. What follows below is a summary.
8.4.6.2 Accelerated Pairs

Most Appliances have four ports: two configured as a bridge called Accelerated Pair A, or apA, and two non-bridged motherboard ports, Primary and Aux1. A typical installation uses only apA. Some Appliances may have a second accelerated pair. Acceleration is not supported on Primary or Aux1. Accelerated pairs do not require an IP address for simple inline-mode operation, but an IP address is required if you use the Repeater Plug-in, WCCP, or SSL acceleration. If apA is left without an IP address, the Primary port should be enabled and have an IP address assigned to it so that the Appliance can be managed. Access from the serial and front-panel interfaces will still be active. Per-port access is controlled on the Configuration: Network Adapters page.
8-52
June 26, 2011
8.4.6.3 Address Formats

Except for the hostname, the network settings expect static IP addresses or masks in the usual decimal dotted-quad notation, such as 10.0.0.150. These should be assigned as if the Appliance were simply another computer on its subnet, not as if it were a router (since it isnt a router). Changes do not take effect until you click the Update button and restart the unit.
8.4.6.4 HA Virtual IP Addresses

If high-availability mode is used, one enabled interface needs to define an HA virtual IP address. This is used to manage the pair as if it were a single unit. Both Appliances in the pair use the same HA Virtual IP address.
8.4.6.5 Web Management Access

By default, the browser-based user interface can be accessed from any enabled interface. You can use this checkbox to disable management access on selected interfaces.
8.4.6.6 VLAN Settings

If your network uses VLANs, the Appliance should be set to a valid VLAN address. Inline traffic will be accelerated regardless of the VLAN addresses (if any) of the packets, but traffic addressed to the Appliance itself must match the Appliances VLAN setting that is, either no VLAN at all or a matching VLAN. The correct VLAN setting is necessary for the proper operation of: The browser-based user interface. Virtual inline mode. Proxy mode.
VLAN support is enabled by entering the VLAN number (a decimal number in the range of 0-4095), checking the Enable box, and pressing Update. Changes do not take effect until the unit is restarted. Note: When the VLAN is enabled, the management interface only responds to browser traffic from the specified VLAN. Thus, accidentally specifying the wrong VLAN will make the browser-based interface inaccessible. This can be reset from the LCD front-panel interface.
8-53
8.4.6.7 Ethernet Tab

Figure 8-62 Ethernet tab.
Each Ethernet interface used by the Appliance is listed here, along with its speed (10, 100, or 1000 Mbps), its duplex setting (full or half), and its auto-negotiation state (auto or forced to a specific mode). Note: Auto-negotiation failures on Fast Ethernet (100 Mbps) networks are the most common cause of performance problems with Appliances. These are caused by a flaw in the Fast Ethernet Specification. See Section 7.2.2.2 for more information. A pull-down menu allows you to reset the modes of the individual Ethernet ports. Changes do not take effect until you click the Update Adapter Configuration button. Clicking on the individual adapter links (such as eth1) will open the Detailed Information page for the adapter, which is shown in Figure 8-63.
8.4.6.8 Detailed Adapter Information

The Detailed Adapter Information page gives both summary statistics for the adapter and second-by-second transmit and receive statistics. Clicking on the black arrows next to the graphs will move the view into the past (left arrows) or towards the present (right arrows) in one-minute increments.
8-54
June 26, 2011
The table offers More Info links for bridged adapters (that is, the two adapters used in inline mode) and individual flows. (A flow is the set of all accelerated connections between a given pair of Appliances.) The statistics for bridged adapters and individual flows are similar to those for individual adapters, with summary tables and second-by-second graphs.
Figure 8-63 Ethernet adapter detailed information page, top half.
8-55
Figure 8-64 Ethernet adapter detailed information page, bottom half.
8.4.7
Configuration: Logging/Monitoring
The Configuration: Logging/Monitoring page controls the logging and alert settings for the Appliance. It has seven tabs: Log Options, Log Extraction, Log Statistics, Log Removal, Alert Options, Syslog Server, and SNMP.
8-56
June 26, 2011
8.4.7.1 Log Options Tab

Figure 8-65 Log Options tab.
These options set the kind of information that is stored in the log: Log System Records. This gives general statistics about connections every 60 seconds. Most users will want to disable this option. Log Adapter Records. This reports the status of each Ethernet port every 60 seconds. Most users will want to disable this option. Log Flow Records. This summarizes the status of the communication between this unit and each active Acceleration Partner every 60 seconds. Most users will want to disable this option. Log Connection Records. This summarizes the state of each active accelerated connections every 60 seconds. Most users will want to disable this option. Log Open/Close Records. Adds a log entry whenever an accelerated connection is opened or closed. These records contain performance statistics in addition to identifying the endpoints and the connection duration. Leave this option enabled. Log Text Records. Shows kernel and other OS messages. Leave this option enabled. Log Alert Records. Repeats the information from the Alerts page in the log. Leave this option enabled. Other Settings. The Log Max Size, Lines Displayed, and Max Export Count fields are self-explanatory and rarely need to be changed.
8-57
8.4.7.2 Log Extraction Tab

Figure 8-66 Log Extraction tab.
To export log files, select a range of entries by number of date/time, and press the Export button. Your browser will show an Open/Save dialog that allows you to open the log file with a default application or save it to a file. Log files are exported as ordinary ASCII text files with a.txt extension or as XML files. Line ending style is selectable for convenience when important to systems with different newline conventions (such as Windows CR/LF vs. UNIX LF).
8.4.7.3 Log Statistics Tab

Figure 8-67 Log Statistics Tab
The Log Statistics tab gives basic information about the logging system.
8-58
June 26, 2011
8.4.7.4 Log Removal Tab

Figure 8-68 Configure Settings: Log extraction
You can erase the log files by pressing the Remove button.
8.4.7.5 Alert Options Tab

Figure 8-69 Part of the Alert Options tab.
Two Kinds of Alert Message There are two kinds of Alerts: 1. User-configurable alerts, which appear on the Configure Settings: Alert page. These are mostly informational and are primarily of use when troubleshooting. Each of these alerts has a radio button to select between Alert, Logged, and Disabled. 2. Internal alerts. These generally indicate a more serious problem, and cannot be masked by the user. They do not appear on the Configure Settings: Alert page. User-Configurable Alerts Alerted means that when the condition occurs, it will be logged, the alert icon will appear at the top of the screen, and the condition will be listed when the Error link is clicked. Logged means that when the condition occurs, it will be logged, but the alert icon will not appear and the condition will not be listed when the Error link is clicked. Disabled means the condition will not be logged. Not all conditions can be disabled. These lack a radio button under the Disabled column. The Alert Retention Time parameter sets how long an Alert stays active after the condition that caused it has gone away.
8-59
Each parameter has an associated description in the Help column (the text for which will not be repeated here). Changes will not take effect unless you press the Update button. The Reset to defaults button restores the factory-recommended settings. Alerts include: WAN Loss Rate LAN Loss Rate Connection Stalled (probable application hang) Connection Timeout Invalid Connection Attempt NIC Negotiated Half-Duplex ARP Timeout Attempt to Exceed License Key File Limit Asymmetric Network Configuration Invalid or Illegal Packets Received Out of CPU Resources Out of Memory Resources Internal Errors Compression Error Detected Softboost-Hardboost Mismatch Disk Drive is Degraded NIC Watchdog Bypass Event Disk is Fragmented Network Unreachable DNS Lookup Failed Appliance in the Middle Intercepting Options Major Internal Errors Minor Internal Errors Internal Warning WCCP Detected Major Error WCCP Detected Minor Error WCCP Warning Network Driver Hang Detected Signaling Channel Establishment Error SCPS Mode Mismatch Detected Repeater Plug-in count is nearing its limit SSL Communication Error
Internal Alerts Contact your support representative if you receive Alert messages that are not represented on the Configure Settings: Alert page.
8-60 June 26, 2011
Some of these messages give guidance about whether you should contact us immediately or at your convenience. Alert Messages Potential error conditions are reported at one of three levels: they can be ignored, they can be logged, or they can be logged and also cause an Alert warning to appear at the top of the page:
The Alerts page lets you select the reporting for different types of error. Clicking on the link displays information about the outstanding alerts, as shown in Figure 8-70.
Figure 8-70 Alert details page
Alerts will clear themselves if the problem goes away for long enough (by default, for one hour).
8.4.7.6 Syslog Server Tab

Figure 8-71 Configure Settings: Syslog server
Log entries can be sent to a syslog server at any IP you select. Alert messages are sent with a severity level of warning. All other messages are sent with a severity of info. Alert messages contain the string ALERT:.
8-61
All messages are sent to the syslog server, whether they are enabled in the Log Options tab or not. An example of syslog output is shown below. The Appliance is identified through the management IP at the start of the message. Each message is formatted as a single line.
May 08 14:40:36 172.16.0.101 Open:69.59.212.183:3672 Partner:172.16.0.102{00-13-72-3C-68-51}->207.47.50.203:443 May 08 14:40:37 172.16.0.101 Connection Status: 66.151.150.190:443<->69.59.212.183:3609 Duration:58.000 Sec May 08 14:40:37 172.16.0.101 Connection Status: 207.47.50.203:443<->69.59.212.183:3668 Duration:0 Secs
8.4.7.7 SNMP Tab

Figure 8-72 SNMP tab.
This tab sets up SNMP monitoring of the Appliance. SNMP operation is disabled by default, but is enabled by the button at the top of the page. SNMP v1 and v2c are supported.
8-62 June 26, 2011
Fields on this page have their conventional meanings. Management access must be restricted by giving an IP or network number for the management station. However, this can be circumvented by setting the IP Bit mask to zero (equivalent to a bit mask of 0.0.0.0). To give access to any host on a Class C subnet, set the IP Bit Mask to 24 (equivalent to 255.255.255.0). To limit access to a single host, set the IP Bit Mask to 32 (equivalent to 255.255.255.255). SNMP accesses are read-only; that is, monitoring but not configuration is supported by SNMP. The parameters available via SNMP are documented in the .MIB files themselves.
8.4.7.8 Installing the SNMP MIB Files

SNMP MIB files can be downloaded from the links at the bottom of the page. The files reside on the Appliance. They must be loaded into the SNMP manager in the following order:
APPACCELERATION-PRODUCTS-MIB.txt APPACCELERATION-SMI.txt APPACCELERATION-STATUS-MIB.txt APPACCELERATION-TC.txt CITRIX-COMMON-MIB.txt
8.4.8
Configuration: Repeater Plug-ins
This page controls how the Appliance interacts with Repeater Plug-in. Repeater Plug-in support is a licensed option; so this page is greyed out if no Plug-ins are supported by your license.
8-63
8.4.8.1 Signaling Channel Configuration Tab

Figure 8-73 Signaling Channel Configuration tab.
This tab controls the basic operation of the Appliance when dealing with Plug-ins. Signaling IP. This is an IP address that is used for the signaling connection between the Plug-in and the Appliance, which transfers status information, and for data connections when using redirector mode. Signaling Port. This is the port used by the signaling connection. Defaults to port 443 (HTTPS), which is generally the best choice. Connection Mode. Choices are transparent mode (in which connections are intercepted and accelerated transparently, as with Appliance-to-Appliance communication) and redirector mode (where the Plug-in addresses accelerated connections to the signaling IP directly. Transparent mode is recommended; redirector mode has several liabilities that make it a mode of last resort. Enable Plug-in-Appliance RTT Detection. This feature prevents acceleration when the Plug-in and Appliance are on the same LAN. Such local acceleration is undesirable because the Appliances bandwidth limit will be applied to local connections, which will greatly reduce the speed of LAN-to-LAN traffic. Min. Plug-in-Appliance RTT for Acceleration. This value should be larger than any RTT (ping time) seen on the local LAN, but smaller than that seen by any remote user. The default value of 20 ms is adequate for most networks. Refresh/Cancel/Apply. Depending on context, some subset of these buttons will appear. Note: Changes to the connection status will not be updated in real time. Press the Refresh button to see the actual status.
8-64
June 26, 2011
8.4.8.2 Acceleration Rules Tab

Figure 8-74 Plug-in acceleration rules.
This tab defines which Plug-in connections will be accelerated. The rules are based on the destination address of the connections SYN packet (that is, the IP address of the server). Rules can either include or exclude addresses or port ranges. The first matching entry determines whether Plug-in acceleration is allowed or disallowed. Note: If the rules on this page specify that acceleration is allowed, acceleration will be enabled even if it is forbidden on the service-class policies page.
8.4.8.3 Best Practices With Acceleration Rules

Use Accelerate rules for all subnets that are local to the Appliance. Generally this means the LAN subnets at the site where the Appliance is installed. If there are any destination addresses in this space that are not really LAN addresses, add Exclude rules for these addresses and move the Exclude rules above the Accelerate rules. This would include any remote sites with addresses that seem local. If the Appliance is inline with a VPN (and is not inline with anything else), and is operating in transparent mode, you can set the Appliance to accelerate your entire enterprise rather than just the local site. In this case, the only accelerated connections will be from Plug-in VPN connections and accelerating all the traffic between the Plug-in and VPN is optimal.
8-65
8.4.8.4 General Configuration Tab

Figure 8-75 General client configuration.
This tab enables various housekeeping and diagnostic features related to the Repeater Plug-in. The operation of most features is TBD.
8-66
June 26, 2011
8.4.9
Configuration: Secure Partners
Figure 8-76 Configuring peer communication.
This page is used to set up the SSL signaling connection used by SSL compression. Its fields and use are describe in Section 4.20.4, Step 7.
8-67
8.4.10 Configuration: Service Classes

8.4.10.1 Service Class Definition Tab
Figure 8-77 Service Class Definition tab.
Service classes map applications, IP ranges, incoming Diffserv (DSCP) fields, or VLANs to acceleration and traffic-shaping policies. This page shows the list of defined service classes. This is an ordered list; the first matching service-class definition will be used. Each service class has controls to move the definition within the list, edit the definition, or delete it. By default, only the service class names are shown, but they can be expanded to summarize their definitions as well. Creating a New Service Class Click on the Create button at the top of the page. This will pop up the Create Service Class Page (see Figure 8-78). Give the new service class a name, select an acceleration policy (choices are: none, flow-control only, memory-based compression only, and disk-based compression), assign a traffic-shaping policy, and enter a set of filter rules. Typically a single filter rule will be used, specifying an application or an IP range.
8-68
June 26, 2011
Figure 8-78 Create Service Class page.
Rules can be based on the application, source and destination IP address, VLAN tag, or the incoming DiffServ (TOS/DSCP) bits. If the SSL Profiles field is used, any traffic matching the service class is considered to also match the selected SSL profile. The traffic-shaping policies can be set to the same policy for all links or with per-link policies. In most installations, per-link policies are not desirable. Multiple rules can be specified. Fields within a single rule are ANDed together, so all specified fields must match. When multiple rules are used, they are evaluated in order. If any rule matches, the traffic is considered to belong to the service class. Traffic-shaping policies are chosen from the pull-down menu. By default, a range of policies from Very Low to Very High are defined, each policy having twice the weighted priority of the next-lower policy. In addition, there is a VoIP Traffic policy that has an effectively infinite weight (and thus must be used with caution), and a Default Policy. Editing an Existing Service Class This process is essentially the same as creating a new service class. Meaning of Acceleration Policies Flow Control Only. The Flow Control checkbox enables or disables acceleration. Recommended for traffic that is 100% uncompressible because the same data will never be seen twice (mostly encrypted protocols and live video). Note that pre-compressed traffic such as JPG images, ZIP archives, and audio/video streams that are played more than once are all highly compressible on the second pass. For example, if two people play the same YouTube video, the compressor will achieve a high compression ratio for the second users, since the video data will be the same as before and will match the first copy. Disk Compression. Enables flow control and the full range of compression features (disk-based and memory-based compression). Recommended for most traffic. Memory-based Compression. Enables flow control and memory-based compression only. This option is rarely used.
8-69
Rules are Evaluated In Order Acceleration policy. When a connection is opened, the first matching policy in the list will be used. Rules can be moved up and down in the list using the Move Up and Move Down buttons. Changes do not take effect until the Apply button is pressed. Acceleration policies are based solely on information available on the first packet of the connection (the SYN packet). The results of deep packet inspection are not available until later in the connection, so such matches cannot be made. Acceleration policies are only meaningful on accelerated connections. Traffic-Shaping Policy. The initial traffic-shaping policy is based on the first packet seen, but deep-packet inspection may change this decision. For example, an application that is defined based on a URL will match when a data packet containing an HTTP GET url command is seen. This will reclassify the traffic-shaping policy for the connection. All WAN data flows have a traffic-shaping policy, whether they are accelerated or non-accelerated, TCP or non-TCP. Only Acceleration Features Allowed by Both Units Are Used Only acceleration options that are agreed upon by both Appliances will be used. For example, if one unit selects compression for a connection and the other does not, the connection will be uncompressed. Traffic will not be accelerated unless there are two Appliances involved, one at either end of the link, and both enable flow-control or compression for the connection. Other TCP Traffic is a special category that specifies the default acceleration action to take if no other service classes apply. Special-Case Handling for Internet HTTP/HTTPS The service class policies for HTTP and HTTPS are split into Private and Internet variants. The reason for this is that some Web sites have paranoid firewalls that reset TCP connections with unknown TCP options, which sometimes include acceleration options. While such connections will be retried as unaccelerated connections after a timeout period, this is time-consuming and annoying to the users. The Web (Private) and Web (Private-Secure) service classes define HTTP and HTTPS service on the standard private networks of 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16, as defined in RFC1918. These addresses are not routable on the public Internet, and instead are used by most organizations for their private networks. As such, we can assume that the problem of paranoid firewalls will not occur on these networks, and HTTP and HTTPS traffic can be accelerated normally. The Web (Internet) and Web (Internet-Secure) service classes are for non-private Web traffic and have flow control and compression disabled. The ordering of the two sets of rules is important; the Private rules need to occur first in the Service Class Policy list. These rules are not necessary unless Internet traffic passes through a single Appliance. If Internet traffic passes through two Acceleration units (two Appliances or an Appliance and a Plug-in), the Internet rules can be set to the same values as the Private rules, allowing acceleration on all Web traffic.
8-70 June 26, 2011
8.4.10.2 Traffic Shaping Tab

This tab reiterates the service classes, but with the traffic-shaping policies listed as one line per link, to make it easier to examine or alter per-link policies.
8.4.11 Configuration: SSL Acceleration

This page consists of five disguised tabs (disguised because they are implemented as buttons). They are: Profiles. Allows you to set up server profiles, typically one per endpoint SSL server. The fields for this tab, and the procedure for using it, are given in Section 4.20.4, Steps 9-10. Manage CAs. Allows you to upload CA certificates. See Section 4.20.4, Step 6. Manage Keys. Upload certificate/key pair. See Section 4.20.4, Step 6. Import SSL. Upload an SSL configuration previously saved on the Export SSL tab.
Figure 8-79 Import SSL tab.
Export SSL. Save the current SSL configuration to a file.

Figure 8-80 Export SSL tab.
8-71
8.4.12 Configuration: SSL Encryption

Figure 8-81 Configuration: SSL Encryption page
This page has the main password and enable/disable toggles for SSL compression. Key Store. For greater security, keys are password-protected. SSL compression will not take place unless the key store is opened with the password. For security reasons, SSL compression is disabled after each restart, until this password is entered. If user data encryption is used, compression is also disabled until this password is entered. See Section 4.20. User Data Store. User data, consisting mostly of disk-based compression history, can optionally be encrypted using AES-256 encryption. Changing the encryption state causes disk-based compression history to be lost. Encrypting the user data protects the contents from disk-based compression history from being examined if the unit is stolen or removed from service. SSL Optimization. The master enable/disable switch for the SSL compression feature.
8-72
June 26, 2011
8.4.13 Configuration: Traffic Shaping Policies

Figure 8-82 Configuration Traffic Shaping Policies page.
The Configuration: Traffic Shaping Policies page allows you to add traffic-shaping policies. The default policies are adequate for most installations and cannot be edited or deleted (except for the ICA Priorities and Default policies). However, if you have special requirements, new polices can be added or edited.
8-73
8.4.13.1 Creating and Editing Policies

Figure 8-83 Create Policy page.
Pressing the Create button takes you to the Create Policy page, which has the following fields (some of which are hidden by default, but can be revealed with the Show Advanced Options button): Name. The name of the new policy. Must be unique. Weighted Priority. This can be the same as an existing priority value or can be a custom value between 1 and 256. A connection with a priority of 256 will get 256 times the bandwidth share as a connection with a priority of 1. Set ICA Priorities. If this policy will be used for Citrix XenApp/XenDesktop traffic, the traffics internal priority values can be mapped to Branch Repeater priorities. Optimize for Voice. If checked, this policy will have effectively infinite priority. This is highly undesirable for most traffic, since it will prevent meaningful traffic shaping and will cause data starvation for other traffic if there is enough optimized for voice traffic to fill the link. Use only for VoIP, and always use in conjunction with a bandwidth limit on the policy (for example, 50% of the link speed). Set Diffserv/TOS. Sets the Diffserv field of matching traffic to the indicated value, informing downstream routers of the traffic priority.
8-74
June 26, 2011
Set ICA Diffserv/TOS. As above, but allows the Diffserv field to be set differently depending on the priority field within the ICA data stream. Has no effect on non-ICA traffic. Limit Bandwidth. Prevents the traffic from this policy from exceeding a specified percentage of link bandwidth, or a specified absolute rate. Because this limits performance, it is rarely used except with voice traffic. Editing policies is essentially identical to creating new ones.
8.4.14 Configuration: Tuning

Figure 8-84 Configure Settings: Tuning page
This page contains a number of TCP-oriented settings, including which ports are accelerated, TCP window scaling limits, connection timeouts, etc. The individual setting are listed below. Note: Unlike the other pages, the buttons on the Tuning page are greyed out until you change a parameter.
8-75
8.4.14.1 Window Settings
There are two tuning settings: the WAN scale limit and the LAN scale limit. These set the TCP scaling option between the two Appliances (See RFC 1323). The default LAN scale limit is 16, corresponding to a 64 KB (216 bytes) advertised window. The default WAN scale limit is 23, corresponding to an 8 MB (223 bytes) advertised window. These values rarely need to be changed from their defaults, though in WANs with a very high bandwidth-delay product, the WAN scale limit may need to be increased, while on a WAN with a very low bandwidth-delay product, the WAN scale limit may need to be decreased. The rule of thumb is to have a WAN scale limit that is at least 2-3 times the bandwidth-delay product. For example, a 200 Mbps link with a 500 ms RTT has a bandwidth-delay product of 100,000,000 bits. Doubling this gives 200,000,000 bits, or 25,000,000 bytes. This is larger than the default 8 MB window. Increasing the WAN scale limit to 23 (225 bytes or 32 MB) would accommodate this. Increasing these limits under other circumstances will not increase performance and will only waste memory.
8.4.14.2 Connection Timeout
Idle accelerated connections should time out eventually, as they consume system resources. This entry gives the idle time that must elapse before the Appliance closes a connection. If the application sends keep-alive packets, these will reset the idle timer. Such connections will never be closed by the connection timeout mechanism. Some links see thousands of half-closed connections that never become fully closed. These may eventually overflow the Appliances connection table. The Active Connections page can identify half-closed connections. If the problem cannot be fixed at its source, shortening the idle timeout can eliminate the problem.
8.4.14.3 Special Ports
8-76
June 26, 2011
When using address translation with the ftp or rshell (rsh/rcp/rexec) protocols, the agent performing the address translation must be protocol-aware. FTP control ports and rshell control ports define which ports are used with these two protocol groups. If you use nonstandard ports for these protocols, adding the port numbers the special ports list will allow them to work in proxy mode.
8.4.14.4 Privileged Ephemeral Ports

Ports in this range can be used as ephemeral ports only by specific applications.
8.4.14.5 Virtual Inline
Virtual inline mode allows a router to send packets to the Appliance and receive packets back from it. There are two slight variations of this forwarding. The first is to forward packets to the default gateway. The second is to forward them to the Ethernet address they came from. Both have the potential to create routing loops. Policy-based routing is required to prevent router loops. See Section 4.11.
8.4.14.6 Daisy-Chain
Acceleration takes place between two Appliances. If three or more Appliances are used in series, the link will not be accelerated end-to-end. Instead, the link between Appliances 1 and 2 will be accelerated, but not between Appliances 2 and 3. Appliances with the Enable Daisy-Chained Units option set will detect when they are in the middle of a chain, and pretend that such connections are non-accelerated. This guarantees that the two endpoint Appliances will both see an accelerated connection. Daisy-chaining is not recommended for hardboost links. Peculiarities of Daisy-Chaining Daisy-chaining does not need to be enabled except on the middle units. The bandwidth graph of the middle unit will display daisy-chained connections as non-accelerated. If a middle Appliance has its acceleration disabled or restarts, the daisy-chained connections will be reset, just like the ordinary accelerated connections.
8-77
8.4.14.7 TCP Maximum Segment Size (MSS)
This specifies the maximum size of the TCP portion of a packet. This defaults to 1380 bytes. If you have a VPN that encapsulates packets inside another header (as PPTP and IPSec VPNs do), you may need to reduce this to prevent packet fragmentation. Reducing the MSS to 1340 will usually accomplish this. Both the Default MSS and Maximum MSS fields should always be set to the same value.
8.4.14.8 Forwarding Loop Prevention
The Forwarding Loop Prevention option allows the same packet to traverse Appliances twice without causing trouble. In most deployments, this does not happen, but sometimes it is unavoidable. Passing the same packet through the same Appliance multiple times, or through more than one Appliance in the same group, can cause problems.
8.4.14.9 Legacy CIFS Protocol Filtering

Allows specific IP ranges to be either included into or excluded from CIFS acceleration. Not recommended for new installations.
8.4.14.10Generic Settings
This allows any internal Appliance parameter to be set to an arbitrary value. This is generally done only at the request of Support. For example, the bandwidth limit can be set 1,000 kbps by putting SlowSendRate in the Setting field and 1000 K/S in the Value field. You can also query the current setting of a parameter by filling in the Setting field but leaving the Value field blank. Note: The internal Appliance values are not documented and setting them in this way is not recommended, unless you are advised to do so by Support.
8-78 June 26, 2011
8.4.15 Configuration: Windows Domain

Figure 8-85 Configuration: Windows Domain page.
The Configuration: Windows Domain page allows the server-side Appliance to join the same Windows Domain as the servers it is accelerating, allowing encrypted MAPI and signed SMB traffic to be accelerated (providing that the client-side Appliance has SSL acceleration configured to the point where a secure peer relationship exists between the client-side and server-side Appliances). Joining the domain needs to happen only once, by typing in the domain credentials. (If the domain password changes, this will have to be repeated.) Demo Mode In demo mode, the login credentials of a single user are used instead of the domain credentials. This allows the acceleration of outcropped MAPI and signed SMB for that user. This mode is recommended for demonstration and testing only.
8-79
8.5 Reports Pages
8.5
8.5.1
Reports Pages
Reports: Compression
8.5.1.1 Compression Graphs Tab

Figure 8-86 Compression graphs tabs.
These tabs show graphs and tables based on several timescales (minute, hour, day, etc.): Accelerated Line Usage. This has nothing to do with compression, but shows the top accelerated service classes by the amount of WAN bandwidth used. Non-Accelerated Line Usage. This has nothing to do with compression, but shows the top non-accelerated service classes by the amount of WAN bandwidth used. Compression by Service Class. Shows the data size before and after compression, for compressed traffic only. This is measured at the compression engine, and gives the amount of data seen by the users application (that is, it excludes headers and retransmissions), and thus has data sizes smaller than those seen on the link for both the before and after categories, since it measures goodput rather than total usage. Service Class Details. This has nothing to do with compression but shows some statistics on a per-service-class basis.
8-80
June 26, 2011
8.5.1.2 Compression Status Tab

Figure 8-87 Compression status tab.
The Compression Status tab shows cumulative compression statistics rather than second-by-second results. The statistics can be cleared at any time by pressing the Clear button. This affects only the statistics on this page. Otherwise, the data covers the time since the last restart. Statistics are reported separately for the sending and receiving direction. The compression ratios have their usual meaning (uncompressed bytes / compressed bytes). The Data Reduction values are a different way of expressing the same information as the compression ratio. For example, a connection with 10:1 compression has a bandwidth reduction of 90%. Only payload bytes are considered in these calculations. However, compression aggregates packets (several packets can be compressed into one), so the number of packets (and hence the number of header bytes) tends to be reduced by an amount roughly equal to the compression ratio. That is, a 2:1 compression ratio will tend to halve the number of packets, which is equivalent to 2:1 header compression.
8-81
8.5 Reports Pages
8.5.2
Reports: LAN vs. WAN
Figure 8-88 Reports: LAN vs. WAN page.
The LAN vs. WAN report compares all LAN traffic to all WAN traffic (including non-accelerated traffic). This can provide meaningful insights in some (but not all) deployments. In simple inline deployments, where LAN traffic is directly related to WAN traffic in some way, the difference between the traffic volumes shows some of the effect of caching and compression, since these operations reduce WAN data usage. However, read-ahead and some flow-control optimizations increase total WAN usage, even though they increase overall performance at the same time, making this page hard to interpret. As with other historical pages, this covers timescales from last minute to last restart.
8-82
June 26, 2011
8.5.3
Reports: Link Usage
Figure 8-89 Reports: Link Usage page.
The Reports: Link Usage shows the LAN-side and WAN-side traffic in both directions. As with other historical pages, this covers timescales from last minute to last restart.
8-83
8.5 Reports Pages
8.5.4
Reports: Service Classes
Figure 8-90 Reports: Service Classes page.
The Reports: Service Classes page shows the WAN-side traffic over the specified time period, with each service class shown in a different color, along with a table giving traffic statistics for the service classes. See also the Top Applications graph (Section 8.5.5), which is similar but breaks the traffic down into individual applications, which gives finer-grained reporting than service classes. As with other historical pages, this covers timescales from last minute to last restart.
8-84
June 26, 2011
8.5.5
Reports: Top Applications
8.5.5.1 Historical Graphs

Figure 8-91 Reports: Top Applications page.
The Reports: Top Applications page lists the most common applications in terms of WAN usage, showing pie charts, and time graph, and a table of total usage over the specified time interval. By default, the top ten applications are listed. This can be changed with the Customize button. As with other historical pages, this covers timescales from last minute to last restart. The second table on the historical tabs shows the list of applications for a second time, with links to historical information on the application, the parent application, and the application group.
8-85
8.5 Reports Pages
8.5.5.2 Active Applications Tab

Figure 8-92 Active Applications tab.
The Active Applications tab shows a table of all applications seen since the last restart, sorted by WAN data volume.
8-86
June 26, 2011
8.5.6
Reports: Traffic Shaping
Figure 8-93 Reports: Traffic Shaping page.
The Reports: Traffic Shaping page shows historical graphs and tables of WAN traffic, with each traffic-shaping policy shown in a different color. As with other historical pages, this covers timescales from last minute to last restart. The last restart tab has a different format and allows you to click on an individual traffic-shaping policy and see its historical graphs in isolation.
8-87
8.6 System Maintenance Pages
8.6
8.6.1
System Maintenance Pages

System Maintenance: Backup/Restore
Figure 8-94 System Maintenance: Backup/Restore page.
Backup Settings/Restore Settings. The units configuration can be saved to a file through your browser. License files, SSH parameters, and the IP addresses on the Management IP pages are not saved. Once saved, the file can be restored to the same Appliance. License files, SSH parameters, and IP addresses are not restored. The file is an ordinary text file, but should not be edited manually. Reset to Factory Defaults. Sets all parameters except IP addresses, bandwidth settings, and licenses to their factory defaults.
8.6.2
System Maintenance: Clear Statistics
Figure 8-95 System Maintenance: Clear Statistics page.
The System Maintenance: Clear Statistics page allows you to reset the Appliances statistics, allowing you to create reports that start at the beginning of the desired sampling window.
8-88
June 26, 2011
8.6.3
System Maintenance: Date/Time
Figure 8-96 System Maintenance: Date/Time page
The date and time are set on this page. You can set the date and time manually by updating the time fields with the current time, or use an NTP server by specifying its IP or DNS address. The Zone field allows you to choose a time zone. The date and time must be accurate (within 10-20 seconds) for the Appliance to join a Windows Domain successfully.
8-89
8.6.4
System Maintenance: Diagnostics
8.6.4.1 Tracing Tab

Figure 8-97 The Tracing tab.
Trace files are effective in helping our Technical Support team pinpoint your problem. The Appliance provides a certain amount of tracing continuously. The results can be packaged into an ZIP archive if you press the Stop Trace button. This archive can be downloaded onto your computer, via the Retrieve File button. Once downloaded, it can be forwarded to Support.Because the trace files are generated continuously, they also provide crash analysis data. This tab has a large number of tracing parameters, none of which should be touched except at the request of Support.
8.6.4.2 Bypass Card Test Tab

Figure 8-98 Bypass Card Test tab
The fail-to-wire (Ethernet bypass) functionality of the Ethernet interface can be tested for a user-selected period with the feature. Enter the number of seconds for the unit to fail-to-wire (bypassing all Appliance functionality and causing the unit to act as if it
8-90
June 26, 2011
had a cross-over cable between the two ports) and press the Submit Query button. The bypass relay will close for the specified number of seconds. Afterwards, normal operation will resume.
8.6.4.3 Retrieve Cores Tab

Figure 8-99 Retrieve Cores tab
If the Appliance software has exited abnormally, core files will have been left behind. The unit will restart automatically after an abnormal exit, except in cases of persistent crashes, where it will disable acceleration while leaving the management interface active. 1. Select one or more core files to send to Support. Choose core files based on date and time. That is, a core file that was generated at a time when the unit was failing or behaving strangely is better than one from a period where no one noticed anything wrong. When in doubt, send them all. 2. In the Core Retrieval table, select the check boxes in the left-hand column of the desired core files. Leave the checkboxes for Retrieve Core, Trace, and Log checked and the Timespan at 20 minutes. (The Timespan field tells the system how far back before the core file was generated to collect log data and similar information.) 3. Press the Get Core Files button. The selected files will be gathered into a.zip archive (this may take several minutes), and a new screen will be shown. 4. Click on the Click here link. A dialog box will ask you what you want to do with the file. Select Save File to Disk. A Save As.. dialog box will open. Choose an appropriate directory and save the file.
8-91
8.6.4.4 Line Tester Tab

Figure 8-100 Line Tester tab
The Line Test: SERVER function starts an iperf server on the Appliance, running in TCP mode. Iperf is a free TCP/UDP performance testing tool, available for Windows and UNIX systems from: http://dast.nlanr.net/Projects/Iperf The documentation for iperf is also on this site. Iperf is preinstalled on Appliances as a convenience. To run iperf tests, one system (an Appliance or other host) must run iperf as a server, and another must connect to it as a client. The defaults on the Diagnostics Tools page are the usual defaults for iperf. Press the Start Server button to start an iperf server on the Appliance. The Line Test: CLIENT function starts an iperf client on the unit, running in TCP mode. You specify the iperf server to connect to, the port number, the interface, and the length of the test. For the latter two parameters, the defaults are usually adequate. When the test is complete, the connection speed will be reported.
8.6.4.5 Ping and Traceroute Tabs

The Ping and Traceroute tabs (not shown) allow you to use the standard ping and traceroute utilities to test connectivity to remote systems.
8-92
June 26, 2011
8.6.4.6 System Info Tab

Figure 8-101 System Info tab
The System Info tab takes you to a page that lists all parameters that are not set to their defaults. This information is read-only. It is used by Support when some kind of misconfiguration is suspected. When you report a problem, you may be asked to check one or more values on this page. The information is intended for use by Support, and is not documented. This page also replicates the detailed adapter info described in Section 8.4.6.8.
8-93
8.6.5
System Maintenance: Restart System
Figure 8-102 System Tools: Restart System page.
Clicking the Restart Repeater button will cause the Appliance to be restarted, a process that takes several minutes.
8.6.6
System Maintenance: Update Software
Figure 8-103 System upgrade page.
8.6.6.1 Upgrading to a New Release

The Appliance software is upgraded by means of patch files that you obtain from Citrix. The usual source is http://www.MyCitrix.com. Log into MyCitrix (you need a valid service agreement, a login, and a password). Navigate to Downloads: Repeater: Firmware. Select a release and click on Get Firmware to download the release. To install a patch file, click the Browse button on the System Upgrade Page (see Figure 8-103), select the patch file, and upload it to the Appliance. This requires that the patch file be on a file system that can be accessed by your browser. (This condition is met automatically if you used the same browser to download the patch in the first place.) A patch file will be examined by the Appliance and will only be installed if it is a valid patch file that will upgrade the system to a different release from the one currently in use.
8-94 June 26, 2011
An upgrade preserves license files and system settings. The upgraded unit requires no reconfiguration except for any new features that have been added with the new release. Once a patch is installed, a new screen will ask if the unit can be restarted. The patch will not be applied until the unit is restarted. If the user chooses not to restart the system immediately, a reminder will be placed at the top of each page. The unit may require several minutes longer than usual to restart when it is applying a patch.
Figure 8-104 Display on a successful patch upload.
Figure 8-105 A reminder is displayed if restarting is deferred.
8.6.6.2 Downgrading to a Prior Release

You can also revert to any previously installed release by selecting it from the Downgrade Release pull-down menu and pressing the Change button. If you are using Repeater disk encryption, the other releases on the unit will be displayed in orange, and the Downgrade Release option is not available unless you first disable disk encryption. The Appliance maintains copies of older releases, and the downgrade process reverts to one of these. Licenses and settings are not copied back from the newer release to the older one. Instead, the unit will revert to the settings that were in effect at the time the older release was upgraded.
8-95
8.6.6.3 Changing the Version Type

The Change Version Type option allows you to select a debug version of the release. Possible debug versions are Level 1 or Level 2. You should not select these unless instructed to do so by Support.
8-96
June 26, 2011
Chapter9
CommandLineInterface
The command-line interface (CLI), allows flexible remote access, remote configuration, and scripting on the Appliance. The command-line interface is accessed through two mechanisms: SSH and SFTP. SSH is used for interactive and script access, while SFTP is used for transferring files into and out of the Appliance. The syntax is straightforward. Numeric fields are in decimal. String fields can be surrounded by double-quotes, or the quotes can be omitted strings that contain no embedded spaces.
9.1
SSH Access
To use the CLI via SSH, open an SSH connection to the Appliance. For an Appliance on address 172.16.0.103, the login sequence is (bold text is typed by you):
ssh cli@172.16.0.103 Last login: Fri Jun 20 14:50:22 2008 from xx.xx.xx.xx Login: admin Password: xxxxxxxx Command Line Interpreter - Version 1.0 Copyright 2008 Citrix Systems. All Rights Reserved. (admin)>
On Windows systems, you might need to install the PuTTY package and use putty instead of ssh. Note that you first log in as user cli, which has a null password, but you are immediately prompted to log in with proper Appliance credentials, using any username/password that would work on the Appliances browser-based UI. Once logged in, all the CLI commands are available to you.
9.2
RS-232 Access
The CLI can also be used via a null modem cable to the Appliances serial port at 115,200 baud, 8 data bits, 1 stop bit, no parity. The login procedure is the same as with SSH.
9-1
9.3 SFTP Access
9.3
9.3.1
SFTP Access
Enabling file transfer
A special account, with username transfer, allows file transfers into and out of the Appliance. This account is disabled by default but can be enabled via the CLI with the set access type transfer password password command. This enables the transfer account and sets its password to password. (Once enabled, the transfer account cannot be disabled. However, it can be effectively disabled by assigning it a very long and unmemorable password.)
9.3.2
Transferring Files
Once enabled, you can use sftp (or, on Windows, perhaps psftp), to log onto the Appliance with username transfer and the password you selected. You can then upload or download files. See the Command Descriptions section (below) for the commands that accept uploaded files or create downloadable files. Note: Do not use pathnames for the Appliance side of the transfer. Transfer all files into or out of the default directory. Note: Filenames should contain only the characters a-z, A-Z, 0-9, period, and hyphen (dash).
9.4
9.4.0.1
Command Description
quit
9.4.1
9.4.1.1
CLI Navigation
exit
Syntax: exit Exits from the CLI. Same as quit.
9.4.1.2
Syntax: quit
quit
Exits from the CLI. Same as exit.
9.4.2
9.4.2.1
System Tools
show config-script
Syntax: show config-script [-replicate] [-file filename]
9-2
June 26, 2011
Chapter 9. Command Line Interface
Displays the appliances current configuration or, optionally, saves the configuration to the file filename. This configuration can be reloaded into the same appliance or another appliance. -replicate omits appliance-specific configuration such as IP addresses, allowing the output of this command to be used more conveniently for configuring multiple appliances. -file filename specifies that the output should be saved to the specified file rather than displayed. No pathname components should be used.
9.4.2.2
list config-script-files
Syntax: list config-script-files Displays a list of the saved configuration files on the appliance.
9.4.2.3
save settings
Syntax: save settings -file filename Saves all parameters to the file specified by filename. The file is saved in the settings folder on the unit.
9.4.2.4
restore settings
Syntax: restore settings -file filename Restores all parameters from the file specified by filename. The file must be in the settings folder on the unit. CAUTION: This command takes effect immediately and reboots the appliance, without an are you sure? verification.
9.4.2.5
list settings-files
Syntax: list settings-files Displays a list of the saved settings files on the appliance.
9.4.2.6
reset settings
Syntax: reset settings Equivalent to Reset to Factory Defaults in the UI. Sets all parameters except IP addresses and the license file to their factory settings. CAUTION: This command takes effect immediately and reboots the appliance, without an are you sure? verification.
9.4.2.7
restart
Syntax: restart Reboots the appliance.
9-3
9.4 Command Description
CAUTION: This command takes effect immediately, without an are you sure? verification.
9.4.2.8
Syntax: what
what
Reserved for use by Command Center.
9.4.2.9
show software
Syntax: show software Lists all of the versions of the software installed on the appliance. One of these will be the running version, while the others are available through the restore command (or, on the Web UI, the Downgrade Release feature).
9.4.2.10
verify software
Syntax: verify software -file filename Performs checks on file filename to see if it is a complete, uncorrupted software release file. Note: This command is intended for newly transferred files. Files listed via the show software command are known-good files and cannot be checked by this command.
9.4.2.11
install software
Syntax: install software -file filename [-restart] Installs the software file filename and optionally (with the -restart option) restarts the appliance. Note: This command is intended for newly transferred files. Files listed via the show software command are installed via the restore software command.
9.4.2.12
list software-files
Syntax: list software-files Displays a list of software release files on the appliance.
9.4.2.13
restore software
Syntax: restore software -version version Reinstalls a previously installed software version. Version is the software version string. It must be identical to one of the versions listed by the show software command. Example: restore software -version 4.3.24.1014
9-4
June 26, 2011
9.4.2.14
set software
Syntax: set software -type {default, level1, level2, defaultmc, level1mc, level2mc} Selects which version of the binary should be used. Default should be used unless Citrix Support recommends otherwise.
9.4.3
9.4.3.1
licenses
add local-license
Syntax: add local-license [-name license-name] -file filename Installs the license file filename. -name specifies the license name to be assigned on the system. -file specifies a previously uploaded license file in the transfer account. Example: add local-license -name new -file newlicense.txt
9.4.3.2
list license-files
Syntax: list license-files Displays a list of license files uploaded to the transfer account.
9.4.3.3
remove local-license
Syntax: remove local-license -name license-name Removes an installed license.
9.4.3.4
rename local-license
Syntax: rename local-license -old old-license-name -new new-license-name Changes an installed license name.
9.4.3.5
show license-models
Syntax: show license-models Displays the list of models which is needed to acquire license from the remote license server.
9.4.3.6
show license
Syntax: show license Displays the current license server configuration and the licensed features.
9.4.3.7
show local-license
Syntax: show local-license Displays the name of all local licenses installed.
9.4.3.8
set license-server
Syntax: set license-server -location local Syntax: set license-server -location remote [-model model name] [-ip ipaddr] [-port port] Configures the system to use local or remote license server. -model specifies the model name with which to acquire the license. Use show license-models command to display the list of models. -ip is the IP address of the remote license server. -port specifies the remote license server port (default 27000). Example: set license-server -location remote -model v1000 -ip 192.168.0.1 -port 27000
9.4.4
9.4.4.1
Security
show user
Syntax: show user [-name username] Lists all the users defined on the appliance, and whether they are administrators or view-only users. If the -name option is specified, only the information about the specified user will be shown.
9.4.4.2
add user
Syntax: add user -name username -password password -privilege {admin, viewer} Defines a new user with the specified username, password, and privilege.
9.4.4.3
set user
Syntax: set user -name username

9-6 June 26, 2011
-password password -privilege {admin, viewer} Alters the definition of an existing user with the specified username, allowing a change to the password or privilege level.
9.4.4.4
remove user
Syntax: remove user -name username Deletes user username
9.4.4.5
show access
Syntax: show access [-type {radius, tacacs, web, transfer, support}] Summarizes the settings for the Web UI, for Radius and TACACS+ authentication, for transfer account, and for the support account, including the enabled ports and options. By default, all five categories are displayed, but a single category can be selected with the -type option.
9.4.4.6
enable access
Syntax: enable access -type {radius, tacacs, web} Enables one of: Radius authentication, TACACS+ authentication, or access to the Web UI. Parameters for these features remain at their previous settings.
9.4.4.7
disable access
Syntax: disable access -type {radius, tacacs, web} Disables one of: Radius authentication, TACACS+ authentication, or access to the Web UI. Parameters for these features remain at their previous settings.
9.4.4.8
set access
Syntax: set access -type radius [-ip ipaddr] [-port port] [-secret secret] Syntax: set access -type tacacs [-ip ipaddr] [-port port]
[-secret secret] [-encrypt {enable, disable}] Syntax: set access -type web [-protocol {http, https} -port port] [-forwardhttp {enable, disable}] [-ssl-cert certfile -ssl-key keyfile] Syntax: set access -type transfer -password password Syntax: set access -type support -password password Configures access parameters. The first two forms enable Radius and TACACS+ authentication, respectively. The third form sets the Web UI parameters. The forth form sets a password for the transfer account, which is used for transferring files. The last form sets a password for the support account.
9.4.4.9
list certificate-files
Syntax: list certificate-files Displays any uploaded certificate files.
9.4.5
9.4.5.1
System Status
enable unit
Syntax: enable unit Enables unit for traffic shaping and acceleration.
9.4.5.2
disable unit
Syntax: disable unit Put unit in passthrough mode. No traffic shaping nor acceleration.
9.4.5.3
enable acceleration
Syntax: enable acceleration Enables flow control and compression.
9.4.5.4
disable acceleration
Syntax: disable acceleration Disables flow control and compression.

9-8 June 26, 2011
9.4.5.5
enable traffic-shaping
Syntax: enable traffic-shaping Enables quality of service traffic shaping.
9.4.5.6
disable traffic-shaping
Syntax: disable traffic-shaping Disables quality of service traffic shaping.
9.4.5.7
enable ica-multi-stream
Syntax: enable ica-multi-stream Enables protocol acceleration for ICA multi-stream connections
9.4.5.8
disable ica-multi-stream
Syntax: disable ica-multi-stream Disables protocol acceleration for ICA multi-stream connections
9.4.5.9
show system-status
Syntax: show system-status Displays the same information as the Web UIs Status page.
9.4.6
9.4.6.1
IP Address Configuration
show dns-server
Syntax: show dns-server Displays the currently defined DNS server.
9.4.6.2
set dns-server
Syntax: set dns-server ipaddr Sets the IP address of the DNS server. The unit uses a single DNS server for all DNS requests.
9.4.6.3
show hostname
Syntax: show hostname Displays the currently defined hostname for the appliance.
9.4.6.4
set hostname
Syntax: set hostname name Sets the appliances hostname to name.
9.4.6.5
show adapter
Syntax: show adapter [{apa, apb, primary, aux1}]
9-9
Shows the status and IP settings of all adapters, or, optionally, a single specified adapter. The information is the same as in the Web UIs IP Address page.
9.4.6.6
set adapter
Syntax: set adapter {apa, apb, primary, aux1} [-status {enable, disable}] [-ip addr] [-netmask mask] [-gateway gwaddr] [-ha-vip addr] [-vlan {enable, disable}] [-vlan-group groupnumber] [-web-management {enable, disable}] [-ssh-management {enable, disable}] Sets the parameters of the specified adapter. These are the same parameters used on the Web UIs IP Address page. Valid VLAN group numbers range from 1 to 4094.
9.4.7
9.4.7.1
Ethernet Configuration
set interface
Syntax: set interface -adapter {apa.1, apa.2, apb.1, apb.2, primary, aux1} -speed-duplex {auto, 1000full, 100full, 100half, 10full, 10half} Sets the speed and duplex parameters for the specified Ethernet port.
9.4.7.2
show interface
Syntax: show interface [-adapter {apa.1, apa.2, apb.1, apb.2, primary, aux1}] Displays the Ethernet speed and duplex settings of all Ethernet ports, or, optionally, a single specified port.
9.4.8
9.4.8.1
Bandwidth Configuration
show bandwidth
Syntax: show bandwidth Displays the bandwidth limits and other information from the Web UIs Bandwidth Management page.
9-10
June 26, 2011
9.4.8.2
set bandwidth
Syntax: set bandwidth [-mode {hardboost, softboost}] [-send-limit kbps] [-receive-limit kbps] Sets the bandwidth limits and other bandwidth management settings. These parameters are the same as those on the Web UIs Bandwidth Management page. The -schedule and -per-remote-unit settings are meaningful only with hardboost. The -min-rate setting is meaningful only with partial bandwidth.
9.4.9
9.4.9.1
Link Configuration
show links
Syntax: show links [-verbose] Displays all of the currently defined links. The verbose parameter if specified will output a detailed listing of the settings for each link being displayed.
9.4.9.2
show link
Syntax: show link -name name Displays a detailed listing of the settings for the link specified by the name parameter.
9.4.9.3
rename link
Syntax: rename link -old oldname -new newname Renames the specified link.
9.4.9.4
remove link
Syntax: remove link {-all, -name name} Deletes either the named link or all links.
9.4.9.5
remove link-filter
Syntax: remove link-filter -link name {-all, -filter-position number} Removes either all link filters for the specified link or the filter at the position specified by number.
Valid filter positions range from 1 to N (where N is the number of filters in the current list).
9.4.9.6
move link
Syntax: move link -name name { -direction {up, down} -count count, -position {bottom, top, number} } Moves the named link either relative to the current position (using the direction parameter) or absolutely (using the position parameter). Valid integer positions range from 1 to N (where N is the number of links in the current list).
9.4.9.7
add link
Syntax: add link [-position {bottom, top, number}] -name name -type {LAN, WAN} -max-in-bandwidth rate [{bps, kbps, mbps, gbps}] -max-out-bandwidth rate [{bps, kbps, mbps, gbps}] {-match-all-traffic, filter-criteria-list} where filter-criteria-list is [-adapters ([-exclude] adapter-name),...] [-source-ips ([-exclude] ip),...] [-destination-ips ([-exclude] ip),...] [-vlans ([-exclude] vlan),...] [-wccp-service-groups ([-exclude] id),...] [-source-macs ([-exclude] mac),...] [-destination-macs ([-exclude] mac),...] Creates a new link with the specified name, type, bandwidth rates and a single filter rule which can be either a match all traffic type rule or a rule based upon the criteria specified for adapters, source ips, destination ips, vlans, wccp service groups, source macs and destination macs. Double quotes can be used as delimiters for the link name (which may contain spaces). If no position parameter is specified, the new link will be inserted at the top of the current list of links. Valid position arguments are top, bottom or a number in the range from 1 to N (where N is the number of links in the current list). To add an entry to the bottom of the list specify bottom.
9-12
June 26, 2011
The units for the bandwidth rate will default to mbps if nothing is specified. Bandwidth rates must be at least 56 kbps and cannot exceed 1 gbps. If the match all traffic filter rule is not specified, then at least one filter criteria option must be specified. VLANs are specified by VLAN group numbers which range from 1 to 4094. WCCP service group values range from 51 to 99. MAC addresses should be entered as 2 digit hex terms separated by -s, for example, 00-0C-F1-56-98-AD.
9.4.9.8
add link-filter
Syntax: add link-filter -link name [-filter-position {bottom, top, number}] [-adapters ([-exclude] adapter-name),...] [-source-ips ([-exclude] ip),...] [-destination-ips ([-exclude] ip),...] [-vlans ([-exclude] vlan),...] [-wccp-service-groups ([-exclude] id),...] [-source-macs ([-exclude] mac),...] [-destination-macs ([-exclude] mac),...] Creates a new link filter in the link specified by the name parameter. If no filter position parameter is specified, the new filter will be inserted at the bottom of the current list of filters. If a filter position is specified, then the new filter will be inserted at that position in the list. Valid integer positions range from 1 to N (where N is the number of filters in the list). For the adapters, source-ips, destination-ips, vlans, wccp-service-groups, source-macs, and destination-macs parameters, if a setting is not provided, then any value for these fields will be considered a match. All of these parameters provide the ability to specify a comma separated list of items. Each item may indicate that instead of a match operation on the item being performed that an exclude operation is done instead. VLANs are specified by VLAN group numbers which range from 1 to 4094. WCCP service group values range from 51 to 99. MAC addresses should be entered as 2 digit hex terms separated by -s, for example, 00-0C-F1-56-98-AD.
9.4.9.9
set link
Syntax: set link -name name [-type {LAN, WAN}] [-max-in-bandwidth rate [{bps, kbps, mbps, gbps}]] [-max-out-bandwidth rate [{bps, kbps, mbps, gbps}]]
9-13
Changes the definition of an existing link. Double quotes can be used as delimiters for the link name (which may contain spaces). At least one of the link attributes must be set. The units for the bandwidth rate will default to mbps if nothing is specified. Bandwidth rates must be at least 56 kbps and cannot exceed 1 gbps.
9.4.9.10
set link-filter
Syntax: set link-filter -link name -filter-position number {-match-all-traffic, filter-criteria-list} where filter-criteria-list is [-adapters {match-all, ([-exclude] adapter-name),...]} [-source-ips {match-all, ([-exclude] ip),...]} [-destination-ips {match-all, ([-exclude] ip),...]} [-vlans {match-all, ([-exclude] vlan),...]} [-wccp-service-groups {match-all, ([-exclude] id),...]} [-source-macs {match-all, ([-exclude] mac),...]} [-destination-macs {match-all, ([-exclude] mac),...]} Change the definition of the existing link filter specified by the name and filter-position parameters. Multiple filter settings may be changed at once and the other settings will be left unchanged. At least one of the link filter attributes must be set. Valid filter positions range from 1 to N (where N is the number of filters in the list). VLANs are specified by VLAN group numbers which range from 1 to 4094. WCCP service group values range from 51 to 99. MAC addresses should be entered as 2 digit hex terms separated by -s, for example, 00-0C-F1-56-98-AD.
9.4.10 Service Class Configuration

9.4.10.1 show service-classes
Syntax: show service-classes [{-modified-only, -names name,...}] [-verbose] Displays either all the currently defined service classes, only the modified ones, or only the ones with names that have been requested. The verbose parameter if specified will output a detailed listing of the settings for each service class being displayed.
9.4.10.2
show service-class
Syntax: show service-class

9-14 June 26, 2011
-name name Displays a detailed listing of the settings for the service class specified by the name parameter.
9.4.10.3
enable service-class
Syntax: enable service-class -name name Enables the service class specified by the name parameter. By default newly created service classes are disabled so that filter rules can be added.
9.4.10.4
disable service-class
Syntax: disable service-class -name name Disables the service class specified by the name parameter. Disabled service classes will not match any connections and therefore will not provide any acceleration.
9.4.10.5
rename service-class
Syntax: rename service-class -old oldname -new newname Renames the specified service class.
9.4.10.6
remove service-class
Syntax: remove service-class {-all, -name name} Deletes either the named service class or all service classes.
9.4.10.7
remove service-class-filter
Syntax: remove service-class-filter -service-class name {-all, -filter-position number} Removes either all filters for the specified service class or the filter at the position specified by number. Valid filter positions range from 1 to N (where N is the number of filters in the list).
9.4.10.8
move service-class
Syntax: move service-class -name name { -direction {up, down} -count count, -position {bottom, top, number} }
Moves the named service class either relative to the current position (using the direction parameter) or absolutely (using the position parameter). Valid integer positions range from 1 to N (where N is the number of service classes in the list).
9.4.10.9
add service-class
Syntax: add service-class [-position {bottom, top, number}] -name name -acceleration {disk, flow-control, memory, none} -traffic-shaping-policy {default, policy-name} [-per-link-policies (link-name policy-name),...] Creates a new service class with the specified acceleration type and traffic shaping policy. Double quotes can be used as delimiters for the service class name (which may contain spaces). A newly added service class will always be created in a disabled state and must have at least one service class filter added to it before it can be enabled. If no position parameter is specified, the new service class will be inserted at the top of the current list of service classes. Valid integer positions range from 1 to N (where N is the number of service classes in the list). The specified traffic shaping policy will be used for this service class on all links. Per-link traffic shaping policies only need to be specified for links which have a traffic shaping policy that is different for this service class than the policy specified by the -traffic-shaping-policy setting.
9.4.10.10
add service-class-filter
Syntax: add service-class-filter -service-class name [-filter-position {bottom, top, number}] [-bidirectional {enable, disable}] [-applications ([-exclude] name),...] [-source-ips ([-exclude] ip),...] [-destination-ips ([-exclude] ip),...] [-diffserv-dscps ([-exclude] dscp),...] [-vlans ([-exclude] vlan),...] [-ssl-profiles ([-exclude] profile),...]
9-16
June 26, 2011
Creates a new service class filter in the service class specified. If no filter position parameter is specified, the new filter will be inserted at the bottom of the current list of filters. If a filter position is specified, then the new filter will be inserted at that position in the list. Valid integer positions range from 1 to N (where N is the number of filters in the list). If the bi-directional parameter is enabled then the filter will also match connection setup messages that have a source IP address that matches the filters destination-ips setting and a destination IP address that matches the filters source-ips setting. Please note that this setting only applies to which connections can be accelerated, it does not apply to traffic shaping. For the applications, source-ips, destination-ips, diffserv-dscps and vlans parameters, if a setting is not provided, then any value for these fields will be considered a match. All of these parameters provide the ability to specify a comma separated list of items. Each item may indicate that instead of a match operation on the item being performed that an exclude operation is done instead. Valid DiffServ DSCP values range from 0 to 63. VLANs are specified by VLAN group numbers which range from 1 to 4094. SSL profile names which are specified must already be configured in the system or they will be rejected. At least one ssl profile name must be configured in the ssl-profiles parameter for SSL connections to be matched.
9.4.10.11
set service-class
Syntax: set service-class -name name [-acceleration {disk, flow-control, memory, none}] [-traffic-shaping-policy {default, policy}] [-per-link-policies (link-name policy-name),...] Changes the definition of an existing service class. Double quotes can be used as delimiters for the service class name (which may contain spaces). At least one of the service class attributes must be set. The specified traffic shaping policy will be used for this service class on all links. Per-link traffic shaping policies only need to be specified for links which have a traffic shaping policy that is different for this service class than the policy specified by the -traffic-shaping-policy setting.
9.4.10.12
set service-class-filter
Syntax: set service-class-filter -service-class name -filter-position number {-match-all-traffic, filter-criteria-list} where filter-criteria-list is [-bidirectional {enable, disable}]
[-applications {match-all, ([-exclude] name),...}] [-source-ips {match-all, ([-exclude] ip),...}] [-destination-ips {match-all, ([-exclude] ip),...}] [-diffserv-dscps {{match-all, ([-exclude] dscp),...}] [-vlans {match-all, ([-exclude] vlan),...}] [-ssl-profiles {disable, ([-exclude] profile),...}] Change the definition of the existing service class filter rule specified by the name and filter-position parameters. Valid filter positions range from 1 to N (where N is the number of filters in the current list). Multiple filter settings may be changed at once and the other settings will be left unchanged. At least one of the service class filter attributes must be set. If the bi-directional parameter is enabled then the filter will also match connection setup messages that have a source IP address that matches the filters destination-ips setting and a destination IP address that matches the filters source-ips setting. Please note that this setting only applies to which connections can be accelerated, it does not apply to traffic shaping. Valid DiffServ DSCP values range from 0 to 63. VLANs are specified by VLAN group numbers which range from 1 to 4094. SSL profile names which are specified must already be configured in the system or they will be rejected.
9.4.11 Traffic Shaping Configuration

9.4.11.1 show traffic-shaping-policies
Syntax: show traffic-shaping-policies Displays the summary list of traffic shaping policies.
9.4.11.2
show traffic-shaping-policy
Syntax: show traffic-shaping-policy {-all, -id id, -name name} Displays the detail information of one or all traffic shaping policies.
9.4.11.3
add traffic-shaping-policy
Syntax: add traffic-shaping-policy -name name -priority integer [-ica-realtime-priority integer] [-ica-interactive-priority integer] [-ica-bulk-transfer-priority integer] [-ica-background-priority integer] [-optimize-voice {enable, disable}]
9-18 June 26, 2011
[-diffserv {integer, disabled}] [-ica-realtime-diffserv {integer, disabled}] [-ica-interactive-diffserv {integer, disabled}] [-ica-bulk-transfer-diffserv {integer, disabled}] [-ica-background-diffserv {integer, disabled}] [-limit-bandwidth {by-percent, by-rate} -max-in integer -max-out integer] Add a new traffic shaping policy. Double quotes can be used as delimiters for the name (which may contain spaces). Valid priority values range from 1 to 256. DiffServ values are specified by DSCP codes which range from 0 to 63. Bandwidth may be limited by percent which can range from 1 to 99 or by kbps rate which can range from 56 to 1000000.
9.4.11.4
set traffic-shaping-policy
Syntax: set traffic-shaping-policy -name name -priority integer [-ica-priorities {enable, disable}] [-ica-realtime-priority integer] [-ica-interactive-priority integer] [-ica-bulk-transfer-priority integer] [-ica-background-priority integer] [-optimize-voice {enable, disable}] [-diffserv {integer, disabled}] [-ica-diffserv {enable, disable}] [-ica-realtime-diffserv {integer, disabled}] [-ica-interactive-diffserv {integer, disabled}] [-ica-bulk-transfer-diffserv {integer, disabled}] [-ica-background-diffserv {integer, disabled}] [-limit-bandwidth {by-percent, by-rate} -max-in integer -max-out integer] Modify an existing traffic shaping policy. Double quotes can be used as delimiters for the name (which may contain spaces). Valid priority values range from 1 to 256. DiffServ values are specified by DSCP codes which range from 0 to 63. Bandwidth may be limited by percent which can range from 1 to 99 or by kbps rate which can range from 56 to 1000000.
9-19
9.4.11.5
rename traffic-shaping-policy
Syntax: rename traffic-shaping-policy -old oldname -new newname Renames the specified traffic shaping policy.
9.4.12 remove traffic-shaping-policy

Syntax: remove traffic-shaping-policy {-all, -name name} Remove one or all traffic shaping policies. Some traffic shaping policies (e.g. Default Traffic Shaping Policy) are not permitted to be removed.
9.4.12.1
clear traffic-shaping-policy-stats
Syntax: clear traffic-shaping-policy-stats Resets all traffic shaping policy performance counters.
9.4.13 SNMP Configuration

9.4.13.1 show snmp
Syntax: show snmp Reports then enabled/disabled status of the SNMP feature.
9.4.13.2
enable snmp
Syntax: enable snmp Enables the SNMP feature.
9.4.13.3
disable snmp
Syntax: disable snmp Disables the SNMP feature.
9.4.13.4
show snmp-system-mib
Syntax: show snmp-system-mib Displays the current name, location, contact, and authentication failure trap settings.
9.4.13.5
set snmp-system-mib
Syntax: set snmp-system-mib [-name name] [-location location] [-contact name] [-auth-fail-trap {enable, disable}]
9-20 June 26, 2011
Sets the SNMP name of the appliance, its location, the contact persons name, and whether to enable authentication failure traps. Double quotes can be used as delimiters for string fields (which may contain spaces).
9.4.13.6
show snmp-manager
Syntax: show snmp-manager [-id id] Displays the current SNMP manager entries. If -id is specified, only that SNMP manager is displayed.
9.4.13.7
add snmp-manager
Syntax: add snmp-manager -community name -ip addr [-netmask {0, 4, 8, 12, 16, 20, 24, 28, 32}] Enables access to SNMP functions by remote systems on the specified subnets and with the specified community name. Double quotes can be used as delimiters for string fields (which may contain spaces).
9.4.13.8
remove snmp-manager
Syntax: remove snmp-manager {-all, -id number} Syntax: remove snmp-manager -community name -ip addr [-netmask {0, 4, 8, 12, 16, 20, 24, 28, 32}] Removes the specified SNMP manager entry, or all SNMP manager entries. Double quotes can be used as delimiters for string fields (which may contain spaces).
9.4.13.9
-id id
show snmp-trapdest
Syntax: show snmp-trapdest Displays the SNMP trap destination entry at position id.
9.4.13.10
add snmp-trapdest
Syntax: add snmp-trapdest -name name -ip addr [-port port] [-version {v1, v2c}]
Adds a new SNMP trap destination. Double quotes can be used as delimiters for string fields (which may contain spaces).
9.4.13.11
remove snmp-trapdest
Syntax: remove snmp-trapdest {-all, -name name, -id id} Removes the SNMP trap destination define by name or ID, or all SNMP trap destinations. Double quotes can be used as delimiters for string fields (which may contain spaces).
9.4.14 Alert Configuration

9.4.14.1 show alert-configuration
Syntax: show alert-configuration [-name alertname] Syntax: show alert-configuration -retention Displays the settings of the Alert system, or optionally of a single, named Alert. Equivalent to the information on the Alert Configuration page. With -retention, the Alert Retention Time is displayed.
9.4.14.2
set alert-configuration
Syntax: set alert-configuration {-retention seconds , -verbose {enable, disable}} Syntax: set alert-configuration -name name -level {alerted, logged, disable, default} [-threshold integer] Sets parameters for individual, named Alerts, or sets global parameters. Equivalent to the Alert Configuration page. The -retention option sets the alert timeout value in seconds, while the -verbose option allows verbose or non-verbose reporting to be selected. The -threshold option is used to specify alerting thresholds. Not all alerts support a threshold.
9.4.14.3
reset alert-configuration
Syntax: reset alert-configuration Sets all Alerts to factory defaults.
9.4.15 Alert Management

9.4.15.1 clear alert
Syntax: clear alert
9-22 June 26, 2011
{-all, -id id} This command will clear an alert, or all alerts if -all is specified.
9.4.15.2
show alerts
Syntax: show alerts This command will show the current alerts.
9.4.16 WCCP Configuration

9.4.16.1 show wccp
Syntax: show wccp [-id id] Displays the current settings for all WCCP service groups, or optionally only for the service group specified with -id.
9.4.16.2
enable wccp
Syntax: enable wccp Global WCCP enable. Not effective unless acceleration is enabled and at least one WCCP service group is defined.
9.4.16.3
disable wccp
Syntax: disable wccp Global WCCP disable.
9.4.16.4
add wccp
Adds a new WCCP service-group definition. The parameters are the same as those on the WCCP Configuration page on the Web UI. Syntax: add wccp -id id [-accelerated-pair {apa, apb}] -router-communication unicast -address addr1[,...,addrN] [-router-assignment {hash, mask, auto}] [-router-forwarding {auto, gre, level-2}] [-state {enable, disable}] [-priority number] [-protocol {tcp, udp}] Syntax: add wccp -id id
[-accelerated-pair {apa, apb}] -router-communication multicast -address addr [-router-assignment {hash, mask, auto}] [-router-forwarding {auto, gre, level-2}] [-router-return {auto, gre, level-2}] [-time-to-live number] [-state {enable, disable}] [-priority number] [-protocol {tcp, udp}] Default values for the optional parameters are as follows: -accelerated-pair = apa -router-assignment = hash -router-forwarding = auto -router-return -time-to-live -state -priority -protocol = auto =1 = enable =0 = tcp
9.4.16.5
-id id
set wccp
Syntax: set wccp [-accelerated-pair {apa, apb}] [ -router-communication unicast -address addr1[,...,addrN] ] [-router-assignment {hash, mask, auto}] [-router-forwarding {auto, gre, level-2}] [-state {enable, disable}] [-priority number] [-protocol {tcp, udp}] Syntax: set wccp -id id
9-24 June 26, 2011
[-accelerated-pair {apa, apb}] [ -router-communication multicast -address addr ] [-router-assignment {hash, mask, auto}] [-router-forwarding {auto, gre, level-2}] [-router-return {auto, gre, level-2}] [-time-to-live number] [-state {enable, disable}] [-priority number] [-protocol {tcp, udp}] Alters an existing WCCP service-group definition. The parameters are the same as those on the WCCP Configuration page on the Web UI.
9.4.16.6
remove wccp
Syntax: remove wccp {-all , -id num} Deletes all WCCP service groups or (with -id) only the specified service group number.
9.4.17 Logging
9.4.17.1 show syslog
Syntax: show syslog Displays the current syslog parameters.
9.4.17.2
set syslog
Syntax: set syslog -ip addr [-port port] Sets the IP address of the syslog server, and optionally the port number.
9.4.17.3
enable syslog
Syntax: enable syslog Enables syslog logging.
9.4.17.4
disable syslog
Syntax: disable syslog
9-25
Disable syslog logging.
9.4.17.5
[-stats]
show log
Syntax: show log [-options] Shows the current logfile configurations and disk usage statistics. With -stats, only the usage statistics are shown. With -options, only the configuration is shown. The information here is equivalent to the Log Configuration page in the Web UI.
9.4.17.6
set log
Syntax: set log [-max-size megabytes] [-display-lines lines] [-max-export-lines lines] [-system {enable, disable}] [-adapter {enable, disable}] [-flow {enable, disable}] [-connection {enable, disable}] [-openclose {enable, disable}] [-text {enable, disable}] [-alert {enable, disable}] Sets the display parameters for the View Logs page. The settings here correspond to those on the Configure Logs page.
9.4.17.7
extract log
Syntax: extract log -by-record -from number -to number -records number -format {text, xml} -type {system, adapter, slow-flow, fast-flow, flow, connection, open, close, open-close, text, alert, all} -eol {lf, crlf, cr} [-file filename] Syntax: extract log
9-26 June 26, 2011
-by-datetime -from yyyy-mm-dd [hh:mm[:ss]] -to yyyy-mm-dd [hh:mm[:ss]] -records number -format {text, xml} -type {system, adapter, slow-flow, fast-flow, flow, connection, open, close, open-close, text, alert, all} -eol {lf, crlf, cr} [-file filename] Extracts the selected records to file filename. This command has the same parameters as that on the View Logs page on the Web UI.
9.4.17.8
clear logs
Syntax: clear logs Removes all log records, similar to the Remove All Log Records button in the Web UI.
9.4.17.9
list log-extracted-files
Syntax: list log-extracted-files Displays a list of log files saved by the extract log command.
9.4.18 Proxy Configuration

9.4.18.1 show proxy
Syntax: show proxy Displays the current proxy definitions.
9.4.18.2
add proxy
Syntax: add proxy -local local vipaddr -target {target ipaddr, host) [-description description] Adds a new proxy definition. This command has the same parameters as that on the Proxy page on the Web UI.
9.4.18.3
remove proxy
Syntax: remove proxy {-all, -local vipaddr}
9-27
Removes a proxy definition. -local specifies which proxy definition to remove. -all specifies that all proxy definitions should be removed.
9.4.19 Client Configuration

9.4.19.1 show client-rule
Syntax: show client-rule [-id id] Displays a client acceleration rule. If -id is omitted, all client rules are displayed.
9.4.19.2
add client-rule
Syntax: add client-rule -type {accelerate, exclude} -subnet {*, subnet} -ports {*, port-range} Adds a client acceleration rule. This command has the same parameters as those on the Client Acceleration Rules page of the Web UI.
9.4.19.3
remove client-rule
Syntax: remove client-rule {-all, -id id} Removes a client acceleration rule. -id specifies which rule to remove. -all specifies that all rules should be removed.
9.4.19.4
show signaling-channel
Syntax: show signaling-channel Displays the Client Signaling Channel options.
9.4.19.5
enable signaling-channel
Syntax: enable signaling-channel Enables the Client Signaling Channel.
9.4.19.6
disable signaling-channel
Syntax: disable signaling-channel Disables the Client Signaling Channel.
9.4.19.7
set signaling-channel
Syntax: set signaling-channel [-ip ipaddr] [-port port] [-mode {redirector, transparent}]
9-28 June 26, 2011
Sets the Client Signaling Channel options. This command has the same parameters as those on the Client Signaling Channel Configuration page of the Web UI.
9.4.19.8
show client-settings
Syntax: show client-settings Displays the Client General Configuration options.
9.4.19.9
set client-settings
Syntax: set client-settings [-upgrade-notify {enable, disable}] [-upgrade-url url] [-diag-ftp-server server] [-diag-ftp-port port] [-diag-ftp-user user] [-diag-ftp-password password] [-diag-ftp-directory directory] [-diag-email email] [-diag-popups {enable, disable}] [-diag-uploads {enable, disable}] Sets the Client General Configuration options. This command has the same parameters as those on the Client General Configuration page of the Web UI.
9.4.20 Group Mode Configuration

9.4.20.1 show group-mode
Syntax: show group-mode [-type {local, peers, rules}] Displays the group mode configuration.
9.4.20.2
enable group-mode
Syntax: enable group-mode Enables group mode. Syntax: enable group-mode -type peer -member-ip ipaddr Enables a group mode peer. -member-ip specifies which peer to enable. Syntax: enable group-mode -type rule
{-all, -id id} Enables a group forwarding rule. -id specifies which rule to enable. -all specifies that all rules should be enabled.
9.4.20.3
disable group-mode
Syntax: disable group-mode Disables group mode. Syntax: disable group-mode -type peer -member-ip ipaddr Disables a group mode peer. -member-ip specifies which peer to disable. Syntax: disable group-mode -type rule {-all, -id id } Disables a group forwarding rule. -id specifies which rule to disable. -all specifies that all rules should be disabled.
9.4.20.4
set group-mode
Syntax: set group-mode [-accelerate-with-failure {enable, disable}] [-forward-loop-prevention {enable, disable}] Enables or disables group mode options. This command has the same parameters as that on the Group Mode page on the Web UI. Syntax: set group-mode -type local -adapter {apa, apb, primary} Sets the adapter parameter of the local group mode. This command has the same parameters as that on the Group Mode page on the Web UI.
9.4.20.5
add group-mode
Syntax: add group-mode -type peer -member-ip ipaddr -state {enable, disable} -common-name name [-ha-common-name name] Adds a group mode peer. This command has the same parameters as that on the Group Mode page on the Web UI.
9-30 June 26, 2011
Syntax: add group-mode -type rule -member-ip ipaddr -subnet subnet -ports port-range [-forwarded-if {match, not-match}] [-state {enable, disable}] Adds a group forwarding rule. This command has the same parameters as that on the Group Mode page on the Web UI.
9.4.20.6
remove group-mode
Syntax: remove group-mode -type peer {-all, -member-ip ipaddr} Removes a group mode peer. -member-ip specifies which peer to remove. -all specifies that all peers should be removed. Syntax: remove group-mode -type rule {-all, -id id} Removes a group forwarding rule. -id specifies which rule to remove. -all specifies that all rules should be removed.
9.4.21 SSL Configuration

9.4.21.1 add ssl-profile
Syntax: add ssl-profile -name profile-name [-state {enable, disable}] -proxy-type transparent [-virtual-hostname hostname] -private-key private-key-name Adds an SSL profile for transparent proxy mode. This command has the same parameters as that on the Profile tab of the SSL Settings page on the Web UI. Syntax: add ssl-profile -name profile-name [-state {enable, disable}] -proxy-type split
9-31
[-virtual-hostname hostname] -cert-key cert-key-pair-name [-build-cert-chain {enable, disable}] [-cert-chain-store {use-all-configured-CA-stores, store-name}] [-cert-verification {none, Signature/Expiration, Signature/Expiration/ Common-Name-White-List, Signature/Expiration/Common-Name-Black-List}] [-verification-store {use-all-configured-CA-stores, store-name}] [-server-side-protocol {SSL-version-2, SSL-version-3, SSL-version-2-3-OR-TLS-1.0, TLS-1.0}] [-server-side-ciphers ciphers] [-server-side-authentication {enable, disable}] [-server-side-cert-key cert-key-pair-name] [-server-side-build-cert-chain {enable, disable}] [-server-side-renegotiation {disable-old-style, enable-old-style, new-style, compatible}] [-client-side-protocol-version {SSL-version-2, SSL-version-3, SSL-version-2-3-OR-TLS-1.0, TLS-1.0}] [-client-side-ciphers ciphers] [-client-side-renegotiation {disable-old-style, enable-old-style, new-style, compatible}] Adds an SSL profile for split proxy mode. This command has the same parameters as that on the Profile tab of the SSL Settings page on the Web UI.
9.4.21.2
set ssl-profile
Syntax: set ssl-profile -name profile-name [-state {enable, disable}] [-proxy-type transparent] [-virtual-hostname hostname] [-private-key private-key-name] Modifies an SSL profile created for transparent proxy mode. Syntax: set ssl-profile -name profile-name [-state {enable, disable}] [-proxy-type split] [-virtual-hostname hostname] [-cert-key cert-key-pair-name]
9-32 June 26, 2011
[-build-cert-chain {enable, disable}] [-cert-chain-store {use-all-configured-CA-stores, store-name}] [-cert-verification {none, Signature/Expiration, Signature/Expiration/ Common-Name-White-List, Signature/Expiration/Common-Name-Black-List}] [-verification-store {use-all-configured-CA-stores, store-name}] [-server-side-protocol {SSL-version-2, SSL-version-3, SSL-version-2-3-OR-TLS-1.0, TLS-1.0}] [-server-side-ciphers ciphers] [-server-side-authentication {enable, disable}] [-server-side-cert-key cert-key-pair-name] [-server-side-build-cert-chain {enable, disable}] [-server-side-renegotiation {disable-old-style, enable-old-style, new-style, compatible}] [-client-side-protocol-version {SSL-version-2, SSL-version-3, SSL-version-2-3-OR-TLS-1.0, TLS-1.0}] [-client-side-ciphers ciphers] [-client-side-renegotiation {disable-old-style, enable-old-style, new-style, compatible}] Modifies an SSL profile created for split proxy mode.
9.4.21.3
show ssl-profiles
Syntax: show ssl-profiles Shows name, profile type, and state of all SSL profiles created.
9.4.21.4
show ssl-profile
Syntax: show ssl-profile {-id id, -name profile-name} Show profile detail by id or profile name.
9.4.21.5
remove ssl-profile
Syntax: remove ssl-profiles {-all, -id id, -name profile-name} Removes SSL profile. -id and -name specifies which profile to remove. -all specifies that all profiles are to be removed.
9.4.21.6
rename ssl-profile
Syntax: rename ssl-profiles -old old-profile-name -new new-profile-name

Changes an SSL profile name.
9.4.21.7
show ssl-optimization
Syntax: show ssl-optimization Shows SSL optimization status.
9.4.21.8
enable ssl-optimization
Syntax: enable ssl-optimization Enables SSL optimization feature.
9.4.21.9
disable ssl-optimization
Syntax: disable ssl-optimization Disables SSL optimization feature.
9.4.21.10
show ssl-secure-peer-connections
Syntax: show ssl-secure-peer-connections Shows SSL peer configuration.
9.4.21.11
show ssl-ca-store
Syntax: show ssl-ca-store -name ca-store-name Shows detail information on the SSL CA certificate.
9.4.21.12
show ssl-ca-stores
Syntax: show ssl-ca-stores Shows summary information (name, expiration date, certificate count) on all SSL Cetificate Authority certificates.
9.4.21.13
show ssl-cert-key-pair
Syntax: show ssl-cert-key-pair -name cert-key-pair-name Shows detail information on the SSL certificate/key pair.
9.4.21.14
show ssl-cert-key-pairs
Syntax: show ssl-cert-key-pairs Shows summary information (name, expiration date, certificate count, key type) on all configured SSL certificate/key pairs.
9.4.21.15
show ssl-disk-encryption
Syntax: show ssl-disk-encryption Shows user data store encryption status

9-34 June 26, 2011
9.4.21.16
show ssl-keystore
Syntax: show ssl-keystore Shows encryption key store status.
9.4.21.17
show ssl-peer-auto-discovery
Syntax: show ssl-peer-auto-discovery Shows SSL peer auto-discovery configuration.
9.4.21.18
show ssl-peer-connect-to
Syntax: show ssl-peer-connect-to Shows SSL peer connect to configuration.
9.4.21.19
show ssl-peer-listen-on
Syntax: show ssl-peer-listen-on Shows SSL peer listen on configuration.
9.4.21.20
add ssl-ca-store
Syntax: add ssl-ca-store [-name name] -file ca-certificate-filename Adds an SSL CA certificate store.
9.4.21.21
remove ssl-ca-store
Syntax: remove ssl-ca-store -name name Removes an SSL CA certificate store.
9.4.21.22
add ssl-cert-key-pair
Syntax: add ssl-cert-key-pair -name certificate/key-pair-name {(-type combined -file certificate/key-pair-filename), (-type separate -key-file key-filename -cert-file cert-filename)} [-key-password password] [-file-password password] Adds an SSL certificate authority certificate store.
9-35
9.4.21.23
remove ssl-cert-key-pair
Syntax: remove ssl-cert-key-pair -name certificate/key-pair-name Removes an SSL certificate authority certificate store.
9.4.21.24
add ssl-peer-auto-discovery-publish-item
Syntax: add ssl-peer-auto-discovery-publish-item -ip-port ipaddr:port Publishes a NAT IP address/port entry.
9.4.21.25
remove ssl-peer-auto-discovery-publish-item
Syntax: remove ssl-peer-auto-discovery-publish-item {-all, -ip-port ipaddr:port} Removes one or all NAT IP address/port entries.
9.4.21.26
add ssl-peer-connect-to-item
Syntax: add ssl-peer-connect-to-item -ip-port ipaddr:port Adds an SSL peer IP address/port to be connected to.
9.4.21.27
remove ssl-peer-connect-to-item
Syntax: remove ssl-peer-connect-to-item {-all, -ip-port ipaddr:port} Removes one or all SSL peer IP address/port entries.
9.4.21.28
add ssl-peer-listen-on-item
Syntax: add ssl-peer-listen-on-item -ip-port ipaddr:port Adds an SSL peer listen on Repeater IP address/port.
9.4.21.29
remove ssl-peer-listen-on-item
Syntax: remove ssl-peer-listen-on-item {-all, -ip-port ipaddr:port} Removes one or all SSL peer listen on Repeater IP address/port entries.
9.4.21.30
add ssl-secure-peer-connections-item
Syntax: add ssl-secure-peer-connections-item -cert-verification Signature/Expiration/Common-Name-Black-List -item black-list-item

9-36 June 26, 2011
Adds an additional SSL peer security black list item. The first black list item was configured with the set ssl-secure-peer-connections command. Syntax: add ssl-secure-peer-connections-item -cert-verification Signature/Expiration/Common-Name-White-List -item white-list-item Adds an additional SSL peer security white list item. The first white list item was configured with the set ssl-secure-peer-connections command.
9.4.21.31
remove ssl-secure-peer-connections-item
Syntax: remove ssl-secure-peer-connections-item {-all, -item list-item} Removes one or all SSL peer security white list or black list entries.
9.4.21.32
set ssl-cert-key-pair
Syntax: set ssl-cert-key-pair -name certificate/key-pair-name -action {add|replace} -cert-key {DSA|RSA} {(-type combined -file certificate/key-pair-filename), (-type separate -key-file key-filename -cert-file cert-filename)} [-key-password password] [-file-password password] Adds or replaces a DSA/RSA certificate/key.
9.4.21.33
set ssl-keystore
Syntax: set ssl-keystore -password new-password -old-password old-password
9.4.21.34
set ssl-secure-peer-connections
Syntax: set ssl-secure-peer-connections -cert-key-name cert-key-name -ca-cert-store ca-cert-store-name -cert-verification {None,Signature} -cipher ssl-cipher-specification
Specifies the SSL peer configuration. Syntax: set ssl-secure-peer-connections -cert-key-name cert-key-name -ca-cert-store ca-cert-store-name -cert-verification Signature/Expiration/Common-Name-Black-List -item black-list-item-1 -cipher ssl-cipher-specification Specifies the SSL peer configuration, where peer security ceritficate verification is a black list. The first black list entry is specified here, additional entries may be added using the add ssl-secure-peer-connections-item command. Syntax: set ssl-secure-peer-connections -cert-key-name cert-key-name -ca-cert-store ca-cert-store-name -cert-verification Signature/Expiration/Common-Name-White-List -item white-list-item-1 -cipher ssl-cipher-specification Specifies the SSL peer configuration, where peer security ceritficate verification is a white list. The first white list entry is specified here, additional entries may be added using the add ssl-secure-peer-connections-item command.
9.4.22 Test Mode commands

9.4.22.1 clear compression-stats
Syntax: clear compression-stats This command will clear the compression statistics, similar to the Clear button in the Compression Status section of the Web UI.
9.4.22.2
clear compression-history
Syntax: clear compression-history This command will reset the compression history content, similar to a Compressionhistory content_reset command given to console.php.
9.4.22.3
show object
Syntax: show object -class class [-name name] This command shows the current value of a parameter or system object.
9.4.22.4
set object
Syntax: set object -class class -name name -value value This command sets the value of a parameter or system object.
9-38
June 26, 2011
9.4.23 Alert Configuration

9.4.23.1 clear application-counters
Syntax: clear application-counters Resets all application performance counters.
9.4.23.2
show applications
Syntax: show applications This command shows the list of configured applications
9.4.23.3
show application
Syntax: show application {-all, -name name, -id id, -group application group} This command shows the configuration information of the selected application. The parameter -id selects the application listed on the show applications output.
9.4.23.4
add application
Syntax: add application -name name [-description description] [-group application group] [-classification-type ethertype, ica-published-app, ip, tcp, udp, web-address] [-classification-parameters classification parameters] This command creates a new application.
9.4.23.5
rename application
Syntax: show application -old old-application-name -new new-application-name This command changes the application name.
9.4.23.6
remove application
Syntax: remove application {-all, -name name} This command removes the configured application.
9.4.23.7
set application
Syntax: set application

-name name
[-description description] [-group application group] [-classification-type ethertype, ica-published-app, ip, tcp, udp, web-address] [-classification-parameters classification paramenters] This command changes the configuration of an application.
9-40
June 26, 2011
Chapter10
SpecificationsandSupport
Figure 10-1 Specifications for Repeater Appliances
Physical Height Width Depth Weight Power Supply Wattage Voltage Temperature Operating Temperature Storage Temperature 50F to 95F (10C to 35C) 40F to 149F (40C to 65C) 50F to 95F (10C to 35C) 40F to 149F (40C to 65C) 300 100240 VAC, 5060 Hz 700 110/240 VAC., 50-60 Hz 1U Units: Repeater 65xx and 85xx 1.7 in. (4.3 cm) 16.8 in. (42.6 cm) 23.1 in. (58.6 cm) 38 lb (17.2 kg) max. 2U Units: Repeater 68xx and 88xx 3.5 in. (8.9 cm) 17.6 in. (44.7 cm) 29.8 in. (75.7 cm) 59 lb (26.76 kg) max.
Figure 10-2 Specifications for Branch Repeater Appliances

Physical Height Width Depth Weight Packing Dimensions 1.7 in. (4.3 cm) 17.2 in. (43.7 cm) 11.3 in. (28.7 cm) 11.8 lb. (5.4 kg) 22.8 in. x 6 in. x 18 in. Power Supply Wattage Voltage 78 W typ., 260 W max. 100-240 VAC, 50-60 Hz Temperature Operating Temperature Storage Temperature 50-95 F, 10-35 C at 8-90% humidity, non-condensing -40-158F, -40-70 C at 5-95% humidity, non-condensing
10-1
10.1 Contact Us
10.1
Contact Us
To contact Citrix Support, call 1-800-4CITRIX or use the My Support section on MyCitrix at http://www.citrix.com. You will be asked for your hardware serial number as part of the support process. Detailed instructions for contacting support can be found at: http://citrix.com/site/ resources/dynamic/sup2nd/Citrix_HWS_SerialNO.pdf.
{ d i - B
i R {
h B
d R [ h Zb g A{ i p B Z b g A{ i O i p r g p - o B d R [ hZ bg gp A i d R[ h Z bg g p A - L u t \ - ?
Citrix System, Inc. 883-00002-00
10-2
June 26, 2011

Citrix Branch Repeater User Guide

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Citrix Branch Repeater User Guide

Caricato da

Copyright:

Formati disponibili

Citrix Branch Repeater Family Installation and Users Guide

Citrix Systems, Inc.

Need help? Contact Citrix Support. See Section 10.1.

June 26, 2011

June 26, 2011

June 26, 2011

10 Specifications and Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-1 10.1 - Contact Us. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2

Branch Repeater Family Installation and Users Guide

June 26, 2011

Repeater 8500 Series Appliance

Repeater 8800 Series Appliance

Branch Repeater Family Installation and Users Guide, rel. 6.0

1.1 Branch Repeater Product Line

Branch Repeater Product Line

June 26, 2011

Who Should Read This Guide

What Is In This Guide

Note About Screen Captures

Branch Repeater Family Installation and Users Guide, rel. 6.0

1.5 Note About Screen Captures

June 26, 2011

Traffic in both directions must pass through both Acceleration units.

Branch Repeater Family Installation and Users Guide, rel. 6.0

2.2 Product Selection

June 26, 2011

Chapter 2. Appliance Deployment Guide

Selecting a Deployment Mode

Branch Repeater Family Installation and Users Guide, rel. 6.0

2.3 Selecting a Deployment Mode

June 26, 2011

Chapter 2. Appliance Deployment Guide

Figure 2-4 Recommended deployment modes, based on WAN router topology.

B. Single LAN, Redundant WANs LAN Redundant WANs to Site X LAN

Redundant WANs to Site X

WAN to Site X WAN to Site Y

WAN to Site X WAN to Site Y

WAN to Site X WAN to Site Y

Deployment Mode Summary

2.3.3.1 Forwarding Modes

Branch Repeater Family Installation and Users Guide, rel. 6.0

2.3 Selecting a Deployment Mode

Figure 2-5 Options supported for each router topology

June 26, 2011

Chapter 2. Appliance Deployment Guide

2.3.3.2 High Availability

2.3.3.3 Acceleration Modes

Forwarding Loop Prevention

Branch Repeater Family Installation and Users Guide, rel. 6.0

2.5 Guidelines for Sites With Multiple WAN Routers

Guidelines for Sites With Multiple WAN Routers

Solving the Problem With Appliances

Chapter 2. Appliance Deployment Guide

Branch Repeater Family Installation and Users Guide, rel. 6.0

2.5 Guidelines for Sites With Multiple WAN Routers

Mixing Modes Within a Single Appliance

June 26, 2011

Chapter 2. Appliance Deployment Guide

Figure 2-10 Combinations of forwarding modes within a single Appliance

Solving the Problem in the Router

Branch Repeater Family Installation and Users Guide, rel. 6.0

2.6 Deploying to Support VPNs

Deploying to Support VPNs

June 26, 2011

Chapter 2. Appliance Deployment Guide