Citrix Branch Repeater Family™: Installation and User's Guide

Citrix Branch Repeater Family™
Installation and User’s Guide

Releases 5.5-5.7
Citrix Systems, Inc.

© CITRIX SYSTEMS, INC., 2010. ALL RIGHTS RESERVED. NO PART OF THIS DOCU-
MENT 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 11.1.

Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1
1.1 - Branch Repeater Product Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2
1.2 - Who Should Read This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2
1.3 - What Is In This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3
1.4 - Releases Covered in This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3
1.5 - Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3
1.6 - Note About Screen Captures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-4
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-7
2.3.3.1 - Forwarding Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-7
2.3.3.2 - High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-7
2.3.3.3 - Acceleration Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-7
2.4 - Forwarding Loop Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-8
2.5 - Guidelines for Sites With Multiple WAN Routers . . . . . . . . . . . . . . . . . . . . .2-8
2.5.1 - Solving the Problem With Appliances . . . . . . . . . . . . . . . . . . . . . . . . . .2-9
2.5.2 - Mixing Modes Within a Single Appliance . . . . . . . . . . . . . . . . . . . . . . . 2-10
2.5.3 - Solving the Problem in the Router . . . . . . . . . . . . . . . . . . . . . . . . . . .2-10
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 Recom-
mended) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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-4
3.3.3 - Turn on the Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-6
3.3.4 - Perform Initial Configuration Via the Front Panel . . . . . . . . . . . . . . . . . .3-6
3.3.5 - Browser-Based Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8
3.3.6 - Install the License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8
3.3.7 - Configure the High-Availability Pair . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8
3.3.8 - Set Bandwidth Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
3.3.9 - Check Service Class Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
3.3.10 - Configure Repeater Plug-in Support . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
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-17
3.3.14 - Disable Encryption on Outlook 2007 Clients . . . . . . . . . . . . . . . . . . . 3-17
3.4 - Testing the Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17
Branch Repeater Family Installation and User’s Guide i

3.5 - Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18
3.5.1 - Cabling and Duplexing Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18
3.5.2 - Can’t Connect in Virtual Inline Mode . . . . . . . . . . . . . . . . . . . . . . . . . 3-18
3.5.3 - No Transfers are Accelerated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19
3.5.3.1 - TCP Option Usage and Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19
3.5.4 - Windows Filesystem (CIFS) Transfers Are Not Accelerated . . . . . . . . . . 3-20
3.5.5 - Accelerated Connections Run Slowly . . . . . . . . . . . . . . . . . . . . . . . . . 3-20
3.5.6 - Accelerated Connections Run, then Hang . . . . . . . . . . . . . . . . . . . . . . 3-20
3.5.7 - Contact Us . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-21
3.6 - Licensing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21
3.6.1 - Licensing Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26
3.7 - . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-27
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 - Bandwidth Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6
4.3.1 - Bandwidth Management Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6
4.3.2 - How the Appliance Allocates Bandwidth . . . . . . . . . . . . . . . . . . . . . . . .4-7
4.3.3 - An Appliance Should Become The Bottleneck Gateway. . . . . . . . . . . . . .4-7
4.3.4 - Reserving Bandwidth For Non-Accelerated Connections . . . . . . . . . . . . .4-9
4.3.4.1 - Partial Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9
4.3.4.2 - Full Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9
4.3.5 - Performance Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
4.4 - QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11
4.4.1 - QoS Example 1: FTP Background Queue . . . . . . . . . . . . . . . . . . . . . . 4-12
4.4.2 - QoS Example 2: Guaranteed Bandwidth for Disk Replication. . . . . . . . . 4-14
4.4.2.1 - Using QoS Effectively . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15
4.4.3 - Dynamic QoS For Citrix XenApp (ICA) . . . . . . . . . . . . . . . . . . . . . . . . 4-15
4.4.3.1 - Example of ICA QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15
4.4.4 - Notes on QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16
4.5 - Ethernet Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-17
4.5.1 - Bridged Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18
4.5.2 - Motherboard Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-18
4.5.3 - Port Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18
4.5.4 - The Primary Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19
4.5.5 - The Aux1 Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19
4.5.6 - Using Multiple Bridges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19
4.6 - Autodiscovery and Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20
4.6.1 - Firewall Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21
4.7 - Forwarding Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-22
4.8 - Inline Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-23
4.8.1 - Accelerating an Entire WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24
4.8.2 - Accelerating Some Systems But Not Others . . . . . . . . . . . . . . . . . . . . 4-24
4.9 - Redirector Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25
ii September 20, 2010

4.9.1 - How it Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25
4.9.2 - Configuring Redirector Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26
4.10 - WCCP Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-27
4.10.1 - How it Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-27
4.10.2 - Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28
4.10.3 - Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28
4.10.4 - Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28
4.10.5 - Router Support for WCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28
4.10.6 - Router Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-29
4.10.7 - Appliance Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-30
4.10.8 - Service Group Configuration Details. . . . . . . . . . . . . . . . . . . . . . . . . 4-30
4.10.9 - Testing and Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32
4.11 - Virtual Inline Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32
4.11.1 - How Virtual Inline Mode Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33
4.11.1.1 - Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33
4.11.2 - Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34
4.11.2.1 - How the Appliance Forwards Packets. . . . . . . . . . . . . . . . . . . . . . 4-34
4.11.3 - The Need for Policy-Based Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-35
4.11.4 - Health Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-36
4.11.5 - Routing Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-37
4.11.6 - Virtual Inline Mode For Multi-WAN Environments . . . . . . . . . . . . . . . .4-39
4.11.7 - Virtual Inline Mode and High Availability. . . . . . . . . . . . . . . . . . . . . . 4-39
4.12 - Group Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-40
4.12.1 - When to Use Group Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-42
4.12.1.1 - Alternatives to Group Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-42
4.12.2 - How Group Mode Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-42
4.12.3 - Owner Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-44
4.12.3.1 - IP-Based Ownership Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-44
4.12.3.2 - Failure Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-45
4.12.4 - Setting the Bandwidth Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-45
4.12.5 - Enabling Group Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-45
4.12.6 - Setting Forwarding Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-47
4.13 - Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-48
4.13.1 - XenApp Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-49
4.13.2 - How Compression Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-50
4.13.2.1 - Memory-Based Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-50
4.13.2.2 - Disk-Based Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-51
4.13.3 - Enabling/Disabling Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-52
4.13.4 - Measuring Disk-Based Compression Performance . . . . . . . . . . . . . . . 4-52
4.13.4.1 - Testing LAN performance with Iperf . . . . . . . . . . . . . . . . . . . . . . 4-53
4.13.4.2 - Using FTP for initial testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-53
4.14 - CIFS (Windows Filesystem) Acceleration . . . . . . . . . . . . . . . . . . . . . . . . 4-54
4.14.1 - CIFS Security and Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-55
4.14.2 - Interpretation the CIFS Status Page . . . . . . . . . . . . . . . . . . . . . . . . 4-57
4.14.3 - CIFS Management Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-58
4.15 - Microsoft Outlook (MAPI) Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . 4-59
4.15.1 - Supported Outlook/Exchange Versions and Modes . . . . . . . . . . . . . . . 4-59
4.15.2 - Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-59
4.15.2.1 - Disabling Encryption on Outlook 2007 . . . . . . . . . . . . . . . . . . . . . 4-60
4.15.2.2 - Performance Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-61
4.16 - SSL Compression (Release 5.7 Only) . . . . . . . . . . . . . . . . . . . . . . . . . . 4-62
Branch Repeater Family Installation and User’s Guide iii

4.16.1 - How SSL Compression Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-63
4.16.2 - SSL Transparent Proxy and Split Proxy Modes. . . . . . . . . . . . . . . . . . 4-63
4.16.2.1 - SSL Split Proxy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-63
4.16.2.2 - SSL Transparent Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-64
4.16.3 - Generating Security Keys and Certificates . . . . . . . . . . . . . . . . . . . . 4-65
4.16.4 - Configuring SSL Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-65
4.16.4.1 - Configuring the Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-65
4.16.5 - Using SSL Compression on the Repeater Plug-in . . . . . . . . . . . . . . . .4-74
4.17 - Service Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-75
4.17.1 - How Service Class Policies are Evaluated . . . . . . . . . . . . . . . . . . . . .4-76
4.17.2 - SSL Rules (Rel. 5.7 Only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-76
4.18 - Additional Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-77
4.19 - Proxy Mode (Legacy Feature). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-77
4.19.0.1 - Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-77
4.19.0.2 - Proxy Mode Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-80
4.19.0.3 - VIP-to-VIP Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-81
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-13
5.3.1 - Customizing the Plug-in MSI File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
5.3.2 - Using Customized Plug-in Software . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17
5.3.3 - Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18
5.3.4 - Installation Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19
5.3.5 - Running the Plug-in For the First Time . . . . . . . . . . . . . . . . . . . . . . . . 5-21
5.4 - Testing the Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-23
5.5 - Troubleshooting Plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-23
5.6 - Repeater Plug-in Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24
5.6.1 - Configuration Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24
5.6.2 - Performance Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-26
5.6.3 - Diagnostics Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-27
5.6.4 - “Certificates” Tab (Rel. 5.7 Only) . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-29
5.6.5 - Uninstalling the Repeater Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-30
iv September 20, 2010

5.6.6 - Updating the Repeater Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-30
6 Branch Repeater VPX (Rel. 5.6 Only) . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1

6.1 - About Branch Repeater VPX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1
6.1.1 - Uses For Branch Repeater VPX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1
6.1.2 - Other Branch Repeater VPX Features . . . . . . . . . . . . . . . . . . . . . . . . . .6-4
6.2 - Differences Between VPX and Repeater . . . . . . . . . . . . . . . . . . . . . . . . . .6-5
6.3 - System Requirements and Provisioning. . . . . . . . . . . . . . . . . . . . . . . . . . .6-6
6.3.1 - Supported Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-6
6.3.2 - Minimum Resource Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-6
6.3.3 - Maximum Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-7
6.3.4 - Resource Usage Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-7
6.4 - Virtual Ethernet Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-8
6.5 - Upgrading a Previous Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-8
6.6 - Initial Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-8
6.6.1 - Install XenServer and XenCenter. . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-9
6.6.2 - Install Licenses on the Citrix License Server . . . . . . . . . . . . . . . . . . . . .6-9
6.6.3 - Install the Branch Repeater VPX Virtual Machine . . . . . . . . . . . . . . . . . .6-9
6.7 - Additional Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19
7 Cabling and Physical Deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1

7.1 - Power On/Off. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1
7.2 - Ethernet Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1
7.2.1 - Gigabit Ethernet Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1
7.2.2 - Fast Ethernet (100 Mbps) Networks. . . . . . . . . . . . . . . . . . . . . . . . . . .7-1
7.2.2.1 - Connector Polarity and Cross-Over Cables . . . . . . . . . . . . . . . . . . . .7-1
7.2.2.2 - Fast Ethernet Auto-Negotiation Failures . . . . . . . . . . . . . . . . . . . . .7-2
7.2.2.3 - Older Fast Ethernet Equipment. . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3
7.2.3 - 10BaseT (10 Mbps) Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3
7.2.4 - Ethernet Bypass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3
7.3 - What Happens if the Appliance Fails . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3
7.3.1 - Inline Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-3
7.3.2 - WCCP Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4
7.3.3 - Virtual Inline Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4
7.3.4 - Group Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4
7.3.5 - High-Availability Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4
7.3.6 - Redirector Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4
7.4 - High-Availability Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4
7.4.1 - Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-5
7.4.2 - How High Availability Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-5
7.4.3 - HA Virtual Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-6
7.4.4 - Enabling/Disabling High-Availability Mode . . . . . . . . . . . . . . . . . . . . . .7-7
7.4.5 - Updating Software for a High-Availability Pair . . . . . . . . . . . . . . . . . . . .7-7
8 Configuration Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1

8.1 - Altered Menu Structure for Release 5.7. . . . . . . . . . . . . . . . . . . . . . . . . . .8-1
8.2 - “Monitoring” Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3
8.2.1 - “Monitoring: System Status” Page . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4
8.2.1.1 - Enabling/Disabling Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4
8.2.1.2 - Status Lines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4
8.2.2 - “Monitoring: Usage Graph” Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-6
Branch Repeater Family Installation and User’s Guide v

8.2.3 - “Monitoring: Active Connections” Page. . . . . . . . . . . . . . . . . . . . . . . . .8-8
8.2.3.1 - Selecting Which Accelerated Connections to Show . . . . . . . . . . . . . .8-8
8.2.3.2 - Unaccelerated Connections Display . . . . . . . . . . . . . . . . . . . . . . . . .8-9
8.2.3.3 - Connection Details Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10
8.2.3.4 - Flow Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13
8.2.4 - Monitoring: CIFS Status” Pages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-15
8.2.5 - “Monitoring: Service Class Statistics” Page . . . . . . . . . . . . . . . . . . . . . 8-17
8.2.6 - “Monitoring: Compression Status” . . . . . . . . . . . . . . . . . . . . . . . . . . 8-22
8.2.7 - “Monitoring: QoS Statistics” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-25
8.2.7.1 - QoS Statistics Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-26
8.2.7.2 - QoS Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-27
8.2.8 - “Monitoring: WCCP Status”. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-28
8.2.9 - “Monitoring: Repeater Plug-in” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-30
8.2.10 - “Monitoring: MAPI Status” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-30
8.2.10 - “Acceleration Graphs” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-30
Figure 8-27 - “Accelerated Connections” Tab. . . . . . . . . . . . . . . . . . . . . . . . 8-32
Figure 8-28 - “Unaccelerated Connections” Tab . . . . . . . . . . . . . . . . . . . . . . 8-33
8.2.11 - “Monitoring: ICA Status” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-33
8.2.12 - “Monitoring: Peer Status” (Rel. 5.7 Only) . . . . . . . . . . . . . . . . . . . . . 8-34
8.3 - The “Configure Settings” Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-35
8.3.1 - “Configure Settings: Bandwidth Management” . . . . . . . . . . . . . . . . . . 8-35
8.3.1.1 - Hardboost vs. Softboost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-35
8.3.1.2 - Bandwidth Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-35
8.3.1.3 - Full Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-37
8.3.1.4 - Partial Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-37
8.3.1.5 - Accelerated Traffic Minimum Send Rate (Partial Bandwidth Only) . . . 8-38
8.3.1.6 - Bandwidth Schedules (Hardboost Only). . . . . . . . . . . . . . . . . . . . . 8-38
8.3.1.7 - Separate Schedules for Individual Remote Sites
(Hardboost Only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-39
8.3.2 - “Configure Settings: Proxy” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-40
8.3.3 - “Configure Settings: Interface” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-45
8.3.3.1 - Detailed Adapter Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-45
8.3.4 - “Configure Settings: Tuning” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-48
8.3.4.1 - Window Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-49
8.3.4.2 - Connection Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-49
8.3.4.3 - Special Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-49
8.3.4.4 - Virtual Inline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-50
8.3.4.5 - Daisy-Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-50
8.3.4.6 - TCP Maximum Segment Size (MSS) . . . . . . . . . . . . . . . . . . . . . . .8-51
8.3.4.7 - SCPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-51
8.3.4.8 - Forwarding Loop Prevention. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-51
8.3.4.9 - Generic Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-52
8.3.5 - “Configure Settings: SNMP” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-53
8.3.5.1 - Installing the SNMP MIB Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-54
8.3.5.2 - SNMP Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-54
8.3.6 - “Configure Settings: Date/Time” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-55
8.3.7 - “Configure Settings: Logging” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-56
8.3.7.1 - Log Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-56
8.3.7.2 - Syslog Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-57
8.3.7.3 - Exporting Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-58
8.3.7.4 - Erasing Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-59
vi September 20, 2010

8.3.8 - “Configure Settings: Alerts” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-60
8.3.8.1 - Two Kinds of Alert Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-61
8.3.8.2 - User-Configurable Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-61
8.3.8.3 - Internal Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-62
8.3.8.4 - Alert Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-62
8.3.9 - “Configure Settings: UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-62
8.3.9.1 - Web Access Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-63
8.3.9.2 - HTTPS Certificate Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-64
8.3.9.3 - Graphing Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-65
8.3.9.4 - Miscellaneous Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-66
8.3.10 - “Configure Settings: CIFS” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-67
8.3.11 - “Configure Settings: Service Class” . . . . . . . . . . . . . . . . . . . . . . . . . 8-68
8.3.11.1 - Creating a New Service Class . . . . . . . . . . . . . . . . . . . . . . . . . . .8-69
8.3.11.2 - Creating New Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-69
8.3.11.3 - Creating SSL Rules (rel. 5.7 Only) . . . . . . . . . . . . . . . . . . . . . . . 8-70
8.3.12 - “Configure Settings: Service Class Policy”. . . . . . . . . . . . . . . . . . . . . 8-71
8.3.12.1 - Rules are Evaluated In Order . . . . . . . . . . . . . . . . . . . . . . . . . . .8-72
8.3.12.2 - Only Features Allowed by Both Units Are Used . . . . . . . . . . . . . . . 8-72
8.3.12.3 - Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-72
8.3.12.4 - Special-Case Handling for Internet HTTP/HTTPS . . . . . . . . . . . . . . 8-72
8.3.13 - “Configure Settings: QoS” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-74
8.3.14 - “Configure Settings: IP Address” . . . . . . . . . . . . . . . . . . . . . . . . . . .8-75
8.3.14.1 - Accelerated Pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-76
8.3.14.2 - Address Formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-76
8.3.14.3 - HA Virtual IP Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-76
8.3.14.4 - Web Management Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-76
8.3.14.5 - VLAN Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-76
8.3.15 - “Configure Settings: High Availability” . . . . . . . . . . . . . . . . . . . . . . . 8-77
8.3.15.1 - Status and Configuration Tab . . . . . . . . . . . . . . . . . . . . . . . . . . .8-77
8.3.15.2 - Partner Information Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-78
8.3.15.3 - HA VIP Address Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-78
8.3.16 - “Configure Settings: Group Mode” . . . . . . . . . . . . . . . . . . . . . . . . . . 8-79
8.3.17 - “Configure Settings: WCCP” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-80
8.3.18 - “Configure Settings: Repeater Plug-in”. . . . . . . . . . . . . . . . . . . . . . . 8-82
8.3.18.1 - Signaling Channel Configuration Tab . . . . . . . . . . . . . . . . . . . . . . 8-82
8.3.18.2 - Acceleration Rules Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-84
8.3.18.3 - Best Practices With Acceleration Rules. . . . . . . . . . . . . . . . . . . . . 8-84
8.3.18.4 - General Configuration Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-85
8.3.19 - “System Settings: Cert/Key for HA/GM” (Rel. 5.7 Only) . . . . . . . . . . . 8-86
8.3.20 - “Acceleration Settings: Encryption” (Rel. 5.7 Only) . . . . . . . . . . . . . . 8-87
8.3.21 - “Acceleration Settings: Peers” (Rel. 5.7 Only) . . . . . . . . . . . . . . . . . . 8-88
8.3.22 - “Acceleration Settings: SSL” (Rel. 5.7 Only) . . . . . . . . . . . . . . . . . . . 8-88
8.4 - The “Reporting” Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-90
8.4.1 - “Reporting: Generate Report” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-90
8.5 - The “System Tools” Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-92
8.5.1 - “System Tools: Save/Restore Configuration” . . . . . . . . . . . . . . . . . . . 8-92
8.5.2 - “System Tools: Update Software” . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-93
8.5.2.1 - Upgrading to a New Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-93
8.5.2.2 - Downgrading to a Prior Release . . . . . . . . . . . . . . . . . . . . . . . . . . 8-94
8.5.2.3 - Changing the Version Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-94
8.5.3 - “System Tools: Manage Licenses” . . . . . . . . . . . . . . . . . . . . . . . . . . .8-95
Branch Repeater Family Installation and User’s Guide vii

8.5.3.1 - The License Information Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-95
8.5.3.2 - The License Configuration Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-96
8.5.3.3 - The License Server Tab (Rel. 5.6 Only) . . . . . . . . . . . . . . . . . . . . . 8-98
8.5.3.4 - Local Licenses Tab (Rel. 5.6 Only) . . . . . . . . . . . . . . . . . . . . . . . . 8-98
8.5.3.5 - The Licensed Features Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-99
8.5.4 - “System Tools: Restart System” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-99
8.5.5 - “System Tools: View Logs” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-101
8.6 - The “Security” Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-102
8.6.1 - “Security: Set Certificates” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-102
8.6.2 - “Security: Manage Users”. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-102
8.6.2.1 - Security: Local Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-103
8.6.2.2 - Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-104
8.6.3 - “Security: Access” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-105
8.6.4 - “Security: Logout” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-105
8.7 - The “Diagnostics” Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-106
8.7.1 - “Diagnostics: Diagnostic Tools” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-106
8.7.1.1 - Tracing Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-107
8.7.1.2 - Bypass Card Test Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-107
8.7.1.3 - Retrieve Cores Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-107
8.7.1.4 - Line Tester (Iperf) Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-108
8.7.1.5 - Ping and Traceroute Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-108
8.7.1.6 - System Info Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-109
9 Command Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1

9.1 - SSH Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1
9.2 - SFTP Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1
9.2.1 - Enabling file transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1
9.2.2 - Transferring Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-2
9.3 - Command Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-2
9.3.1 - CLI Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-2
9.3.1.1 - exit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-2
9.3.1.2 - quit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-2
9.3.1.3 - help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-2
9.3.1.4 - show. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-2
9.3.2 - System Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-3
9.3.2.1 - show config-script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-3
9.3.2.2 - list config-script-files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-3
9.3.2.3 - reset settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-3
9.3.2.4 - restart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-3
9.3.2.5 - what . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-3
9.3.2.6 - show software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-3
9.3.2.7 - verify software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4
9.3.2.8 - install software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4
9.3.2.9 - list software-files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4
9.3.2.10 - restore software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4
9.3.2.11 - set software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4
9.3.3 - Security Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4
9.3.3.1 - show user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4
9.3.3.2 - add user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4
9.3.3.3 - set user. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-5
9.3.3.4 - remove user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-5
viii September 20, 2010

9.3.3.5 - show access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-5
9.3.3.6 - enable access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-5
9.3.3.7 - disable access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-5
9.3.3.8 - set access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-5
9.3.3.9 - list certificate-files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-5
9.3.4 - System Status Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6
9.3.4.1 - enable unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6
9.3.4.2 - disable unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6
9.3.4.3 - show system-status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6
9.3.5 - IP Address Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6
9.3.5.1 - show dns-server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6
9.3.5.2 - set dns-server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6
9.3.5.3 - show hostname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6
9.3.5.4 - set hostname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6
9.3.5.5 - show adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6
9.3.5.6 - set adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7
9.3.6 - Ethernet Configuration Commands . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7
9.3.6.1 - set interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7
9.3.6.2 - show interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7
9.3.7 - Bandwidth Configuration Commands . . . . . . . . . . . . . . . . . . . . . . . . . .9-7
9.3.7.1 - show bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7
9.3.7.2 - set bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7
9.3.7.3 - add bandwidth-rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7
9.3.7.4 - remove bandwidth-rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-8
9.3.8 - Service Class Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-8
9.3.8.1 - show service-classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-8
9.3.8.2 - add service-class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-8
9.3.8.3 - set service-class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-8
9.3.8.4 - remove service-class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-8
9.3.8.5 - rename service-class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-8
9.3.8.6 - show service-class-rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-9
9.3.8.7 - add service-class-rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-9
9.3.8.8 - remove service-class-rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-9
9.3.9 - ICA Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-9
9.3.9.1 - show dynamic-ica-queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-9
9.3.9.2 - set dynamic-ica-queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-9
9.3.10 - QoS Configuration Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-9
9.3.10.1 - show qos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-9
9.3.10.2 - set qos-classname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-9
9.3.10.3 - set qos-bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-9
9.3.11 - SNMP Configuration Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10
9.3.11.1 - show snmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10
9.3.11.2 - enable snmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10
9.3.11.3 - disable snmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10
9.3.11.4 - show snmp-system-mib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10
9.3.11.5 - set snmp-system-mib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10
9.3.11.6 - add snmp-manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10
9.3.11.7 - remove snmp-manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10
9.3.11.8 - show snmp-trapdest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10
9.3.11.9 - add snmp-trapdest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
9.3.11.10 - remove snmp-trapdest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
Branch Repeater Family Installation and User’s Guide ix

9.3.12 - Alert Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
9.3.12.1 - show alert-configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
9.3.12.2 - set alert-configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
9.3.12.3 - reset alert-configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
9.3.13 - WCCP Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
9.3.13.1 - show wccp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
9.3.13.2 - enable wccp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12
9.3.13.3 - disable wccp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12
9.3.13.4 - add wccp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12
9.3.13.5 - set wccp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12
9.3.13.6 - remove wccp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12
9.3.14 - Logging Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12
9.3.14.1 - show syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12
9.3.14.2 - set syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
9.3.14.3 - enable syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-13
9.3.14.4 - disable syslog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-13
9.3.14.5 - show log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
9.3.14.6 - set log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
9.3.14.7 - extract log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
9.3.14.8 - list log-extracted-files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
9.3.15 - Proxy Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14
9.3.15.1 - show proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14
9.3.15.2 - add proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14
9.3.15.3 - remove proxy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-14
9.3.16 - Repeater Plug-in (Client) Configuration . . . . . . . . . . . . . . . . . . . . . . 9-14
9.3.16.1 - show client-rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14
9.3.16.2 - add client-rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14
9.3.16.3 - remove client-rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14
9.3.16.4 - show signaling-channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14
9.3.16.5 - enable signaling-channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14
9.3.16.6 - disable signaling-channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14
9.3.16.7 - set signaling-channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-15
9.3.16.8 - show client-settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15
9.3.17 - Group Mode Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15
9.3.17.1 - show group-mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15
9.3.17.2 - enable group-mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15
9.3.17.3 - disable group-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15
9.3.17.4 - set group-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15
9.3.17.5 - add group-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16
9.3.17.6 - remove group-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-16
9.3.18 - SSL Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16
9.3.18.1 - SSL Compression Enable/Disable . . . . . . . . . . . . . . . . . . . . . . . . 9-16
9.3.18.2 - SSL Keystore Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16
9.3.18.3 - SSL Disk Encryption Configuration . . . . . . . . . . . . . . . . . . . . . . . 9-16
9.3.18.4 - SSL Profile Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-16
9.3.18.5 - SSL CA Certificate Store Configuration . . . . . . . . . . . . . . . . . . . . 9-17
9.3.18.6 - SSL Certificate/Key Pairs Configuration . . . . . . . . . . . . . . . . . . . . 9-17
9.3.18.7 - SSL Peer Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-18
x September 20, 2010

10 Serial Monitor Command Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-1
11 Specifications and Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-1

11.1 - Contact Us. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2
Branch Repeater Family Installation and User’s Guide xi

xii September 20, 2010
Chapter 1
Introduction
Repeater Appliances optimize your WAN links, giving your users maximum respon-
siveness and throughput at any distance, and providing that “locally connected” expe-
rience 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 twenty-
minute 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 User’s Guide, rel. 5.5-5.7 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.
• 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 virtual machine. This product combines the flexibility of vir-
tual 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 Win-
dows-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 User’s Guide.
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-2 September 20, 2010

Chapter 1. Introduction
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 ongo-
ing management.
• Chapter 9 describes the command-line interface.
• Chapter 10 describes the command set of the serial monitor.
• Chapter 11 provides product specifications.
1.4 Releases Covered in This Guide

This guide covers releases 5.5-5.7. Most of the information also applies to earlier
releases as well. In general, Appliances running different releases are fully compatible
with each other, and can use any features that both have in common.
Release numbering works as follows:
• Release 2.0 is the Branch Repeater with Windows Server equivalent to Release
5.5. Branch Repeater with Windows Server is not covered in this manual: see the
Branch Repeater with Windows Server Installation and User’s Guide, rel. 2.0-3.0.
• Release 3.0 is the Branch Repeater with Windows Server equivalent to Release
5.7. Branch Repeater with Windows Server is not covered in this manual: see the
Branch Repeater with Windows Server Installation and User’s Guide, rel. 2.0-3.0.
• Release 5.5 corresponds to Release 2.0, but covers Repeater, Branch Repeater,
and the Repeater Plug-in. The bulk of this document reflects Release 5.5. Differ-
ences between this release and releases 5.6 and 5.7 are noted where necessary.
• Release 5.6 is the Branch Repeater VPX equivalent to Release 5.5. Except where
specified otherwise (see especially Section 6.2), the features in this manual apply
equally to releases 5.5 and 5.6.
• Release 5.7 adds SSL compression to the feature set.
1.5 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 Appli-
ance, or Branch Repeater VPX virtual machine
Flow. This term means “all connections passing between the same pair of Accelera-
tion 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.
1.6 Note About Screen Captures
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.6 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.
On Release 5.7, the left-hand menu bar has been substantially rearranged. Most
screen captures show the Release 5.5 menu structure. See Figure 8-1 for a compari-
son between the two.

Chapter 2
Appliance Deployment Guide

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 NETWORK B
WAN
WAN Router WAN Router

Appliance Appliance
WAN Link
Transparent,
AutoOptimized
Acceleration
LAN Link LAN Link
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 User’s Guide for more information.
• Branch Repeater VPX. An Appliance in the form of a Xen virtual machine. 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 band-
width, 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 Licensed Bandwidth Limit Range
Repeater Plug-in N/A
Branch Repeater, Branch Repeater with

1-10 mbps
Windows Server
Branch Repeater VPX 1-45 mbps
Repeater 8500 Series 5-45 mbps
Repeater 8800 Series 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.)

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.
Link Speed
Appliance Model
1 mbps 10 mbps 100 mbps
Data lifetime at 33% link utilization
Repeater 8800 180 days 18 days 43 hours
Data lifetime at 100% link utilization
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 deploy-
ments. 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 Appli-
ances, 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, 8500, and 8300 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 Selecting a Deployment Mode

2.3.1 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 net-
work is concerned, it is as if the Appliance weren’t there at all; its operation is com-
pletely transparent.
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 this require an extra LAN port on the router
and (on Cisco routers) a newer version of Cisco IOS.
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. Single LAN/Single WAN is the only configura-
tion for which hardboost and partial bandwidth are both supported. (The differ-
ence between hardboost and softboost, full bandwidth and partial bandwidth, 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 con-
figuration 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 cate-
gories: 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.

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

Inline
LAN WAN LAN WAN
B. Single LAN, Redundant WANs

Inline
Redundant
Redundant LAN WANs to Site X
LAN
WANs to Site X
C. Single LAN, WANs to Two or More Sites Hop-by-Hop

WCCP WAN to Site X
LAN
WAN to Site Y
WAN to
Site X
LAN Hub-and-Spoke
WAN to WAN to
Inline Site X
Site Y
LAN
WAN to
Site Y
D. Dual LANs, Single WAN
LAN
WAN
LAN
LAN WCCP
WAN
LAN
LAN
WAN
LAN
Two Accelerated
Bridges
E. Multiple LANs, Multiple WANs

WAN to
Site X
LAN
LAN
WAN to
WAN to
Site Y
LAN Site X
LAN WCCP WAN to
WAN to Site X
Site Y LAN
LAN
Two Accelerated WAN to
Bridges Site Y
Figure 2-5 Options supported for each router topology

Appliances WITH Ethernet Bypass Cards
High
Soft- Hard- Full Partial Group
Config. Mode Avail-
Boost Boost BW BW Mode
ability
A. Inline Yes Yes Yes Yes Yes Yes
B. WCCP Yes No Yes No Yes Yes
C1. WCCP Yes No Yes No No Yes
C2. Inline Yes No Yes No Yes Yes
D. WCCP Yes No Yes No No Yes
Inline,
D2. Dual Yes No Yes No No Yes
Bridges
E. WCCP Yes No Yes No No Yes
Inline,
E2. Dual Yes No Yes No No Yes
Bridges
Appliances WITHOUT Ethernet Bypass Cards
High
Soft- Hard- Full Partial Group
Config. Mode Avail-
Boost Boost BW BW Mode
ability
A. Inline Yes Yes Yes Yes No No
B. WCCP Yes No Yes No No No
C1. WCCP Yes No Yes No No No
C2. Inline Yes No Yes No No No
D. WCCP Yes No Yes No No No
Inline,
D2. Dual No No Yes No No No
Bridges
E. WCCP Yes No Yes No No No
Inline,
E2. Dual No No Yes No No No
Bridges

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. Sup-
ported 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
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 net-
work devices.)
• Virtual Inline mode. Similar to WCCP mode. Uses “policy-based routing.” Gener-
ally requires a dedicated LAN port on the router. Not recommended on units with-
out 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.
• 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 Appli-
ance 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 Ether-
net 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 deply-
ment. Acts like normal TCP, only faster.
• Partial bandwidth mode. When non-accelerated traffic is seen, the Appliance
backs off the accelerated traffic to make room for it. Useful for ensuring VoIP qual-
ity under hardboost, or under softboost when your router is not set up to do this
for you.
2.4 Forwarding Loop Prevention
• Full bandwidth mode. What you have when partial bandwidth mode is disabled.
2.4 Forwarding Loop Prevention

The “Forwarding Loop Prevention” option allows the same packet to traverse Appli-
ances 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 accel-
erable 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 dis-
abled by default.
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 don’t 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.
SITE C SITE D
WAN
LAN
WRONG
LAN
SITE E
LAN

2.5.1 Solving the Problem With Appliances

This problem can be addressed using either Appliance configuration or router configu-
ration. 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.
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.
SITE C SITE D
WAN
OK
LAN LAN
SITE E
LAN
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 independent links to be accelerated.
• 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.
• 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.
Keep in mind that sites with only one WAN link do not participate in asymmetric rout-
ing and are not a problem. This is shown in Figure 2-9.
2.5 Guidelines for Sites With Multiple WAN Routers
Figure 2-8 By covering all links with either group mode or virtual inline mode, asymmetric
routing ceases to be a problem.
SITE C SITE D
Group Mode Virtual
WAN Inline
OK
LAN LAN
SITE E
LAN
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.
SITE G SITE H
WAN
OK
LAN LAN
SITE I SITE J
LAN LAN
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
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
2-10 September 20, 2010

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

Supported Combinations, Units WITH Ethernet Bypass Cards
Virtual WCCP- WCCP- Multiple High Group

Config. Inline
Inline GRE L2 Bridges Avail. Mode
Repeater
Y Y Y Y Y Y N
Plug-in
Inline Y Y NR* NR* Y Y Y
Virtual
Y Y Y Y Y N
Inline
WCCP-
Y Y Y Y N
GRE
WCCP-
Y Y Y N
L2
Multiple
Y Y N
Bridges
High Avail. Y Y
Supported Combinations, Units WITHOUT Ethernet Bypass Cards
Virtual WCCP- WCCP- Multiple High Group

Config. Inline
Inline GRE L2 Bridges Avail. Mode
Repeater
N N N N N N N
Plug-in
Inline Y NR* NR* NR* N N N
Virtual
NR* NR* NR* N N N
Inline
WCCP-
Y Y N N N
GRE
WCCP-
Y N N N
L2
Multiple
N N N
Bridges
High Avail. N N
Y = Yes, supported. N = Not supported. NR = Not recommended
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 accel-
erated link from participating in load-balancing and dynamic routing.
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 traf-
fic. 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.
Servers
Appliance Inline Firewall Router

VPN
Other
Users
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.
Servers
Appliance Firewall Router
Other “One-Armed”
Users VPN
2-12 September 20, 2010

Figure 2-13 Alternate method of accelerating “one-armed” VPN traffic. Non-VPN traffic
bypasses the Appliance and will not be accelerated.
Servers Firewall
Router
Appliance
Other
Users “One-Armed”
VPN
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 as follows:
• Access Gateway Enterprise Edition, release 9.0.66 and up.
• Access Gateway Standard Edition, release 4.5.7 and up.
• Access Gateway Advanced Edition, release 4.5.7 and up.
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
starting in release 4.5.7. Configure Repeater support using the Access Gateway
Administration Tool:
1. Go to the “Global Cluster Policies” page and check the “Advanced Option” check-
box that says, “Enable TCP optimization with Repeater Plug-in.”
2. Make sure that the IP addresses used by the Repeater (redirector IP and manage-
ment IP) have access enabled on the “Network Resources” section on the “Access
Policy Manager” page.
3. For each of these addresses, enable all protocols (TCP, UDP, ICMP) and enable
“Preserve TCP Options.”
2-14 September 20, 2010

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 traf-
fic 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 accessi-
ble to the servers being accelerated.
This deployment is convenient for testing, since it requires no reconfiguration of the
router or network and doesn’t cause even a momentary disruption of network service.
The only traffic passing through the Appliance is Repeater Plug-in traffic. Other net-
work traffic is totally unaffected. In addition, there is no concern about asymmetric
routing, because the Repeater Plug-in traffic is addressed specifically to the Appli-
ance.
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.
Servers Firewall
Router
Appliance
Other
Users “One-Armed”
VPN
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, the partial bandwidth fea-
ture (available for inline mode) is not available. Any need to protect non-acceler-
ated 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 Appli-
ance-to-Appliance acceleration becomes desirable. In many cases this requires noth-
ing more than enabling WCCP on the Appliance and in your router, without recabling
the Appliance.
2-16 September 20, 2010

Chapter 3
Installing the Appliance
The procedures in this section will get your Appliance up and running.
• Expert users may prefer to use the Quick Installation Sheet.
• 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 nor-
mally 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 appro-
priate resources and information, and to make basic decisions about the installation:
1. Required: Review Chapter 2 before installing the Appliance.
Recommended: Read this document through Chapter 4 before beginning.
2. 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.
3. Verify that adequate power is available. Branch Repeater has a 200 W power
supply (100-240 V, 50-60 Hz). The Repeater 8300 and 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.
4. Select your basic operating configuration based on the guidelines in
Chapter 2: inline, WCCP, or virtual inline.
3.2 Pre-Installation
5. Determine whether your installation will use hardboost or softboost accelera-

tion. Softboost is the recommended mode for most installations.
Answer the following questions to determine the correct mode:
a. Have already determined that softboost doesn’t give the speed you
require in your point-to-point network?
b. Are you accelerating a fixed-speed, point-to-point WAN link or a

hub-and-spoke network with fixed-speed links, where the hub band-
width is equal or greater than the sum of the spoke bandwidths?
d. If you answered “Yes” to all these questions, you can try hardboost.
Note: Hardboost and softboost are mutually incompatible. The same Appli-
ance 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. Identify your cabling needs and acquire appropriate cables. Use the provided
cables if possible. See Section 7.2.
7. 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
Appliance WAN Router

LAN Subnet
(Example: 172.16.0.0/16) WAN or
Internet
Interface apA
Management IP Router Port IP
Signaling IP (Example: 172.16.0.1)
Example:
Management IP: 172.16.0.102
Signaling IP: 172.16.0.202

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.10).
9. 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.4.)
3.3 Installation
3.3.1 Install the Appliance Into the Rack
10. 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.
apA
Power Primary Aux1 Accelerated Pairs
RS-232 Ethernet Ethernet (Bridged Ethernet Ports
Serial Port Port With Bypass Feature)
On units without the
bypass feature, these
ports become apA
Accelerated
Power Serial Primary Aux1 Pair A
3.3 Installation
3.3.2 Install Ethernet Cables

