Citrix Branch Repeater Family™ Branch Repeater Family™ Installation and User’s Guide Release...

Citrix Branch Repeater Family™

Installation and User’s GuideRelease 6.0-6.2

Citrix Systems, Inc.

© CITRIX SYSTEMS, INC., 2012. 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.phpLZS 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.

Contents1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-11.1 - Branch Repeater Product Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-11.2 - Who Should Read This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-21.3 - What Is In This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-21.4 - Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-31.5 - Note About Screen Captures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3

2 Appliance Deployment Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-12.1 - Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-12.2 - Product Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-22.3 - Selecting a Deployment Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-3

2.3.1 - Use Inline Mode When Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-32.3.2 - WAN-Router-Based Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-42.3.3 - Deployment Mode Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-5

2.3.3.1 - Forwarding Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-52.3.3.2 - High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-72.3.3.3 - Acceleration Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-7

2.4 - Forwarding Loop Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-72.5 - Guidelines for Sites With Multiple WAN Routers . . . . . . . . . . . . . . . . . . . . .2-8

2.5.1 - Solving the Problem With Appliances . . . . . . . . . . . . . . . . . . . . . . . . . .2-82.5.2 - Mixing Modes Within a Single Appliance . . . . . . . . . . . . . . . . . . . . . . .2-102.5.3 - Solving the Problem in the Router . . . . . . . . . . . . . . . . . . . . . . . . . . .2-11

2.6 - Deploying to Support VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-122.6.1 - Supporting Repeater Plug-in With Citrix Access Gateway VPNs . . . . . . .2-13

2.6.1.1 - Configuring Access Gateway Standard Edition Support . . . . . . . . . .2-132.7 - Supporting Repeater Plug-in With “One-Armed” Redirector Mode (Not Recom-mended). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-15

3 Installing the Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-13.1 - Installation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-13.2 - Pre-Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-13.3 - Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3

3.3.1 - Install the Appliance Into the Rack . . . . . . . . . . . . . . . . . . . . . . . . . . .3-33.3.2 - Install Ethernet Cables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-33.3.3 - Turn on the Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-73.3.4 - Perform Initial Configuration Via the Front Panel . . . . . . . . . . . . . . . . . .3-73.3.5 - Browser-Based Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-83.3.6 - Quick Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-93.3.7 - Configure the High-Availability Pair . . . . . . . . . . . . . . . . . . . . . . . . . .3-113.3.8 - Set Hardboost Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-133.3.9 - Check Service Class Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-133.3.10 - Configure Repeater Plug-in Support . . . . . . . . . . . . . . . . . . . . . . . . .3-133.3.11 - (WCCP Only) Enable WCCP Mode and Configure Router . . . . . . . . . . .3-153.3.12 - (Virtual Inline Only) Enable Virtual Inline Mode and Configure Router .3-153.3.13 - Security: Change the Admin Password . . . . . . . . . . . . . . . . . . . . . . .3-163.3.14 - Disable Encryption on Outlook 2007 Clients . . . . . . . . . . . . . . . . . . .3-16

3.4 - Testing the Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-173.5 - Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-18

Branch Repeater Family Installation and User’s Guide i

3.5.1 - Cabling and Duplexing Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-183.5.2 - Can’t Connect in Virtual Inline Mode . . . . . . . . . . . . . . . . . . . . . . . . .3-183.5.3 - Compressed Throughput is No Greater than Uncompressed Throughput 3-183.5.4 - No Transfers are Accelerated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-18

3.5.4.1 - TCP Option Usage and Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . .3-193.5.5 - Windows Filesystem (CIFS) Transfers Are Not Accelerated . . . . . . . . . .3-203.5.6 - Accelerated Connections Run, then Hang . . . . . . . . . . . . . . . . . . . . . .3-203.5.7 - Contact Us . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-21

3.6 - Licensing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-213.6.1 - Log Into My Citrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-213.6.2 - Exchanging Licenses From Pre-Release-5.02.0 Appliances . . . . . . . . . .3-223.6.3 - Obtaining a License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-233.6.4 - Licensing Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-24

3.7 - Check Converted Service Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-24• - . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-25

4 Theory of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14.1 - In This Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14.2 - How Acceleration Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1

4.2.1 - Virtual Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14.2.2 - Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-24.2.3 - Lossless, Transparent Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . .4-24.2.4 - Fair Queuing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-34.2.5 - WAN Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4

4.2.5.1 - Transactional Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-54.3 - Acceleration Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6

4.3.1 - Bandwidth Management Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-64.3.2 - How the Appliance Allocates Bandwidth . . . . . . . . . . . . . . . . . . . . . . . .4-64.3.3 - An Appliance Should Become The Bottleneck Gateway. . . . . . . . . . . . . .4-74.3.4 - Performance Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-8

4.4 - Link Definitions and Traffic Shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-84.4.1 - Comparison with Release 5.x QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-94.4.2 - Traffic Shaping Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-94.4.3 - Configuring Traffic Shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-104.4.4 - Defining a Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-11

4.4.4.1 - What is a Link?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-124.4.4.2 - Information Needed to Define a Link. . . . . . . . . . . . . . . . . . . . . . .4-124.4.4.3 - Defining a Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-134.4.4.4 - Example: Simple Inline Link . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-144.4.4.5 - Example: Inline Deployment with Dual Bridges . . . . . . . . . . . . . . .4-164.4.4.6 - Example: Using IP Addresses in Link Definitions. . . . . . . . . . . . . . .4-174.4.4.7 - Example: WCCP and Virtual Inline Modes . . . . . . . . . . . . . . . . . . .4-18

4.5 - Service Class Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-184.5.0.1 - Differences Between Acceleration Policies and Traffic Shaping Policies . .4-204.5.0.2 - Using Service Class Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-20

4.6 - Traffic Shaping Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-204.6.1 - XenApp/XenDesktop Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-22

4.7 - Application Classifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-244.8 - Ethernet Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-25

4.8.1 - Bridged Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-26

ii November 14, 2012

4.8.2 - Motherboard Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-264.8.3 - Port Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-264.8.4 - The Primary Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-274.8.5 - The Aux1 Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-274.8.6 - Using Multiple Bridges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-27

4.9 - Autodiscovery and Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . .4-284.9.1 - Firewall Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-28

4.10 - Forwarding Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-294.11 - Inline Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-31

4.11.1 - Accelerating an Entire WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-324.11.2 - Accelerating Some Systems But Not Others . . . . . . . . . . . . . . . . . . .4-32

4.12 - Redirector Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-334.12.1 - How it Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-334.12.2 - Configuring Redirector Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-35

4.13 - WCCP Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-354.13.1 - How it Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-364.13.2 - Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-374.13.3 - Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-374.13.4 - Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-374.13.5 - Router Support for WCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-374.13.6 - Redirection Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-374.13.7 - Traffic Shaping and WCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-384.13.8 - Router Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-384.13.9 - Appliance Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-394.13.10 - Service Group Configuration Details . . . . . . . . . . . . . . . . . . . . . . . .4-404.13.11 - Testing and Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-41

4.14 - Virtual Inline Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-424.14.1 - How Virtual Inline Mode Works . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-42

4.14.1.1 - Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-434.14.2 - Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-43

4.14.2.1 - How the Appliance Forwards Packets. . . . . . . . . . . . . . . . . . . . . .4-434.14.3 - The Need for Policy-Based Rules . . . . . . . . . . . . . . . . . . . . . . . . . . .4-444.14.4 - Health Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-444.14.5 - Routing Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-464.14.6 - Virtual Inline Mode For Multi-WAN Environments . . . . . . . . . . . . . . . .4-484.14.7 - Virtual Inline Mode and High Availability. . . . . . . . . . . . . . . . . . . . . .4-48

4.15 - Group Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-494.15.1 - When to Use Group Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-50

4.15.1.1 - Alternatives to Group Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-504.15.2 - How Group Mode Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-514.15.3 - Owner Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-52

4.15.3.1 - IP-Based Ownership Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-534.15.3.2 - Failure Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-53

4.15.4 - Setting the Bandwidth Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-534.15.5 - Enabling Group Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-544.15.6 - Setting Forwarding Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-55

4.16 - Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-564.16.1 - XenApp/XenDesktop Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . .4-574.16.2 - How Compression Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-59

4.16.2.1 - Memory-Based Compression . . . . . . . . . . . . . . . . . . . . . . . . . . .4-594.16.2.2 - Disk-Based Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-59

Branch Repeater Family Installation and User’s Guide iii

4.16.3 - Enabling/Disabling Compression . . . . . . . . . . . . . . . . . . . . . . . . . . .4-604.16.4 - Measuring Disk-Based Compression Performance . . . . . . . . . . . . . . .4-61

4.16.4.1 - Testing LAN performance with Iperf . . . . . . . . . . . . . . . . . . . . . .4-624.16.4.2 - Using FTP for initial testing . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-62

4.17 - CIFS (Windows Filesystem) Acceleration . . . . . . . . . . . . . . . . . . . . . . . .4-634.17.1 - CIFS Security and Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-644.17.2 - Interpreting CIFS Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-664.17.3 - CIFS Management Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-67

4.18 - Microsoft Outlook (MAPI) Acceleration . . . . . . . . . . . . . . . . . . . . . . . . .4-674.18.1 - Supported Outlook/Exchange Versions and Modes. . . . . . . . . . . . . . .4-674.18.2 - Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-68

4.18.2.1 - Disabling Encryption on Outlook 2007 . . . . . . . . . . . . . . . . . . . . .4-684.18.2.2 - Performance Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-68

4.19 - Joining a Windows Domain (CIFS/MAPI Enhancements) . . . . . . . . . . . . .4-704.19.1 - Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-704.19.2 - Joining the Windows Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-71

4.19.2.1 - Adding the Kerberos Delegate User. . . . . . . . . . . . . . . . . . . . . . .4-714.19.3 - Enabling NTLM Version 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-74

4.20 - SSL Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-764.20.1 - How SSL Compression Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-774.20.2 - SSL Transparent Proxy and Split Proxy Modes. . . . . . . . . . . . . . . . . .4-77

4.20.2.1 - SSL Split Proxy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-774.20.2.2 - SSL Transparent Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-78

4.20.3 - Generating Security Keys and Certificates . . . . . . . . . . . . . . . . . . . .4-794.20.4 - Configuring SSL Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-79

4.20.4.1 - Configuring the Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-794.20.5 - Using SSL Compression on the Repeater Plug-in . . . . . . . . . . . . . . . .4-86

4.21 - Additional Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-864.22 - Proxy Mode (Legacy Feature). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-87

4.22.0.1 - Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-874.22.0.2 - Proxy Mode Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-904.22.0.3 - VIP-to-VIP Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-91

5 Cabling and Physical Deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-15.1 - Power On/Off. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-15.2 - Ethernet Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1

5.2.1 - Gigabit Ethernet Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-15.2.2 - Fast Ethernet (100 Mbps) Networks. . . . . . . . . . . . . . . . . . . . . . . . . . .5-1

5.2.2.1 - Connector Polarity and Cross-Over Cables . . . . . . . . . . . . . . . . . . . .5-15.2.2.2 - Fast Ethernet Auto-Negotiation Failures . . . . . . . . . . . . . . . . . . . . .5-25.2.2.3 - Older Fast Ethernet Equipment. . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3

5.2.3 - 10BaseT (10 Mbps) Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-35.2.4 - Ethernet Bypass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3

5.3 - VLAN Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-45.4 - What Happens if the Appliance Fails . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-4

5.4.1 - Inline Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-45.4.2 - WCCP Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-45.4.3 - Virtual Inline Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-45.4.4 - Group Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-55.4.5 - High-Availability Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-55.4.6 - Redirector Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-5

iv November 14, 2012

5.5 - High-Availability Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-55.5.1 - Cabling Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-55.5.2 - Other Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-55.5.3 - How High Availability Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-65.5.4 - HA Virtual Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-85.5.5 - Enabling/Disabling High-Availability Mode . . . . . . . . . . . . . . . . . . . . . .5-85.5.6 - Updating Software for a High-Availability Pair . . . . . . . . . . . . . . . . . . . .5-85.5.7 - Saving/Restoring Parameters in the HA Pair . . . . . . . . . . . . . . . . . . . . .5-8

6 The Repeater Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-16.1 - About the Repeater Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1

6.1.1 - Acceleration Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-26.1.2 - Supported Plug-in Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-26.1.3 - Theory of Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-36.1.4 - Detailed Description of Transparent Mode . . . . . . . . . . . . . . . . . . . . . .6-4

6.1.4.1 - Packet Flow in Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . .6-66.1.5 - Detailed Description of Redirector Mode . . . . . . . . . . . . . . . . . . . . . . . .6-76.1.6 - How the Plug-in Selects an Appliance . . . . . . . . . . . . . . . . . . . . . . . . .6-8

6.2 - Deploying Appliances for Use With Plug-ins . . . . . . . . . . . . . . . . . . . . . . . .6-96.2.1 - Use a Dedicated Appliance Where Practical. . . . . . . . . . . . . . . . . . . . . .6-96.2.2 - Use Inline Mode When Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-96.2.3 - Put the Appliances in a Secure Part of your Network . . . . . . . . . . . . . .6-106.2.4 - Avoid NAT Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-106.2.5 - Select Softboost Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-106.2.6 - Define Plug-in Acceleration Rules . . . . . . . . . . . . . . . . . . . . . . . . . . .6-10

6.2.6.1 - Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-116.2.7 - Port Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-126.2.8 - TCP Option Usage and Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-126.2.9 - Compatibility Issue with Pre-Release-4.3 Appliances . . . . . . . . . . . . . .6-12

6.3 - Deploying Plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-126.3.1 - Customizing the Plug-in MSI File . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-136.3.2 - Using Customized Plug-in Software . . . . . . . . . . . . . . . . . . . . . . . . . .6-166.3.3 - Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-176.3.4 - Installation Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-186.3.5 - Running the Plug-in For the First Time . . . . . . . . . . . . . . . . . . . . . . . .6-20

6.4 - Testing the Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-216.5 - Troubleshooting Plug-ins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-216.6 - Repeater Plug-in Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . .6-21

6.6.1 - Basic Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-216.6.2 - Advanced Display. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-22

6.6.2.1 - Rules Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-226.6.2.2 - Connections Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-226.6.2.3 - Diagnostics Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-23

6.6.3 - “Certificates” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-246.6.4 - Uninstalling the Repeater Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . .6-256.6.5 - Updating the Repeater Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-25

7 Branch Repeater VPX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-17.1 - About Branch Repeater VPX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1

7.1.1 - Uses For Branch Repeater VPX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-17.1.2 - Other Branch Repeater VPX Features. . . . . . . . . . . . . . . . . . . . . . . . . .7-4

Branch Repeater Family Installation and User’s Guide v

7.2 - Differences Between VPX and Repeater . . . . . . . . . . . . . . . . . . . . . . . . . .7-57.3 - System Requirements and Provisioning. . . . . . . . . . . . . . . . . . . . . . . . . . .7-6

7.3.1 - Supported Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-67.3.1.1 - Minimum Resource Requirements. . . . . . . . . . . . . . . . . . . . . . . . . .7-67.3.1.2 - Maximum Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-7

7.3.2 - Resource Usage Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-77.4 - Virtual Ethernet Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-87.5 - Upgrading a Previous Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-87.6 - Initial Installation, XenServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-9

7.6.1 - Install XenServer and XenCenter. . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-97.6.2 - Install the Branch Repeater VPX Virtual Machine . . . . . . . . . . . . . . . . . .7-9

7.7 - Initial Installation, VMware vSphere . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-187.7.1 - Configuring Advanced VMware Features. . . . . . . . . . . . . . . . . . . . . . .7-35

7.7.1.1 - VLAN Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-357.7.1.2 - Larger Disks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-377.7.1.3 - VMware Guest Customization. . . . . . . . . . . . . . . . . . . . . . . . . . . .7-39

7.7.2 - VMware Guest Customization Procedure. . . . . . . . . . . . . . . . . . . . . . .7-407.8 - Initial Installation, Hyper-V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-44

7.8.1 - Hyper-V Server Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-447.8.2 - Configure the Hyper-V Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-457.8.3 - Install the Branch Repeater VPX Virtual Machine . . . . . . . . . . . . . . . . .7-46

7.9 - Additional Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-48

8 Repeater on NetScaler SDX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-18.1 - Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1

8.1.1 - Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-18.1.2 - Hardware Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-18.1.3 - Software Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-18.1.4 - Acceleration Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2

8.2 - Installing the Appliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-28.3 - Configuring the Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2

9 Configuration Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-19.1 - Logging Into the UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-19.2 - “Command Menu” Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-2

9.2.1 - “Dashboard” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-29.2.1.1 - “Aggregate Link Throughput” Graph . . . . . . . . . . . . . . . . . . . . . . . .9-29.2.1.2 - “Appliance Status” Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-39.2.1.3 - “Top Applications by WAN Volume” Graph . . . . . . . . . . . . . . . . . . . .9-39.2.1.4 - “Top Service Classes by Compression Ratio” Graph . . . . . . . . . . . . .9-39.2.1.5 - “Top ICA/CGP Applications by WAN Volume” Graph . . . . . . . . . . . . .9-39.2.1.6 - “Traffic Shaping: WAN Throughput” Graph . . . . . . . . . . . . . . . . . . .9-3

9.2.2 - “Features” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-49.2.2.1 - Traffic Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-49.2.2.2 - Traffic Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-49.2.2.3 - Traffic Shaping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-49.2.2.4 - CIFS Protocol Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-49.2.2.5 - Group Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-49.2.2.6 - High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-59.2.2.7 - ICA Multi-Stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-59.2.2.8 - MAPI Cross-Protocol Optimization. . . . . . . . . . . . . . . . . . . . . . . . . .9-5

vi November 14, 2012

9.2.2.9 - SCPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-59.2.2.10 - Secure Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-59.2.2.11 - SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-59.2.2.12 - SSH Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-59.2.2.13 - SSL Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-59.2.2.14 - Syslog Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-69.2.2.15 - User Data Store Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-69.2.2.16 - WCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6

9.2.3 - “Quick Installation” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-69.2.4 - “Logout”. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-8

9.3 - “Monitoring” Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-89.3.1 - “Monitoring: Citrix (ICA/CGP)” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-8

9.3.1.1 - “ICA Connections” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-89.3.1.2 - “ICA Statistics” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-99.3.1.3 - “Acceleration Graphs” Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-10

9.3.2 - “Monitoring: Compression” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-119.3.3 - “Monitoring: Connections” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-12

9.3.3.1 - Selecting Which Accelerated Connections to Show . . . . . . . . . . . . .9-139.3.3.2 - “Unaccelerated Connections” Tab . . . . . . . . . . . . . . . . . . . . . . . . .9-149.3.3.3 - Connection Details Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-159.3.3.4 - Flow Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-18

9.3.4 - “Monitoring: Filesystem (CIFS/SMB)”. . . . . . . . . . . . . . . . . . . . . . . . .9-209.3.4.1 - “Acceleration Graphs” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-209.3.4.2 - “Connections” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-21

9.3.5 - “Monitoring: Logging” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-229.3.6 - “Monitoring: Outlook (MAPI)” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-22

9.3.6.1 - Acceleration Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-229.3.6.2 - Accelerated Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-239.3.6.3 - Unaccelerated Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-24

9.3.7 - “Monitoring: Repeater Plug-ins” . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-249.3.8 - “Monitoring: Secure Partners”. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-259.3.9 - “Monitoring: Server Load Indicator”. . . . . . . . . . . . . . . . . . . . . . . . . .9-279.3.10 - “Monitoring: Usage Graph” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-289.3.11 - “Monitoring: WCCP” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-29

9.4 - “Configuration” Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-319.4.1 - “Configuration: Administrator Interface” . . . . . . . . . . . . . . . . . . . . . .9-31

9.4.1.1 - “Web Access” Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-319.4.1.2 - “HTTPS Certificate” Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-329.4.1.3 - “User Accounts” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-329.4.1.4 - “RADIUS” and “TACACS+” Tabs . . . . . . . . . . . . . . . . . . . . . . . . . .9-339.4.1.5 - “SSH Access” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-349.4.1.6 - “Graphing” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-349.4.1.7 - “Miscellaneous” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-35

9.4.2 - “Configuration: Advanced Deployments” . . . . . . . . . . . . . . . . . . . . . .9-369.4.2.1 - “WCCP Configuration” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-369.4.2.2 - “High Availability (HA)” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-389.4.2.3 - “HA Partner Info” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-399.4.2.4 - “HA VIP Address” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-399.4.2.5 - “Group Mode” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-409.4.2.6 - “HA/Group Mode SSL Certificates” Tab . . . . . . . . . . . . . . . . . . . . .9-419.4.2.7 - “Proxy” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-41

Branch Repeater Family Installation and User’s Guide vii

9.4.3 - “Configuration: Application Classifiers”. . . . . . . . . . . . . . . . . . . . . . . .9-469.4.4 - “Configuration: Licensing” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-47

9.4.4.1 - “License Information” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-489.4.4.2 - “License Server” Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-489.4.4.3 - “Local Licenses” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-499.4.4.4 - “Licensed Features” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-50

9.4.5 - “Configuration: Links” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-509.4.5.1 - “Link Definition” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-509.4.5.2 - The “Create Link” and “Edit Link” Forms . . . . . . . . . . . . . . . . . . . .9-519.4.5.3 - “Hardboost/Softboost” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-529.4.5.4 - “Traffic Shaping” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-53

9.4.6 - “Configuration: Network Adapters” . . . . . . . . . . . . . . . . . . . . . . . . . .9-549.4.6.1 - “IP Addresses” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-549.4.6.2 - Accelerated Pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-549.4.6.3 - Address Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-559.4.6.4 - HA Virtual IP Addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-559.4.6.5 - Web Management Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-559.4.6.6 - VLAN Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-559.4.6.7 - “Ethernet” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-569.4.6.8 - Detailed Adapter Information. . . . . . . . . . . . . . . . . . . . . . . . . . . .9-56

9.4.7 - “Configuration: Logging/Monitoring” . . . . . . . . . . . . . . . . . . . . . . . . .9-589.4.7.1 - “Log Options” Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-599.4.7.2 - “Log Extraction” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-609.4.7.3 - “Log Statistics” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-609.4.7.4 - “Log Removal” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-619.4.7.5 - “Alert Options” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-619.4.7.6 - “Syslog Server” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-639.4.7.7 - “SNMP” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-649.4.7.8 - Installing the SNMP MIB Files. . . . . . . . . . . . . . . . . . . . . . . . . . . .9-65

9.4.8 - “Configuration: Repeater Plug-ins” . . . . . . . . . . . . . . . . . . . . . . . . . .9-659.4.8.1 - “Signaling Channel Configuration” Tab . . . . . . . . . . . . . . . . . . . . .9-659.4.8.2 - “Acceleration Rules” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-669.4.8.3 - Best Practices With Acceleration Rules . . . . . . . . . . . . . . . . . . . . .9-669.4.8.4 - “General Configuration” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-67

9.4.9 - “Configuration: Secure Partners”. . . . . . . . . . . . . . . . . . . . . . . . . . . .9-689.4.10 - “Configuration: Service Classes” . . . . . . . . . . . . . . . . . . . . . . . . . . .9-69

9.4.10.1 - “Service Class Definition” Tab . . . . . . . . . . . . . . . . . . . . . . . . . .9-699.4.10.2 - “Traffic Shaping” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-72

9.4.11 - “Configuration: SSL Acceleration” . . . . . . . . . . . . . . . . . . . . . . . . . .9-729.4.12 - “Configuration: SSL Encryption” . . . . . . . . . . . . . . . . . . . . . . . . . . .9-739.4.13 - “Configuration: Traffic Shaping Policies” . . . . . . . . . . . . . . . . . . . . . .9-74

9.4.13.1 - Creating and Editing Policies . . . . . . . . . . . . . . . . . . . . . . . . . . .9-759.4.14 - “Configuration: Tuning” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-76

9.4.14.1 - Window Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-779.4.14.2 - Connection Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-779.4.14.3 - Special Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-779.4.14.4 - Privileged Ephemeral Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-789.4.14.5 - Virtual Inline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-789.4.14.6 - Daisy-Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-789.4.14.7 - TCP Maximum Segment Size (MSS) . . . . . . . . . . . . . . . . . . . . . .9-799.4.14.8 - Forwarding Loop Prevention. . . . . . . . . . . . . . . . . . . . . . . . . . . .9-79

viii November 14, 2012

9.4.14.9 - Legacy CIFS Protocol Filtering . . . . . . . . . . . . . . . . . . . . . . . . . .9-799.4.14.10 - Generic Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-79

9.4.15 - “Configuration: Windows Domain” . . . . . . . . . . . . . . . . . . . . . . . . . .9-809.5 - “Reports” Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-81

9.5.1 - “Reports: Compression” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-819.5.1.1 - “Compression Graphs” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-819.5.1.2 - “Compression Status” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-82

9.5.2 - “Reports: LAN vs. WAN”. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-839.5.3 - “Reports: Link Usage” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-849.5.4 - “Reports: Service Classes” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-859.5.5 - “Reports: Top Applications” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-86

9.5.5.1 - Historical Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-869.5.5.2 - “Active Applications” Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-87

9.5.6 - “Reports: Traffic Shaping” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-889.6 - “System Maintenance” Pages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-89

9.6.1 - “System Maintenance: Backup/Restore”. . . . . . . . . . . . . . . . . . . . . . .9-899.6.2 - “System Maintenance: Clear Statistics” . . . . . . . . . . . . . . . . . . . . . . .9-899.6.3 - “System Maintenance: Date/Time” . . . . . . . . . . . . . . . . . . . . . . . . . .9-909.6.4 - “System Maintenance: Diagnostics”. . . . . . . . . . . . . . . . . . . . . . . . . .9-91

9.6.4.1 - “Tracing” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-919.6.4.2 - “Bypass Card Test” Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-919.6.4.3 - “Retrieve Cores” Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-929.6.4.4 - “Line Tester” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-939.6.4.5 - “Ping” and “Traceroute” Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-939.6.4.6 - “System Info” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-949.6.4.7 - “Diagnostic Data” Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-95

9.6.5 - “System Maintenance: Restart System” . . . . . . . . . . . . . . . . . . . . . . .9-959.6.6 - “System Maintenance: Update Software” . . . . . . . . . . . . . . . . . . . . . .9-96

9.6.6.1 - Upgrading to a New Release . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-969.6.6.2 - Downgrading to a Prior Release . . . . . . . . . . . . . . . . . . . . . . . . . .9-979.6.6.3 - Changing the Version Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-97

10 Command Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-110.1 - SSH Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-110.2 - RS-232 Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-110.3 - SFTP Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2

10.3.1 - Enabling file transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-210.3.2 - Transferring Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2

10.4 - Command Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-210.4.0.1 - quit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2

10.4.1 - CLI Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-210.4.1.1 - exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-210.4.1.2 - quit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2

10.4.2 - System Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-210.4.2.1 - show config-script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-210.4.2.2 - list config-script-files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-310.4.2.3 - save settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-310.4.2.4 - restore settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-310.4.2.5 - list settings-files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-310.4.2.6 - reset settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-310.4.2.7 - restart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-3

Branch Repeater Family Installation and User’s Guide ix

10.4.2.8 - what . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-410.4.2.9 - show software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-410.4.2.10 - verify software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-410.4.2.11 - install software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-410.4.2.12 - list software-files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-410.4.2.13 - restore software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-410.4.2.14 - set software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-5

10.4.3 - licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-510.4.3.1 - add local-license. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-510.4.3.2 - list license-files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-510.4.3.3 - remove local-license . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-510.4.3.4 - rename local-license . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-510.4.3.5 - show license-models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-510.4.3.6 - show license . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-510.4.3.7 - show local-license. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-610.4.3.8 - set license-server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-6

10.4.4 - Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-610.4.4.1 - show user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-610.4.4.2 - add user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-610.4.4.3 - set user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-610.4.4.4 - remove user. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-710.4.4.5 - show access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-710.4.4.6 - enable access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-710.4.4.7 - disable access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-710.4.4.8 - set access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-710.4.4.9 - list certificate-files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-8

10.4.5 - System Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-810.4.5.1 - enable unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-810.4.5.2 - disable unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-810.4.5.3 - enable acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-810.4.5.4 - disable acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-810.4.5.5 - enable traffic-shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-910.4.5.6 - disable traffic-shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-910.4.5.7 - enable ica-multi-stream. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-910.4.5.8 - disable ica-multi-stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-910.4.5.9 - show system-status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-9

10.4.6 - IP Address Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-910.4.6.1 - show dns-server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-910.4.6.2 - set dns-server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-910.4.6.3 - show hostname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-910.4.6.4 - set hostname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-910.4.6.5 - show adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-910.4.6.6 - set adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-10

10.4.7 - Ethernet Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1010.4.7.1 - set interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1010.4.7.2 - show interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-10

10.4.8 - Bandwidth Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1010.4.8.1 - show bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1010.4.8.2 - set bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-11

10.4.9 - Link Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1110.4.9.1 - show links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-11

x November 14, 2012

10.4.9.2 - show link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1110.4.9.3 - rename link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1110.4.9.4 - remove link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1110.4.9.5 - remove link-filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1110.4.9.6 - move link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1210.4.9.7 - add link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1210.4.9.8 - add link-filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1310.4.9.9 - set link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1310.4.9.10 - set link-filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-14

10.4.10 - Service Class Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1410.4.10.1 - show service-classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1410.4.10.2 - show service-class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1410.4.10.3 - enable service-class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1510.4.10.4 - disable service-class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1510.4.10.5 - rename service-class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1510.4.10.6 - remove service-class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1510.4.10.7 - remove service-class-filter . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1510.4.10.8 - move service-class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1510.4.10.9 - add service-class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1610.4.10.10 - add service-class-filter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1610.4.10.11 - set service-class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1710.4.10.12 - set service-class-filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-17

10.4.11 - Traffic Shaping Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1810.4.11.1 - show traffic-shaping-policies . . . . . . . . . . . . . . . . . . . . . . . . . 10-1810.4.11.2 - show traffic-shaping-policy. . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1810.4.11.3 - add traffic-shaping-policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1810.4.11.4 - set traffic-shaping-policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1910.4.11.5 - rename traffic-shaping-policy . . . . . . . . . . . . . . . . . . . . . . . . . 10-20

10.4.12 - remove traffic-shaping-policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2010.4.12.1 - clear traffic-shaping-policy-stats . . . . . . . . . . . . . . . . . . . . . . . 10-20

10.4.13 - SNMP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2010.4.13.1 - show snmp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2010.4.13.2 - enable snmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2010.4.13.3 - disable snmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2010.4.13.4 - show snmp-system-mib. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2010.4.13.5 - set snmp-system-mib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2010.4.13.6 - show snmp-manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2110.4.13.7 - add snmp-manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2110.4.13.8 - remove snmp-manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2110.4.13.9 - show snmp-trapdest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2110.4.13.10 - add snmp-trapdest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2110.4.13.11 - remove snmp-trapdest . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-22

10.4.14 - Alert Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2210.4.14.1 - show alert-configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2210.4.14.2 - set alert-configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2210.4.14.3 - reset alert-configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-22

10.4.15 - Alert Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2210.4.15.1 - clear alert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2210.4.15.2 - show alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-23

10.4.16 - WCCP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2310.4.16.1 - show wccp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-23

Branch Repeater Family Installation and User’s Guide xi

10.4.16.2 - enable wccp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2310.4.16.3 - disable wccp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2310.4.16.4 - add wccp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2310.4.16.5 - set wccp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2410.4.16.6 - remove wccp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-25

10.4.17 - Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2510.4.17.1 - show syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2510.4.17.2 - set syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2510.4.17.3 - enable syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2510.4.17.4 - disable syslog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2510.4.17.5 - show log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2610.4.17.6 - set log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2610.4.17.7 - extract log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2610.4.17.8 - clear logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2710.4.17.9 - list log-extracted-files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-27

10.4.18 - Proxy Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2710.4.18.1 - show proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2710.4.18.2 - add proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2710.4.18.3 - remove proxy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-27

10.4.19 - Client Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2810.4.19.1 - show client-rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2810.4.19.2 - add client-rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2810.4.19.3 - remove client-rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2810.4.19.4 - show signaling-channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2810.4.19.5 - enable signaling-channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2810.4.19.6 - disable signaling-channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2810.4.19.7 - set signaling-channel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2810.4.19.8 - show client-settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2910.4.19.9 - set client-settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-29

10.4.20 - Group Mode Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2910.4.20.1 - show group-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2910.4.20.2 - enable group-mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2910.4.20.3 - disable group-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3010.4.20.4 - set group-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3010.4.20.5 - add group-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3010.4.20.6 - remove group-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-31

10.4.21 - SSL Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3110.4.21.1 - add ssl-profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3110.4.21.2 - set ssl-profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3210.4.21.3 - show ssl-profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3310.4.21.4 - show ssl-profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3310.4.21.5 - remove ssl-profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3310.4.21.6 - rename ssl-profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3310.4.21.7 - show ssl-optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3410.4.21.8 - enable ssl-optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3410.4.21.9 - disable ssl-optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3410.4.21.10 - show ssl-secure-peer-connections. . . . . . . . . . . . . . . . . . . . . 10-3410.4.21.11 - show ssl-ca-store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3410.4.21.12 - show ssl-ca-stores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3410.4.21.13 - show ssl-cert-key-pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3410.4.21.14 - show ssl-cert-key-pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-34

xii November 14, 2012

10.4.21.15 - show ssl-disk-encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3410.4.21.16 - show ssl-keystore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3510.4.21.17 - show ssl-peer-auto-discovery . . . . . . . . . . . . . . . . . . . . . . . . 10-3510.4.21.18 - show ssl-peer-connect-to . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3510.4.21.19 - show ssl-peer-listen-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3510.4.21.20 - add ssl-ca-store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3510.4.21.21 - remove ssl-ca-store. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3510.4.21.22 - add ssl-cert-key-pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3510.4.21.23 - remove ssl-cert-key-pair . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3610.4.21.24 - add ssl-peer-auto-discovery-publish-item . . . . . . . . . . . . . . . 10-3610.4.21.25 - remove ssl-peer-auto-discovery-publish-item . . . . . . . . . . . . . 10-3610.4.21.26 - add ssl-peer-connect-to-item . . . . . . . . . . . . . . . . . . . . . . . . 10-3610.4.21.27 - remove ssl-peer-connect-to-item . . . . . . . . . . . . . . . . . . . . . 10-3610.4.21.28 - add ssl-peer-listen-on-item . . . . . . . . . . . . . . . . . . . . . . . . . 10-3610.4.21.29 - remove ssl-peer-listen-on-item. . . . . . . . . . . . . . . . . . . . . . . 10-3610.4.21.30 - add ssl-secure-peer-connections-item . . . . . . . . . . . . . . . . . . 10-3610.4.21.31 - remove ssl-secure-peer-connections-item . . . . . . . . . . . . . . . 10-3710.4.21.32 - set ssl-cert-key-pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3710.4.21.33 - set ssl-keystore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3710.4.21.34 - set ssl-secure-peer-connections . . . . . . . . . . . . . . . . . . . . . . 10-37

10.4.22 - Test Mode commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3810.4.22.1 - clear compression-stats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3810.4.22.2 - clear compression-history . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3810.4.22.3 - show object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3810.4.22.4 - set object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-38

10.4.23 - Alert Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3910.4.23.1 - clear application-counters . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3910.4.23.2 - show applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3910.4.23.3 - show application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3910.4.23.4 - add application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3910.4.23.5 - rename application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3910.4.23.6 - remove application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3910.4.23.7 - set application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-39

11 Specifications and Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-111.1 - Contact Us. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-2

Branch Repeater Family Installation and User’s Guide xiii

xiv November 14, 2012

Chapter 1

Introduction

By giving maximum responsiveness at any distance, Repeater Appliances provide that “locally connected” experience to remote users and remote applications. Obviously, cutting down on the time users spend waiting for remote data is the same thing as increased their productivity and satisfaction.

Repeater 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 these benefits continue 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. Repeater Appliances need reconfiguration only when your local WAN link changes.

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, including the new multi-session ICA standard), Microsoft Outlook (MAPI), and SSL, giving protocol optimizations that reduce transaction time (and thus user waiting) and bring all the benefits of multi-session compression.

• Traffic shaping to ensure that high-priority and interactive traffic takes precedence over low-priority or bulk traffic.

• Advanced TCP protocol acceleration, which reduces delays on congested or high-latency links, making our benefits tenacious under difficult network condi-tions.

1.1 Branch Repeater Product LineThe 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).

• Large Datacenters: Repeater on NetScaler SDX. These are the flagship Appli-ances, for high-speed WAN links up to 2 gbps. Repeater on NetScaler SDX (called “Repeater SDX” for short), combines a virtual NetScaler load-balancer with up to eight virtual Repeater appliances. Repeater SDX is affordable because of Citrix’ “pay as you grow’ architecture, where you pay for only the capability you need today, in spite of having the full high-end hardware platform, and a license upgrade will unlock add additional power when you need it.

• Datacenters and Other Busy Sites: Repeater Appliances. There are two Repeater product lines: the 8500 Series, which has a 1U form factor and is suit-

Branch Repeater Family Installation and User’s Guide 1-1

1.2 Who Should Read This Guide

able for links up to 45 mbps, and the 8800 Series, a 2U form-factor accelerator suitable for links up to 500 mbps.

• Branch Offices: 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 Win-dows Server.

• Virtual Appliances: Branch Repeater VPX. The Branch Repeater software is available as a Xen, VMware vSphere, or Hyper-V virtual machine. This product combines the flexibility of virtual machines with the functionality of Repeater appliances, allowing you to use your choice of hardware and combine the VPX with the right combination of other server or appliance virtual machines for your needs.

• Mobile and Remote Users: 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.

1.2 Who Should Read This GuideThis document describes the installation and operation of the Plug-in and Appliance. It assumes that the reader is a network administrator with prior experience in installing Windows software, rack-mount equipment, IP networking, and Ethernet networking.

1.3 What Is In This Guide• Chapter 2 describes how to deploy your Appliance to match your network.• Chapter 3 is a step-by-step installation procedure for the Appliance. • Chapter 4 gives the theory of operation. • Chapter 5 discusses cabling and physical deployment issues. • Chapter 6 covers the Repeater Plug-in.• Chapter 7 describes the Repeater VPX.• Chapter 8 describes Repeater on NetScaler SDX.• Chapter 9 tells how to use the management interface for configuration and ongo-

ing management. • Chapter 10 describes the command-line interface.• Chapter 11 provides product specifications.

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 November 14, 2012

Chapter 1. Introduction

1.4 TerminologySeries. 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.

Appliance. Any Repeater, Branch Repeater, Branch Repeater VPX, or Branch Repeater with Windows Server unit.

Repeater Plug-in. A software-only implementation of Citrix acceleration technology that runs on Windows PCs.

Citrix Accelerator or Citrix Acceleration Plug-in. The Repeater Plug-in.

1.5 Note About Screen CapturesThe screen images shown in this manual were not captured exclusively from your exact product or release. There will be slight variations between the UI in this manual and the one that you see on the product. These variations are normal and should be ignored.


1.5 Note About Screen Captures

1-4 November 14, 2012

Chapter 2

Appliance Deployment Guide

2.1 IntroductionAppliance 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.

Note: Repeater SDX deployment is covered in the Citrix Repeater 500/1000/1500/2000 on NetScaler SDX Administration Guide.

Note: Plug-in deployment is covered in Chapter 6.

Note: Repeater VPX deployment is covered both here and in Chapter 7.

Note: Read this whole chapter before installing your Appliances!

Figure 2-1 Acceleration enhances performance when traffic passes through two Appliances.

NETWORK A NETWORK B

ApplianceWAN LinkTransparent,

AutoOptimized Acceleration

LAN Link LAN Link

Appliance

WAN Router WAN Router

WAN


2.2 Product Selection

2.2 Product SelectionCitrix offers the following acceleration products:

• Repeater on NetScaler SDX. Used in busy datacenters and other extremely high-traffic sites. See the Citrix Repeater on NetScaler SDX Administration Guide for more information.

• 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 virtual machine for Citrix Xen-Server or VMware vSphere. See Chapter 7 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 6 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.

Disk Size

Disk space is used mostly for compression history, and more disk space results in greater compression performance.

The Repeater SDX offers more disk capacity than the other Appliances: up to4 TB for Repeater for SDX, roughly 600 GB for the Repeater 8800, and 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

Figure 2-2 Licensed bandwidth limits by product line

Product Licensed Bandwidth Limit Range

Repeater Plug-in N/A

Branch Repeater, Branch Repeater with Windows Server

1-10 mbps

Branch Repeater VPX 1-45 mbps

Repeater 8500 Series 5-45 mbps

Repeater 8800 Series 45-500 mbps

Repeater 310/500/1000/1500/2000 on NetScaler SDX

310-2,000 mbps

2-2 November 14, 2012

Chapter 2. Appliance Deployment Guide

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

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 and 8500 Series Appliances have redundant disk drives. • Appliances can be used in high-availability mode (two redundant Appliances with

automatic failover).

Best Practices: Your redundancy decision should be consistent with those used for your WAN routers and network servers.

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

Figure 2-3 Examples of disk data lifetime.

Appliance ModelLink Speed

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





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.

See Figure 2-4 as you read this list:

A. Single LAN, Single WAN: Inline mode. The router has a single active LAN interface and a single active WAN interface. The recommended mode for this case is inline mode, which gives the simplest installation, the most features, and the highest performance of any mode. (The difference between hardboost and soft-boost, and inline, virtual inline, WCCP, and group mode will be discussed in Sec-tion 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.

Note: The configurations for which we recommend WCCP mode can all use virtual inline mode instead, but virtual inline is less flexible, has fewer fea-tures, and much less instrumentation than WCCP, and should be used as a mode of last resort only.

2-4 November 14, 2012


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

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

LAN

LAN

WAN

WAN to Site X

WANLAN

WAN to Site Y

WAN to Site X

WAN to Site YLAN

LAN Redundant WANs to Site X

LANRedundant

WANs to Site X

Inline

Inline

WCCP

A. Single LAN, Single WAN

B. Single LAN, Redundant WANs

C. Single LAN, WANs to Two or More Sites

LAN WANLAN

LAN WANLAN

WCCP

LANLAN

LANLAN

WCCP

WAN to Site X

WAN to Site Y

WAN to Site X

WAN to Site Y

D. Dual LANs, Single WAN

E. Multiple LANs, Multiple WANs

LAN

InlineWAN to Site X

WAN to Site Y



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.

Figure 2-5 Options supported for each router topology

Appliances WITH Ethernet Bypass Cards

Config. Mode Softboost Hardboost Group ModeHigh

Availability

A. Inline Yes Yes Yes Yes

B. WCCP Yes No Yes Yes

C1. WCCP Yes No No Yes

C2. Inline Yes No Yes Yes

D. WCCP Yes No No Yes

D2. Inline, Dual

BridgesYes No No Yes

E. WCCP Yes No No Yes

E2. Inline, Dual

BridgesYes No No Yes

Appliances WITHOUT Ethernet Bypass Cards

Config. Mode Softboost Hardboost Group ModeHigh

Availability

A. Inline Yes Yes No No

B. WCCP Yes No No No

C1. WCCP Yes No No No

C2. Inline Yes No No No

D. WCCP Yes No No No

D2. Inline, Dual

BridgesNo No No No

E. WCCP Yes No No No

E2. Inline, Dual

BridgesNo No No No

2-6 November 14, 2012


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

2.4 Forwarding Loop PreventionThe “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

2.5 Guidelines for Sites With Multiple WAN RoutersWhen 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.

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.

Some forwarding modes can deal with asymmetric routing (see also Figure 2-8):

• Multiple Bridges. An Appliance with two accelerated bridges or accelerated pairs (for example, apA and apB), allows two links to be accelerated in inline mode. The two links can be fully independent, load-balanced, or primary/backup links.

• WCCP mode allows a single Appliance to be shared between multiple WAN routers, allowing it to see all the WAN traffic regardless of the link it arrived on.

• Virtual inline mode allows a single Appliance to be shared between multiple WAN routers, allowing it to see all the WAN traffic regardless of the link it arrived on.

Figure 2-6 Asymmetric routing can take place if packets travel via C-E-D instead of C-D.

2-8 November 14, 2012


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

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.

Figure 2-8 By covering all links with either group mode or virtual inline mode, asymmetric routing ceases to be a problem.


2.5 Guidelines for Sites With Multiple WAN Routers

2.5.2 Mixing Modes Within a Single Appliance

In general, all modes are simultaneously active. However, some combinations should not be used together. See Figure 2-10

Figure 2-9 Links leading to sites with only one WAN link cannot create asymmetric routing problems; only sites with multiple links can mis-route packets.

Mix and Match. As shown in Figure 2-9, one end of the link can use virtual inline mode while the other end uses group mode. This is true in general: the two ends of a link do not have to use the same forwarding mode.

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

Supported Combinations, Units WITH Ethernet Bypass Cards

Config. InlineVirtual Inline

WCCP- GRE

WCCP-L2

Multiple Bridges

High Avail.

Group Mode

Repeater Plug-in

Y Y Y Y Y Y N

Inline Y N N N Y Y Y

Virtual Inline

Y Y Y Y Y N

WCCP-GRE

Y Y Y Y N

WCCP-L2

Y Y Y N

Multiple Bridges

Y Y N

High Avail. Y Y

2-10 November 14, 2012


2.5.3 Solving the Problem in the Router

Router configuration to eliminate asymmetric routing involves disabling any kind of dynamic or load-balanced routing for the link, and substituting a static route. This does not mean that the alternate path cannot be used as a failover, but it should not be used unless the accelerated link fails. WCCP and policy-based routing with health-checking both lend themselves to this. The main thing is to prevent the accel-erated link from participating in load-balancing and dynamic routing.

Supported Combinations, Units WITHOUT Ethernet Bypass Cards

Config. InlineVirtual Inline

WCCP- GRE

WCCP-L2

Multiple Bridges

High Avail.

Group Mode

Repeater Plug-in

N N N N N N N

Inline Y N N N N N N

Virtual Inline

Y Y Y N N N

WCCP-GRE

Y Y N N N

WCCP-L2

Y N N N

Multiple Bridges

N N Y

High Avail. N N

Y = Yes, supported. N = Not supported.

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


2.6 Deploying to Support VPNs

2.6 Deploying to Support VPNsVPN 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.

Figure 2-12 One option for accelerating “one-armed” VPNs. The Appliance is on the server side of the VPN. All VPN traffic with a local destination will be accelerated. VPN traffic with a remote destination will not be accelerated. Non-VPN traffic can also be accelerated.

2-12 November 14, 2012


For acceleration to be effective, the VPN must preserve TCP header options. This is true of most VPNs.

2.6.1 Supporting Repeater Plug-in With Citrix Access Gateway VPNs

The Repeater Plug-in is supported by Access Gateway VPNs. See the Branch Repeater Release Notes for a list of supported Access Gateway releases.

2.6.1.1 Configuring Access Gateway Standard Edition Support

(For other VPNs, see your VPN documentation.)

The Access Gateway Standard Edition VPN supports Repeater Plug-in acceleration. Configure Repeater support using the Access Gateway Administration Tool:

1. Go to the “Global Cluster Policies” page and check the “Advanced Option” 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.

Figure 2-13 Alternate method of accelerating “one-armed” VPN traffic. Non-VPN traffic bypasses the Appliance and will not be accelerated.


2.6 Deploying to Support VPNs

3. For each of these addresses, enable all protocols (TCP, UDP, ICMP) and enable “Preserve TCP Options.”

2-14 November 14, 2012


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)

The disadvantages of this deployment are:

• It supports client traffic only. Most deployments involve multiple Appliances and require support for Appliance-to-Appliance traffic.

• By not passing all the WAN traffic through the Repeater, traffic shaping is not effective. Any need to protect non-accelerated traffic will have to be dealt with in the router.

A compromise approach is to use the redirector-mode-only deployment at first, but to be prepared to shift to the topology recommended earlier in this chapter once 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.

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.

2-16 November 14, 2012

Chapter 3

Installing the Appliance

The procedures in this section will get your Appliance up and running.

• Repeater SDX users should read Chapter 8 first.• Branch Repeater VPX users should read Chapter 7 first.• Repeater Plug-in Installation is covered in Chapter 6.• Branch Repeater with Windows Server users should also read the Citrix Branch

Repeater with Windows Server Installation and User’s Guide, rel. 2.0-3.0, for product-specific information.

3.1 Installation OverviewThe 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-InstallationBefore 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 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.

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.

6. Identify your cabling needs and acquire appropriate cables. Use the provided cables if possible. See Section 5.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.

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.

Figure 3-1 Assigning IP addresses

3-2 November 14, 2012

Chapter 3. Installing the Appliance

8. (Virtual inline mode only) Identify an unused Ethernet port on your router, and make sure that you understand how to configure policy-based routing (see Section 4.13).

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 5.5.)

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.

3.3.2 Install Ethernet Cables

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

Figure 3-2 Appliance connectors.


3.3 Installation

Starting with release 4.1, units can be shipped with more than one pair of accelerated LAN/WAN ports. See Section 4.8 for information on using 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. These ports can be used for other purposes. See Section 4.8.

a. You can use either port of an accelerated pair as the WAN-facing port, but when you define your links, you need to know which port that is. Refer to Figure 3-5 for the individual port names. A good convention is to use apA.1 as the LAN port and apA.2 as the WAN port. If only one port is used (WCCP or virtual inline installations), use apA.1.

Figure 3-3 Basic cabling, inline mode

Figure 3-4 Basic cabling, inline high-availability pairs

3-4 November 14, 2012


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.

c. If you are installing a high-availability pair, the two units are connected in parallel, as shown in Figure 3-4.

Figure 3-5 Ethernet port locations on the appliance.

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, which auto-matically detects and compensates for the type of cable.

High availability pairs must have one cable disconnected initially, to prevent data loops. This cable will be installed after HA configuration.

Primary Aux1

apA.1 apA.2

Rear of Appliance, Branch Repeater

Primary Aux1

apA.1 apA.2apB.1 apB.2(optional)

Rear of Appliance, Branch Repeater 8500 Series

Primary Aux1

apA.2


apA.1

apB.2

apB.1

(Optional)


3.3 Installation

d. (Virtual Inline and WCCP Installations.) Install the units as shown in Figure 3-6 and Figure 3-7. Plug the cable into either one of the two ports of the Acceleration unit’s accelerated pair (marked “Accelerated LAN/WAN Ports”) Virtual inline installations are always connected directly to a router port. WCCP installations must also be on an isolated subnet but this isolation can be achieved using methods other than a dedicated router port, such as with a VLAN.

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.

Figure 3-6 Basic cabling, virtual inline and WCCP modes.

Figure 3-7 Basic cabling, virtual inline or WCCP high-availability pair

3-6 November 14, 2012


• (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.

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):

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.

Figure 3-8 Front-panel configuration (Sheet 1 of 2)

15a.Default display while the system boots. The five buttons are shown on the right.

15b.

This display appears after the system is initialized. The top line gives the current accelerated bandwidth limit. The bottom line is a performance bar graph (which will be invisible if no accelerated transfers are underway).

15c.Pressing the down button displays the hostname. This cannot be set from the front panel.

15d.

The accelerated interface (called “apA” starting in release 4.1, and unlabeled in earlier releases) should be on by default.

15e.

Pressing the down button again displays the VLAN tagging status. This defaults to off. If your network does not require a VLAN id to reach the Appliance’s UI, skip to step 15h.


3.3 Installation

3.3.5 Browser-Based Configuration

16. (Virtual Inline Units) Configure your router to allow access to the Appliance’s management IP address.

15f.

If your network requires VLAN tagging:

Press the center button to enter the VLAN tagging menu. Press the up button to turn tagging on. Use the right button to move the cursor to different digits of the decimal VLAN number, and the up/down arrows to change the values of the digits.

15g.Finally, press the center button to submit the VLAN number, and press it again to verify that you wish to keep it.

15h.Pressing the down button again displays the IP address.

15i.

Enter the Management IP address from Step 7. Pressing the middle button allows you to edit the IP address. The left and right buttons move the cursor. The up and down buttons increment and decrement the IP address. Pressing the middle button saves the address.

15j.

Pressing the down button once more displays the netmask. Press the middle button to edit the netmask. The button definitions are the same as when changing the IP address. Press the middle button to stop editing.

15k.Pressing the down button displays the gateway address. Edit as with the IP address.

15l.

Ignore Primary port entries. The Primary port was introduced in release 4.1. Do not configure it now. Press the down button until you see the “Restart?” screen.

15m.

Pressing the down button displays the restart screen. Changes do not take effect until you restart. Press the middle button to restart.

Figure 3-8 Front-panel configuration (Sheet 2 of 2)

3-8 November 14, 2012


17. Using a Web browser, go to the Appliance management page with the URL: http://xx.xx.xx.xx, where xx.xx.xx.xx is the management IP address you assigned in Step 7. You will be prompted for a username and password. The factory default values are “Admin” and “password. (You will change the Admin password in Step 24.)

3.3.6 Quick Installation

The quick installation page serves a a complete installation for simple inline deploy-ments, and as mostly-complete installation for others.

Follow this procedure:

18. In the browser-based UI, click on the “Quick Installation” link.

19. Verify that the information in the “Management Access” section is correct.

Note: Some older browsers are not supported. In particular, Chrome and Internet Explorer versions before 6.x are not supported.

Figure 3-9 “Quick Installation” page.


3.3 Installation

20. Update the “System Services” section.

a. Add your secondary DNS server, if any.

b. Either add your NTP time server (recommended), or manually update the date and time.

c. Set the time zone.

21. Install a license.

a. Most licenses are network licenses. On the “Citrix License Type” entry, select a model number for which your license server has a license, and put the license server’s IP address or hostname (for example, 172.16.0.1 or license-server.example.com) in the “License Server Address” field. This address must be accessible from the Appliance via both ping and a TCP connection on the licensing port. Leave the Licens-ing Service Port at the default unless you know that it uses a non-stan-dard address.

b. If you are using a local license, you will have to add it later. See Section 3.6 on acquiring local licenses, and Section 9.4.4.3 on installing them.

22. Define the WAN link.

a. For the “Receive (Download) Speed” field, enter 95% of the link’s nom-inal download speed. (Most links are specified a few percent higher than their actual throughput due to link-management overhead). Be sure to get the unit of measurement right (kbps or mbps).

b. For the “Send (Upload) Speed” field, enter 95% of the link’s nominal upload speed.

c. For the “WAN-Side Adapter” field, select either apA.1 or apA.2, depend-ing on which port you plugged WAN-side cable into during Step 11.

23. Press the “Install” button. The system will restart.

Note: Your license server must be reachable by ICMP pings from the Appli-ance. This may require reconfiguring your firewall.

3-10 November 14, 2012


24. For security, the Admin password should be changed from its default value after the Appliance restarts. In the browser-based UI, go to the “Configura-tion: Administrator Interface: User Accounts” tab. Press the “Modify” button for the Admin account, check the “Change” box, enter the new password: _____________ twice, and press the “Update” button.

25. For a simple inline deployment, basic installation is complete. You must do additional configuration if:

• Your Appliance is not inline, or is serving multiple WAN links (Section 4.4.4).

• You will be using the Repeater Plug-in (Section 3.3.10).• You are using any of the following deployment modes: High-availability

(Section 3.3.7), group mode (Section 4.15), or WCCP (Section 4.13).• You are upgrading from release 5.x and you defined non-standard service

classes. These are converted automatically, but may require adjustment. See Section 3.7.

• You wish to use any of the following features: hardboost (Section 3.3.8), SSL acceleration (Section 4.15), signed SMB (Windows file system) acceleration (Section 4.20), or encrypted MAPI (Outlook) acceleration (Section 4.19).

26. To test your installation, go to Step 38.

27. Installation is complete.

3.3.7 Configure the High-Availability Pair

28. If you are configuring a high-availability pair, set up the HA functionality first, then finish the configuration using the virtual IP address that controls both units together.

This procedure also works when creating an HA pair by adding a second unit to an existing installation.

a. On the “Features” page of the first Appliance, disable “Traffic Process-ing.” This will disable acceleration until the HA pair is configured.

b. Repeat for the second Appliance.

c. On the first Appliance, go to the “Configuration: Advanced Deploy-ments: High Availability” tab. See Figure 3-10.

d. Check the “Enabled” box.

e. Follow the “Configure HA Virtual IP Address” link and assign the virtual IP address you selected in Step 9. to the apA interface. This address will be used later to control both units together.


3.3 Installation

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-figuration: Advanced Deployments: High Availability” tab) in the “Part-ner 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 “Traffic Processing” on the “Features” page. The rest of the installation will be performed from this virtual address.

k. Plug in the cable that was left disconnected.

Figure 3-10 High-availability configuration page.

3-12 November 14, 2012


3.3.8 Set Hardboost Mode

29. Follow this procedure only if you selected hardboost mode in Step 5. Click the “Bandwidth Management” link. This will show you the bandwidth page.

a. Make sure the acceleration mode (hardboost or softboost) matches the one you selected in Step 5.

b. For now, set the “WAN Bandwidth Send Limit” and “WAN Bandwidth Receive Limit” to 95% of the link bandwidth in both the sending and receiving directions (note that your link may have different speeds for each direction). This should match the send/receive speeds you used when defining your WAN link. Press the “Update” button.

3.3.9 Check Service Class Settings

30. On the “Configure: Service Classes” page, check the following:

a. HTTP Settings. If the Appliance is being used only with Repeater Plug-in, or the path between users and the Internet passes through two Appliances, then go to the “Web (Internet)” service class policy. Select the “Accelerate” checkbox and set compression to “Disk.” See Figure 3-12.

b. HTTPS Settings. If the Appliance is being used only with Repeater Plug-in, or the path between users and the Internet passes through two Appliances, then go to the “Web (Internet-Secure)” service class policy. Select the “Accelerate checkbox and set compression to “None.”

c. Press the “Apply” button to save your changes.

3.3.10 Configure Repeater Plug-in Support

31. Follow these steps only if you will use the Appliance with the Repeater Plug-in.Go to the Appliance’s “Configuration: Repeater Plug-ins: Signaling Channel Configuration” tab. (See Figure 3-13.)

a. Enter the Signaling IP from Step 7 in the “Signaling IP” field.

Figure 3-11 Hardboost bandwidth setup.


3.3 Installation

Figure 3-12 Service Class Policies page.

Figure 3-13 Repeater Plug-in Support.

3-14 November 14, 2012


b. Leave the Signaling Port and Connection Mode at their default values. These will be updated later.

c. Press “Update”

32. On the “Configuration: Repeater Plug-ins: Acceleration Rules” tab:

• Add an “Accelerated” rule for each local LAN subnet that can be reached by the Appliance. That is, press the “ADD” button, specify “Accelerate,” and type in the subnet IP/mask.

• Repeat for each subnet that is local to the Appliance.• If you wish to exclude some portion of the included range, add an

“Exclude” rule and move it above the more general rule. For example, 10.217.1.99 looks like a local address but is really the local end of a VPN unit, create an “Exclude” rule for it on a line above the “Accelerate” rule for 10.217.1.0/24.

• If you wish to use acceleration only for a single port (not recommended), such as port 80 for HTTP, replace the wildcard in the “Ports” field with this value. To support more than one port, add additional rules, one per port.

• In general, narrow rules (usually exceptions) should be listed first, then general rules.

• 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.3.11 (WCCP Only) Enable WCCP Mode and Configure Router

33. WCCP was introduced in release 3.0. To configure your Appliance for WCCP, follow the procedures in Section 4.13.

3.3.12 (Virtual Inline Only) Enable Virtual Inline Mode and Configure Router

34. Go to the “Tuning” page and select the “Return to Ethernet Sender” button if it is not already selected. (See Section 4.14.)

Figure 3-14 Setting Plug-in rules on the Appliance


3.3 Installation

35. Reconfigure your router to forward inbound and outbound WAN traffic to the Appliance, using policy-based routing based on the ingress port to prevent routing loops. The basic technique is:

Route inbound traffic from the WAN interface to the Appliance.

Route outbound traffic from the WAN interface to the Appliance.

3.3.13 Security: Change the Admin Password

36. On the “Configuration: Administrator Interface: User Accounts” tab, press the “Modify” button and change the admin user password. Press the “Update” button when done.

3.3.14 Disable Encryption on Outlook 2007 Clients

37. To get the benefits of Microsoft Outlook (MAPI) acceleration on Outlook 2007, encryption must be disabled on the users’ systems. See Section 4.18.2.

Figure 3-15 Using the Tuning page for virtual inline modes.

3-16 November 14, 2012


3.4 Testing the Installation38. Ping the remote Appliance at its management address to make sure it is run-

ning.

39. On your local Appliance’s management page, click the “Dashboard” link to see the traffic passing through the Appliance. The graphs will be updated periodically (by default, once per minute).

40. 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, iperf, HTTP, SMTP, and so on.)

41. 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, and the throughput should be considerably faster than the WAN link. (If not, you may have gotten apA.1 and apA.2 reversed in your link definitions. This can be fixed on the “Configuration: Links” page.

Compression ratios can be read on the “Monitoring: Connections” page (on the “Accelerated Connections” tab. By default, only open connec-tions are displayed, but if you change the “Connection State” filter to “Any,” the data will persist for about a minute after the connection closes.

42. Check for CIFS acceleration:

a. Reboot a convenient PC or workstation and mount all the CIFS (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.

b. Look at the “Monitoring: Filesystem (CIFS/SMB)” page. Your connec-tions to CIFS file servers should be listed under “Accelerated CIFS Con-nections.” If they are listed under “Non-Accelerated CIFS Connections” with “Reason 3: Security Settings,” you need to disable “CIFS Signing” on your server. See Section 4.17.1. If the connections are not listed at all, you have a routing or setup problem.

43. Your installation is up and running! Additional configuration you may wish to perform includes:

a. Bandwidth tuning (Section 4.3.4).

b. Adding user accounts (Section 9.4.1.3).


3.5 Troubleshooting

c. Altering traffic-shaping policies if the default ones prove to be inade-quate for some reason. (Section 4.6.)

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 use 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 5.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).• Router misconfiguration. Router loops or other configuration problems may be

preventing connections from succeeding.

3.5.3 Compressed Throughput is No Greater than Uncompressed Throughput

This generally happens if the LAN and WAN ports are reversed on the “Configuration: Links” page.

3.5.4 No Transfers are Accelerated

If the transfer succeeds, but is not accelerated (the “Monitoring: Usage Graph” page doesn’t show the bandwidth as “Accelerated” bandwidth or shows no bandwidth usage at all) then:

• Inline mode: If the bandwidth is not shown as accelerated bandwidth, one or both of the Appliances is not enabled, or the remote Appliance is not installed, or at

Note: On Branch Repeater VPX, the VPX virtual machine cannot discover the speed and duplex mode of the physical Ethernet ports, so troubleshoot-ing must be done with the aid of the hypervisor.

3-18 November 14, 2012


least one unit is not on the path taken by the data. If no bandwidth usage is shown at all, the local Appliance is not on the path taken by the data (check your cabling and routing tables).

• Virtual inline and WCCP modes: If the traffic doesn’t appear at all on the Appli-ance’s usage graph, then the router isn’t routing the traffic through the Appliance. Check your configuration.

• General: Your firewall or router may be overly aggressive about blocking connec-tions, and is rejecting accelerated traffic because it has unusual TCP options. See

3.5.4.1 TCP Option Usage and Firewalls

Acceleration parameters are sent via TCP options. These may occur in any packet, and are guaranteed to be present in the SYN and SYN-ACK packets that establish the connection.

Your firewall must not block TCP options in the range of 24-31 (decimal), or 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 WSOptionshostname(config-tcp-map)# tcp-options range 24 31 allowhostname(config-tcp-map)# class-map WSOptions-classhostname(config-cmap)# match anyhostname(config-cmap)# policy-map WSOptionshostname(config-pmap)# class WSOptions-Classhostname(config-pmap-c)# set connection advanced-options WSOptionshostname(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 anypixfirewall(config)# tcp-map tcpmappixfirewall(config-tcp-map)# tcp-opt range 24 31 allowpixfirewall(config-tcp-map)# exitpixfirewall(config)# class-map tcpmappixfirewall(config-cmap)# match access-list tcpmap pixfirewall(config-cmap)# exitpixfirewall(config)# policy-map global_policypixfirewall(config-pmap)# class tcpmap pixfirewall(config-pmap-c)# set connection advanced-options tcpmap

3.5.5 Windows Filesystem (CIFS) Transfers Are Not Accelerated

A lack of acceleration on Windows filesystem (CIFS) transfers is usually caused by one of the following:

• Persistent connections. Only connections that are started after Acceleration is enabled are accelerated. CIFS connections are very persistent, and it is usually necessary to dismount and remount the filesystem on the client (or reboot) before acceleration will be seen. To see the full effects of acceleration, restarting the file server is the quickest method of guaranteeing that all the old connections have closed, though this is disruptive in a production environment.

• Security signing. A Windows server option called “signing” adds authentication data to CIFS transfers. Signing prevents the CIFS protocol from being optimized (unless the Appliance has joined a Windows domain. See Section 4.19.2), though it does not interfere with compression or flow control. See Section 4.17.1.

A log message is created when this happens:CIFS Session from client <ip> to server <ip> cannot be accelerated for CIFS due to: server security settings.

3.5.6 Accelerated Connections Run, then Hang

This is typically a problem when a VPN adds so much additional header/trailer data to the packets that they become fragmented. Many networks have broken or poorly functioning fragmentation machinery, and the connection hangs after a series of full-sized packets is fragmented.

This happens on a per-connection basis, and non-bulk-transfer connections (such as ssh terminal sessions) are often not affected.

The log of the receiver-side Acceleration unit may contain large numbers of “TCP Checksum Error” messages.

The Acceleration unit already uses a reduced MSS to make room for its own headers and those of other equipment, but this needs to be reduced further if these problems are seen.

3-20 November 14, 2012


To fix this problem, two packet-size parameters need to be reduced. In most cases, reducing DefaultMss and MaximumMss to 1340 bytes (from their default of 1380) will fix the VPN fragmentation problem.

The MSS value can be changed on the “Configuration: Tuning” page. Setting “Default-Mss” to 1340 and “MaximumMss” to 1340 should solve the “VPN hang” problem.

3.5.7 Contact UsNeed help? Contact Citrix Support. See Section 11.1.

3.6 LicensingStarting with Release 6.0, Citrix network licensing is the normal method of obtaining licenses for Appliances. On the “Quick Installation” page, specifying a license server, and a Repeater/Branch Repeater model number for which licenses are available on that server, are all that is required to license the Appliance.

Obviously, for the Appliance to acquire a network license, it must be able to open a connection to the network license server. The network license server must also respond to ping requests.

To obtain these licenses, follow the procedure below.

3.6.1 Log Into My Citrix

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

Note: Your license server must be reachable by ICMP pings from the Appli-ance. This may require reconfiguring your firewall.

Figure 3-16 Login page at http://www.MyCitrix.com.


3.6 Licensing

3.6.2 Exchanging Licenses From Pre-Release-5.02.0 Appliances

• You need the model number of your existing Appliance for this step. You will need its host ID as well, but not yet.

• Select “My Tools: Product Upgrade/Fulfillment.” On the “Product Upgrade/Fulfill-ment” page, select “Upgrade Eligible Products.”

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

• Select your product line and model number on two dropdown menus and press “Submit”

Figure 3-17 Navigating to the “Product Upgrades/Fulfillment” page.

Figure 3-18 The “Upgrade Eligible Products” tool.

3-22 November 14, 2012


• 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.3 Obtaining a License• This step uses the “Activation System/Manage Licenses” tool, which is reached

from the “My Tools: Activation System/Manage Licenses” dropdown.• Select “Activate/Allocate” from the “Current Tool” dropdown. • Enter the license code from the email into the “License Code” field.• You will asked for the host ID of your license server. This can be discovered run-

ning lmhostid. Typically, this is done from the command line:cd \Program Files\Citrix\Licensing\LSlmhostid

• Follow the prompts to the end of the procedure.

• At the end of this process, you will generate a license file. Download this file to your computer. You will add this to your license server in the usual way.

• If your Appliance supports the Repeater Plug-in (Repeater and Branch Repeater VPX Appliances do: Branch Repeater and Branch Repeater with Windows Server Appliances do not), repeat the procedure to convert Client concurrent user entitle-ments into a concurrent user license for the license server.

• If you use high-availability pairs or Appliances at disaster recovery sites, you can “return and reallocate” your Repeater Plug-in licenses from the first Appliance for use on a second one without losing their functionality on the first Appliance. This allows client licenses to be active in two places at once. Use the “Activation Sys-tem/Manage Licenses” tool on My Citrix to return and reallocate the licenses.

Figure 3-19 Entering the license code.


3.7 Check Converted Service Classes

• Reallocation can be done a fixed number of times (determined by Citrix). Only one copy of a license is allowed to be in use at any given time.

3.6.4 Licensing Notes• If you are a Citrix Partner, you can receive Not for Resale licenses via the “Partner

Toolbox” on My Citrix.• You can find additional information at the following locations:

• Licensing README: http://support.citrix.com/proddocs/topic/licensing/lic-readme.html

• Citrix Licensing: http://support.citrix.com/pages/licensing• Obtaining License Files from My Citrix: http://support.citrix.com/proddocs/

index.jsp?topic=/licensing/lic-obtaining-your-license-files.html• Citrix License Server for Windows Software and Documentation: https://

www.citrix.com/English/ss/downloads/results.asp?productID=186 • Citrix WANScaler Software and Documentation: https://www.citrix.com/

English/ss/downloads/results.asp?productID=33886• Citrix Branch Repeater Software and Documentation: https://www.citrix.com/

English/ss/downloads/results.asp?productID=1350184

3.7 Check Converted Service ClassesRead this section if you are converting an Appliance from release 5.x and you defined non-default service classes.

The “Configuration: Service Classes” page maps applications to acceleration and traf-fic-shaping policies. When upgrading from release 5.x, the service class definitions and policies are updated to their release 6.0 equivalents when possible, and are translated into release 6.0 otherwise. If for some reason the definition cannot be translated, the service class is disabled and flagged as shown in Figure 3-20.

Possible issues include:

• Service classes which contained no rules. This was allowed in release 5.x, but in release 6.0 such definitions are disabled automatically.

• Service classes that specified a wide range of port numbers, such as “33000-34000.” These can fail because they overlap the ports in an existing appli-cation definition.

• If a service class includes a port list or port range that includes any port from a release 6.0 application, the entire application (and thus all its ports) will be included in the updated rules.

When examining service class policies:

• Go to the “Configuration: Service Classes” page and scan the definitions for ones with the red icon indicating that they are disabled. Reimplement the service classes as necessary. This may require creating new application definitions, since port ranges have been shifted from the “Service Classes” page to the “Application Classifiers” page.

3-24 November 14, 2012


• Scan the “Traffic Shaping Policy” column to ensure that the policies for the service classes are appropriate. In general:

• VoIP and interactive applications like the XenApp (ICA and CGP) are given higher priorities,

• background bulk-transfer applications are given lower priorities, • and most applications are given the default priority.

• It is best to change as few policies as possible from their defaults until perfor-mance has been monitored for some time and a baseline has been established.

For more information on service classes, see Section 4.5.

Figure 3-20 Checking for untranslatable service classes.


3-26 November 14, 2012

Chapter 4

Theory of Operation

4.1 In This Section• How Acceleration Works (Section 4.2).• Bandwidth Control (Section 4.3).• Link Definition (Section 4.4).• Service Classes and Traffic-Shaping Policies (Section 4.5-4.7).• Ethernet Ports (Section 4.8).• Autodiscovery and Autoconfiguration (Section 4.9).• Forwarding Modes (Section 4.10-4.15).• Compression (Section 4.16).• CIFS (Windows Filesystem) Acceleration (Section 4.17).• Microsoft Outlook (MAPI) Acceleration (Section 4.18).• SSL Compression (Section 4.20).• Other Features (Section 4.21).• Proxy Mode (Section 4.22).

4.2 How Acceleration WorksOrdinary 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 How Acceleration Works

4.2.2 Optimizations

Optimization techniques fall into these interrelated categories:

1. Lossless, transparent flow control.2. Fair Queuing3. WAN Optimizations 4. Compression (Section 4.16)5. Windows Filesystem (CIFS) acceleration Section 4.17)

4.2.3 Lossless, Transparent Flow Control

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.

Figure 4-1 Acceleration enhances performance transparently.

NETWORK A NETWORK B

ApplianceWAN LinkTransparent,

AutoOptimized Acceleration

LAN Link LAN Link

Appliance

WAN Router WAN Router

WAN

4-2 November 14, 2012

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 relies on the link definitions (Section 4.4) and the traffic-shaping policies (Section 4.6), which allow weighted fair queuing, so some traffic can be given a higher priority than others.


4.2 How Acceleration Works

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.

Non-TCP traffic, such as UDP, is not accelerated. It is still managed by the traffic shaper, however.

Figure 4-2 Fair queuing in action.

Sched-uler

DATA

ACK

DATA

ACK

DATA

ACK

Per-ConnectionQueuesData Streams

4-4 November 14, 2012


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

Figure 4-3 Non-accelerated TCP performance plummets with distance

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

One-WayDistance(Miles)

0.01 0.1 1.0 10 100 1,000 10,000

Dialup

ADSL

T1

T3 100Mb/s

1Gb/sOC-12

OC-48OC-192

10 Mb/s

Connection Speed (Mb/s)

Long-Haul(Limited by TCP)

Short-Haul(Limited by Line

Speed)

100,000

10,000

1,000

100

10

1

0.1

Worldwide

Cross-Country

Cross-State

Cross-City(MAN)

Cross-Campus

OC-3

10Gb/s


4.3 Acceleration Modes

4.3 Acceleration Modes

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 link’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 utilization. This means that interactive applications see fast response times while bulk-trans-fer applications see high bandwidth. Softboost will share the network with other applications in any topology and will also interoperate with third-party QoS sys-tems.

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

4.3.2 How the Appliance Allocates Bandwidth

The Appliance uses a rate-based sender for WAN traffic, sending packets based on a bandwidth limit that is set manually for each link.

The rate at which an Appliance sends accelerated data depends on several parame-ters:

• The bandwidth limit, set on the “Configuration: Links” page of the management interface. This value limits the maximum rate at which both accelerated and non-accelerated traffic will be sent or received on any individual link. Separate limits are placed on sending and receiving, to accommodate asymmetric links

• For hardboost, a second bandwidth limit is also used, that limits accelerated band-width (only) independently of the link speed. Normally, these two limits are the same. This is set on the “Hardboost/Softboost” tab on the “Configuration: Links” page.

• The licensed bandwidth limit, which is the highest value that can be entered in the “sending BW limit” field. This is controlled by the Appliance’s license. The receiving limit is unconstrained. The license key is preinstalled into your unit. Updated keys can be installed through the management interface. See Section 9.4.4.

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-6 November 14, 2012


4.3.3 An Appliance Should Become The Bottleneck Gateway

The fair queuing algorithm used by Appliance’s traffic shaper is more sophisticated than typical router-based QoS. To take advantage of this, the bandwidth limit of the Appliance should be set slightly lower than the link speed, when possible. By injecting packets into the network slightly slower than the link speed, they never back up in the router, which minimizes queueing.

Normally a setting of approximately 95% of the link speed gives optimum results.

For variable-speed links, the bandwidth limit should be set to 95% of the maximum expected speed.

Example 1: On a 1.5 mbps point-to-point link with a bit rate of 1.54 mbps, set the sending and receiving bandwidth limits to 95% of 1.54 mbps, or 1463 kbps. Either hardboost or softboost can be used.

Example 2: Suppose you have a simple hub-and-spoke deployment. Site 1 has two T1 links, one terminating at Site 2 and one terminating at Site 3. If all three sites have Appliances, then the hub Appliance would have its bandwidth limits set to 95% of the aggregate bandwidth (twice the value in Example 1, or 2926 kbps). The Appli-ances at the two spokes would set their bandwidth limits as in Example 1 (1463 kbps). Either hardboost or softboost can be used

Example 4: Suppose you have a three-site deployment, but instead of hub-and-spoke, each site connects to a network cloud with a 1.5 mbps link. This is no longer hub-and-spoke, but a mesh. Each site would have the same bandwidth limits (95% of a t1’s 1.54 mbps, or 1453 kbps). Hardboost works poorly in mesh deploy-ments, so softboost should be used.

Example 6: A link which has a guaranteed data rate of 2.0 mbps and a peak data rate of 5.0 mbps should receive a softboost bandwidth limit of 90-95% of 5.0 mbps, or 4500-4750 kbps, but a hardboost bandwidth limit of 90-95% of 2.0 mbps, or 1800-1900 kbps.

Example 7. Suppose a central office has a site-to-site VPN running at 45 mbps, and a certain branch office has a DSL link with a 6 mbps download speed and a 384 kbps upload speed. The central office Appliance should be set for 95% of 45 mbps, or 42750 kbps, while the branch-office Appliance should have its sending speed set for 95% of 384 kbps (365 kbps) and its receiving speed set for 95% of 6 mbps (5700 kbps). If the sum of all the branch-office Appliances does not exceed 45 mbps in either direction, hardboost can be used. Otherwise, softboost should be used.

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

Note: Set the bandwidth limits to match the speed of its local link, without regard to the speed at the other end of the WAN. This simplifies configuration and allows each unit to be installed with knowledge of the local links only. (The only exception is when there is an intermediate bottleneck that is slower than either endpoint link. This rare situation is dealt with by using the intermediate bottleneck speed on affected Appliance, instead of the local speed.)


4.4 Link Definitions and Traffic Shaping

4.3.4 Performance Tuning

For initial testing, a value of 95% of the link bandwidth is a good starting point.

One simple method of setting the bandwidth limit is:

1. Create enough accelerated bulk-transfer traffic to fill the link at the current 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 Appliance will do). Under Linux, the ping command issues one ping per second until stopped, by default. Under Windows, use the “ping -t hostname” command.

4. Adjust the bandwidth limit on the Appliances. As the bandwidth limit increases, you will reach a point where ping time start to go up but throughput remains flat or declines. The bandwidth should be set at a point where the ping time is near its minimum but the throughput is near the maximum. This is usually, but not always, between 90% and 100% of the nominal link speed.

With hardboost, setting the bandwidth limit even slightly higher than the link 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.

4.4 Link Definitions and Traffic ShapingRelease 6.0 introduces a new traffic-shaping engine that manages all the traffic on your WAN links, in both the incoming and outgoing directions. It replaces the previous system, “Repeater QoS,” which operated only on accelerated traffic and in the send-ing direction only.

The Repeater traffic shaper is an easy-to-use solution for link congestion. For a simple inline installation, configuring it requires just four parameters: LAN port, WAN port, link upload bandwidth, and link download bandwidth.

While highly configurable for sites with special needs, the default traffic-shaping set-tings are fine for most installations, providing these benefits:

• Quick response times for interactive traffic such as XenApp and XenDesktop.• Protection of latency- and jitter-sensitive VoIP traffic.

Note: When upgrading an Appliance from release 5.x to release 6.x, any Repeater QoS definitions will be converted to traffic-shaping policies auto-matically. For example, if a QoS category of “Queue A” was assigned 30% of the link in release 5.x, this will be converted into a traffic-shaping policy called “Queue A” with a priority of 30.

For the release 5.x default case, where 100% of the link was assigned to Queue A, no conversion is done, and the release 6.0 defaults are used instead.

4-8 November 14, 2012


• Eliminates “hitting the wall” during peak periods, providing usable performance even under extreme load.

• Allows bulk transfers to fill the link with whatever bandwidth is left over from interactive tasks.

• Extends the benefits of fair queuing to all traffic, when in previous releases it was available only to accelerated traffic.

4.4.1 Comparison with Release 5.x QoS

Release 6.0’s traffic shaping replaces the “Repeater QoS” function of release 5.x. Traffic shaping works on different principles than Repeater 5.x QoS and any settings cannot be migrated when you upgrade to release 6.0. Advantages of traffic shaping over the old system include:

• All link traffic is shaped, not just accelerated connections.• The old system of having five queues has been replaced with a one queue per ser-

vice class, with weighted fair queuing between queues.• Traffic is shaped independently for each link.• The improved application classifier allows more fine-grained control over traffic

shaping.

4.4.2 Traffic Shaping Basics

Like previous releases of Repeater, the traffic shaper is based on bandwidth-limited fair queuing, meaning that every service class gets its fair share of the link band-width. If the link is otherwise idle, any connection (in any service class) can use the entire link. Once multiple connections are competing for the link bandwidth, each gets its share of the link bandwidth in a controlled way.

Some highlights of the traffic shaper:

• All WAN traffic is subject to traffic shaping: accelerated connections, non-acceler-ated connections, and non-TCP traffic such as UDP flows, GRE streams, etc.

• The algorithm is weighted fair queuing, where the administrator assigns each ser-vice class a priority. A service class with a weighted priority of 100 will get twice the bandwidth as a service class with a weighted priority of 50. These weights have values from 1 to 256. See Figure 4-4.

• Connections within a service class get an equal share of its bandwidth.• Each connection its fair share of the link bandwidth, since priorities are applied to

the actual WAN data transferred, after compression. This means that, if you have two data steams with the same priority, one achieving 10:1 compression and the other achieving 2:1 compression, the end-users will see a 5:1 difference in user-visible throughput, though the WAN link usage of the two connections is identical. In practice, this disparity is desirable, since it is not application band-width but WAN bandwidth that is the scarce resource that needs to be managed.

• The weighted priority of a service class is based on the network protocol or appli-cation, which is detected by the classifier and used to select the traffic-shaping policy. (The classifier is also used for generating reports.)

• Traffic shaping applied to the WAN link in both the sending and receiving direc-tions, to both accelerated and non-accelerated traffic. This prevents congestion



and increased latency even when the other side of the link is not equipped with Branch Repeater. For example, it will prioritize and manage Internet downloads.

• In addition so shaping the traffic directly, the traffic shaper can affect it indirectly by setting the DSCP (differentiated services code point) field to inform down-stream routers about the type of traffic shaping each packet requires.

4.4.3 Configuring Traffic Shaping

Traffic shaping is controlled by four sets of parameters:

1. Link definitions, which tell the traffic shaper which WAN link the packet is using. In a site with multiple link, each link has its own bandwidth limits and is managed independently.

2. Application definitions, which tell the classifier which protocol or application the traffic belongs to.

3. Traffic-shaping policies, which tell the traffic shaper what weighted priority and other parameters to use.

Figure 4-4 Weighted fair queuing.

Figure 4-5 Control flow for acceleration and packet shaping.

TrafficShaper

Per-Connection Queues

Weight = 3

Weight = 2

Weight = 1

Output Data Stream

ClassifierPacket Data Service Class

PoliciesApplication

Acceleration Engine

Traffic Shaper

Application Definitions

Service Class Definitions

Traffic Shaping Policies

Acceleration Parameters

Traffic Shaping

Parameters

4-10 November 14, 2012


4. Service class rules, which map applications, IP addresses, etc. to acceleration and traffic-shaping policies.

In a typical installation, only the link definitions must be configured. The others can be left at their default values, and only changed if a problem arises and new defini-tions are needed. This is the recommended method of deploying the product. All parameters are described in Chapter 9.

4.4.4 Defining a Link

Traffic shaping relies on an accurate link definition, which tells the appliance which traffic is LAN traffic and which is WAN traffic.

The “Configuration: Links” page shows the currently defined links, either as a listing (collapsed) or in summary form (expanded). By default, the following links are defined but not configured:

1. apA.1, one of the two ports on the accelerated bridge.2. apA.2, the other port on the accelerated bridge.3. If the system has dual accelerated bridges, apB.1 and apB.2 also exist.4. “All Other Traffic,” which is not a true link, but is a catch-all for traffic that doesn’t

match any actual link definitions.

Figure 4-6 Link definition tab, collapsed (top) and expanded (bottom)



The two motherboard ports, Primary and Aux1, can also be defined as links, but doing so rarely serves any purpose, since they are used for management and as a back-channel for high-availability and group modes rather than WAN traffic. Allowing their traffic to fall under the “All Other Traffic” category is usually best.

4.4.4.1 What is a Link?

For our purposes, a “link” is a physical link, typically “a cable that leaves the build-ing.” It is an actual, physical link with its own bandwidth capacity:

• A VLAN is not a link.• A virtual link is not a link.• A VPN tunnel is not a link.• Other tunnel aren’t links, either.

4.4.4.2 Information Needed to Define a Link

The “Links” list is pre-populated with the apA.1 and apA.2 placeholder links, which are not fully defined by default and will require editing.

The traffic shaper needs the following information if a link is to be managed:

1. The speed of the link in both the send and receive directions. 2. Whether the “link” is a WAN link or a LAN network.3. A way of distinguishing link traffic from other traffic.

All of these are defined on the “Create/Edit Link” page, which is reached from the “Configuration: Links: Link Definition” tab.

Link Speed. When talking about link speed, we always mean the speed of the physi-cal WAN segment that terminates in the building with the Repeater. The speed of the other end of the link is not considered. This is shown in Figure 4-7, which shows a network of four appliances. Each appliance has its incoming and outgoing bandwidths set to 95% of the speed of its own, local WAN segment, without regard to the speed of the remote endpoints.

This is a general rule with Repeater configuration: configuration considers only local conditions, not the conditions at the remote sites.

The reason the bandwidth limits are set to 95% of the link speed instead of 100% is to allow for link overhead (few links can carry data at 100% of their published speeds) and to ensure that the appliance is slightly slower than the link, so that it becomes a slight bottleneck. Traffic shaping is not effective unless the traffic shaper is itself the bottleneck, so it must be set slightly slower than the actual link throughput.

Figure 4-7 Local bandwidth limits track local link speeds.

10 mbps

2 mbps

1 mbps

2 mbps

Configured for 10 mbps




4-12 November 14, 2012


Telling a WAN Link From a LAN Network. In each link definition, the user declares whether the definition is a WAN link or LAN network. This is used to categorize traffic, as described below.

Distinguishing Link Traffic From Other Traffic. The traffic shaper needs to know whether a packet is traveling on the WAN, and, if so, in what direction.

• For simple inline deployments, this is done by declaring that one port of the accel-erated bridge belongs to the WAN link and that the other port belongs to the LAN.

• In other deployment modes, this is done by examining IP addresses, MAC addresses, VLANs, or WCCP service groups. (Note that testing for WCCP service groups is not yet supported.)

• When a site has multiple WANs, then the link definitions must have rules that allow the appliance to tell traffic from different WANs apart.

4.4.4.3 Defining a Link

Ordered Lists of Links, Ordered Lists of Rules. The link definitions arranged in an ordered list, one entry per link, which are tested from top to bottom. The first match-ing rule is used. Within each link definition is an ordered list of rules, which is also tested from top to bottom. Each packet is compared to these rules, and if it matches one of them, then the packet is considered to be traveling over that link.

Within a rule, the fields are all ANDed together, so all specified values have to match. All fields default to “Any,” a wildcard entry that always matches. When a field consists of a list, such as a list of IP subnets, these are ORed together: that is, if any element matches, then the list as a whole is considered to be a match.

Figure 4-8 Link definition rules.



4.4.4.4 Example: Simple Inline Link

In this example, all traffic passing through the accelerated bridge is assumed to be WAN traffic. The link is an ADSL link with different send and receive speeds (6.0 mbps down, 1.0 mbps up). The WAN is connected to accelerated bridge port apA.1, and the LAN is connected accelerated bridge port apA.2. See Figure 4-9.

This link is very easy to specify on the “Edit Links” page. See Figure 4-10.

The tasks on the WAN link (apA.1) are:

1. Give the WAN a descriptive name, such as “WAN to Headquarters (apA.1).”2. Set the type to “WAN.”3. Set the incoming and outgoing bandwidth limits to 95% of the nominal link speed.4. Verify that a rule has been defined that specifies the WAN Ethernet adapter, which

in this example is apA.1 5. Press “Save.”

The tasks on the LAN link (apA.2) are similar:

1. Give it a descriptive name, such as “Local LAN (apA.2).”2. Set the type to “LAN.”3. Set the incoming and outgoing bandwidth limits to 95% of the nominal Ethernet

speed (95 mbps or 950 mbps).4. Verify that a rule exists that specifies the LAN Ethernet adapter, which in this

example is apA.2.5. Press “Save.”

Figure 4-9 Simple inline link example.

1.0 mbps send

6.0 mbps receive

Branch Repeater

ADSL

Incoming BW = 0.95 x 6.0 mbpsOutgoing BW = 0.95 x 1.0 mbps

apA.2 apA.1

172.16.0.0/24

Internet

4-14 November 14, 2012


Figure 4-10 WAN definition (top) and LAN definition (bottom).



4.4.4.5 Example: Inline Deployment with Dual Bridges

This example is similar to the previous one, but the site has a second link, a T1 link to the corporate WAN, in addition to the ADSL Internet link. The Repeater has two accel-erated bridges, one for each WAN link.

Configuration is almost as simple as the single-bridge case, with the following addi-tional steps:

1. Edit a second WAN link on apB, which in this case is apB.1. Set the type to “LAN.” The link bandwidth is set to 95% of the 1.5 mbps T1 speed, and the link is given a new name, such as “WAN to HQ.”

2. Add a rule specifying apB.2 to the “LAN” definition and delete the default link def-inition for “apB.2.” (Alternatively, you can edit the default link definition for apB.2 to specify it as a LAN link, as was done for apA.2.)

Figure 4-11 Inline, dual-bridge link example.

RepeaterapA.2 apA.1

172.16.0.0/24

Internet

apB.2 apB.1WAN10.0.0.0/8

6/1 mbps

1.5/1.5 mbps

4-16 November 14, 2012


4.4.4.6 Example: Using IP Addresses in Link Definitions

You can use IP subnets instead of bridge ports to distinguish LAN traffic from WAN traffic. This is essential in “one-armed” (non-inline) deployments, where only a single bridge port is used. IP subnets are sometimes useful for inline deployments as well.

The traffic classifier uses the “Src IP” and “Dst IP” fields in a specialized (and some-times confusing) way:

• The “Src IP” field is only examined on packets entering the appliance. • The “Dst IP” is only examined on packets exiting the appliance.

This convention allows the direction of packet travel to be implicitly considered as part of the definition.

In the example in Figure 4-12, the LAN and WAN links can be defined without specify-ing the Ethernet ports at all, using the LAN subnet instead:

• Create a rule for the LAN link definition and specify the LAN subnet in the “SRC IP” field.

• Create a rule for the WAN link definition and specify the LAN subnet (not the WAN subnet) in the “DST IP” field.

Figure 4-12 Simple inline LAN definition using IP-based rules.

Branch Repeater

apA.2 apA.1

172.16.0.0/24Internet


4.5 Service Class Policies

4.4.4.7 Example: WCCP and Virtual Inline Modes

Configuration of this WCCP link using IP addresses is the same as the previous exam-ple, because the IP subnets are identical.

When WCCP-GRE is used, the GRE headers are ignored and the headers of the encap-sulated data packet are used. This means that the same link definition works for WCCP-L2, WCCP-GRE, and virtual inline.

WCCP and virtual inline modes require configuration of your router. WCCP also requires configuration on the “Configuration: Advanced Deployments” page.

4.5 Service Class PoliciesService classes determine traffic-shaping policies and acceleration policies. In previ-ous releases, service-class policies mapped protocols and applications solely to accel-eration decisions, and acceleration decisions applied only to accelerated connections.

Release 6.0 expands service classes to select a traffic-shaping policy in addition to an acceleration policy:

• Each service class represents a bandwidth pool, entitled to a fraction of the link speed equal to (my_priority/sum_of_all_priorities).

• Traffic-shaping policies apply equally to both accelerated and non-accelerated traf-fic. This means that an accelerated XenApp connection and a non-accelerated one both receive traffic shaping, so both can receive an elevated priority compared to bulk traffic.

Figure 4-13 WCCP or virtual inline deployment using IP-based rules.

B ranch R epea te r

apA .2

1 72 .16 .0 .0 /2 4

In te rne t

LA N

4-18 November 14, 2012


• Traffic-shaping policies control non-TCP traffic as well as TCP traffic, meaning that sensitive real-time traffic like VoIP (which uses the UDP protocol), can be expe-dited.

• Service classes can now be based on a greatly expanded list of parameters, including:• applications, • protocols, • URLs, • Citrix published applications, • IP or VLAN addresses, • DSCP bits, • and SSL profiles.

• The traffic policy for a service class can be specified on a per-link basis if desired.

The default service-class policies are recommended as a starting point. Modify them if they prove inadequate for your link.

As in previous releases, the service classes are an ordered list, and the first matching policy is used. See Figure 4-14.

Figure 4-14 Default service-class list.


4.6 Traffic Shaping Policies

4.5.0.1 Differences Between Acceleration Policies and Traffic Shaping Policies

• Acceleration policies are applied based on the contents of the initial SYN packet of a TCP connection. Once applied, the acceleration policy lasts for the duration of the connection.

• This means that, to be effective, an acceleration policy has to be based on a test (or filter rule) that applies to the initial SYN packet. This means that virtually all service classes intended for accelerated traffic are defined in terms of well-known port numbers, such as port 80 for HTTP. Tests based on IP addresses also work.

• The traffic-shaping policy is not a permanent decision, since it can be based on deep packet inspection, which may not return a definitive answer on the first packet of the data flow. So the traffic-shaping category may change from the ini-tial decision, based on the first packet, to the later, more definitive one.• For example, an http connection to “http://www.google.com” opens with

connection is a SYN packet that contains a header but no payload. The header will have an IP destination port of 80, and this will match the “HTTP: Internet” service class definition. The accelerator will base its acceleration decision (in this case, “No acceleration”) on this service class.

• The traffic shaper will use the traffic-shaping policy from the “HTTP: Internet” service-class policy temporarily. However, when the first payload packet is seen by the classifier, it will contain the string “GET http://www.google.com,” and this URL will match the “Google” application definition. If there is a service class definition that uses the “Google” application, the traffic shaper will start using that service class.

• Regardless of the service class policy, the reporting will track the usage of the “Google” application.

• Remember: all traffic has an application and a service class, and all service classes have a traffic shaping policy. Only TCP connections have an acceleration policy.

4.5.0.2 Using Service Class Policies

The more specific policies must be above more general ones on the service-class page. For example:

• Service classes based on URLs must be above the HTTP service classes in the ser-vice-class list.

• Service classes based on ICA (XenApp/XenDesktop) published applications must be above the ICA service class.

This is because the first matching rule is used, and since all URL-based rules will match the HTTP service class, putting the HTTP service class above them will mean that the URL-based rules or published application-based rules would never be used.

4.6 Traffic Shaping PoliciesThe service class policy selects a traffic-shaping policy from the list, and the traf-fic-shaping policy sets the following parameters for the traffic:

• Weighted Priority (1-256). Higher weighted priorities mean more bandwidth. A connection with a weighted priority of 256 are entitled to 256x the bandwidth of a connection with a weighted priority of 1. (In practice, these bandwidth ratios will

4-20 November 14, 2012


only be seen in bulk-transfer traffic where the traffic shaper is the dominant bot-tleneck. Protocols that are RTT-limited, interactive, or contain their own bandwidth managers — Citrix XenApp falls into all three categories — will show different ratios, because other factors besides the traffic shaper are also affecting the traf-fic.)

• ICA priorities. Usually used only on the “Citrix” policy. This declares a mapping between the four XenApp/XenDesktop priority bits and traffic shaper weighted pri-orities. See Section 4.6.1.

• Optimize for Voice. Handle with care. This option gives the traffic a weighted prior-ity of infinity, meaning that it will monopolize the link if there is enough traffic to do so. • Use only for VoIP data traffic (not VoIP control traffic)• Always use a maximum bandwidth policy with this feature, such as “75% of

link speed.” • Never use this feature for TCP traffic.

• Set Diffserv/TOS. Sets the DSCP bits on output packets to the selected value. Used to control downstream routers. For ICA (XenApp/XenDesktop) traffic, each of the four ICA priority values can be tagged with a different DSCP value. This is par-ticularly valuable with the new “Multistream ICA” feature, where the XenApp or XenDesktop client uses different connections for different priority levels.

• Limit Bandwidth. Prevents the traffic using this policy from exceeding the specified bandwidth, stated either as a percentage of link speed (preferred) or as an abso-lute value. Percentages are recommended so that the same definitions can apply to links of different speeds. This feature will leave bandwidth on the table. For example, if you have a policy set to “50% of link speed,” it will not allow the affected traffic to use more than 50% of the link, even if the link is otherwise idle. Throttling traffic in this way is inconsistent with maximum performance, so this feature is rarely used except with VoIP traffic using the “Maximize for Voice” set-ting.


4.6 Traffic Shaping Policies

The default policies span a broad range of priorities, with each policy separated by its neighbors by a factor of two in priority. Note that, with the exception of the Default “Traffic Shaping policy,” the default policies cannot be edited or deleted, to ensure that they have the same meaning on all appliances. To make changes, create a new traffic-shaping policy with the new parameters and change the appropriate ser-vice-class policies to refer to the new traffic-shaping policy. See Figure 4-15.

4.6.1 XenApp/XenDesktop Policies

The two-bit ICA priority field in the Citrix ICA and CGP protocols used by XenApp and XenDesktop can be used to assign different traffic-shaping priorities to different XenApp/XenDesktop traffic. (The controls for this are on the “Configuration: Traffic Shaping Policies: Create Policy” page, but are hidden by default. Press the “Show All Advanced Options” button to show these options. (See Section 9.4.13 for more infor-mation on this page.)

These options support both single-connection and multi-connection ICA/CGP streams. In single-connection streams (the traditional ICA/CGP implementation) all four priori-ties are multiplexed in a single connection. The newer multi-connection option uses different connections for different priority levels.

ICA priorities can be mapped to DSCP values in the IP header, informing the down-stream routers about the kind of handling each packet requires.

Note that, if you change the state of the “Set ICA Priorities” checkbox for a traf-fic-shaping policy, existing connections under that policy will be reclassified as “Other TCP traffic” for the rest of their lifetimes. They cannot be transferred from one ICA traffic-shaping state to another.

Figure 4-15 Creating a new traffic-shaping policy

4-22 November 14, 2012


Figure 4-16 Creating an ICA traffic-shaping policy that specifies per-priority DSCP values.


4.7 Application Classifiers

4.7 Application ClassifiersThe classifier uses application definitions to divide the traffic into protocols and appli-cations. This is used to create reports and by the service-class mechanism. Many applications are already defined, and you can define more as needed. The following top-level classifications are available:

• Ethertype List• Citrix Published Application Name• IP Protocol Number List• TCP Port List• UDP Port List• Web Address (URL)

See the “Create Application” page in Figure 4-17.

The application classifier uses the official protocol and port specifications from the IANA (Internet Assigned Numbers Authority), http://www.iana.org. Sometimes appli-cations other than the official ones will use a port. The classifier generally can’t tell when this happens. When your network uses such applications, this problem can gen-erally be resolved going to the application classifier and renaming the application from its official name to its actual name.

Applications must not have overlapping definitions. For example, if you had one appli-cation that uses TCP ports 3120 and 3128, and another application that uses port 3120 only, you cannot specify port 3120 in both definitions.

Figure 4-17 Defining a new application

4-24 November 14, 2012


4.8 Ethernet PortsA 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.

Note: Acceleration is supported only on Accelerated Pairs. The Primary and Aux1 ports are for UI and group-mode backchannel access.

Figure 4-18 Ethernet ports.


4.8 Ethernet Ports

The ports are named as follows:

4.8.1 Bridged Ports

Bridges can act in inline mode, where they act as a transparent bridge, as if they were an Ethernet switch. Packets flow in one port and out the other. Bridges can also act in single-ended mode, where packets flow in one port and back out the same port.

Bypass card (optional). If the Appliance loses power or fails in some other way, an internal relay closes and the two bridged ports are connected electrically. This main-tains network continuity but makes the bridge ports inaccessible.

4.8.2 Motherboard Ports

While the Ethernet ports on a bypass card are inaccessible when the bypass relay is closed, the motherboard ports remain active. You can sometimes access a failed Appliance from the motherboard ports when the bridged ports are inaccessible.

4.8.3 Port Parameters

Each bridge and motherboard port can be:

• Enabled or disabled• Assigned an IP address and netmask• Assigned a default gateway• Assigned to a VLAN• Set to 1000 mbps, 100 mbps, or 10 mbps at full or half duplex

All of these parameters except the speed/duplex setting are set on the “Configure Settings: IP Address” page. The speed/duplex settings are set on the “Configure Set-tings: Interface” page.

Notes about parameters:

• Disabled ports will not respond to any traffic. • The browser-based UI can be enabled or disabled independently on all ports.• To secure the UI on ports with IP addresses, select HTTPS rather than HTTP on the

“UI” page. • Inline mode works even if a bridge has no IP address; all other modes require that

an IP address be assigned to the port.• Traffic is not routed between interfaces. For example, a connection on bridge apA

will not cross over to the Primary or Aux1 ports, but will remain on bridge apA. The entire issue of routing is left to your routers.

Figure 4-19 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)

4-26 November 14, 2012


4.8.4 The Primary Port

If the Primary port is enabled and has an IP address assigned to it, the Appliance takes its “identity” from it. That is, UI displays on other units will report this IP address. When the Primary port is not enabled, the IP address of Accelerated Pair A is used.

The Primary port is used for:

• Administration via the Web-based UI.• A backchannel for group mode (See Section 4.15).• A backchannel for high-availability mode (See Section 5.5).

4.8.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.8.6 Using Multiple Bridges

When two or more accelerated bridges are present, they can be used to accelerate two different links. These links can either be fully independent or they can be redun-dant links, connecting to the same site. Redundant links can be either load-balanced or main-link/failover-link pairs.

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

Figure 4-20 Using dual bridges

LANLAN

Two Accelerated Bridges

WAN to Site X

WAN to Site Y

LANLAN

Two Accelerated Bridges

Load-BalancedWAN Links

LANLAN

WANWAN

HA Pair


4.9 Autodiscovery and Autoconfiguration

made by the router, and automatically tracks the load-balancing or main-link/failover-link algorithm in real time. For non-load-balanced links, this same algorithm also ensures that packets will always use the correct bridge.

WCCP and Virtual Inline Modes. Multiple bridges are supported with both WCCP and virtual inline modes (not shown). Usage is the same as the single-bridge case, except that WCCP has the additional limitation that all traffic for a given WCCP service group must arrive on the same bridge.

Only One Bandwidth Limit. A system with two accelerated pairs still has only one bandwidth limit. If the pairs are attached to different WAN links, there is no way of specifying a per-link bandwidth limit. In the deployments shown above, this is not an issue; both accelerated pairs service the same link. In cases where this is not the case, softboost mode must be used, since hardboost mode cannot tolerate any 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 5.5 for more about high availability mode.)

4.9 Autodiscovery and AutoconfigurationAcceleration 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-21.

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.9.1 Firewall Considerations

The use of TCP options puts accelerated traffic at risk from firewalls that are overly enthusiastic about denying service to connections using uncommon TCP options. The most usual firewall action is to strip off the “unknown” options and then forward the packet. This prevents acceleration but does not impair connectivity.

A small fraction of Web sites deny service to connections with unknown options. That is, the Appliance-tagged SYN packets are dropped. The Appliance notices when 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-28 November 14, 2012


Such firewalls need to be reconfigured to allow TCP options in the range of 24-31 (decimal). Examples for two common Cisco firewalls are given in Section 3.5.4.1. The basic procedure will be similar for other firewalls.

4.10 Forwarding ModesAn 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.

Figure 4-21 How autodiscovery works.

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.

Appliance Appliance Server

23

4

5

1

7

Client

6

SYN Tagged SYN SYN

SYN-ACKTagged

SYN-ACK

SYN-ACK


4.10 Forwarding Modes

This packet forwarding can be done in different ways, such as inline mode, virtual inline mode, and WCCP mode. While these methods are called “modes,” all are active simultaneously. (However, they have different cabling and deployment requirements that prevents inline mode from being used simultaneously with the others.) The Appli-ance can tell the different modes apart by the destination IP address and destination Ethernet MAC, as shown in Figure 4-22. For example, in inline mode, the Appliance is acting as a bridge, and the packets contain neither the Appliance’s IP address nor the Appliance’s Etherenet MAC address.

The forwarding modes are:

1. Inline mode, where the Appliance transparently accelerates traffic flowing between its two Ethernet ports (see Figure 4-23). In this mode, the Appliance appears (to the rest of the network) to be an Ethernet bridge. This mode is explained in Section 4.11. Inline mode is the recommended mode, as it requires the least configuration.

2. WCCP mode, which uses the WCCP v. 2.0 protocol to communicate with the router. It is easy to configure on most routers. With older routers and high-speed links, it may not be as fast as virtual inine.

3. Virtual inline mode, where a router sends WAN traffic to the Appliance and the Appliance returns it to the router. In this mode, the Appliance appears to be a router, but in fact it has no routing tables and sends its output packets to the real router. Virtual inline mode is recommended when inline mode and high-speed WCCP operation are not practical.

4. Proxy mode, where Appliance performs address translation according to tables set up by the administrator. In this mode, the Appliance appears to be a host. Proxy mode is not recommended for new installations; it is a legacy mode. Proxy mode does not support CIFS acceleration.

5. Redirector mode, where a Repeater Plug-in sends traffic to an 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.

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

Figure 4-22 How Ethernet and IP addresses determine the forwarding mode.

Destination IP Addr. Dest. Ethernet Addr. Mode

Not Appliance Not Appliance Inline or Pass-through

Not Appliance Appliance Virtual Inline or L2 WCCP

Appliance Appliance Direct (UI access, etc.)

Appliance (VIP) ApplianceProxy Mode or

High-Availability VIP

Appliance (WCCP GRE Packet)

Appliance WCCP GRE Mode

Appliance (Redirector IP)

ApplianceRedirector Mode (Repeater

Plug-in)

All modes can be active simultaneously. The mode used for a given packet is determined by the Ethernet and IP headers.

4-30 November 14, 2012


bandwidth limit, which means that they are not throttled. Acceleration has the unique characteristic of achieving acceleration without throttling. The unit can thus be put inline with LAN segments if desired, and LAN-to-LAN traffic will not be affected. Only traffic passing through two Appliances is

Appliances support all three configurations simultaneously.

4.11 Inline Mode

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.

Figure 4-23 Inline mode, used to accelerated all the traffic on a WAN.

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.

NETWORK A NETWORK B

Appliance

TCP/IP traffic passing through two appliances is accelerated

Appliance

WAN


4.11 Inline Mode

Link-Down Propagation. If carrier is lost on one of the bridge ports, the carrier will be dropped on the other bridge port to ensure that the carrier-down condition is prop-agated 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.

Link-down propagation has two operating modes:

• If the Primary port is not enabled, the link-down state on one bridge port is mir-rored briefly on the other bridge port, and then the port is re-enabled. This allows the Appliance to be reached via the still-connected port for management, HA heartbeat, and other tasks.

• If the Primary port is enabled, it is assumed that it is used for management, HA heartbeat, and other tasks, and that means that the link-down condition on one bridge port can be mirrored on the other port until carrier is restored or the unit is rebooted. This is true even if the Primary port is enabled but not connected, so the Primary port should be left disabled (the default) if not in use.

4.11.1 Accelerating an Entire WAN

Figure 4-23 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.11.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-24.

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.

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-32 November 14, 2012


4.12 Redirector ModeRedirector mode is a proxying mode used by the Repeater Plug-in system. Each client acquires a list of Appliances and the subnets they accelerate, and forwards matching traffic to the indicated Appliances.

4.12.1 How it Works

Accelerated connections are passed from the Repeater Plug-in to the Appliance, which in turn passes them to the server. In other words, the Appliance acts as a proxy. Acceleration information between the Repeater Plug-in and Appliance uses TCP option headers, and doesn’t require a control connection.

Figure 4-25 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.

Figure 4-24 Inline mode accelerating selected systems only.

NETWORK A

Appliance

WAN

Accelerated Non-Accelerated


4.12 Redirector Mode

Because of the explicit addressing, redirector mode never suffers from asymmetric routing, which makes it simple to deploy.

Figure 4-25 Repeater packet flow, showing the address changes used by Redirector mode.

Repeater Plug-in10.0.0.50

Repeater Appliance10.200.0.201

Server10.200.0.10

1 23

4

5

6

The connection is now fully open. The client and server send packets back and forth via the appliance.

While the addresses are altered in Redirector mode, the destination port numbers are not (though the ephemeral port number may be). The data is not encapsulated. Redirector mode is a proxy, not a tunnel.

There is no 1:1 relationship between packets (though in the end, the data received is always identical to the data sent). Compression may reduce many input packets into a single output packet. CIFS acceleration will perform speculative read-ahead and write-behind operations. Also, if packets are dropped between appliance and the Repeater Plug-in, the retransmission is handled by the appliance, not the server, using advanced recovery algorithms.

6

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

The Repeater Plug-in looks up the dst address and decides to redirect the connection to the appliance at 10.200.0.201.

Src: 10.0.0.50, Dst: 10.200.0.201

(10.200.0.10 is preserved in a TCP option field. Options 24-31 are used for various parameters.)

The appliance accepts the connection and forwards the packet to the server (using the dst address from the TCP options field), and giving itself as the src.

Src: 10.200.0.201, Dst: 10.200.0.10

The server accepts the connection and responds with a TCP SYN-ACK packet.

Src: 10.200.0.10, Dst: 10.200.0.201

The appliance rewrites the addresses and forwards the packet to the Plug-in (placing the server address in an option field).

Src: 10.200.0.201, Dst: 10.0.0.50

1

2

3

4

5

4-34 November 14, 2012


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

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

Figure 4-26 Basic cabling, redirector mode

Figure 4-27 Basic cabling, WCCP mode

Appliance in Redirector Mode

Switch

ToLAN

ToWAN

Router

Appliance in WCCP Mode

Switch

ToLAN

ToWAN

Router


4.13 WCCP Mode

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 should be deployed either on a dedicated router port (or WCCP-capable switch port) or isolated from other traffic through a VLAN. Do not mix inline and WCCP modes.

4.13.1 How it Works

WCCP 2.0 has two transport mechanisms: GRE encapsulation and L2 forwarding. Starting with release 4.2.17, the Appliance supports both methods, and chooses the fastest available method by default. Earlier releases supported GRE encapsulation only.

GRE encapsulation (WCCP-GRE), as the name implies, creates a GRE tunnel between the router and Appliance. The Appliance decapsulates the traffic from the tunnel, operates upon it, and sends the resulting packets back through the tunnel. The Appli-ance behaves as if the traffic were inline.

L2 forwarding (WCCP-L2) operates at the Ethernet level. The router sends packets to the Appliance without altering their IP headers, and the Appliance send packets back to the router. L2 forwarding works only if the Appliance is on the same Ethernet 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 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.

In general, only a single Appliance is allowed in a WCCP service group. This is enforced by the Appliance. (There are exceptions with Repeater SDX, which are beyond the scope of this document. Please contact your Citrix representative if WCCP-based load-balancing is required in your application.) When a new Appliance attempts to contact the router, it will discover that the other Appliance is handling the service group and cause an Alert. It will periodically check whether the service group is still active with the other Appliance, and will handle the service group when the other Appliance becomes inactive.

Multiple service groups can be used with WCCP. For example, the traffic from one WAN link can be sent to the Appliance under service group 51, and the traffic from another link can be sent under service group 52. The Appliance is indifferent to which service group is used. It will track service-group usage as follows: if a packet arrives on one service group, output packets for the same connection will be sent on the

4-36 November 14, 2012


same service group. If packets arrive for the same connection on multiple service groups, output packets will track the most recently seen service group for that con-nection.

The Appliance also supports multiple routers. The Appliance is indifferent to whether all the routers use the same service group or whether different routers use different service groups.

4.13.2 Performance

WCCP-L2 is a high-performance mode and can be as fast as inline mode.

WCCP-GRE has somewhat lower performance than inline mode. The encapsulation/decapsulation and checksum operations have some overhead, especially on the router.

Usually, the router is the limiting factor in WCCP-GRE performance. With modern routers, performance in excess of 155 mbps is readily achieved.

4.13.3 Limitations• Do not mix inline and WCCP traffic on the same Appliance.• On Appliances with more than one accelerated pair, all the traffic for a given WCCP

service group must arrive on the same accelerated pair.

4.13.4 Best Practices• For sites with a single WAN router, use WCCP whenever inline mode is not 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. Do not mix inline and WCCP mode in the same Appliance.

4.13.5 Router Support for WCCP

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

4.13.6 Redirection Strategies

There are two basic approaches to redirecting traffic from the router to the appliance:

1. On the WAN port only, add a “wccp redirect in” statement and a “wccp redirect out” statement.

2. On every port on the router, add a “wccp redirect in” statement (except for ports that are isolated from the WAN).

The first method redirects only WAN traffic to the appliance, while the second method redirects all router traffic to the appliance, whether it is WAN-related or not. (If a port is known to never carry WAN-bound traffic, such as an isolated internal subnet, it doesn’t need a redirect statement.) On a router with several LAN ports and a lot of LAN-to-LAN traffic, sending all traffic to the appliance can overload its LAN segment and burden the appliance with a substantial, unnecessary load. If GRE is used, the unnecessary traffic can load down the router as well.


4.13 WCCP Mode

Some routers and WCCP-capable switches do not support “wccp redirect out,” so the second method must be used. In this case, it is best to avoid routing large numbers of ports through the appliance, perhaps using two routers, one for WAN routing and one for LAN-to-LAN routing.

In general, method 1 is preferable in practice, because it isolates the appliance-cen-tric configuration to the WAN ports and avoids sending traffic to the appliance unnec-essarily. On some routers, the “redirect in” path is faster and puts less of a load on the router’s CPU than the “redirect out” path. This can be determined by direct exper-iment on your router: try both redirection methods under full network load to see which gives the highest transfer rates.

4.13.7 Traffic Shaping and WCCP

Each service group can be either TCP or UDP, but not both. For the traffic shaper to be effective, both kinds of WAN traffic need to pass through the Appliance. This means that:

• Acceleration requires one service group, for TCP traffic.• Traffic shaping requires two service groups, one for TCP traffic and one for UDP

traffic. The difference between the two is configured in the Appliance, and the router accepts this configuration.

4.13.8 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 termip wccp version 2! We will configure the Appliance to use group 51 for TCP and 52 for UDP.ip wccp 51ip wccp 52

! Repeat the following three lines for each WAN interface! you wish to accelerate:

interface your_wan_interface

ip wccp 51 redirect outip wccp 51 redirect in

ip wccp 52 redirect outip wccp 52 redirect in

! If the Appliance is inline with one of the router interfaces! (NOT SUPPORTED), add the following line for that interface ! to prevent loops:ip wccp redirect exclude in^Z

4-38 November 14, 2012


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 2ip 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 outip wccp 51 redirect in! ! The following line is needed only on the interface facing the other router,! if there is another router participating in this service group.ip wccp 51 group-listen

!If the Appliance is inline with one of the router interfaces, !(which is supported but not recommended), add!the following line for that interface to prevent loops:ip wccp redirect exclude in

^Z

4.13.9 Appliance Configuration

Configuration takes place on the “Configure Settings: WCCP” page (See Section 9.2.2.16 for details on this UI page):

1. Press the “New WCCP Service Group” button.2. In the “New Service Group” box, select between “Unicast” and “Multicast,” then

add a unicast or multicast IP address in the box below.3. The default service group number (51) and protocol (TCP). (WCCP priority (0) and

Time-to-Live (1) generally do not need to be changed, but if they do, put new val-ues in the boxes provided).

4. Press “Create.”5. Repeat with another service group for UDP traffic. For example, service group 52

and protocol UDP. Press “Create.”6. Press the “Enable” button at the top of the page.7. Go to the “Monitoring: WCCP Status” page. The “Status” field should change to

“Connected” within 60 seconds. (See Section 9.3.11 for more information about this UI page.)

8. Send traffic over the link and verify from the Usage Graph or Accelerated Connec-tions pages that connections are being accelerated.


4.13 WCCP Mode

4.13.10 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-22. Packet Return Method (multicast only): GRE or Level-23. 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.”

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 mode will be negotiated with the router. 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.

4-40 November 14, 2012


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 or UDP packets to the appliance. Routers can modify this with access lists or by selecting which interfaces to redirect to the ser-vice 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. By default, because there is only a single appliance in the service group, a one-bit mask is used, to conserve router resources. Release 6.0 used a larger mask.

4.13.11 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 9.3.11.

Log Entries. The “Monitoring: Logging” page will have an entry when WCCP mode is established or lost.

Figure 4-28 Log entry when WCCP mode is enabled.


4.14 Virtual Inline Mode

Router Status. On the router, the “show ip wccp” command will also show the status of the WCCP link:

Router>enablePassword:Router#show ip wccpGlobal 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


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.

Note that the fail-to-wire feature is effective only for inline mode. In virtual inline mode, maintaining packet flow in the face of Appliance failure can be achieved with high-availability pairs.

4.14.1 How Virtual Inline Mode Works

In virtual inline mode, the Appliance receives packets from a router, operates on them, and then forwards output packets in one of two ways:

1. By sending them to the default gateway.2. By sending them to the Ethernet address they came from.

Where a single router is involved, the two methods are equivalent. Method 2 allows multiple routers to share an Appliance, with each router receiving its own packets back.

Note: Virtual inline mode is inferior to inline mode and WCCP, and should only be used when both of these two modes are impractical.

Note: Do not mix inline and virtual inline modes. Virtual inline and WCCP modes may be mixed freely.

4-42 November 14, 2012


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.14.1.1 Example

Figure 4-29 shows a simple network where all traffic destined for the remote site is sent to the gateway router.

The router redirects WAN traffic to the Appliance so that it can be accelerated. This is accomplished with policy-based routing (PBR) rules.

4.14.2 Configuration

The following are some configuration details for the example network:

• Endpoint systems have their gateways set to the local router (this is already true).• Appliances have their default gateway set to the local router (on the

“Configuration: Network Adapters” page). • Virtual Inline settings are on the “Configuration: Tuning” menu.• Routers are configured to redirect both incoming and outgoing WAN traffic to the

Appliance.

4.14.2.1 How the Appliance Forwards Packets

There are two packet-forwarding options on the Virtual Inline section:

1. Send to Gateway (used with a single WAN router). Virtual inline output packets are forwarded to the default gateway for delivery. (This is true even of packets destined for hosts on the local subnet.) This mode is usually less desirable than the “Return to Ethernet Sender” option, since it add an easily forgotten ele-ment of complexity to your routing structure.

Figure 4-29 Virtual inline example. Appliances are at 192.168.1.200 and 192.168.2.200.

Local Site Remote Site

Router Router

Appliance192.168.1.200

Local Network10.10.10.0/24

Remote Network20.20.20.0/24


FE 0/0 FE 0/0FE 0/1

FE 1/0FE 1/0

FE 0/1



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

• Traffic shaping is not effective unless all WAN traffic through the Appliance.

4.14.4 Health Monitoring

If the Appliance fails, data should not be routed to it. By default, Cisco policy-based routing does no health monitoring, but this can be enabled with the “verify-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: 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.

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.

4-44 November 14, 2012


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 connectedtrack 123 rtr 1 reachability!rtr 1

type echo protocol IpIcmpecho 192.168.1.200schedule 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.14.5 Routing Examples

The following configuration performs the routing into the Appliance. It conforms to the Cisco IOS CLI, and may not be applicable to routers from other vendors.

Local Site, Health-Checking Enabled:

!! For health-checking to work, 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!interface FastEthernet0/1 ip address 172.68.1.5 255.255.255.0 ip policy route-map wan_side_map!interface FastEthernet1/0 ip address 192.168.1.5 255.255.255.0!ip classlessip 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.255ip 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

4-46 November 14, 2012


Remote Side (No Health Checking):

! This example does not use health-checking.! Remember, health-checking is always recommended,! so this is a configuration of last resort.! !ip cef!interface FastEthernet0/0 ip address 20.20.20.5 255.255.255.0 ip policy route-map client_side_map!interface FastEthernet0/1 ip address 171.68.2.5 255.255.255.0 ip policy route-map wan_side_map!interface FastEthernet1/0 ip address 192.168.2.5 255.255.255.0!ip classlessip route 0.0.0.0 0.0.0.0 171.68.2.1!ip access-list extended client_side permit ip 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255ip access-list extended wan_side permit ip 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255!route-map wan_side_map permit 20 match ip address wan_sideset ip next-hop 192.168.2.200

!route-map client_side_map permit 10 match ip address client_sideset 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):

!ip access-list extended client_side permit tcp 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255ip access-list extended wan_side permit tcp 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255!



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.14.6 Virtual Inline Mode For Multi-WAN Environments

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

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.14.7 Virtual Inline Mode and High Availability

Virtual Inline and High Availability can be used together. A simple high-availability deployment is shown in Figure 4-31. 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 5.5 for a complete description of High Availability mode.

Figure 4-30 Asymmetric routing example, with redundant links at the local site.


Routers

Router

192.168.2.200192.168.1.200

Local Network:10.10.10.0/24

Remote Network: 20.20.20.0/24

FE 0/0

FE 0/1

FE 1/0

FE 0/0

FE 0/1

FE 0/1 FE 0/0FE 1/0

FE 1/0

4-48 November 14, 2012


4.15 Group ModeGroup 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.

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-31 High-availability example.

Figure 4-32 Group mode over redundant links


Routers

Router


VIP: 192.168.1.200



Local Network:10.10.10.0/24

Remote Network: 20.20.20.0/24

FE 0/0

FE 0/1

FE 1/0

FE 0/0

FE 0/1

FE 0/1 FE 0/0FE 1/0

FE 1/0

WAN

WAN

Group Mode Group Mode


4.15 Group Mode

Group mode uses a heartbeat mechanism to verify that other members of the group are active. Packets are only forwarded to active group members.

4.15.1 When to Use Group Mode1. You have multiple WAN links, and2. There is a chance of asymmetric routing (a packet on a given connection might

travel over either link), and3. Group mode seems simpler and more practical than the alternatives that use a

single appliance (WCCP, virtual inline, multiple bridges).

4.15.1.1 Alternatives to Group Mode

Group mode is one of several alternative approaches to dealing with multiple links, any of which may carry traffic for a given connection. The other approaches are:

• WCCP mode, where traffic from two or more links are sent to the same Appliance by WAN routers, via the WCCP protocol.

Figure 4-33 Group mode over non-redundant links with possible asymmetric routing

Figure 4-34 Group mode to connect multiple nearby sites.

WAN

WAN

WAN

Group Mode

WAN

Group Mode

Campus A

Campus B

High-SpeedMAN Link

Rest of Network

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.

4-50 November 14, 2012


• Virtual inline mode, where your routers send traffic from two or more links through the same Appliance (or high-availability pair).

• Multiple bridges, where each link passes through a different accelerated bridge in the same appliance.

• LAN-level aggregation, where an Appliance (or high-availability pair) is placed closer to the LAN, before the point where WAN traffic has been split into two or more paths.

4.15.2 How Group Mode Works

In group mode, the Appliances that are part of the group each take ownership for a portion of the 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-35.

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.

Figure 4-35 Sending-side traffic flow in group mode. Traffic is returned to its original path for delivery.

Legend1. Traffic arrives at non-owning unit2. Traffic is forwared to owning unit3. Owning unit accelerates traffic and returns it4. Accelerated traffic is delivered

Group Mode (Sending Side) Does Not Disturb Original Routing Path

WAN

WAN

4

2

1

3


4.15 Group Mode

4.15.3 Owner Selection

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.

Figure 4-36 Receiving-side traffic flow in group mode. Traffic is returned to its original path for delivery.

Figure 4-37 Using IP-based selection in a primary/backup link topology

WAN

WAN

1

2

4

Legend1. Traffic arrives at non-owning unit.2. Traffic is forwared to owning unit3. Owning unit accelerates traffic and returns it4. Accelerated traffic is delivered

3

Group Mode (Receiving Side) Does Not Disturb Original Routing Path

Set to handle alltraffic (sendingnone to partner)

WAN

WAN

PrimaryLink

BackupLink

Set to sendall traffic to

partner

Appliance selection matchesroute selection

4-52 November 14, 2012


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.15.3.1 IP-Based Ownership Rules

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

4.15.3.2 Failure Modes

There are two user-selectable failure modes in Group Mode. These control how the group members interact with each other after one of them fails, and also determines whether their bypass cards fail in the open state (blocking traffic through the Appli-ance) or the closed state (allowing traffic to pass through.

Continue to accelerate. If a group member fails, its bypass card is opened and no traffic passes through the failed Appliance. This will presumably trigger a fail-over if redundant links are used. Otherwise, the link is simply inaccessible. The other 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.15.4 Setting the Bandwidth Limit

In group mode, the WAN bandwidth of a connection comes out of the bandwidth limit of the unit that “owns” it, even when it is sent over a different link. This raises the possibility that a link may have more traffic sent over it than its actual capacity, espe-cially if the links are of different sizes. This can be dealt with in two ways:


4.15 Group Mode

1. By using softboost mode, which is well-behaved in the face of uncertain bandwidth conditions. Set the bandwidth limit as usual (to 90%-95% of the speed of the link the unit is inline with).

2. By using hardboost, but setting the bandwidth limit far enough below the link speed that worst-case behavior does not overrun the link. This sometimes occurs by default on very fast links that the Appliances cannot fill in any event (such as a pair of 155 mbps Appliances on a 1 gbps link).

4.15.5 Enabling Group Mode

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 SSL common name 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 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.

Figure 4-38 Group mode page.

4-54 November 14, 2012


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.

b. The bottom button should read, “Disable Group Mode.” If it does not, enable group mode by pressing the button.

7. Refresh the screen. The top of the page should list the group mode partners, but complain about their status.

8. Repeat this procedure with the other members of the group. Within 20 seconds after enabling the last member of the group, the “Group Mode Status” should to go “NORMAL,” and the other group mode members should be listed with “Status: On-Line” and “Configuration: OK.”

4.15.6 Setting Forwarding Rules

By default, group mode apportions connections between members by applying a hash to the source and dest addresses. This is unlikely to match the traffic patterns arriving over the WAN. When a group member receives a packet for a connection that 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.


4.16 Compression

In the example below, member 172.16.1.102 is the owner of all traffic to or from its own subnet (172.16.1.0/24), while member 172.16.0.184 is the owner of all other traffic.

If a packet arrives at unit 172.16.1.102, and it is not addressed to/from net 172.16.1.0/24, it will be forwarded to 172.16.0.184.

If unit 172.16.0.184 fails, however, unit 172.16.1.102 will no longer forward packets, and will attempt to handle the traffic itself. This behavior can be inhibited by pressing the “Do NOT Accelerate When Member Failure Detected” button.

On a setup with a primary link and a backup link, the forwarding rules would send all traffic to the Appliance on the primary link. If the primary link failed, but the primary unit did not,

4.16 CompressionRepeater compression uses breakthrough technology to provide transparent multi-level compression.

Repeater compression is true compression that acts on arbitrary byte streams. It is not application-aware, is indifferent to connection boundaries, and can compress a string optimally the second time it appears in the data. It supports compression at any link speed.

The compression engine is very fast, allowing the speedup factor for compression to approach the compression ratio. For example, a bulk transfer monopolizing a 1.5 mbps T1 link achieving a 100:1 compression ration can deliver a speedup ratio of almost 100x, or 150 mbps. This works so long as the WAN bandwidth is the only bot-tleneck in the transfer. If the server hardware, the client hardware, the LAN, or the application are also bottlenecks, throughput will necessarily be reduced to the speed of the slowest element in the chain. Protocols that spend time waiting for applica-tion-level handshaking will also see speedup factors lower than the compression ratio, since the compressor can reduce the size of data but can’t do anything about the pauses between data.

Figure 4-39 Forwarding rules

4-56 November 14, 2012


Unlike most compression methods, Repeater compression history is shared between connections, meaning that data sent earlier by connection A can be referred to later by connection B in lieu of retransmitting the data. This gives much higher perfor-mance 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, 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.16.1 XenApp/XenDesktop Acceleration

Note: For the purposes of this section, “XenApp” means “XenApp and XenDesktop” and refers to the ICA and CGP protocol streams.

XenApp/XenDesktop (ICA/CGP) acceleration has three components:

1. Compression. The Appliance cooperates with XenApp clients and servers to com-press XenApp data streams for interactive data (keyboard/mouse/display/audio) and batch data (printing and file transfers). This takes place transparently and requires no configuration on the Appliance. A small amount of configuration, described below, is required on the XenApp server.

2. Multi-stream ICA. In addition to compression, Branch Repeater supports the new Multi-stream ICA protocol, in which up to four connections are used for the differ-ent ICA priorities, rather than multiplexing all priorities over the same connection. This gives interactive tasks greater responsiveness, especially when combined with Branch Repeater’s traffic shaping.

Note: Multi-stream ICA is disabled by default. It can be enabled on the “Features” page.


4.16 Compression

3. Traffic shaping. Branch Repeater’s traffic shaper uses the priority bits in the XenApp data protocols to modulate the connection’s priority in real time, matching the bandwidth share of each connection to what it’s doing at the moment.

XenApp acceleration applies to both the ICA and CGP protocols within XenApp. The Repeater appliances, XenApp servers, and XenApp clients provide cooperative acceleration of XenApp connections, giving substantial speedup compared to XenApp alone. This cooperation requires up-to-date versions of all three components.

Enabling XenApp Acceleration:

1. Check the ICA service class policy on Appliances that have been upgraded to Branch Repeater 6.x from prior releases. On the “Configuration: Service Classes” page, the “ICA” service class should show “disk” in the “Acceleration” column and “ICA Priorities” in the “Traffic Shaping” column. If not, the service class definition needs to be edited to correct this. (See Section 9.4.10.)

2. Update XenApp 4.x servers and clients. (Not necessary on XenApp 5.0 and above). Use Presentation Server 4.5 with Hotfix Rollup Pack PSE450W2K3R03 (Beta) or later. This release includes the following server and client software, both of which must be installed for XenApp compression:c. Server package PSE450R03W2K3WS.msp or later.d. Client version 11.0.0.5357 or later.

3. Update XenDesktop servers and clients to release 4.0 or above.4. Verify XenApp server registry settings. (Not necessary on XenApp 5.0 and

above.) On the XenApp servers, verify these settings and correct or create them as necessary:

HKLM\System\CurrentControlSet\Control\Citrix\WanScaler\EnableForSecureIca = 1HKLM\System\CurrentControlSet\Control\Citrix\WanScaler\EnableWanScalerOptimization = 1HKLM\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.”

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-58 November 14, 2012


4.16.2 How Compression Works

4.16.2.1 Memory-Based Compression

An Appliance can transparently compress all of the accelerated sessions passing between two compression-enabled Appliances. A very large compression history is used to provide high compression ratios. This history is kept in RAM for high 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 disk or memory compression on the “Configuration: Service Classes” page, there are no parameters. Additional parameters would be superfluous, as much better results are obtained through dynamic self-adjustment than could be attained through static configuration.

Some benefit can be obtained by disabling compression on ports that are known to carry encrypted data streams, such as HTTPS and SSH. The default service-class 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.

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.16.2.2 Disk-Based Compression

Disk-based compression allows redundant data strings of virtually any length to be recognized and reduced to a handful of bytes. Compression history varies by Appli-ance model, from a minimum of 128 GB on Branch Repeater to a maximum of 600 GB on the Repeater 8800.


4.16 Compression

For example, if a user were to download a set of Linux distribution disks over an accelerated T1 link, and another user re-downloaded them days, weeks or even months later, the second copy would still be in the Appliances’ compression history and would download at several hundred megabits per second.

Disk-based compression is not caching, which can serve up stale, out-of-date data, but is true compression, fetched on demand from the endpoint server.

Disk-based compression saves selected data streams to disk on both the sending and receiving Appliances. Fingerprints of this data (based on a hashing function) are retained in memory. These fingerprints also identify potential matches with data already on the disk. Such data is fetched from the disk and verified byte-for-byte with the incoming data stream by the sending Appliance. Identical strings are reduced to tokens containing the disk identifier, offset, and length of the match. The receiving Appliance retrieves this data from the matching copy its own disk.

(Some compression schemes assume that identical fingerprints indicate identical data, but this is not always true. The Appliance always verifies every byte of a 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.16.3 Enabling/Disabling Compression

Compression is enabled on a per-service-class basis on the “Configuration: Service Classes” page. There is a pull-down menu for each service class, with the following options:

• Disk, meaning both disk-based and memory-based compression are enabled. (If the unit is not licensed or configured for disk-based compression, memory-based compression will be used instead.) This option should be selected unless you have a specific reason for disabling it.

• Memory, meaning that memory-based compression is enabled but disk-based compression is not. This setting is rarely used.

4-60 November 14, 2012


• Flow-Control Only, which disables compression but enables flow-control acceler-ation. This should be selected for services that are always encrypted, plus the FTP Control channel

• None, meaning that compression and flow-control are both disabled..

4.16.4 Measuring Disk-Based Compression Performance

Compression performance varies with a number of factors, including the amount of redundancy in the data stream and, to a lesser extent, the structure of the data 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.

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.

Figure 4-40 Using service class policies to alter compression settings.


4.16 Compression

The “Compression Status” page reports the system compression performance since the system was started or the “Clear” button was used to reset the statistics.

Compression for individual connections is reported in the “connection close” messages in the log:

Neither of these methods distinguishes between disk-based and memory-based 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.16.4.1 Testing LAN performance with Iperf

Iperf is useful for preliminary testing. Iperf is extremely compressible (even on the first pass) and uses relatively little CPU and no disk resources on the two endpoint systems. Compressed performance with Iperf should be over 200 mbps over a T1 link if the LANs on both sides use Gigabit Ethernet, or slightly less than 100 mbps if there is any Fast Ethernet equipment on the LAN paths between endpoints and Appliances.

Iperf is pre-installed on the Appliances (under the Diagnostics menu) and is available from http://dast.nlanr.net/Projects/Iperf/. Ideally, it should be installed and run from the endpoint systems, so the network is tested from end to end, not just from Appli-ance to Appliance.

4.16.4.2 Using FTP for initial testing

FTP is useful for more realistic testing than iperf. FTP is simple and familiar, and its results are easy to interpret. Second-pass performance should be roughly the same as with iperf. If not, the limiting factor will probably turn out to be the disk subsystem on one of the endpoint systems.

To test the disk-based compression system, use the following procedure:

1. Transfer a multi-gigabyte data stream between two units with disk-based 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 history. You may find this too disruptive on a production network.

3. Transfer the data stream a second time and note the effect on compression.

4-62 November 14, 2012


4.17 CIFS (Windows Filesystem) AccelerationThe 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. Both the SMB1 and SMB2 versions of CIFS are supported.

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 inefficient on long-haul networks, requiring an excessive number of round-trips to complete an operation. Because the protocol is very sensitive to link latency, full acceleration must be protocol-aware.

CIFS acceleration reduces the number of round-trips through a variety of techniques. The pattern of requests from the client is analyzed and its next action is predicted. In many cases, it is safe to act upon the prediction even if it is wrong, and these safe operations are the basis of many optimizations.

For example, SMB1 clients issue sequential file reads in a non-overlapping fashion, waiting for each 64KB read complete before issuing the next one. By implementing read-ahead, the Appliance can safely deliver up to 10x acceleration by prefetching the anticipated data.

Additional techniques accelerate directory browsing and small-file operations. 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-41.

The modes of CIFS acceleration are:

• Large file reads and writes• Small file reads and writes• Directory browsing.• Metadata caching.

Large file reads and writes. These SMB1 optimizations are for file transfers of at least 640 KB in size. Safe read-ahead and write-behind techniques are used to stream the data without pauses for every transfer (a transfer is 64 KB or less).

These optimizations are enabled only if the transfer has a BATCH or EXCLUSIVE lock and is “simple.” File copies are always simple; files opened through applications may or may not be, depending on how they are performed within the application.

Speedup ratios of 10x are readily obtainable with CIFS acceleration, provided your link and disks are fast enough to allow ten times your current transfer speeds. 50x speedup can be obtained if necessary. This is not normally enabled due to memory consumption. See your Citrix representative if 10x is not sufficient.

Small file reads and writes. Small-file enhancements center more around 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-


4.17 CIFS (Windows Filesystem) Acceleration

ple, they will not be performed if the CIFS client was not granted an exclusive lock on the directory. When the SMB2 protocol is used, file metadata is cached locally for even greater improvements.

Directory Browsing. Standard CIFS clients perform directory browsing in an extremely inefficient way, requiring an enormous number of round-trips to open a remote folder. CIFS acceleration reduces this to 2-3 round-trips. When the SMB2 pro-tocol is used, directory data is cached locally for even greater improvements.

4.17.1 CIFS Security and Acceleration

Windows file servers have two security modes, “signing” and “sealing.”

• “Sealing” prevents CIFS acceleration altogether.• “Signing” prevents acceleration unless the server-side Appliance has joined a Win-

dows domain (See Section 4.19) and the two Appliances have established a secure peer relationship (See Section 4.20). When these two requirements are met, signing is accelerated automatically.

To accelerate signed CIFS traffic, see Sections 4.19 and 4.20. Otherwise, signing must be disabled (if it is not disabled already), as described below.

Figure 4-41 CIFS server/client support.

Product Server Client

Windows Server 2008 Yes Yes

Windows 7 Yes Yes

Windows Vista Yes Yes

Windows Server 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

Note: Most third-party CIFS implementations emulate one of the servers or clients listed above. To the extent that the emulation is successful, it will be accelerated or not, according to the table above. If the emulation behaves differently from what the CIFS accelerator expects, it will terminate CIFS acceleration for that connection.

The behavior of CIFS acceleration with a given CIFS implementation cannot be known for certain until it has been tested.

4-64 November 14, 2012


By default, Windows file servers offer signing but do not require it, except for domain servers, which require it by default.

To achieve CIFS acceleration with systems that currently require signing, you must change the system security settings to disable this requirement. This is done from local security settings on the file server or in group policies. In the following exam-ples, the local settings will be shown. The group-policy changes are, of course, almost identical.

Windows Server 2003 and Windows Server 2008 (see Figure 4-42):

In “Local Security Settings”:

• Set “Domain member: Digitally encrypt or sign secure channel data (always) to “Disabled”

• Set “Microsoft network client: Digitally sign communications (always)” to “Disabled”

• Set “Microsoft network server: Digitally sign communications (always)” to “Disabled”

Figure 4-42 Windows Server security options, Windows Server 2003 and Windows Server 2008.


4.17 CIFS (Windows Filesystem) Acceleration

Windows 2000 Server (see Figure 4-43):

• Set “Digitally sign server communication (always)” to “Disabled”• Set “Digitally sign client communication (always)” to “Disabled”

Another option, sealing, encrypts the data stream, which prevents CIFS acceleration. Sealing is not enabled by default on Windows file servers.

If sealing has been enabled on your systems, it can be disabled by setting the options on “Secure channel: Digitally encrypt secure channel data” options (on the same page as the signing options) to “Disabled.”

In either case, the issue can be detected through the log file on the client-side Accel-eration unit:

CIFS Session from client <ip> to server <ip> cannot be accelerated for CIFS due to: server security settings.

4.17.2 Interpreting CIFS Statistics

The “Monitoring: Filesystem (CIFS/SMB) page shows a list of accelerated CIFS con-nections. These connections are divided into “optimized” and “non-optimized” connec-tions. Since all these connections are accelerated (with flow control and

Figure 4-43 Windows 2000 security options.

4-66 November 14, 2012


compression), “optimized” connections have CIFS optimizations added in addition to flow control and compression, while “non-optimized” connections have flow control and compression only.

4.17.3 CIFS Management Summary1. CIFS acceleration will show significant improvement even at relatively short link

distances.2. CIFS acceleration begins when a filesystem is first accessed by the client. If accel-

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 “Monitoring: File-system (CIFS/SMB)” page will increase briefly.

5. Only the Appliance furthest from the fileserver reports CIFS acceleration with full statistics; the other unit sees it as ordinary acceleration. This is frequently confus-ing.

6. CIFS acceleration is not supported in proxy mode.7. If CIFS acceleration does not take place with a Windows server, check its security

settings.

4.18 Microsoft Outlook (MAPI) AccelerationMicrosoft Outlook acceleration provides improved performance on traffic between Microsoft Outlook clients and Microsoft Exchange Servers, increasing throughput with a variety of optimizations, including data prefetching and compression.

This feature is also called “MAPI acceleration,” after the MAPI protocol used between Outlook and Exchange Server.

4.18.1 Supported Outlook/Exchange Versions and Modes• Microsoft Outlook 2003-2010.• Exchange Server 2003-2010.• Any combination of supported clients and servers (using the MAPI protocol) is

supported.• Outlook must connect to the Exchange Server normally, using the MAPI protocol

(no HTTP or HTTPS proxy or “Outlook Anywhere”).


4.18 Microsoft Outlook (MAPI) Acceleration

• If the server-side Appliance has joined a Windows domain, connections with MAPI encryption will be accelerated. Otherwise, they will not be, and encryption should be disabled in the Outlook clients.

4.18.2 Configuration

Outlook acceleration is a zero-configuration feature that is enabled by default. (If desired, it can be disabled by disabling acceleration on the MAPI service class on the “Configure Settings: Service Class Policy” page.) Outlook acceleration will take place automatically if the following conditions are met:

• There is an Appliance at the Exchange Server end of the WAN.• There is an Appliance at the Outlook end of the WAN, OR the system running

Outlook is also running the Repeater Plug-in.• All Outlook/Exchange traffic passes through the appliances.• Either the Exchange Server or the Outlook are restarted (acceleration does not

begin until existing MAPI connections are closed).• Either encryption is disabled on Outlook or the server-side Appliance belongs to

the Windows domain and has a secure peer relationship with the client-side Appliance (or Repeater Plug-in).

4.18.2.1 Disabling Encryption on Outlook 2007

Unless the server-side Appliance has joined the Windows domain and has a secure peer relationship with the client-side Appliance (or Repeater Plug-in), encryption between Outlook and Exchange Server must be disabled for acceleration to take place. (For more on joining the Windows domain, see Section 4.19.)

Encryption was disabled by default before Outlook 2007. Starting with Outlook 2007, encryption is enabled by default.

To disable encryption manually on a single Outlook 2007 client, go to the menu shown in Figure 4-44 and uncheck the box, “Encrypt data between Microsoft Office Outlook and Microsoft Exchange. To disable encryption for multiple users via group policies, follow the instructions at http://support.microsoft.com/default.aspx/kb/924617. Change the Properties for “Enable RPC Encryption” to “Disabled” under “User Configuration: Administrative Templates: Microsoft Office Outlook 2007: Tools: Advanced Settings: Exchange.”

4.18.2.2 Performance Note

MAPI uses a different data format from other protocols. This prevents cross-protocol compression from being effective. That is, a file that was first transferred via FTP and then as an email attachment will not receive a compression advantage on the second transfer. If the same data is sent twice via MAPI, the second transfer will receive full compression.

4-68 November 14, 2012

http://support.microsoft.com/default.aspx/kb/924617


Figure 4-44 Disabling Encryption on Outlook 2007.


4.19 Joining a Windows Domain (CIFS/MAPI Enhancements)


By joining a Windows domain, the following capabilities are enabled:

• Acceleration of “Signed” Windows Filesystem (CIFS) traffic. Before, signed traffic could not be accelerated, and the signing feature (which is enabled by default), had to be disabled on fileservers. By joining the same Windows domain as the server, the server-side appliance can handle signed traffic. This feature works with servers using either the older SMB1 protocol (Windows 2003, Windows XP) and the newer SMB2 protocol (Windows 2008, Windows Vista, Windows 7).

• Acceleration of encrypted Outlook/Exchange (MAPI) traffic. Before, encrypted Outlook/Exchange traffic could not be accelerated. Since encryption was enabled by default on Outlook clients, acceleration required global policy changes. By join-ing the same Windows domain as the Exchange server, the server-side appliance becomes part of the security infrastructure and can accelerate encrypted MAPI traffic, and the mail clients can run with default settings.

4.19.1 Requirements

To benefit from joining a domain, the following must be true:

• Both the client-side and server-side acceleration units must have established a “secure peer relationship,” as with Repeater SSL compression. See Section 4.20.

• In release 6.0, the Windows Domain controller must support NTLM version 1, which is disabled by default. (Release 6.1 works with the Windows default NTLM 2 plus Kerberos setting). Once NTLM 1 is enabled (on the Domain controller only), signed CIFS and encrypted MAPI will work with all the servers in the domain. See Section 4.19.3.

• In release 6.1, Outlook must not be configured for the non-default “Kerberos only” or “NTLM only” options. The default (negotiated) option is required for accelera-tion.

• In release 6.0, both the client and server must be members of the same domain as the Appliance. In release 6.1, the client and server can be members of any domain that has two-way trust with the Appliance’s domain.

• Note that the Macintosh Outlook client does not use the MAPI (Outlook/Exchange) standard and is not accelerated by this feature.

4-70 November 14, 2012


4.19.2 Joining the Windows Domain

Go to the “Configuration: Windows Domain” page and press the “Join Domain” but-ton. Enter the domain administration credentials. The appliance will join the domain, which involves exchanging a shared secret with the domain controller, allowing the appliance to remain part of the domain indefinitely. (The domain administration cre-dentials are not saved on the appliance.)

4.19.2.1 Adding the Kerberos Delegate User

(Release 6.1 only) The delegated user must be configured on the Windows domain server for some of the advanced CIFS/MAPI acceleration features of release 6.1 to operate. Follow these steps:

1. On the domain controller that is responsible for the CIFS/MAPI servers to be accel-erated, create a new user. We will give the user the name “delegate_user.” Create the user with “Active Directory Users and Computers,” selecting “Users” under your domain name.

2. In “Active Directory Users and Computers, select “View: Advanced Features” to

Figure 4-45 Joining a Windows domain (release 6.1 version shown; release 6.0 lacks the Kerberos option).



allow the “Attributes Editor” tab to be displayed in “User Properties.”

3. In the delegate user’s User Properties, go to the “Attribute Editor” tab and set the

Figure 4-46 Creating a delegate user on the Windows domain controller.

4-72 November 14, 2012


ServicePrincipalName to “delegate/delegate_user.”

4. Next, on every server in the domain for which you want acceleration of encrypted CIFS/MAPI traffic, grant delegated user access for CIFS and MAPI:a. Go to “Active Directory Users and Computers: delegate_user: Properties: Del-

egation.”b. Select “Trust this user for delegation to specified services only” and “Use any

authentication protocol.”

Figure 4-47 Setting the service principal name (SPN) for delegation.



c. Add the CIFS and ExchangeMDB services for delegation, specifying the local hostname as the “User or Computer.”

5. If the server does not have a DNS reverse lookup entry for the domain controller, the following two commands must be run. If your domain controller had a host-name of “dc” and a fully-qualified domain name of “dc.example.com” and was at address 10.102.79.x, you would use the commands:dnscmd dc /zoneadd 79.102.10.in-addr.arpa /primarydnscmd dc /recordadd 79.102.10.in-addr.arpa 25 PTR dc.example.com

4.19.3 Enabling NTLM Version 1

Release 6.0 does not support Kerberos or NTLM version 2, while it does support NTLM version 1. However, NTLM support is not the default on Windows networks. Follow this procedure when release 6.0 is used:

Figure 4-48 Adding the services.

Note: This procedure is required only for release 6.0. Release 6.1 supports NTLM version 2 and Kerberos, which are the Windows defaults.

Note: Use this procedure only if your security policies permit it.

4-74 November 14, 2012


On the Windows domain controller, this is done with the “Group Management Policy” screen under “Default Domain Policy.” Set “Network Security: LAN Manager Authenti-cation Level” to “Send LM and NTLM responses.”

The Group Management Policy application (gpmc.msc) is bundled with Windows 2008 Server and above, and can be downloaded for Windows 2003 Server from: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=21895.

Enabling NTLMv1 on individual clients is done similarly, with “Local Policies: Security Options” (secpol.msc). Set “Network Security: LAN Manager Authentication Level” to “Send LM and NTLM responses.”


4.20 SSL Compression

4.20 SSL CompressionSSL 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-49 SSL Compression.

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.

Client-SideSSL Connection

WANSSL Tunnel

Server-SideSSL Connection

SSL Connection

Ordinary SSL Connection

Accelerated SSL Connection

4-76 November 14, 2012


4.20.1 How SSL Compression WorksSSL 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.

4.20.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.20.2.1 SSL Split Proxy

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

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.

Figure 4-50 SSL split proxy mode.

Servers’ Credential

SSL Signaling Connection

SSL Data Connection Servers



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.20.2.2 SSL Transparent Proxy

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.

Figure 4-51 SSL transparent proxy mode.

Server’s Private Keys

SSL Signaling Connection

SSL Data Connection

4-78 November 14, 2012


True client authentication is supported in this mode, but Temp RSA and Diffie-Hellman are not. SSL transparent proxy mode is suited for applications that require client authentication if the following features are not required: Diffie-Hellman, Temp RSA, TLS session tickets, SSL version 2. Also, session renegotiation must not be attempted, or the connection will terminate.

No configuration is required on the client-side Appliance (other than configuring a peer relationship with the server-side Appliance), and no configuration is required on the client, which sees the connection exactly as if it were talking to the server directly.

To support multiple servers, multiple private keys can be installed on the Appliance, one per SSL profile. Special SSL rules in the service class definitions match up servers to SSL profiles, and thus SSL profiles to private keys.

4.20.3 Generating Security Keys and CertificatesThe 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 keyopenssl genrsa -out my.key 2048# Now create a Certificate Signing Requestopenssl req -new -key my.key -out my.csr# Finally, create a self-signed certificate with a 365-day expirationopenssl x509 -req -days 365 -in my.csr -signkey my.key -out my.crt

For production use, consult your organization’s security policies.

4.20.4 Configuring SSL Compression

4.20.4.1 Configuring the Appliance

The following procedure uses the “Configuration: SSL Encryption,” “Configuration: Secure Partners,” and “Configuration: SSL Encryption” pages. This pages are described in full in Sections 9.4.9, 9.4.11, and 9.4.12.

Note: The “Configuration: SSL Acceleration” page has an unusual structure. It is divided into five tabs, but instead of having tab icons at the top, it has buttons at the bottom. The five tabs are: “Profiles,” “Manage CAs,” “Manage Keys,” “Import SSL,” and “Export SSL.”



Follow this procedure to set up SSL compression:

1. Hide the “Configure SSL Connection Guide.” These online instructions are less comprehensive than the ones you are reading now and should be ignored. Press the “Hide Guide” link at the upper right-hand corner of the online help block.

2. Install a crypto license. Without a crypto license, SSL Compression and User Data Encryption are not available, and you will see a yellow warning message to this effect on the “Configuration: SSL Acceleration” page.a. Order a crypto license from Citrix.b. Install the license via the “System Settings: License Management: License

Server” tab if you are using a network license server, or the “Configuration: Licensing: Local Licenses” tab otherwise (see Section 9.4.4.3).

c. Verify successful installation on the “Licensed Features” tab of the “Configura-tion: Licensing” page. The “Crypto License” heading should appear in the Licensed Features table and the crypto license expiration date should be in the feature.

3. Set a key store password, then open the key store. On the “Configuration: SSL Encryption” page, open the key store and assign a password to it. (You will have to re-enter this password after every restart, so don’t forget it.)

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. This feature uses AES-256 encryption.

5. Enable SSL compression (under “SSL Optimization”) by pressing the “Enable” button. (However, compression will not take place until further configuration is done.)

6. Install credentials for the SSL signaling connection. The Appliances will use these credentials to authenticate each other, and to encrypt communications between each other. On each Appliance, acquire a CA certificate and certificate/key pair for the SSL signaling connection. See the examples of certificate and key generation in Section 4.20.3. When using self-signed certificates, the same 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 “Configuration: SSL Acceleration” page, click

the “Manage CAs” button at the bottom of the page, then press the “Add” but-ton. 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-52. (See also Section 9.4.11.)

b. Install the Cert/Key Pair. This process is nearly identical to inserting the CA Certificate. Press the “Manage Keys” button at the bottom of the page, then press the “Add” button. Cert/key pairs are sometimes generated as a single

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.

4-80 November 14, 2012


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.

7. .Set up the SSL signaling connection on the Appliance. See Figure 4-53.

Figure 4-52 Installing certificates.

Figure 4-53 Configuring peer communication.



a. Enable Peer Connections. Select “Enabled” under “Peer State.”b. Select Cert/key and CA for Signaling Connection. On the “Configuration:

Secure Partners” page, specifying the certificate/key pair and CA certificate store you installed in the previous step.

c. Select Peer Authentication Method. Under “Certificate Validation,” select how authorized peers are identified. “Signature/Expiration” is the default: that is, the credentials are examined for authenticity based on their signature and expiration date. Other options include “Signature/Expiration/Common Name White List,” where the common name on the certificate must be present in a whitelist (which appears below the radio button when this option is selected); “Signature/Expiration/Common Name Black List,” where the common name must not appear in the blacklist (which appears below the radio button when this option is selected); and “None.”

d. SSL Cipher Specification. This uses the OpenSSL syntax for specifying accept-able ciphers for the signaling connection. The signaling connection carries key 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.

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.

4-82 November 14, 2012


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 “Configura-tion: SSL Acceleration” page. The procedure is the same as adding cert/key pairs and CA certificates for the signaling connection.

9. Set up a split-proxy SSL Profile for your SSL server. See Figure 4-54. (See the next step for transparent proxy.)

Figure 4-54 Configuring split proxy.



a. Go to the server-side Appliance only, go to the “Configuration: SSL Accelera-tion” 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.

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.

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 “Configuration: SSL Acceleration” page and create a profile:a. Click the “Add” button to add a new profile. b. Profile Name. Select a profile name for the “Profile Name” field.c. Profile Enabled. Check the “Profile Enabled” box.d. Proxy Type. Select “Transparent.”e. Virtual Host Name (optional). If your SSL server uses more than one virtual

hostname, type the virtual hostname that matches the server credentials you supplied in the “Virtual Host Name” field. Otherwise, you can leave it blank. This option is effective only for TLS. To support multiple virtual host names, create multiple SSL Profiles.

f. SSL 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.

4-84 November 14, 2012


11.Create an SSL service class. On the server-side Appliance, go to the “Configu-ration: Service Classes” page and create a new service class with appropriate SSL rules. We will take the example of an HTTPS server at 172.16.0.1:

a. Create the Service Class. On the “Configuration: Service Classes” page, press the “Create” button. Type in a name for the new service class (for example, “Accelerated HTTPS”) and press the “Create” button. The new service class will appear at the top of the service class list.

b. Enable Acceleration. Set the acceleration policy to “Disk” or “Memory.”c. Create a Rule. Click on the service 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.

d. Toggle the “Bidirectional” Icon (between the “Src IP” and “Dst IP” columns) to make the rule unidirectional. SSL rules do not work with bidirectional mode set.

e. Attach the Rule to an SSL Profile. Each SSL rule is attached to one or more SSL profiles. Press the “Add” button and select the profile you created for this server, then press the “Add” button.

f. Save the Rule. Press the “Save” button.g. Set service classes on the client-side Appliance. SSL traffic will not be 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), but it must enable acceleration and compression. The traffic will fall into an existing service class, such as “HTTPS” or “Other TCP Traffic,” and if this class’s policy enables acceleration and compression, no additional configuration is needed.

12.Verify operation. SSL connections matching the SSL service class rules should now be compressed. To see if they are, look at the “Monitoring: Connections” list and click on the “info” balloon on the Details column for the connection. It will report the connection’s service class on the “Detailed Connection Information”

Figure 4-55 SSL service class rules.


4.21 Additional Features

table. If this matches your SSL service class, SSL compression is taking place.

4.20.5 Using SSL Compression on the Repeater Plug-in

The Repeater Plug-in is always used as the client-side unit and thus requires no additional SSL configuration besides installing credentials for the SSL signaling connection. The main difference between SSL compression on the Plug-in and the Appliance is that no facility is provided to encrypt the user data in disk-based compression history.

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 6.6.3 for instructions on installing SSL signaling connection credentials.

4.21 Additional FeaturesThe following list gives, in brief, additional features that are not further elaborated in this section. Configuration details for these features are given in Chapter 9.

• 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 9.2.2.9 for more information on the SCPS implemen-tation. See http://www.scps.org for general SCPS information.

• SNMP support. See Section 9.4.7.7.• Performance monitoring. Summary performance graphs are shown on the Dash-

board page of the browser-based interface. Detailed performance information is given on additional pages in the “Monitoring” pages (Section 9.3) and the “Report-ing” pages (Section 9.5).

• Debugging support. The Appliance detects many potential problems and reports them via the browser-based interface. An “Alert” feature warns the user whenever

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.

4-86 November 14, 2012


a potential problem has been detected. Extensive log files are also kept. See Sec-tion 9.3.5.

• Remote software updates. The browser-based interface allows the administrator to install new version of the software. Previous versions are retained by the sys-tem, and it is possible to revert to an older version. See Section 9.6.6.

• Remote license upgrades. Each unit has a licensed bandwidth limit. This can be increased by installing a new license key using the browser-based interface. See Section 9.6.6.

• Two levels of user accounts are supported: Admin and Viewer. See Section 9.4.1.3.

• A serial interface allows access to the command-line interface. See Chapter 10.

4.22 Proxy Mode (Legacy Feature)

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.22.0.1 Overview

For a connection to be accelerated, its data must pass through an Appliance at each end. This happens automatically in inline mode, since the Appliances are between the WAN and the target systems, and all data passing between these two systems must pass through the two Appliances.

When the Appliance is not inline with the path between the two systems, packets must be addressed to it explicitly. The mechanism for this is to assign a virtual IP address (or VIP) to the Appliance. Applications use the virtual IP address instead the real IP address of the target system. For example, “ftp Alpha-proxy” is used instead of “ftp Alpha.” The local Appliance responds to the virtual IP address and forwards packets to the remote Appliance, which in turn forwards it to system “Alpha.”

A proxy-mode Appliance can be anywhere; it does not have to be between the WAN and the systems to be accelerated. Proxy mode makes it easier to reserve an 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-56 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.”

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.



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-56 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-57 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.

Figure 4-56 Proxy mode connection from system “Alpha” to “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)

System "Alpha"

System "Beta"

Network A Network B

VIP: "Beta-Proxy-A"

Appliance-A

Appliance-B

VIP: "Beta-Proxy"

4-88 November 14, 2012


Figure 4-57 Proxy mode connections from system “Beta” to “Alpha.”

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)

System "Alpha"

System "Beta"

Network A Network B

VIP: "Beta-Proxy-A"

Appliance-A

Appliance-B

VIP: "Beta-Proxy"



4.22.0.2 Proxy Mode Topologies

Proxy mode is shown in Figure 4-58. 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 9.4.2.7 for a description of the “proxies” page in the management interface.

A proxy connection can be used with the units either inline or out-of-line. In fact, one end of the connection can be in inline mode and the other in proxy mode. The inline unit requires no configuration at all.

This allows the simplicity of inline operation at remote offices, while allowing proxy mode (with its greater control) in central offices.

All four case of inline vs. out-of-line units are supported by proxy mode, as shown in Figure 4-58.

Figure 4-58 Combinations of inline and proxy mode

Client Side Server Side

Case Mode VIP Points To ModeVIP Points

To

1 Inline - Inline -

2 Proxy Server Inline -

3 Inline - Proxy Server

4 ProxyServer VIP (on server-side

Appliance)Proxy Server

ClientNetwork

ServerNetwork

Case 1. Inline Mode

ClientNetwork

ServerNetwork

Case 2. Full Proxy Mode

ClientNetwork

ServerNetwork


ClientNetwork

ServerNetwork


Server Server

ServerServer

4-90 November 14, 2012


• 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.22.0.3 VIP-to-VIP Proxies

In Case 4, we used a VIP-to-VIP proxy. To access a remote server, the local Appliance had a proxy whose VIP pointed not to the server, but to a VIP on the remote network. Why was this done?

For acceleration to take place, the data must pass through both Appliances. When a unit is not inline, data from a new connection reaches it in one of two ways: either because the client addressed the data to it (by using a VIP) or because the other Appliance forwarded the data to it.



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

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 9.4.2.7 for a description of the “Configuration: Advanced Deployments: Proxy” configuration page.

Figure 4-59 Proxy mode, showing VIP-to-VIP proxying.

To systems on Network A, “Beta” appears to be a local system at address “A-Beta-Proxy.”

"Alpha"

"Beta"

VIP: "A-Beta-Proxy"

Network A Network B

VIP: "B-Beta-Proxy"

WAN

4-92 November 14, 2012

Chapter 5

Cabling and Physical Deployment

5.1 Power On/OffThe 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.

5.2 Ethernet IssuesThe 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

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

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

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


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

5.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 “Configuration: Network Adapters” page. (See Section 9.4.6.)

In a fail-to-wire installation, the issue extends to both Appliance ports plus the ports they connect to. All four ports should be set to Auto, or all four should be forced to the same mode.

The auto-negotiation problem may occur anywhere along the path between LAN and WAN, not necessarily on the connection to the Appliance itself. It is not unusual to discover long-standing cases of this problem in installations where past performance

5-2 November 14, 2012

Chapter 5. Cabling and Physical Deployment

expectations have been low. It should be suspected when the “Alerts” page reports high packet losses. (See Section 9.4.7.5.) If the mismatch occurs on a link directly connected to the Appliance, the Alerts section will report a half-duplex connection.

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

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

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

Figure 5-1 Basic cabling, inline mode

Figure 5-2 Basic cabling, inline high-availability pairs

Appliance

Detail: LAN-Side Cabling

LAN

Server, Client

Cross-Over

Orange

WANRouter

Detail: WAN-Side Cabling

Straight-Through

Blue

Cross-Over

Orange

Straight-Through

Blue

DSL or Cable

Modem

Router or Other Device (see below)

Internal Router

Cross-Over

Orange

Straight-Through

Blue

Switch

Switch

Switch or Other Device (see below)

Use Existing Cabling

Use Existing Cabling

See BelowSee Below

WAN or Internet


5.3 VLAN Support

The optional Fiber Ethernet card also supports bypassing.

The bypass feature is wired as if there were a cross-over cable between the two ports, which is the correct behavior in properly wired installations.

Bypass Installations Must Be Tested. Improper cabling may work in normal operation but not in bypass mode. The Ethernet ports are tolerant of improper cabling and will often silently adjust to it. Bypass mode is hard-wired and has no such adaptability. The bottom line is that inline installations should be tested with the Appliance turned off to verify that the cabling is correct for bypass mode.

5.3 VLAN SupportBranch Repeater supports VLAN trunking. This means that any combination of VLAN tags can be present on accelerated traffic, and it will be handled and accelerated cor-rectly. This works in all forwarding modes (inline, WCCP, virtual inline, and group mode).

For example, if one connection passing through the bridge is addressed to 10.0.0.1, VLAN 100, and another connection is addressed to 10.0.0.1, VLAN 111, Branch Repeater knows that these are two distinct destinations.

5.4 What Happens if the Appliance Fails

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

When the Appliance comes back online, existing connections will continue as non-accelerated connections. New connections will be accelerated in the usual way.

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

5.4.3 Virtual Inline Mode

If the “verify-availability” option is used with virtual inline mode, the router behaves like it does with WCCP mode, bypassing the unit when it is not available and 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.

5-4 November 14, 2012


5.4.4 Group Mode

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

5.4.5 High-Availability Mode

See Section 5.5 below. Individual HA units always fail “open” (bridging disabled).

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

5.5 High-Availability ModeTwo 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.

5.5.1 Cabling Requirements

The two units are installed onto the same subnet in either a parallel arrangement or a one-armed arrangement. Both are shown in Figure 5-3. When using a one-armed arrangement, use the apA.2 port (and, optionally, the apB.2 port), not the apA.1 port (See Figure 5-4).

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 5-3 with additional switches.

The spanning-tree protocol (STP) is not recommended on the router or switch ports attached to the Repeater Appliances, because STP can increase the failover time by tens of seconds.

5.5.2 Other 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.


5.5 High-Availability Mode

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

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.

Figure 5-3 Cabling for high-availability pairs.

LANWAN

apA.2

apA.2

apA.1

apA.1Switch

(Spanning Tree Disabled)

Switch(Spanning Tree

Disabled)

LANapA.2

apA.2Switch


WAN

Pri. Port Pri. Port

Switch

Mgt. LAN

LANWAN

apA.2

apA.2

apA.1

apA.1Switch


Switch(Spanning Tree

Disabled)

Inline

Inline With Management LAN

One-Armed (Virtual Inline or WCCP)

5-6 November 14, 2012


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.

Figure 5-4 Ethernet port locations on the appliance.

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.

Note: The secondary unit in the HA pair has one of its bridge ports disabled to pre-vent forwarding loops. This port is apA.1. If the unit has dual bridges, apB.1 is also disabled. In one-armed installations, this means that you should always use port apA.2, or the secondary unit will become inaccessible as soon as HA is enabled.

Primary Aux1

apA.1 apA.2

Rear of Appliance, Branch Repeater

Primary Aux1

apA.1 apA.2apB.1 apB.2(optional)


Primary Aux1

apA.2


apA.1

apB.2

apB.1

(Optional)



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.

5.5.4 HA Virtual Address

You must assign a new IP address for the high-availability pair. This HA Virtual Address is used to manage the two as if they were a single unit. Once high-availability mode is enabled, managing the secondary unit through its IP address is mostly dis-abled, with most parameters greyed out. A warning message is displayed on every page giving the reason. The secondary unit can have its HA state disabled from its management UI, however.

5.5.5 Enabling/Disabling High-Availability Mode

Follow the procedure in Section 3.3.7.

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

5.5.7 Saving/Restoring Parameters in the HA Pair

The “System Maintenance: Backup/Restore” function can be used to save and restore parameters of HA pairs as follows:

To back up the parameters, simply use the “Backup” feature as usual, logging into the GUI on the VIP address (as is normal when managing the HA pair).

To restore the parameters:

1. Disable HA on both Appliances.2. Unplug a network cable from the bridge of one Appliance.3. Unplug the power cord from this Appliance.4. Restore the parameters on the other Appliance (this will require a restart, which

will re-enable HA).5. Wait for this Appliance to restart. It will become the Primary.6. Restart the other Appliance.

Note: pressing the “Update button” will terminate all open TCP connections

5-8 November 14, 2012


7. Log into the GUI on the second Appliance and re-enable HA. The Appliance will get its parameters from the Primary.

8. Plug in the network cable removed in step 2.9. Both Appliances are now restored and synchronized.



5-10 November 14, 2012

Chapter 6

The Repeater Plug‐in 6.1 About the Repeater 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.

Figure 6-1 Repeater allows accelerated communications from clients worldwide.

Internet

Mobile VPN Users with Repeater

Plug-in

Home-Office VPN Users with Repeater

Plug-in

Small Branch Office(Internet/VPN

Connected)

Firewall RepeaterPlug-in

VPN Firewall

Repeater8800

Central Office

Servers

RepeaterPlug-in

PrivateWAN

Large Branch Office

Repeater8500

Servers

OrdinaryPCs

OrdinaryPCs

Small Branch Office(WAN Connected)

RepeaterPlug-in

Repeater8800


6.1 About the Repeater Plug-in

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

6.1.2 Supported Plug-in Platforms

The Repeater Plug-in is supported on desktop and laptop systems, but not on net-books or thin clients. It is supported on the following operating systems:

• Windows XP Home• Windows XP Professional• Windows Vista (all 32-bit versions of Home Basic, Home Premium, Business,

Enterprise, and Ultimate)• Windows 7 (all 32-bit and 64-bit versions of Home Basic, Home Premium, Profes-

sional, Enterprise, and Ultimate).

Recommended hardware requirements are:

• Pentium 4-class CPU• 2 GB of RAM• 2 GB of free disk space

Minimum hardware requirements are:

• 1.0 GHz CPU• 1 GB RAM• 500 MB free disk space

6-2 November 14, 2012

Chapter 6. The Repeater Plug-in

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



6.1.4 Detailed Description of Transparent Mode

In transparent mode, the packets for accelerated connections must pass through the target Appliance, much as they do in Appliance-to-Appliance acceleration.

Figure 6-2 Transparent mode, showing three of the possible acceleration paths.

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.


Plug-in


Plug-in


Connected)

Firewall Repeater Plug-in

VPN

Repeater A2(8800)

Central Office A

Servers

Repeater Plug-in

PrivateWAN

Large Branch Office B

Repeater B (8500)

ServersOrdinaryPCs

OrdinaryPCs


Repeater Plug-in

ACCELERATED

Internet

ACCELERATED

ACCELERATED

Repeater A1 (8800)

Firewall

6-4 November 14, 2012


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 6-2. The Repeater Plug-in is compatible with most IPSec, and PPTP VPNs, and with Citrix AG-SE and AG-AE SSLVPNs.



6.1.4.1 Packet Flow in Transparent Mode

Packet flow in transparent mode is shown in Figure 6-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 6-3 Packet flow in transparent mode.



Server10.200.0.10

1 23

4

5

6

The Repeater Plug-in receives the SYN-ACK packet. The options in the packet headers indicate that the connection is accelerated. The Plug-in strips the options and passes the SYN-ACK packet to the application. The connection is now fully open and accelerated.

6


The Repeater Plug-in looks up the destination address and sees that it matches a subnet accelerated by the appliance. It attaches Repeater options to the TCP header of the SYN packet. No addresses are changed.

Src: 10.0.0.50, Dst: 10.200.0.10

The appliance notes the SYN options and recognizes that this is an accelerable connection. It strips the options from the packet and allows it to pass through to the server. No addresses are changed.

Src: 10.0.0.50, Dst: 10.200.0.10


Src: 10.200.0.10, Dst: 10.0.0.50

The appliance tags the SYN-ACK packet with a TCP header option that shows that acceleration will take place.

Src: 10.200.0.201, Dst: 10.0.0.50

1

2

3

4

5

6-6 November 14, 2012


6.1.5 Detailed Description of Redirector Mode

Figure 6-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 6-4 Redirector mode, showing one possible acceleration path.

Internet


Plug-in


Plug-in


Connected)

Firewall RepeaterPlug-in

VPN Firewall

Repeater8800

Central Office

Servers

Repeater Plug-in

PrivateWAN

Large Branch Office

Repeater8500

Servers

OrdinaryPCs

OrdinaryPCs


Repeater Plug-in

Repeater8800

ACCELERATED CONNECTION



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

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.

Figure 6-5 Packet flow in redirector mode.

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.



Server10.200.0.10

1 23

4

5

6

The connection is now fully open. The client and server send packets back and forth via the appliance.

While the addresses are altered in Redirector mode, the destination port numbers are not (though the ephemeral port number may be). The data is not encapsulated. Redirector mode is a proxy, not a tunnel.

There is no 1:1 relationship between packets (though in the end, the data received is always identical to the data sent). Compression may reduce many input packets into a single output packet. CIFS acceleration will perform speculative read-ahead and write-behind operations. Also, if packets are dropped between appliance and the Repeater Plug-in, the retransmission is handled by the appliance, not the server, using advanced recovery algorithms.

6


The Repeater Plug-in looks up the dst address and decides to redirect the connection to the appliance at 10.200.0.201.

Src: 10.0.0.50, Dst: 10.200.0.201

(10.200.0.10 is preserved in a TCP option field. Options 24-31 are used for various parameters.)

The appliance accepts the connection and forwards the packet to the server (using the dst address from the TCP options field), and giving itself as the src.

Src: 10.200.0.201, Dst: 10.200.0.10


Src: 10.200.0.10, Dst: 10.200.0.201

The appliance rewrites the addresses and forwards the packet to the Plug-in (placing the server address in an option field).

Src: 10.200.0.201, Dst: 10.0.0.50

1

2

3

4

5

6-8 November 14, 2012


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

6.2 Deploying Appliances for Use With Plug-ins

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

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

Note: You must read Chapter 2 in addition to this section.


6.2 Deploying Appliances for Use With Plug-ins

However, Appliances can use any of the deployment modes described in Chapter 2, with the exception of group mode. These modes are suitable for both Appli-ance-to-Appliance and client-to-Appliance acceleration, and can be used for either redirector or transparent mode.

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

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

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

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

6-10 November 14, 2012


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.

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

Figure 6-6 Setting Plug-in rules on the Appliance


6.3 Deploying Plug-ins

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

6.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.4.1 for more information.

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

6.3 Deploying Plug-insThe 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.”

6-12 November 14, 2012


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.

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

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

Note: The altered parameters in your edited.MSI file are only used on new installa-tions. 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 and applies them globally (including SSL compression characteristics). This can lead to undesirable and confusing results, especially if the DNS server rotates the order of IPs on each request.


http://www.microsoft.com/downloads/details.aspx?FamilyID=0baf2b35-c656-4969-ace8-e4c0c0716adb&DisplayLang=en

http://www.microsoft.com/downloads/details.aspx?FamilyID=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 6-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 6-8

To edit a parameter, double-click on its value, type the new value, and press Enter, as shown in Figure 6-9.

When done, use the “File -> Save As..” command to save your edited file with a new filename; for example, “test.msi”.

Figure 6-7 Using Orca.

6-14 November 14, 2012


Figure 6-8 Plug-in parameters.

Parameter Description Default CommentsWSAPPLI-ANCES

List of Appliances None Enter the IP or DNS addresses of your Appliances here. Comma-separated list in the form of “{ Appliance1, Appliance2, Appliance3 }”. If the port used for signaling connections is differ-ent from the default (443), specify this in the form “Appliance1:port_number”.

DBCMINSIZE Minimum amount of disk space to use for compres-sion, in megabytes

250 Changing this to a larger value (for example, 2000) will improve compres-sion performance, but will prevent installation if there is not enough disk space. The Plug-in will not install unless there is at least DBCMINSIZE + 100 MB of free disk space.

PRI-VATEKEYPEM

Private key for the Plug-in. Part of the certificate/key pair used with SSL compression

None Use Orca’s “Paste Cell” command, as the normal “Paste” function does not preserve the key’s format.

Should be a private key in PEM format (starting with “-----BEGIN RSA PRI-VATE KEY-----”)

X509CERTPEM Certificate for the Plug-in. Part of the certificate/key pair used with SSL compression


Should be a certificate in PEM format (starting with “-----BEGIN CERTIFICATE -----”)

CACERTPEM Certification Authority Certifi-cate for the Plug-in. Used with SSL compression


Should be a certificate in PEM format (starting with “-----BEGIN CERTIFICATE -----”)



Your Plug-in software has now been customized.

6.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 6.3.1.

Figure 6-9 Editing parameters in Orca.

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.

6-16 November 14, 2012


7. Obtain the Repeater Plug-in software (a file in the form of “Repeater*.msi”) from your Citrix representative.

8. Copy the file to the client system by some convenient means (shared filesys-tem, FTP server, Web download, etc.)

6.3.3 Installation

9. 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).

10. 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 500 MB of disk space.

Figure 6-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



11. Once the installer finishes, you it may ask you to restart the system. After restarting, the Repeater Plug-in will start automatically.

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

Figure 6-11 Final installation screen.

6-18 November 14, 2012


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.



6.3.5 Running the Plug-in For the First Time

12. Right-click the Accelerator icon in the task bar and select “Manage Acceleration” to launch the Citrix Plug-in Accelerator Manager.

13. 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. 7.5 GB is not too much, if you have this much disk space available.

• Press the “Apply” button.

14. The Repeater accelerator is now running. All future connections to acceler-ated subnets will be accelerated

Figure 6-12 Citrix Accelerator Manager, initial (Basic) display.

6-20 November 14, 2012


6.4 Testing the Installation15. On the Plug-in’s “Advanced.. Rules” tab, the “Acceleration Rules” list 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.

6.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.4.1.• The Plug-in is using an unsupported VPN.

6.6 Repeater Plug-in Command Reference

6.6.1 Basic Display

The Basic display is shown in Figure 6-12. This is the display that appears initially. The other commands are on the Advanced display.

The Basic display allows two parameters to be set:

• The “Signaling Addresses” field specifies the IP address of each Appliance that will be used by the Plug-in. If you have more than one Appliance, this can be a comma-separated list (though this is not the recommended configuration). This is an ordered list, with the leftmost Appliances having precedence over the others. Acceleration will be attempted with the leftmost Appliance for which a signaling connection can be established. Both DNS addresses and IP addresses can be used.

Examples: 10.200.33.200, ws.mycompany.com, ws2.mycompany.com• The so-called “Data Cache” slider adjusts the amount of disk space allocated to

the Plug-in’s disk-based compression. More is better. The maximum allowed value of 7.5 GB is not too much.



6.6.2 Advanced Display.

The “Advanced” page contains four tabs: Rules, Connections, Diagnostics, and Certfi-cates.

At the bottom of the display are buttons to enable acceleration, disable acceleration, and return to the Basic display.

6.6.2.1 Rules Tab

This tab gives an abbreviated list of the acceleration rules downloaded from the Appli-ances. The Appliance’s signaling address and port are shown, the acceleration mode (redirector or transparent), and its connection state, followed by a summary of the Appliance’s rules.

6.6.2.2 Connections Tab• 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 6-13 Citrix Accelerator Manager, “Advanced .. Rules” tab

6-22 November 14, 2012


accelerated connections, plus a status field that reports “Active” if the CIFS con-nection is running with our special CIFS optimizations.

• Accelerated MAPI Connections. The number of open, accelerated Outlook/Exchange connections.

• Accelerated ICA connections. The number of open, accelerated XenApp and XenDesktop connections using the ICA or CGP protocols.

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

6.6.2.3 Diagnostics Tab

The Diagnostics page reports the number of connections in different categories, and other useful information.

• 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 History. This feature should not be used.

Figure 6-14 Citrix Accelerator Manager, “Advanced.. Diagnostics” tab



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

6.6.3 “Certificates” Tab

This tab allows you to install security credentials for the SSL compression feature. The purpose of these security credentials is to allow the Appliance to verify whether the Plug-in is a trusted client or not. See Section 4.20 for more information on SSL Com-pression.

To upload the CA certificate and certificate/key pair:

1. Click the “CA Certificate Management” radio button.2. Press the “Import” button.3. Upload a CA certificate. The certificate file must use one of the supported file

types (.pem, .crt., .cer, or .spc. The examples given in Section 4.20.3 are in PEM format.) A dialog box may ask you to “Select the certificate store you want to use,” presenting you with a list of keywords. Select the first keyword on the list.

4. Click the “Client Certificate Management” radio button.5. Press the “Import” button.6. Select the format of the certificate/key pair (either PKCS12 or PEM/DER).

Figure 6-15 The “Certificates” tab.

6-24 November 14, 2012


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.

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

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



6-26 November 14, 2012

Chapter 7

Branch Repeater VPX

7.1 About Branch Repeater VPXBranch Repeater VPX is software product that acts a virtualized Repeater Appliance, roughly equivalent in functionality to the Repeater 8500 Series.

Because it is a virtual machine, you can deploy it using your choice of hardware, exactly where you need it, and combined it with other virtual machines -- servers, VPN units, or other appliances -- to create a unit that precisely suits your needs.

Branch Repeater VPX software is available as:

• A Xen virtual machine running under XenServer 5.5 and later. • A VMware vSphere virtual machine running under ESX/ESXi 4.1 or ESXi 5.0.• A Hyper-V virtual machine under 64-bit Windows 2008 R2 SP1.

7.1.1 Uses For Branch Repeater VPX1. 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.

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.

Note: XenServer and VMware vSphere support VLAN trunking, but Hyper-V does not.

Figure 7-1 VPX use case #1: Branch-office accelerator


7.1 About Branch Repeater VPX

The virtual environment allows you to add whatever functionality you like to the server unit, with your choice of operating system and features. Whatever you install, Branch Repeater VPX will accelerate its WAN traffic — network filesystem access, Web traffic, backups, remote applications, database queries, and so on. More than that, it will accelerate all the WAN traffic from every system in the branch office. You can even deploy multiple virtual servers on the same machine, consolidating your branch-office rack down to a single unit running multiple virtual machines.

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.

Figure 7-2 VPX use case #2: Accelerated branch-office server

7-2 November 14, 2012

Chapter 7. Branch Repeater VPX

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 7-3 VPX use case #3: Accelerated Endpoint Servers

Figure 7-4 VPX use case #4: VPN accelerator


7.1 About Branch Repeater VPX

5. Multiple Branch Repeater VPX Instances. By putting multiple instances of Branch Repeater VPX on the same server, you can create different types or levels of acceleration services within the same unit. One VPX instance might be dedi-cated to a critical application, or each instance dedicated to an individual remote site or customer.

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.

7.1.2 Other Branch Repeater VPX Features• Support of Citrix Command Center 4.0 and up.• Support of Branch Repeater VPX Express licenses, which support a maximum

accelerated sending rate of 512 kbps, 10 accelerated connections, and 5 Repeater Plug-ins.

Figure 7-5 VPX use case #5: Multiple instances for dedicated acceleration resources, using VLAN switches to direct traffic to the appropriate Branch Repeater VPX

Figure 7-6 VPX use case #6: WCCP deployment

7-4 November 14, 2012


• VPX for XenServer:• XenServer Essentials Support• XenMotion Live Migration• XenServer High Availability• Workload Balancing• Performance Monitoring and Alerts

• VPX for VMware vSphere (See Note, below):• VMWare vCenter Server (remote management).• VMWare vSphere HA (high availability).• VMWare vSphere vMotion (migrate Branch Repeater VPX to a different server

with identical processors).• VMWare Guest Customization (replicate VPX with different per-instance

parameters).• VPX for Hyper-V

• VLAN trunking is not supported.

7.2 Differences Between VPX and RepeaterIn 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 and vSphere HA

are supported.)

In cases where an Ethernet bypass card is desirable, using WCCP instead of inline mode will provide an effective failover mechanism.


7.3 System Requirements and Provisioning

7.3 System Requirements and ProvisioningBranch Repeater VPX runs under XenServer 5.5 and VMware vSphere ESX/ESXi 4.1. Branch Repeater VPX supports four configurations, from 2-8 GB of RAM and 100-500 GB of disk. The intermediate, 4 GB RAM/250 GB disk configuration is similar to the Repeater 8500 Series appliance.

7.3.1 Supported Configurations

7.3.1.1 Minimum Resource Requirements

For production environments, the Branch Repeater VPX virtual machine requires a minimum of:

• 2 virtual CPUs.• 2 GB RAM• 100 GB disk (local disks will give maximum performance)• 2 virtual NICs (Ethernet ports)

The server hosting Branch Repeater VPX needs RAM and disk resources greater than those required by the VPX virtual machine. (VPX does not support VMware hardware over-commit.) It is not absolutely necessary to have as many physical Ethernet ports as virtual ones, however, if one of Branch Repeater VPX’s Ethernet ports is connected to another virtual machine on the same server. 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.

Note: The configurations below are the only supported configurations.

Figure 7-7 Production configurations, XenServer and VMware vSphere.

Type vCPUs RAM DiskMax. WAN

Speed

Max. Accel. Conn.

Max. Repeater Plug-Ins

2 GB production config. 2 2 GB 100 GB 2 mbps 1,000 50


4 GB production config.* 2 4 GB 250 GB 45 mbps 15,000 400


* With 45mbps license

Figure 7-8 Other configurations (not for production networks).

Type vCPUs RAM DiskMax. WAN

Speed

Max. Accel. Conn.

Max. Repeater Plug-Ins

VPX Express 2 1 GB 60 GB 512 kbps 10 5

Min. evaluation config. 2 1 GB 60 GB 2 mbps 1,000 5

7-6 November 14, 2012


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

7.3.1.2 Maximum Resources

The maximum amount of resources that a single Branch Repeater VPX virtual machine can use effectively are:

• 4 virtual CPUs• 8 GB RAM• 500 GB disk• 4 virtual NICs

7.3.2 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. Four virtual CPUs are the maximum recommended number.

Network

• Two virtual network interfaces are required. These will be bridged and used for both acceleration and the browser-based user interface.These interfaces must be attached to different virtual networks. Note that, for single-ended operation, the second interface can be a stub, attached only to Branch Repeater VPX.

• If a third virtual network interface is added, it provides an independent interface to Branch Repeater VPX, and is the equivalent to the Primary port. It can be used for the browser-based interface, but not for acceleration.

Other Virtual Machines

• Server resources beyond those allocated to Branch Repeater VPX are available for other virtual machines on the same server.


7.4 Virtual Ethernet Ports

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

7.4 Virtual Ethernet PortsThe 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 server. Only one physical port is required in this case, but both virtual ports are used, as shown in Figure 7-9.

Routing. Virtual network routing can be used to connect other virtual machines on the server to Branch Repeater VPX, but the simplest method of connecting such vir-tual 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, whether they originate inside or outside the server hosting VPX.

7.5 Upgrading a Previous InstallationThe software upgrade mechanism built into Branch Repeater is also supported with Branch Repeater VPX. Alternatively, you can install a new virtual machine containing the desired release.

Figure 7-9 Ethernet (Network) port assignments, single-ended operation

Figure 7-10 An inline deployment that accelerates external traffic and traffic from local VMs.

7-8 November 14, 2012


7.6 Initial Installation, XenServerBranch Repeater VPX is a standard virtual machine in XenServer XVA format. It is downloaded from MyCitrix in the usual way. It is distributed as a ZIP archive to reduce download time.

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

7.6.2 Install the Branch Repeater VPX Virtual Machine1. 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 7-11 through Figure 7-13. Local disk storage will give maximum perfor-mance and reduce contention for disk and network resources.

Figure 7-11 Importing the Branch Repeater VPX virtual machine.


7.6 Initial Installation, XenServer

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 attach both virtual adapters to the same network, or forwarding loops will be created and network outages may be caused. In addition, do not attach the two physical Ethernet

Figure 7-12 Select the server.

Figure 7-13 Configure storage

7-10 November 14, 2012


ports associated with Branch Repeater VPX to the same Ethernet switch. See Figure 7-14.

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

Figure 7-14 Configure virtual network interfaces



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

Figure 7-15 Complete the import

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.

7-12 November 14, 2012


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 7-7 as a guide.

Figure 7-16 Setting the disk allocation



9. Click on “Startup Options,” check the “Auto-start on server boot” checkbox. (The OS Boot Parameters are not used).

Figure 7-17 Setting the virtual CPU and memory allocations

7-14 November 14, 2012


10.Set the basic network parameters.This differs between Release 6.0 and Release 6.1. For Release 6.0, 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: adminPassword: passwordadmin> set adapter apa -ip 172.16.0.213 -netmask 255.255.255.0 -gateway 172.16.0.1admin> restart

Figure 7-18 Setting the start-on-server-boot option



11. For Release 6.1, when a Repeater VPX virtual machine is started for the first time, it automatically run the “Deployment Wizard.” This wizard asks questions about the deployment mode: Inline, WCCP, or “PBR” (virtual inline), or “Setup Using Web UI.” Select “Setup Using Web UI.” On the next screen, enter the IP, netmask, and gateway for the apA interface, and select “Finish.”

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

13.On the “Quick Installation” page, perform a quick installation. See Section 3.3.6.14.Enable bridging with the “Enable Bridging” link. This will pop up a warning dialog

box to remind you that if the two accelerated bridge ports are both connected to the same virtual or physical Ethernet segment, network loops will be created which may bring down your entire network. Check the network assignments in XenCenter, and if the two network devices are connected to different Networks, press “OK.” Otherwise, shut down the Branch Repeater VPX virtual machine and fix the network assignments first.

Figure 7-19 Setting the IP parameters for the accelerated bridge

7-16 November 14, 2012


15.Complete the configuration as you would with any Branch Repeater installation.

Figure 7-20 Double-checking network assignments in XenCenter


7.7 Initial Installation, VMware vSphere


(This section covers installation for VMware vSphere. For XenServer installation, see Section 7.6.)

These instructions assume that you have a basic familiarity with VMware vSphere. Most of this procedure uses the vSphere Client, and details of its operation may vary with new releases of the vSphere software. The VMware documentation should be considered definitive in this regard; the procedure below shows the desired results and one example of achieving them.

The Branch Repeater VPX base image is a VMware virtual machine in OVA format, which is typically downloaded from MyCitrix. It is distributed as a ZIP archive to reduce download time.

1. Install VMware ESX 4.1 or ESXi 4.1on the selected server and the vSphere Client on a system from which you can manage the server. These can be downloaded from http://downloads.VMware.com.

2. In VMware vSphere Client, log onto your VMware server to configure net-working. Branch Repeater VPX requires non-default networking options. Among other things, you will create two new virtual switches (vswitch1 and vswitch2) for the accelerated bridge, which must be assigned to two different virtual switches:

a. On virtual switch vswitch0, enable Promiscuous Mode (Configuration: Networking: Virtual Switch vswitch0: Properties: VM Network: Edit: Security: Promiscuous Mode: “Accept”). See Figure 7-21 through Figure 7-25.

Note: These instructions assume that you have a basic familiarity with VMware vSphere. Most of this procedure uses the vSphere Client, and details of its operation may vary with new releases of the vSphere software. The VMware documentation should be considered definitive in this regard; the procedure below shows the desired results and one example of achieving them.

7-18 November 14, 2012


Figure 7-21 Configuring vSwitch0.

Figure 7-22 Configuring vSwitch0, continued.




Figure 7-24 Configuring vSwitch0: setting promiscuous mode.

7-20 November 14, 2012


b. Create virtual switch vswitch1. (Configuration: Networking: Add Net-working: Virtual Machine: Next: Create a virtual switch). Select one of the vmnic ports offered under “create a virtual switch.” This should be the port attached to the LAN side of your network. Do not select “Use vSwitch0,” because this will cause routing loops. Press “Next.” See Figure 7-26 through Figure 7-29.


Figure 7-26 Configuring vSwitch1



Figure 7-27 Creating vSwitch1, continued.


7-22 November 14, 2012


c. Label the new virtual switch “apA-1” (a standard Branch Repeater port name). Press “Next” and “Finish.” See Figure 7-31.


Figure 7-30 Naming vSwitch1



d. Enable promiscuous mode on vSwitch1, as in Step 2a. See Figure 7-31

e. Create a third virtual switch, vSwitch2, as in Steps 2b-2c above, but attaching it to the port on the WAN side of your network and naming it “apA-2”. See Figure 7-32 through Figure 7-36.

Figure 7-31 Enabling promiscuous mode on vSwitch1

Figure 7-32 Creating vSwitch2

7-24 November 14, 2012


Figure 7-33 Selecting the vSwitch2 connection type

Figure 7-34 Selecting the vSwitch2 port



f. Enable promiscuous mode on vSwitch2, as you did on the other ports (see Step 2a).

Figure 7-35 Naming vSwitch2

Figure 7-36 Creating vSwitch2, continued

7-26 November 14, 2012


3. Install the virtual machine.

a. Go to “File: Deploy OVF Template: Deploy from file: Browse” and select the Branch Repeater VPX OVA file. Press “Next.” See Figure 7-37 through Figure 7-39.

Figure 7-37 Installing the Branch Repeater VPX virtual machine

Figure 7-38 Installing the Branch Repeater VPX virtual machine, continued.



b. Change the name of the virtual machine if desired. Press “Next.” See Figure 7-40.



7-28 November 14, 2012


c. Attach the ports on the virtual machine to the ports you have previously defined: LAN-apA1 to apA-1, and WAN-apA2 to apA-2. Press “Next.” See Figure 7-41.

d. Verify that the mapping looks correct and press “Finish.”

e. Wait for the import process to finish. There will be a “Deployment Com-pleted Successfully” dialog box.

4. (Optional) Add a Primary Ethernet port.

a. Go to “Branch Repeater VPX: Edit Settings: Add: Ethernet Adapter: Next.” Select “VMXNET 3” as the adapter type. Select “VM Network” as the network label. Click “Finish” and “OK.” See Figure 7-42 through Figure 7-45.

Note: Always assign the two Branch Repeater bridge ports (accelerated pair ports) to different virtual and physical Ethernet segments.

If you assign both Branch Repeater bridge (accelerated pair) ports to the same virtual or physical Ethernet port or switch, you will cause network loops. These network loops can make managing Branch Repeater impossible and can bring down the entire Ethernet segment. For example, you will cause network loops if you assign both Branch Repeater ports to vmnic0. This will also happen if you assign the Branch Repeater ports to different physical Ethernet interfaces, but plug both Ethernet interfaces into the same physical switch.

Figure 7-41 Mapping network interfaces to Branch Repeater VPX



Figure 7-42 Installing the Primary Interface

Figure 7-43 Installing the Primary interface, continued.

7-30 November 14, 2012


5. If desired, change the memory and hard disk parameters assigned to the Branch Repeater VPX virtual machine to match one of the supported, non-default configurations listed in Figure 7-7.These parameters are adjusted on the screen. See Figure 7-46.

Figure 7-46 Adjusting memory and disk allocation.

7-32 November 14, 2012


6. Start VPX. Go to the Branch Repeater VPX console. Press the start button. See Figure 7-47.

7. Configure VPX. This procedure depends on whether you are running the Release 6.0 or 6.1 Repeater VPX software.

8. (Release 6.0 only.)When prompted for a login (in the console window), log in with login “admin” and password “password”.

b. Set the accelerated bridge (apA) IP parameters using the following com-mand (your IP/netmask values will vary):set adapter apa -ip 172.16.0.213 -gateway 172.16.0.1 -netmask 255.255.255.0

c. If the Primary port is used, set its IP parameters with the command (your IP/netmask parameters will vary). This IP must be different from the one assigned to apA:set adapter primary -ip 172.16.1.222 -gateway 172.16.1.1 -netmask 255.255.255.0

d. restart the virtual machine to allow the parameters to take effect with the command:restart

9. (Release 6.1 only.) When a Repeater VPX virtual machine is started for the first time, it automatically run the “Deployment Wizard.” This wizard asks questions about the deployment mode: Inline, WCCP, or “PBR” (virtual inline), or “Setup Using Web UI.” Select “Setup Using Web UI.” On the next screen, enter the IP, netmask, and gateway for the apA interface, and select “Finish.”

10. Continue configuration from the Web UI using the URL of either apA or Pri-mary IP. For example (your address will vary): https://172.16.0.213

Log in with username “admin” and password “password”

Figure 7-47 Starting the Branch Repeater VPX virtual machine

Note: In systems with a Primary port, do not specify “-gateway” on both the Primary and apA ports. Choose one or the other.



11. On the “Quick Installation” page, perform a quick installation. See Section 3.3.6.

12. Enable bridging, using the “Enable Bridging” link. This will pop up a warning dialog box to remind you that if the two accelerated bridge ports are both connected to the same virtual or physical Ethernet switch, network loops will be created which may bring down your entire network. Check your network assignments and cabling, and if the two network devices are connected to different switches, press “OK.” Otherwise, shut down the Branch Repeater VPX virtual machine and fix the network assignments first.

13. Complete the installation based on the instructions in the Chapter 3, steps 31 and up.

7-34 November 14, 2012


7.7.1 Configuring Advanced VMware Features

7.7.1.1 VLAN Support

Branch Repeater VPX accelerates VLAN traffic automatically, without special configu-ration, and is thus compatible with VLAN trunking. To use VLAN trunking in a VPX deployment, the VMware server needs to have VLAN trunking enabled on the two apA bridge ports (apA.1 and apA.2), whose VLAN IDs need to be set to “All(4095).” This can be done in the vSphere Client. Highlights of this process are shown below.

Note: These instructions assume that you have a basic familiarity with VMware vSphere. Most of this procedure uses the vSphere Client, and details of its operation may vary with new releases of the vSphere software. The VMware documentation should be considered definitive in this regard; the procedure below shows the desired results and one example of achieving them.

Figure 7-48 Enabling VLAN trunking.



Figure 7-49 Enabling VLAN trunking, continued.

Figure 7-50 Enabling VLAN trunking, continued.

7-36 November 14, 2012


7.7.1.2 Larger Disks

To support the 500 GB Branch Repeater VPX configuration, the datastore must be configured to support a maximum file size of 512 GB or more. This requires that the datastore have a block size of 2 MB or greater.

In VMware ESXi 4.1, this is done by:

1. Deleting any existing virtual machines on the server using vSphere Client.

2. Delete the existing datastore (see Figure 7-52).3. Creating a new datastore with a block size of 2 MB or greater (see Figure 7-53 and

Figure 7-54.

4. Creating a 500 GB virtual disk (see Figure 7-55).

Figure 7-51 Enabling VLAN trunking, continued. Both apA bridge ports need to support trunking with the “All(4095)” option.

Figure 7-52 Deleting the default datastore



In ESX 4.1, the procedure is done manually, as follows:

1. Boot the ESX 4.1 installation DVD.

Figure 7-53 Adding a new datastore.

Figure 7-54 Setting the datastore block size.

Figure 7-55 Creating a 500 GB virtual disk.

7-38 November 14, 2012


2. Select the ESX installation as “Install ESX in graphical mode”

3. After getting the “ESX Installer” welcome screen, Press “Ctrl+Alt+F2” to switch to the shell.

4. Run the command:

ps | grep Xorg

5. Kill the Xorg process. For example, if the PID of Xorg is 582, run:

kill 582

6. After killing the Xorg process you will get the message “Press <return> to reboot”, Instead, press “Ctrl+Alt+F3” to go to another console and continue working without rebooting.

7. Run the command:

cd /usr/lib/vmware/weasel

8. Edit fsset.py with the command (these instructions assume you are familiar with vi):

vi fsset.py

9. Search for “class vmfs3FileSystem(FileSystemType):”

10. Change the “blockSizeMB” parameter to 2 (default should be shown as 1)

11. Save the file and exit vi.

12. Go to the root directors and run weasel:

cd /

/bin/weasel

13. Proceed with the normal installation process

14. Now you should be able to create virtual disk size of 500GB, as shown in Figure 7-55.

7.7.1.3 VMware Guest Customization

VMware guest customization is supported for some Branch Repeater parameters, but not all.

Supported parameters:

• Hostname• Primary adapter network settings• Primary DNS configuration

Not supported

• Accelerated bridge (apA) networks settings• Domain name, Area, Location, Secondary DNS, Tertiary DNS, and DNS search

path• Branch Repeater-specific parameters such as bandwidth limits.



7.7.2 VMware Guest Customization Procedure

1. Start with a Branch Repeater VPX virtual machine that has been configured to include the Primary port as well as apA. Verify that the Ethernet port con-figuration matches that in Figure 7-56.

2. Convert the VPX virtual machine into a template, as shown in Figure 7-57

Figure 7-56 Verify Ethernet port assignments.

Figure 7-57 Convert to template

7-40 November 14, 2012


3. Deploy a new virtual machine from the template, as shown in Figure 7-59.

4. On the “Deploy Template” screens, name the new VPX virtual machine, select “Thick Format” for virtual disks, and select “Customize using the Customiza-tion Wizard.”

Figure 7-58



5. In the Customization Wizard, enter a hostname and a dummy domain name for the new VPX virtual machine, as shown in Figure 7-59.

6. The value on the Time Zone screen is ignored by Branch Repeater. Accept the default and go on to the next screen.

7. On the “Network” screen, select “Custom Settings” if you need to change the Primary port IP address from the one in the template. You will assign this address (plus a subnet mask and default gateway) to NIC3. Do not change NIC1 or NIC2.

Figure 7-59 Customization wizard.

7-42 November 14, 2012


8. On the “DNS and Domain Settings” screen, enter the DNS address used by Branch Repeater VPX in the “Primary DNS” field. Leave the “Secondary DNS” and “Tertiary DNS” paths blank. Add a dummy domain such as “test.com” to the “DNS Search Path.” See Figure 7-60.

9. Click “Next” and “Finish” to exit the Guest Customization Wizard.

10. In the Deploy Template Wizard, uncheck the “Power on the virtual machine after creation” box.

11. Double-check network assignments before powering up the virtual machine. Attaching both apA ports to the same virtual or real switch will cause network loops.

12. Start the virtual machine and continue configuration from Step 6 in Section 7.7.

Figure 7-60 Setting the DNS server


7.8 Initial Installation, Hyper-V


7.8.1 Hyper-V Server Requirements• The server’s processor must support Intel Virtualization Technology.• The server must run 64-bit Windows 2008 R2 SP1 (Standard, Enterprise, or Data-

Center Editions), with a full installation (not a Core installation), and the Hyper-V component enabled.

• Minimum system configuration is 4 GB RAM, 200 GB hard drive, and 2 CPU cores.• Two physical Ethernet NICs are required; three are recommended. The procedure

below uses three NICs.

7-44 November 14, 2012


7.8.2 Configure the Hyper-V Server

1. Log into the server as Administrator, either at a keyboard/VGA console or via the NIC you will use for management (not at one of the ports you will use for the accelerated bridge).

2. Configure the accelerated bridge as follows:a. Select “Virtual Network Manager.. New virtual network.. External” and press

the “Add” button.b. Name the new virtual network “apA Network 1” and select which physical NIC

to map it to, and press “OK” to apply the changes.c. Press “Yes” if a pop-up complains that connectivity may be lost.

Figure 7-61 Configuring Ethernet ports using Hyper-V Manager.



3. Repeat step 2 for the other accelerated bridge port, but calling it “apA Network 2” and connecting it to a different physical port.

7.8.3 Install the Branch Repeater VPX Virtual Machine

Branch Repeater VPX is a standard Hyper-V virtual machine. It is downloaded from MyCitrix in the usual way. It may be distributed as a ZIP archive to reduce download time.

1. Download and unzip the Branch Repeater VPX distribution from MyCitrix.2. From the Hyper-V Manager, use “Import Virtual Machine..” to browse to the loca-

tion of the virtual machine and import it. 3. Select the virtual machine, right-click, and choose “Settings..”4. In the Hardware list, select the first network adapter in the list. Go to the “Net-

work” pull-down menu and select “apA Network 1.” Make sure that the “Enable spoofing of MAC addresses” box is checked. If not, select it and apply the changes.

5. Repeat for the second network adapter in the list, assigning it to “apA Network 2.”6. Allocate disk space to the virtual machine by selecting a local hard drive, pressing

the “Edit” button, and using the “Edit Virtual Hard Drive Wizard” to increase the allocation to one of the supported sizes, using the “Expand” option.

7. Allocate RAM space to the virtual machine by selecting “Memory” and adjusting

Figure 7-62 Installing the Branch Repeater VPX virtual machine.

7-46 November 14, 2012


the memory allocation to one of the supported sizes.

8. (Optional.) Define the management port by selecting “Add Hardware” followed by “Network Adapter” and pressing the “Add” button. This will create a third interface that can be named “Primary Network 3.” Make sure the “Enable spoofing of MAC addresses” box is checked.

9. Right-click on the Branch Repeater VPX virtual machine and select “Connect..”

Figure 7-63 Configuring disk and RAM allocation.


7.9 Additional Configuration

10.Click on “Action..” “Start” to start the virtual machine.

11.When a Repeater VPX virtual machine is started for the first time, it automatically run the “Deployment Wizard.” This wizard asks questions about the deployment mode: Inline, WCCP, or “PBR” (virtual inline), or “Setup Using Web UI.” Select “Setup Using Web UI.” On the next screen, enter the IP, netmask, and gateway for the apA interface, and select “Finish.”

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

13. Perform a quick installation as described in Section 3.3.6.

7.9 Additional ConfigurationFor additional configuration instructions, see the other chapters in this user’s guide.

Figure 7-64 Starting the VPX virtual machine.

7-48 November 14, 2012

Chapter 8

Repeater on NetScaler SDX

8.1 Introduction

Repeater on NetScaler SDX creates a maximum-performance WAN accelerator by combining three Citrix technologies in one chassis: the Xen hypervisor, the NetScaler load-balancer, and Branch Repeater, to accelerate WAN links of up to 2 gbps.

Repeater on NetScaler SDX (called “Repeater SDX” for short), supports up to eight virtual Repeater appliances, based on the Repeater VPX product (see Chapter 7). These virtual Repeaters are typically configured as identical, load-balanced instances.

While the rest of the Branch Repeater product line uses 1 gbps Ethernet ports exclu-sively, the Repeater SDX uses both 1 gbps and 10 gbps ports for maximum perfor-mance and flexibility.

8.1.1 Use Cases

Repeater SDX is recommended for installations where a Repeater 8800 is not enough. Typical uses include:

• Hub-and-spoke links with a hub speed of greater than 155 mbps.• Data replication over high-speed Internet connections rather than leased lines.• Wherever you need the highest possible performance.

8.1.2 Hardware Platforms

Repeater SDX uses two different hardware platforms:

• Repeater SDX 310, 500, and 1000 use the NetScaler 11505/13505 SDX platform.• Repeater SDX 1500 and 2000 use the NetScaler 17555/19555 SDX platform.

8.1.3 Software Platforms

Repeater SDX includes the following:

• A Xen hypervisor.• A NetScaler VPX load-balancer.• Multiple Repeater VPX instances.

Note: This chapter is valid only for Branch Repeater software release 6.x running on the Repeater on NetScaler SDX models 310, 500, 1000, 1500, and 2000.


8.2 Installing the Appliance

• A service GUI that looks like the Repeater GUI, but manages and monitors all Repeater instances simultaneously,

These three components of Repeater SDX are configured separately.

8.1.4 Acceleration Features

While most Repeater features are present on Repeater SDX, the following Repeater features and GUI elements are not present:

• The Quick Installation page• Group Mode

8.2 Installing the ApplianceSee the Repeater 6.0 Quick Start Guide: Repeater 500/1000/1500/2000 for NetScaler 11505/13505/17555/19555 SDX Platform at http://support.citrix.com/arti-cle/CTX133358.

8.3 Configuring the ApplianceSee the Citrix Repeater 500/1000/1500/2000 on NetScaler SDX Administration Guide at http://support.citrix.com/proddocs/topic/branch-repeater/ns-brsdx-admin-wrap-per-con-60.html.

Warning. Upgrade your SDX system only with releases approved for use in Repeater SDX. Ordinary releases will not work.

8-2 November 14, 2012

Chapter 9

Configuration Reference

This chapter describes the browser-based user interface of the Citrix Repeater and Branch Repeater Appliances.

Different Citrix acceleration products have different user interfaces:

• Repeater Appliances and Branch Repeater Appliances use the same browser-based interface, documented in this chapter.

• Branch Repeater with Windows Server has its own MMC (Microsoft Management Console) user interface, described in the Branch Repeater With Windows Server Installation and User’s Guide.

• The Repeater Plug-in has its own simplified user interface, which is covered in Section 6.6.

9.1 Logging Into the UIThe 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 “Dashboard” page (see Section 9.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 9.4.1.3.

Link bar. The left edge of this page (and every other page) contains links to the other pages. The link bar is divided into five categories:

1. an unlabeled top-level category (Section 9.2).2. “Monitoring” (Section 9.3).3. “Configuration” (Section 9.4).4. “Reports” (Section 9.5).5. “System Maintenance” (Section 9.6).

These categories can be expanded to show the links to individual pages, or collapsed.

An “Alert(s)” link also appears on the top row if warnings or errors have been detected by the system. This link takes you to the Alerts page (see Section ).


9.2 “Command Menu” Pages


9.2.1 “Dashboard”

The dashboard shows you the status of the entire appliance at a glance. It has graphs for incoming and outgoing traffic, top applications by WAN volume, top service classes by compression ratio, WAN throughput by traffic-shaping policy, and more. By default, the page updates every minute, but this can be changed by pressing the “Customize” button.

Most features of the dashboard are disabled until you define your appliance’s links.

9.2.1.1 “Aggregate Link Throughput” Graph

This graph shows the incoming traffic (“WAN to LAN”) and outgoing traffic “LAN to WAN”).

The LAN-side and WAN-side traffic are shown in different colors. When on compres-sion, caching, or application acceleration is going on, the LAN-side traffic and the WAN-side traffic are essentially identical, because the appliance is not modifying the data as it passes through. Compression and caching reduce the amount of WAN-side traffic.

Figure 9-1 “Dashboard” page

9-2 November 14, 2012

Chapter 9. Configuration Reference

9.2.1.2 “Appliance Status” Table

This table gives a grab bag of information about the appliance. We recommend that you minimize this table in normal use, because the graphs are generally more useful.

The statistics in this table are self-explanatory.

9.2.1.3 “Top Applications by WAN Volume” Graph

This graph shows the top ten applications, ranked by WAN data volume, measured over the last hour.

9.2.1.4 “Top Service Classes by Compression Ratio” Graph

This graph shows the top compressed service classes, ranked by compression ratio. Note that service classes are not identical to applications. (There are hundreds of applications and only about 20 service classes by default.)

The compression ratio is dependent on the amount of long-term redundancy in the data streams, and tends to increase over time as the appliance’s compression history fills.

9.2.1.5 “Top ICA/CGP Applications by WAN Volume” Graph

This graph is similar to the “Top Applications” graph but considers only Citrix XenApp/XenDesktop published application data over the last hour.

9.2.1.6 “Traffic Shaping: WAN Throughput” Graph

This graph shows the predominant traffic-shaping policies being applied to the WAN traffic in the last hour. There are separate graphs for incoming (WAN to LAN) and out-going (LAN to WAN) traffic.



9.2.2 “Features”

This page has enable/disable toggles for the appliance’s features, plus a master enable/disable toggle called “Traffic Processing.”

In normal use, this page is helpful mostly for disabling features, since many features require more configuration than simply toggling their state from “disabled” to “enabled.” Most features should be enabled on the relevant page under the “Configu-ration” menu.

9.2.2.1 Traffic Processing

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

9.2.2.2 Traffic Acceleration

This toggle enables and disables the acceleration engine.

9.2.2.3 Traffic Shaping

This toggle enables and disables the traffic-shaping engine.

9.2.2.4 CIFS Protocol Optimization

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

9.2.2.5 Group Mode

Can be used to disable group mode, if enabled. See Section 9.2.2.5 for group-mode configuration.

Figure 9-2 Part of the “Features” page

9-4 November 14, 2012


9.2.2.6 High Availability

Can be used to disable high-availability mode, if enabled. See Section 9.2.2.6 for high-availability configuration.

9.2.2.7 ICA Multi-Stream

Enables ICA multi-stream acceleration support. If enabled, multi-stream ICA sessions will be negotiated when both the client and server are multi-stream-enabled. Other-wise, single-stream ICA sessions will be used.

If multi-stream, multi-port ICA is enabled on your XenApp servers, you must also modify the “ICA” service class to include the additional ports you have defined for multi-port mode.

9.2.2.8 MAPI Cross-Protocol Optimization

Allows MAPI session data to match non-MAPI session data in the compressor.

9.2.2.9 SCPS

SCPS is a TCP variant used in satellite communication and similar applications. The Appliance can accelerate SCPS connections if this option is selected.

The main practical difference between SCPS and the default Appliance behavior is that SCPS-style “selective negative acknowledgements” (SNACKs) are used instead of standard “selective acknowledgements” (SACKs). These two methods of enhancing data retransmissions are mutually exclusive, so if the Appliance on one end of the connection has SCPS enabled and one does not, retransmission performance will 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.

9.2.2.10 Secure Partner

Duplicates the functionality of the “Partner State” toggle on the “Configuration: Secure Partners” page. See Section 9.4.9.

9.2.2.11 SNMP

Duplicates the functionality of the “SNMP Status” button on the “Logging/Monitoring: SNMP” tab. See Section 9.4.7.7.

9.2.2.12 SSH Access

Duplicates the functionality of the “SSH Access” Enable/Disable button on the “Config-uration: Administrator Interface: SSH Access” page. See Section 9.4.1.5.

9.2.2.13 SSL Optimization

Duplicates the functionality of the “SSL Optimization” Enable/Disable button on the “SSL Encryption” page. See Section 9.4.12.



9.2.2.14 Syslog Support

Duplicates the functionality of the “Send to Syslog Server” checkbox on the “Configu-ration: Logging/Monitoring: Syslog Server” tab. See Section 9.4.7.6.

9.2.2.15 User Data Store Encryption

Duplicates the functionality of the “Enable Encryption” button on the “Configuration: SSL Encryption’ page. See Section 9.4.12.

9.2.2.16 WCCP

Duplicates the functionality of the “Enable” button on the “Configuration: Advanced Deployments: WCCP” tab. See Section 9.4.2.1.

9.2.3 “Quick Installation”

The “Quick Installation” page allows a complete single-page installation of many appliances, and a partial installation for most other appliances.

Figure 9-3 “Quick Installation” page

9-6 November 14, 2012


Additional configuration will be required if any of the following are true:

• The appliance is not using inline mode.• Your appliance has dual accelerated bridges (apA and apB).• The appliance is part of a high-availability or group-mode pair.• You plan to use SSL acceleration or hardboost.• You need to make changes to the default traffic-shaping policies.

The fields in the quick installation are:

1. Adapter. For most appliances, this is “apA,” the accelerated bridge. Dual-bridge systems will allow you to select “apB” instead.

2. IP Address, Gateway, Netmask. These will already be configured (from the LCD front-panel installation step), but you can change them if desired.

3. Primary/Secondary DNS IP Address. Lets you specify a primary and backup DNS server.

4. NTP Time Server. Allows you to specify an NTP time server to keep your appli-ance’s clock synchronized. Highly recommended.

5. Date/Time. If you cannot use an NTP time server, the date and time can be set manually here.

6. Local Time Zone. Specify your time zone here.7. Citrix License Type. Gives you a choice between “Local License” and a network

license that matches your hardware. Legacy (release 5.x) licenses are local licenses; new licenses are generally network licenses.

8. License Server Address. You must specify a license server when using network licenses. You can use either an IP address (such as 172.16.0.44) or a hostname (such as license_server.example.com).

9. Licensing Service Port. If your license server uses a port different from the default value of 27000, specify it here.

10.Receive (Download) Speed. Use 95% of your nominal WAN receive rate.11.Send (Upload) Speed. Use 95% of your nominal WAN send rate.12.WAN-side Adapter. This will be either apA.1 or apA.2, depending on which port

the Ethernet cable to your WAN is plugged into. (Dual-bridge systems might use apB.1 or apB.2.)

13.Perform Quick Install. Press the “Install” button to perform the installation. 14.Wait for System to Restart. After the system restarts, continue with your con-

figuration if necessary. Otherwise, your appliance is configured and operational.


9.3 “Monitoring” Pages

9.2.4 “Logout”

Clicking the “logout” link will pop up a dialog box asking if you want to end your ses-sion. If you end your session.


9.3.1 “Monitoring: Citrix (ICA/CGP)”

This page allows you to monitor total ICA traffic (in the sending direction only) and the list of ICA connections.

9.3.1.1 “ICA Connections” Tab

The “ICA Connections” tab lists all the currently open Citrix (ICA/CGP) connections, including with the client computer’s name and the name of the XenApp published application or XenDesktop desktop. The ICA connection list is similar to the main “Connections” list (Section 9.3.3) and can be filtered or sorted in the same way.

Figure 9-4 “Logout” dialog

Figure 9-5 “ICA Connections” Tab.

9-8 November 14, 2012


9.3.1.2 “ICA Statistics” Tab

The “ICA Statistics” tab summarizes XenApp/XenDesktop statistics: by ICA packet priority, by protocol type, by stream type, and by ICA virtual channel.

Figure 9-6 “ICA Statistics” Tab.



9.3.1.3 “Acceleration Graphs” Tabs

The “Acceleration Graphs” tab shows the sender-side behavior of accelerated XenApp/XenDesktop traffic. Non-accelerated traffic is not shown. Timescales for these graphs are selectable between 60 seconds and one month.

The real-time effect of compression can be estimated by comparing the WAN-side throughput to the LAN-side throughput. (Compression reduces the WAN-side data volume.)

Figure 9-7 “Accelerated Graphs” Tab.

9-10 November 14, 2012


9.3.2 “Monitoring: Compression”

The “Monitoring: Compression” page gives a real-time view of the multi-level com-pression engine, which automatically selects the optimum compression engine for the data being compressed.This graph can span one minute, one hour, one day, one week, or one month.

The compression engine dynamically selects between several algorithm. Each algo-rithm is called a “matcher.” The smallest compression engines have a relatively small compression history, and can match strings within a few thousand or tens of thou-sands of bytes of the current data. The “big matcher” can handle matches between 100 MB and several gigabytes in size, depending on the appliance model. Finally, the disk matcher can handle matches of almost arbitrary size.

Each matcher is color-coded. The graph is similar to the usage graph (Section 9.3.10), except only compressed traffic is shown. The vertical axis gives the effective throughput of the compressed data, which can be many times greater than the WAN data rate. Compression and decompression are shown separately.

• Raw data is not compressed at all. It has a compression ratio of 1:1.• The micro matcher and little matcher have compression ratios that typically fall in

the range of 1:1 to 10:1.• The big matcher usually gives memory-based compression ratios in excess of

10:1, and sometimes in excess of 200:1.• The disk matcher can give compression ratios up to 10,000:1.

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

Figure 9-8 “Monitoring: Compression” page.



• If enough data has gone by, the first-pass copy will no longer be in compression history when the object is sent again, and second-pass compression ratios will not be seen. This depends on the size of the compression history and the number of partner Appliances. The total amount of disk-matcher compression history is 100 GB or more on all models of Appliance.

• If the Appliance is communicating with many different Acceleration Partners, this limits the amount of compression history that any one unit can have.

9.3.3 “Monitoring: Connections”

This page consists of a list of accelerated connections and a filter specification. The list of accelerated connections identifies the IP and port numbers for the two endpoint systems, gives information about the duration and data transferred in the connection so far, and identifies the other Appliance (or Repeater Plug-in) in the connection. Clicking on the IP address of a Acceleration Partner Appliance takes you to the man-agement interface of that Appliance.

Figure 9-9 “Monitoring: Connections” page (accelerated connections).

9-12 November 14, 2012


9.3.3.1 Selecting Which Accelerated Connections to Show

In a busy system, with hundreds or thousands of connections, it can be difficult to find the information you are looking for. You have two methods of dealing with this information:

Sorting. Clicking on the column headers will sort the connections by the value in that column, in ascending order. Clicking the header again will sort the columns in descending order.

Filtering. The filter at the top of the page can be used to hide all connections that do not pass the stated tests. Filtering can be performed on:

• Source IP and port range• Destination IP and port range• Connection duration• Bytes transferred

• Connection state: opening (half-open), open, closing (half-closed) closed, all.

Note: Half-open and half-closed connections may be listed as “accelerated connections.” The accelerated vs. non-accelerated status of a connection is generally not known until the connection is fully open (that is, until the SYN-ACK packet is received by the system that sent the SYN packet). Half-open connections can be identified because they have a “Acceleration Partner” of “None” and a “Bytes Transferred” of “0”.

Half-open and half-closed connections can be filtered out of the list with the “Connection State” filter at the top of the page. Selecting “Open” will show only fully open connections.



9.3.3.2 “Unaccelerated Connections” Tab

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 left-most column. Placing the mouse pointer over this code will display an explanation of what the code means, and why the connection was unaccelerated.

Common reasons for non-acceleration are:

Figure 9-10 Unaccelerated connections.

Figure 9-11 Non-acceleration reasons (Sheet 1 of 2).

Code DescriptionUR:1. Reason is unknownUR:2 No partner Acceleration unit was detectedUR:3 Routing asymmetry: the SYN packet did not pass through this unit.

UR:4Routing asymmetry: the SYN-ACK packet did not pass through this 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.

UR:11Connection failed both with and without acceleration options (destination not responding or responds with TCP reset).

UR:12Connection failed when acceleration options were attached, but succeeded without acceleration (firewall problem).

UR:13 This unit is between two other units and daisy-chaining is enabled.

9-14 November 14, 2012


9.3.3.3 Connection Details Page

The left-most column in the Accelerated Connection table is the “Details” column, containing links to per-connection information, as shown in Figure 9-10 through Figure 9-9.

The connection details start with WAN and LAN traffic graphs, continues with a table giving overall status of the connection, and concludes with a longer table giving detailed information about the connection.

UR:14:Maximum number of simultaneous partner Appliances has been 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.

UR:22No initial TCP handshake seen (often seen after a Acceleration unit is 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.

UR:25Group mode connection, but group-mode acceleration has been disabled.

UR:26 Plug-in connection is using invalid Signaling/Redirector IP address.UR:27 Cannot establish a signaling connection to partner.

Figure 9-11 Non-acceleration reasons (Sheet 2 of 2).



WAN/LAN graphs. These show only the traffic for the selected connection. Otherwise, they are the same as the usual throughput graph.

Detailed Connection Information table. See Figure 9-13. This table reports:

• Creation Time: the date and time when the connection was opened.• Uncompressed Bytes Transmitted: the amount of data transferred in the 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 9-12 Connection Details page. Top portion: graphs.

9-16 November 14, 2012


Detailed Per-Endpoint Information table. See Figure 9-14. This table is primarily for the use of Support and is not fully documented here. Some of the reported values are not always accurate. In particular, the RTT value uses a counter-intuitive 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.)

Figure 9-13 Connection Details page, “Detailed Connection Information” table.



• Total Payload Bytes: As above, but with headers and retransmissions removed from the calculation.

9.3.3.4 Flow Information

A “flow” consists of all the traffic flowing between a pair of Appliances. Clicking on the “i” link marked “Flow” will give information for the flow as a whole, as shown in Figure 9-15. The entries should be self-explanatory.

Figure 9-14 Connection Details page, “Detailed Per-Endpoint Information” table.

9-18 November 14, 2012


Figure 9-15 Flow information page.



9.3.4 “Monitoring: Filesystem (CIFS/SMB)”

9.3.4.1 “Acceleration Graphs” Tab

The “Acceleration Graphs” tab shows four graphs:

1. CIFS Accelerated Read Traffic, the total bandwidth from accelerated CIFS read requests. (Note that “read” vs. “write” is based on whether the CIFS command was a read or write command, and has nothing to do with the send/receive direc-tion as seen by the Appliance.)

2. CIFS Accelerated Write Traffic, the total bandwidth from accelerated CIFS write requests.

3. CIFS Saved Requests, the difference in bandwidth between the accelerated throughput and the throughput that would have been achieved without accelera-tion.

4. CIFS (SMB2) Requests Responded Locally, the bandwidth of requests serviced locally rather than passed on to the endpoint server, such as the bandwidth sav-ings from metadata caching.

Figure 9-16 CIFS acceleration graphs

9-20 November 14, 2012


9.3.4.2 “Connections” Tab

Connections. Clicking the “Connections” tab at the top of the page will cause a table of CIFS connections to be displayed. These are divided into accelerated and non-accelerated connections. Clicking the icon in the “Details” column will give detailed information about this CIFS connection.

“File Details” and Read/Write counters. When the Appliance is on the server side of the link, the “File Details” entry always reads “Not Available” and the read and write counters always read zero. Information about the connection can be obtained from the client-side Appliance.

The “Signed” column. Reports whether CIFS signing is in effect.

The “Reason” column. For so-called “non-accelerated” connections, a “Reason” column gives a code specifying why CIFS optimizations were not used. The reasons are one of these:

1. The connection uses the Vista SMB 2.0 format, and SMB 2.0 acceleration is not enabled.

2. CIFS optimizations are disabled on the Appliance.3. Security settings on the connection prevent optimization.4. The connection requires CIFS signing, which prevents optimization.5. CIFS optimization is disabled or not supported on the remote Acceleration unit.6. The CIFS “dialect level” is not supported.7. The connection is not using the negotiated protocol.

Figure 9-17 “Connections” tab.



9.3.5 “Monitoring: Logging”

The logging page shows system activity, including configuration changes and boot progress messages. See Figure 9-18.

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. Traffic shaping and classification are not logged.

Additional detail about acceleration is available by clicking the link in the left column of the entry. For example, if you click on the “System Status” entry, you get a System Status report that gives a second-by-second throughput graph and a table of other status data for the same minute.

Status reports for the system, flows, connections, and adapters are all similar, with performance graphs at the top and tables of related system objects and their status below. Arrows to the left and right of the graphs will give a report for one minute pre-viously or one minute later, respectively.

9.3.6 “Monitoring: Outlook (MAPI)”

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

9.3.6.1 Acceleration Graphs

The “Acceleration Graphs” tab shows the accelerated MAPI traffic for the last 60 seconds. The two graphs are “Read-Ahead Throughput,” showing the performance of traffic traveling from the Exchange Server to the Outlook client, and “Write-Behind Traffic,” showing traffic from the Outlook client to the Exchange server.

These graphs will look different on the two Appliances, and different from the main usage graphs as well, since they show movement into and out of the MAPI engine, not actual traffic on the WAN. The differences are caused by buffering.

Figure 9-18 “Monitoring: Logging” page.

9-22 November 14, 2012


9.3.6.2 Accelerated SessionsThis 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 9-19 “Acceleration Graphs” tab.

Figure 9-20 “Accelerated Sessions” tab.



9.3.6.3 Unaccelerated SessionsThis 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.

9.3.7 “Monitoring: Repeater Plug-ins”

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 9-23.

Figure 9-21 “Unaccelerated Sessions” tab.

Figure 9-22 Monitoring Repeater Plug-in.

9-24 November 14, 2012


9.3.8 “Monitoring: Secure Partners”

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

Figure 9-23 Detailed Plug-in Information

Figure 9-24 Peer Status command.



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.

9-26 November 14, 2012


9.3.9 “Monitoring: Server Load Indicator”

The “Monitoring: Server Load indicator” page shows a gauge using indicating the total load of the Appliance. Low load shows in the green region, high load in the yellow, and extreme load in the red.

Data rates on the LAN side, in terms of packets per second and bits per second, are also graphed. The appliance’s load tracks packet rates more closely than bit rates.

The LAN input queue latency over the last minute is also displayed. A high input queue latency indicates that the Appliance is becoming overloaded.

Figure 9-25 “Monitoring: Server Load Indicator” page



9.3.10 “Monitoring: Usage Graph”

The “Monitoring: Usage Graph” page shows real-time throughput graphs for the WAN and LAN sides of the Appliance’s acceleration engine. The graph defaults to a static display, but an auto-refresh mode can be selected by clicking the “Toggle” link. Click-ing 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 for-ward in time. See Figure 9-27.

The amount of time covered by the display varies from one minute to one month. The shorter timescales are useful when setting parameters such as bandwidth limits or service class rules; the longer timescales are useful for general monitoring.

Restarting the Appliance will cause all the graph data to be lost.

• The graph shows the traffic as seen by the acceleration engine. This means that only TCP traffic is shown, and it is not segregated by link; it shows global TCP traf-fic through the Appliance.

• Dark blue indicates accelerated “goodput,” or payload data.• Light blue indicates the overhead of accelerated connections: packet headers,

acknowledgement packets (ACKs), and retransmissions.• Orange indicates non-accelerated traffic.

Figure 9-26 “Monitoring: Usage Graph” page

Tabs at the top of the page allow you to select a timescale to display: the last minute, hour, day, week or month.

Accelerated Line Usage (light blue): Total accelerated line usage, including headers, ACK packets, and retransmitted packets.

Accelerated Goodput (dark blue): Payload data, excluding retransmissions and headers.

Non-Accelerated (orange): Non-accelerated TCP traffic (including data and overhead) Non-TCP traffic is not included in the graph.)

Compression is taking place during periods when the LAN traffic is higher than the WAN traffic. In the diagram above, a data stream of 250-300 mbps has been reduced by more than 500:1, to around 400 kbps.

9-28 November 14, 2012


• 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 “Configuration: Administrator Interface” page, which allows you so change the graphing features, including the frequency of update and whether separate graphs are shown for the sending and receiving direc-tions. See Section 9.4.1.6.

Clicking “Popup Graph” will create a new window containing a similar auto-refreshing throughput graph. See Figure 9-27.

9.3.11 “Monitoring: WCCP”

The “Monitoring: WCCP” page reports on the status of the Appliance’s WCCP inter-face. For each configured WCCP service group, it reports the accelerated pair used by that service group, the routers identified for that service group, the type of partner assignment (Hash or Mask), the connection mode (GRE or L2) used by the router, last contact time, connection status, and packets in and out.

The page is auto-updating and lags the actual state of the interface by only a few sec-onds.

Figure 9-27 Popup performance graph

Figure 9-28 “Monitoring: WCCP” page



Most of the fields are self-explanatory except for the “Status” field, which is described below:

Figure 9-29 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.

Disable interfaceThe accelerated interface defined for the service group has been disabled.

Bad subnet for interface

The accelerated interface has a network definition that contains no subnet portion (subnet works out to 0.0.0.0, usually due to the subnet field not being defined).

Internal problem Internal software error.

Service Group is disabled

The service group has been manually disabled on the WCCP Configuration page.

Acceleration is disabled

The service group does not operate when acceleration is disabled.

WCCP is disabled WCCP itself is disabled.

Contacting router No response has been received yet from the router.

Connecting to routerAt least one packet has been received from the router, and WCCP protocol negotiations are underway.

Connected to router Negotiation is complete and the WCCP interface is fully active.

Disconnecting from router

The Appliance is terminating its connection to the router, probably due to a user-initiated configuration change.

No response from router

The router has been completely unresponsive for at least five minutes

Router’s forward or return capability

mismatch

Cannot communicate with the router because the specified mode is not available. Usually means that the Appliance is configured for WCCP-L2, but the router does not support this mode.

Multicast discovering Attempting to find multicast service group partners.

Multicast failed to discover

No multicast group partners were found in the last five minutes.

Multicast shutdownThe multicast service group is no longer attempting to discover partners.

Router’s view has other cache

There is another WCCP device, such as another Appliance, using the same service group. We do not allow this.

9-30 November 14, 2012


9.4 “Configuration” Pages

9.4.1 “Configuration: Administrator Interface”

This page has a range of options relating to the browser-based and LCD front-panel interfaces It is divided into four eight tabs: Web Access, HTTPS Certificate, User Accounts, Radius, TACACS+, SSH Access, Graphing, and Miscellaneous.

9.4.1.1 “Web Access” Tab

Web Access Protocol. Selects between HTTP and secure HTTP (HTTPS).HTTPS is the default

HTTP/HTTPS Ports. Sets the port used for each protocol. The non-selected protocol is greyed out. To access it, select the protocol, press “Update,” and then change the port number. Setting the port numbers to zero will disable browser-based access (re-enabling browser-based access will require the use of the serial interface or the command-line interface).

HTTP Forwarding to HTTPS. If HTTPS is the selected protocol, attempts to reach the interface via HTTP will result in an redirect to the correct protocol and port.

Router assignment capability mismatch

There is a mismatch between the configured router assignment and the actual capabilities of the router. For example, if Auto is selected, and communication with the first connected router caused the “Hash” method to be selected, if a subsequent router does not support “Hash,” this status message will be given.

Router is off-net and appliance’s gateway

is invalid

Packet forwarding cannot take place because the appliance’s gateway is invalid (not on the same subnet as the appliance).

Service group had socket send error

Internal software error. Please report this event to Support.

Figure 9-30 “Web Access” Tab

Figure 9-29 WCCP status messages (Sheet 2 of 2)



9.4.1.2 “HTTPS Certificate” Tab

HTTPS SSL Certificate, HTTPS SSL Private Key. These boxes allow you to paste in your own certificate and private key for SSL security, which is used by HTTPS. The Appliance is delivered with a default SSL key and certificate, which is not particularly secure. To replace it with your own key and certificate, generate these using your organization’s standard procedure, then paste them into the boxes on the UI page and press the “Update” button.

9.4.1.3 “User Accounts” Tab

These users accounts are maintained locally by the Appliance. There are two types of accounts: Admin and Viewer.

Admin accounts allow the user to view all pages and modify all settings.

Viewer accounts allow the user to see only the Main page and pop-up performance graphs.

You can create as many accounts as you like.

Figure 9-31 Configure Settings: UI page, HTTPS Certificate tab

Figure 9-32 “User Accounts” Tab

9-32 November 14, 2012


The menu page is self-explanatory. Changes take effect as soon as the “Update”, “Delete”, or “Add” buttons are pressed.

9.4.1.4 “RADIUS” and “TACACS+” Tabs

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.

Note on RADIUS authentication. Radius authentication will succeed 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 on TACACS authentication. Administrative privileges are granted if the TACACS user has privilege level 15. Lower levels will be granted viewer access.

Figure 9-33 RADIUS Authentication Tab

Figure 9-34 TACACS+ Authentication Tab

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.



9.4.1.5 “SSH Access” Tab

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 10). 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.

9.4.1.6 “Graphing” Tab

This tab controls the graphing functions of the acceleration engine, which covers the graphs on the “Monitoring” pages but not those on the “Reports” pages or the Dash-board, which are configured separately.

Display WAN Side Graph/Display LAN Side Graph. The data flow is not identical on the LAN side of the Appliance and the WAN side. The differences between the two flows can provide useful information. For example, the difference between accelerated line usage and goodput should be very low on the LAN side, because LANs usually (but not always) have a low packet-loss rate. But if there is a problem with the local LAN (a failing switch, for example, or a port accidentally configured to half-duplex), losses may be high. By default, both graphs are shown.

Combine Send/Recv Graphs. By default, send and receive traffic are added together, but they can be displayed separately. This is useful on busy systems with traffic moving in both directions.

Autoscale Graphs. By default, bandwidth graphs are scaled automatically, but they can be scaled to user-specified limits.

Figure 9-35 Security: Manage Users page

Figure 9-36 “Graphing” tab

9-34 November 14, 2012


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.

9.4.1.7 “Miscellaneous” Tab

Lock Changes via LCD. Checking this box prevents system settings from being updated via the front-panel interface. By default, the front-panel is not locked.

Max Connections Shown on Connection Page. A busy system may have thousands of open connections. The default is to show the first 800. This may be set to any value desired.

GUI Session Timeout. If the Web interface is idle for more than this time (in minutes), you will have to log in again. Setting the value to zero will disable session timeouts.

CLI Session Timeout. If the command-line interface is idle for more than this time (in minutes), you will have to log in again. Setting the value to zero will disable session timeouts.

Figure 9-37 Configure Settings: UI page, Miscellaneous tab



Login Failure Limit. If an invalid password is given more than this many times in a row, you will not be able to login until the “login failure lockout period” has expired.

Login Failure Lockout Period. Logins are disabled by this many seconds if the “login failure limit” has been exceeded.

Show SSL Connection Help Guide. Enables some online help text at the bottom of SSL-acceleration related pages. Disabled by default. Because this User’s Guide has much more comprehensive procedures, this help guide is not recommended.

9.4.2 “Configuration: Advanced Deployments”

This page has the configuration for advanced deployment modes: WCCP, high-avail-ability, group mode, and proxy mode.

9.4.2.1 “WCCP Configuration” Tab

This page allows WCCP mode to be configured. In WCCP mode, the router sends data to the Appliance, which returns it after processing to the router. Both L2 and GRE transport are supported.

See Section 4.13 for the procedure for setting up your router and Appliance for use with WCCP.

A single Appliance can be shared by in WCCP mode, which is convenient for sites with asymmetrically routed links. These routers can all be in a single service class or in dif-ferent service classes. A given service class supports either multicast or unicast oper-ation, 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-

Figure 9-38 “WCCP Configuration” tab

9-36 November 14, 2012


onds) and stop sending packets to the Appliance. Instead, it will send them directly to the next-hop router.

• New WCCP Service Group. Opens a dialog box on the right-hand edge of the screen.

• Id. This is the service group number, which is also used by the router. Must not conflict with other WCCP devices on the local network. The default value of 51 is usually adequate.

• Enabled. This allows individual service groups to be enabled or disabled, in 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 packet return is only user-selectable when the Router Communication parameter (below) is set to “Multicast.”

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



9.4.2.2 “High Availability (HA)” Tab

This page allows you to set up Appliances as high-availability pairs, so that if one unit fails, the other will take over.

High Availability Status: One of Standalone, Primary, or Secondary. A standalone unit is not part of an HA pair. A primary unit is actively handling accelerated connections. A secondary unit is idle, ready to take over if the primary unit fails.

Partner High Availability Status: Status of the HA partner, if present.

SSL Common Name: Uniquely identifies this Appliance. You type this string into the “Partner SSL Common Name” field on your HA partner Appliance.

Virtual VIP Configuration: The virtual IP address used to manage the pair as a unit is not set here, but on the “Configure Settings: UI” page. A link is provided here.

VRRP VRID: This identifies the HA pair according to the VRRP (Virtual Router 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.

Figure 9-39 Configure Settings: High Availability page

Note: pressing the “Update button” will terminate all open TCP connections.

9-38 November 14, 2012


9.4.2.3 “HA Partner Info” Tab

Lists information about the HA partner unit, if configured

9.4.2.4 “HA VIP Address” Tab

Repeats the VIP information from the “Configure Settings: Network Adapters: IP Addresses” tab.

Figure 9-40 “HA Partner Info” Tab.

Figure 9-41 “HA VIP Address” Tab.



9.4.2.5 “Group Mode” Tab

Group mode is a means for allowing two or more redundant links to be shared by two or more inline Appliances, with no requirement that all the packets for a given con-nection pass through the same Appliance.

Group mode and the fields on the “Group Mode” page are fully explained in Section 4.15.

Figure 9-42 “Group mode” tab.

9-40 November 14, 2012


9.4.2.6 “HA/Group Mode SSL Certificates” Tab

When an Appliance is a member of a high-availability pair or group-mode group, these certificates and keys are used to authenticate each other.

Private keys and certificates are factory-installed, but can be replaced, if desired. Press the “Edit” button, and paste the new certificates and key in the boxes provided, replacing the old ones, then press “Update.”

9.4.2.7 “Proxy” Tab

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.

Figure 9-43 “HA/Group Mode SSL Certificates” tab.

Figure 9-44 Proxies page.



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 9-45.

A proxy entry requires two IP addresses: the IP address of the server and the local VIP address that you assign to the server.

Figure 9-46. 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.22.0.2.

This takes care of connections initiated by the inline site. But the reverse connection “ftp Beta” requires its own configuration, since the packets will not flow through the Appliance-A unless they are sent to it via a virtual IP address. Another virtual IP entry must be configured, this time pointing to the server on the remote network. This is shown in Figure 9-47, and corresponds to Case 3 in Section 4.22.0.2, and illustrates a general point about proxies, which is that the target system does not have to be on the same network as the Appliance. See Figure 4-56.

The final example, in Figure 9-48, shows proxy configuration where neither unit is inline. This corresponds to Case 4 in Section 4.22.0.2.

Figure 9-45 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.

9-42 November 14, 2012


Figure 9-46 Proxy configuration, allowing Network B to access Alpha and Anvil.

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.

ApplianceMgmt Addr: "Appliance-A" 10.0.0.150VIP Addr: "Alpha-Proxy" 10.0.0.152VIP Addr: "Anvil-Proxy" 10.0.0.153

System "Alpha"10.0.0.51

System "Anvil"10.0.0.60

System "Beta"172.16.0.1

ApplianceMgmt Addr: "Appliance-B" 172.16.0.200

Network A: 10.0.0.x Network B: 172.16.0.x

WAN



Figure 9-47 Proxy configuration, allowing Network A to access “Beta.”

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.

ApplianceMgmt Addr: "Appliance-A" 10.0.0.150VIP Addr: "Beta-Proxy-A" 10.0.0.154




ApplianceMgmt Addr: "Appliance-B" 172.16.0.200VIP Addr: "Beta-Proxy" 172.16.0.201


9-44 November 14, 2012


Figure 9-48 Proxy configuration with neither site inline.

Figure 9-49 Appliance-A configuration. The third entry is the first part of a VIP-to-VIP proxy between Appliance-A and Appliance-B.

ApplianceMgmt Addr: "Appliance-A" 10.0.0.150VIP Addr: "Alpha-Proxy" 10.0.0.152VIP Addr: "Anvil-Proxy" 10.0.0.153VIP Addr: "Beta-Proxy-A" 10.0.0.154




ApplianceMgmt Addr: "Appliance-B" 172.16.0.200VIP Addr: "Beta-Proxy" 172.16.0.201VIP Addr: "Alpha-Proxy-B" 172.16.0.202VIP Addr: "Anvil-Proxy-B" 172.16.0.203




9.4.3 “Configuration: Application Classifiers”

The “Configuration: Application Classifiers” page defines all the applications recog-nized by the Branch Repeater classifier.

The classifier uses application definitions to divide the traffic into protocols and appli-cations. This is used to create reports and to set traffic-shaping policies through the service-class mechanism. A great many applications are already defined, and you can define more as needed.

Application Group pull-down menu. Applications are divided into groups, and by selecting one from the “Application Group” pull-down menu, you can restrict the dis-play to the members of the selected group.

Figure 9-50 Appliance-B configuration. Additional VIP addresses have been defined for Alpha and Anvil.

Figure 9-51 Part of the “Configuration: Application Classifiers” page.

9-46 November 14, 2012


Only show user modified settings checkbox. This checkbox allows you to show only applications that differ from the defaults, whether by being added or modified.

Auto-discover Citrix published applications checkbox. This option allows any Citrix published applications seen in the data stream to be added to the application list automatically. Once discovered, they will show up in reports and can be used for traffic-shaping policies.

Expand All/Collapse All buttons. In the collapsed state, just the application names are displayed. Otherwise, their definitions are shown as well.

Create button. Used to create a new application.See Figure 9-52. The procedure for creating a new application is described in Section 4.7.

Edit button. Allows an existing application to be altered. This process is essentially the same as creating a new application.

Delete button. Deletes an application.

9.4.4 “Configuration: Licensing”

A license file must be installed before your Appliance will accelerate connections. License files are generally obtained on MyCitrix. See the release notes for more infor-mation.

Figure 9-52 Defining a new application

Note: Use caution when editing or deleting applications, since there is no way to reset the definitions to their defaults without resetting the entire Appliance to its factory defaults.



9.4.4.1 “License Information” Tab

The “License Information” tab gives the information needed for the creation of a license for your Appliance, or to match up a pre-generated license with the correct Appliance. If a license has been successfully installed, the “Required Action” field will say, “None.”

The format of the License Information tab is different if no license has been installed. The “Required Action” field will report that only a legacy license is installed. A link is provided to go to the My Citrix and obtain another.

9.4.4.2 “License Server” Tab

This tab specifies whether licenses will be obtained locally or remotely. If local licenses are used, they are installed using the “Local Licenses” tab. With remote licensing, the license file is installed on a Citrix License Server running on the machine of your choice. Remote licenses were introduced in release 5.6.

If remote licenses are used, the “Remote License Server” address must be supplied, plus the “Remote License Server Port” (the default value will almost always be cor-rect). Also, the type of license must be specified in the “Model” pull-down menu.

Figure 9-53 “License Information” tab.

Figure 9-54 “License Server” tab.

9-48 November 14, 2012


These licenses specify the maximum supported bandwidth. The remote license server needs to have a license available for the model selected, or no license will be acquired.

If SSL acceleration, MAPI acceleration, or signed SMB acceleration are required, then a “crypto license” must also be installed. Checking the “Crypto License Requested” box will acquire a crypto license, if available.

9.4.4.3 “Local Licenses” Tab

This tab is where you install the license itself. Most Appliances with local licenses will have 1-3 active licenses: for acceleration, for the Repeater Plug-in, and for SSL accel-eration (the crypto license).

The steps for installing a license are:

1. Add a new license by pressing the “Add” button.2. Type a name into the License Name Field. This name can be anything, but it 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.

Figure 9-55 License Configuration tab on the Configuration: Licensing page.



9.4.4.4 “Licensed Features” Tab

This tab reports the features that have been licensed for this Appliance.

9.4.5 “Configuration: Links”

The “Configuration: Links” page is where your WAN and LAN links are defined. Defin-ing links enables the Appliance’s reporting and traffic shaping.

9.4.5.1 “Link Definition” Tab

This tab is the entry point for defining and modifying links. New links are defined by pressing the “Create” button. Existing links are modified by pressing the “Edit” but-ton. Both these actions take you to a similar form that allows you to specify link-defi-nition rules. See Figure 9-58.

The order in which the links are shown on this is significant. When deciding which link a packet belongs to, the Appliance tests the links in order, and the first matching link is selected. This means that overlapping definitions are allowed, and the last defini-tion in the link can match all traffic, serving as a default link.

The “Order” buttons can move a link up or down the list.

The “Expand All” button will show the expanded form of the display, summarizing the link definitions instead of displaying only the names of the link.

Figure 9-56 Configuration: Licensing page.

Figure 9-57 “Link Definition” tab.

9-50 November 14, 2012


9.4.5.2 The “Create Link” and “Edit Link” Forms

A link definition has a set of send/receive bandwidth limits and a list of rules that define which traffic belongs to the link. Within a rule, the fields are all ANDed together, so all specified values have to match. All fields default to “Any,” a wildcard entry that matches all traffic. When a field consists of a list, such as a list of IP sub-nets, these are ORed together: that is, if any element matches, then the list as a whole is considered to be a match.

Links can be based on the Ethernet adapter associated with the traffic, the source and destination IP addresses, VLAN tag, WCCP service group (for WCCP-GRE only), and the source and destination Ethernet MAC address. A simple inline deployment might identify only the LAN-side and WAN-side accelerated bridge ports (apA.1 and apA.2), while a complex datacenter deployment might need to use most of the features pro-vided on the form to disambiguate traffic. See Section 4.4 for a complete description of link definition.

Defining a link in terms of its IP addresses is possible except when redundant links are used. Since a given packet may go over either link in an active-standby or active-active dual-link deployment, some other method must be used to determine which link the packet is using. If dual bridges are used, then the traffic for one link can go over apA and the other over apB, and the links can be defined in terms of adapters. If the two links are served by different routers, the MAC addresses of the routers can be used to tell the traffic apart. When all else fails, WCCP-GRE can be used, and the router can use a different service group for each WAN link, allowing the Repeater unit to tell the link traffic apart in by service group.

Figure 9-58 “Edit Link” form.

Figure 9-59 Link definition rules.



• Adapter. This specifies a list of adapters (Ethernet ports). When links can be iden-tified by ethernet adapter, this simplifies configuration.

• Src IP. The Source IP rules are considered for packets entering the unit (packets exiting the unit are ignored). On these packets, the rules in the “Src IP” field are compared against the Source Address field in the IP header. The rule specifies a list of IP addresses or subnets. Negative matches, such as “Exclude 10.0.0.1” are also supported.

• Dst IP. The Destination IP rules are considered for packets exiting the unit (pack-ets entering the unit are ignored). On these packets, the rules in the “Dst IP” field are compared against the Destination Address field in the IP header. The rule specifies a list of IP addresses or subnets. Negative matches, such as “Exclude 10.0.0.1” are also supported.

• VLAN. The VLAN rules are applied to the VLAN headers of packets entering or exit-ing the unit.

• WCCP Service Group. The WCCP Service Group rules are applied to GRE-encapsu-lated WCCP packets entering or leaving the unit. (This does not work with L2 WCCP.)

The traffic classifier uses the “Src IP” and “Dest IP” fields in a specialized way (the same applies to “Src MAC” and “Dst MAC”):

• The “Src” field is only examined on packets entering the appliance. • The “Dst” is only examined on packets exiting the appliance.

This convention allows the direction of packet travel to be implicitly considered as part of the definition. The same concepts applies to the “Src MAC” and “Dst MAC” rules.

9.4.5.3 “Hardboost/Softboost” Tab

This tab allows you to select between hardboost and softboost modes and adjust the acceleration engine’s send and receive rates. These rates have nothing to do with the traffic shaper, which operates independently of the acceleration engine.

WAN Boost Mode. These controls allow you to choose between hardboost and soft-boost. Softboost is the recommended mode.

Hardboost is supported only on point-to-pint links and is incompatible with traffic shaping.

Bandwidth Limits. One or two bandwidth limits are shown. The two limits are “WAN Bandwidth Send Limit” and “WAN Bandwidth Receive Limit.”

Figure 9-60 “Hardboost/Softboost” tab.

9-52 November 14, 2012


The sending limit is the maximum speed at which the acceleration engine will send data. It acts as a bandwidth clock that meters traffic onto the WAN link at the speci-fied speed. This prevents the link from being overrun.

The receiving limit is transmitted to the partner appliance, informing it that it should send accelerated data no faster than the specified rate. The local appliance communi-cates this rate but does not enforce it.

These values are ignored by the traffic shaper, which is not integrated with the accel-eration engine.

When traffic shaping is disabled (on the “Features” page), an additional bandwidth limit is revealed, the “WAN Bandwidth Send Limit.” This sets the outgoing speed of accelerated traffic only. If traffic-shaping is re-enabled, this value is no longer dis-played, but it is still enforced.

If hardboost is selected, the hardboost bandwidth limit must be set correctly. This number represents the speed at which the acceleration engine will attempt to receive data, and must be no faster than either the speed of the local WAN link (in the receive direction) or the remote WAN link (in the sending direction).

When softboost is selected, the receive bandwidth limit has an indirect effect on per-formance, informing the remote appliance to send no faster than the limit. This nego-tiation is ignored by the traffic shapers in both appliances, and normally the receive bandwidth limit is set higher than the actual link speed to prevent accidental traffic throttling.

9.4.5.4 “Traffic Shaping” Tab

This tab shows all the service-class traffic-shaping policies sorted by link, making it easier to do per-link policy selection.

Figure 9-61 “Traffic Shaping” tab.



9.4.6 “Configuration: Network Adapters”

9.4.6.1 “IP Addresses” Tab

This tab allows you to configure the IP address, netmask, gateway, HA virtual address, and VLAN of each interface, as well as enabling or disabling the interface.

For complete information on port usage, see Section 4.8. What follows below is a summary.

9.4.6.2 Accelerated Pairs

Most Appliances have four ports: two configured as a bridge called “Accelerated Pair A,” or apA, and two non-bridged motherboard ports, Primary and Aux1.

A typical installation uses only apA. Some Appliances may have a second accelerated pair. Acceleration is not supported on Primary or Aux1.

Accelerated pairs do not require an IP address for simple inline-mode operation, but an IP address is required if you use the Repeater Plug-in, WCCP, or SSL acceleration. If apA is left without an IP address, the Primary port should be enabled and have an IP address assigned to it so that the Appliance can be managed. Access from the serial and front-panel interfaces will still be active. Per-port access is controlled on the “Configuration: Network Adapters” page.

Figure 9-62 “IP Addresses” tab.

9-54 November 14, 2012


9.4.6.3 Address Formats

Except for the hostname, the network settings expect static IP addresses or masks in the usual decimal dotted-quad notation, such as “10.0.0.150”. These should be assigned as if the Appliance were simply another computer on its subnet, not as if it were a router (since it isn’t a router).

Changes do not take effect until you click the “Update” button and restart the unit.

9.4.6.4 HA Virtual IP Addresses

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

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

9.4.6.6 VLAN Settings

If your network uses VLANs, the Appliance should be set to a valid VLAN address.

Inline traffic will be accelerated regardless of the VLAN addresses (if any) of the 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.”

Changes do not take effect until the unit is restarted.

Note: When the VLAN is enabled, the management interface only responds to browser traffic from the specified VLAN. Thus, accidentally specifying the wrong VLAN will make the browser-based interface inaccessible. This can be reset from the LCD front-panel interface.



9.4.6.7 “Ethernet” Tab

Each Ethernet interface used by the Appliance is listed here, along with its speed (10, 100, or 1000 Mbps), its duplex setting (full or half), and its auto-negotiation state (auto or forced to a specific mode).

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 9-64.

9.4.6.8 Detailed Adapter Information

The Detailed Adapter Information page gives both summary statistics for the adapter and second-by-second transmit and receive statistics.

Clicking on the black arrows next to the graphs will move the view into the past (left arrows) or towards the present (right arrows) in one-minute increments.

Figure 9-63 “Ethernet” tab.

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 5.2.2.2 for more information.

9-56 November 14, 2012


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 9-64 Ethernet adapter detailed information page, top half.



9.4.7 “Configuration: Logging/Monitoring”

The “Configuration: Logging/Monitoring” page controls the logging and alert settings for the Appliance. It has seven tabs: “Log Options,” “Log Extraction,” “Log Statistics,” “Log Removal,” “Alert Options,” “Syslog Server,” and “SNMP.”

Figure 9-65 Ethernet adapter detailed information page, bottom half.

9-58 November 14, 2012


9.4.7.1 “Log Options” Tab

These options set the kind of information that is stored in the log:

• Log System Records. This gives general statistics about connections every 60 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.

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

Figure 9-66 “Log Options” tab.



9.4.7.2 “Log Extraction” Tab

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

9.4.7.3 “Log Statistics” Tab

The “Log Statistics” tab gives basic information about the logging system.

Figure 9-67 “Log Extraction” tab.

Figure 9-68 “Log Statistics” Tab

9-60 November 14, 2012


9.4.7.4 “Log Removal” Tab

You can erase the log files by pressing the “Remove” button.

9.4.7.5 “Alert Options” Tab

Two Kinds of Alert Message

There are two kinds of Alerts:

1. User-configurable alerts, which appear on the “Configure Settings: Alert” page. These are mostly informational and are primarily of use when troubleshooting. Each of these alerts has a radio button to select between “Alert,” “Logged,” and “Disabled.”

2. Internal alerts. These generally indicate a more serious problem, and cannot be masked by the user. They do not appear on the “Configure Settings: Alert” page.

User-Configurable Alerts

• Alerted means that when the condition occurs, it will be logged, the alert icon will appear at the top of the screen, and the condition will be listed when the “Error” link is clicked.

• Logged means that when the condition occurs, it will be logged, but the alert icon will not appear and the condition will not be listed when the “Error” link is clicked.

• Disabled means the condition will not be logged. Not all conditions can be 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.

Figure 9-69 Configure Settings: Log extraction

Figure 9-70 Part of the “Alert Options” tab.



Each parameter has an associated description in the Help column (the text for which will not be repeated here).

Changes will not take effect unless you press the “Update” button.

The “Reset to defaults” button restores the factory-recommended settings.

Alerts include:

• WAN Loss Rate• LAN Loss Rate• Connection Stalled (probable application hang)• Connection Timeout• Invalid Connection Attempt• NIC Negotiated Half-Duplex• ARP Timeout• Attempt to Exceed License Key File Limit• Asymmetric Network Configuration• Invalid or Illegal Packets Received• Out of CPU Resources• Out of Memory Resources• Internal Errors• Compression Error Detected• Softboost-Hardboost Mismatch• Disk Drive is Degraded• NIC Watchdog Bypass Event• Disk is Fragmented• Network Unreachable• DNS Lookup Failed• Appliance in the Middle Intercepting Options• Major Internal Errors• Minor Internal Errors• Internal Warning• WCCP Detected Major Error• WCCP Detected Minor Error• WCCP Warning• Network Driver Hang Detected• Signaling Channel Establishment Error• SCPS Mode Mismatch Detected• Repeater Plug-in count is nearing its limit• SSL Communication Error

Internal Alerts

Contact your support representative if you receive Alert messages that are not repre-sented on the “Configure Settings: Alert” page.

9-62 November 14, 2012


Some of these messages give guidance about whether you should contact us immedi-ately or at your convenience.

Alert Messages

Potential error conditions are reported at one of three levels: they can be ignored, they can be logged, or they can be logged and also cause an “Alert” warning to appear at the top of the page:

The Alerts page lets you select the reporting for different types of error.

Clicking on the link displays information about the outstanding alerts, as shown in Figure 9-71.

Alerts will clear themselves if the problem goes away for long enough (by default, for one hour).

9.4.7.6 “Syslog Server” Tab

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

Figure 9-71 Alert details page

Figure 9-72 Configure Settings: Syslog server



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

9.4.7.7 “SNMP” Tab

This tab sets up SNMP monitoring of the Appliance. SNMP operation is disabled by default, but is enabled by the button at the top of the page. SNMP v1 and v2c are supported.

Figure 9-73 “SNMP” tab.

9-64 November 14, 2012


Fields on this page have their conventional meanings.

Management access must be restricted by giving an IP or network number for the “management station.” However, this can be circumvented by setting the IP Bit mask to zero (equivalent to a bit mask of 0.0.0.0). To give access to any host on a Class C subnet, set the IP Bit Mask to 24 (equivalent to 255.255.255.0). To limit access to a single host, set the IP Bit Mask to 32 (equivalent to 255.255.255.255).

SNMP accesses are read-only; that is, monitoring but not configuration is supported by SNMP.

The parameters available via SNMP are documented in the .MIB files themselves.

9.4.7.8 Installing the SNMP MIB Files

SNMP MIB files can be downloaded from the links at the bottom of the page. The files reside on the Appliance. They must be loaded into the SNMP manager in the order listed on the page.

9.4.8 “Configuration: Repeater Plug-ins”

This page controls how the Appliance interacts with Repeater Plug-in. Repeater Plug-in support is a licensed option; so this page is greyed out if no Plug-ins are sup-ported by your license.

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

Figure 9-74 “Signaling Channel Configuration” tab.



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; redirector mode has several liabilities that make it a mode of last resort.

Enable Plug-in-Appliance RTT Detection. This feature prevents acceleration when the Plug-in and Appliance are on the same LAN. Such “local acceleration” is undesirable because the Appliance’s bandwidth limit will be applied to local connections, which will greatly reduce the speed of LAN-to-LAN traffic.

Min. Plug-in-Appliance RTT for Acceleration. This value should be larger than any RTT (ping time) seen on the local LAN, but smaller than that seen by any remote user. The default value of 20 ms is adequate for most networks.

Refresh/Cancel/Apply. Depending on context, some subset of these buttons will appear.

9.4.8.2 “Acceleration Rules” Tab

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.

9.4.8.3 Best Practices With Acceleration Rules• Use “Accelerate” rules for all subnets that are local to the Appliance. Generally this

means the LAN subnets at the site where the Appliance is installed.• If there are any destination addresses in this space that are not really LAN

addresses, add “Exclude” rules for these addresses and move the “Exclude” rules

Note: Changes to the connection status will not be updated in real time. Press the “Refresh” button to see the actual status.

Figure 9-75 Plug-in acceleration rules.

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.

9-66 November 14, 2012


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 and accelerating all the traffic between the Plug-in and VPN is optimal.

9.4.8.4 “General Configuration” Tab

This tab enables various housekeeping and diagnostic features related to the Repeater Plug-in. The operation of most features is TBD.

Figure 9-76 General client configuration.



9.4.9 “Configuration: Secure Partners”

This page is used to set up the SSL signaling connection used by SSL compression. Its fields and use are describe in Section 4.20.4, Step 7.

Figure 9-77 Configuring peer communication.

9-68 November 14, 2012


9.4.10 “Configuration: Service Classes”

9.4.10.1 “Service Class Definition” Tab

Service classes map applications, IP ranges, incoming Diffserv (DSCP) fields, or VLANs to acceleration and traffic-shaping policies.

This page shows the list of defined service classes. This is an ordered list; the first matching service-class definition will be used. Each service class has controls to move the definition within the list, edit the definition, or delete it.

By default, only the service class names are shown, but they can be expanded to summarize their definitions as well.

Creating a New Service Class

Click on the “Create” button at the top of the page. This will pop up the “Create Ser-vice Class Page” (see Figure 9-79). Give the new service class a name, select an acceleration policy (choices are: none, flow-control only, memory-based compression only, and disk-based compression), assign a traffic-shaping policy, and enter a set of filter rules. Typically a single filter rule will be used, specifying an application or an IP range.

Figure 9-78 “Service Class Definition” tab.



Rules can be based on the application, source and destination IP address, VLAN tag, or the incoming DiffServ (TOS/DSCP) bits. If the “SSL Profiles” field is used, any traf-fic matching the service class is considered to also match the selected SSL profile.

The traffic-shaping policies can be set to the same policy for all links or with per-link policies. In most installations, per-link policies are not desirable.

Multiple rules can be specified. Fields within a single rule are ANDed together, so all specified fields must match. When multiple rules are used, they are evaluated in order. If any rule matches, the traffic is considered to belong to the service class.

Traffic-shaping policies are chosen from the pull-down menu. By default, a range of policies from “Very Low” to “‘Very High” are defined, each policy having twice the weighted priority of the next-lower policy. In addition, there is a “VoIP Traffic” policy that has an effectively infinite weight (and thus must be used with caution), and a “Default Policy.”

Editing an Existing Service Class

This process is essentially the same as creating a new service class.

Meaning of Acceleration Policies

Flow Control Only. The “Flow Control” checkbox enables or disables acceleration. Rec-ommended for traffic that is 100% uncompressible because the same data will never be seen twice (mostly encrypted protocols and live video). Note that pre-compressed traffic such as JPG images, ZIP archives, and audio/video streams that are played more than once are all highly compressible on the second pass. For example, if two people play the same YouTube video, the compressor will achieve a high compression ratio for the second users, since the video data will be the same as before and will match the first copy.

Disk Compression. Enables flow control and the full range of compression features (disk-based and memory-based compression). Recommended for most traffic.

Memory-based Compression. Enables flow control and memory-based compression only. This option is rarely used.

Figure 9-79 “Create Service Class” page.

9-70 November 14, 2012


Rules are Evaluated In Order

Acceleration policy. When a connection is opened, the first matching policy in the list will be used. Rules can be moved up and down in the list using the “Move Up” and “Move Down” buttons. Changes do not take effect until the “Apply” button is pressed.

Acceleration policies are based solely on information available on the first packet of the connection (the SYN packet). The results of deep packet inspection are not avail-able until later in the connection, so such matches cannot be made.

Acceleration policies are only meaningful on accelerated connections.

Traffic-Shaping Policy. The initial traffic-shaping policy is based on the first packet seen, but deep-packet inspection may change this decision. For example, an applica-tion that is defined based on a URL will match when a data packet containing an “HTTP GET url” command is seen. This will reclassify the traffic-shaping policy for the connection.

All WAN data flows have a traffic-shaping policy, whether they are accelerated or non-accelerated, TCP or non-TCP.

Only Acceleration Features Allowed by Both Units Are Used

Only acceleration options that are agreed upon by both Appliances will be used. For example, if one unit selects compression for a connection and the other does not, the connection will be uncompressed. Traffic will not be accelerated unless there are two Appliances involved, one at either end of the link, and both enable flow-control or compression for the connection.

“Other TCP Traffic” is a special category that specifies the default acceleration action to take if no other service classes apply.

Special-Case Handling for Internet HTTP/HTTPS

The service class policies for HTTP and HTTPS are split into “Private” and “Internet” variants. The reason for this is that some Web sites have paranoid firewalls that reset TCP connections with “unknown” TCP options, which sometimes include acceleration options. While such connections will be retried as unaccelerated connections after a timeout period, this is time-consuming and annoying to the users.

The “Web (Private)” and “Web (Private-Secure)” service classes define HTTP and HTTPS service on the standard private networks of 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16, as defined in RFC1918. These addresses are not routable on the public Internet, and instead are used by most organizations for their private 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 “Web (Internet)” and “Web (Internet-Secure)” service classes are for non-private Web traffic and have flow control and compression disabled.

The ordering of the two sets of rules is important; the “Private” rules need to occur first in the “Service Class Policy” list.

These rules are not necessary unless Internet traffic passes through a single 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.



9.4.10.2 “Traffic Shaping” Tab

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

9.4.11 “Configuration: SSL Acceleration”

This page consists of five disguised tabs (disguised because they are implemented as buttons). They are:

Profiles. Allows you to set up server profiles, typically one per endpoint SSL server. The fields for this tab, and the procedure for using it, are given in Section 4.20.4, Steps 9-10.

Manage CA’s. Allows you to upload CA certificates. See Section 4.20.4, Step 6.

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

Import SSL. Upload an SSL configuration previously saved on the Export SSL tab.

Export SSL. Save the current SSL configuration to a file.

Figure 9-80 “Import SSL” tab.

Figure 9-81 “Export SSL” tab.

9-72 November 14, 2012


9.4.12 “Configuration: SSL Encryption”

This page has the main password and enable/disable toggles for SSL compression.

• Key Store. For greater security, keys are password-protected. SSL compression will not take place unless the key store is opened with the password. For security reasons, SSL compression is disabled after each restart, until this password is entered. If user data encryption is used, compression is also disabled until this password is entered. See Section 4.20.

• User Data Store. User data, consisting mostly of disk-based compression history, can optionally be encrypted using AES-256 encryption. Changing the encryption state causes disk-based compression history to be lost. Encrypting the user data protects the contents from disk-based compression history from being examined if the unit is stolen or removed from service.

• SSL Optimization. The master enable/disable switch for the SSL compression feature.

Figure 9-82 “Configuration: SSL Encryption” page



9.4.13 “Configuration: Traffic Shaping Policies”

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

Figure 9-83 “Configuration” Traffic Shaping Policies” page.

9-74 November 14, 2012


9.4.13.1 Creating and Editing Policies

Pressing the “Create” button takes you to the “Create Policy” page, which has the fol-lowing fields (some of which are hidden by default, but can be revealed with the “Show Advanced Options” button):

Name. The name of the new policy. Must be unique.

Weighted Priority. This can be the same as an existing priority value or can be a custom value between 1 and 256. A connection with a priority of 256 will get 256 times the bandwidth share as a connection with a priority of 1.

Set ICA Priorities. If this policy will be used for Citrix XenApp/XenDesktop traffic, the traffic’s internal priority values can be mapped to Branch Repeater priorities.

Optimize for Voice. If checked, this policy will have effectively infinite priority. This is highly undesirable for most traffic, since it will prevent meaningful traffic shaping and will cause data starvation for other traffic if there is enough “optimized for voice” traf-fic to fill the link. Use only for VoIP, and always use in conjunction with a bandwidth limit on the policy (for example, 50% of the link speed).

Set Diffserv/TOS. Sets the Diffserv field of matching traffic to the indicated value, informing downstream routers of the traffic priority.

Figure 9-84 “Create Policy” page.



Set ICA Diffserv/TOS. As above, but allows the Diffserv field to be set differently depending on the priority field within the ICA data stream. Has no effect on non-ICA traffic.

Limit Bandwidth. Prevents the traffic from this policy from exceeding a specified per-centage of link bandwidth, or a specified absolute rate. Because this limits perfor-mance, it is rarely used except with voice traffic.

Editing policies is essentially identical to creating new ones.

9.4.14 “Configuration: Tuning”

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.

Figure 9-85 Configure Settings: Tuning page

Note: Unlike the other pages, the buttons on the Tuning page are greyed out until you change a parameter.

9-76 November 14, 2012


9.4.14.1 Window Settings

There are two tuning settings: the WAN scale limit and the LAN scale limit. These set the TCP scaling option between the two Appliances (See RFC 1323). The default LAN scale limit is 16, corresponding to a 64 KB (216 bytes) advertised window. The default WAN scale limit is 23, corresponding to an 8 MB (223 bytes) advertised window.

These values rarely need to be changed from their defaults, though in WANs with a very high bandwidth-delay product, the WAN scale limit may need to be increased, while on a WAN with a very low bandwidth-delay product, the WAN scale limit may need to be decreased. The rule of thumb is to have a WAN scale limit that is at least 2-3 times the bandwidth-delay product.

For example, a 200 Mbps link with a 500 ms RTT has a bandwidth-delay product of 100,000,000 bits. Doubling this gives 200,000,000 bits, or 25,000,000 bytes. This is larger than the default 8 MB window. Increasing the WAN scale limit to 23 (225 bytes or 32 MB) would accommodate this.

Increasing these limits under other circumstances will not increase performance and will only waste memory.

9.4.14.2 Connection Timeout

Idle accelerated connections should time out eventually, as they consume system resources. This entry gives the idle time that must elapse before the Appliance closes a connection. If the application sends keep-alive packets, these will reset the idle timer. Such connections will never be closed by the connection timeout mechanism.

Some links see thousands of half-closed connections that never become fully closed. These may eventually overflow the 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.

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

9.4.14.4 Privileged Ephemeral Ports

Ports in this range can be used as ephemeral ports only by specific applications.

9.4.14.5 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.11.

9.4.14.6 Daisy-Chain

Acceleration takes place between two Appliances. If three or more Appliances are used in series, the link will not be accelerated end-to-end. Instead, the link between Appliances 1 and 2 will be accelerated, but not between Appliances 2 and 3.

Appliances with the “Enable Daisy-Chained Units” option set will detect when they are in the middle of a chain, and pretend that such connections are non-accelerated. This guarantees that the two endpoint Appliances will both see an accelerated connection.

Daisy-chaining is not recommended for hardboost links.

Peculiarities of Daisy-Chaining

• Daisy-chaining does not need to be enabled except on the middle units. • The bandwidth graph of the middle unit will display daisy-chained connections as

non-accelerated.• If a middle Appliance has its acceleration disabled or restarts, the daisy-chained

connections will be reset, just like the ordinary accelerated connections.

9-78 November 14, 2012


9.4.14.7 TCP Maximum Segment Size (MSS)

This specifies the maximum size of the TCP portion of a packet. This defaults to 1380 bytes. If you have a VPN that encapsulates packets inside another header (as PPTP and IPSec VPNs do), you may need to reduce this to prevent packet fragmentation. Reducing the MSS to 1340 will usually accomplish this.

Both the “Default MSS” and “Maximum MSS” fields should always be set to the same value.

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

9.4.14.9 Legacy CIFS Protocol Filtering

Allows specific IP ranges to be either included into or excluded from CIFS accelera-tion. Not recommended for new installations.

9.4.14.10Generic Settings

This allows any internal Appliance parameter to be set to an arbitrary value. This is generally done only at the request of Support.

For example, the bandwidth limit can be set 1,000 kbps by putting “SlowSendRate” in the “Setting” field and “1000 K/S” in the “Value” field.

You can also query the current setting of a parameter by filling in the “Setting” field but leaving the “Value” field blank.

Note: The internal Appliance values are not documented and setting them in this way is not recommended, unless you are advised to do so by Sup-port.



9.4.15 “Configuration: Windows Domain”

The “Configuration: Windows Domain” page allows the server-side Appliance to join the same Windows Domain as the servers it is accelerating, allowing encrypted MAPI and signed SMB traffic to be accelerated (providing that the client-side Appliance has SSL acceleration configured to the point where a secure peer relationship exists between the client-side and server-side Appliances).

Joining the domain needs to happen only once, by typing in the domain credentials. (If the domain password changes, this will have to be repeated.)

Demo Mode

In demo mode, the login credentials of a single user are used instead of the domain credentials. This allows the acceleration of outcropped MAPI and signed SMB for that user. This mode is recommended for demonstration and testing only.

Figure 9-86 “Configuration: Windows Domain” page.

9-80 November 14, 2012


9.5 “Reports” Pages

9.5.1 “Reports: Compression”

9.5.1.1 “Compression Graphs” Tab

These tabs show graphs and tables based on several timescales (minute, hour, day, etc.):

Accelerated Line Usage. This has nothing to do with compression, but shows the top accelerated service classes by the amount of WAN bandwidth used.

Non-Accelerated Line Usage. This has nothing to do with compression, but shows the top non-accelerated service classes by the amount of WAN bandwidth used.

Compression by Service Class. Shows the data size before and after compression, for compressed traffic only. This is measured at the compression engine, and gives the amount of data seen by the user’s application (that is, it excludes headers and retransmissions), and thus has data sizes smaller than those seen on the link for both the “before” and “after” categories, since it measures “goodput” rather than total usage.

Service Class Details. This has nothing to do with compression but shows some statis-tics on a per-service-class basis.

Figure 9-87 Compression graphs tabs.



9.5.1.2 “Compression Status” Tab

The “Compression Status” tab shows cumulative compression statistics rather than second-by-second results. The statistics can be cleared at any time by pressing the “Clear” button. This affects only the statistics on this page. Otherwise, the data covers the time since the last restart. Statistics are reported separately for the sending and receiving direction.

The compression ratios have their usual meaning (uncompressed bytes / compressed bytes).

The “Data Reduction” values are a different way of expressing the same information as the compression ratio. For example, a connection with 10:1 compression has a bandwidth reduction of 90%.

Only payload bytes are considered in these calculations. However, compression aggregates packets (several packets can be compressed into one), so the number of packets (and hence the number of header bytes) tends to be reduced by an amount roughly equal to the compression ratio. That is, a 2:1 compression ratio will tend to halve the number of packets, which is equivalent to 2:1 header compression.

Figure 9-88 Compression status tab.

9-82 November 14, 2012


9.5.2 “Reports: LAN vs. WAN”

The “LAN vs. WAN” report compares all LAN traffic to all WAN traffic (including non-accelerated traffic). This can provide meaningful insights in some (but not all) deployments. In simple inline deployments, where LAN traffic is directly related to WAN traffic in some way, the difference between the traffic volumes shows some of the effect of caching and compression, since these operations reduce WAN data usage. However, read-ahead and some flow-control optimizations increase total WAN usage, even though they increase overall performance at the same time, making this page hard to interpret.

As with other historical pages, this covers timescales from “last minute” to “last restart.”

Figure 9-89 “Reports: LAN vs. WAN” page.



9.5.3 “Reports: Link Usage”

The “Reports: Link Usage” shows the LAN-side and WAN-side traffic in both direc-tions.


Figure 9-90 “Reports: Link Usage” page.

9-84 November 14, 2012


9.5.4 “Reports: Service Classes”

The “Reports: Service Classes” page shows the WAN-side traffic over the specified time period, with each service class shown in a different color, along with a table giving traffic statistics for the service classes. See also the “Top Applications” graph (Section 9.5.5), which is similar but breaks the traffic down into individual applica-tions, which gives finer-grained reporting than service classes.


Figure 9-91 “Reports: Service Classes” page.



9.5.5 “Reports: Top Applications”

9.5.5.1 Historical Graphs

The “Reports: Top Applications” page lists the most common applications in terms of WAN usage, showing pie charts, and time graph, and a table of total usage over the specified time interval. By default, the top ten applications are listed. This can be changed with the “Customize” button.


The second table on the historical tabs shows the list of applications for a second time, with links to historical information on the application, the parent application, and the application group.

Figure 9-92 “Reports: Top Applications” page.

9-86 November 14, 2012


9.5.5.2 “Active Applications” Tab

The “Active Applications” tab shows a table of all applications seen since the last restart, sorted by WAN data volume.

Figure 9-93 “Active Applications” tab.



9.5.6 “Reports: Traffic Shaping”

The “Reports: Traffic Shaping” page shows historical graphs and tables of WAN traffic, with each traffic-shaping policy shown in a different color.

As with other historical pages, this covers timescales from “last minute” to “last restart.” The “last restart” tab has a different format and allows you to click on an individual traffic-shaping policy and see its historical graphs in isolation.

Figure 9-94 “Reports: Traffic Shaping” page.

9-88 November 14, 2012


9.6 “System Maintenance” Pages

9.6.1 “System Maintenance: Backup/Restore”

Backup 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 Appliance. License files, SSH parameters, and IP addresses are not restored. The file is an ordinary text file, but should not be edited manually.

Reset to Factory Defaults. Sets all parameters except IP addresses, bandwidth set-tings, and licenses to their factory defaults.

9.6.2 “System Maintenance: Clear Statistics”

The “System Maintenance: Clear Statistics” page allows you to reset the Appliance’s statistics, allowing you to create reports that start at the beginning of the desired sampling window.

Figure 9-95 “System Maintenance: Backup/Restore” page.

Figure 9-96 “System Maintenance: Clear Statistics” page.



9.6.3 “System Maintenance: Date/Time”

The date and time are set on this page. You can set the date and time manually by updating the time fields with the current time, or use an NTP server by specifying its IP or DNS address. The Zone field allows you to choose a time zone.

The date and time must be accurate (within 10-20 seconds) for the Appliance to join a Windows Domain successfully.

Figure 9-97 “System Maintenance: Date/Time” page

9-90 November 14, 2012


9.6.4 “System Maintenance: Diagnostics”

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

9.6.4.2 “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

Figure 9-98 The “Tracing” tab.

Figure 9-99 Bypass Card Test tab



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.

9.6.4.3 “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 core file was generated to collect log data and similar information.)

3. Press the “Get Core Files” button. The selected files will be gathered into a.zip archive (this may take several minutes), and a new screen will be shown.

4. Click on the “Click here” link. A dialog box will ask you what you want to do with the file. Select “Save File to Disk.” A “Save As..” dialog box will open. Choose an appropriate directory and save the file.

Figure 9-100 Retrieve Cores tab

9-92 November 14, 2012


9.6.4.4 “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.

9.6.4.5 “Ping” and “Traceroute” Tabs

The “Ping” and “Traceroute” tabs (not shown) allow you to use the standard ping and traceroute utilities to test connectivity to remote systems.

Figure 9-101 Line Tester tab



9.6.4.6 “System Info” Tab

The “System Info” tab takes you to a page that lists all parameters that are not set to their defaults. This information is read-only. It is used by Support when some kind of misconfiguration is suspected. When you report a problem, you may be asked to check one or more values on this page.

The information is intended for use by Support, and is not documented. This page also replicates the detailed adapter info described in Section 9.4.6.8.

Figure 9-102 “System Info” tab

9-94 November 14, 2012


9.6.4.7 “Diagnostic Data” Tab

The “Diagnostic Data” tab packages data for analysis by Citrix Support. There are two features: tracing and one-button data collection. Use them only at the request of Citrix Support, which will provide you with instructions for which options to set and where to send the resulting data files.

9.6.5 “System Maintenance: Restart System”

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

Figure 9-103 “Diagnostic Data” tab

Figure 9-104 System Tools: Restart System page.



9.6.6 “System Maintenance: Update Software”

9.6.6.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 9-105), 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.

Figure 9-105 System upgrade page.

9-96 November 14, 2012


The unit may require several minutes longer than usual to restart when it is applying a patch.

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

If you are using Repeater disk encryption, the other releases on the unit will be dis-played in orange, and the “Downgrade Release” option is not available unless you first disable disk encryption.

The Appliance maintains copies of older releases, and the downgrade process reverts to one of these. Licenses and settings are not copied back from the newer release to the older one. Instead, the unit will revert to the settings that were in effect at the time the older release was upgraded.

9.6.6.3 Changing the Version Type

The “Change Version Type” option allows you to select a debug version of the release. Possible debug versions are “Level 1” or “Level 2.” You should not select these unless instructed to do so by Support.

Figure 9-106 Display on a successful patch upload.

Figure 9-107 A reminder is displayed if restarting is deferred.



9-98 November 14, 2012

Chapter 10

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.

10.1 SSH AccessTo 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 [email protected] Last login: Fri Jun 20 14:50:22 2008 from xx.xx.xx.xxLogin: adminPassword: xxxxxxxxCommand Line Interpreter - Version 1.0Copyright 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.

10.2 RS-232 AccessThe CLI can also be used via a null modem cable to the Appliance’s serial port at 115,200 baud, 8 data bits, 1 stop bit, no parity. The login procedure is the same as with SSH.


10.3 SFTP Access

10.3 SFTP Access

10.3.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.)

10.3.2 Transferring Files

Once enabled, you can use sftp (or, on Windows, perhaps psftp), to log onto the Appliance with username “transfer” and the password you selected. You can then upload or download files.

See the “Command Descriptions” section (below) for the commands that accept uploaded files or create downloadable files.

Note: Do not use pathnames for the Appliance side of the transfer. Transfer all files into or out of the default directory.

Note: Filenames should contain only the characters a-z, A-Z, 0-9, period, and hyphen (dash).

10.4 Command Description

10.4.0.1 quit

10.4.1 CLI Navigation

10.4.1.1 exit

Syntax: exit

Exits from the CLI. Same as “quit.”

10.4.1.2 quit

Syntax: quit

Exits from the CLI. Same as “exit.”

10.4.2 System Tools

10.4.2.1 show config-script

Syntax: show config-script

[-replicate]

[-file “filename”]

10-2 November 14, 2012

Chapter 10. Command Line Interface

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 such as IP addresses, allowing the output of this command to be used more conveniently for configuring multiple appliances.

-file “filename” specifies that the output should be saved to the specified file rather than displayed. No pathname components should be used.

10.4.2.2 list config-script-files

Syntax: list config-script-files

Displays a list of the saved configuration files on the appliance.

10.4.2.3 save settings

Syntax: save settings

-file “filename”

Saves all parameters to the file specified by “filename”. The file is saved in the “settings” folder on the unit.

10.4.2.4 restore settings

Syntax: restore settings


Restores all parameters from the file specified by “filename”. The file must be in the “settings” folder on the unit.

CAUTION: This command takes effect immediately and reboots the appliance, without an “are you sure?” verification.

10.4.2.5 list settings-files

Syntax: list settings-files

Displays a list of the saved settings files on the appliance.

10.4.2.6 reset settings

Syntax: reset settings

Equivalent to “Reset to Factory Defaults” in the UI. Sets all parameters except IP addresses and the license file to their factory settings.

CAUTION: This command takes effect immediately and reboots the appliance, without an “are you sure?” verification.

10.4.2.7 restart

Syntax: restart

Reboots the appliance.



CAUTION: This command takes effect immediately, without an “are you sure?” verification.

10.4.2.8 what

Syntax: what

Reserved for use by Command Center.

10.4.2.9 show software

Syntax: show software

Lists all of the versions of the software installed on the appliance. One of these will be the running version, while the others are available through the “restore” command (or, on the Web UI, the “Downgrade Release” feature).

10.4.2.10 verify software

Syntax: verify software


Performs checks on file “filename” to see if it is a complete, uncorrupted software release file.

Note: This command is intended for newly transferred files. Files listed via the “show software” command are known-good files and cannot be checked by this command.

10.4.2.11 install software

Syntax: install software

-file “filename” [-restart]

Installs the software file “filename” and optionally (with the -restart option) restarts the appliance.

Note: This command is intended for newly transferred files. Files listed via the “show software” command are installed via the “restore software” command.

10.4.2.12 list software-files

Syntax: list software-files

Displays a list of software release files on the appliance.

10.4.2.13 restore software

Syntax: restore software

-version “version”

Reinstalls a previously installed software version. “Version” is the software version string. It must be identical to one of the versions listed by the “show software” command.

Example: restore software -version 4.3.24.1014

10-4 November 14, 2012


10.4.2.14 set software

Syntax: set software

-type {default, level1, level2, defaultmc, level1mc, level2mc}

Selects which version of the binary should be used. “Default” should be used unless Citrix Support recommends otherwise.

10.4.3 licenses

10.4.3.1 add local-license

Syntax: add local-license

[-name “license-name”]


Installs the license file “filename”.

-name specifies the license name to be assigned on the system.

-file specifies a previously uploaded license file in the transfer account.

Example: add local-license -name “new” -file newlicense.txt

10.4.3.2 list license-files

Syntax: list license-files

Displays a list of license files uploaded to the transfer account.

10.4.3.3 remove local-license

Syntax: remove local-license

-name “license-name”

Removes an installed license.

10.4.3.4 rename local-license

Syntax: rename local-license

-old “old-license-name”

-new “new-license-name”

Changes an installed license name.

10.4.3.5 show license-models

Syntax: show license-models

Displays the list of models which is needed to acquire license from the remote license server.

10.4.3.6 show license

Syntax: show license

Displays the current license server configuration and the licensed features.



10.4.3.7 show local-license

Syntax: show local-license

Displays the name of all local licenses installed.

10.4.3.8 set license-server

Syntax: set license-server

-location local

Syntax: set license-server

-location remote

[-model “model name”]

[-ip “ipaddr”]

[-port “port”]

Configures the system to use local or remote license server.

-model specifies the model name with which to acquire the license. Use show license-models command to display the list of models.

-ip is the IP address of the remote license server.

-port specifies the remote license server port (default 27000).

Example: set license-server -location remote -model v1000 -ip 192.168.0.1 -port 27000

10.4.4 Security

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

10.4.4.2 add user

Syntax: add user

-name “username”

-password “password”

-privilege {admin, viewer}

Defines a new user with the specified username, password, and privilege.

10.4.4.3 set user

Syntax: set user


10-6 November 14, 2012



-privilege {admin, viewer}

Alters the definition of an existing user with the specified username, allowing a change to the password or privilege level.

10.4.4.4 remove user

Syntax: remove user


Deletes user “username”

10.4.4.5 show access

Syntax: show access

[-type {radius, tacacs, web, transfer, support}]

Summarizes the settings for the Web UI, for Radius and TACACS+ authentication, for transfer account, and for the support account, including the enabled ports and options. By default, all five categories are displayed, but a single category can be selected with the -type option.

10.4.4.6 enable access

Syntax: enable access

-type {radius, tacacs, web}

Enables one of: Radius authentication, TACACS+ authentication, or access to the Web UI. Parameters for these features remain at their previous settings.

10.4.4.7 disable access

Syntax: disable access

-type {radius, tacacs, web}

Disables one of: Radius authentication, TACACS+ authentication, or access to the Web UI. Parameters for these features remain at their previous settings.

10.4.4.8 set access

Syntax: set access

-type radius

[-ip “ipaddr”]

[-port “port”]

[-secret “secret”]

Syntax: set access

-type tacacs

[-ip “ipaddr”]

[-port “port”]



[-secret “secret”]

[-encrypt {enable, disable}]

Syntax: set access

-type web

[-protocol {http, https} -port “port”]

[-forwardhttp {enable, disable}]

[-ssl-cert “certfile” -ssl-key “keyfile”]

Syntax: set access

-type transfer


Syntax: set access

-type support


Configures access parameters. The first two forms enable Radius and TACACS+ authentication, respectively. The third form sets the Web UI parameters. The forth form sets a password for the “transfer” account, which is used for transferring files. The last form sets a password for the “support” account.

10.4.4.9 list certificate-files

Syntax: list certificate-files

Displays any uploaded certificate files.

10.4.5 System Status

10.4.5.1 enable unit

Syntax: enable unit

Enables unit for traffic shaping and acceleration.

10.4.5.2 disable unit

Syntax: disable unit

Put unit in passthrough mode. No traffic shaping nor acceleration.

10.4.5.3 enable acceleration

Syntax: enable acceleration

Enables flow control and compression.

10.4.5.4 disable acceleration

Syntax: disable acceleration

Disables flow control and compression.

10-8 November 14, 2012


10.4.5.5 enable traffic-shaping

Syntax: enable traffic-shaping

Enables quality of service traffic shaping.

10.4.5.6 disable traffic-shaping

Syntax: disable traffic-shaping

Disables quality of service traffic shaping.

10.4.5.7 enable ica-multi-stream

Syntax: enable ica-multi-stream

Enables protocol acceleration for ICA multi-stream connections

10.4.5.8 disable ica-multi-stream

Syntax: disable ica-multi-stream

Disables protocol acceleration for ICA multi-stream connections

10.4.5.9 show system-status

Syntax: show system-status

Displays the same information as the Web UI’s Status page.

10.4.6 IP Address Configuration

10.4.6.1 show dns-server

Syntax: show dns-server

Displays the currently defined DNS server.

10.4.6.2 set dns-server

Syntax: set dns-server “ipaddr”

Sets the IP address of the DNS server. The unit uses a single DNS server for all DNS requests.

10.4.6.3 show hostname

Syntax: show hostname

Displays the currently defined hostname for the appliance.

10.4.6.4 set hostname

Syntax: set hostname “name”

Sets the appliance’s hostname to “name.”

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

10.4.6.6 set adapter

Syntax: set adapter {apa, apb, primary, aux1}

[-status {enable, disable}]

[-ip “addr”]

[-netmask “mask”]

[-gateway “gwaddr”]

[-ha-vip “addr”]

[-vlan {enable, disable}]

[-vlan-group “groupnumber”]

[-web-management {enable, disable}]

[-ssh-management {enable, disable}]

Sets the parameters of the specified adapter. These are the same parameters used on the Web UI’s “IP Address” page.

Valid VLAN group numbers range from 1 to 4094.

10.4.7 Ethernet Configuration

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

10.4.7.2 show interface

Syntax: show interface

[-adapter {apa.1, apa.2, apb.1, apb.2, primary, aux1}]

Displays the Ethernet speed and duplex settings of all Ethernet ports, or, optionally, a single specified port.

10.4.8 Bandwidth Configuration

10.4.8.1 show bandwidth

Syntax: show bandwidth

Displays the bandwidth limits and other information from the Web UI’s Bandwidth Management page.

10-10 November 14, 2012


10.4.8.2 set bandwidth

Syntax: set bandwidth

[-mode {hardboost, softboost}]

[-send-limit “kbps”]

[-receive-limit “kbps”]

Sets the bandwidth limits and other bandwidth management settings. These parameters are the same as those on the Web 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.

10.4.9 Link Configuration

10.4.9.1 show links

Syntax: show links

[-verbose]

Displays all of the currently defined links. The verbose parameter if specified will output a detailed listing of the settings for each link being displayed.

10.4.9.2 show link

Syntax: show link

-name “name”

Displays a detailed listing of the settings for the link specified by the name parameter.

10.4.9.3 rename link

Syntax: rename link

-old “oldname”

-new “newname”

Renames the specified link.

10.4.9.4 remove link

Syntax: remove link

{-all, -name “name”}

Deletes either the named link or all links.

10.4.9.5 remove link-filter

Syntax: remove link-filter

-link “name”

{-all, -filter-position “number”}

Removes either all link filters for the specified link or the filter at the position specified by “number”.



Valid filter positions range from 1 to N (where N is the number of filters in the current list).

10.4.9.6 move link

Syntax: move link

-name “name”

{ -direction {up, down} -count “count”,

-position {bottom, top, “number”} }

Moves the named link either relative to the current position (using the direction parameter) or absolutely (using the position parameter).

Valid integer positions range from 1 to N (where N is the number of links in the current list).

10.4.9.7 add link

Syntax: add link

[-position {bottom, top, “number”}]

-name “name”

-type {LAN, WAN}

-max-in-bandwidth “rate” [{bps, kbps, mbps, gbps}]

-max-out-bandwidth “rate” [{bps, kbps, mbps, gbps}]

{-match-all-traffic, “filter-criteria-list”}

where “filter-criteria-list” is

[-adapters ([-exclude] “adapter-name”),...]

[-source-ips ([-exclude] “ip”),...]

[-destination-ips ([-exclude] “ip”),...]

[-vlans ([-exclude] “vlan”),...]

[-wccp-service-groups ([-exclude] “id”),...]

[-source-macs ([-exclude] “mac”),...]

[-destination-macs ([-exclude] “mac”),...]

Creates a new link with the specified name, type, bandwidth rates and a single filter rule which can be either a “match all traffic” type rule or a rule based upon the criteria specified for adapters, source ips, destination ips, vlans, wccp service groups, source macs and destination macs. Double quotes can be used as delimiters for the link name (which may contain spaces).

If no position parameter is specified, the new link will be inserted at the top of the current list of links. Valid position arguments are “top”, “bottom” or a number in the range from 1 to N (where N is the number of links in the current list). To add an entry to the bottom of the list specify “bottom”.

10-12 November 14, 2012


The units for the bandwidth rate will default to mbps if nothing is specified. Bandwidth rates must be at least “56 kbps” and cannot exceed “1 gbps”. If the “match all traffic” filter rule is not specified, then at least one filter criteria option must be specified.

VLANs are specified by VLAN group numbers which range from 1 to 4094. WCCP service group values range from 51 to 99. MAC addresses should be entered as 2 digit hex terms separated by “-”’s, for example, “00-0C-F1-56-98-AD”.

10.4.9.8 add link-filter

Syntax: add link-filter

-link “name”

[-filter-position {bottom, top, “number”}]

[-adapters ([-exclude] “adapter-name”),...]




[-wccp-service-groups ([-exclude] “id”),...]

[-source-macs ([-exclude] “mac”),...]

[-destination-macs ([-exclude] “mac”),...]

Creates a new link filter in the link specified by the name parameter. If no filter position parameter is specified, the new filter will be inserted at the bottom of the current list of filters. If a filter position is specified, then the new filter will be inserted at that position in the list. Valid integer positions range from 1 to N (where N is the number of filters in the list).

For the adapters, source-ips, destination-ips, vlans, wccp-service-groups, source-macs, and destination-macs parameters, if a setting is not provided, then any value for these fields will be considered a match. All of these parameters provide the ability to specify a comma separated list of items. Each item may indicate that instead of a match operation on the item being performed that an exclude operation is done instead.


10.4.9.9 set link

Syntax: set link

-name “name”

[-type {LAN, WAN}]

[-max-in-bandwidth “rate” [{bps, kbps, mbps, gbps}]]

[-max-out-bandwidth “rate” [{bps, kbps, mbps, gbps}]]



Changes the definition of an existing link. Double quotes can be used as delimiters for the link name (which may contain spaces). At least one of the link attributes must be set.

The units for the bandwidth rate will default to mbps if nothing is specified. Bandwidth rates must be at least “56 kbps” and cannot exceed “1 gbps”.

10.4.9.10 set link-filter

Syntax: set link-filter

-link “name”

-filter-position “number”



[-adapters {match-all, ([-exclude] “adapter-name”),...]}

[-source-ips {match-all, ([-exclude] “ip”),...]}

[-destination-ips {match-all, ([-exclude] “ip”),...]}

[-vlans {match-all, ([-exclude] “vlan”),...]}

[-wccp-service-groups {match-all, ([-exclude] “id”),...]}

[-source-macs {match-all, ([-exclude] “mac”),...]}

[-destination-macs {match-all, ([-exclude] “mac”),...]}

Change the definition of the existing link filter specified by the name and filter-position parameters. Multiple filter settings may be changed at once and the other settings will be left unchanged. At least one of the link filter attributes must be set. Valid filter positions range from 1 to N (where N is the number of filters in the list).


10.4.10 Service Class Configuration

10.4.10.1 show service-classes

Syntax: show service-classes

[{-modified-only, -names “name”,...}]

[-verbose]

Displays either all the currently defined service classes, only the modified ones, or only the ones with names that have been requested. The verbose parameter if specified will output a detailed listing of the settings for each service class being displayed.

10.4.10.2 show service-class

Syntax: show service-class

10-14 November 14, 2012


-name “name”

Displays a detailed listing of the settings for the service class specified by the name parameter.

10.4.10.3 enable service-class

Syntax: enable service-class

-name “name”

Enables the service class specified by the name parameter. By default newly created service classes are disabled so that filter rules can be added.

10.4.10.4 disable service-class

Syntax: disable service-class

-name “name”

Disables the service class specified by the name parameter. Disabled service classes will not match any connections and therefore will not provide any acceleration.

10.4.10.5 rename service-class

Syntax: rename service-class

-old “oldname”

-new “newname”

Renames the specified service class.

10.4.10.6 remove service-class

Syntax: remove service-class


Deletes either the named service class or all service classes.

10.4.10.7 remove service-class-filter

Syntax: remove service-class-filter

-service-class “name”

{-all, -filter-position “number”}

Removes either all filters for the specified service class or the filter at the position specified by “number”.

Valid filter positions range from 1 to N (where N is the number of filters in the list).

10.4.10.8 move service-class

Syntax: move service-class

-name “name”

{ -direction {up, down} -count “count”,

-position {bottom, top, “number”} }



Moves the named service class either relative to the current position (using the direction parameter) or absolutely (using the position parameter).

Valid integer positions range from 1 to N (where N is the number of service classes in the list).

10.4.10.9 add service-class

Syntax: add service-class

[-position {bottom, top, “number”}]

-name “name”

-acceleration {disk, flow-control, memory, none}

-traffic-shaping-policy {default, “policy-name”}

[-per-link-policies (“link-name” “policy-name”),...]

Creates a new service class with the specified acceleration type and traffic shaping policy. Double quotes can be used as delimiters for the service class name (which may contain spaces). A newly added service class will always be created in a disabled state and must have at least one service class filter added to it before it can be enabled.

If no position parameter is specified, the new service class will be inserted at the top of the current list of service classes. Valid integer positions range from 1 to N (where N is the number of service classes in the list).

The specified traffic shaping policy will be used for this service class on all links. Per-link traffic shaping policies only need to be specified for links which have a traffic shaping policy that is different for this service class than the policy specified by the “-traffic-shaping-policy” setting.

10.4.10.10 add service-class-filter

Syntax: add service-class-filter


[-filter-position {bottom, top, “number”}]

[-bidirectional {enable, disable}]

[-applications ([-exclude] “name”),...]



[-diffserv-dscps ([-exclude] “dscp”),...]


[-ssl-profiles ([-exclude] “profile”),...]

10-16 November 14, 2012


Creates a new service class filter in the service class specified. If no filter position parameter is specified, the new filter will be inserted at the bottom of the current list of filters. If a filter position is specified, then the new filter will be inserted at that position in the list. Valid integer positions range from 1 to N (where N is the number of filters in the list).

If the bi-directional parameter is enabled then the filter will also match connection setup messages that have a source IP address that matches the filter’s destination-ips setting and a destination IP address that matches the filter’s source-ips setting. Please note that this setting only applies to which connections can be accelerated, it does not apply to traffic shaping.

For the applications, source-ips, destination-ips, diffserv-dscps and vlans parameters, if a setting is not provided, then any value for these fields will be considered a match. All of these parameters provide the ability to specify a comma separated list of items. Each item may indicate that instead of a match operation on the item being performed that an exclude operation is done instead.

Valid DiffServ DSCP values range from 0 to 63. VLANs are specified by VLAN group numbers which range from 1 to 4094. SSL profile names which are specified must already be configured in the system or they will be rejected.

At least one ssl profile name must be configured in the ssl-profiles parameter for SSL connections to be matched.

10.4.10.11 set service-class

Syntax: set service-class

-name “name”

[-acceleration {disk, flow-control, memory, none}]

[-traffic-shaping-policy {default, “policy”}]

[-per-link-policies (“link-name” “policy-name”),...]

Changes the definition of an existing service class. Double quotes can be used as delimiters for the service class name (which may contain spaces). At least one of the service class attributes must be set.

The specified traffic shaping policy will be used for this service class on all links. Per-link traffic shaping policies only need to be specified for links which have a traffic shaping policy that is different for this service class than the policy specified by the “-traffic-shaping-policy” setting.

10.4.10.12 set service-class-filter

Syntax: set service-class-filter


-filter-position “number”



[-bidirectional {enable, disable}]



[-applications {match-all, ([-exclude] “name”),...}]

[-source-ips {match-all, ([-exclude] “ip”),...}]

[-destination-ips {match-all, ([-exclude] “ip”),...}]

[-diffserv-dscps {{match-all, ([-exclude] “dscp”),...}]

[-vlans {match-all, ([-exclude] “vlan”),...}]

[-ssl-profiles {disable, ([-exclude] “profile”),...}]

Change the definition of the existing service class filter rule specified by the name and filter-position parameters. Valid filter positions range from 1 to N (where N is the number of filters in the current list).

Multiple filter settings may be changed at once and the other settings will be left unchanged. At least one of the service class filter attributes must be set.

If the bi-directional parameter is enabled then the filter will also match connection setup messages that have a source IP address that matches the filter’s destination-ips setting and a destination IP address that matches the filter’s source-ips setting. Please note that this setting only applies to which connections can be accelerated, it does not apply to traffic shaping.

Valid DiffServ DSCP values range from 0 to 63. VLANs are specified by VLAN group numbers which range from 1 to 4094. SSL profile names which are specified must already be configured in the system or they will be rejected.

10.4.11 Traffic Shaping Configuration

10.4.11.1 show traffic-shaping-policies

Syntax: show traffic-shaping-policies

Displays the summary list of traffic shaping policies.

10.4.11.2 show traffic-shaping-policy

Syntax: show traffic-shaping-policy

{-all, -id “id”, -name “name”}

Displays the detail information of one or all traffic shaping policies.

10.4.11.3 add traffic-shaping-policy

Syntax: add traffic-shaping-policy

-name “name”

-priority “integer”

[-ica-realtime-priority “integer”]

[-ica-interactive-priority “integer”]

[-ica-bulk-transfer-priority “integer”]

[-ica-background-priority “integer”]

[-optimize-voice {enable, disable}]

10-18 November 14, 2012


[-diffserv {“integer”, disabled}]

[-ica-realtime-diffserv {“integer”, disabled}]

[-ica-interactive-diffserv {“integer”, disabled}]

[-ica-bulk-transfer-diffserv {“integer”, disabled}]

[-ica-background-diffserv {“integer”, disabled}]

[-limit-bandwidth {by-percent, by-rate}

-max-in “integer” -max-out “integer”]

Add a new traffic shaping policy. Double quotes can be used as delimiters for the name (which may contain spaces).

Valid priority values range from 1 to 256. DiffServ values are specified by DSCP codes which range from 0 to 63. Bandwidth may be limited by percent which can range from 1 to 99 or by kbps rate which can range from 56 to 1000000.

10.4.11.4 set traffic-shaping-policy

Syntax: set traffic-shaping-policy

-name “name”

-priority “integer”

[-ica-priorities {enable, disable}]

[-ica-realtime-priority “integer”]

[-ica-interactive-priority “integer”]

[-ica-bulk-transfer-priority “integer”]

[-ica-background-priority “integer”]

[-optimize-voice {enable, disable}]

[-diffserv {“integer”, disabled}]

[-ica-diffserv {enable, disable}]

[-ica-realtime-diffserv {“integer”, disabled}]

[-ica-interactive-diffserv {“integer”, disabled}]

[-ica-bulk-transfer-diffserv {“integer”, disabled}]

[-ica-background-diffserv {“integer”, disabled}]

[-limit-bandwidth {by-percent, by-rate}

-max-in “integer” -max-out “integer”]

Modify an existing traffic shaping policy. Double quotes can be used as delimiters for the name (which may contain spaces).

Valid priority values range from 1 to 256. DiffServ values are specified by DSCP codes which range from 0 to 63. Bandwidth may be limited by percent which can range from 1 to 99 or by kbps rate which can range from 56 to 1000000.



10.4.11.5 rename traffic-shaping-policy

Syntax: rename traffic-shaping-policy

-old “oldname”

-new “newname”

Renames the specified traffic shaping policy.

10.4.12 remove traffic-shaping-policy

Syntax: remove traffic-shaping-policy


Remove one or all traffic shaping policies. Some traffic shaping policies (e.g. Default Traffic Shaping Policy) are not permitted to be removed.

10.4.12.1 clear traffic-shaping-policy-stats

Syntax: clear traffic-shaping-policy-stats

Resets all traffic shaping policy performance counters.

10.4.13 SNMP Configuration

10.4.13.1 show snmp

Syntax: show snmp

Reports then enabled/disabled status of the SNMP feature.

10.4.13.2 enable snmp

Syntax: enable snmp

Enables the SNMP feature.

10.4.13.3 disable snmp

Syntax: disable snmp

Disables the SNMP feature.

10.4.13.4 show snmp-system-mib

Syntax: show snmp-system-mib

Displays the current name, location, contact, and authentication failure trap settings.

10.4.13.5 set snmp-system-mib

Syntax: set snmp-system-mib

[-name “name”]

[-location “location”]

[-contact “name”]

[-auth-fail-trap {enable, disable}]

10-20 November 14, 2012


Sets the SNMP name of the appliance, its location, the contact person’s name, and whether to enable authentication failure traps. Double quotes can be used as delimiters for string fields (which may contain spaces).

10.4.13.6 show snmp-manager

Syntax: show snmp-manager

[-id “id”]

Displays the current SNMP manager entries. If -id is specified, only that SNMP manager is displayed.

10.4.13.7 add snmp-manager

Syntax: add snmp-manager

-community “name”

-ip “addr”

[-netmask {0, 4, 8, 12, 16, 20, 24, 28, 32}]

Enables access to SNMP functions by remote systems on the specified subnets and with the specified community name. Double quotes can be used as delimiters for string fields (which may contain spaces).

10.4.13.8 remove snmp-manager

Syntax: remove snmp-manager

{-all, -id “number”}

Syntax: remove snmp-manager

-community “name”

-ip “addr”

[-netmask {0, 4, 8, 12, 16, 20, 24, 28, 32}]

Removes the specified SNMP manager entry, or all SNMP manager entries. Double quotes can be used as delimiters for string fields (which may contain spaces).

10.4.13.9 show snmp-trapdest

Syntax: show snmp-trapdest

-id “id”

Displays the SNMP trap destination entry at position “id.”

10.4.13.10 add snmp-trapdest

Syntax: add snmp-trapdest

-name “name”

-ip “addr”

[-port “port”]

[-version {v1, v2c}]



Adds a new SNMP trap destination. Double quotes can be used as delimiters for string fields (which may contain spaces).

10.4.13.11 remove snmp-trapdest

Syntax: remove snmp-trapdest

{-all, -name “name”, -id “id”}

Removes the SNMP trap destination define by name or ID, or all SNMP trap destinations. Double quotes can be used as delimiters for string fields (which may contain spaces).

10.4.14 Alert Configuration

10.4.14.1 show alert-configuration

Syntax: show alert-configuration

[-name “alertname”]

Syntax: show alert-configuration

-retention

Displays the settings of the Alert system, or optionally of a single, named Alert. Equivalent to the information on the Alert Configuration page. With -retention, the Alert Retention Time is displayed.

10.4.14.2 set alert-configuration

Syntax: set alert-configuration

{-retention “seconds” , -verbose {enable, disable}}

Syntax: set alert-configuration

-name “name”

-level {alerted, logged, disable, default}

[-threshold “integer”]

Sets parameters for individual, named Alerts, or sets global parameters. Equivalent to the Alert Configuration page. The -retention option sets the alert timeout value in seconds, while the -verbose option allows verbose or non-verbose reporting to be selected. The -threshold option is used to specify alerting thresholds. Not all alerts support a threshold.

10.4.14.3 reset alert-configuration

Syntax: reset alert-configuration

Sets all Alerts to factory defaults.

10.4.15 Alert Management

10.4.15.1 clear alert

Syntax: clear alert

10-22 November 14, 2012


{-all, -id “id”}

This command will clear an alert, or all alerts if -all is specified.

10.4.15.2 show alerts

Syntax: show alerts

This command will show the current alerts.

10.4.16 WCCP Configuration

10.4.16.1 show wccp

Syntax: show wccp

[-id “id”]

Displays the current settings for all WCCP service groups, or optionally only for the service group specified with -id.

10.4.16.2 enable wccp

Syntax: enable wccp

Global WCCP enable. Not effective unless acceleration is enabled and at least one WCCP service group is defined.

10.4.16.3 disable wccp

Syntax: disable wccp

Global WCCP disable.

10.4.16.4 add wccp

Adds a new WCCP service-group definition. The parameters are the same as those on the WCCP Configuration page on the Web UI.

Syntax: add wccp

-id “id”

[-accelerated-pair {apa, apb}]

-router-communication unicast

-address “addr1[,...,addrN]”

[-router-assignment {hash, mask, auto}]

[-router-forwarding {auto, gre, level-2}]

[-state {enable, disable}]

[-priority “number”]

[-protocol {tcp, udp}]

Syntax: add wccp

-id “id”




-router-communication multicast

-address “addr”



[-router-return {auto, gre, level-2}]

[-time-to-live “number”]




Default values for the optional parameters are as follows:

-accelerated-pair = apa

-router-assignment = hash

-router-forwarding = auto

-router-return = auto

-time-to-live = 1

-state = enable

-priority = 0

-protocol = tcp

10.4.16.5 set wccp

Syntax: set wccp

-id “id”


[

-router-communication unicast

-address “addr1[,...,addrN]”

]






Syntax: set wccp

-id “id”

10-24 November 14, 2012



[

-router-communication multicast

-address “addr”

]



[-router-return {auto, gre, level-2}]

[-time-to-live “number”]




Alters an existing WCCP service-group definition. The parameters are the same as those on the WCCP Configuration page on the Web UI.

10.4.16.6 remove wccp

Syntax: remove wccp

{-all , -id “num”}

Deletes all WCCP service groups or (with -id) only the specified service group number.

10.4.17 Logging

10.4.17.1 show syslog

Syntax: show syslog

Displays the current syslog parameters.

10.4.17.2 set syslog

Syntax: set syslog

-ip “addr”

[-port “port”]

Sets the IP address of the syslog server, and optionally the port number.

10.4.17.3 enable syslog

Syntax: enable syslog

Enables syslog logging.

10.4.17.4 disable syslog

Syntax: disable syslog



Disable syslog logging.

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

10.4.17.6 set log

Syntax: set log

[-max-size “megabytes”]

[-display-lines “lines”]

[-max-export-lines “lines”]

[-system {enable, disable}]

[-adapter {enable, disable}]

[-flow {enable, disable}]

[-connection {enable, disable}]

[-openclose {enable, disable}]

[-text {enable, disable}]

[-alert {enable, disable}]

Sets the display parameters for the View Logs page. The settings here correspond to those on the Configure Logs page.

10.4.17.7 extract log

Syntax: extract log

-by-record

-from “number”

-to “number”

-records “number”

-format {text, xml}

-type {system, adapter, slow-flow, fast-flow, flow, connection,

open, close, open-close, text, alert, all}

-eol {lf, crlf, cr}

[-file filename]

Syntax: extract log

10-26 November 14, 2012


-by-datetime

-from “yyyy-mm-dd” [“hh:mm[:ss]”]

-to “yyyy-mm-dd” [“hh:mm[:ss]”]

-records “number”

-format {text, xml}

-type {system, adapter, slow-flow, fast-flow, flow, connection,

open, close, open-close, text, alert, all}

-eol {lf, crlf, cr}

[-file “filename”]

Extracts the selected records to file “filename.” This command has the same parameters as that on the View Logs page on the Web UI.

10.4.17.8 clear logs

Syntax: clear logs

Removes all log records, similar to the “Remove All Log Records” button in the Web UI.

10.4.17.9 list log-extracted-files

Syntax: list log-extracted-files

Displays a list of log files saved by the “extract log” command.

10.4.18 Proxy Configuration

10.4.18.1 show proxy

Syntax: show proxy

Displays the current proxy definitions.

10.4.18.2 add proxy

Syntax: add proxy

-local “local vipaddr”

-target {“target ipaddr”, “host”)

[-description “description”]

Adds a new proxy definition. This command has the same parameters as that on the Proxy page on the Web UI.

10.4.18.3 remove proxy

Syntax: remove proxy

{-all, -local “vipaddr”}



Removes a proxy definition. -local specifies which proxy definition to remove. -all specifies that all proxy definitions should be removed.

10.4.19 Client Configuration

10.4.19.1 show client-rule

Syntax: show client-rule

[-id “id”]

Displays a client acceleration rule. If -id is omitted, all client rules are displayed.

10.4.19.2 add client-rule

Syntax: add client-rule

-type {accelerate, exclude}

-subnet {*, “subnet”}

-ports {*, “port-range”}

Adds a client acceleration rule. This command has the same parameters as those on the Client Acceleration Rules page of the Web UI.

10.4.19.3 remove client-rule

Syntax: remove client-rule


Removes a client acceleration rule. -id specifies which rule to remove. -all specifies that all rules should be removed.

10.4.19.4 show signaling-channel

Syntax: show signaling-channel

Displays the Client Signaling Channel options.

10.4.19.5 enable signaling-channel

Syntax: enable signaling-channel

Enables the Client Signaling Channel.

10.4.19.6 disable signaling-channel

Syntax: disable signaling-channel

Disables the Client Signaling Channel.

10.4.19.7 set signaling-channel

Syntax: set signaling-channel

[-ip “ipaddr”]

[-port “port”]

[-mode {redirector, transparent}]

10-28 November 14, 2012


Sets the Client Signaling Channel options. This command has the same parameters as those on the Client Signaling Channel Configuration page of the Web UI.

10.4.19.8 show client-settings

Syntax: show client-settings

Displays the Client General Configuration options.

10.4.19.9 set client-settings

Syntax: set client-settings

[-upgrade-notify {enable, disable}]

[-upgrade-url “url”]

[-diag-ftp-server “server”]

[-diag-ftp-port “port”]

[-diag-ftp-user “user”]

[-diag-ftp-password “password”]

[-diag-ftp-directory “directory”]

[-diag-email “email”]

[-diag-popups {enable, disable}]

[-diag-uploads {enable, disable}]

Sets the Client General Configuration options. This command has the same parameters as those on the Client General Configuration page of the Web UI.

10.4.20 Group Mode Configuration

10.4.20.1 show group-mode

Syntax: show group-mode

[-type {local, peers, rules}]

Displays the group mode configuration.

10.4.20.2 enable group-mode

Syntax: enable group-mode

Enables group mode.


-type peer

-member-ip “ipaddr”

Enables a group mode peer. -member-ip specifies which peer to enable.


-type rule




Enables a group forwarding rule. -id specifies which rule to enable. -all specifies that all rules should be enabled.

10.4.20.3 disable group-mode

Syntax: disable group-mode

Disables group mode.


-type peer


Disables a group mode peer. -member-ip specifies which peer to disable.


-type rule

{-all, -id “id” }

Disables a group forwarding rule. -id specifies which rule to disable. -all specifies that all rules should be disabled.

10.4.20.4 set group-mode

Syntax: set group-mode

[-accelerate-with-failure {enable, disable}]

[-forward-loop-prevention {enable, disable}]

Enables or disables group mode options. This command has the same parameters as that on the Group Mode page on the Web UI.

Syntax: set group-mode

-type local

-adapter {apa, apb, primary}

Sets the adapter parameter of the local group mode. This command has the same parameters as that on the Group Mode page on the Web UI.

10.4.20.5 add group-mode

Syntax: add group-mode

-type peer


-state {enable, disable}

-common-name “name”

[-ha-common-name “name”]

Adds a group mode peer. This command has the same parameters as that on the Group Mode page on the Web UI.

10-30 November 14, 2012


Syntax: add group-mode

-type rule


-subnet “subnet”

-ports “port-range”

[-forwarded-if {match, not-match}]


Adds a group forwarding rule. This command has the same parameters as that on the Group Mode page on the Web UI.

10.4.20.6 remove group-mode

Syntax: remove group-mode

-type peer

{-all, -member-ip “ipaddr”}

Removes a group mode peer. -member-ip specifies which peer to remove. -all specifies that all peers should be removed.

Syntax: remove group-mode

-type rule


Removes a group forwarding rule. -id specifies which rule to remove. -all specifies that all rules should be removed.

10.4.21 SSL Configuration

10.4.21.1 add ssl-profile

Syntax: add ssl-profile

-name “profile-name”


-proxy-type transparent

[-virtual-hostname “hostname”]

-private-key “private-key-name”

Adds an SSL profile for transparent proxy mode. This command has the same parameters as that on the Profile tab of the SSL Settings page on the Web UI.

Syntax: add ssl-profile



-proxy-type split




-cert-key “cert-key-pair-name”

[-build-cert-chain {enable, disable}]

[-cert-chain-store {use-all-configured-CA-stores, “store-name”}]

[-cert-verification {none, Signature/Expiration, Signature/Expiration/Common-Name-White-List, Signature/Expiration/Common-Name-Black-List}]

[-verification-store {use-all-configured-CA-stores, “store-name”}]

[-server-side-protocol {SSL-version-2, SSL-version-3, SSL-version-2-3-OR-TLS-1.0, TLS-1.0}]

[-server-side-ciphers “ciphers”]

[-server-side-authentication {enable, disable}]

[-server-side-cert-key “cert-key-pair-name”]

[-server-side-build-cert-chain {enable, disable}]

[-server-side-renegotiation {disable-old-style, enable-old-style, new-style, compatible}]

[-client-side-protocol-version {SSL-version-2, SSL-version-3, SSL-version-2-3-OR-TLS-1.0, TLS-1.0}]

[-client-side-ciphers “ciphers”]

[-client-side-renegotiation {disable-old-style, enable-old-style, new-style, compatible}]

Adds an SSL profile for split proxy mode. This command has the same parameters as that on the Profile tab of the SSL Settings page on the Web UI.

10.4.21.2 set ssl-profile

Syntax: set ssl-profile



[-proxy-type transparent]


[-private-key “private-key-name”]

Modifies an SSL profile created for transparent proxy mode.

Syntax: set ssl-profile



[-proxy-type split]


[-cert-key “cert-key-pair-name”]

10-32 November 14, 2012


[-build-cert-chain {enable, disable}]

[-cert-chain-store {use-all-configured-CA-stores, “store-name”}]

[-cert-verification {none, Signature/Expiration, Signature/Expiration/Common-Name-White-List, Signature/Expiration/Common-Name-Black-List}]

[-verification-store {use-all-configured-CA-stores, “store-name”}]

[-server-side-protocol {SSL-version-2, SSL-version-3, SSL-version-2-3-OR-TLS-1.0, TLS-1.0}]

[-server-side-ciphers “ciphers”]

[-server-side-authentication {enable, disable}]

[-server-side-cert-key “cert-key-pair-name”]

[-server-side-build-cert-chain {enable, disable}]

[-server-side-renegotiation {disable-old-style, enable-old-style, new-style, compatible}]

[-client-side-protocol-version {SSL-version-2, SSL-version-3, SSL-version-2-3-OR-TLS-1.0, TLS-1.0}]

[-client-side-ciphers “ciphers”]

[-client-side-renegotiation {disable-old-style, enable-old-style, new-style, compatible}]

Modifies an SSL profile created for split proxy mode.

10.4.21.3 show ssl-profiles

Syntax: show ssl-profiles

Shows name, profile type, and state of all SSL profiles created.

10.4.21.4 show ssl-profile

Syntax: show ssl-profile

{-id “id”, -name “profile-name”}

Show profile detail by id or profile name.

10.4.21.5 remove ssl-profile

Syntax: remove ssl-profiles

{-all, -id “id”, -name “profile-name”}

Removes SSL profile. -id and -name specifies which profile to remove. -all specifies that all profiles are to be removed.

10.4.21.6 rename ssl-profile

Syntax: rename ssl-profiles

-old “old-profile-name”

-new “new-profile-name”



Changes an SSL profile name.

10.4.21.7 show ssl-optimization

Syntax: show ssl-optimization

Shows SSL optimization status.

10.4.21.8 enable ssl-optimization

Syntax: enable ssl-optimization

Enables SSL optimization feature.

10.4.21.9 disable ssl-optimization

Syntax: disable ssl-optimization

Disables SSL optimization feature.

10.4.21.10 show ssl-secure-peer-connections

Syntax: show ssl-secure-peer-connections

Shows SSL peer configuration.

10.4.21.11 show ssl-ca-store

Syntax: show ssl-ca-store

-name “ca-store-name”

Shows detail information on the SSL CA certificate.

10.4.21.12 show ssl-ca-stores

Syntax: show ssl-ca-stores

Shows summary information (name, expiration date, certificate count) on all SSL Cetificate Authority certificates.

10.4.21.13 show ssl-cert-key-pair

Syntax: show ssl-cert-key-pair

-name “cert-key-pair-name”

Shows detail information on the SSL certificate/key pair.

10.4.21.14 show ssl-cert-key-pairs

Syntax: show ssl-cert-key-pairs

Shows summary information (name, expiration date, certificate count, key type) on all configured SSL certificate/key pairs.

10.4.21.15 show ssl-disk-encryption

Syntax: show ssl-disk-encryption

Shows user data store encryption status

10-34 November 14, 2012


10.4.21.16 show ssl-keystore

Syntax: show ssl-keystore

Shows encryption key store status.

10.4.21.17 show ssl-peer-auto-discovery

Syntax: show ssl-peer-auto-discovery

Shows SSL peer auto-discovery configuration.

10.4.21.18 show ssl-peer-connect-to

Syntax: show ssl-peer-connect-to

Shows SSL peer connect to configuration.

10.4.21.19 show ssl-peer-listen-on

Syntax: show ssl-peer-listen-on

Shows SSL peer listen on configuration.

10.4.21.20 add ssl-ca-store

Syntax: add ssl-ca-store

[-name “name”]

-file “ca-certificate-filename”

Adds an SSL CA certificate store.

10.4.21.21 remove ssl-ca-store

Syntax: remove ssl-ca-store

-name “name”

Removes an SSL CA certificate store.

10.4.21.22 add ssl-cert-key-pair

Syntax: add ssl-cert-key-pair

-name “certificate/key-pair-name”

{(-type combined

-file “certificate/key-pair-filename”),

(-type separate

-key-file “key-filename”

-cert-file “cert-filename”)}

[-key-password “password”]

[-file-password “password”]

Adds an SSL certificate authority certificate store.



10.4.21.23 remove ssl-cert-key-pair

Syntax: remove ssl-cert-key-pair


Removes an SSL certificate authority certificate store.

10.4.21.24 add ssl-peer-auto-discovery-publish-item

Syntax: add ssl-peer-auto-discovery-publish-item

-ip-port “ipaddr:port”

Publishes a NAT IP address/port entry.

10.4.21.25 remove ssl-peer-auto-discovery-publish-item

Syntax: remove ssl-peer-auto-discovery-publish-item

{-all, -ip-port “ipaddr:port”}

Removes one or all NAT IP address/port entries.

10.4.21.26 add ssl-peer-connect-to-item

Syntax: add ssl-peer-connect-to-item


Adds an SSL peer IP address/port to be connected to.

10.4.21.27 remove ssl-peer-connect-to-item

Syntax: remove ssl-peer-connect-to-item


Removes one or all SSL peer IP address/port entries.

10.4.21.28 add ssl-peer-listen-on-item

Syntax: add ssl-peer-listen-on-item


Adds an SSL peer listen on Repeater IP address/port.

10.4.21.29 remove ssl-peer-listen-on-item

Syntax: remove ssl-peer-listen-on-item


Removes one or all SSL peer listen on Repeater IP address/port entries.

10.4.21.30 add ssl-secure-peer-connections-item

Syntax: add ssl-secure-peer-connections-item

-cert-verification Signature/Expiration/Common-Name-Black-List

-item “black-list-item”

10-36 November 14, 2012


Adds an additional SSL peer security black list item. The first black list item was configured with the ‘set ssl-secure-peer-connections’ command.

Syntax: add ssl-secure-peer-connections-item

-cert-verification Signature/Expiration/Common-Name-White-List

-item “white-list-item”

Adds an additional SSL peer security white list item. The first white list item was configured with the ‘set ssl-secure-peer-connections’ command.

10.4.21.31 remove ssl-secure-peer-connections-item

Syntax: remove ssl-secure-peer-connections-item

{-all, -item “list-item”}

Removes one or all SSL peer security white list or black list entries.

10.4.21.32 set ssl-cert-key-pair

Syntax: set ssl-cert-key-pair


-action {add|replace}

-cert-key {DSA|RSA}

{(-type combined

-file “certificate/key-pair-filename”),

(-type separate

-key-file “key-filename”

-cert-file “cert-filename”)}

[-key-password “password”]

[-file-password “password”]

Adds or replaces a DSA/RSA certificate/key.

10.4.21.33 set ssl-keystore

Syntax: set ssl-keystore

-password “new-password”

-old-password “old-password”

10.4.21.34 set ssl-secure-peer-connections

Syntax: set ssl-secure-peer-connections

-cert-key-name “cert-key-name”

-ca-cert-store “ca-cert-store-name”

-cert-verification {None,Signature}

-cipher “ssl-cipher-specification”



Specifies the SSL peer configuration.




-cert-verification Signature/Expiration/Common-Name-Black-List

-item “black-list-item-1”


Specifies the SSL peer configuration, where peer security ceritficate verification is a black list. The first black list entry is specified here, additional entries may be added using the ‘add ssl-secure-peer-connections-item’ command.




-cert-verification Signature/Expiration/Common-Name-White-List

-item “white-list-item-1”


Specifies the SSL peer configuration, where peer security ceritficate verification is a white list. The first white list entry is specified here, additional entries may be added using the ‘add ssl-secure-peer-connections-item’ command.

10.4.22 Test Mode commands

10.4.22.1 clear compression-stats

Syntax: clear compression-stats

This command will clear the compression statistics, similar to the “Clear” button in the “Compression Status” section of the Web UI.

10.4.22.2 clear compression-history

Syntax: clear compression-history

This command will reset the compression history content, similar to a “Compressionhistory content_reset” command given to console.php.

10.4.22.3 show object

Syntax: show object -class “class” [-name “name”]

This command shows the current value of a parameter or system object.

10.4.22.4 set object

Syntax: set object -class “class” -name “name” -value “value”

This command sets the value of a parameter or system object.

10-38 November 14, 2012


10.4.23 Alert Configuration

10.4.23.1 clear application-counters

Syntax: clear application-counters

Resets all application performance counters.

10.4.23.2 show applications

Syntax: show applications

This command shows the list of configured applications

10.4.23.3 show application

Syntax: show application

{-all, -name “name”, -id “id”, -group “application group”}

This command shows the configuration information of the selected application. The parameter -id selects the application listed on the show applications output.

10.4.23.4 add application

Syntax: add application

-name “name”


[-group “application group”]

[-classification-type “ethertype, ica-published-app, ip, tcp, udp, web-address”]

[-classification-parameters “classification parameters”]

This command creates a new application.

10.4.23.5 rename application

Syntax: show application

-old “old-application-name”

-new “new-application-name”

This command changes the application name.

10.4.23.6 remove application

Syntax: remove application


This command removes the configured application.

10.4.23.7 set application

Syntax: set application

-name “name”




[-group “application group”]

[-classification-type “ethertype, ica-published-app, ip, tcp, udp, web-address”]

[-classification-parameters “classification paramenters”]

This command changes the configuration of an application.

10-40 November 14, 2012

Chapter 11

Specifications and Support

Figure 11-1 Specifications for Repeater Appliances

Physical1U Units: Repeater 65xx and

85xx2U Units: Repeater 68xx and

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 Temperature

50°F to 95°F (10C to 35C) 50°F to 95°F (10C to 35C)

Storage Temperature

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

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

– {� »• i‚ É“ � «‚ µ‚ Ä‚ ¢‚ é“ dŒ ¹ƒ R� [ƒ hƒ Zƒ bƒ g‚ Í� A– {� »• i� ê— p‚ Å‚ ·� B “ dŒ ¹ƒ R� [ƒ hƒ Zƒ bƒ g‚ Í� A– {� »• i ÈŠ O‚ Ì� »• i‚ È‚ ç‚ Ñ‚ É‘ ¼‚ Ì— p“ r‚ ÅŽ g— p‚ ¢‚ ½‚ ¾‚ -‚ ±‚ Æ‚ Í� o— ‚ Ü‚ ¹‚ ñ� B� »• i– {‘ Ì‚ É‚ Í“ � «‚ ³‚ ê‚ ½“ dŒ ¹ƒ R� [ƒ hƒ Zƒ bƒ g‚ ðŽ g— p‚ µ� A‘ ¼� »• i‚ Ì“ dŒ ¹ƒ R� [ƒ hƒ Zƒ bƒ g‚ ðŽ g— p‚ µ‚ È‚ ¢‚ Å‚ -‚ ¾‚ ³‚ ¢� B ‚ ±‚ Ì� ‘– Ê‚ Í� A‚ ‚ -‚ Ü‚ Å‚ àŽ æ? » ¡– ¾� ‘‚ Ì’ Ç‹ L‚ ‚ é‚ ¢‚ Í• Ê� û‚ Ì Ê’ u• t‚ ‚ Æ‚ È‚ éŽ –‚ ð— \‚ ß‚ ²— ¹� ³‚ -‚ ¾‚ ³‚ ¢� B Citrix System, Inc. 883-00002-00

11-2 November 14, 2012

http://www.citrix.com

http://citrix.com/site/resources/dynamic/sup2nd/Citrix_HWS_SerialNO.pdf

http://citrix.com/site/resources/dynamic/sup2nd/Citrix_HWS_SerialNO.pdf

Citrix Branch Repeater Family™ Branch Repeater Family™ Installation and User’s Guide Release...

Documents

Transcript of Citrix Branch Repeater Family™ Branch Repeater Family™ Installation and User’s Guide Release...