Figure 3-3 Basic cabling, inline mode
Switch or Router or
Other Device Other Device
(see below) (see below)
WAN or
LAN See Below Use Existing Internet
Use Existing See Below
Cabling Cabling
Appliance
Detail: LAN-Side Cabling Detail: WAN-Side Cabling
Straight-Through Cross-Over
Blue Orange
Switch WAN
Router
Cross-Over
Straight-Through
Orange
Blue
Internal
Router Switch
Cross-Over Straight-Through
Orange Blue
DSL or
Cable
Server,
Modem
Client
Figure 3-4 Basic cabling, inline high-availability pairs
11. 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.”
Starting with release 4.1, units can be shipped with more than one pair of
accelerated LAN/WAN ports. See Section 4.5 for information on using multi-
ple 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. Starting with
release 4.1, these ports can be used for other purposes. See Section 4.5.
a. You can use either port of an accelerated pair as the WAN-facing port.
The unit auto-detects which port is which.

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 con-
nected to the Appliance use Gigabit Ethernet.
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.
d. (Virtual Inline Installations.) Install the units as shown in Figure 3-5

and Figure 3-6. Plug the cable into either one of the two ports of the
Acceleration unit’s accelerated pair (marked “Accelerated LAN/WAN
Ports”).
Figure 3-5 Basic cabling, virtual inline mode
Router
To To
LAN WAN
Cross-Over
Orange
Appliance
Figure 3-6 Basic cabling, virtual inline high-availability pair
To To
LAN WAN
Switch
HA Pair
3.3 Installation
e. (WCCP Installations.) Install the units as shown in Figure 3-7.

Figure 3-7 Basic cabling, WCCP mode
Switch Router
To To
LAN WAN
Appliance in WCCP Mode
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.
13. 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.
• (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 Turn on the Unit

14. 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 com-
mands.
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):
Figure 3-8 Front-panel configuration (Sheet 1 of 2)
Default display while the system boots.

15a. Branch Repeater The five buttons are shown on the right.
This display appears after the system is

initialized. The top line gives the current
BW 20 M/s accelerated bandwidth limit. The bottom
15b.
line is a performance bar graph (which
will be invisible if no accelerated
transfers are underway).
Pressing the down button displays the
Host Name
15c. hostname. This cannot be set from the
localhost.local front panel.
The accelerated interface (called “apA”
apA I/F starting in release 4.1, and unlabeled in
15d.
On earlier releases) should be on by
default.
Pressing the down button again displays
the VLAN tagging status. This defaults
apA VLAN id
15e. to off. If your network does not require
Off a VLAN id to reach the Appliance’s UI,
skip to step 15h.
If your network requires VLAN tagging:
Press the center button to enter the
VLAN tagging menu. Press the up
apA VLAN id button to turn tagging on. Use the right
15f.
On 0000 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
Save? ->Yes/No
15g. submit the VLAN number, and press it
On 1234 again to verify that you wish to keep it.
apA IP Address Pressing the down button again displays

15h.
0.0.0.0 the IP address.
Enter the Management IP address from

Step 7. Pressing the middle button
allows you to edit the IP address. The
apA IP Address
15i. left and right buttons move the cursor.
000.000.000.000 The up and down buttons increment
and decrement the IP address. Pressing
the middle button saves the address.
3.3 Installation
Figure 3-8 Front-panel configuration (Sheet 2 of 2)

Pressing the down button once more
displays the netmask. Press the middle
apA Netmask button to edit the netmask. The button
15j.
0.0.0.0 definitions are the same as when
changing the IP address. Press the
middle button to stop editing.
apA Gateway
15k. gateway address. Edit as with the IP
0.0.0.0 address.
Ignore Primary port entries. The
Primary port was introduced in release
Primary I/F
15l. 4.1. Do not configure it now. Press the
Off down button until you see the
“Restart?” screen.
Restart? restart screen. Changes do not take
15m.
effect until you restart. Press the middle
button to restart.
3.3.5 Browser-Based Configuration

16. (Virtual Inline Units) Configure your router to allow access to the Appliance’s
management IP address.
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 either “password” (release 5.7) or
“wanscaler” (releases 5.5 and 5.6). (You will change the Admin password in
Step 29.)
Note: Some older browsers are not supported. In particular, Internet

Explorer versions before 6.x are not supported.
3.3.6 Install the License

18. Following the procedure in Section 3.6, acquire the license for this Appliance.
19. In the browser-based UI, go to the “License Configuration” tab on the “Sys-
tem Tools: Manage Licenses” page. Add the license by clicking the “Add” but-
ton, assigning a name (any name) to the “License Name” field, and pasting
the license contents into the grey “License Content” box. (See Section 8.5.3.)
3.3.7 Configure the High-Availability Pair

20. 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 main (System Status) page of the first Appliance, press the
“Disable” button. This will disable acceleration until the HA pair is con-
figured.
b. Repeat for the second Appliance.
c. On the first Appliance, go to the “Settings: High Availability menu.” See

Figure 3-9. You will fill in all the fields on the “Status and Information”
tab and press the “Update” button.
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 doesn’t matter, so
long as it doesn’t collide with other VRRP devices on your network.
g. Fill in the other unit’s SSL Common Name (from the other unit’s “Con-
figure: High Availability” page) in the “Partner SSL Common Name”
field.
h. Press the “Update” button.
i. Repeat steps c-h on the second Appliance. Remember that one Ether-
net 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.
j. With your browser, navigate to the virtual IP address of the HA pair.

Enable acceleration. (Press the “Enable” button on the “System Status”
page.) The rest of the installation will be performed from this virtual
address.
k. Plug in the cable that was left disconnected.
3.3 Installation
Figure 3-9 High-availability configuration page.
3.3.8 Set Bandwidth Parameters

Figure 3-10 Initial bandwidth setup.
21. 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.
3-10 September 20, 2010

b. For now, set the “Bandwidth Limit (Send)” and “Bandwidth Limit
(Receive)” to 90% of the link bandwidth in the sending and receiving
directions, and press the “Update” button.
Some links are asymmetrical, leading to different values for the two
bandwidth limits. Figure 3-10 shows the settings for a DSL link with
384 kbps in the sending direction and 6 mbps in the receiving direction.
c. Verify that the “Full Bandwidth” option is selected.
The other choice, “Partial Bandwidth,” should be used only if the Appli-
ance is deployed in inline mode on a WAN router with a single LAN link
and a single WAN link. Full bandwidth should be used in all other cases.
Partial Bandwidth will cause the Appliance to slow down accelerated

traffic to make room for non-accelerated traffic, which can be useful
with VoIP and other latency-sensitive traffic if your router is not already
handling this task. If you selected “Partial Bandwidth,” press “Update.”
The “Minimum Send Rate” box will appear. This determines how far the
unit will back off for non-accelerated traffic. Allowing it to back off to
50% of the link speed is a good number to start with, so calculate 50%
of your link speed in kbps and enter it in the “Accelerated Traffic Mini-
mum Send Rate” box and press “Update” again.
d. Click on the “System Status” link at the side of the page. If the “Status”
row does not say “NORMAL,” click the “Enable” button.
3.3.9 Check Service Class Settings

22. On the “Configure Settings: Service Class Policy” 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 “HTTP (Internet)” service class policy. Select
the “Accelerate” checkbox and set compression to “Disk.” See
Figure 3-11.
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 “HTTPS (Internet)” service class policy.
Select the “Accelerate checkbox and set compression to “None.”
c ICA Settings. Enable acceleration and set compression to “Disk.”
d FTP Control Settings. Enable acceleration and set compression to

“None.”
3.3 Installation
Figure 3-11 Service Class Policies page.
3-12 September 20, 2010

e Unclassified TCP Settings. On the “Unclassified TCP” service class policy

(at the bottom of the page), uncheck “Accelerate” for now, if it isn’t
unchecked already.This will cause only known applications to be accel-
erated during your initial tests, allowing you to verify basic operation of
the installation. Once in a while, a non-standard network application
has difficulty coexisting with Repeater. This is typically confined to
legacy applications with little traffic demand. (You will re-enable
“Unclassified TCP” in Step 36.)
d. Press the “Apply” button to save your changes.
3.3.10 Configure Repeater Plug-in Support

Figure 3-12 Repeater Plug-in Support.
Follow these steps if you will use the Appliance with the Repeater Plug-in.
23. Go to the Appliance’s “Configure Settings: Repeater Plug-in” page. (See
Figure 3-12.)
a. Enter the Signaling IP from Step 7 in the “Signaling IP” field.
3.3 Installation
b. Leave the Signaling Port and Connection Mode at their default values.
These will be updated later.
c. Press “Update”
24. On the “Acceleration Rules” tab, create a list of subnets that are on the same
site as the Appliance. This will inform the Repeater Plug-in that it should send
traffic for the subnets to this Appliance.
25. 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 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 sup-
port 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 “Accel-
erated” rule (before matching an “Excluded” rule) are accelerated.
3-14 September 20, 2010

Figure 3-13 Setting Plug-in rules on the Appliance
3.3.11 (WCCP Only) Enable WCCP Mode and Configure Router

26. WCCP was introduced in release 3.0. To configure your Appliance for WCCP,
follow the procedures in Section 4.10.
3.3.12 (Virtual Inline Only) Enable Virtual Inline Mode and

Configure Router
27. Go to the “Tuning” page and select the “Return to Ethernet Sender” button
for now. (See Section 4.11.)
28. 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 WAN traffic to the Appliance when it enters the router
on any LAN port other than the one used by the Appliance.
Route outbound WAN traffic to the WAN interface if it entered the

router on the LAN port used by the Appliance.
3.3 Installation
Figure 3-14 Using the Tuning page for virtual inline modes.
3-16 September 20, 2010

3.3.13 Security: Change the Admin Password

29. For security, the Admin password should be changed from its default value.
Click the “User Accounts” link at the top of the page.
Releases 5.5-5.6: Delete the text in the “Password” field for the Admin
account and type in a new password: _____________. Click the
“Update” button. For more information about User Accounts, see Sec-
tion 8.6.2.
Release 5.7: Press the “Modify” button for the Admin account, check
the “Change” box, enter the new password: _____________ twice, and
press the “Update” button.
3.3.14 Disable Encryption on Outlook 2007 Clients

30. To get the benefits of Microsoft Outlook (MAPI) acceleration on Outlook 2007,
encryption must be disabled on the users’ systems. See Section 4.15.2.
3.4 Testing the Installation

Basic installation is complete.
31. Ping the remote Appliance at its management address to make sure it is run-
ning.
32. On your local Appliance’s management page, click the “Usage Graph” link.
Click on the “Toggle” link to turn on auto-refresh. The throughput graph will
now be updated periodically.
33. 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 con-
nections, including ssh, rsync, HTTP, SMTP, and so on.)
34. 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.
Send the file a second time. This should yield a compression ratio of at
least 100:1.
Compression ratios can be read from the “System Tools: View Logs”
page.
35. Check for CIFS acceleration:
a. Reboot a convenient PC or workstation and mount all the CIFS (Win-

dows) file systems that are normally accessed over the WAN. This
should ensure that it will open new CIFS connections, which will be
accelerated.
3.5 Troubleshooting
b. Look at the “Monitoring: CIFS Status” 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.14.1. If they are not listed at all, you have a rout-
ing or setup problem.
36. Your installation is up and running! Additional configuration you may wish to
perform includes:
a. Bandwidth tuning (Section 4.3.5).
b. Adding user accounts (Section 8.6.2).
c. Re-enabling the “Unclassified TCP” service class on all your Appliances

after they have been running smoothly for a while (several days would
be ideal). (Check the “Accelerate” box and select “Disk” compression.)
In the unlikely event that a legacy application refuses to run with Accel-
eration, create a service class policy that excludes it. (Section 8.3.11.)
3.5 Troubleshooting
3.5.1 Cabling and Duplexing Problems
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 us of straight-through vs. cross-over cables, which causes a total
loss of connectivity on 10/100 Mbps links.
• 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 Can’t Connect in Virtual Inline Mode

If LAN-to-WAN connectivity is lost in a virtual inline installation, check for the follow-
ing causes:
• Cabling errors (see above).
• IP forwarding not enabled. If you can reach the Appliance’s browser-based inter-
face via the LAN, but LAN-to-WAN connectivity does not exist, check the “Tuning”
page to see that IP forwarding is enabled.
3-18 September 20, 2010

• Router misconfiguration. Router loops or other configuration problems may be

preventing connections from succeeding.
3.5.3 No Transfers are Accelerated

If the transfer succeeds, but is not accelerated (the graph doesn’t show the band-
width as “Accelerated” bandwidth or shows no bandwidth usage at all) then:
• Inline mode: If the bandwidth is shown as “TCP” bandwidth, one or both of the
Appliances is not enabled, 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 mode: If the traffic doesn’t appear at all on the Appliance’s usage
graph, then the router isn’t routing the traffic through the Appliance.
• General: Your firewall or router may be overly aggressive about blocking connec-
tions, and is rejecting accelerated traffic because it has unusual TCP options.
3.5.3.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 accelera-
tion cannot take place, and accelerated connections will be blocked.
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 incom-
ing 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
3.5 Troubleshooting
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.4 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
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,
though it does not interfere with compression or flow control. See Section 4.14.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.5 Accelerated Connections Run Slowly

This can happen when the “Partial Bandwidth” option is selected inappropriately.
On each Appliance, look at the “Monitoring: Usage Graph” page. If the non-acceler-
ated (red) traffic exceeds the speed of the accelerated link, traffic on its way to some
other link is present in large volumes, and the Partial Bandwidth option must be dis-
abled. On each Appliance, change the “Configure Settings: Bandwidth Management:
Partial Bandwidth” option to “Full Bandwidth” and press the “Update” button.
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 data stream breaks down after a series
of full-sized packets is fragmented.
3-20 September 20, 2010

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 almost all
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 “Configure Settings: Tuning” page. Setting
“DefaultMss” to 1340 and “MaximumMss” to 1340 should solve the “VPN hang” prob-
lem.
3.5.7 Contact Us
Need help? Contact Citrix Support. See Section 11.1.
3.6 Licensing
The Branch Repeater family now uses Citrix Licensing, replacing the previous
Repeater licensing method. Existing Appliances will need a new license that is valid
under the new system. This license will be available at MyCitrix.com.
Note: Until you install a license, your Appliance will not accelerate connections.
Note: New Appliances are now shipped from the factory unlicensed.
Note: Repeater Plug-ins get their licenses dynamically from the Appliances they
communicate with. This is automatic and nothing needs to be done on the Client.
• If you are upgrading an older release of the Appliance (4.x or below for Repeater/
Branch Repeater, 1.0.x for Branch Repeater with Windows Server), you must
return your existing license and reallocate and regenerate it at MyCitrix.com.
• If you have a new Appliance, you do not need to exchange a license.
3.6 Licensing
Log Into My Citrix

Figure 3-15 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 representa-
tive.
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/Fullfilment.” On the “Product Upgrade/Fullfil-
ment” page, select “Upgrade Eligible Products.”
3-22 September 20, 2010

• Your existing pool of Appliances and Client licenses will be listed.

Figure 3-16 Navigating to the “Product Upgrades/Fulfillment” page.
• Select your product line and model number on two dropdown menus and press
“Submit”
Figure 3-17 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.6 Licensing
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.
• Branch Repeater VPX: 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
• Repeater/Branch Repeater: You will be asked for the host ID of the Appliance.
This can be found on the “System Tools: Update License” page for pre-5.0
releases and the “System Tools: Manage Licenses” page on newer releases. Enter
the host ID (without dashes) in the appropriate box.
Figure 3-18 The host ID is called “Licensing Mac” on release 4.x and “License Host Id” on
release 5.x.
• Branch Repeater with Windows Server: You will also be asked for the Appli-
ance’s host ID. This can be found on the “System Tools: Update License” page for
3-24 September 20, 2010

pre-5.0 releases and the “System Tools: Manage Licenses” page on newer
releases. Your Appliance may show multiple host IDs, separated by spaces,
instead of one. If so, use the rightmost one only. The Host ID must start with
003048. Enter the host ID in the appropriate box.
Figure 3-19 The host ID is called the “License Host Id” on release 5.0.x. Only the leftmost
host ID should be used.
• Follow the prompts to the end of the procedure.

Figure 3-20 Entering the license code.
3.6 Licensing
• At the end of this process, you will generate a license file. Download this file to
your computer. You will paste it into the Appliance in the next step.
• If your Appliance supports the Repeater Plug-in, repeat the procedure to convert
Client concurrent user entitlements into a concurrent user license for the Appli-
ance. You can allocate your Repeater Plug-in entitlements across your Appliances
as desired; however, each model has a maximum number of Plug-ins that it can
support, and allocating more than this will not be effective. The Branch Repeater
product lines does not support the Repeater Plug-in.
• 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 Sys-
tem/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.
Installing the License
(If your Appliance is running release 4.x software (1.0.x for Branch Repeater with
Windows Server), you must install release 5.x/1.5.x first.)
• Repeater/Branch Repeater: To install the license, go to the “System Tools: Manage
Licenses” page and select the “License Configuration” tab. Add a new licensse by
pressing the “Add” button.
• Branch Repeater with Windows Server: To install the license, go to the “Configura-
tion: Manage Licenses” page. Add a new license by clicking the “Add License” link.
• Type a name into the “License Name” Field. This name can be anything, but it can-
not be blank.
• Upload the license you obtained from Citrix from the “Load from File” button. (Pre-
vious releases used a cut-and-paste mechanism, but this has been changed to a
file upload).
• Press the “Install” (Repeater/Branch Repeater) or “Finish” (Branch Repeater with
Windows Server) button.
• After a delay, the license should install successfully.
• Repeater: Repeat for the Repeater Plug-in license file if you have one.
3.6.1 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
3-26 September 20, 2010

• 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
3.7
3-28 September 20, 2010

Chapter 4
Theory of Operation
4.1 In This Section

• How Acceleration Works (Section 4.2).
• Bandwidth Control (Section 4.3).
• QoS (Section 4.4).
• Ethernet Ports (Section 4.5).
• Autodiscovery and Autoconfiguration (Section 4.6).
• Forwarding Modes (Section 4.7-4.12).
• Compression (Section 4.13).
• CIFS (Windows Filesystem) Acceleration (Section 4.14).
• Microsoft Outlook (MAPI) Acceleration (Section 4.15).
• SSL Compression (Section 4.16).
• Service Classes (Section 4.17).
• Other Features (Section 4.18).
• Proxy Mode (Section 4.19).
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 com-
peting 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 traf-
fic. 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 band-
width limit, which configures the link speed.
4.2.2 Optimizations
Optimization techniques fall into these interrelated categories:
1. Lossless, transparent flow control.
2. Fair Queuing
3. QoS (Section 4.4)
4. WAN Optimizations
5. Compression (Section 4.13)
6. Windows Filesystem (CIFS) acceleration Section 4.14)
4.2.3 Lossless, Transparent Flow Control

Figure 4-1 Acceleration enhances performance transparently.
NETWORK A NETWORK B
WAN
Accelerator
Accelerator
WAN Link
Transparent,
AutoOptimized
Acceleration
LAN Link LAN Link
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%, it’s time to add more band-
width, 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 don’t 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 Appli-
ance 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 gate-
ways, 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.

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 connection’s 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 doesn’t back up, and without pend-
ing data in the queues, the queuing protocol doesn’t 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 addi-
tion, 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 applica-
tions 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 trans-
parently.
Fair queuing has no parameters to set: it adjusts itself dynamically to the traffic flow.
Fair queuing is a standard feature on all Appliances.
Figure 4-2 Fair queuing in action.
Per-Connection
Data Streams Queues
DATA
ACK
DATA
Sched-
uler
ACK
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 con-
sider 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 applica-
tions. 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 regard-
less 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.

Figure 4-3 Non-accelerated TCP performance plummets with distance
One-Way
Distance
(Miles)
Dialup
100,000
ADSL
Worldwide
10,000
T1
Cross-Country Long-Haul
(Limited by TCP)
10 Mb/s 1,000
Cross-State
T3
100
Cross-City
Short-Haul Mb/s 100
(MAN) (Limited by Line OC-3
Speed) OC-12
1Gb/s 10
Cross-Campus OC-48
OC-
192
1
10
Gb/s
0.1
0.01 0.1 1.0 10 100 1,000 10,000
Connection Speed (Mb/s)
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.)
Non-TCP traffic, such as UDP, is not accelerated. It is passed through immediately,

unchanged.
Note: Some applications that run under UDP by default, such as older versions of
NFS, can also run in TCP mode.
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 trans-
action 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 key-
presses or mouse movements, often consists of a single undersized packet per trans-
4.3 Bandwidth Control
action, 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-trans-
action RTO protection to other traffic.

The Appliance uses a rate-based sender for accelerated connections. This means that
accelerated data is sent at a constant rate when possible. This rate is selected by
bandwidth limits on the two Acceleration units involved in the connection. By setting
the bandwidth limit slightly lower than the link speed, congestion and packet loss are
eliminated, giving ideal link performance.
Only accelerated connections are rate-limited. Non-accelerated traffic is passed
through immediately.
4.3.1 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 Appliance’s bandwidth limit. If the bandwidth limit is set slightly lower than the
link speed, packet loss and latency will be minimized, while maximizing link utili-
zation. 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 accelerated connections, sending packets
based on a bandwidth limit that is set manually for each Appliance. The Appliances in
a connection negotiate sending and receiving rates between themselves. Each unit
has a sending limit and a receiving limit. The smaller of the sender’s sending limit and
the receiver’s receive limit is used as the bandwidth limit.
Note: Prior to release 4.1, softboost uses only the sending bandwidth limit. Start-
ing with release 4.1, both the sending and receiving limits are used. Interactive
performance is often greatly increased if both limits are set.
The rate at which a Acceleration unit sends depends on several parameters:

• The bandwidth limit, set on the Bandwidth Scheduler page of the management
interface. This value limits the maximum rate at which accelerated traffic will be
sent or received. Separate limits can be placed on sending and receiving.
• The licensed bandwidth limit, which is the highest value that can be entered in the
“sending BW limit” field. This is controlled by your license key. 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.5.3.
• Partial or Full bandwidth selection, which determines whether non-accelerated
traffic counts towards the sending bandwidth limit.
• System bandwidth schedules, a hardboost-only option that allows bandwidth to
vary with the time of day, and whether it is a weekday or weekend. These values
override the main bandwidth limit.
• Appliance-to-Appliance schedules, a hardboost-only option that allows limits with
individual acceleration partners. These values override the main bandwidth limit.
Bandwidth limits and schedules are set on the “BW Scheduler” page of the manage-
ment interface. See Section 8.3.1.
A connection between two Appliances will receive a fair share of the negotiated band-
width. For example, if there were 5 bulk-transfer connections on a 10 mpbs link, each
connection would receive 2 mbps.
Real-world traffic is more complicated than this, because many connections do not
require their full bandwidth share. Such connections get all the bandwidth they want,
and the unused surplus is divided between connections that can use it.
When an Appliance is talking to more than one Appliance-equipped site, its maximum
bandwidth is divided among the remote links.
4.3.3 An Appliance Should Become The Bottleneck Gateway

The fair queuing algorithm used by Appliances 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,
and queuing and latency are minimized.
Normally a setting of approximately 90-95% of the link speed gives optimum results.
For variable-speed links, or when a single Appliance is handling the traffic from two or
more links, the bandwidth limit should be set to 90-95% of the maximum expected
speed.
Note: Hardboost is recommended for fixed-speed links only. If used with a vari-
able-speed link, the bandwidth limit must not exceed that of the guaranteed band-
width (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 90-95% of 1.54 mbps, or 1390-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
90%-95% of the aggregate bandwidth (twice the value in Example 1, or 2780-2926
kbps). The Appliances at the two spokes would set their bandwidth limits as in Exam-
ple 1 (1390-1463 kbps). Either hardboost or softboost can be used
Note: Set the bandwidth limits of each Appliance to match the speed of its local
link, without regard to the speed at the other end of the WAN. This simplifies con-
figuration 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 bot-
tleneck speed on affected Appliance, instead of the local speed.
Example 3: Suppose you have a hub-and-spoke deployment as above, but Site 3

does not have an Appliance. In this case, what you really have is a T1 point-to-point
deployment. Since the Appliance ignores non-accelerated traffic, this case is really the
same as Example 1.
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
(90-95% of a t1’s 1.54 mbps, or 1390-1453 kbps). Hardboost works poorly in mesh
deployments, so softboost should be used.
Example 5: Suppose you have two sites, Site 1 and Site 2, that are connected by a
pair of redundant T1 links. One is active and one is passive. Each site has a single
Acceleration unit. Because only a one of the links is used at any given time, the band-
width of the backup link should be ignored. If the bandwidths of the two links are the
same, then hardboost can be used. If the backup link is slower, then hardboost would
overdrive the link, 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 90-95% of 45 mbps, or

40500-4275 kbps, while the branch-office Appliance should have its sending speed
set for 90-95% of 384 kbps (346-365 kbps) and its receiving speed set for 90-95% of
6 mbps (5400-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.
4.3.4 Reserving Bandwidth For Non-Accelerated Connections

Two options are available for dealing with non-accelerated connections: the “Partial
Bandwidth” option and the “Full Bandwidth” option.
4.3.4.1 Partial Bandwidth

The partial bandwidth option is used on inline, point-to-point, fixed-speed links when
latency-critical non-accelerated traffic, such as VoIP, sometimes needs to use part of
the Appliance’s bandwidth.
With the partial bandwidth option, non-accelerated traffic counts towards the band-
width limit. In effect, this means that non-accelerated traffic has precedence over
accelerated traffic, which backs off byte for byte.
Use partial bandwidth only on point-to-point, inline links where the WAN router has
only a single LAN link and a single WAN link. In all other cases, use full bandwidth.
The reason partial bandwidth should be avoided in other modes is that the Appliance
can’t tell one kind of non-accelerated traffic from another. If your router has two WAN
links, the Appliance will unnecessarily slow down accelerated traffic on one link
because of non-accelerated traffic on the other one. If your router has two LAN links,
the Appliance would slow down to make room for LAN-to-LAN traffic. But in a router
with one WAN link and one LAN link (which is the most common case), all traffic on
the LAN port is destined for the WAN, and vice versa, and partial bandwidth works
very well.
The bandwidth limit should be set to 90%-95% of the link bandwidth, as usual. When
there isn’t any non-accelerated traffic, accelerated traffic can use virtually the entire
link.
Note: In deployments where VoIP or other non-accelerated traffic needs to be pro-

tected, but partial bandwidth is not an option, enable the QoS options on your
router. VoIP QoS is built into all modern, commercial-quality routers. See your
router documentation.
4.3.4.2 Full Bandwidth

The full bandwidth option reserves the full amount specified by the bandwidth limit for
accelerated traffic. It is used when accelerated transfers need to operate at predict-
able speeds. With full bandwidth, accelerated transfers have precedence; non-accel-
erated transfers will back off to accommodate them.
The Appliance will take as much bandwidth as its bandwidth limit (and the other ele-
ments of the bandwidth algorithm) allows. It will do this at the expense of non-accel-
erated traffic. If the Appliance bandwidth is set lower than the link speed, the
bandwidth left over is available for non-accelerated connections.
For example, if you have a 45 Mbps link and your Appliance is set for 30 Mbps, 15
Mbps is left over for non-accelerated traffic. Non-accelerated traffic behaves exactly
as if it were on a dedicated 15 Mbps link.
When an Appliance is idle, it uses no bandwidth, and non-accelerated connections can
use the full bandwidth of the link. When an Appliance uses only part of its bandwidth
(for example, when the application cannot handle data at full speed), non-accelerated
connections can use the leftover bandwidth.
In short, an Appliance splits the link into two virtual links: accelerated and non-accel-
erated. Each acts as if the other weren’t there. Accelerated traffic always behaves as
if the non-accelerated traffic didn’t exist, and takes its full allocated bandwidth
regardless of the amount of non-accelerated traffic. Non-accelerated traffic also
behaves as if it had the link to itself, but the apparent size of the link is variable,
depending on how much accelerated traffic there is.
4.3.5 Performance Tuning

For initial testing, a value of 90% 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 band-
width 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 Acceleration unit 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. As the bandwidth limit increases, you will reach a point
where ping time start to go up but throughput remains flat or declines. The band-
width 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 band-
width 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 hard-
boost, since it leads to heavy packet losses. In softboost, it merely causes latency to
become uncontrolled.
In most cases, it is not desirable to devote 100% of the link bandwidth to a hardboost
Appliance in full bandwidth mode, even if all of your communication will be between
Appliance-equipped sites. The reason is that the Appliances currently accelerates only
TCP connections, so UDP- and ICMP-based packets such as DNS queries and pings will
be blocked whenever accelerated transfers are making full use of the link. This would
cause seemingly random failures. Setting aside a few percent of the link bandwidth
for unaccelerated traffic will prevent this. This consideration does not apply to partial
bandwidth mode.
4-10 September 20, 2010

4.4 QoS
QoS was introduced in release 4.1. It consists of three parts:
1. Dynamic, zero-config QoS that automatically gives precedence to interactive traf-
fic.
2. Policy-based QoS that allows the administrator to allocate bandwidth into different
categories.
3. A XenApp (ICA/Citrix Presentation Server) feature that optionally maps traffic of
different priority levels into the administrator-defined categories.
Of these, the dynamic, zero-config QoS is the most important, since for the majority
of installations it works so well that no additional configuration is necessary. The
remainder of the QoS system exists to adjust the Appliance when this default
behavior falls short in some way.
QoS is applied only to accelerated traffic, since its purpose is to adjust the bandwidth
priority of selected accelerated traffic classes. Non-accelerated traffic is not subject to
QoS.
QoS implements a simple, general method of separating traffic into five queues, each
of which is assigned a percentage of the link bandwidth (more precisely, the band-
width limit). These queues are initially named “A” through “E,” but can be renamed
according to their function. Fair queuing is performed within each queue, and
weighted fair queuing is performed between the queues. See Figure 4-4.
Figure 4-4 QoS in operation. QoS divides traffic into different queues, each of which has a
different bandwidth slice. Weighted fair queuing is performed within each queue and between
the queues.
Queue A: 80%
Data
Connections
QoS
Scheduler
Queue B: 20%
Data
Connections
While the queues each have a specified bandwidth percentage, each queue will lend
its leftover bandwidth to the other queues. This means that the bandwidth assign-
ments are minimum levels, not maximums.
This results in a QoS system embodying Repeater’s “accelerator” philosophy. Nothing
stands in the way of a connection using bandwidth that would otherwise be wasted.
The bandwidth assignments only come into play when there is competition for the
bandwidth; that is, when the link is saturated.
4.4 QoS
4.4.1 QoS Example 1: FTP Background Queue

An organization has a set of FTP bulk-transfers that normally run only at night. By
using QoS queues, these transfers can safely be allowed to run during the day as well,
using mostly idle bandwidth. This can be done by
1. Adjusting the QoS allocations as shown in Figure 4-5.
Figure 4-5 Splitting the bandwidth 90/10 between two queues
2. Altering the Service Class Policy queue assignments as shown in Figure 4-6.
Figure 4-6 Assigning the “FTP Data” service class to the “FTP” queue.
3. QoS configuration is complete. Figure 4-7 shows the results, where normal,
non-FTP traffic (light green) dominates the link at first, but then goes idle, allow-
ing FTP traffic (dark green) to use the full link bandwidth.
4-12 September 20, 2010

Figure 4-7 QoS example, showing FTP class (dark green) using either 10% of the link or the
unused link bandwidth, whichever is more.
4.4 QoS
4.4.2 QoS Example 2: Guaranteed Bandwidth for Disk

Replication
Suppose the WAN in example 1 also runs an ongoing disk synchronization task that
has an internal bandwidth limit set to 5,000 kbps (25% of the Appliance’s bandwidth
limit). Obviously, 25% of the link represents a “fair share” of the link bandwidth when
there are four active connections, but, if more connections are present, fair queuing
will not give the replication task all the bandwidth it wants.
We can deal with this issue easily through QoS. The method is as follows: the applica-
tion wants 25% of the link speed, but to be on the safe side, we will allocate more --
35%. This allows some burstiness in the application, in case the QoS scheduler and
the application schedule work on different timescales (which they probably do). We
can adjust the value later, depending on whether the replication task is falling behind
or not.
The following steps will create the new queue:
1. On the “Configure Settings: Service Class” page, create a new service class called
“Disk Replication” that matches the IP and port of the replication partner. (See
Section 4.17.)
2. On the “Configure Settings: QoS” page, rename Queue C to “Replication” and
assign it 35% of the link speed. (You will have to reduce the Queue A allocation
from 90% to 55%).
3. On the “Configure Setting: Service Class Policy” page, move the “Disk Replication”
service class to the top of the list of policies (to ensure that it isn’t masked by
other policies), change the Queue assignment to “Replication,” make sure “Flow
Control” is checked and “Compression” is set to “Disk” (if available; “Memory” oth-
erwise), and press the “Update” button.
4. Configuration is complete.
Figure 4-8 Configuration with a queue for FTP and another for disk replication.
4-14 September 20, 2010

4.4.2.1 Using QoS Effectively

To use QoS effectively, keep the following points in mind:
• Try the default settings first. Most installations do not require manual QoS set-
tings. Use these only to adjust traffic when the auto-optimizing zero-config behav-
ior falls short in some area.
• QoS is dependent upon the bandwidth limit. Set both the sending and receiving
bandwidth limits appropriately. If the bandwidth limit is set higher than the link
speed, QoS will have little or no effect. This is because a too-high bandwidth limit
will convince the QoS system that some queues are under-utilized and have band-
width to lend to other queues. This results in the bandwidth apportionment never
being observed.
• Use as few queues as possible. The QoS system supports five queues. Often only
two are required, when either there is a special process that needs to run at a cer-
tain minimum speed (such as disk replication), or when there is a background pro-
cess that should use mostly idle bandwidth. Use no more queues than you have
clearly defined traffic categories.
• Do not worry too much about the bandwidth allocation. In a few cases (disk repli-
cation), the required bandwidth is known. Assign this number, plus a generous
safety margin, to the queue. In other cases, simply dividing the bandwidth evenly
between classes will give you a good start.
• Monitor the QoS graphs and statistics to give you an idea of how the system is
working. See Section 8.2.7.
4.4.3 Dynamic QoS For Citrix XenApp (ICA)

QoS has special features for the Citrix XenApp (Presentation Server) ICA protocol. ICA
embeds a dynamic, four-level priority level into its data stream. These priority levels
can be assigned to QoS queues. (By default, they are all assigned to Queue A.)
ICA priorities are mapped to queues on the “Configure Settings: Service Class Policy
Page,” as shown in Figure 4-9.
Figure 4-9 Mapping ICA priorities to QoS queues.
4.4.3.1 Example of ICA QoS

Let us build upon QoS example 1. We wish to divide the ICA traffic into appropriate
queues.
4.4 QoS
Because all service classes are assigned to Queue A by default, it is convenient to

leave Queue A as the default queue. We have five queues in all, but one is already
assigned to FTP, and Queue A is being left as the default queue. This leaves us with
three unassigned queues for four ICA priority levels. This means we will have to
assign two levels into one queue. We will do this to the two highest-priority queues,
on the grounds that high-priority traffic is interactive, low-bandwidth traffic, and it will
be easy to over-provision the queue so there’s plenty of bandwidth for both priority
levels.
Thought process:
• We have already defined the FTP queue as 10% of the link bandwidth. We will not
change this.
• We have 90% of the link left to allocate.
• Our rule of thumb is, “When in doubt, divide bandwidth equally.” This tends to
over-provision the interactive classes (because interactive traffic uses relatively
little bandwidth), ensuring snappy performance. Any excess allocation will be
released to the less-interactive classes, so there is no waste.
• We have two ICA classes assigned to one queue.
One solution is as follows:
Queue A (Default Queue) 20%
Queue B (FTP) 10%
Queue C (ICA Real-Time and Interactive) 30%
Queue D (ICA Bulk-Transfer) 20%
Queue E (ICA Background) 20%
This divides the bandwidth evenly, except for our FTP bandwidth, which we are keep-
ing at 10%, and the high-priority ICA bandwidth, which we are over-provisioning with
30%.
Another approach would be to combine the FTP and ICA Background traffic into the
same queue, since they are both low-priority bulk-transfer categories:
Queue A (Default Queue) 20%
Queue B (FTP) and ICA Background 20%
Queue C (ICA Real-Time) 20%
Queue D (ICA Interactive) 20%
Queue E (ICA Bulk Transfer) 20%
4.4.4 Notes on QoS

• QoS is a sender-side system (as are nearly all QoS systems). This means that it
controls outgoing traffic according to your queue definitions, but accepts incoming
traffic as-is. This is not important on point-to-point links, since the sender and
receiver see the same packet stream. On hub-and-spoke and mesh deployments,
the receiver’s view is different from the sender’s whenever two or more sites are
4-16 September 20, 2010

sending to the receiver at once. As with any other sender-side QoS system, this
leads to a loss of control over latency and queue ratios during the period of con-
tention.
• QoS operates only on accelerated traffic, since it is an extension of fair queuing.
Inline installations can also use the “Partial Bandwidth” feature to protect VoIP and
other latency-sensitive non-accelerated traffic.
• QoS (in softboost mode) is compatible with other QoS solutions. QoS will work in
tandem with your existing QoS solutions, if present. The only things you need to
keep in mind are:
• The Appliance should be on the “fast side” of the chain, that is, on the LAN side
of any QoS-enabled routers or Appliances. This will prevent the other devices
from defeating Compression by slowing down the uncompressed data stream
to WAN speeds.
• Hardboost should not be used. Hardboost is unresponsive to QoS techniques
such as congestion signals or increased queueing. Use softboost on networks
that have non-Repeater QoS.
4.5 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 accelera-
tion. The motherboard ports can be used for secondary purposes. Most installations
use only the bridged ports.
Some Branch Repeater units will have only the motherboard ports. In this case, the
two motherboard ports are bridged.
Figure 4-10 Ethernet ports.
4.5 Ethernet Ports
The ports are named as follows:

Figure 4-11 Ethernet port names.
Motherboard port 1 Primary (or apA.1 if no bypass card is present)
Motherboard port 2 Auxiliary1 or Aux1 (or apA.2 if no bypass card is present)
Bridge #1 Accelerated Pair A (apA, with ports apA.1 and apA.2)
Bridge #2 Accelerated Pair B (apB, with ports apB.1 and apB.2)
Note: Acceleration is supported only on Accelerated Pairs. The Primary and Aux1
ports are for UI and group-mode backchannel access.
4.5.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. Inline
and single-ended connections may occur simultaneously.
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 main-
tains network continuity but makes the bridge ports inaccessible.
4.5.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.5.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 Set-
tings: Interface” page.
Notes about parameters:
• Disabled ports will not respond to any traffic.
• The browser-based UI is active on all enabled ports. However, UI access on accel-
erated pairs can be disabled by not assigning an IP address to the accelerated
pair.
• To secure the UI on ports with IP addresses, select HTTPS rather than HTTP on the
“UI” page.
4-18 September 20, 2010

• 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.5.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.12).
• A backchannel for high-availability mode (See Section 7.4).
4.5.5 The Aux1 Port

The Aux1 port is identical to the primary port. If the Aux1 port is enabled and the Pri-
mary port is not, the Appliance takes its identity from the Aux1 port’s IP address. If
both are enabled, the Primary port sets the units identity.
4.5.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 redun-
dant links, connecting to the same site. Redundant links can be either load-balanced
or main-link/failover-link pairs.
Note: Multiple bridges are not supported under group mode.
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
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.
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 ambi-
guity 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.4 for more about high availability mode.)
4.6 Autodiscovery and Autoconfiguration
Figure 4-12 Using dual bridges
WAN to
LAN Site X
LAN
Two Accelerated WAN to
Bridges Site Y
LAN Load-Balanced
LAN WAN Links
Two Accelerated
Bridges
LAN WAN
LAN WAN
HA Pair
4.6 Autodiscovery and Autoconfiguration

Acceleration units detect each other’s 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-13.
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 auto-
matically. In addition, the same process allows autoconfiguration. The two Appliances
use the TCP header options to exchange operating parameters, including the band-
width limits (in both the sending and receiving directions), the basic acceleration
mode (hardboost or softboost), and the acceptable compression modes (disk, mem-
ory, or none). Everything an Appliance needs to know about its partner is exchanged
with each connection, allowing per-connection variations; for example, per-ser-
vice-class variations in the allowable compression types.
4-20 September 20, 2010

Figure 4-13 How autodiscovery works.
Client Appliance Appliance Server
1 SYN Tagged
2 SYN
SYN
3
4
5
SYN-ACK SYN-ACK
6 Tagged
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-spe-
cific TCP header options to it and adjusting its window size.
3. The second Appliance reads the TCP options, removes them from the packet, and for-
wards 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 fire-
walls are all unaware of this; it happens transparently.
4.6.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 con-
nection 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.7 Forwarding Modes
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.3.1. The
basic procedure will be similar for other firewalls.
4.7 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.
This packet forwarding can be done in different ways. While these three methods are
called “modes,” all are available simultaneously.
Figure 4-14 How Ethernet and IP addresses determine the forwarding mode.
Destination IP Addr. Ethernet Addr. Mode
Foreign Foreign Inline or Pass-through
Foreign Local Virtual Inline or L2 WCCP
Local Local Direct (UI access, etc.)
Local (VIP) Local Proxy Mode
Local (WCCP GRE

Local WCCP Mode
Packet)
Local (Redirector IP) Local Redirector Mode
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-15). In this mode, the Appliance
appears (to the rest of the network) to be an Ethernet bridge. This mode is
explained in Section 4.8. 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 Appliance’s redirec-
tor IP address. The Appliance replaces the source address of the packet with its
true destination and forwards it to the server.
4-22 September 20, 2010

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
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.8 Inline Mode

Figure 4-15 Inline mode, used to accelerated all the traffic on a WAN.
NETWORK A NETWORK B
WAN
Appliance
Appliance
TCP/IP traffic passing through
two appliances is accelerated
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 Appliance’s 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.8 Inline Mode
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.8.1 Accelerating an Entire WAN

Figure 4-15 shows a typical configuration for inline mode. For both sites, the Appli-
ances are placed between the LAN and the WAN, so all WAN traffic that can be accel-
erated 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 queu-
ing 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.8.2 Accelerating Some Systems But Not Others

To reserve the Appliance’s 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-16.
Figure 4-16 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-24 September 20, 2010

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 con-
trol is up to the bottleneck gateway, and interactive responsiveness may suffer.
4.9 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.9.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 doesn’t require a control connection.
Figure 4-17 Repeater packet flow, showing the address changes used by Redirector mode.
1 The user's application opens a TCP

connection to the server, sending a
TCP SYN packet.
Src: 10.0.0.50, Dst: 10.200.0.10

Repeater Plug-in Repeater Appliance Server
The Repeater Plug-in looks up the
2 dst address and decides to redirect 10.0.0.50 10.200.0.201 10.200.0.10
the connection to the appliance at
10.200.0.201. 1 2
Src: 10.0.0.50, Dst: 10.200.0.201 3
(10.200.0.10 is preserved in a TCP 4

option field. Options 24-31 are used
for various parameters.) 5
The appliance accepts the connection 6
3
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

6 The connection is now fully open. The client and server send packets
The appliance rewrites the addresses back and forth via the appliance.
5 and forwards the packet to the Plug-
in (placing the server address in an While the addresses are altered in Redirector mode, the destination
option field). port numbers are not (though the ephemeral port number may be).
The data is not encapsulated. Redirector mode is a proxy, not a
Src: 10.200.0.201, Dst: 10.0.0.50 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.9 Redirector Mode
Figure 4-17 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 inter-
cepting 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
server’s 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 indi-
cated 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.9.2 Configuring Redirector Mode

Redirector mode’s method of operation requires only one Ethernet port, but redirector
mode can be combined with inline mode (which requires two ports) or other deploy-
ment modes: virtual inline, WCCP, etc. See Figure 2-10.
Figure 4-18 Basic cabling, redirector mode
Switch Router
To To
LAN 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 Appli-
ance on the Appliance’s “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-26 September 20, 2010

4.10 WCCP Mode

Figure 4-19 Basic cabling, WCCP mode
Switch Router
To To
LAN 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 Ether-
net segment as the router, direct L2 forwarding. Such traffic is treated by the Appli-
ance as if it were received in inline mode.
A WCCP-mode Appliance requires only a single attached Ethernet port. It may be
deployed anywhere on the LAN, though ideally there would be no more than one
switch between the Appliance and the router, to minimize contention for LAN band-
width.
4.10.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 Appli-
ance behaves as if the traffic were inline. GRE encapsulation allows the Appliance to
be on a different Ethernet segment or subnet from the router, (though it is a good
practice to keep the two as close together as possible).
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 seg-
ment 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 Appli-
ance’s heartbeat is lost, the router bypasses the Appliance until the heartbeat is
4.10 WCCP Mode
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.
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, rees-
tablishing 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 periodi-
cally check whether the service group is still active with the other Appliance, and will
handle the service group when the other Appliance becomes inactive.
4.10.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.10.3 Limitations
• Inline and WCCP traffic should not be mixed on the same Appliance if this can be
avoided, due to the possibility of router loops. If this cannot be avoided, add the
following statement on the router interface connected to the Appliance:
ip wccp redirect exclude in
• 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.10.4 Best Practices

• For sites with a single WAN router, use WCCP whenever inline mode is not practi-
cal.
• 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 vir-
tual inline mode.
4.10.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-28 September 20, 2010

4.10.6 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.)
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 inter-
face. 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:
^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:
^Z
4.10 WCCP Mode
4.10.7 Appliance Configuration

Configuration takes place on the “Configure Settings: WCCP” page (See Section
8.3.17 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.
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.2.8 for more information about
this UI page.)
7. Send traffic over the link and verify from the Usage Graph or Accelerated Connec-
tions pages that connections are being accelerated.
4.10.8 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 adver-
tises 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 con-
nected, 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.”
4-30 September 20, 2010

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
“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.11 Virtual Inline Mode
4.10.9 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.2.8.
Log Entries. The “View Logs” page will have an entry when WCCP mode is estab-
lished or lost.
Figure 4-20 Log entry when WCCP mode is enabled.
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: 172.16.2.4
Protocol Version: 2.0
Service Identifier: 51
Number of Cache Engines: 0
Number of routers: 0
Total Packets Redirected: 19951
Redirect access-list: -none-
Total Packets Denied Redirect: 0
Total Packets Unassigned: 0
Group access-list: -none-
Total Messages Denied to Group: 0
Total Authentication failures: 0

Note: Virtual inline mode is inferior to inline mode and WCCP, and should
only be used when both of these two modes are impractical.
The Appliance can be deployed in a virtual inline mode where selected traffic is redi-
rected 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 rout-
ing issues faced when two or more WAN links are used.
4-32 September 20, 2010

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.11.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.
Virtual inline mode allows a router to send packets to Appliances in a way that is com-
pletely transparent to the rest of the network.
The Appliance determines the forwarding method on a packet-by-packet basis, mean-
ing that inline, virtual inline, and proxy modes can be mixed in the same unit.
4.11.1.1 Example
Figure 4-21 shows a simple network where all traffic destined for the remote site is
sent to the gateway router.
Figure 4-21 Virtual inline example. Appliances are at 192.168.1.200 and 192.168.2.200.
Local Site Remote Site

Local Network Remote Network
10.10.10.0/24 20.20.20.0/24
Router Router
FE 0/0 FE 0/1 FE 0/1 FE 0/0
FE 1/0
FE 1/0
Appliance Appliance
192.168.1.200 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.11.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 (using the
“Configure Settings->Management IP” field).
• Virtual Inline settings are on the “Configure Settings->Tuning” menu. (See Figure
4-22.)
• Routers are configured to redirect both incoming and outgoing WAN traffic to the
Appliance.
4.11.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 ele-
ment 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 out-
put 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-34 September 20, 2010

Figure 4-22 Virtual inline uses either “return to sender” or “forward to gateway” mode.
4.11.3 The Need for Policy-Based Rules

Both forwarding methods will create routing loops if the routing rules do not distin-
guish 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 router’s Ethernet ports to the Appli-
ance, 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 for-
warded back to the Appliance; others can be.
The basic routing algorithm to be used is:
• Don’t 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.
• If the “partial bandwidth” feature is used, all WAN traffic should be routed through
the Appliance.
• If the “full bandwidth” feature is used, only TCP-based WAN traffic need be routed
through the Appliance. However, there is no harm in routing 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 sys-
tems 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.11.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-availabil-
ity” 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 sup-
port 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.
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-36 September 20, 2010

4.11.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, don’t 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
!
ip address 172.68.1.5 255.255.255.0
ip policy route-map wan_side_map
!
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 it’s 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
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
!
ip address 20.20.20.5 255.255.255.0
ip policy route-map client_side_map
!
ip address 171.68.2.5 255.255.255.0
ip policy route-map wan_side_map
!
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
!
permit ip 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255
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 origi-
nating 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 router’s doc-
umentation 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 side’s configuration is reproduced here):
!
permit tcp 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255
permit tcp 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255
!
4-38 September 20, 2010

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 “don’t
care” bit.
4.11.6 Virtual Inline Mode For Multi-WAN Environments

Figure 4-23 Asymmetric routing example, with redundant links at the local site.
Local Network:
10.10.10.0/24
Routers
Remote Network:
FE 0/1
20.20.20.0/24
Router
FE 0/0
FE 1/0 FE 0/1 FE 0/0
FE 1/0
FE 1/0
FE 0/1
FE 0/0
192.168.2.200
192.168.1.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-23.
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 pre-
ferred. In a more hierarchical network, one router might be preferred over the other,
and would be configured as the Appliance’s default router.
4.11.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-24. 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 con-
figuration tables, rather than the IP address of an individual appliance.
See Section 7.4 for a complete description of High Availability mode.
4.12 Group Mode
Figure 4-24 High-availability example.
Local Network:
10.10.10.0/24
Routers
Remote Network:
FE 0/1
20.20.20.0/24
Router
FE 0/0
FE 1/0 FE 0/1 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 Appliance
192.168.1.201 192.168.1.202
4.12 Group Mode

Note: Multiple bridges are not supported under 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 Appli-
ance, 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.
4-40 September 20, 2010

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-25 Group mode over redundant links
WAN
WAN
Group Mode Group Mode
Figure 4-26 Group mode over non-redundant links with possible asymmetric routing
WAN
WAN
WAN
Group Mode
Figure 4-27 Group mode to connect multiple nearby sites.
Campus A
Rest of
High-Speed WAN Network
MAN Link
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.12 Group Mode
4.12.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.12.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.
• 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.12.2 How Group Mode Works

In group mode, the Appliances that are part of the group each take ownership for a
portion of the group’s 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 for-
wards 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-28.
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 mecha-
nism, and simply accept the routers’ forwarding decisions.
4-42 September 20, 2010

Figure 4-28 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
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
Figure 4-29 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 4
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.12 Group Mode
4.12.3 Owner Selection

Figure 4-30 Using IP-based selection in a primary/backup link topology
Set to handle all

traffic (sending
Primary none to partner)
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.
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 nor-
mally. 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 forward-
ing. In this way, group mode leaves the router’s link selection unchanged.
Because the group-mode hash isn’t 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 dou-
bled, which halves the Appliance’s 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 Appli-
ances, 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.12.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-44 September 20, 2010

4.12.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 open (blocking traffic through the Appliance) or closed
(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 Appli-
ances 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.12.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, espe-
cially if the links are of different sizes. This can be dealt with in two ways:
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.12.5 Enabling Group Mode

Group mode requires that two or more Appliances be added to the group. An Appli-
ance 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 man-
agement 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 mem-
bers (groups of three or more are supported but are rarely used). Type the other
4.12 Group Mode
Figure 4-31 Group mode page.
group member’s IP address in the “Member VIP” field. This is the IP address of the
port used by the other Appliance for group-mode communication.
3. Enter the other group member’s SSL common name in the “SSL common name”
column. (The SSL common name is listed on the other Appliance’s “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 doesn’t block traffic, but any
member failure causes a complete loss of acceleration, since it causes the oth-
ers 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.
4-46 September 20, 2010

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.12.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 doesn’t
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.
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.
4.13 Compression
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-32 Forwarding rules
4.13 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.
Unlike most compression methods, the compression history is shared between con-
nections, 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 Appliance’s 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,
4-48 September 20, 2010

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 Appliance’s disk as well as memory, providing up to 600 GB
of compression history.
4.13.1 XenApp 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.
Note that XenApp compression 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. Update Appliances to release 5.0 or above.
2. Change ICA service class policy on all Appliances to “Accelerate, Disk Com-
pression.” This is done on the “Configuration: Service Class Policy” page on each
appliance’s UI. This was not the default with older releases, and needs to be
changed manually.
3. Update XenApp servers and clients. 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 compres-
sion:
c. Server package PSE450R03W2K3WS.msp or later.
d. Client version 11.0.0.5357 or later.
4. Verify XenApp server registry settings. 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 serv-
ers, 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 fol-
lowing option on the client under “Citrix Program Neighborhood->Custom ICA
Connections.” Right-click a connection icon and then uncheck “Properties->
Options->Enable Session Reliability.”
4.13 Compression
6. Verify acceleration. Start XenApp sessions over the accelerated link. On the
“Monitoring: Active Connections” page on the Appliances, accelerated ICA connec-
tions should appear. A compression ratio of greater than 1:1 indicates that com-
pression 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.13.2 How Compression Works
4.13.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 perfor-
mance, 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 Appli-
ances), the second and subsequent occurrences will be compressed.
Other than enabling and disabling compression on the Service Class Policy page,
there are no parameters (see Section 4.17). Additional parameters would be superflu-
ous, 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 def-
initions do this.
Compression involves pointers to previously encountered runs of data, interspersed
with runs of data that hasn’t been seen before, which is sent as literal data. The point-
ers to previously encountered data are quite small, no more than a few bytes. Reduc-
ing 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.
4-50 September 20, 2010

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, compres-
sion 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 Appli-
ances simultaneously. These Acceleration Partners can support compression or not in
any combination.
4.13.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 Appli-
ance model, from a minimum of 128 GB on Branch Repeater to a maximum of 600 GB
on the Repeater 8800.
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 poten-
tial 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 com-
pression can easily reduce this 100 GB transfer to 1 GB (transferring only the differ-
ences), 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 Ser-
vice Class Rules, but you can leave disk+memory compression enabled for all streams
that aren’t encrypted.
4.13 Compression
4.13.3 Enabling/Disabling Compression

Compression is enabled on a per-service-class basis on the “Configure Settings->
Service Class Policy” 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
• None, meaning that compression is disabled. This should be selected for services
that are always encrypted, plus the FTP Control channel.
Figure 4-33 Using service class policies to alter compression settings.
4.13.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 pro-
tocol.
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 diffi-
cult to predict in practice.
4-52 September 20, 2010

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.
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 com-

pression, 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 repre-
sentative 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.13.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 Appli-
ance to Appliance.
4.13.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 com-
pression 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
4.14 CIFS (Windows Filesystem) Acceleration
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.

The CIFS acceleration feature provides a suite of protocol-specific performance
enhancements to CIFS-based (Windows and Samba) file transfer and directory brows-
ing, including both enhancements to CIFS transport and to related protocols such as
DCERPC.
CIFS acceleration is supported on all models. CIFS is a TCP-based protocol and bene-
fits from flow control. However, CIFS is implemented in a way that is highly subopti-
mal 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 acceleration.
For example, CIFS 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. Accel-
eration 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-34.
The modes of CIFS acceleration are:
• Large file reads and writes
• Small file reads and writes
• Directory browsing.
Large file reads and writes. These 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.
4-54 September 20, 2010

Figure 4-34 CIFS server/client support.

Product Server Client
Windows Vista Yes* Yes*
Windows 2003 Yes Yes
Windows XP Yes Yes
Windows 2000 Yes Yes
NetApp Yes N/A
Samba Yes No
Windows NT Yes No
Windows ME and earlier No No
Others See Note
*Windows Vista connections will be accelerated if Vista is used as the client or the server, but
not both. For example, a connection between a Vista desktop and a Windows 2003 server
will be accelerated, but a connection between a Vista desktop and a Vista server will not.
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.
CIFS acceleration sports the “NT LM 0.12” dialect, which is used by the vast majority of CIFS
implementations. Other dialects will not receive CIFS protocol acceleration, but will still
benefit from flow control and compression.
The behavior of CIFS acceleration with a given CIFS implementation cannot be known for
certain until it has been tested.
Small file reads and writes. Small-file enhancements center more around meta-
data (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-
ple, they will not be performed if the CIFS client was not granted an exclusive lock on
the directory.
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.
4.14.1 CIFS Security and Acceleration

Windows file servers have two security modes, “signing” and “sealing.” Both inhibit
CIFS acceleration.
Figure 4-35 Windows Server security options, Windows Server 2003.
NETWORK A
WAN
Appliance
Accelerated Non-Accelerated
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 require signing, you must change the
system security settings to disable this requirement. This is done from “Local Security
Settings.”
Windows 2003 Server (see Figure 4-35):
• 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-36):
• 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.”
4-56 September 20, 2010

Figure 4-36 Windows 2000 security options.
In either case, the issue can be detected through the log file on the client-side Accel-
eration unit:
CIFS Session from client <ip> to server <ip> cannot be accelerated for CIFS
due to: server security settings.
4.14.2 Interpretation the CIFS Status Page

Figure 8-12 and Figure 8-14 show the CIFS traffic as seen by the Appliance closest to
the user.
Note: The CIFS status page is only meaningful on the Appliance closest to the
requesting system. The unit closest to the fileserver will show nothing on the CIFS
page. This is because the CIFS acceleration, as currently implemented, is per-
formed entirely by the unit closest to the requesting system. The other unit sees a
stream of CIFS traffic that is not easily distinguishable from ordinary traffic.
The top graph shows CIFS optimization, the ratio between the accelerated transfer
time and an estimate of the time the client’s original requests would have taken,
using the current bandwidth and RTT of the actual connection. A ratio of 100% shows
no CIFS acceleration, while 1000% shows a 10x speedup.
Figure 4-37 CIFS status page.
This graph only considers the boost that CIFS acceleration gives in addition to ordi-
nary Acceleration. (Since flow control gives a 2x-3x speedup over a typical link, the
“CIFS Optimization” graph may be under-reporting the benefit of installing Appliances
by a factor of 2-3.)
4.14.3 CIFS Management Summary

1. CIFS acceleration should show significant improvement even at relatively short
link distances.
2. CIFS acceleration begins when a filesystem is first accessed by the client. If accel-
4-58 September 20, 2010

eration is enabled with the fileserver and client already up and running, no accel-
eration 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 clos-
ing themselves, even when idle. This is annoying during test, but has little impor-
tance in normal deployment.
3. Dismounting and remounting a filesystem in Windows does not have the desired
effect, because Windows doesn’t 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 dis-
mount the volume. In Linux, smbmount and umount will fully dismount the vol-
ume.
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 CIFS Status 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.15 Microsoft Outlook (MAPI) Acceleration

Release 5.5 introduces Microsoft Outlook acceleration. This feature provides improved
performance on traffic between Microsoft Outlook clients and Microsoft Exchange
Servers, increasing throughput with a variety of optimizations, including read-ahead,
write-behind, and compression.
This feature is also called “MAPI acceleration,” after the MAPI protocol used between
Outlook and Exchange Server.
4.15.1 Supported Outlook/Exchange Versions and Modes

• Microsoft Outlook 2003 and 2007.
• Exchange Server 2003 and 2007.
• Outlook must use normal Exchange mode (no HTTP or HTTPS proxy), without
encryption.
4.15.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
“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.
4.15 Microsoft Outlook (MAPI) Acceleration
• Either the Exchange Server or the Outlook are restarted (acceleration does not
begin until existing MAPI connections are closed).
• Encryption is disabled on Outlook.
4.15.2.1 Disabling Encryption on Outlook 2007

Encryption between Outlook and Exchange Server must be disabled, or acceleration
will not take place. This was the default before Outlook 2007. Starting with Outlook
2007, 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-38 and uncheck the box, “Encrypt data between Microsoft Office Outlook
Figure 4-38 Disabling Encryption on Outlook 2007.
and Microsoft Exchange. To disable encryption for multiple users via group policies,
4-60 September 20, 2010

follow the instructions at http://support.microsoft.com/default.aspx/kb/924617.

Change the Properties for “Enable RPC Encryption” to “Disabled” under “User Configu-
ration: Administrative Templates: Microsoft Office Outlook 2007: Tools: Advanced
Settings: Exchange.”
4.15.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.
Figure 4-39 MAPI traffic graphs.
4.16 SSL Compression (Release 5.7 Only)

SSL compression allows SSL connections (HTTPS traffic, for example) to be
compressed using Branch Repeater’s 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-40 SSL Compression.
Ordinary SSL Connection
SSL Connection
Accelerated SSL Connection
Client-Side WAN Server-Side

SSL Connection SSL Tunnel 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 organization’s security poli-
cies.
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-62 September 20, 2010

4.16.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 doesn’t 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.16.2 SSL Transparent Proxy and Split Proxy Modes

There are two SSL compression modes: transparent proxy and split proxy. They sup-
port 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 simi-
lar to each other.
4.16.2.1 SSL Split Proxy

Figure 4-41 SSL split proxy mode.
Servers’
Credential
SSL Signaling Connection
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 server’s 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 server’s credentials is the more trouble-free option.
4.16.2.2 SSL Transparent Proxy

Figure 4-42 SSL transparent proxy mode.
Server’s Private
Keys
SSL Signaling Connection
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
server’s credentials (certificate/key pair) are installed on the server-side Appliance so
it can act on the server’s behalf. The server-side Appliance then configures the
client-side Appliance to handle its end of the connection. The server’s credentials are
not installed on the client-side Appliance.
4-64 September 20, 2010

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.16.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 organization’s security policies.
4.16.4 Configuring SSL Compression
4.16.4.1 Configuring the Appliance

The following procedure uses the “Acceleration Settings: Encryption,” “Acceleration
Settings: Peers,” and “Acceleration Settings: SSL” pages. This pages are described in
full in Sections 8.3.20-8.3.22.
Note: The “Acceleration: SSL” 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.”
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 “Acceleration Settings: SSL” page (see Figure 4-43).
a. Download a crypto license from MyCitrix (see Section 3.3.6)
b. Install the license via the “System Settings: License Management” page (see
Section 8.5.3).
c. Verify successful installation on the “Licensed Features” tab of the “System
Settings: License Management” page. The “Crypto License” heading should
appear in the Licensed Features table and the crypto license expiration date
should be in the future.
Figure 4-43 The SSL page before the crypto license is installed
4-66 September 20, 2010

Figure 4-44 Installing the crypto license.
3. Set a key store password, then open the key store. On the “Acceleration Set-
tings: Encryption” page, open the key store and assign a password to it. (You will
have to re-enter this password after every restart, so don’t forget it.) See
Figure 4-45.
4. (Recommended, but optional) Encrypt disk data by pressing the “Enable Encryp-
tion” 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.
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.)
Figure 4-45 The key store is open but encryption is not yet enabled.
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.16.3. When using self-signed certificates, the same certifi-
cate can be used for the certificate and the CA certificate. When using proper cer-
tificates, 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 “Acceleration Settings: SSL” 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-46. (See also Section 8.3.22.)
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
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” but-
ton again.
4-68 September 20, 2010

.
Figure 4-46 Adding security credentials.
7. Set up the SSL signaling connection on the Appliance. See Figure 4-47.
a. Enable Peer Connections. Select “Enabled” under “Peer State.”
b. Select Cert/key and CA for Signaling Connection. On the “Acceleration Set-
tings: Peers” 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);
Figure 4-47 Configuring peer communication.
“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 his-
tory can be disabled at the option of the remote Appliance’s 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 accept-
able ciphers for the signaling connection. The signaling connection carries key
4-70 September 20, 2010

information and should use a cipher specification suitable for this task, accord-
ing to the standards used by your organization. You can create a new specifi-
cation 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 combi-
nation 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 con-
figure 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 estab-
lished but the SSL signaling connection is not, check your settings.
8. Install credentials from your SSL server. Acquire copies of your server’s cer-
tificate/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 “Accelera-
tion Settings: SSL” 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-48. (See
the next step for transparent proxy.)
a. Go to the server-side Appliance only, go to the “Acceleration Settings: SSL
Settings” 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/Pri-
vate Key” fields.
Figure 4-48 Configuring split proxy.
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.
j. Server-Side Proxy Configuration. Selects the protocols that are allowed when
talking to the server and specifies the ciphers.
k. Authentication required. If checked, the server’s 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 renegotia-
tion settings that are allowed when talking to the client-side unit.
4-72 September 20, 2010

10. (Optional) Create an SSL Transparent Proxy for your SSL server. SSL trans-
parent proxy is less commonly used because its strict requirements are matched
by fewer applications under their default configurations. However, Appliance con-
figuration is simple. On the server-side Appliance only, go to the “Profiles” tab of
the “Acceleration Settings: SSL Settings” 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 Server’s Private Key. Select your server’s private key that you installed in
step 8 for “Private Key” field.
g. Press the “Add” button.
11. Create an SSL service class. On the server-side Appliance, go to the “Accelera-
tion Settings: Service Class” 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-49 SSL service class rules.
a. Create the Service Class. On the “Service Class” page, press the “Insert New
Service Class Rule” button. Type in a name for the new service class (for
example, “HTTPS (SSL)”) and press the “Create” button. The new service class
will appear at the top of the service class list.
b. Create a Rule. Click on the service class’s name and press the “New SSL Rule”
button. Specify the server’s 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.
c. 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.
d. Save the Rule. Press the “Save” button.

e. Modify Acceleration Type (Optional). By default, disk-based compression is
used for the new SSL service class. If this is not desirable (unlikely), it can be
changed on the “Service Class Policies” page.
f. Set service classes on the client-side Appliance. SSL traffic will not be com-
pressed 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). The
traffic will fall into an existing service class, such as “HTTPS” or “Unclassified
TCP,” and if this class’s policy enables acceleration and compression, no addi-
tional 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 connection’s service class on the “Detailed Connection Information”
table. If this matches your SSL service class, SSL compression is taking place.
4.16.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 commu-
nications. 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 organiza-
tion’s 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-74 September 20, 2010

4.17 Service Classes

Figure 4-50 Service class policies
A service class is a named group of IP addresses, port numbers, or both. For example,
a service class called “HTTP” might be defined as any connection with port 80 as the
destination port.
Acceleration features can be enabled or disabled on a service-class basis. Selectable
features currently include “flow control” (generally called “acceleration” in this docu-
ment), and compression.
4.17 Service Classes
Service class rules are evaluated on both Acceleration units. Only the features
common to both sets of rules are enabled. For example, if one unit specifies “Flow
control + compression,” and the other specifies only “Flow control,” then flow control
is enabled and compression is disabled.
In addition, statistics are gathered independently for each service class, making mon-
itoring and management easier. Service class statistics are reported twice: once for
the accumulated statistics since the unit was last restarted, and again for the statis-
tics since the last time the user reset the statistics. These statistics can be reset at
any time for convenience in testing.
Service classes have three top-level pages in the user interface: “Monitoring: Service
Class Statistics” (Section 8.2.5), “Configure Settings: Service Class” (Section 8.3.11),
and “Configure Settings: Service Class Policy” (Section 8.3.12).
4.17.1 How Service Class Policies are Evaluated

The “Service Class Policy” page lists the rules in order. Rules are evaluated from top
to bottom. Only the first matching rule is applied.
The “Service Class” page is where policies are defined. A policy has one or more rules,
which consist of an IP address (or subnet), a source port, and a dest port. Any of
these can be wildcards.
Service class rules only consider the packet that initiates the connection (the
TCP SYN packet). Addresses and ports are evaluated from the contents of this packet.
For example, consider the following address and ports of an HTTP connection from a
system at 10.0.0.51 to a server at 10.0.0.60:
Source: 10.0.0.51 port 12345 (this is the “ephemeral port”)
Dest: 10.0.0.60 port 80
A rule for all HTTP traffic would specify dest port 80 and ignore the source ports. A
rule for HTTP traffic to the specific server would specify dest IP 10.0.0.60, port 80.
Most rules are protocol-centric and consider only the dest port.
The “Unclassified TCP” policy matches all ports and IP addresses, and is always evalu-
ated last. It gives the default action for connections that do not match any other
rules.
4.17.2 SSL Rules (Rel. 5.7 Only)

SSL Rules map a service class rule to an SSL profile. This is a prerequisite to SSL
compression. The purpose of an SSL rule is to align SSL credentials with SSL servers,
and to indicate that SSL compression should be used with these servers.
An SSL rule contains the usual fields, plus a list of SSL profiles. If any profile in the list
matches the credentials offered by the endpoint client AND the IP/port specifications
also match, then the rule succeeds and the acceleration action of its service class is
applied. If the acceleration action includes compression, SSL compression is
attempted.
See Section 8.3.11 for more on service-class rules.
4-76 September 20, 2010

4.18 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.3.4 for more information on the SCPS implementa-
tion. See http://www.scps.org for general SCPS information.
• SNMP support. See Section 8.3.5.
• Performance monitoring. An overall system performance graph is shown on the
Main page of the browser-based interface. Detailed performance information is
given on additional pages. Active accelerated connections are shown on the Main
page and logged, along with performance information. See Section 8.2.
• Debugging support. The Appliance detects many potential problems and reports
them via the browser-based interface. An “Alert” feature warns the user whenever
a potential problem has been detected. Extensive log files are also kept. See Sec-
tion 8.3.8.
• Remote software updates. The browser-based interface allows the administrator
to install new version of the software. Previous versions are retained by the sys-
tem, and it is possible to revert to an older version. See Section 8.5.2.
• 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.5.3.
• Two levels of user accounts are supported: Admin and Viewer. See Section 8.6.2.
• A serial interface allows basic access to the system, in a way similar to the
front-panel interface. See Chapter 10.
4.19 Proxy Mode (Legacy Feature)

Note: Proxy mode is maintained as a legacy mode only. Its use in new instal-
lations is not recommended. CIFS acceleration is not supported under proxy mode.
Proxy mode does not forward non-IP traffic, which causes trouble with some appli-
cations.
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 compat-
ibility with other sites, proxying can also be used by inline Appliances.
4.19.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
Figure 4-51 Proxy mode connection from system “Alpha” to “Beta.”
Network A Network B
Appliance-A
VIP: "Beta-Proxy"
VIP: "Beta-Proxy-A"
Appliance-B
System System
"Alpha" "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)
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 Appli-
ance 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-51 shows how proxy mode accelerates connections between two networks.
Any connection addressed to VIP address “Beta-Proxy” will create an accelerated con-
nection with system “Beta.”
4-78 September 20, 2010

Figure 4-52 Proxy mode connections from system “Beta” to “Alpha.”
Network A Network B
Appliance-A
VIP: "Beta-Proxy"
VIP: "Beta-Proxy-A"
Appliance-B
System System
"Alpha" "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)
Once the connection is opened, data flowing in the reverse direction is also acceler-
ated. That is, an “ftp Beta-Proxy” session will accelerate both get and put com-
mands. However, the proxy in Figure 4-51 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-52 shows a reverse connection that allows systems to open accelerated con-
nections 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.19.0.2 Proxy Mode Topologies

Figure 4-53 Combinations of inline and proxy mode
Case 1. Inline Mode Case 2. Full Proxy Mode

Client Server Client Server
Network Network Network Network
Server Server
Case 3. Full Proxy Mode Case 4. Full Proxy Mode

Client Server Client Server
Network Network Network Network
Server Server
Client Side Server Side
VIP Points
Case Mode VIP Points To Mode
To
1 Inline - Inline -
2 Proxy Server Inline -
3 Inline - Proxy Server
Server VIP (on server-side

4 Proxy Proxy Server
Appliance)
Proxy mode is shown in Figure 4-53. 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.3.2 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-53.
4-80 September 20, 2010

• Case 1 is inline mode. The server’s 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 net-
work topology favors it and the desire is to accelerate all traffic between Appli-
ance-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 server’s 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 net-
work 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 server’s 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 any-
where.
• 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 prox-
ies on the client and server sides. Any connections addressed to the client-side
VIP, from any source, will receive acceleration. The client doesn’t have to be on
the same network as the client-side Appliance; it can be anywhere. Similarly, the
server doesn’t have to be on the same network as the server-side Appliance.
4.19.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.
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-54.
Figure 4-54 Proxy mode, showing VIP-to-VIP proxying.
Network A Network B
WAN
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 con-
figuration 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 vir-
tual 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 lim-
ited 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 avail-
able.
See Section 8.3.2 for a description of the “Settings: Proxies” configuration page.
4-82 September 20, 2010

Chapter 5
The Repeater Plug-in
5.1 About the Repeater Plug-in

Figure 5-1 Repeater allows accelerated communications from clients worldwide.
Large Branch Office
Servers
Ordinary Small Branch Office

Repeater PCs (WAN Connected)
8500
Central Office Repeater

Plug-in
Repeater
8800
Servers
Private
WAN
Repeater Small Branch Office
8800 (Internet/VPN
Connected)
VPN Firewall
Firewall Repeater
Internet Plug-in
Repeater Ordinary
Plug-in PCs
Mobile VPN Users

Home-Office VPN with Repeater
Users with Repeater Plug-in
Plug-in
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, allow-
ing better compression (and far higher throughput) than be achieved with conven-
tional 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 experi-
ence 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 the following operating systems:
• Windows XP Home
• Windows XP Professional
• Windows Vista (Home Basic, Home Premium, Business, Enterprise, and Ultimate)
• Windows 7 (all 32-bit and 64-bit versions).
Recommended hardware requirements are:
• Pentium 4-class CPU
• 1 GB of RAM
• 2 GB of free disk space
Minimum hardware requirements are:
• 1.0 GHz CPU
• 512 MB RAM
• 350 MB free disk space

Chapter 5. The Repeater Plug-in
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 applica-
tions. Citrix AG-SE and AG-AE VPNs requires a small amount of Repeater-specific con-
figuration (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 Appli-
ance-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 Appli-
ance-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 Appliance’s redirector IP address. The Appli-
ance 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.1.4 Detailed Description of Transparent Mode

Figure 5-2 Transparent mode, showing three of the possible acceleration paths.
Large Branch Office B
Ordinary Servers
PCs
Small Branch Office

Repeater B (WAN Connected)
(8500)
ACCELERATED
ACCELERATED
Central Office A Repeater
Plug-in
Repeater A2
(8800)
Servers
Repeater A1 Private
(8800) WAN
Small Branch Office
(Internet/VPN
Connected)
VPN Firewall
Firewall Repeater
Internet Plug-in
Repeater Ordinary ACCELERATED

Plug-in PCs
Mobile VPN Users

Plug-in
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.

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 Appli-
ances, 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 soft-
ware 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 acceler-
ation, 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 ini-
tiating 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. Appli-
ance-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.1.4.1 Packet Flow in Transparent Mode

Packet flow in transparent mode is shown in Figure 5-3. It is almost identical to Appli-
ance-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 sig-
naling connection.
Figure 5-3 Packet flow in transparent mode.

TCP SYN packet.
Src: 10.0.0.50, Dst: 10.200.0.10

2 destination address and sees that it 10.0.0.50 10.200.0.201 10.200.0.10
matches a subnet accelerated by the
appliance. It attaches Repeater 1 2
options to the TCP header of the SYN
packet. No addresses are changed. 3
Src: 10.0.0.50, Dst: 10.200.0.10 4
The appliance notes the SYN options 5

3 and recognizes that this is an
accelerable connection. It strips the 6
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

4 and responds with a TCP SYN-ACK
packet.
Src: 10.200.0.10, Dst: 10.0.0.50
The appliance tags the SYN-ACK 6 The Repeater Plug-in receives the SYN-ACK packet. The
5 packet with a TCP header option that options in the packet headers indicate that the connection is
shows that acceleration will take accelerated. The Plug-in strips the options and passes the
place. SYN-ACK packet to the application. The connection is now
fully open and accelerated.
Src: 10.200.0.201, Dst: 10.0.0.50

5.1.5 Detailed Description of Redirector Mode

Figure 5-4 Redirector mode, showing one possible acceleration path.
Large Branch Office
Servers
Ordinary Small Branch Office

Repeater PCs (WAN Connected)
8500
Central Office Repeater

Plug-in
Repeater
8800
Servers
Private
WAN
Repeater Small Branch Office
8800 (Internet/VPN
ACCELERATED Connected)
CONNECTION
VPN Firewall
Firewall Repeater
Internet Plug-in
Repeater Ordinary
Plug-in PCs
Mobile VPN Users

Plug-in
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 any-
where, 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 server’s point of
view, the connection originates at the Appliance.
• Return traffic from the server is addressed to the Appliance, which performs opti-
mizations in the return direction and forwards the output packets to the Plug-in.
• The destination port numbers are not changed, so network monitoring applica-
tions can still classify the traffic.
Figure 5-5 Packet flow in redirector mode.

TCP SYN packet.
Src: 10.0.0.50, Dst: 10.200.0.10

2 dst address and decides to redirect 10.0.0.50 10.200.0.201 10.200.0.10
the connection to the appliance at
10.200.0.201. 1 2
Src: 10.0.0.50, Dst: 10.200.0.201 3
(10.200.0.10 is preserved in a TCP 4

option field. Options 24-31 are used
for various parameters.) 5
The appliance accepts the connection 6
3
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

6 The connection is now fully open. The client and server send packets
The appliance rewrites the addresses back and forth via the appliance.
5 and forwards the packet to the Plug-
in (placing the server address in an While the addresses are altered in Redirector mode, the destination
option field). port numbers are not (though the ephemeral port number may be).
The data is not encapsulated. Redirector mode is a proxy, not a
Src: 10.200.0.201, Dst: 10.0.0.50 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 typi-
cal use case for the Repeater Plug-in is as a VPN accelerator, and the recom-
mended 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 Appliance’s 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.

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-in’s Appliance list is selected.
(If the Appliances were specified as DNS addresses, and the DNS record has mul-
tiple 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 accelera-
tion is often difficult, as the two uses sometimes call for the Appliance to be at differ-
ent 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 data-
center, 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 Appliance’s 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. Typi-
cally, 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.
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 Appli-
ance-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 infra-
structure 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” intro-
duces 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-user’s Internet connection.
When used in a non-VPN WAN environment, it depends on the topology. One solu-
5-10 September 20, 2010

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 “Acceler-
ate” 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 sup-
port 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 “Accel-
erated” rule (before matching an “Excluded” rule) are accelerated.
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 fire-
wall 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 con-
nection.
Your firewall must not block TCP options in the range of 24-31 (decimal), or accelera-
tion 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 firm-
ware may do so by default.
See Section 3.5.3.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-12 September 20, 2010

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.”
There is very little Plug-in configuration. The Plug-in software is distributed as an exe-
cutable 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 Appli-
ances 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 appli-
cation 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 instal-
lations. 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 Appli-
ances, 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 undesir-
able unless all Appliances are configured identically, because the Plug-in takes
some of it characteristics from the leftmost appliance in the list (especially, in
Release 5.7, 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 Microsoft’s Orca MSI edi-
tor, which is part of Microsoft’s free “Platform SDK,” which can be downloaded from:
http://www.microsoft.com/downloads/details.aspx?Fami-
lyID=0baf2b35-c656-4969-ace8-e4c0c0716adb&DisplayLang=en
Download the PSDK-x86.exe version of the SDK and execute it. Follow the installa-
tion 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://sup-
port.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 win-
dow. Open the Repeater Plug-in MSI file with “File -> Open..”, as shown in Figure 5-7.
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 September 20, 2010

Figure 5-7 Using Orca.
Figure 5-8 Plug-in parameters.

Parameter Description Default Comments
WSAPPLI- List of Appliances None Enter the IP or DNS addresses of your
ANCES Appliances here. Comma-separated list
in the form of “{ Appliance1,
Appliance2, Appliance3 }”. If the port
used for signaling connections is differ-
ent from the default (443), specify this
in the form “Appliance1:port_number”.
DBCMINSIZE Minimum amount 250 Changing this to a larger value (for
of disk space to example, 2000) will improve compres-
use for compression performance, but will prevent
sion, in megabytes 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.
PRI- Private key for the None Release 5.7 only. Use Orca’s “Paste
VATEKEYPEM Plug-in. Part of the Cell” command, as the normal “Paste”
certificate/key pair function does not preserve the key’s
used with SSL format.
compression
Should be a private key in PEM format
(starting with “-----BEGIN RSA PRI-
VATE KEY-----”)
X509CERTPEM Certificate for the None Release 5.7 only. Use Orca’s “Paste
Plug-in. Part of the Cell” command, as the normal “Paste”
certificate/key pair function does not preserve the key’s
used with SSL format.
compression
Should be a certificate in PEM format
(starting with “-----BEGIN CERTIFICATE
-----”)
CACERTPEM Certification None Release 5.7 only. Use Orca’s “Paste
Authority Certifi- Cell” command, as the normal “Paste”
cate for the function does not preserve the key’s
Plug-in. Used with format.
SSL compression
Should be a certificate in PEM format
(starting with “-----BEGIN CERTIFICATE
-----”)
5-16 September 20, 2010

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.
6. Obtain the Repeater Plug-in software (a file in the form of “Repeater*.msi”)

from your Citrix representative.
7. Copy the file to the client system by some convenient means (shared filesys-
tem, FTP server, Web download, etc.)
5.3.3 Installation
Figure 5-10 Initial installation screen.
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).
9. The installation program will ask you where to install the software. This direc-
tory 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.
5-18 September 20, 2010

10. Once the installer finishes, you it may ask you to restart the system. After
restarting, the Repeater Plug-in will start automatically.
Figure 5-11 Final installation screen.
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: Prop-

erties,” 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).
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 semi-
colons. 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 inter-
fering with the installation. Usually, once the installation is complete, there are no fur-
ther 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 doesn’t work, reboot the system and try again.
5-20 September 20, 2010

5.3.5 Running the Plug-in For the First Time

11. Right-click the Accelerator icon in the task bar and select “Manage Accelera-
tion” to launch the Citrix Accelerator Manager.
Figure 5-12 Citrix Accelerator Manager, initial (performance) tab.
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.
Figure 5-13 Citrix Accelerator Manager, configuration tab
13. The Repeater accelerator is now running. All future connections to acceler-
ated subnets will be accelerated
5-22 September 20, 2010

5.4 Testing the Installation

14. On the Plug-in’s “Configuration” tab, the “Acceleration Rules” table should
show each Appliance as “Connected” and each Appliance’s accelerated sub-
nets 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 “Diagnos-
tics” 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.3.1.
• The Plug-in is using an unsupported VPN.
5.6 Repeater Plug-in Command Reference

5.6.1 Configuration Tab
Figure 5-14 Citrix Accelerator Manager, configuration tab
The “Configuration” page contains the user-settable commands. These consist of:
• Accelerator Appliances (Must be set): The “Signaling Addresses” field speci-
fies 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 Appli-
ances 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 compres-
sion. More is better. 10 GB is not too much.
• Show SSL Configuration (rel. 5.7 only): Makes the “Certificates” tab visible.
5-24 September 20, 2010

• Acceleration Rules: Gives an abbreviated list of the acceleration rules down-

loaded from the Appliances. The Appliance’s signaling address and port are shown,
the acceleration mode (redirector or transparent), and its connection state, fol-
lowed by a summary of the Appliance’s 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. Acceler-
ated connections will be reset.
• Status Line: The status line at the bottom of the page gives the current opera-
tional status and the revision number of the Plug-in.
5.6.2 Performance Tab

Figure 5-15 Citrix Accelerator Manager, performance tab.
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 band-
width. Only accelerated traffic is shown.
• Bytes Before Compression. This is the amount of data accepted from applica-
tions 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-26 September 20, 2010

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

Figure 5-16 Citrix Accelerator Manager, diagnostics tab
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 Appli-
ance 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
Figure 5-17 Detailed connection display from a “More..” button.
accelerated connections, plus a status field that reports “Active” if the CIFS con-
nection 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 connec-
tion 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. Usu-
ally 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 mes-
sages.
• Open in Notepad. Allows you to view the status messages in a larger window, or,
if necessary, send them to Support.
5-28 September 20, 2010

5.6.4 “Certificates” Tab (Rel. 5.7 Only)

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.16 for more information on SSL Com-
pression.
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 con-
nect 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 certif-
icate/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.16.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. 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 Con-
trol 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-30 September 20, 2010

Chapter 6
Branch Repeater VPX (Rel. 5.6 Only)
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.
Release 5.6 of the Branch Repeater VPX software is a Xen virtual machine running
under XenServer 5.5.
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 and Xen-
Server Essentials.
Figure 6-1 VPX use case #1: Branch-office accelerator
XenServer
WAN
BranchRepeater VPX
Branch-Office
Users
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.
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
XenServer
WAN
Branch
Repeater VPX Branch-Office
Server
Branch-Office
Users
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, data-
bases, Web server, and more.

Chapter 6. Branch Repeater VPX (Rel. 5.6 Only)
Figure 6-3 VPX use case #3: Accelerated Endpoint Servers
XenServers
Branch Datacenter
Repeater VPX Server
WAN
Branch Datacenter
Repeater VPX Server
Branch Datacenter
Repeater VPX Server
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 vir-
tual 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
Xenserver
Internet
Branch
VPN
Repeater VPX Datacenter
Servers
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 dedi-
cated 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
Xenserver
Internet
VSWITCH VSWITCH
Datacenter
Servers
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
Xenserver
Internet
Branch
Repeater VPX
Server
6.1.2 Other Branch Repeater VPX Features

• Support of Citrix Command Center 4.0 and up.
• XenServer Essentials Support:
• XenMotion Live Migration
• XenServer High Availability
• Workload Balancing
• Performance Monitoring and Alerts
• 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.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 User’s Guide applies equally to Repeater and Branch Repeater VPX
appliances.
As you read this User’s 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 is supported.)
In cases where an Ethernet bypass card is desirable, using WCCP instead of inline
mode will provide an effective failover mechanism.
6.3 System Requirements and Provisioning
6.3 System Requirements and Provisioning

Branch Repeater VPX runs under XenServer. Branch Repeater VPX can be configured
to use 1-8 GB of RAM, 60-500 GB of disk, and 1-2 virtual CPUs. The intermediate,
4 GB RAM/250 GB disk configuration is similar to the Repeater 8500 Series.
6.3.1 Supported Configurations

Note: The configurations below are the only supported configurations.
Figure 6-7 Supported Configurations

Max.
Max. WAN Max. Accel.
Type RAM Disk Repeater
Speed Connections
Plug-Ins
Minimal, default
configuration. Not for 1 GB 60 GB 2 mbps 1,000 50
production networks
1 GB production config 1 GB 100 GB 2 mbps 1,000 50
6.3.2 Minimum Resource Requirements

The system hosting Branch Repeater VPX needs to run XenServer 5.5. Branch
Repeater VPX does not require hardware virtualization support in the CPU (though
this is desirable).
The Branch Repeater VPX virtual machine requires a minimum of:
• 1 CPU
• 1 GB RAM
• 60 GB disk (local disks will give maximum performance)
• 2 virtual NICs (Ethernet ports)
The absolute minimum (60 GB disk) configuration is not for production environments,
but can be useful for ad hoc testing and demonstrations on machines with inadequate
resources.
The server hosting Branch Repeater VPX needs resources greater than or equal to
these, with the exception of Ethernet ports. Possible Ethernet options include:
• Mapping Branch Repeater VPX’s two virtual ports to two physical ports, rendering
its operation equivalent to a stand-alone branch repeater.
• Mapping one of Branch Repeater VPX’s 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 VPX’s virtual ports to a virtual network, thus
chaining Branch Repeater VPX between two sets of virtual machines on the same
server.

6.3.3 Maximum Resources

The maximum amount of resources that a single Branch Repeater VPX virtual
machine can use effectively are:
• 2 CPUs
• 8 GB RAM
• 500 GB disk
• 4 virtual NICs
6.3.4 Resource Usage Notes

Disk and RAM
• As the amount of RAM and disk are increased, the additional resources are allo-
cated 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 sub-
system. 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. Mem-
ory 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 match-
ing.
CPU
• Performance does not scale linearly with additional CPUs. Two virtual CPUs are the
maximum recommended number. In most installations, performance is most sen-
sitive to the speed of a single CPU core.
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 in XenCenter. 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.
• Resource usage by other virtual machines will affect Branch Repeater VPX perfor-
mance, and vice versa. Acceleration makes intensive use of CPU, memory, disk,
and network.
6.4 Virtual Ethernet Ports
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 termi-
nates 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-8.
Figure 6-8 Ethernet (Network) port assignments, single-ended operation
Branch Repeater VPX WAN

Network 1
Other
VMs
XenServer
Routing. XenServer virtual network routing can be used to connect other virtual
machines on the server to Branch Repeater VPX, but the simplest method of connect-
ing such virtual machines is to attach them to the server’s LAN-side Ethernet port.
WAN-bound packets then will pass through the Branch Repeater VPX’s bridge and be
accelerated automatically.
Figure 6-9 An inline deployment that accelerates both external traffic and traffic from local
VMs.
LAN Branch Repeater VPX WAN

Network 0 Network 1
Other
VMs
XenServer
6.5 Upgrading a Previous Installation

The software upgrade mechanism built into Branch Repeater is also supported with
Branch Repeater VPX, starting with release 5.6.1. Alternatively, you can install a new
virtual machine containing the desired release.
6.6 Initial Installation

Branch Repeater VPX is a standard XenServer virtual machine in 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 “System Tools:
Manage Licenses” page of the Branch Repeater VPX user interface, using the proce-
dure in section 3.6 of the Branch Repeater Family Installation and User’s Guide,
release 5.5.
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 pro-
vided 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
Figure 6-10 through Figure 6-12. Local disk storage will give maximum perfor-
mance and reduce contention for disk and network resources.

Figure 6-10 Importing the Branch Repeater VPX virtual machine.
Figure 6-11 Select the server.
6-10 September 20, 2010

Figure 6-12 Configure storage
4. Attach virtual network interfaces “interface 0” and “interface 1”to the two differ-
ent virtual adapters (called “Networks” on this page). These two interfaces will be
used as Branch Repeater VPX’s accelerated bridge. Do not assign 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-13.
Figure 6-13 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 configu-
ration that requires that the VM be halted), then press “Finish” to complete the ini-
tial installation. See Figure 6-14.
Figure 6-14 Complete the import
6-12 September 20, 2010

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-15.
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-15 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 sup-
ported configuration. Use the table in Figure 6-7 as a guide.
Figure 6-16 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 September 20, 2010

Figure 6-17 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
Note: The default admin password has changed for release 5.6, and is now “pass-
word”.
Figure 6-18 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 exam-
ple:
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 Bridg-
ing” 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 Ether-
net segment, network loops will be created which may bring down your entire net-
work. Check the network assignments in XenCenter, and if the two network
devices are connected to different Networks, press “OK.” Otherwise, shut down
6-16 September 20, 2010

the Branch Repeater VPX virtual machine and fix the network assignments first.
Figure 6-19 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 “System Tools: Manage
Licenses” page and uploading the license file.
15. (When licensing via a central license server) License the Branch Repeater VPX by
going to the “System Tools: Manage Licenses” page and setting the following
parameters (See Figure 6-18):
• 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-21.)
16. Complete the configuration as you would with any Branch Repeater installation.
Figure 6-20 License parameters on the Branch Repeater VPX
6-18 September 20, 2010

Figure 6-21 License information
6.7 Additional Configuration

For additional configuration instructions, see the remainder of this user’s guide.
6.7 Additional Configuration
6-20 September 20, 2010

Chapter 7
Cabling and Physical Deployment
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 perfor-
mance 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, it’s 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 gener-
ally, but not always, use the same connector polarity as computers.
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 mis-
matched 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 “Interfaces” page. (See Section
8.3.3.)
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
expectations have been low. It should be suspected when the “Alerts” page reports
high packet losses. (See Section 8.3.8.) If the mismatch occurs on a link directly con-
nected to the Appliance, the Alerts section will report a half-duplex connection.
Figure 7-1 Basic cabling, inline mode
Switch or Router or
Router Switch
WAN or
LAN Internet
Use Existing See Below See Below Use Existing
Cabling Cabling
Appliance
Detail: LAN-Site Cabling Detail: WAN-Side Cabling
Straight-Through Cross-Over
Blue Orange
Switch WAN
Router
Cross-Over
Straight-Through
Orange
Blue
Internal
Router Switch
Cross-Over Straight-Through
Orange Blue
DSL or
Cable
Server,
Modem
Client

Chapter 7. Cabling and Physical Deployment
Figure 7-2 Basic cabling, inline high-availability pairs
Switch Switch
TO TO
LAN WAN
Blue Straight- Blue Straight-
Through Cables HA Pair Through Cables
7.2.2.3 Older Fast Ethernet Equipment

Older Fast Ethernet products did not support full-duplex operation at all. Older equip-
ment 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 possi-
ble. 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.
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 What Happens if the Appliance Fails

7.3.1 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.
7.4 High-Availability 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.3.2 WCCP Mode

The WCCP protocol has integral health-checking, and the router will bypass the Appli-
ance 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.3.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 reattach-
ing when it is. If “verify-availability” is not used, all packets forwarded to the Appli-
ance will be dropped if the Appliance isn’t available.
7.3.4 Group Mode

Group mode has selectable failure behaviors, described in Section 4.12.3.2. The failed
unit will fail “open” (bridging disabled) or “closed” (bridging or bypass relay enabled).
7.3.5 High-Availability Mode

See Section 7.4 below. Individual HA units always fail “open” (bridging disabled).
7.3.6 Redirector Mode

The Repeater Plug-in performs health-checking on redirector-mode Appliances and
bypasses unresponsive Appliances, sending traffic directly to endpoint servers
instead.

Two identical Appliances on the same subnet can be combined as a high-availability
pair. The units each monitor the other’s status using the standard VRRP (Virtual
Router Redundancy Protocol) heartbeat mechanism. If the primary unit fails, the sec-
ondary 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, as 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 TO
LAN WAN
Blue Straight- Blue Straight-
Through Cables HA Pair Through Cables
Switch
Router
TO
LAN
Blue Straight-
Through Cables HA Pair
TO
WAN
7.4.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 deter-
mine 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.4.2 How High Availability Works

Status monitoring. Once High Availability is enabled, the primary unit sends a “heart-
beat” signal once per second. This heartbeat signal is compatible with the VRRP (Vir-
tual 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 broad-
cast. 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 initial-
ize 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 sec-
ondary unit. To the users, the symptoms of failover will be the closing of open con-
nections, 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 second-
ary unit immediately.
Both units must be running the same software release, or HA cannot be enabled.
HA in WCCP mode. When WCCP is used with an HA pair, the primary Appliance estab-
lishes 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 Appli-
ance will establish WCCP communication with the router.
7.4.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, the management IP addresses of the secondary unit becomes (for
the most part), inaccessible, as shown in Figure 7-4.
Figure 7-4 HA pairs are managed from the primary only.
The management pages for the secondary unit becomes unavailable once it is part of a
high-availability pair.

7.4.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.4.5 Updating Software for a High-Availability Pair

Updating an HA pair will cause a failover at one point, and all open accelerated con-
nections 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.

Chapter 8
Configuration Reference
This chapter describes the browser-based user interface of the Citrix 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 User’s Guide.
• The Repeater Plug-in has its own simplified user interface, which is covered in
Section 5.6.
• Release 5.7 substantially rearranges the left-hand menu bar. This document gen-
erally uses the menu structure in releases 5.5 and 5.6. See Section 8.1 for the
mapping between Release 5.7 and 5.5-5.6.
Note: Branch Repeater and Repeater Appliances have the same user interface.
Screen images from the two product lines are used interchangeably in this chapter,
and thus some images may say “Repeater” and others “Branch Repeater.”
8.1 Altered Menu Structure for Release 5.7

In Release 5.7, the “Configure Settings” category was split into three categories:
1. System Settings
2. Acceleration Settings
3. Deployment Settings
In this User’s Guide, all three categories are lumped under “System Settings” as
shown below
Figure 8-1 Comparison between rel. 5.7 and rel. 5.5 menu structures
Release 5.7 Menu Entry Release 5.5-5.6 Menu Entry Section
Monitoring: System Status Monitoring: System Status 8.2.1
Monitoring: Usage Graph Monitoring: Usage Graph 8.2.2
Monitoring: Connections Monitoring: Active Connections 8.2.3
Monitoring: CIFS Status Monitoring: CIFS Status 8.2.4
Monitoring: Service Class Statistics Monitoring: Service Class Statistics 8.2.5
Monitoring: Compression Status Monitoring: Compression Status 8.2.6
8.1 Altered Menu Structure for Release 5.7
Figure 8-1 Comparison between rel. 5.7 and rel. 5.5 menu structures (Continued)
Monitoring: QoS Statistics Monitoring: QoS Statistics 8.2.7
Monitoring: WCCP Status Monitoring: WCCP Status 8.2.8
Monitoring: Repeater Plug-ins Monitoring: Repeater Plug-ins 8.2.9
Monitoring: Peer Status N/A 8.2.12
Monitoring: MAPI Status Monitoring: MAPI Status 8.2.10
Monitoring: ICA Status Monitoring: ICA Status 8.2.11
System Settings: Interface Configure Settings: Interface 8.3.3
System Settings: Tuning Configure Settings: Tuning 8.3.4
System Settings: SNMP Configure Settings: SNMP 8.3.5
System Settings: Date/Time Configure Settings: Date/Time 8.3.6
System Settings: Logging Configure Settings: Logging 8.3.7
System Settings: Alert Configure Settings: Alert 8.3.8
System Settings: Admin Interface Configure Settings: UI 8.3.9
System Settings: IP Address Configure Settings: IP Address 8.3.14
System Settings: License Management System Tools: Manage Licenses 8.5.3
System Settings: User Accounts Security: Manage Users 8.6.2
System Settings: Repeater Plug-in Configure Settings: Repeater Plug-in 8.3.18
System Settings: SSH Access Security: Access 8.6.3
System Settings: Cert/Key for HA/GM Security: Certificates 8.3.19
Acceleration Settings: Bandwidth Configure Settings: Bandwidth

8.3.19
Management Management
Acceleration Settings: CIFS Configure Settings: CIFS 8.3.10
Acceleration Settings: Service Class Configure Settings: Service Class 8.3.11
Acceleration Settings: Service Class Configure Settings: Service Class Policy

8.3.12
Policy
Acceleration Settings: QoS Configure Settings: QoS 8.3.13
Acceleration Settings: Encryption N/A 8.3.20
Acceleration Settings: Peers N/A 8.3.21
Acceleration Settings: SSL N/A 8.3.22
Deployment Settings: Proxy Configure Settings: Proxy 8.3.2
Deployment Settings: High Availability Configure Settings: High Availability 8.3.15
Deployment Settings: Group Mode Configure Settings: Group Mode 8.3.16

Chapter 8. Configuration Reference
Figure 8-1 Comparison between rel. 5.7 and rel. 5.5 menu structures (Continued)
Deployment Settings: WCCP Configure Settings: WCCP 8.3.17
Reporting: Generate Report Reporting: Generate Report 8.4.1
System Commands: Backup/Restore System Tools: Save/Restore 8.5.1
System Commands: Update Software System Tools: Update Software 8.5.2
System Commands: View Logs System Tools: View Logs 8.5.5
System Commands: Restart System System Tools: Restart System 8.5.4
System Commands: Diagnostics System Tools: Diagnostic Tool 8.7.1
System Commands: Logout Security: Logout 8.6.4
8.2 “Monitoring” Pages

The browser-based interface has it root URL at the Appliance’s 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 “Monitoring: System Status” 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.6.2.
Link bar. The left edge of this page (and every other page) contains links to the other
pages. 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.3.8).
8.2.1 “Monitoring: System Status” Page

Figure 8-2 “Monitoring: System Status” page (initial page)
This page shows basic system status.
8.2.1.1 Enabling/Disabling Acceleration
The “Status” row identifies the product type (“Repeater 8500” in the example above)
and shows whether acceleration is NORMAL (enabled) or DISABLED. The “Enable” or
“Disable” button allows you to change this state. The user interfaces remain active
when acceleration is disabled.
Disabling acceleration will reset all open accelerated connections. New connections
will not be accelerated. New proxy-mode connections will not be accepted when accel-
eration is disabled.
Re-enabling acceleration has no effect on existing connections, but new connections
will be accelerated.
8.2.1.2 Status Lines
The “Throughput” row reports the current maximum bandwidth setting and the
licensed bandwidth limit. The “Adjust Using BW Scheduler” link takes you to the
Bandwidth Scheduler page, where the current setting can be changed (see Section
8.3.1). The licensed limit is changed with a new license key from Citrix (see Section
8.5.3).
This row reports throughput limits, not the throughput of currently open connections.
Second-by-second throughput is given on the Main page (see Section 8.2).

If separate send/receive rates have been enabled, both values will be shown here.
The “Up Time” row gives the elapsed time since the last restart.
The “Bandwidth Mode” shows the acceleration mode: Hardboost or Softboost, Full
Bandwidth or Partial Bandwidth.
The “Active Connections” row lists both accelerated and unaccelerated TCP connec-
tions. Non-TCP traffic is not listed.
An “Active” connection is one that has seen traffic in the last second.
The “Repeater Plug-in” row lists how many Repeater Plug-in are using the Appliance,
and the maximum number of simultaneously active Plug-ins allowed by the license.
The “Software Version” row lists the release number, build number, and compilation
date of the software.
The “System Hardware” row reports the hardware platform type.
The “System Personality” row reports the model number of the Appliance.
The “Bypass Card Type” row gives the version number of the Ethernet bypass
(fail-to-wire) card in the system.
8.2.2 “Monitoring: Usage Graph” Page

Figure 8-3 “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 (red): Non-accelerated traffic of all kinds (including data and overhead).
Compression is taking place during periods when the LAN traffic is higher than the
(compressed) WAN traffic. In the diagram above, periods of high compression are creating
data spikes at 2.5 mbps in a WAN stream of about 400 kbps.
The “Monitoring: Usage Graph” page shows real-time throughput graphs for the WAN
and LAN sides of the Appliance. 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-4.
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.
• Dark blue indicates accelerated “goodput,” or payload data.
• Light blue indicates the overhead of accelerated connections: packet headers,
acknowledgement packets (ACKs), and retransmissions.
• Red indicates non-accelerated traffic.
• The graphs are stacked, so the topmost point on the graph shows total acceler-
ated traffic (LAN-side graph) or total line usage (WAN-side graph).
The “Graph Settings” link takes you to the “Configure Settings: UI” 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 Sec-
tion 8.3.9.
Clicking “Popup Graph” will create a new window containing a similar auto-refreshing
throughput graph. See Figure 8-4.
Figure 8-4 Popup performance graph
8.2.3 “Monitoring: Active Connections” Page

Figure 8-5 “Monitoring: Active Connections” page.
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 man-
agement interface of that Appliance.
8.2.3.1 Selecting Which Accelerated Connections to Show

In a busy system, with hundreds or thousands of accelerated 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.2.3.2 Unaccelerated Connections Display

You can choose to display either accelerated or unaccelerated connections. The dis-
play format similar in either case. However, the unaccelerated connections display
shows an “Unaccelerated Reason” code in the leftmost 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-6 Unaccelerated connections.
Common reasons for non-acceleration are:

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

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

The leftmost column in the Accelerated Connection table is the “Details” column, con-
taining links to per-connection information, as shown in Figure 8-8 through Figure
8-10.
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-10 September 20, 2010

WAN/LAN graphs. These show only the traffic for the selected connection. Otherwise,
they are the same as the usual throughput graph.
Figure 8-8 Connection Details page. Top portion: graphs.
Detailed Connection Information table. See Figure 8-9. This table reports:
• Creation Time: the date and time when the connection was opened.
• Uncompressed Bytes Transmitted: the amount of data transferred in the connec-
tion 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.
Figure 8-9 Connection Details page, “Detailed Connection Information” table.
Detailed Per-Endpoint Information table. See Figure 8-10. 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 smooth-
ing 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 Accel-
eration 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 con-
nection. 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-12 September 20, 2010

• Total Payload Bytes: As above, but with headers and retransmissions removed
from the calculation.
Figure 8-10 Connection Details page, “Detailed Per-Endpoint Information” table.
8.2.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-11. The entries should be self-explanatory.
Figure 8-11 Flow information page.
8-14 September 20, 2010

8.2.4 Monitoring: CIFS Status” Pages

The CIFS status pages have a toggle (through release 3.1) or tabs (release 4.0 and
up) to switch between a throughput graph mode and an accelerated connections list
mode.
Figure 8-12 CIFS status page, accelerated connections mode.
Note: In releases prior to release 3.3, the CIFS status pages are only meaningful
on the Appliance closest to the requesting system. The unit closest to the
fileserver will show nothing on these pages. This is because the CIFS acceler-
ation, as currently implemented, is performed entirely by the unit closest to the
client system. The other unit sees a stream of CIFS traffic that is not easily distin-
guishable from ordinary traffic.
In newer releases, the read and write traffic graphs are correct but the other infor-
mation is shown as zeroes on both graphs and tables.
The page has an auto-refresh toggle. The auto-refresh rate uses the same refresh
period as the main Usage Graph.
Figure 8-13 CIFS connection details page
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. See Figure 8-13. Clicking the
“Graphs” tab at the top of the page will return you to throughput graph mode.
Note: The term “non-accelerated” is used improperly on this page. In reality, all
connections listed on this page are benefiting from Acceleration. The connections
listed as “non-accelerated” are benefiting from normal Acceleration but not from
CIFS-specific optimizations. The ones listed as “accelerated” are benefiting from
CIFS-specific optimizations in addition to normal Acceleration.
“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 “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 connections uses the Vista SMB 2.0 format, which is not supported.
2. CIFS optimizations are disabled on the Appliance.
3. Security settings on the connection prevent optimization.
8-16 September 20, 2010

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.
Throughput graph. This shows three 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 direc-
tion as seen by the Appliance.)
2. CIFS Accelerated Write Traffic, the total bandwidth from accelerated CIFS write
requests.
3. CIFS optimization, the ratio between the accelerated transfer time and an esti-
mate of the time the client’s original requests would have taken, using the current
bandwidth and RTT of the actual connection. A ratio of 100% shows no CIFS accel-
eration, while 1000% shows a 10x speedup. This graph only considers the boost
that CIFS acceleration gives in addition to ordinary Acceleration and compression.
8.2.5 “Monitoring: Service Class Statistics” Page

This page gives connection, payload, and packet statistics for all the classes that have
been defined on the “Service Class” page (Section 8.3.11). Starting with release 4.1,
per-service-class line utilization and compression graphs are shown on additional
tabs.
Clicking on the row and pressing the “Details” button will give comprehensive infor-
mation about a given service class, as shown in Figure 8-16, including information
about non-accelerated (pass-through) connections that match the service class defi-
nition.
Pressing the “Reset” button will set these statistics for the selected row to zero.
The line utilization graph shows a pie chart of the top service classes for accelerated
and non-accelerated traffic. See Figure 8-17.
The compressibility graph shows a set of bar charts showing the amount of data
before and after compression on the top compressible service classes. See
Figure 8-18.
Figure 8-14 CIFS status page, throughput graph mode.
8-18 September 20, 2010

Figure 8-15 Service class statistics page.
Figure 8-16 Service class details page.
Figure 8-17 Service class line usage page.
8-20 September 20, 2010

Figure 8-18 Service class compressibility page.
8.2.6 “Monitoring: Compression Status”

Figure 8-19 Compression status page, compression/decompression breakdown tab
The compression status page gives a breakdown of the multi-level compression

traffic, which automatically selects the optimum compression engine for the data
being compressed. Starting with release 4.3, this graph can span one minute, one
hour, one day, one week, or one month. Before release 4.3, only the one-minute
timespan was available.
Each compression engine is called a “matcher.” The smallest compression engine, the
“micro matcher,” has only a small amount of compression history, and can only match
strings within a few thousand bytes of the current data. The next compression engine,
the “mini matcher,” can handle much larger spans of data. The “big matcher” can
handle matches up to several gigabytes in size or up to several gigabytes in distance
from the current data. Finally, the disk matcher can handle matches of almost arbi-
trary size.
Each matcher is color-coded. The graph is similar to the usage graph, except only
compressed connections are shown. The vertical axis gives the effective throughput of
the compressed data, which may 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.
Other compression points:
• First-pass data (data that does not match anything already in compression mem-
ory) gives compression ratios anywhere between 1:1 (typical for compressed
8-22 September 20, 2010

binary data) and 10:1 or even more (where there is significant internal redun-
dancy, 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.
• 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.
• If the Appliance is communicating with many different Acceleration Partners, this
limits the amount of compression history that any one unit can have.
The compression status tab shows cumulative compression statistics rather than
second-by-second results. (Starting with release 4.1, this portion is on a separate tab
rather than at the bottom of the same page as the time chart.) The statistics can be
cleared at any time by pressing the “Clear” button. Statistics are reported separately
for the sending and receiving direction.
Figure 8-20 Compression status tab.
The compression ratios have their usual meaning (uncompressed bytes / compressed
bytes).
The “Effective Bandwidth” is the negotiated bandwidth limit (in the sending direction)
multiplied by the compression ratio in the sending direction. If factors other than link
speed (such as application speed) are the limiting factors in throughput, the “effective
bandwidth” will have little resemblance to actual throughput.
The “Bandwidth Reduction” values are a different way of expressing the same infor-
mation as the compression ratio. For example, a connection with 10:1 compression
has a bandwidth reduction of 90%.
Note: In some releases, the percentage bandwidth reduction values are displayed
incorrectly. They display (100 - percent_reduction) rather than the true value.
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-24 September 20, 2010

8.2.7 “Monitoring: QoS Statistics”

Figure 8-21 QoS Statistics page, main tab.
The QoS feature was added in release 4.1.

The QoS Statistics page shows a statistics tab and three usage charts, showing QoS
queue usage graphs covering the past month, week, minute, hour, and day.
The QoS system uses five queues with arbitrary, user-settable names and bandwidth
fractions. Bandwidth is shared; that is, when one queue has bandwidth that is not
being used, is given up to other queues.
Queue assignment is on a per-service-class basis. Special parsing allows Citrix Pre-
sentation Manager (ICA) traffic to be handled dynamically, with different ICA priorities
mapped to different QoS queues.
8.2.7.1 QoS Statistics Table

General QoS statistics are reported as follows:
• QoS Traffic Class Names. These are the names of the individual queues. They
default to “A” through “E,” but can be renamed on the “Configure Settings: QoS”
page.
• Total Bytes Sent. Total traffic sent (accelerated connections only) that was
assigned to this queue. (QoS is a sender-only algorithm.)
• Sent Byte Ratio. The percentage of total accelerated traffic assigned to this queue.
• Total Sent Packets. The number of packets assigned to this queue.
• Sent Packet Ratio. The percentage of total accelerated packets assigned to this
queue. This value will vary from the “Sent Byte Ratio” because the average packet
size will not be identical between queues.
• Average Packet Size (bytes). The average size of packets assigned to this queue.
• Average send rate (bps). The average transmission rate from this queue. Will gen-
erally be smaller than the assigned rate, since gaps between transmissions count.
• Configured Min Send Rate (bps). The value here is the bandwidth limit times the
bandwidth fraction assigned to the queue. For example, a queue with a 10%
bandwidth share on a unit with a 9,000 kbps bandwidth limit will show 900,000
bps in this column. The “min” in the title comes from the fact that the “minimum
send rate” is used if Partial Bandwidth is enabled.
• Average Bandwidth Utilization (%). The percentage of the configured send rate
that is actually being used, measured since the last time the counters were reset.
Includes idle time. May exceed 100% if the queue is able to borrow bandwidth
from other queues.
• Configured Min Send Rate Ratio. In spite of its name, this is just the bandwidth
percentage that was configured on the “Configure Settings: QoS” page.
• Bandwidth Sharing (bps). Average rate at which bandwidth is shared with other
queues (positive numbers) or borrowed from other queues (negative numbers).
Citrix ICA QoS statistics are reported as follows:
• Service Name. The name of the ICA service class. Generally “ICA.”
• ICA Priority. One of four protocols defined in the ICA protocol.
• Total Bytes Sent, Sent Byte Ratio, Total Sent Packets, Sent Packet Ratio, Average
Packet Size, Average Send Rate: Same as with the previous tables.
Reset Counters button. This clears all the statistics. Useful at the beginning of a
test.
8-26 September 20, 2010

8.2.7.2 QoS Graphs

Figure 8-22 QoS usage graph, showing the interaction of a queue named “Normal” with a
90% bandwidth allocation and a queue named “Background” with 10%. The background queue
uses the full link bandwidth whenever the other queue goes idle.
The QoS graph shows the interaction between the different QoS queues in real time.
The tabs at the top of the page allow you to choose views covering the list minute,
hour, and day. The legend above the graph shows the five queue names and assigns
a color to each queue.
The graph is useful for monitoring the interaction between different QoS queue, and
also monitoring whether there is enough traffic being offered to fill the link.
Only TCP traffic is shown on this graph.
8.2.8 “Monitoring: WCCP Status”

Figure 8-23 Monitoring WCCP status.
The “Monitoring: WCCP Status” page was added in release 4.2.17.

This page reports on the status of the Appliance’s WCCP interface. For each config-
ured 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, con-
nection status, and packets in and out.
The page is auto-updating and lags the actual state of the interface by only a few sec-
onds.
Most of the fields are self-explanatory except for the “Status” field, which is described
below:
Figure 8-24 WCCP status messages (Sheet 1 of 2)
Text Description
Unknown error WCCP interface is not working for an unknown reason.
Undefined interface The defined interface for the service group does not exist.
Bad configuration The service group configuration does not make sense.
The accelerated interface defined for the service group has been
Disable interface
disabled.
The accelerated interface has a network definition that contains no

Bad subnet for
subnet portion (subnet works out to 0.0.0.0, usually due to the
interface
subnet field not being defined).
Internal problem Internal software error.
Service Group is The service group has been manually disabled on the WCCP
disabled Configuration page.
Acceleration is The service group does not operate when acceleration is disabled.
disabled
WCCP is disabled WCCP itself is disabled.
8-28 September 20, 2010

Figure 8-24 WCCP status messages (Sheet 2 of 2)

Contacting router No response has been received yet from the router.
At least one packet has been received from the router, and WCCP
Connecting to router
protocol negotiations are underway.
Connected to router Negotiation is complete and the WCCP interface is fully active.
Disconnecting from The Appliance is terminating its connection to the router, probably
router due to a user-initiated configuration change.
No response from The router has been completely unresponsive for at least five
router minutes
Router’s forward or Cannot communicate with the router because the specified mode is
return capability not available. Usually means that the Appliance is configured for
mismatch WCCP-L2, but the router does not support this mode.
Multicast discovering Attempting to find multicast service group partners.
Multicast failed to No multicast group partners were found in the last five minutes.
discover
The multicast service group is no longer attempting to discover

Multicast shutdown
partners.
Router’s view has There is another WCCP device, such as another Appliance, using the
other cache 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,
Router assignment
and communication with the first connected router caused the
capability mismatch
“Hash” method to be selected, if a subsequent router does not
support “Hash,” this status message will be given.
Router is off-net and Packet forwarding cannot take place because the appliance’s
appliance’s gateway gateway is invalid (not on the same subnet as the appliance).
is invalid
Service group had Internal software error. Please report this event to Support.
socket send error
8.2.9 “Monitoring: Repeater Plug-in”

Figure 8-25 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-26.
8.2.10 “Monitoring: MAPI Status”

The “Monitoring: MAPI Status” page has three tabs: “Acceleration Graphs,”
“Accelerated Connections,” and “Unaccelerated Connections.”
“Acceleration Graphs” Tab

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 from the main usage
graphs, since they show movement into and out of the MAPI engine, not actual traffic
on the WAN. The differences are caused by buffering.
8-30 September 20, 2010

Figure 8-26 Detailed Plug-in Information
Figure 8-27 “Acceleration Graphs” tab.
“Accelerated Connections” Tab

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-28 “Accelerated Connections” tab.
8-32 September 20, 2010

“Unaccelerated Connections” Tab

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-29 “Unaccelerated Connections” tab.
8.2.11 “Monitoring: ICA Status”

Figure 8-30 Monitoring: ICA Status.
This page allows you to monitor total ICA traffic (in the sending direction only) and
the list of ICA connections. The ICA connection list is similar to the Active Connection
list and can be filtered or sorted in the same way.
8.2.12 “Monitoring: Peer Status” (Rel. 5.7 Only)

Figure 8-31 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 peer’s 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-34 September 20, 2010

8.3 The “Configure Settings” Pages

8.3.1 “Configure Settings: Bandwidth Management”
Figure 8-32 Bandwidth management (softboost).
8.3.1.1 Hardboost vs. Softboost

Figure 8-33 Selecting between hardboost and softboost.
Softboost and hardboost are two different bandwidth-control modes (see Section
4.3.1). Hardboost gives ideal performance over fixed-speed links. However, if the
hardboost bandwidth limit exceeds the link speed, it will send faster than the link
speed and produce high packet-loss rates and poor performance. This makes it
unsuitable to variable-speed links. Hardboost is also unresponsive to third-party QoS
systems.
Softboost is more responsive to packet loss and is forgiving of situations where the
bandwidth limit is higher than the link speed. In a congested environment, it will back
off in the face of competing traffic. This makes softboost more flexible in shared, con-
gested, and variable bandwidth environments, but also less aggressive in seizing
bandwidth.
8.3.1.2 Bandwidth Limit
These values set how much line bandwidth is used by accelerated connections.
Figure 8-34 Bandwidth management (hardboost).
The sending bandwidth limit sets an upper limit to how fast the Appliance will send
accelerated data on the WAN. For example, if the limit is 5,500 kbps, the Appliance
will never send accelerated data faster than 5,500 kbps. This reduces congestion on
the WAN by not overrunning it.
The receive bandwidth limit is used indirectly. It is sent to acceleration partners,
which use it to adjust their sending rate. In essence, an appliance’s sending rate is
limited by its own sending limit or its partner’s receiving limit, whichever is smaller.
This is useful in hub-and-spoke and mesh topologies where each partner may have a
different link bandwidth. (See Section 4.3.2 for more about bandwidth allocation.)
8-36 September 20, 2010

8.3.1.3 Full Bandwidth
The Full Bandwidth mode means that the Appliance will attempt to send accelerated
data at the bandwidth limit you set. Other traffic is forwarded immediately to the
output port, but is ignored for the purposes of bandwidth calculations. If the band-
width limit is set to the effective data rate of the link, non-accelerated traffic will com-
pete with accelerated transfers.
With softboost, this competition acts like any other TCP traffic. Hardboost, however, is
very aggressive and will suppress competing traffic unless room is made for it.
If the bandwidth limit is set lower than the link speed, the difference between the
bandwidth limit and the link speed is reserved for non-accelerated transfers. (See
Section 4.3.4.2.)
8.3.1.4 Partial Bandwidth
The partial bandwidth feature allows non-accelerated connections to take precedence

over accelerated connections. This is often appropriate on links that carry sensitive
non-accelerated traffic such as VoIP, and also when there is quite a bit of general
non-accelerated traffic. (See Section 4.3.4.1.)
Note: Partial bandwidth should only be used on point-to-point links where the local
WAN router has a single LAN link and a single WAN link. More complex topologies
will confuse the partial bandwidth algorithm, causing it to back off unnecessarily,
reducing performance (possibly to zero).
Partial bandwidth is especially useful for hardboost links, because hardboost will
ignore any indications from your router-based QoS system that it should slow down.
Without partial bandwidth, hardboost might interfere with sensitive traffic like VoIP.
It is also useful for softboost links if you are not using router-based QoS to protect
your VoIP connections. If you are using router-based QoS, partial bandwidth is unnec-
essary.
How It Works
By enabling partial bandwidth, non-accelerated traffic has priority. All packets for
non-accelerated connections are transferred immediately from the input port to the
output port. In addition, the non-accelerated traffic counts towards the bandwidth
limit, meaning that accelerated traffic backs off in the face of non-accelerated traffic.
This combination of immediate forwarding and backing off means that non-acceler-
ated traffic moves through the network as quickly as it would on an idle link.
With partial bandwidth, the bandwidth limit should be set to the effective data rate of
the link. 90%-95% of the nominal link speed usually works well. Non-accelerated
traffic can monopolize the link during peak periods; accelerated traffic will monopolize
the link when it is otherwise idle.
The effect of partial bandwidth is to make the presence of accelerated connections
invisible to non-accelerated traffic, while allowing accelerated traffic to use bandwidth
that would otherwise be wasted. This eliminates the need for bandwidth schedules,
which are normally used to back off the accelerated bandwidth limit during peak
usage hours.
Partial bandwidth considers only the traffic that passes through the Appliance. This
implies that the Appliance should be placed as close to the LAN/WAN boundary as
possible. Partial bandwidth is used only on the sending Appliance.
Enabling Partial Bandwidth

1. Click the “Partial Bandwidth” box on the “Settings: Bandwidth Scheduler” page.
2. Set the “Bandwidth Limit” to 90% of the quoted data rate (for example, roughly
1.4 Mbps on a T1 line). If the effective data rate is known, set it to 95% of the
effective data rate.
3. Delete any bandwidth schedules. When partial bandwidth is used, the bandwidth
limit should always be 90-95% of the link bandwidth.
8.3.1.5 Accelerated Traffic Minimum Send Rate (Partial Bandwidth

Only)
When used with the partial bandwidth option, this specifies a rate below which accel-
erated traffic will not back off. It defaults to zero, meaning that accelerated connec-
tions can be shut down entirely by non-accelerated traffic.
8.3.1.6 Bandwidth Schedules (Hardboost Only)
The bottom table shows the schedules. The Appliance will use the first schedule that
matches both the time of day and the day of the week. See Figure 8-35.
Schedules are allowed to wrap around past midnight. For example, a schedule of
22:00-4:00 is valid. However, because the bandwidth scheduler performs a simple
AND of the day and time, weekday schedules are truncated at 23:59 on Friday, and
weekend schedules are truncated at 23:59 on Sunday.
Schedules are allowed to overlap. The first schedule in the list to match the current
day and time will be applied.
When making changes to a schedule, remember to press the “Update” button. If you
navigate away from a schedule without pressing “Update,” your changes will be lost.
8-38 September 20, 2010

8.3.1.7 Separate Schedules for Individual Remote Sites

(Hardboost Only)
Another option is to enable separate schedules for specified Acceleration Partners.

Enabling this option will cause a new table to appear on the Bandwidth Scheduler
page: “Appliance to Appliance Bandwidth Control Scheduler.”
Figure 8-35 Bandwidth schedule, showing split send/receive bandwidths and per-site band-
width schedule.
These schedules have all the parameters of a system bandwidth schedule, and adds
an entry for the management address of a remote Appliance. When talking to this
unit, the bandwidth value in the “Appliance to Appliance” table takes precedence over
that in the general table. This allows more bandwidth to be made available to favored
sites, or less to disfavored ones.
As with regular schedules, the bandwidth limit will be the default bandwidth or the
Appliance-to-Appliance bandwidth, whichever is less.
8.3.2 “Configure Settings: Proxy”

Figure 8-36 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.
Proxying involves address translation. The addresses are entered in the Proxy Config-
uration 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-37.
Figure 8-37 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.
8-40 September 20, 2010

Figure 8-38 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 "Beta"
System "Alpha" System "Anvil" 172.16.0.1
10.0.0.51 10.0.0.60
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.
Figure 8-38. shows a configuration that allows users of Network B to access two serv-
ers on Network A: Alpha and Anvil. This corresponds to Case 2 in Section 4.19.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-39, and corresponds to Case 3 in Section 4.19.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-51.
The final example, in Figure 8-40, shows proxy configuration where neither unit is
inlined. This corresponds to Case 4 in Section 4.19.0.2.
Figure 8-39 Proxy configuration, allowing Network A to access “Beta.”
Appliance
VIP Addr: "Beta-Proxy" 172.16.0.201
Appliance
VIP Addr: "Beta-Proxy-A" 10.0.0.154
System "Beta"
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-42 September 20, 2010

Figure 8-40 Proxy configuration with neither site inline.
Appliance
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
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 "Beta"
10.0.0.51 10.0.0.60
Figure 8-41 Appliance-A configuration. The third entry is the first part of a VIP-to-VIP proxy
between Appliance-A and Appliance-B.
Figure 8-42 Appliance-B configuration. Additional VIP addresses have been defined for Alpha
and Anvil.
8-44 September 20, 2010

8.3.3 “Configure Settings: Interface”

Figure 8-43 Configure Settings: Interfaces page
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 Informa-
tion page for the adapter, which is shown in Figure 8-44.
8.3.3.1 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.
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 sec-
ond-by-second graphs.
Figure 8-44 Ethernet adapter detailed information page, top half.
8-46 September 20, 2010

Figure 8-45 Ethernet adapter detailed information page, bottom half.
8.3.4 “Configure Settings: Tuning”

Figure 8-46 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 set-
ting are listed below.
Note: Unlike the other pages, the buttons on the Tuning page are greyed out until
you change a parameter.
8-48 September 20, 2010

8.3.4.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.3.4.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 Appliance’s connection table. The Active Connec-
tions page can identify half-closed connections. If the problem cannot be fixed at its
source, shortening the idle timeout can eliminate the problem.
8.3.4.3 Special Ports
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.3.4.4 Virtual Inline
Virtual inline mode allows a router to send packets to the Appliance and receive pack-
ets 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.8.
8.3.4.5 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.
• The behavior of the middle link depends on the “Full Bandwidth/Partial Bandwidth”
switch on the Bandwidth Management page. Normally, daisy-chained units should
be set to softboost, full bandwidth. If Full Bandwidth is selected on a hardboost
link, competition between ordinary and daisy-chained bandwidth will cause the
link to become overcommitted. If Partial Bandwidth is selected, the daisy-chained
unit will give daisy-chained bandwidth precedence over ordinary accelerated
bandwidth.
8-50 September 20, 2010

8.3.4.6 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.3.4.7 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 suf-
fer. This condition will cause an “SCPS Mode Mismatch” alert.
We recommend that, if you must mix SCPS-enabled Appliances with non-SCPS-
enabled 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.3.4.8 Forwarding Loop Prevention
The “Forwarding Loop Prevention” option allows the same packet to traverse Appli-
ances 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.3.4.9 Generic 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 Sup-
port.
8-52 September 20, 2010

8.3.5 “Configure Settings: SNMP”

Figure 8-47 Configure Settings: SNMP page
This page 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.
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.
8.3.5.1 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.3.5.2 SNMP Data

The following information is available via SNMP:
• Operational Status
• Up, down, failed, unknown
• Load Average (number of running processes) over Past Minute, reported as
int(load_average/100).
• Load Average over Past 15 Minutes
• Bypass Mode (Fail-to-Wire)
• normal, bypass
• Last Alarm
• Active Alarm Table
• Active Alarm Entry
• Alarm index
• Alarm sequence number
• Active alarm ID
• Alarm severity
• Alarm log time
• Alarm description
• Alarm acknowledged
• Alarm service affecting
• Acceleration Status
• Normal, Disabled
• Acceleration Mode
• Softboost, Hardboost
• Bandwidth Limit (kbps)
8-54 September 20, 2010

• WAN Side Bytes Sent in Last Second (KB)

• WAN Side Bytes Received in Last Second (KB)
• LAN Side Bytes Sent in Last Second (KB)
• LAN Side Bytes Received in Last Second (KB)
• Effective Bandwidth After Compression (kbps, Sending BW limit * average com-
pression Ratio)
• Compression Ratio, Sending (compression ratio * 1000)
• Compression Ratio, Receiving (compression ratio * 1000)
• Compression Statistics Collection Lifetime (microseconds)
• Accelerated Connections
• Non-Accelerated Connections
• Service Class Statistics Table
• For each service class: Index, Name, Current Accelerated Connections, Total
Accelerated Connections, Total Accelerated Bytes, Statistics Collection Lifetime
• HA (High-Availability) master IP address
• HA notify new master
• Notify Start
• Notify Shutdown
• Notify Restart
• Notify Bandwidth Limit Change
• Unexpected Restart
• Disabled Due To Persistent Error
8.3.6 “Configure Settings: Date/Time”

Figure 8-48 Configure Settings: 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. The Zone field allows you to choose a
time zone.
If an NTP server is available, type its IP address or DNS address in the “NTP Server”
field. If no NTP server is available, leave this field blank.
To use GMT, select “UTC” from the bottom of the list.
Changes do not take effect until the “Update” button is pressed.
8.3.7 “Configure Settings: Logging”

This page allows you to select the display size for log pages, the maximum log file
size, the maximum exported log size, and to export log files. These should be left at
their default values.
8.3.7.1 Log Options

Figure 8-49 Configure Settings: Log options
These options set the kind of information that is stored in the log:
• Log System Records. This gives general statistics about connections every 60 sec-
onds. Most users will want to disable this option.
• Log Adapter Records. This reports the status of each Ethernet port every 60 sec-
onds. 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 iden-
tifying the endpoints and the connection duration. Leave this option enabled.
8-56 September 20, 2010

• 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.3.7.2 Syslog Server

Figure 8-50 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:”.
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.3.7.3 Exporting Log Files

Figure 8-51 Configure Settings: Log extraction
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 conven-
tions (such as Windows CR/LF vs. UNIX LF).
8-58 September 20, 2010

8.3.7.4 Erasing Log Files

Figure 8-52 Configure Settings: Log extraction
You can erase the log files by pressing the “Remove” button.
8.3.8 “Configure Settings: Alerts”

Figure 8-53 Part of the Configure Settings: Alerts page.
This page allows you to select which events will cause the alert link to appear at the
top of ever UI page. It also controls which alertable conditions are logged. Some
installations will have normal conditions that would be considered errors elsewhere,
such as high packet-loss rates. These can be configured for a higher threshold before
an alert is triggered.
8-60 September 20, 2010

8.3.8.1 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.
8.3.8.2 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 dis-
abled. 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.
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.
The list of alerts in release 4.3 is:
• 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
8.3.8.3 Internal Alerts

Contact your support representative if you receive Alert messages that are not repre-
sented on the “Configure Settings: Alert” page.
Some of these messages give guidance about whether you should contact us immedi-
ately or at your convenience.
8.3.8.4 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-54.
Alerts will clear themselves if the problem goes away for long enough (by default, for
one hour).
8.3.9 “Configure Settings: UI

This page has a range of options relating to the browser-based and LCD front-panel
interfaces It is divided into four tabs.
8-62 September 20, 2010

Figure 8-54 Alert details page
8.3.9.1 Web Access Tab

Figure 8-55 Configure Settings: UI page, Web Access tab
Web Access Protocol. Selects between HTTP (the default) and secure HTTP
(HTTPS).HTTPS is the default
HTTP/HTTPS Port. 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.3.9.2 HTTPS Certificate Tab

Figure 8-56 Configure Settings: UI page, HTTPS Certificate tab
SSL Certificate, SSL Private Key. These boxes allow you to paste in your own certifi-
cate and private key for SSL security, which is used by HTTPS. The Appliance is deliv-
ered with a default SSL key and certificate, which is not particularly secure. To replace
it with your own key and certificate, generate these using your organization’s stan-
dard procedure, then paste them into the boxes on the UI page and press the
“Update” button.
8-64 September 20, 2010

8.3.9.3 Graphing Tab

Figure 8-57 Configure Settings: UI page, Graphing tab
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, which is supposed to have low
losses. 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. Sen-
sible 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.3.9.4 Miscellaneous Tab

Figure 8-58 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 200. This may be set to any value
desired.
User Session Timeout. If the 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-66 September 20, 2010

8.3.10 “Configure Settings: CIFS”

Figure 8-59 CIFS Configuration page.
This page enables or disables CIFS acceleration features and allows acceleration to be
enabled/disabled on a per-IP or per-subnet basis.
CIFS Include/Exclude by Server IP allows individual hosts or networks to be
included or excluded from CIFS acceleration. Networks are specified by base IP and
the number of bits in the host portion of the netmask, as in “10.0.0.0/8”.
Three buttons allow these IP addresses to be ignored (“Accelerate All Traffic”), to
specify the addresses to be accelerated (“Only Traffic with a Server IP Listed Above”),
or excluded (“Never Accelerate Traffic With a Server IP Listed Above.”)
Note that only server addresses can be specified with this mechanism. Plug-in
addresses can’t be specified.
8.3.11 “Configure Settings: Service Class”

Figure 8-60 Service classes
Service classes are defined as lists or ranges of port numbers or IP addresses. They
are used for statistics gathering. In addition, acceleration features are enabled or dis-
abled on a per-service-class basis.
This page shows the list of defined service classes. Clicking on the link holding a ser-
vice class’s name takes you to the definition page. This displays the individual “rules”
or IP/port ranges. These can be modified or deleted, or new rules added, by using the
buttons on the page.
The arrow icons on the right-hand edge of the list bring up buttons that allow you to
rename or delete the selected service class.
8-68 September 20, 2010

8.3.11.1 Creating a New Service Class
Note: Service classes are evaluated in order. Ordering the classes correctly is vital
to proper operation. However, the order cannot be arranged on this page. Instead,
it must be rearranged on the “Service Class Policy” page.
The only exception is when inserting a new service class. This class is inserted
above the highlighted class on the service-class list. This is the last service class
you clicked on, or, if you haven’t clicked on any, it will be at the top of the service
class list.
Click on the “Insert New Service Class” button at the top of the page. Give it a name
and assign it to a QoS traffic class (usually Queue A). Press the “Create” button. This
creates a service class with no rules.
Figure 8-61 Service class definition page
8.3.11.2 Creating New Rules

In the list of service classes, click on the underlined name of the service class. On the
new screen, click the “New Rule..” button. this will put you on the screen shown in
Figure 8-62.
Figure 8-62 Service class definition page
Source and Destination IP Addresses refer to the client system’s source or desti-
nation address. To specify a subnet value, use the standard “/xx” suffix. For example,
“10.0.0.0/8” specifies that the first 8 bits of the address are the network portion,
equivalent to a netmask of “255.0.0.0”.
Bidirectional checkbox. Select the “bidirectional” checkbox if the rule should also
match when the source and destination addresses are reversed. For example, a rule
that specifies a source address of “10.0.0.0/8” would also match a destination
address of “10.0.0.0/8” if the “bidirectional” box is checked.
Port Ranges. When adding new rules, multiple ports can be listed, separated by
commas, and ranges can be used. For example, the entries “80,81,8000,80001” and
“80-81,8000-8001” are equivalent.
8.3.11.3 Creating SSL Rules (rel. 5.7 Only)

Figure 8-63 SSL rules
SSL compression will not take place unless a connection matches an SSL rule. These
rules are created with the ‘New SSL Rule” button. The fields are similar to those for
ordinary rules, except that you are not allowed to leave the dest IP field blank (the
address must resolve to a subnet or individual IP), and at least one SSL profile must
be specified. See Section 4.16 for more information on SSL compression.
8-70 September 20, 2010

8.3.12 “Configure Settings: Service Class Policy”

Figure 8-64 Service class policies
This page sets the evaluation order of service classes and the acceleration, compres-
sion, and queueing options used by each service class:
Flow Control. The “Flow Control” checkbox enables or disables acceleration. If this box
is not checked, the “Compression” and “QoS Queue” settings have no effect.
Compression. The compression option allows you to choose between no compression,
memory compression, and disk compression. The compression setting is not effective
unless flow control is also selected.
QoS Queue. This determines which of the five queues the service class is assigned to.
Dynamic QoS for ICA: ICA (XenApp/Presentation Server) traffic is divided into four
“Priority Classes” (real-time, interactive, bulk-transfer, background). Each class can
be mapped to a QoS queue.
8.3.12.1 Rules are Evaluated In Order

When a connection is opened, the first policy in the list that matches its IP and port
numbers 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.
8.3.12.2 Only Features Allowed by Both Units Are Used

Only 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.
“Unclassified TCP” is a special category that specifies the default action to take if no
other rules apply.
8.3.12.3 Recommendations
• Enable flow control for all service classes except possibly “HTTP (Internet)” and
“HTTPS (Internet)” (See below). “Unclassified TCP” should be disabled for a while
after the initial installation, then enabled after the installation is running smoothly.
• Disable compression (select “None”) for the following services:
• The FTP control channel (should not be compressed because compression
interferes with network address translation, which must snoop the control
channel).
• Encrypted traffic (SSH, HTTPS, etc.). Encrypted traffic is not compressible.
• Enable disk-based compression for ICA (XenApp/Presentation Server), FTP, NFS,
and CIFS.
• Enable disk-based compression for any service that has average transfer sizes of
more than a few megabytes.
• For all other services, use memory-based compression.
Accelerating or compressing only “important” traffic can be done, but this generally
gives inferior results to compressing all traffic (except FTP Control) that is known to
be unencrypted. When in doubt, compress.
8.3.12.4 Special-Case Handling for Internet HTTP/HTTPS

Starting in release 4.1, 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
8-72 September 20, 2010

sometimes include acceleration options. While such connections will be retried as

unaccelerated connections after a timeout period, this is time-consuming and annoy-
ing to the users.
The “HTTP (Private)” and “HTTPS (Private)” 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 net-
works. 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 “HTTP (Internet)” and “HTTPS (Internet)” 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 Appli-
ance. 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.3.13 “Configure Settings: QoS”

Figure 8-65 Configure Settings: QoS page
This page allows you to divide the link bandwidth between the different QoS queues,
as described in Section 4.4. The bandwidth assignments must add up to 100%.
QoS was introduced in release 4.1.
8-74 September 20, 2010

8.3.14 “Configure Settings: IP Address”

Figure 8-66 Configure Settings: IP Address page
This page 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.5. What follows below is a
summary.
8.3.14.1 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 inline mode operation, provided
that the Appliance does not use proxy mode and is not used with Repeater Plug-in. 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. (Access to the management interface
can also be disabled from the “Security: Access” page.) See Section 8.6.3.
8.3.14.2 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 isn’t a router).
Changes do not take effect until you click the “Update” button and restart the unit.
8.3.14.3 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.3.14.4 Web Management Access

By default, the browser-based user interface can be accessed from any enabled inter-
face. You can use this checkbox to disable management access on selected interfaces.
8.3.14.5 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 pack-
ets, but traffic addressed to the Appliance itself must match the Appliance’s VLAN set-
ting – 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.”
8-76 September 20, 2010

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. To disable VLAN support,
use the “VLANDISABLE” command on the serial interface.
VLAN support can also be enabled from the serial interface with the “VLANENABLE x”
command, where x is a decimal number in the range of 0-4095.
8.3.15 “Configure Settings: High Availability”

Figure 8-67 Configure Settings: High Availability page
This page allows you to set up Appliances as high-availability pairs, so that if one unit
fails, the other will take over.
8.3.15.1 Status and Configuration Tab
Note: pressing the “Update button” will terminate all open TCP connections.
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 Appli-
ance. 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 Redun-
dancy 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 rout-
ers), the Appliance is not a router.
Partner SSL Common Name: Copy this from the Acceleration Partner’s “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.3.15.2 Partner Information Tab

Reports the status, SSL common name, software version, and system hardware ver-
sion of the partner Appliance, if any.
8.3.15.3 HA VIP Address Tab

Repeats the VIP information from the “Configure Settings: UI” page.
8-78 September 20, 2010

8.3.16 “Configure Settings: Group Mode”

Figure 8-68 Group mode page.
Group mode was introduced in release 3.1.

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 con-
nection pass through the same Appliance.
Group mode and the fields on the “Group Mode” page are fully explained in Section
4.12.
8.3.17 “Configure Settings: WCCP”

Figure 8-69 Monitoring WCCP status.
The “Configure Settings: WCCP” page was added in release 4.2.17.

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.10 for the procedure for setting up your router and Appliance for use
with WCCP.
A single Appliance can be shared by multiple routers in WCCP mode, which is conve-
nient 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 mul-
ticast 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 inter-
face is disabled, the router will notice this after a timeout period (less than 60 sec-
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.
8-80 September 20, 2010

• 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 addi-
tion 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 router’s address, but the router
does not need to know the Appliance’s address. Although Multicast is the default,
Unicast is the more flexible mode and requires less configuration, so it is recom-
mended.
• 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 router’s 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. Don’t forget to press the “Create” button before leaving the page.
8.3.18 “Configure Settings: Repeater Plug-in”

Figure 8-70 Repeater Plug-in page.
The Repeater Plug-in was introduced in release 4.0.

This page controls how the Appliance interacts with Repeater Plug-in. Repeater
Plug-in support is a licensed option; however, this page is visible even if no Plug-ins
are supported by your license.
8.3.18.1 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 con-
nections 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.
8-82 September 20, 2010

Signaling Channel Source Filtering. (Not available in release 5.5.) Allows you to define
(optional) rules about which source IP addresses are acceptable for Plug-in accelera-
tion. Usually it’s best to attempt acceleration only data connections arriving via the
local VPN. Most other traffic is not accelerable anyway, and since each Plug-in with an
active signaling connection consumes a license, such non-functional signaling connec-
tions can deny service to other users who can actually benefit from acceleration. Set
the rules to accept the IP range used by your local VPN and to exclude everything
else.
Connection Mode. Choices are transparent mode (in which connections are inter-
cepted and accelerated transparently, as with Appliance-to-Appliance communication)
and redirector mode (where the Plug-in addresses accelerated connections to the sig-
naling IP directly. Transparent mode is recommended when convenient, though when
asymmetric routing problems or other path-based problems are encountered, redirec-
tor mode will eliminate these.
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 Appliance’s bandwidth limit will be applied to local connections, which will
greatly reduce the speed of LAN-to-LAN traffic. This feature is effective on release 5.0
Plug-ins and up.
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.3.18.2 Acceleration Rules Tab

Figure 8-71 Plug-in acceleration rules.
This tab defines which Plug-in connections will be accelerated. The rules are based on
the destination address of the connection’s SYN packet (that is, the IP address of the
server). Rules can either include or exclude addresses or port ranges. The first match-
ing entry determines whether Plug-in acceleration is allowed or disallowed.
Note: If the rules on this page specify that acceleration is allowed, acceler-
ation will be enabled even if it is forbidden on the service-class policies
page.
8.3.18.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 connec-
tions will be from Plug-in VPN connections. In this case, accelerating all the traffic
between the Plug-in and VPN is optimal.
8-84 September 20, 2010

8.3.18.4 General Configuration Tab

Figure 8-72 General client configuration.
This tab enables various housekeeping and diagnostic features related to the
Repeater Plug-in. The operation of most features is TBD.
Upgrade Notification/Upgrade URL

By typing a URL that points to a valid Plug-in MSI file in the “Upgrade URL” filed, and
enabling “Upgrade Notification,” users will be prompted to download and install an
upgraded version of the Plug-in whenever the version on the Appliance is newer than
the one the user is running.
Note: This feature is not present in release 5.7. We recommend the use of
Citrix Receiver to distribute updates.
Note: The software checks the Appliance’s version vs. that of the user’s
Plug-in, not the user’s Plug-in vs. the one pointed to by the URL. This means
that, every time you update the Appliance, the users will be prompted to
download an outdated version of the Plug-in if you forget to update the .MSI
file on your Web server at the same time.
8.3.19 “System Settings: Cert/Key for HA/GM” (Rel. 5.7 Only)

Figure 8-73 High-availability and group-mode credentials.
This page’s title means, “Certificates and Private Keys for High Availability and Group
Modes.” When an Appliance is a member of a high-availability pair or group-mode
group, these 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-86 September 20, 2010

8.3.20 “Acceleration Settings: Encryption” (Rel. 5.7 Only)

Figure 8-74 Acceleration Settings: 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, disk-based compression is also disabled
until this password is entered. See Section
• User Data Store. User data, consisting mostly of disk-based compression history,
can optionally be encrypted. 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 Compression. The master enable/disable switch for the SSL compression
feature.
8.3.21 “Acceleration Settings: Peers” (Rel. 5.7 Only)

Figure 8-75 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.16.4, Step 7.
8.3.22 “Acceleration Settings: SSL” (Rel. 5.7 Only)

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.16.4,
Steps 9-10.
Manage CA’s. Allows you to upload CA certificates. See Section 4.16.4, Step 6.
8-88 September 20, 2010

Manage Keys. Upload certificate/key pair. See Section 4.16.4, Step 6.

Import SSL. Upload an SSL configuration previously saved on the Export SSL tab.
Figure 8-76 “Import SSL” tab.
Export SSL. Save the current SSL configuration to a file.

Figure 8-77 “Export SSL” tab.
8.4 The “Reporting” Pages
8.4 The “Reporting” Pages

8.4.1 “Reporting: Generate Report”
Figure 8-78 Generate Report page.
This page was introduced in release 4.1. It allows you to create a system status
report for time periods varying between the last minute and the last month. This
report is created in PDF format and displayed in your browser window, where it can be
viewed, printed, or saved.
The information used to create the report is saved in memory, not disk, so restarting
the Appliance will cause the information from before the restart to be lost.
8-90 September 20, 2010

Figure 8-79 Report format.
8.5 The “System Tools” Pages

8.5.1 “System Tools: Save/Restore Configuration”
Figure 8-80 Save/restore configuration page.
Save Settings/Restore Settings. The unit’s 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 or another Appliance (again, 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 set-
tings, and licenses to their factory defaults.
8-92 September 20, 2010

8.5.2 “System Tools: Update Software”

Figure 8-81 System upgrade page.
8.5.2.1 Upgrading to a New Release

The Appliance software is upgraded by means of patch files that you obtain from Cit-
rix. 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-81), 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 condi-
tion 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.
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-82 Display on a successful patch upload.
Figure 8-83 A reminder is displayed if restarting is deferred.
8.5.2.2 Downgrading to a Prior Release

You can also revert to any previously installed release by selecting it from the “Down-
grade Release” pull-down menu and pressing the “Change” button.
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.5.2.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-94 September 20, 2010

8.5.3 “System Tools: Manage Licenses”

Figure 8-84 System Tools: Manage Licenses page, showing the License Information tab after
a license is installed successfully.
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 infor-
mation.
Note: Release 5.0 introduced a new licensing system. Licenses from older
releases are no longer valid. When upgrading an Appliance to 5.0, a new
license must be installed, using the procedure below. See the release notes
for more information.
8.5.3.1 The License Information Tab

This tab (shown above) give 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.”
Figure 8-85 License Information tab if only a legacy license is installed.
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 Citrix Web page and obtain another.
Note: The procedure for obtaining your license is covered in the release
notes, not in this User’s Guide.
8.5.3.2 The License Configuration Tab

This tab is where you install the license itself. Most Appliances will have one or two
active licenses: one for acceleration, and one for Repeater Plug-in support.
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 can-
not 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-96 September 20, 2010

Figure 8-86 License Configuration tab on the System Tools: Manage Licenses page (rel. 5.5).
8.5.3.3 The License Server Tab (Rel. 5.6 Only)

Figure 8-87 License Server tab on the System Tools: Manage Licenses page (rel. 5.6).
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 cor-
rect). Also, the type of license must be specified in the “Model” pull-down menu. This
specifies the maximum supported bandwidth and needs to match one of the licenses
installed on the remote server.
8.5.3.4 Local Licenses Tab (Rel. 5.6 Only)

This tab is equivalent to the release 5.5. “License Configuration” tab (see Section
8.5.3.2). The only difference is that its content is hidden if the remote license server
option has been selected.
8-98 September 20, 2010

8.5.3.5 The Licensed Features Tab

This tab reports the features that have been licensed for this Appliance.
Figure 8-88 System Tools: Manage Licenses page.
8.5.4 “System Tools: Restart System”

Clicking the “Restart Repeater” button will cause the Appliance to be restarted, a pro-
cess that takes several minutes.

Figure 8-89 System Tools: Restart System page.
8-100 September 20, 2010

8.5.5 “System Tools: View Logs”

Figure 8-90 System Tools: View Logs page.
The logging page shows system activity, including configuration changes and boot
progress messages. See Figure 8-90.
Status reports are logged every minute, including system status, adapter status, con-
nection status, and flow status. Events, including the opening or closing of an acceler-
ated connection, are also logged. Unaccelerated connections are not logged.
Additional detail is available by clicking the link in the left column of the entry. For
example, if you click on the “System Status” entry in Figure 8-90, 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 pre-
viously or one minute later, respectively.
8.6 The “Security” Pages

8.6.1 “Security: Set Certificates”
Figure 8-91 Security: Set Certificates page
This page contains SSL certificates and private keys used by the Appliance. They
should not be changed unless you are instructed to do so by Support.
8.6.2 “Security: Manage Users”

This page allows usernames and passwords to be added, deleted, or updated.
8-102 September 20, 2010

8.6.2.1 Security: Local Accounts

Figure 8-92 Local 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.
Note: If you forget the passwords for all the Admin users, the only way to regain
admin access is to use the RESETTOFACTORY command over the RS-232 serial
port.
8.6.2.2 Authentication
Figure 8-93 RADIUS Authentication Tab
Figure 8-94 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-104 September 20, 2010

8.6.3 “Security: Access”

Figure 8-95 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.6.4 “Security: Logout”

Figure 8-96 Security: Logout page
Clicking this link will end your session. To continue using the browser-based interface,
you must log in again. You will be presented with a login pop-up if you click on any
link.
8.7 The “Diagnostics” Pages

8.7.1 “Diagnostics: Diagnostic Tools”
This page had several troubleshooting aids.
Figure 8-97 Part of the Tracing Tab on the Diagnostics page
8-106 September 20, 2010

8.7.1.1 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.7.1.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
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.7.1.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 fail-
ing 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 corefile 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.7.1.4 Line Tester (Iperf) 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 ade-
quate. When the test is complete, the connection speed will be reported.
8.7.1.5 Ping and Traceroute Tabs

These tabs (not shown) provide the standard network tools ping and traceroute. You
can specify the IP address of the target system and the Ethernet interface to use.
8-108 September 20, 2010

8.7.1.6 System Info Tab

Figure 8-101 Retrieve Cores tab
The “Get System Info” link 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.
8-110 September 20, 2010

Chapter 9
Command Line Interface
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 Appliance’s browser-based UI.
Once logged in, all the CLI commands are available to you.
9.2 SFTP Access

9.2.1 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 Command Description
9.2.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.3.1 CLI Navigation
9.3.1.1 exit
Syntax: exit
Exits from the CLI. Same as "quit."
9.3.1.2 quit
Syntax: quit
Exits from the CLI. Same as "exit."
9.3.1.3 help
Syntax: help "command"
When used in the form of "help command", displays the help topic for the specified
command.
Hint: When in doubt, type "show config-script." This will display the Appliance's
current configuration, which will provide useful examples of the commands and their
syntax.
Example: help save settings
9.3.1.4 show
Syntax: show "parameter"
Displays the current settings of the specified parameter.
Example: show bandwidth
Example Output:
Status: Softboost
Bandwidth: Full
Bandwidth Limit (Send): 325 Kbps

Chapter 9. Command Line Interface
Bandwidth Limit (Receive): 5500 Kbps
9.3.2 System Tools
9.3.2.1 show config-script

Syntax: show config-script [-replicate] [-file "filename"]
Displays the Appliance's 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 (IP addresses, netmasks, VLANs, and
gateways), 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.3.2.2 list config-script-files

Syntax: list config-script-files
Displays a list of the saved configuration files on the Appliance.
9.3.2.3 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, without an "are you sure?"
verification.
9.3.2.4 restart
Syntax: restart
Reboots the Appliance.
CAUTION: This command takes effect immediately, without an "are you sure?"
verification.
9.3.2.5 what
Syntax: what
Reserved for use by Command Center.
9.3.2.6 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.3.2.7 verify software

Syntax: verify software -file "filename"
Performs checks on file "filename" to see if it is a complete, uncorrupted Appliance
software release file.
Note: This command is indented for newly transferred files. Files listed via the "show
software" command are known-good files and cannot be checked by this command.
9.3.2.8 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 indented for newly transferred files. Files listed via the "show
software" command are installed via the "restore software" command.
9.3.2.9 list software-files

Syntax: List software-files
Displays a list of software files brought into the system via SFTP.
9.3.2.10 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.3.2.11 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
Support recommends otherwise.
9.3.3 Security Commands
9.3.3.1 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.3.3.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.3.3.3 set user

Syntax: add user -name "username" -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.3.3.4 remove user

Syntax: remove user -name "username"
Deletes user "username"
9.3.3.5 show access

Syntax: show access [-type {radius, tacacs, web}]
Summarizes the settings for the Web UI and for Radius and TACACS+ authentication,
including the enabled ports and options. By default, all three categories are displayed,
but a single category can be selected with the -type option.
9.3.3.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.3.3.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.3.3.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"] [-ssl-certificate
"certfile" -ssl-key "keyfile"]
Syntax: set access -type support -password “new password”
Syntax: set access -type transfer -password “new password”
Configures login access for different access mechnisms, including setting up Radius
authentication, TACACS+ authentication, Web UI access, and file-transfer access via
SFTP. Note that, for TACACS+, Radius, and Web access, this command configures but
does not enable access, which is done with the "enable access" command.
9.3.3.9 list certificate-files

Syntax: list certificate-files
Displays any uploaded certificate files.
9.3.4 System Status Commands
9.3.4.1 enable unit

Syntax: enable unit
Enables Acceleration. Equivalent to the master enable button on the Web UI Status
page.
9.3.4.2 disable unit

Syntax: disable unit
Disables Acceleration without causing the Appliance process to exit. Equivalent to the
master disable button on the Web UI Status page.
9.3.4.3 show system-status

Syntax: show system-status
Displays the same information as the Web UI's Status page.
9.3.5 IP Address Configuration
9.3.5.1 show dns-server

Syntax: show dns-server
Displays the currently defined DNS server.
9.3.5.2 set dns-server

Syntax: set dns-server "addr"
Sets the IP address of the DNS server. The Applianceuses a single DNS server for all
DNS requests.
9.3.5.3 show hostname

Syntax: show hostname
Displays the currently defined hostname for the Appliance.
9.3.5.4 set hostname

Syntax: set hostname "name"
Sets the Appliance's hostname to "name."
9.3.5.5 show adapter

Syntax: show adapter [{apa, apb, primary, aux1}]
Shows the status and IP settings of all adapters, or, optionally, a single specified
adapter. The information is the same as in the Web UI's "IP Address" page.

9.3.5.6 set adapter

Syntax: set adapter {apa, apb, primary, aux1} [-status {enable, disable}] [-ip
"addr"] [-netmask "mask"] [-gateway "gwaddr"] [-vlan {enable, disable}]
[-vlan-group "groupnumber"]
Sets the parameters of the specified adapter. These are the same parameters used on
the Web UI's "IP Address" page.
9.3.6 Ethernet Configuration Commands
9.3.6.1 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.3.6.2 show interface

Syntax: [-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.3.7 Bandwidth Configuration Commands
9.3.7.1 show bandwidth

Syntax: show bandwidth
Displays the bandwidth limits and other information from the Web UI's Bandwidth
Management page.
9.3.7.2 set bandwidth

Syntax: set bandwidth [-mode {hardboost, softboost}] [-bandwidth {full, partial}]
[-schedule {enable, disable}] [-per-remote-unit {enable, disable}] [-min-rate
"kbps"] [-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 UI's 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.3.7.3 add bandwidth-rule

Syntax: add bandwidth-rule [-start-time "hh:mm"] [-end-time "hh:mm"]
[-day-of-week {weekdays, everyday, weekends}] [-send-limit "kbps"]
[-receive-limit "kbps"] [-remote-unit "addr"]
Adds a bandwidth rule to the bandwidth scheduler. Used by hardboost only.
9.3.7.4 remove bandwidth-rule

Syntax: remove bandwidth-rule {-all, "id"}
Syntax: remove bandwidth-rule [-start-time "hh:mm"] [-end-time "hh:mm"]
[-day-of-week {weekdays, everyday, weekends}] [-send-limit "kbps"] [-receive-limit
"kbps"] [-remote-unit "addr"]
Removes all bandwidth rules, or the one specified by "id," or the one matching the
specified parameters.
9.3.8 Service Class Configuration
9.3.8.1 show service-classes

Syntax: show service-classes
Displays all currently defined service classes. The information is the same as in the
Web UI's Service Class Policy page.
9.3.8.2 add service-class

Syntax: add service-class -name "name" -qos {queue-a, queue-b, queue-c,
queue-d, queue-e, dynamic} [-accelerate {enable, disable}] [-compression {disk,
memory, none}]
Creates a new service class with the parameters shown. These parameters are the
same as those on the Web UI's Service Class Policies page. If not specified,
-accelerate defaults to "enable" and -compression defaults to "disk."
The new service class will be inserted at the bottom of the current list of service
classes. If this is not appropriate, you must delete the entire service class list and
redefine it with the rules in their new order.
9.3.8.3 set service-class

Syntax: set service-class -name "name" [-qos {queue-a, queue-b, queue-c,
queue-d, queue-e, dynamic}] [-accelerate {enable, disable}] [-compression {disk,
memory, none}]
Changes the definition of an existing service class. If not specified, -qos defaults to
"queue-a," -accelerate defaults to "enable" and -compression defaults to "disk."
9.3.8.4 remove service-class

Syntax: remove service-class {-all, -name "name"}
Deletes either the named service class or all service classes.
9.3.8.5 rename service-class

Syntax: rename service-class -old "oldname" -new "newname"
Renames the specified service class.

9.3.8.6 show service-class-rules

Syntax: show service-class rules -name "name"
Displays the currently defined rules for service class "name."
9.3.8.7 add service-class-rule

Syntax: add service-class-rule -name "name" [-source "src"] [-destination ""]
[-bidirectional {enable, disable}] [-ports "port-range"]
Defines a rule for the named service class. The parameters are the same as for
service class rules in the Web UI.
9.3.8.8 remove service-class-rule

Syntax: remove service-class-rule -name "name" {-all, -id "num"}
Removes either all rules for a given service class or the rule at position "num."
9.3.9 ICA Configuration
9.3.9.1 show dynamic-ica-queues

Syntax: show dynamic-ica-queues
Displays the mapping between ICA priority and the five queue definitions
9.3.9.2 set dynamic-ica-queues

Syntax: set dynamic-ica-queues [-priority-0 {queue-a, queue-b, queue-c, queue-d,
queue-e}] [-priority-1 {queue-a, queue-b, queue-c, queue-d, queue-e}] [-priority-2
{queue-a, queue-b, queue-c, queue-d, queue-e}] [-priority-3 {queue-a, queue-b,
queue-c, queue-d, queue-e}]
Maps the four ICA priority levels to the five QoS queues.
9.3.10 QoS Configuration Commands
9.3.10.1 show qos

Syntax: show qos
Displays the current QoS queue definitions.
9.3.10.2 set qos-classname

Syntax: set qos-classname [-queue-a "name"] [-queue-b "name"] [-queue-c "name"]
[-queue-d "name"] [-queue-e "name"]
Renames one or more QoS queues.
9.3.10.3 set qos-bandwidth

Syntax: set qos-bandwidth [-queue-a "percent"] [-queue-b "percent"] [-queue-c
"percent"] [-queue-d "percent"] [-queue-e "percent"]
Divides the bandwidth limit among the QoS queues. The five queues must add up to
100.
9.3.11 SNMP Configuration Commands
9.3.11.1 show snmp

Syntax: show snmp
Reports then enabled/disabled status of the SNMP feature.
9.3.11.2 enable snmp

Syntax: enable snmp
Enables the SNMP feature.
9.3.11.3 disable snmp

Syntax: disable snmp
Disables the SNMP feature.
9.3.11.4 show snmp-system-mib

Syntax: show snmp-system-mib
Displays the current name, location, contact, and authentication failure trap settings.
9.3.11.5 set snmp-system-mib

Syntax: set snmp-system-mib [-name "name"] [-location "location"] [-contact
"name"] [-auth-fail-trap {enable, disable}]
Sets the SNMP name of the Appliance, its location, the contact person's name, and
whether to enable authentication failure traps.
9.3.11.6 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.
9.3.11.7 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.
9.3.11.8 show snmp-trapdest

Syntax: show snmp-trapdest "id"
Displays the SNMP trap destination entry at position "id."
9-10 September 20, 2010

9.3.11.9 add snmp-trapdest

Syntax: add snmp-trapdest -name "name" -ip "addr" [-port "port"] [-version {v1,
v2c}]
Adds a new SNMP trap destination.
9.3.11.10 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.
9.3.12 Alert Configuration
9.3.12.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.3.12.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.3.12.3 reset alert-configuration

Syntax: reset alert-configuration
Sets all Alerts to factory defaults.
9.3.13 WCCP Configuration
9.3.13.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.3.13.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.3.13.3 disable wccp

Syntax: disable wccp
Global WCCP disable.
9.3.13.4 add wccp

Syntax: add wccp -id "id" [-priority "number"] [-accelerated-pair {apa, apb}]
[-router-assignment {hash, mask, auto}] [-router-forwarding {auto, gre, level-2}]
-router-communication unicast unicast-addr "addr" [-state {enable, disable}]
-router-communication multicast -multicast-address "addr" [-time-to-live "ttl"]
[-state {enable, disable}]
Adds a new WCCP service-group definition. The parameters are the same as those on
the WCCP Configuration page on the Web UI.
9.3.13.5 set wccp

-router-communication unicast unicast-addr "addr" [-state {enable, disable}]
-router-communication multicast -multicast-address "addr" [-time-to-live "ttl"]
[-state {enable, disable}]
Alters an existing WCCP service-group definition. The parameters are the same as
those on the WCCP Configuration page on the Web UI.
9.3.13.6 remove wccp

Syntax: remove wccp {-all , -id "num"}
Deletes all WCCP service groups or (with -id) only the specified service group number.
9.3.14 Logging Commands
9.3.14.1 show syslog

Syntax: show syslog
Displays the current syslog parameters.
9-12 September 20, 2010

9.3.14.2 set syslog

Syntax: set syslog -ip "addr" [-port "port"]
Sets the IP address of the syslog server, and optionally the port number.
9.3.14.3 enable syslog

Syntax: enable syslog
Enables syslog logging.
9.3.14.4 disable syslog

Syntax: disable syslog
Disable syslog logging.
9.3.14.5 show log

Syntax: show log [-stats] [-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.3.14.6 set log

Syntax: set log [-max-size "megabytes"] [-display-lines "lines"] [-max-export-lines
"lines"] [-system {enable, disable}] [-adapter {enable, disable}] [-flow {enable, dis-
able}] [-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.3.14.7 extract log

Syntax: extract log -by-record -from "number" -to "number" -records "number"
-format {text, xm} -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 -by-datetime -from "yyyy-mm-dd" ["hh:mm[:ss]"] -to
"yyyy-mm-dd" ["hh:mm[:ss]"] -records "number" -format {text, xml} -type {sys-
tem, 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.3.14.8 list log-extracted-files

Syntax: list log-extracted-files
Displays a list of log files saved by the "extract log" command.
9.3.15 Proxy Configuration
9.3.15.1 show proxy

Syntax: show proxy
Displays the currently defined proxy-mode definitions.
9.3.15.2 add proxy

Syntax: add proxy -local "address" -target {“address”, “dns name”} [-description
“description”]
Adds a new proxy definition.
9.3.15.3 remove proxy

Syntax: remove proxy {-all, -local "address"}
Deletes a proxy definition.
9.3.16 Repeater Plug-in (Client) Configuration
9.3.16.1 show client-rule

Syntax: show client-rule [-id “id”]
Displays the current list of client acceleration rules, or, if a rule number (id) is listed,
displays the specified rule.
9.3.16.2 add client-rule

Syntax: add client-rule -type {accelerate,exclude} -subnet {*, “subnet”) -ports (*,
“port-range”)
Defines a new client rule.
9.3.16.3 remove client-rule

Syntax: remove client-rule {-all, -id “id”}
Deletes a client rule.
9.3.16.4 show signaling-channel

Syntax: show signaling-channel
Displays information about the signaling channel (status, IP, port, and mode).
9.3.16.5 enable signaling-channel

Syntax: enable signaling-channel
Enables the signaling channel, which in turn enables client communication.
9.3.16.6 disable signaling-channel

Syntax: disable signaling-channel
Disables the signaling channel and client communication.
9-14 September 20, 2010

9.3.16.7 set signaling-channel

Syntax: set signaling-channel [-ip “address”] [-port “port”] [-mode {redirector,
transparent}]
Sets the IP/port/mode parameters of the signaling channel.
9.3.16.8 show client-settings

Syntax: show 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 “direcotry”] [-diag-email
“email”] [-diag-popups {enable, disable}] [-diag-uploads {enable, disable}]
Alters the settings on the “General Configuration” tab of the Repeater Plug-in Settings
page.
9.3.17 Group Mode Configuration
9.3.17.1 show group-mode

show group-mode [-type {local, peers, rules}]
Displays group-mode status. By default, all status is shown, but a category can be
specified if desired.
9.3.17.2 enable group-mode

Syntax: enable group-mode
Syntax: enable group-mode -type peer -member-ip “address”
Syntax: enable group-mode -type rule {-all, -id “id”}
The first form enables group mode. The second enables group-mode partnering with
an already-defined peer. The third form enables a group-mode rule.
9.3.17.3 disable group-mode

Syntax: disable group-mode
Syntax: disable group-mode -type peer -member-ip “address”
Syntax: disable group-mode -type rule {-all, -id “id”}
The first form disables group mode. The second disables group-mode partnering with
a peer. The third form disables a group-mode rule.
9.3.17.4 set group-mode

Syntax: set group-mode [-accelerate-with-failure {enable, disable}]
[-forward-loop-prevention {enable, disable}]
Syntax: set group-mode -type local -adapter {apa, apb, primary}
Controls group-mode options.
9.3.17.5 add group-mode

Syntax: add group-mode -type peer -member-ip “address” -state {enable, disable}
-common-name “name” [-ha-common-name “name”]
Syntax: add group-mode -type rule -member-ip “address” -subnet “subnet” -ports
“port-range” [-forwarded-if {match,not-match}] [-state ({enable,disable})]
The first form adds a peer to the group. The second form adds a group-mode rule.
9.3.17.6 remove group-mode

Syntax: remove group-mode -type peer {-all, -member-ip “address”}
Syntax: remove group-mode -type rule {-all, -id “id”}
The first form removes a peer from the group. The second form removes a
group-mode rule.
9.3.18 SSL Commands

These commands closely follow the UI commands for the SSL acceleration feature.
See the SSL Compression section in the “Theory of Operation” chapter and the
descritions of the individual commands in the “Configuration Reference” chapter.
9.3.18.1 SSL Compression Enable/Disable

Syntax: show ssl-acceleration
Syntax: enable ssl-acceleration
Syntax: disable ssl-acceleration
9.3.18.2 SSL Keystore Configuration

Syntax: show ssl-keystore
Syntax: set ssl-keystore -password “clear-text-password” [-old-password
“clear-text-password”]
Syntax: enable ssl-keystore -password "clear-text-password"
Syntax: disable ssl-keystore
Syntax: reset ssl-keystore -password "clear-text-password"
9.3.18.3 SSL Disk Encryption Configuration

Syntax: show ssl-disk-encryption
Syntax: enable ssl-disk-encryption
Syntax: disable ssl-disk-encryption
Syntax: reset ssl-disk-encryption
9.3.18.4 SSL Profile Configuration

Syntax: show ssl-profiles
Syntax: show ssl-profile -id "id"
9-16 September 20, 2010

Syntax: show ssl-profile -name "profile-name"

Syntax: add ssl-profile -name "profile-name" [-state {enable,disable}]
[-virtual-hostname "hostname"] -proxy-type transparent -private-key
"private-key-name"
Syntax: add ssl-profile -name "profile-name" [-state {enable,disable}]
[-virtual-hostname "hostname"] -proxy-type split [-ca-cert-store "store-name"]
-cert-key "cert-key-pair-name" [-build-cert-chain {enable, disable}] [-cert-verify
{none, Signature/Expiration, Signature/Expiration/Common-Name-White-List,
Signature/Expiration/Common-Name-Black-List}] [-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 {Unknown, Deny, Compatible, Old, New}]
[-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"]
Syntax: set ssl-profile -name "profile-name" [-state enable, disable]
[-virtual-hostname "hostname"] [-proxy-type transparent] [-private-key
"private-key-name"]
Syntax: set ssl-profile -name "profile-name" [-state enable, disable]
[-virtual-hostname "hostname"] [-proxy-type split] [-ca-cert-store "store-name"]
[-cert-key "cert-key-pair-name"] [-build-cert-chain {enable, disable}] [-cert-verify
{none, Signature/Expiration, Signature/Expiration/Common-Name-White-List,
Signature/Expiration/Common-Name-Black-List}] [-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 {Unknown, Deny, Compatible, Old, New}]
[-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"]
Syntax: remove ssl-profile {-all, {-id "id"}, {-name "profile-name"}}
Syntax: rename ssl-profile -old "old-profile-name" -new "new-profile-name"
9.3.18.5 SSL CA Certificate Store Configuration

Syntax: show ssl-ca-stores
Syntax: show ssl-ca-store -name "ca-store-name"
Syntax: add ssl-ca-store [-name "ca-store-name"] -file "pathname"
Syntax: remove ssl-ca-store -name "ca-store-name"
Syntax: rename ssl-ca-store -old "ca-store-name" -new "ca-store-name"
9.3.18.6 SSL Certificate/Key Pairs Configuration

Syntax: show ssl-cert-key-pairs
Syntax: show ssl-cert-key-pair -name "cert-key-pair-name"
Syntax: add ssl-cert-key-pair -name "cert-key-pair-name" -type combined -file

"cert-key-pair-file" [-key-password "key-password"] [-cert-password
"cert-password"]
Syntax: add ssl-cert-key-pair -name "cert-key-pair-name" -type separate -key-file
"cert-file" -cert-file "key-file" [-key-password "key-password"] [-cert-password
"cert-password"]
Syntax: set ssl-cert-key-pair -name "cert-key-pair-name" -action add, replace
-cert-key {dsa, rsa} -type combined -file "cert-key-pair-file" [-key-password
"key-password"] [-cert-password "cert-password"]
Syntax: set ssl-cert-key-pair -name "cert-key-pair-name" -action add, replace
-cert-key {dsa, rsa} -type separate -key-file "cert-file" -cert-file "key-file"
[-key-password "key-password"] [-cert-password "cert-password"]
Syntax: set ssl-cert-key-pair -name "cert-key-pair-name" -action remove -cert-key
{dsa, rsa} [-key-password "key-password"]
Syntax: remove ssl-cert-key-pair -name "cert-key-pair-name"
Syntax: rename ssl-cert-key-pair -old "cert-key-pair-name" -new
"cert-key-pair-name"
9.3.18.7 SSL Peer Configuration

Syntax: show ssl-secure-peer-connections
Syntax: enable ssl-secure-peer-connections
Syntax: disable ssl-secure-peer-connections
Syntax: set ssl-secure-peer-connections [-cert-key-name "string"] [-ca-cert-store
"string"] [-cert-verify {"None", "Signature/Expiration"}] [-cipher "string"]
Syntax: add ssl-secure-peer-connections-item -cert-verify {"Signature/Expiration/
Common Name White List", "Signature/Expiration/Common Name Black List"} -item
"string"
Syntax: remove ssl-secure-peer-connections-item {{-item "string"}, -all}
Syntax: show ssl-peer-auto-discovery
Syntax: enable ssl-peer-auto-discovery
Syntax: disable ssl-peer-auto-discovery
Syntax: enable ssl-peer-auto-discovery-publish
Syntax: disable ssl-peer-auto-discovery-publish
Syntax: add ssl-peer-auto-discovery-publish-item -ip-port "ip-addr:port"
Syntax: remove ssl-peer-auto-discovery-publish-item {{-ip-port "ip-addr:port"},
-all}
Syntax: show ssl-peer-listen-on
Syntax: add ssl-peer-listen-on-item -ip-port "ip-addr:port"
Syntax: remove ssl-peer-listen-on-item {{-ip-port "ip-addr:port"}, -all}
9-18 September 20, 2010

Syntax: show ssl-peer-connect-to

Syntax: add ssl-peer-connect-to-item -ip-port "ip-addr:port"
Syntax: remove ssl-peer-connect-to-item {{-ip-port "ip-addr:port"}, -all}
9-20 September 20, 2010

Chapter 10
Serial Monitor Command Set
In addition to the front-panel interface and browser-based interface, the Appliance

supports limited configuration over its serial port. The port should be configured for
9600 baud, 8 data bits, 1 stop bit, no parity. Communication with a PC or terminal
requires a null-modem cable.
Perhaps the most important use of the serial interface is to use the “Adminport” com-
mand to re-enable the browser-based UI after it has been disabled by setting its port
to zero. This command is not available on the front-panel interface.
The following example exercises some of the more commonly used commands of the
serial interface:
Citrix v.Release 2.2.11.1927 Built on Mon Feb 23 17:46:11 2006
============================================================================
==================== COMMANDS
============================================================================
============================
ADDRESS your_ip - Sets the IP address
NETMASK your_net_mask - Sets the netmask
GATEWAY your_gateway - Sets the gateway
DNS your_dns - Sets the dns server address
HOSTNAME your_hostname - Sets the hostname
ADMINPORT protocol:port_number - Sets the port the web admin runs on
(default http:80)
.
.
.
DISPLAY - Displays all network setings
STATUS - Displays FilterStatus.txt file
RESTART - Restart. Must be executed after making changes.
example usage: ADDRESS 192.168.1.50

======================================================================
address 10.0.0.150
Address set to: 10.0.0.150
(After completing changes, you must restart the appliance)

netmask 255.255.255.0
Netmask set to: 255.255.255.0

gateway 10.0.0.60
Gateway set to: 10.0.0.60
dns 10.0.0.60
Dns set to: 10.0.0.60
hostname Appliance-A
Hostname set to: Appliance-A
adminport http:80
Adminport set to: http:80
display
=== Current Settings ===Address: IP: 10.0.0.150

Net mask: 255.255.255.0
Gateway: 10.0.0.60
Dns: 10.0.0.60Hostname: Appliance-A
adminport: 80
restart
Restarting...
10-2 September 20, 2010

Chapter 10. Serial Monitor Command Set
The serial monitor has the following command set:

Figure 10-1 Serial interface command set
Command Example Factory Description
Default
address ip_addr address 0.0.0.0 Address of the apA accelerated

10.0.0.150 interface. This is an IP address
in dotted-quad notation. IP
access is disabled if this
address is set to 0.0.0.0.
netmask netmask 255.255. Netmask for the local subnet on

ip_mask 255.0.0.0 255.255 the apA interface. Dotted-quad
notation.
gateway gateway 0.0.0.0 Gateway for the local subnet on

ip_gateway 10.0.0.60 the apA interface. Dotted-quad
notation.
dns ip_dns dns 10.0.0.60 0.0.0.0 DNS server. Dotted quad

notation.
hostname name hostname localhost Hostname. ASCII text string

Appliance-A (valid hostname characters
only).
adminport port adminport http:80 Protocol and port for http-based

http:80 management interface. If
adminport is set to 0, the
management interface is
disabled
display display Displays all network settings.
status status Displays system status (time

system was last restarted).
restart restart restarts the system. This takes

several minutes.
vlandisable vlandisable Disables VLAN support (factory

default)
vlanenable x vlanenable 1 disabled Enables VLAN support with the

VLAN number set to x (1-4095
decimal).
Figure 10-1 Serial interface command set (Continued)
primaryenable, Sets parameters for the Primary
primarydisable, Ethernet port, which is disabled
primaryaddress, by default. See the commands
primarynetmask, of the same name (but lacking
primarygateway, the “primary” prefix) for syntax
primaryvlaneena and usage.
ble,
primaryvlandisab
le
resettofactory resettofactory Sets the unit’s configuration to

a known state.*
* Resettofactory does the following: Bandwidth schedules and proxy tables are
cleared, acceleration is enabled and the bandwidth limit is set to 100 Mbps, other
variables visible in the browser-based interface are also set to default values, the
browser-based interface port is set to http: 80.
Exceptions: IP parameters (address, netmask, gateway, DNS server, and hostname)
are retained, as are license files.
Note: Though similar, the unit is not set to the same state it was in when it left the
factory, despite the command’s name.
10-4 September 20, 2010

Chapter 11
Specifications and Support
Figure 11-1 Specifications for Repeater Appliances

1U Units: Repeater 65xx and 2U Units: Repeater 68xx and
Physical
85xx 88xx
Height 1.7 in. (4.3 cm) 3.5 in. (8.9 cm)
Width 16.8 in. (42.6 cm) 17.6 in. (44.7 cm)
Depth 23.1 in. (58.6 cm) 29.8 in. (75.7 cm)
Weight 38 lb (17.2 kg) max. 59 lb (26.76 kg) max.
Power Supply
Wattage 300 700
Voltage 100–240 VAC, 50–60 Hz 110/240 VAC., 50-60 Hz
Temperature
Operating 50°F to 95°F (10C to 35C) 50°F to 95°F (10C to 35C)

Temperature
Storage –40°F to 149°F (–40C to 65C) –40°F to 149°F (–40C to 65C)

Temperature
Figure 11-2 Specifications for Branch Repeater Appliances

Physical
Height 1.7 in. (4.3 cm)
Width 17.2 in. (43.7 cm)
Depth 11.3 in. (28.7 cm)
Weight 11.8 lb. (5.4 kg)
Packing Dimensions 22.8 in. x 6 in. x 18 in.
Power Supply
Wattage 78 W typ., 260 W max.
Voltage 100-240 VAC, 50-60 Hz
Temperature
Operating Temperature 50-95 F, 10-35 C at 8-90% humidity, non-condensing
Storage Temperature -40-158F, -40-70 C at 5-95% humidity, non-condensing
11.1 Contact Us
11.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.
本製品に同梱している電源コードセットは、本製品専用です。
電源コードセットは、本製品以外の製品ならびに他の用途で使用いただくことは出来ません。
製品本体には同梱された電源コードセットを使用し、他製品の電源コードセットを使用しないで
ください。
この書面は、あくまでも取? 說明書の追記あるいは別冊の位置付けとなる事を予めご了承くださ
い。
Citrix System, Inc.
883-00002-00
11-2 September 20, 2010

Citrix Branch Repeater Family™: Installation and User's Guide

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Citrix Branch Repeater Family™: Installation and User's Guide

Uploaded by

Copyright:

Available Formats

Citrix Branch Repeater Family™

Installation and User’s Guide

Citrix Systems, Inc.

Portions licensed under the Apache License, Version 2.0 http://www.apache.org/

Need help? Contact Citrix Support. See Section 11.1.

2 Appliance Deployment Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1

3 Installing the Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1

Branch Repeater Family Installation and User’s Guide i

4 Theory of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1

ii September 20, 2010

Branch Repeater Family Installation and User’s Guide iii

5 The Repeater Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1

iv September 20, 2010

6 Branch Repeater VPX (Rel. 5.6 Only) . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1

7 Cabling and Physical Deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1

8 Configuration Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1

Branch Repeater Family Installation and User’s Guide v

vi September 20, 2010

Branch Repeater Family Installation and User’s Guide vii

9 Command Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1

viii September 20, 2010

Branch Repeater Family Installation and User’s Guide ix

x September 20, 2010

11 Specifications and Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-1

Branch Repeater Family Installation and User’s Guide xi

Repeater 8500 Series Appliance

Repeater 8800 Series Appliance

The Appliances support a full range of optimizations, including:

1.1 Branch Repeater Product Line

1.2 Who Should Read This Guide

1-2 September 20, 2010

1.3 What Is In This Guide

1.4 Releases Covered in This Guide

Appliance. Any Repeater, Branch Repeater, Branch Repeater VPX, or Branch

1.6 Note About Screen Captures

1-4 September 20, 2010

Appliance Deployment Guide

WAN Router WAN Router

2.2 Product Selection

Licensed Bandwidth Limit

Repeater Plug-in N/A

Branch Repeater, Branch Repeater with

Branch Repeater VPX 1-45 mbps

Repeater 8500 Series 5-45 mbps

Repeater 8800 Series 45-500 mbps

2-2 September 20, 2010

Data lifetime at 33% link utilization

Repeater 8800 180 days 18 days 43 hours

Repeater 8500 60 days 6 days 14 hours

Data lifetime at 100% link utilization

Repeater 8800 60 days 6 days 14 hours

Repeater 8500 20 days 2 days 5 hours

Ethernet Bypass card

2.3 Selecting a Deployment Mode

2.3.2 WAN-Router-Based Guidelines

See Figure 2-4 as you read this list:

2-4 September 20, 2010

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

A. Single LAN, Single WAN

B. Single LAN, Redundant WANs

C. Single LAN, WANs to Two or More Sites Hop-by-Hop

E. Multiple LANs, Multiple WANs