XIPLink User Guide XIP OS

XipOS User Manual

XipOS: User Manual Release 4.0.2 Copyright © 2013 XipLink Inc All rights reserved. Reproduction in whole or in part without permission is prohibited. Information contained herein is subject to change without notice. The specifications and information regarding the products in this document are subject to change without notice. All statements, information, and recommendations in this document are believed to be accurate, but are presented without warranty of any kind, express, or implied. Users must take full responsibility for their application of any products. Trademarks, brand names and products mentioned in this document are the property of their respective owners. All such references are used strictly in an editorial fashion with no intent to convey any affiliation with the name or the product's rightful owner.

Table of Contents 1. XipLink Optimization Technology Overview ....................................................................... 1 1.1. Introduction ......................................................................................................... 1 1.2. Background ......................................................................................................... 2 1.3. The XipLink Advantage ........................................................................................ 2 1.3.1. Protocol Acceleration .................................................................................. 3 1.3.2. Advanced Compression ............................................................................... 3 1.3.3. Internet Optimization .................................................................................. 3 1.3.4. Security .................................................................................................... 4 1.3.5. Quality of Service ...................................................................................... 4 1.3.6. XipOS ..................................................................................................... 4 1.4. Supported Capabilities ........................................................................................... 4 1.4.1. TCP Acceleration Techniques ...................................................................... 4 1.4.2. UDP Acceleration Techniques ...................................................................... 4 1.4.3. Compression and Application Acceleration ..................................................... 5 1.4.4. Tunnelling Options ..................................................................................... 5 1.4.5. Network Appliance Benefits ........................................................................ 5 1.4.6. Standards Support and Interoperability ........................................................... 5 1.4.7. RFC and TCP Enhancements Support ............................................................ 6 1.5. Document Overview ............................................................................................. 6 1.5.1. Conventions used in this Manual .................................................................. 7 2. Quick Start - XA Series ................................................................................................... 8 2.1. Unpacking and Box Contents ................................................................................. 8 2.2. Placing the Optimizer in the Network ...................................................................... 8 2.2.1. Physical Connections .................................................................................. 9 2.3. Accessing the XipOS Web User Interface ............................................................... 10 2.4. Login ................................................................................................................ 10 2.5. XipLink Setup Wizard ......................................................................................... 11 2.5.1. Welcome ................................................................................................ 11 2.5.2. Select Deployment Options ........................................................................ 12 2.5.3. Configure Network Interfaces ..................................................................... 13 2.5.4. Configure DNS ........................................................................................ 15 2.5.5. Configure Networks .................................................................................. 15 2.5.6. Set Password ........................................................................................... 17 2.5.7. Apply Changes To Device Configuration ...................................................... 17 3. Understanding XipLink Optimization ................................................................................ 18 3.1. Dynamic Transparent Negotiation of Optimization Capabilities ................................... 18 3.2. SCPS Protocol Acceleration .................................................................................. 19 3.3. XipLink Transport Control (XTC) Modes ............................................................... 20 3.3.1. XTC - Fixed Rate Control Mode ................................................................. 20 3.3.2. XTC - Dynamic Rate Control Mode ............................................................ 21 3.3.3. XTC - Programmable Fixed Rate Control Mode ............................................. 22 3.3.4. XTC - Enhanced TCP Mode ...................................................................... 22 3.4. Additional TCP Protocol Acceleration Techniques .................................................... 22 3.4.1. TCP Connection Fast Start ......................................................................... 22 3.4.2. Acknowledgement Frequency Reduction (AFR) ............................................. 23 3.4.3. Selective Negative Acknowledgments .......................................................... 23 3.4.4. Quality of Service .................................................................................... 24 3.4.5. Streaming Data Compression ...................................................................... 26 3.4.6. XipOS Tunnelling .................................................................................... 28 3.5. XipLink Hub Optimizations .................................................................................. 28 3.5.1. XiPix Image Compression ......................................................................... 29 3.5.2. HTTP Compression .................................................................................. 29

iii

XipOS

3.6. XipLink Real-Time (XRT) ................................................................................... 3.7. Byte Caching ..................................................................................................... 3.8. Packet Compression ............................................................................................ 3.8.1. Advanced Cellular Compression ................................................................. 3.9. Link Balancing and Bonding ................................................................................ 3.10. Web Cache Communication Protocol .................................................................... 3.10.1. WCCP Deployments ............................................................................... 3.10.2. WCCP Configuration Concepts ................................................................. 3.11. XipLink Wireless Optimizer Internals ................................................................... 3.11.1. Dynamic Socket Buffers .......................................................................... 3.11.2. Burst Connection Handling ....................................................................... 3.11.3. Installation Flexibility .............................................................................. 3.11.4. Management and Monitoring .................................................................... 4. The XipOS Web Interface .............................................................................................. 4.1. Dashboard ......................................................................................................... 4.1.1. Device Name ........................................................................................... 4.1.2. Interface Status ........................................................................................ 4.1.3. Service Status .......................................................................................... 4.1.4. Device Status .......................................................................................... 4.1.5. Sampling Rate ......................................................................................... 4.2. Main Menu ........................................................................................................ 4.3. Applying Changes .............................................................................................. 4.4. Networking Setup ............................................................................................... 4.4.1. Mode ..................................................................................................... 4.4.2. Interfaces ................................................................................................ 4.4.3. DNS ...................................................................................................... 4.4.4. Routes .................................................................................................... 4.4.5. RIP ........................................................................................................ 4.4.6. OSPF ..................................................................................................... 4.4.7. BGP ....................................................................................................... 4.4.8. DHCP .................................................................................................... 4.4.9. SNMP .................................................................................................... 4.4.10. WCCP .................................................................................................. 4.4.11. Redundancy ........................................................................................... 4.5. Optimization ...................................................................................................... 4.5.1. Optimization ............................................................................................ 4.5.2. Networks ................................................................................................ 4.5.3. Service Assignment .................................................................................. 4.5.4. Traffic Assignment ................................................................................... 4.5.5. Lightweight Tunnels ................................................................................. 4.5.6. Link Balancing ........................................................................................ 4.5.7. Web Cache ............................................................................................. 4.6. System .............................................................................................................. 4.6.1. Support & Docs ....................................................................................... 4.6.2. Logs ...................................................................................................... 4.6.3. Stats ....................................................................................................... 4.6.4. Users ..................................................................................................... 4.6.5. Time ...................................................................................................... 4.6.6. Backup ................................................................................................... 4.6.7. Upgrade .................................................................................................. 4.6.8. Reboot ................................................................................................... 4.6.9. Files ....................................................................................................... 4.6.10. Diagnostics ............................................................................................ 4.6.11. Debugging .............................................................................................

iv

29 31 31 31 32 32 33 34 40 40 40 41 41 42 42 42 42 42 43 43 43 44 45 45 47 48 50 51 52 53 54 55 57 59 62 62 64 70 73 76 79 80 83 83 83 84 85 86 87 88 91 92 94 95

XipOS

5. Redundancy Deployment Options .................................................................................... 96 5.1. Router mode Redundancy using CARP .................................................................. 96 5.2. Bridge mode with STP failover ............................................................................. 96 5.3. Bridge mode with fail-to-wire ............................................................................... 97 6. Monitoring and Statistics ................................................................................................ 98 6.1. Optimizer Montoring Tool .................................................................................... 98 6.1.1. Graph Controls ........................................................................................ 99 6.2. Monitored Data Sets ............................................................................................ 99 7. XipOS Command Line Interface .................................................................................... 101 7.1. Introduction ..................................................................................................... 101 7.2. Factory Reset ................................................................................................... 102 7.2.1. Accessing the Factory Reset Menu ............................................................. 102 7.2.2. Factory Reset Menu ................................................................................ 102 8. Advanced Upgrade Procedures ....................................................................................... 103 8.1. Manual Upgrade via CLI .................................................................................... 103 8.2. Replacing the Compact Flash Card ....................................................................... 103 8.2.1. Equipment Required ................................................................................ 104 8.2.2. Procedure .............................................................................................. 104 9. Troubleshooting and Diagnostic Tools ............................................................................. 107 9.1. Netconf Errors .................................................................................................. 107 9.2. System Logs .................................................................................................... 108 9.2.1. The System Log File ............................................................................... 108 9.2.2. The Netconf Log File .............................................................................. 108 9.3. Diagnostic Tools ............................................................................................... 109 9.3.1. netstat ................................................................................................... 109 9.3.2. Quality of Service Queue Control .............................................................. 111 10. Support .................................................................................................................... 113 10.1. Support Resources ........................................................................................... 113 10.2. Return Procedures ........................................................................................... 114 10.3. Frequently asked Questions ............................................................................... 115 11. Appendixes .............................................................................................................. 118 11.1. XipLink Product Matrix .................................................................................... 118 Glossary of Terms ........................................................................................................... 120

v

List of Figures 1.1. XipLink Interoperability between devices ......................................................................... 1 1.2. XipOS ........................................................................................................................ 2 2.1. Placement of the Optimizer ............................................................................................ 8 2.2. XA-500 ...................................................................................................................... 9 2.3. XA-2000 ..................................................................................................................... 9 2.4. XA-4000 | XA-10K ..................................................................................................... 9 2.5. XA-30K ...................................................................................................................... 9 3.1. Dynamically negotiated optimization .............................................................................. 18 3.2. Unoptimized connections using standard TCP .................................................................. 19 3.3. XTC – Fixed Rate Control ........................................................................................... 20 3.4. XTC - Dynamic Rate Control Mode .............................................................................. 21 3.5. XTC - Programmable Fixed Rate Control Mode ............................................................... 22 3.6. TCP Connection Fast Start ........................................................................................... 23 3.7. AFR and Selective Negative Acknowledgments ............................................................... 24 3.8. QoS Re-Prioritizes Traffic ............................................................................................ 25 3.9. Streaming Data Compression ........................................................................................ 27 3.10. Compression Samples ................................................................................................ 28 3.11. XRT Packet Coalescing .............................................................................................. 30 3.12. Basic Single Interface Mode WCCP Deployment ............................................................ 33 3.13. Basic Router Mode WCCP Deployment ........................................................................ 33 3.14. WCCP Hub Deployment ............................................................................................ 34 3.15. WCCP Service Groups ............................................................................................... 35 3.16. Bridge at remote - Router at hub ................................................................................. 41 4.1. Router Mode Redundancy Setup ................................................................................... 60 5.1. Router Mode Redundancy Setup ................................................................................... 96 5.2. Bridge Mode Redundancy Setup ................................................................................... 97 5.3. Fail-to-wire Diagram ................................................................................................... 97

vi

List of Tables 1.1. SCPS-TP Capabilities .................................................................................................... 5 1.2. HTTP RFC's ................................................................................................................ 5 2.1. Factory default IP addresses ......................................................................................... 10 3.1. XRT: Benefit of Coalescing Multiple Streams .................................................................. 30 3.2. XRT: Effect of Different Capture Window Sizes .............................................................. 30 4.1. Differences Between Router, Bridge and Single Interface Modes ......................................... 46 4.2. XipOS SNMP Traps .................................................................................................... 56 11.1. XipLink XA Product Matrix ...................................................................................... 118

vii

List of Examples 4.1. 9.1. 9.2. 9.3. 9.4.

Multi-Link / Multi-Site Network Example ....................................................................... 66 netstat Active Connections .......................................................................................... 110 netstat -e DSB Output ................................................................................................ 110 Sample netstat -s -p scps Output .................................................................................. 111 Using pfctl to View QoS Queue Status ......................................................................... 111

viii

Chapter 1. XipLink Optimization Technology Overview 1.1. Introduction XipLink delivers wireless optimization technology in many flexible ways: • The XE-Series provide portable optimization software for any BSD, Linux or Windows based devices. • The XE-104 is a preloaded single board computer optimizer. • The XA-Series are scalable appliances that deliver optimization from 2 to 155 Mbps. Wireless optimization functions described in this overview operate transparently between users communicating across any two wireless IP networks that have optimization installed. For example, users on an aircraft with XE-Series software embedded in the airborne satellite modem will have their traffic transparently optimized when the connection request encounters an XA-Series appliance installed at the service provider's hub site. Embedded XipLink software interoperates with any other XipOS enabled device.

Figure 1.1. XipLink Interoperability between devices

The challenges of wireless optimization for satellite and terrestrial communication links are significantly different from traditional WAN optimization controllers or application accelerators: • Wireless is a medium that experiences much higher latency and loss. • The price per bit on wireless links, especially over satellites, is much higher. • The ROI on improved use of the capacity is short, often measured in months.

1

XipLink Optimization Technology Overview

1.2. Background XipLink Optimization Software algorithms originate with aerospace research originally intended to increase the communications throughput between spacecraft and the Earth. It was quickly recognized that these same techniques work equally well when optimizing the complete end-to-end wireless link from ground station to ground station. Researchers were also pleasantly surprised by the fact that the techniques had virtually no negative effects on traditional TCP-based applications. This pioneering work resulted in standards from NASA and other space agencies collectively called the Space Communications Protocol Specification (SCPS) and, subsequently a standard named Interoperable Performance Enhancing Proxy (I-PEP). The SCPS (pronounced “skips”) specification combines recommendations for the use of several standard IETF TCP enhancements as well as methods for the dynamic and transparent negotiation of options like special TCP acknowledgement schemes and data compression. The I-PEP standard, which builds on SCPS, is designed specifically for satellite communication profiles but also enables the negotiation of innovative vendor proprietary algorithms. This was a primary intention of the standard, and remains a key to its continued use and recent compliance mandates by the U.S. Department of Defense. While the IETF has introduced some standards for TCP improvement over the years, the SCPS based protocol, along with specialized wireless optimization algorithms originally designed by vendors for space communications, continue to deliver the most advanced wireless optimization capabilities available today. These same algorithms continue to find greater and greater use in commercial and military VSAT applications and function equally well over space segments and terrestrial wireless links.

XipLink Mission Statement Our Mission is to leverage XipLink's proven software in our partner`s network solutions, enabling operators and users to optimize available wireless bandwidth for maximum data throughput at the lowest capital cost.

1.3. The XipLink Advantage At the heart of the XipLink optimizers is our proprietary optimization system, the XipOS. This system encapsulates various components, each component playing a vital role in ensuring that you can achieve optimal data performance through your current wireless infrastructure, thereby ensuring a reduction in operational costs and an increase in end-user satisfaction. That's the XipLink Advantage!

Figure 1.2. XipOS

Prot ocol Accelerat ion Advanced Com pression Int ernet Opt im izat ion Securit y Qualit y of Service (QoS) X ipOS

2

XipLink Optimization Technology Overview

1.3.1. Protocol Acceleration The goal of protocol acceleration is to fill the available upstream and downstream bandwidth pipe. Standard TCP was not originally intended to operate over wireless connections. The following factors severely undermine the performance of standard TCP. • Long propagation Delay. Long-delay channels require larger windows than what standard TCP offers, and a more accurate Round Trip Time (RTT) evaluation. In addition, cumulative ACKs and delayed ACKs are not well suited for long-delay environments. Finally, Slow Start and Congestion Avoidance prove to be rather inefficient in the presence of long propagation delays. • Connection Asymmetry. Wireless communications are very often used to provide asymmetric bandwidth services that are intended for large-scale information consumption. Typical internet applications (e.g. FTP, WEB) require relatively low bandwidth from the user to the information provider (e.g. FTP or HTTP server) and relatively high bandwidth towards the user. This effectively means the downstream throughput (towards the user) is controlled by the rate of upstream ACK's (toward the server). Upstream congestion affects downstream throughput, even though there is plenty of downstream capacity available. • High Error Rate. Wireless communications can be influenced by various external factors such as radio interference and weather. Standard TCP interprets packet loss as loss due to congestion and thus reduces the transmission rate, degrading throughput even further. SCPS standards were implemented to add an advanced layer of transmission control for TCP communication thereby addressing the inherent problem with standard TCP flow control to ensure maximum throughput XipOS provides further optimization through XipLink's proprietary transmission control extensions (XTC), while still conforming to the SCPS standards. More information on XTC can be found in the chapter on XipOS Functionality.

1.3.2. Advanced Compression XipOS uses streaming data compression to effectively compress the TCP payload. This has a two-fold advantage over per-packet compression. Primarily there are more compressible patterns available, creating a higher compression ratio. Secondly it efficiently uses the TCP window and thus reduces the number of packets transmitted. Please see the section on Streaming Data Compression for an in-depth discussion

1.3.3. Internet Optimization There are three methods by which internet web traffic is optimized • Domain Name Caching. Internet traffic is based on IP addresses, however most web page URL's use domain names instead of IP addresses. Internet applications like web browsers need to resolve domain names into IP addresses in order to communicate with servers. On high latency links the time required to resolve domain names causes further delays. The XipOS domain name cache saves the results of domain name resolutions, so that subsequent requests for a cached name can be spared a round-trip time. • Web Proxy (optional). The web proxy option is currently only available on the XipLink XA-4000C and XA-500C series optimizers. These models transparently cache all internet web data for a period of time. Subsequent requests for the same data are served directly out of the cache. • XHO (XipLink Hub Optimization). This is a Hub Side only deployment which supports http compression and image transcoding through lossy compression. There is no requirement for

3

XipLink Optimization Technology Overview additional remote units although deploying a SCPS enable remote will provide further acceleration and optimization benefits.

1.3.4. Security XipOS includes a basic firewall to protect your network from possible attacks, allowing you to specify port and/or address ranges that you want to allow or block. The network behind a XipOS device can also be protected via NAT.

1.3.5. Quality of Service Quality of Service (QoS) delivers the ability to prioritise certain traffic types, such as VoIP and streaming media, above others like FTP transfers. Different locations can use dedicated and unique QoS queues to ensure that each location receives a guaranteed minimum committed throughput while also taking advantage of any available unused throughput. XipLink's QoS implementation uses Hierarchical Fair Service Curves to prioritize, guarantee and control traffic based on user-defined policies.

1.3.6. XipOS XipOS encapsulates all the above components and offers multiple forms of management and monitoring through a secure web interface, SSH and SNMP.1 XipOS is the foundation of all XipLink products, ensuring transparency and interoperability between XipLink devices or with any other SCPS-compliant I-PEP device.

1.4. Supported Capabilities 1.4.1. TCP Acceleration Techniques • XTC Bandwidth Rate Control • Bandwidth Rate Control / Non Use of Congestion Control. Rate can be modified in real time and can account for non-TCP traffic in the path • Quality of Service via Fair Weight Queuing Algorithm • SACK support • Selective Negative Acknowledgments (SNACK) • Fast Start (T/TCP) • Acknowledgement Frequency Reduction • Maximize throughput and fairness while minimizing latency • Packet overhead configuration (for IP-in-IP protocols) • Firewalling and NAT capabilities • Inflight data volume control for TDMA Networks • DSCP reading/marking • Black Hole Detection • Automatic traffic bypass

1.4.2. UDP Acceleration Techniques • XRT (XipLink RealTime): UDP Packet Coalescing; Robust Header Compression (RoHC) 1

Cryptographic security features are only available on "Crypto" product models.

4

XipLink Optimization Technology Overview

1.4.3. Compression and Application Acceleration • TCP streaming data compression (only with bracketed deployments) • XiPix HTTP image transcoding (Optional) • HTTP compression (Optional)

1.4.4. Tunnelling Options • Lightweight IP Tunnelling (no licence requirements) • Advanced Cellular Compression (ACC) (optional licence required)

1.4.5. Network Appliance Benefits • • • • • • • • •

Fail-to-wire support with certain hardware platforms Bridge Mode redundancy via STP Router Mode redundancy via CARP Configuration download/upload Graphical redundancy configuration SNMP support with a defined MIB and trap generation Support for routing protocols such as RIP, OSPF and BGP Support for load-balancing using WCCP hash assignment, with L2 or GRE forwarding Easy to use web interface

1.4.6. Standards Support and Interoperability SCPS-TP is internationally recognized as ISO recommendation 15893:2000 and Consultative Committee on Space Data Systems CCSDS 714.0-B-2 and MIL-STD-2045-44000 among others. It has been recommended as the standard technique for performance enhancement by the U.S. Department of Defence for MILSATCOM IP communications. XipLink has been demonstrated to be Interoperable with the SCPS-TP standard.

Table 1.1. SCPS-TP Capabilities SCPS-TP Capabilities • Enhanced TCP (with latest recommendations) • Rate Control / Non Use of Congestion Control. Rate can be modified in real time and can account for non-TCP traffic in the path. Quality of Service also supported via Weight Fair Queuing Algorithm. • Selective Negative Acknowledgments – Short SNACK (long SNACK not recommended) • RFC 1644: T/TCP (also known as Fast Start) • Acknowledgement Frequency Reduction • Default Source of Data Loss (DSDL). However rarely supported by link layer. Essentially all SCPS-TP features are supported except for Best Effort Transport Service (BETS) which requires specialized applications. An API is also provided to control all of these capabilities, either through a system or socket interface. Use of enhancement can be selective.

Table 1.2. HTTP RFC's RFC

Title

RFC 1945

Hypertext Transfer Protocol -- HTTP/1.0

5

XipLink Optimization Technology Overview RFC

Title

RFC 2616

Hypertext Transfer Protocol -- HTTP/1.1

XipLink’s HTTP Acceleration and data compression are proprietary algorithms. Refer to the Whitepaper “Internet Over Satellite Optimization with XipLink” for further information.

1.4.7. RFC and TCP Enhancements Support RFC

Title

RFC 793

Transmission Control Protocol

RFC 1122

Requirements for Internet Hosts - Communication Layers

RFC 1191

Path MTU Discovery RFC

RFC 1323

TCP Extensions for High Performance

RFC 1644

TCP Extensions for Transactions Functional Specification

RFC 2018

TCP Selective Acknowledgment Options

RFC 2338

Virtual Router Redundancy Protocol

RFC 2488

Enhancing TCP Over Satellite Channels using Standard Mechanisms

RFC 2581

TCP Congestion Control

RFC 2582

The New Reno Modification to TCP's Fast Recovery Algorithm

RFC 2988

Computing TCP's Retransmission Timer

RFC 3135

Increasing TCP's Initial Window

RFC 3390

Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations

RFC 3782

The New Reno Modification to TCP's Fast Recovery Algorithm

1.5. Document Overview This rest of this manual is divided into the following chapters: Chapter 2 Quick Start. device.

Provides instructions on how to quickly set up and configure your XipLink

Chapter 3 Understanding XipLink Optimization. Explains the concepts underlying XipLink's optimization capabilities, giving you the information you need to make the most of your XipLink device. Chapter 4 The XipOS Web Interface. Contains detailed instructions on how to configure all aspects of your XipLink device through its web user interface. Chapter 5 Statistics.

Describes how to view statistical graphs of your XipLink device's performance.

Chapter 7 Advanced Upgrade Procedures. Explains how to perform certain unusual upgrades that are not handled by the web UI's upgrade process. Chapter 8 Troubleshooting and Diagnostic Tools. web UI errors and the device's logs.

Contains information about how to work with

Chapter 9 Support. Explains how to contact XipLink's support department, or return a defective device. Also contains a list of frequently asked questions.

6

XipLink Optimization Technology Overview

1.5.1. Conventions used in this Manual The following icons appear throughout this manual. A note contains important information you need to know in order to properly use your XipLink device. A tip provides insight into a particular way of using your XipLink device.

An important note contains critical information that must be followed in order for your XipLink device to function. Failure to heed a warning could result in a severe disruption in your network.

7

Chapter 2. Quick Start - XA Series This section of the manual will enable you to quickly get up and running. It is assumed that you have some knowledge on Network Topologies and Wireless setups. It is recommended that you read through the other chapters to get an overall insight on how this unit needs to be configured for your particular network topology.

2.1. Unpacking and Box Contents Please verify that you have received the following within your package contents: 1. XA Unit 2. Power Cable 3. Network Cable (Cat 5 Ethernet cable) 4. Console serial cable (RS232 DB9 null modem cable) or USB to RS232 Cable 5. QuickStart leaflet to provide basic startup information. When unpacking and handling the contents of the box please take all precautions against electrostatic discharge as this may cause permanent damage the equipment. Please note: any damage due to electrostatic discharge will void the product warranty.

2.2. Placing the Optimizer in the Network In a typical installation the optimizer is placed in-line into the segment between the LAN network and the Wireless Modem.

Figure 2.1. Placement of the Optimizer

Unaccelerated passing through the optimizer from the LAN is proxied, compressed and accelerated then forwarded over Wireless interface. Any accelerated traffic arriving on the Wireless side is decompressed and then passed back to the LAN. It is important to ensure that the LAN side is always connected to either the Router or Bridge interfaces, and that the wireless equipment is connected to the Wireless interface, otherwise network throughput will be degraded or disrupted. Other deployment options, including out-of-path configurations, are possible. See the section on Web Cache Communication Protocol for scenarios that rely on certain Cisco routers, or contact XipLink for other possibilities.

8

Quick Start - XA Series

2.2.1. Physical Connections All ports on the XA's are clearly marked for identification. Each unit contains a Serial Console port to which you can gain direct access to the unit's console using the included serial cable, See the section on Management through the CLI for more information. Some units include a USB port, but these are currently not used.

2.2.1.1. Product Labels Figure 2.2. XA-500

Figure 2.3. XA-2000

Figure 2.4. XA-4000 | XA-10K

Figure 2.5. XA-30K

9

Quick Start - XA Series

2.3. Accessing the XipOS Web User Interface To access the unit via the Web interface, you will need to make the device available on your PC's network, or you can connect the device directly to your PC's LAN port using the supplied Ethernet cable. The factory default configuration of the device is as follows:

Table 2.1. Factory default IP addresses Interface

IP

Netmask

Management

172.16.1.200

255.255.255.0

Wireless

10.0.0.200

255.255.255.0

Bridged

Not Configured

Router

192.168.1.200

255.255.255.0

It is recommended that you initially connect to the device through the Management interface. This will allow you to configure the device's main network settings without having to reset your PC's IP address. To allow for minimum downtime, you may configure the device prior to installing it in-line on your network.

Steps to take • Connect your PC to the management interface, either via a network or direct LAN cable. • Reconfigure your PC/Laptop to any IP address on the 172.16.1.0/24 subnet (except 172.16.1.200, which is the device's default IP address). For example, use IP address 172.16.1.1 and netmask 255.255.255.0. Please refer to your PC operating system's instructions on how to configure your PC's IP address. • Open your web browser and point it to http://172.16.1.200/ For Crypto versions you will need to connect via a secure https connection on using https://172.16.1.200.

2.4. Login Use the factory default user name and password to log in. User Name: admin Password: xiplink If the login is successful you will be presented with the Quick Config Wizard welcome screen.

10

Quick Start - XA Series

2.5. XipLink Setup Wizard Configuration of your XipOS device is done through a secure web interface. Please note that your web browser requires JavaScript support. It is recommended that your display supports a minimum resolution of 1024x768. The web interface allows you to configure your device and view live statistics. When you first access the web UI you will be presented with the Quick Config Wizard that will guide you step-by-step through the basic configuration options. The unit will be operational once the Quick Config Wizard is complete. Further configuration refinements can then be made within the Networking Setup and Optimization areas of the main UI.

2.5.1. Welcome Welcome and thank you for purchasing our XipLink product. Here you will be able to view and accept the license agreement. Please complete the required registration information before accepting the license agreement.

End User Licence Agreement The use of this device and the installed software is subject to agreeing to the XipLink EULA. Before you can continue with the configuration of the device, you must read the agreement, complete the licensee details (see below), and accept the agreement's terms.

Agreement accepted by Supply the name of the user who has accepted this license.

From organization Supply the name of the organization to which this license is granted.

11

Quick Start - XA Series

Serial number This is the software serial number of your XipOS installation. It is different than the hardware serial number of the device.

License agreement accepted Once you have agreed to the software license and completed the above details, you can click on this checkbox to accept the license.

On-Line Registration Only Visible once agreement is accepted

Please register this unit as on-line registration assists us in supporting your device and enables us to send you notification of any future software updates. Should you not have Internet access when first configuring the device, you may register the device any time by returning to this page and selecting On-Line Registration.

Open User Guide If the PC you are using to configure the device also has Internet access, you can register the device online. On-line registration assists us in supporting your device and enables us to send you notification of any future software updates. Should you not have Internet access when first configuring the device, you may register the device any time by returning to this page and selecting On-Line Registration.

2.5.2. Select Deployment Options

The deployment options specify the network topology in which this device is going to be used. To complete this section, you will need to know where and how this device will form part of your network: which IP addresses to use and preferably some form of network diagram. Please see the section Installation Flexibility for detailed information on this topic.

12

Quick Start - XA Series

Router, Bridge or Single Interface Designate this device as a router, bridge or running in Single Interface mode. Which to choose depends on your network topology and where the unit is physically located. In Bridge mode the unit is transparent to the network and will pass traffic though without the source and destination being aware that the device is in their path. In Router mode, the unit is assigned two IP addresses and traffic needs to be explicitly routed through these addresses. In Router mode you can also enable Network Address Translation (NAT). If you do, you need to specify which interface will do the NAT translation. For most NAT installations, this is the Wireless interface with a public IP address. Single Interface mode allows you to connect only the Wireless interface through to the network and then via tunnelling you would route clients via this PEP. For detailed information refer to the Networking Mode section.

Management Interface The Management interface on the device can be configured to act either as a management interface or as a hybrid RX/TX interface. The selection here depends on your particular deployment requirements: Select the "Use as additional (management) interface" option when the Management interface will be used to manage the device. Typically this is used for out-of-band management, to ensure that management traffic is separate from routed traffic for security reasons. SNMP monitoring and traps are often sent via this interface to a central Network Monitoring System. Select the "Hybrid" option when you have two separate wireless channels, one for transmitting (TX) and once for receiving (RX). This is typically used for a remote deployment where you will have a dedicated SCPC transmission channel and a broadband shared downlink DVB channel. Terminating both channels in a single XipOS device does away with any requirement for an additional upstream router.

Hub or Remote Is the unit deployed at a hub site that communicates with many remote XipLink devices, or is it deployed at a remote end point and only communicates with one other XipLink device? If XipLink devices are deployed on both sides of this device, you need to select Hub/Mesh.

Device name For ease of reference and administration, you should configure a unique name for this device. This name is displayed in the web UI, allowing visual confirmation of the device being configured. The name of the device must consist solely of alphanumeric characters without spaces or punctuation.

2.5.3. Configure Network Interfaces This section allows you to configure the physical interfaces of the XipLink unit. You can enable or disable any interface, and also set various options for each.

13

Quick Start - XA Series

Wireless interface. This interface always faces your wireless equipment. Accelerated/compressed traffic arrives on this interface to be de-compressed and forwarded to its final destination on the Routed interface. Routed interface. Wireless interface.

Unaccelerated traffic is sent to this interface to be optimized before leaving the

Management interface. This interface is primarily used for out-of-band management of the device. It allows you to reconfigure the primary interfaces without having to concern yourself with losing your connection to the device. Should you use a separate management network, you can reconfigure this interface to use a specific IP address on the management subnet. This allows you to manage and monitor the device through this interface without interfering with the core routed traffic. Firewall configurations can also prevent any management traffic through the main Wireless or Routed interfaces, thereby providing an additional level of security to the device.

Address Type Static. DHCP. None.

Assign a fixed IP address to this interface. You also need to supply the netmask. Obtain an IP address from a DHCP server on this interface's network. Assign no IP address to this interface. This is only useful when the device is in Bridge mode.

Maximum Transmission Unit (MTU) The MTU setting defines the maximum size of a IP packet that can be transmitted without fragmentation. Values can range from 576 to 1500.

Media Defines the type of media that is connected to the Ethernet interface. The default is autoselect, which should work in most environments. If you connect the device to any network equipment that is manually configured, the auto-detection may not always work. It is then best to manually configure the media type to avoid conflicts.

VLAN This setting allows you to bind this interface to a particular VLAN

14

Quick Start - XA Series

Default gateway The default gateway is the exit and entry point in a particular network subnet. All traffic that is destined for another network will be routed via this Gateway IP address.

2.5.4. Configure DNS

The Domain Name System (DNS) translates domain names meaningful to humans into IP addresses that can be routed across the network. It is an IP address directory, similar to a telephone directory, that holds all the domain name to IP address translations.

DNS Servers Here you need to configure the primary and secondary DNS server IP's that are reachable from this particular device.

Domain You can also supply a default domain name. The device will use this domain to resolve "unqualified" host names (i.e. names without a '.' in them). This setting is optional and rarely needed.

2.5.5. Configure Networks

15

Quick Start - XA Series

This section allows you to configure the device with the basic characteristics of the Wireless interface's link. Please see the section on the Networks tab to fine tune the configuration for your environment.

Link Properties Click the Edit Link Properties button to configure your wireless link's properties. You can also edit the properties of the "Unassigned" link, which is a catch-all for traffic that the optimizer does not accelerate. Normally the "Unassigned" link has the same properties as the wireless link.

The Maximum Transmit Bandwidth is the maximum speed at which the device will transmit data over the link, while the Maximum Receive Bandwidth is the expected maximum speed that the device will receive data from the link. Bandwidth and rate values must be specified with a unit: • Mb = 1,000,000 bits per second • Kb = 1,000 bits per second • b = 1 bit per second These values can only be integer numbers (without commas); decimal points are ignored. The Link Round Trip Time is the total amount of time (in milliseconds) it takes for a packet to travel over the link in both directions. This critical value is used by the Rate Control algorithms and also ensures that sufficient buffer space is allocated to manage inflight data.

Network Properties Select Standalone hub deployment if your optimizer is to be deployed as a pure XHO hub (i.e. without a remote XipOS device). Selecting this option disables SCPS acceleration and TCP-level compression. The optimizer still proxies all TCP connections, but only applies XHO optimizations to HTTP connections. If you have a hub where some sites have a remote XipOS device and others do not, you can override this setting on a per-site basis using a QoS queue for each site and configuring specific TCP optimizations on the Service Assignment tab. If your optimizer is a pure XHO hub, only select Adjust settings for an external Optimizer/PEP if you have an upstream Performance Enhancing Proxy (PEP) installed between this optimizer's Wireless interface and the wireless transmission equipment. This is required for any PEP that creates spoofed connections, such as a web cache. The 'Wireless' ethernet max speed setting controls the maximum speed of traffic on the Wireless interface. This is typically the speed at which the interface syncs to its switch. For example, set this to 1000Mb for 1000BaseTX Ethernet media.

16

Quick Start - XA Series

2.5.6. Set Password

Please choose a password to access the device. Supply the current password (the factory default password is xiplink) and provide a new password and confirmation. The password score indicates the new password's strength. The higher the value the more difficult the password is to break. Use a password with numbers, a mix of upper- and lowercase letters and punctuation characters to get a high score. A score of at least 50 is recommended.

2.5.7. Apply Changes To Device Configuration Please review all of your settings before applying the changes. Should the Apply Changes option not be available, you will first need to accept the license agreement before you can proceed. The XipOS software distinguishes between the active "running" configuration and the permanent "startup" configuration that is loaded when the device reboots. This distinction lets you experiment with different configuration settings, and allows you to undo your changes by rebooting or power-cycling the device. When you apply your changes, by default they are saved to both the running and startup configurations. You can prevent the changes from being written to the startup configuration by de-selecting the "Also apply to 'startup' configuration" checkbox, which will mean that the changes will only be in effect until the device is rebooted. The system saves your changes by first applying them to the running configuration. If this succeeds (and the "Also apply to 'startup' configuration" checkbox is selected) then the changes are saved to the permanent startup configuration. Should any failure occur while modifying the running configuration, the system will attempt to roll back the changes to the previous state, all UI changes will be kept intact so that you can edit the changes and reapply the configuration. To retrieve the original settings as was previously applied, you will need simply refresh the web browser to reload these settings. When changing the IP address of the device, you will receive a popup to notify you to now connect to the newly configured IP address. This is particularly true when changing the IP of the interface through which you are currently connected. The feedback window indicates the progress and success or failure of the configuration updates.

17

Chapter 3. Understanding XipLink Optimization This chapter describes the techniques and features of XipLink's optimization technology. Understanding these concepts will help you get the most out of your XipLink product. Unlike application accelerators or cache machines, which usually reside very close to the enterprise LAN and which communicate across many intermediate links, wireless optimizers are installed to closely bracket the wireless link. XipLink is committed to standards compliance wherever possible, but in the interest of delivering the maximum wireless capacity XipLink also uses industry leading proprietary algorithms as explained below. The SCPS standard allows such vendor-specific extensions, and XipLink leverages this fundamental capability to rapidly deliver improved algorithms while remaining completely interoperable and transparent.

3.1. Dynamic Transparent Negotiation of Optimization Capabilities The XipLink optimizer transparently proxies every TCP connection. Following the SCPS standard, extended TCP options are exchanged between SCPS-enabled proxies during TCP connection establishment. These options, which are transparent to non-SCPS applications, allow for the negotiation of standard SCPS optimization capabilities on each connection. In addition to standard SCPS capabilities, other enhancements such as selective negative acknowledgments (SNACK) and the use of XipLink high ratio data compression are also negotiated during TCP connection establishment, using standard SCPS extensions for vendor-specific options.

Figure 3.1. Dynamically negotiated optimization

The SCPS TCP options underlying optimization negotiation can be routed over any Layer 3 IP network. This is a key underlying principle in the XipLink system architecture, and allows XipLink to deliver optimization to users across any network topology without the need for awkward network configuration such as tunnels: • TDMA satellite networks • Point-to-point and point to multi-point networks • Hub and Spoke networks • Mesh networks

18

Understanding XipLink Optimization

• Networks that may be only partially installed Once a hub site has an optimizer appliance installed, remote users that are XipLink-enabled, either by software embedded in their wireless device or by connecting through an optimizer on their LAN, get fully maximized throughput. Other users who are not XipLink-enabled continue to use standard TCP, but without optimization benefits.

Figure 3.2. Unoptimized connections using standard TCP

3.2. SCPS Protocol Acceleration XipOS optimizes the transport layer for communications across a wireless link in several ways. The conceptual algorithms for protocol operations over the wireless air interface are based on the SCPS standard. XipLink’s implementation of TCP protocol acceleration also uses additional advanced algorithms that are the result of years of engineering and exacting simulation to ensure maximum use of the available bandwidth. XipOS addresses the loss and latency of wireless communications by applying specialized wireless algorithms and other optimization techniques to fully and fairly utilize the available capacity. Standard TCP encounter several problems when used across a wireless link: • Slow connection setup due to long delay (latency) • Slow discovery of the available wireless bandwidth • Erratic use of the available bandwidth • Slow response to packet loss that occurs in the network • Overreaction to packet loss at high bandwidths, dramatically reducing the output rate • Hard-coded parameters, such as window sizes, limit throughput • Poor response to simultaneous packet loss in many data streams (holes) • Protocol header overhead inefficiently consumes available bandwidth • Considerable bandwidth required for acknowledgements XipLink protocol acceleration algorithms mitigate these issues with a combination of approaches that work collectively to achieve the highest performance for each wireless environment.

Features of the XipLink TCP protocol acceleration module: • Selective Negative Acknowledgment (SNACK). A loss recovery scheme that is highly efficient over wireless links and works with different congestion control algorithms to adapt to packet loss. • Acknowledgement frequency reduction. (AFR) A technique that lowers protocol overhead by 33% or more and is especially effective over high-speed, asymmetric links.

19

Understanding XipLink Optimization

• Dynamic window scaling. Algorithms that scale TCP windows with network load, removing any artificial limits on communication capacity. • Large windows. Uses buffers that are larger than those of other devices in the network, ensuring that additional latency is not introduced.

3.3. XipLink Transport Control (XTC) Modes XipLink offers the largest selection of highly tuned congestion control algorithms. These deliver the absolute maximum capacity over a wireless link when properly matched and configured for the network where the optimizer is installed. XipLink Transport Control (XTC) modes are rate-control and congestion-control algorithms that maximize capacity on a wireless link, beyond the single congestion control mechanism offered in the SCPS standard. As a result, XipOS can deliver significantly more throughput when the rate control algorithm is properly matched to the wireless network where the optimizer or software is installed. A very important concept when discussing rate control algorithms in wireless networks is to understand that the XTC mode may be different for a hub site versus a remote site even though they are operating on the same network. For example, in a hub-and-spoke TDMA network, the high-powered hub site may be capable of transmitting at a fixed rate and so would be set to Fixed Rate Control mode, while the remote sites may experience general RF contention and lower RF power budgets and would therefore be configured in Programmable Fixed Rate Control mode or Dynamic Rate Control mode. Congestion control is always viewed from the perspective of the sending device and it is not uncommon to find the modes configured differently on either end of a wireless link in order to deliver the maximum capacity. The following sections describe the XipLink Transport Control (XTC) modes and briefly explain when each is typically used.

3.3.1. XTC - Fixed Rate Control Mode Fixed Rate Control mode allows the network operator to configure the outbound traffic rate to a fixed, maximum rate. Whether there is one connection or hundreds, the XipLink optimizer will shape the TCP output traffic to sustain this fixed output rate and hold it very close to that maximum. One specific goal of this mode is to ensure that performance does not decrease as the round trip time (RTT) climbs.

Figure 3.3. XTC – Fixed Rate Control

Fixed Rate Control mode is perfectly suited to both ends of a dedicated link like Single Channel Per Carrier (SCPC) space segments, but can also be used on both ends of stable TDMA or even DVB-RCS networks.

20

Understanding XipLink Optimization

In licensed or unlicensed terrestrial networks this algorithm is always recommended at the hub site and can often be used at remote sites in stable point-to-point networks such as those served by a CPE device and good antenna. Fixed Rate Control mode is infrequently used in mobile devices due to the constantly changing signal-tonoise ratio (SNR) these devices encounter as they roam. Even when operating in a licensed spectrum, the very nature of a roaming mobile device and their limited RF power budgets make the bandwidth appear dynamic.

3.3.2. XTC - Dynamic Rate Control Mode Dynamic Rate Control mode is the default congestion control mechanism for a SCPS connection. This mode is useful in several situations, such as: • When the wireless traffic may be passing through one or more unknown service provider networks. • If there is limited buffering capability within the network. • If an intermediate controller is policing the traffic. • When I-PEP interoperability is important. Dynamic Rate Control mode uses proprietary techniques that dynamically discover the available bandwidth and then anticipate and reduce the output rate before congestive loss occurs. XipLink Dynamic Rate Control mode is based on years of research and uses algorithms that are designed to operate best on wireless networks. Wireless optimizers configured to use this mode rapidly determine the available bandwidth and respond very quickly by either increasing or decreasing the TCP output when the available bandwidth varies. This rapid convergence is accomplished by calculating the buffering that occurs within the network using volume-based algorithms. The optimizer then rapidly controls the output TCP flow rate to ensure the smallest buffers are not overrun, which would cause packet loss.

Figure 3.4. XTC - Dynamic Rate Control Mode

Dynamic Rate Control mode is recommended when the available bandwidth is unknown or varies widely, often on dynamic TDMA or DVB-RCS networks, particularly at the remote sites. While not as effective at completely filling a stable link, in many wireless devices it is more important to constantly and quickly adjust the transmission rate for maximum capacity. Dynamic Rate Control mode is also an alternative for links where a traffic shaper may exist in the path between two XipLink optimizers. The traffic shaper's policing would work against Fixed Rate Control mode, dropping optimized traffic that may appear on the network as an aggressive TCP sender holding a very high data rate.

21

Understanding XipLink Optimization

3.3.3. XTC - Programmable Fixed Rate Control Mode This XTC mode, Programmable Fixed Rate Control, allows the “available bandwidth” setting of a fixed rate link to be varied multiple times per second using the XipLink API. When a wireless modem or other external device is capable of determining when the bandwidth changes and can generate a message to XipOS, this mode permits co-ordination of the TCP output to match the available bandwidth across varying degrees of capacity. This function is becoming more and more important in policy enforcement around a device's spectrum usage as well as to keep up with Adaptive Coding Modulation (ACM) dynamics. Using Programmable Fixed Rate Control mode, an external device can vary the “available bandwidth” when it detects a change in the size or depth of its outbound link buffers or a change in the link's speed or modulation characteristics. The external device sets the new “available bandwidth” using the XipLink API. The optimizer software can throttle the TCP output up or down, maximizing the capacity across the link without driving the link to a loss condition due to buffer overflow or upstream network congestion.

Figure 3.5. XTC - Programmable Fixed Rate Control Mode

Full performance on dynamic bandwidth links can be achieved using this mode, but Programmable Fixed Rate Control mode requires software integration within an embedded system or external integration using the XipLink API. As such, this mode is only available with specific devices that support this capability. Programmable Fixed Rate Control mode can operate both at coarse intervals, as when a ship changes satellites as it moves across an ocean, and also very rapidly (sub-second) when tightly coupled with a device that aggressively monitors the available bandwidth.

3.3.4. XTC - Enhanced TCP Mode This is a simple rate control algorithm that follows the basic TCP Reno recommendations for congestion control. It uses improved TCP slow start to react to packet loss. It is useful on stable links when Fixed Rate Control cannot be used due to an upstream QoS traffic shaper, similar to Dynamic Rate Control.

3.4. Additional TCP Protocol Acceleration Techniques 3.4.1. TCP Connection Fast Start Using TCP fast start technology, data can be included in the initial connection handshake. This combines in a single round trip both connection establishment and the first few bytes of data in the TCP connection.

22

Understanding XipLink Optimization

Without TCP fast start, an application has to wait for setup request and acknowledgement to traverse the slow wireless link before sending any data. A typical Internet user with a standard web browser may open several connections to many servers for each web page viewed. TCP fast start can significantly decrease the time needed for a page to load, and will also greatly reduce the amount of contention on the wireless network by decreasing the number of packets sent and reducing the overall bandwidth consumed.

Figure 3.6. TCP Connection Fast Start

XipLink’s fast start is based on our efficient implementation of IETF RFC 1644. Traditional TCP uses a 3-way handshake before data transmission can begin. If we consider a minimum ¼ second delay in each direction, just establishing a TCP connection to a server could require over ½ a second, even before requesting the first bits of data. The benefits of TCP fast start are most apparent when multiple connections are used together in sequence, such as with HTTP and other client-server applications.

3.4.2. Acknowledgement Frequency Reduction (AFR) On asymmetric links, enabling AFR will reduce the number of acknowledgments the receiver will send back as data is received. When AFR is active, the XipLink optimizer will use a calculated “delayed acknowledgement time” based on the configured bandwidth and delay along with a proprietary XipLink algorithm. Standard TCP's “every-second-packet” acknowledgment framework was originally devised to sustain high speed LAN throughput. In contrast, with AFR the XipLink optimizer acknowledges a much large volume of data with a single packet. When enabled, this feature can reduce packet overhead by 33% or more while sustaining maximum throughput across the wireless link. As the link speed increases, or when a communication link is highly asymmetric, protocol reduction benefits continue to increase while sustaining the maximum bandwidth capacity.

3.4.3. Selective Negative Acknowledgments The Selective Negative Acknowledgements (SNACK) technique works in combination with Acknowledgment Frequency Reduction and allows for rapid response to packet loss. It is much more responsive than traditional TCP's packet acknowledgment scheme which has proven ineffective when applied to wireless links. Using SNACK to communicate only those packets lost in transmission allows communications to continue even at very high error rates. This makes XipLink wireless optimization algorithms very resilient to rain fade and other RF related conditions while scaling to very high throughputs. SNACK is more bit-

23

Understanding XipLink Optimization

efficient than Selective Acknowledgement (SACK) and is more effective against the multiple losses that are common with wireless interference.

Figure 3.7. AFR and Selective Negative Acknowledgments

SNACK is an important component of TCP protocol optimization in satellite and terrestrial wireless networks because the higher error rates experienced over wireless links magnify the effects of high latency on retransmissions.

3.4.4. Quality of Service The XipLink wireless optimizer provides several Quality of Service (QoS) capabilities that work with both internal optimization functions as well as with network-wide QoS services. All traffic, including traffic not slated for acceleration, still passes through a fast path in the XipOS kernel. Constantly monitoring all traffic passing through the optimizer ensures that it will not saturate the link with accelerated data, which might cause packet loss in unaccelerated protocols. QoS connections that meet an operator's defined Differentiated Services criteria are given preferred access to the available bandwidth, ensuring that mission-critical or performance-sensitive applications receive the bandwidth they need. Any XipLink wireless optimizer can also tag, mark or re-mark specific traffic as it leaves the device. This enables the network operator to deliver an end-to-end integrated QoS system using differentiated user classes or queues. This capability can be used to prioritize some traffic or limit the bandwidth used by others.

3.4.4.1. QoS Overview Quality of Service allows you to classify packets that pass through the device and assign different priorities to different kinds of traffic. Without QoS, traffic passes through the device on a first-in first-out (FIFO) basis. This can degrade performance when the link becomes congested, and it also allows bandwidth-

24

Understanding XipLink Optimization

hungry applications such as P2P or bulk file downloads to overwhelm the link and prevent the timely delivery of streaming or interactive protocols. These problems are compounded on links with high roundtrip times.

Figure 3.8. QoS Re-Prioritizes Traffic

QoS also helps a hub site deal fairly with multiple remote "spoke" sites when each remote site can have its own downlink rate that differs from the hub site's uplink rate. With QoS you can configure the hub with a fixed maximum transmission rate for each remote site. This in turn allows each remote site to apply its respective downlink rate without causing congestion and limiting bandwidth to other remote sites. QoS only applies priorities and shaping to traffic transmitted over the wireless link from the XipLink optimizer. The device has no way to control the rates at which it receives data (aside from standard TCP congestion control mechanisms, which do not differentiate types of traffic). QoS is therefore normally applied on both devices on either side of the wireless link to control how each device transmits data.

3.4.4.2. QoS Queues XipOS uses the concept of QoS queues to define traffic priorities. Each queue has a parent and zero or more child queues. A special top-level (parentless) queue named root defines the total amount of bandwidth that can be transmitted from a device. (The root queue's limitations are set by the maximum bandwidth of the Wireless link.) The root queue is a conceptual entity and is not exposed in the XipOS GUI.

The parent-child relationships between queues define how bandwidth is allocated among the queues. A queue cannot reserve more bandwidth that what has been reserved by its parent. Each childless (or "leaf") QoS queue is associated with a firewall rule that defines what kind of traffic the queue controls. The order of firewall rules is critical to successfully applying QoS.

One of the childless queues must be designated as the default queue. The default queue shapes all traffic that does not match any other queue. The default queue is the only leaf queue not explicitly associated with a firewall rule.

25

Understanding XipLink Optimization

The Unassigned Queue All XipLink optimizers have an "Unassigned" queue that acts as a catch-all for unclassified traffic that does not match any of the other queues. To lower the priority of unclassified traffic, configure the Unassigned queue with lower bandwidth properties than the other top-level queues. In Single Interface mode, traffic sent to the LAN network is classified in the Unassigned queue.

3.4.4.3. QoS Algorithm The XipOS queueing algorithm is based on Hierarchical Fair Service Curves (HFSC), with several adaptations for wireless and satellite links. HFSC allows proportional bandwidth distribution (supporting equal or unequal bandwidth sharing) as well as control and allocation of latency. Each QoS queue can be configured with three main bandwidth transmission parameters: • Maximum transmission rate • Guaranteed transmission rate • Priority transmission rate All queues in the hierarchy can have a maximum and a guaranteed rate. Leaf queues, since they are the only queues that actually hold packets, can also have a priority rate. The maximum rate is simply an upper limit on the queue's sending rate. Whenever a queue reaches its maximum rate, no further packets can be sent by that queue until the rate subsides. The guaranteed rate controls the queue's relationship with its siblings at the same level in the QoS queue hierarchy. This is the bandwidth guaranteed to a queue when the link is saturated, ensuring that traffic is distributed properly among the sibling queues. Separating the guaranteed and priority rates allows the system to meet priority delay times under all circumstances. It also means that a queue can send a packet to meet its priority rate even if doing so temporarily violates the guaranteed rate of one of its ancestor queues in the hierarchy. The guaranteed rate of a given queue must be equal to or greater than the sum of the guaranteed rates of the queue's children. This ensures that all queues can achieve their configured guaranteed rates. For example, if a queue has two children with guaranteed rates of 2Mbps and 3Mbps, then that queue must have a guaranteed rate of at least 5Mbps. A queue's guaranteed rate can be specified either as an absolute value or as a percentage of its parent's guaranteed rate. A queue with multiple children can have some of its children specify their guaranteed rates as percentages and others as absolute rates. The priority rate is filled first across all queues. In other words, if there is traffic available in several queues the system will first service the queues that have not yet reached their priority rates. Priority rates should not be oversubscribed. They are often used for real time protocols like VoIP, gaming and other latency-sensitive applications. XipOS queues also have a delay parameter that limits the amount of time a packet can spend in the queue. This allows fine control over jitter and the quality of streaming protocols such as voice calls.

3.4.5. Streaming Data Compression In addition to optimizing the TCP protocol for transport over wireless links, XipOS also applies highratio data compression to the TCP payload. To achieve a high compression ratio the software performs

26

Understanding XipLink Optimization

continuous compression on the entire stream of data for each on-going connection, taking advantage of the streaming nature of TCP. Stream-based compression is superior to other payload compression strategies that compress data within individual IP packets. These older per-packet compression algorithms yield lower compression ratios and do not reduce the overall number of packets needed to send the compressed information.

Figure 3.9. Streaming Data Compression

XipOS stream compression algorithms are tuned to ensure that additional latency is not introduced through the buffering required for optimal data compression, which might lead to lower overall bandwidth utilization. Data compression is most effective when performed on larger data sets, because more patterns inside the data can be found and removed. However, if only a few hundred bytes of data are transmitted at a time, the data is briefly buffered before automatically being forwarded out the wireless port without waiting for more data - maintaining very low latency. The timers that ensure this balance between waiting time and data volume are based on years of real-world deployment and simulation experience. A XipLink wireless optimizer will compress only the TCP payload, leaving the TCP headers in the clear. This allows TCP acceleration algorithms to operate on, and XTC rate controls to be applied to, the compressed data stream. This enables the wireless optimizer to transmit at the maximum output rate, as prescribed by the rate control settings, even as the compression ratio varies from packet to packet. Other compression strategies that can yield higher compression ratios but typically operate by putting all traffic into a common compressed tunnel. Such systems require end-to-end or tunnel based configurations, and are not well suited to wireless links because they limit network scalability and add packet overhead, all detrimental to maximizing capacity at low capital cost. The compression ratio of a particular data stream is completely dependent on the nature of the data itself. Text - as found in web pages, email, etc. - is highly compressible while random data is not compressible at all. Internet video streams are generally very compressible while video from modern video surveillance systems is so well encoded by the camera there is not much left that can be compressed. It never hurts to run these streams through the compression module, but user expectations for compression ratios must be realistic based on the type of traffic being transmitted.

27

Understanding XipLink Optimization

Figure 3.10. Compression Samples

Most XipLink customers see between a 40% and 300% compression ratio depending on the data itself and the usage patterns. In general, compression ratios average about 2:1, but this is an area of rapid technology innovation and improvements which will continue to yield higher and higher ratios on traffic that is not already pre-compressed.

3.4.6. XipOS Tunnelling In today's dynamic networks, customers typically have minimal control of content proxying and filtering on their service providers' networks. When the XipOS is deployed in an environment where the optimizer is not placed in a hub or teleport, or when the intercommunication between the two XA's connect over the public internet, it is possible that TCP packets may be stripped of the SCPS or acceleration options added to the TCP headers. This effectively means that the acceleration options will not be negotiated between the various instances of XipOS. To address these situations, XipOS provides a UDP tunnelling feature to protect acceleration options being stripped from the TCP headers. All traffic is optimized prior to being transmitted within this tunnel, so that the maximum capacity of the link can be obtained. Tunnelling also enables remote installations of XipOS optimizers to operate behind a NAT firewall, or within a private network segment, or where the service provider only provides private IP addresses. Finally, tunnelling is required for XipLink Real-Time (XRT) optimization.

3.5. XipLink Hub Optimizations Some XipLink optimizer models support hub-only optimizations (XHOs) that improve performance without the need to deploy a second optimizer on the other side of the wireless link. Hub optimizations provide benefits when they are enabled on the "upstream" or "Internet" side of a wireless link. The XHO capabilities are:

28

Understanding XipLink Optimization

• XiPix web image compression. • HTTP compression for browser-compatible decompression.

3.5.1. XiPix Image Compression XiPix technology automatically reduces the resolution of web images on the fly, dramatically reducing image file sizes with only a minor impact on the user experience. XiPix compression is transparent to the end user, and is compatible with all other XipLink optimization technologies. An operator can configure XiPix's level of compression, allowing you to specify the tradeoff between image size and quality. XiPix technology only applies to JPEG images transmitted over HTTP. Most Internet web sites use JPEGformat images. XiPix is a separately licensed capability, and can only be enabled with a valid activation code. Please contact XipLink to obtain an activation code.

3.5.2. HTTP Compression XipLink's HTTP compression takes advantage of the standard compression capabilities defined in the HTTP protocol. All modern browsers support HTTP compression standards, but few web servers take advantage of it. With XHO HTTP compression, a XipLink optimizer can automatically and transparently compress HTTP traffic that is not already compressed by the web server. The user's web browser will decompress the traffic, so there is no need to deploy a second optimizer on the user's side of the wireless link.

3.6. XipLink Real-Time (XRT) XipLink Real Time optimizations compress and coalesce multiple small UDP packets to significantly enhance UDP bandwidth efficiency. Wireless products have inherent limitations to the number of packets per second they can process. XRT reduces the number of packets required to carry a given volume of realtime traffic. How can UDP traffic benefit from XRT? • • • •

Most VoIP traffic consists of headers - approximately 40%. Most headers do not change much from packet to packet. Multiple streams each have their own overhead and many common headers. Inefficiencies apply to most UDP-based protocols, from standard VoIP and Skype to other small-packet applications such as Citrix. • XRT does not alter the data payload in any way, so it does not rely on any particular VoIP codec or UDP application. XRT is an extension of XipOS lightweight tunnelling. You must enable tunnelling in order to use XRT.

Packet Coalescing Packet coalescing is a technique that combines the payloads of many small network packets into a single large packet that can be transmitted and processed more efficiently. The following figure illustrates how XRT packet coalescing reduces the effective packet-per-second rate of real-time traffic.

29

Understanding XipLink Optimization

Figure 3.11. XRT Packet Coalescing

Packet coalescing is not merely applied on each connection between a client and server, but on multiple data streams between various hosts offering a greater benefit. The benefit is proportional to the number of data streams available for coalescing. The table below illustrates the benefit of coalescing multiple VoIP streams.

Table 3.1. XRT: Benefit of Coalescing Multiple Streams Codec & Bit Rate Capture Window # of calls

Bandwidth Savings

PPS Benefit Ratio

G.729 (8 Kbps)

20 ms

1

8%

1

G.729 (8 Kbps)

20 ms

2

33%

2

G.729 (8 Kbps)

20 ms

5

47%

5

G.729 (8 Kbps)

20 ms

10

52%

10

G.729 (8 Kbps)

20 ms

20

54%

20

G.729 (8 Kbps)

20 ms

50

56%

50

G.729 (8 Kbps)

20 ms

100

57%

70

G.729 (8 Kbps)

20 ms

200

57%

70

These results were obtained under laboratory conditions. Actual results will vary based on the individual packet sizes in the data stream, the capture window size, and the maximum coalesced packet size. Note the convergence towards a 57% bandwidth savings as more streams are coalesced. The next table shows the impact of the capture window size on packet coalescing. Increasing the capture window size would increase the benefit, although it may also increase jitter if not enough UDP traffic is present.

Table 3.2. XRT: Effect of Different Capture Window Sizes Codec & Bit Rate Capture Window # of calls

Bandwidth Savings

PPS Benefit Ratio

G.729 (8 Kbps)

5 ms

10

37%

3

G.729 (8 Kbps)

10 ms

10

47%

5

G.729 (8 Kbps)

15 ms

10

50%

8

G.729 (8 Kbps)

20 ms

10

52%

10

30

Understanding XipLink Optimization

The bandwidth savings and packet-per-second benefit both increase as the capture window increases, although the effect flattens out with larger window sizes.

Header Compression XRT can also apply standard Robust Header Compression (RoHC) to UDP streams, where uncompressed headers can account for as much as 60% of the network traffic. Header compression applies to IP and UDP headers, and can also apply to Real-time Transport Protocol (RTP) headers. Since many RTP-based protocols use non-standard UDP port numbers, it is necessary to explicitly tell the optimizer which traffic should be considered for RTP header compression.

3.7. Byte Caching Byte caching, also known as data deduplication, is a compression technique which reduces duplicated blocks of data that may be very large and/or separated by a large amount of intervening data. XipLink's byte caching can achieve significant reduction of large data sets, with compression ratios typically reaching 80%. These savings are also achievable on data that is already compressed by standard compression algorithms, such as ZIP files and video streams. XipLink's byte caching is implemented at the IP level. This enables it to detect and reduce duplicate data among all data streams passing through the device. For example, XipLink's byte caching can leverage the data it sees in any protocol to compress that same data when it re-appears in any other protocol. So a file downloaded by one client application will "prime the pump" and if that file is downloaded again by a different client, perhaps using a different protocol, XipLink's byte caching will be able to provide immediate and significant savings on the second transmission. XipLink's IP-level byte caching also provides benefits even when the application-layer traffic is encapsulated in one or more layers of tunnelling. It is fully compatible with any kind of IP-within-IP layering. Finally, XipLink's byte caching works around small changes in duplicated data. So a few changed, added, or missing bytes in the data stream won't invalidate the cache for the rest of the data. Byte caching is an extension of XipOS lightweight tunnelling. You must enable tunnelling in order to use byte caching. Byte caching is only available on disk-equipped XA models. This includes the "C" models, as well as the XA-10K and XA-30K.

3.8. Packet Compression XipLink's packet compression reduces the size of individual IP packets. Compressing at the IP layer allows this technique to provide benefits to any kind of IP traffic, but it is especially beneficial for UDP-based protocols such as VoIP. Packet compression is an extension of XipOS lightweight tunnelling. You must enable tunnelling in order to use packet compression.

3.8.1. Advanced Cellular Compression Advanced Cellular Compression (ACC) is a modified form of packet compression that provides benefits in networks that make extensive use of tunnelled protocols. In these environments, which are common

31

Understanding XipLink Optimization

among cellular service providers, the main payload is nested inside multiple layers of encapsulation. These multiple embedded protocol headers overwhelm individual packet compression. ACC leverages the data from one packet to help compress those that follow. This allows it to efficiently compress the embedded headers, resulting in significant savings over simple single-packet compression. ACC is a separately licensed capability, and can only be enabled with a valid activation code. Please contact XipLink to obtain an activation code.

3.9. Link Balancing and Bonding Link balancing spreads multiple TCP sessions over two physical links, enabling more efficient use of overall network capacity. The links are continuously monitored, and their usage is intelligently managed by instantaneously moving sessions between links, without interruption, as conditions change. Link usage can also be driven by policy-based algorithms. UDP traffic also benefits because it is allocated to the best link available. Link bonding allows a single TCP connection to combine the capacity of both links to improve throughput. The TCP connection's packets are distributed among the links while maintaining packet order and timing. Together link balancing and bonding enable many innovative solutions, including: • Highly available connectivity. • Session persistence for communications on the move (COTM) networks. • Cost savings by leveraging smaller equipment to achieve higher capacity. Link balancing and bonding is an extension of XipOS lightweight tunnelling. You must enable tunnelling in order to use link balancing and bonding.

3.10. Web Cache Communication Protocol The Web Cache Communication Protocol (WCCP) allows a router to automatically redirect network traffic to the optimizer. It supports a keep-alive mechanism, so the router can stop redirecting traffic if the optimizer goes offline, and resume redirecting when the optimizer returns. WCCP also allows you to install the optimizer without disrupting your network's connectivity. XipLink optimizers implement WCCP version 2. WCCPv2-compliant routers are only available from Cisco (WCCPv2 was first introduced in IOS 12.0(5)T). Cisco's documentation1 provides an extensive overview of WCCP. Please consult your router's documentation for details on configuring WCCP on your router. XipLink optimizers currently implement the following WCCP features: • Support for HTTP and non-HTTP traffic, including UDP • GRE and Layer 2 packet forwarding • Multiple routers • Multiple optimizers • Automatic failover • Limited load distribution using hash assignment (see below) 1

http://www.cisco.com/en/US/docs/ios/12_2/configfun/configuration/guide/fcf018_ps1835_TSD_Products_Configuration_Guide_Chapter.html, for example.

32

Understanding XipLink Optimization

XipLink optimizers currently do not support the following WCCP features: • GRE or Layer 2 packet return (the optimizer forwards its packets normally using ARP lookups) • MD5 shared security • Multicast groups

3.10.1. WCCP Deployments WCCP allows you to deploy XipLink optimizers without interrupting your network. Unlike a typical inline installation, with WCCP you simply connect the XipLink optimizer directly to your network's router, then configure both the optimizer and your router to redirect traffic through the XipLink device. The deployments described here can also be achieved without WCCP using policy-based routing. Please contact XipLink Support for details.

Figure 3.12. Basic Single Interface Mode WCCP Deployment

Figure 3.12 depicts the simplest WCCP deployment. The optimizer's Wireless interface is connected to a WCCPv2-capable router that lies between the local network and the wireless uplink. In this example the optimizer is configured in Single Interface mode so all redirected traffic is sent to the optimizer's Wireless interface. The optimizer can also connect to the WCCP router in Router mode, as shown in figure 3.13. This requires two network ports on the router, one to send redirected traffic to the optimizer and another to receive traffic from the optimizer. The router redirects traffic to the optimizer's Routed interface, and the optimizer returns traffic from its Wireless interface, which the router routes normally. The rest of this section discusses WCCP deployments with the optimizer in Single Interface mode, but all the deployments are also applicable when the optimizer in is Router mode.

Figure 3.13. Basic Router Mode WCCP Deployment

33

Understanding XipLink Optimization

Hub Deployments with Multiple Routers A single optimizer can support more than one router with WCCP. This is most useful for hub deployments, where the optimizer can accelerate traffic with several remote sites each connected to the hub network via its own router. Such an arrangement is shown in figure 3.14.

Figure 3.14. WCCP Hub Deployment

Load Distribution with WCCP WCCP deployments can also make use of more than one XipLink optimizer. This is most commonly used to allocate different types of traffic to different optimizers. For example, HTTP traffic can be handled by one optimizer, all other TCP traffic by another, and all UDP traffic by yet a third optimizer. For more information, see the section called “Assigning Different Traffic to Different Optimizers”. Another way to use multiple optimizers is to have them share the load for a single type of traffic. This requires the router(s) to use GRE packet forwarding. WCCP's load distribution algorithm is based on source (or destination) IP addresses and ports, and so it will not share the load equally among the optimizers. For more information, see the section called “Distributing Traffic Load Among Several Optimizers”. There is no way for multiple XipLink optimizers to share their quality-of-service (QoS) states, and so any multiple-optimizer deployment may not correctly enforce QoS settings. This is less detrimental when different types of traffic are assigned to different optimizers. Please contact XipLink Support for details.

3.10.2. WCCP Configuration Concepts This section describes basic concepts and patterns for configuring WCCP deployments. A WCCP deployment requires complimentary settings in both the WCCP router(s) and the XipLink optimizer(s). This section only deals with concepts. The details of how to apply these concepts to your WCCP router(s) are beyond the scope of this document — please consult your router's documentation. For details on how to enter WCCP configuration settings in the XipLink optimizer's UI, see Section 4.4.10, “WCCP”.

WCCP Router Configuration The WCCP router is responsible for forwarding incoming traffic to the optimizer, and for routing traffic coming from the optimizer. The router's normal routing configuration is usually fine for routing traffic coming from the optimizer. Keep in mind that traffic leaving the optimizer is spoofed: it retains the same source and destination IP

34

Understanding XipLink Optimization

addresses it had when it arrived at the optimizer. So if the router is already correctly handling traffic on the network, then it should also be able to handle that traffic when it passes through the optimizer. In order to forward traffic to the optimizer, the router must be configured with a service group and that service group must be enabled on the interface that receives the traffic to be forwarded. For the purposes of WCCP, a service group is a definition of what kind of traffic to forward. That definition is actually specified by the XipLink optimizer (see below), but the service group itself must be created on the router and assigned to an interface. Each service group is identified by a number. The convention for WCCP forwarding is to use service groups 61 and 62, though any number from 1 to 255 is valid (and your router may already have some service groups defined). XipLink's WCCP implementation uses dynamic service groups. Do not use a well-known service group (such as group 0). Whatever service group numbers you use, the group numbers you configure in the XipLink optimizer must match the groups you define on the WCCP router. When a WCCP service group is enabled on one of the router's interfaces, the router's configuration only specifies that redirection should occur. Where that traffic gets redirected to is determined as part of the WCCP negotiation with the optimizer: The optimizer tells the router which service group it uses, and the router then knows to forward that service group's traffic onto the interface connected to the optimizer. WCCP redirection always requires two service groups. This is because network traffic is (almost) always bi-directional — requests usually expect replies. Part of a service group's definition specifies either source or destination protocol port numbers, but not both. Thus two service groups are needed: One to redirect requests (using destination port numbers), and another to redirect replies (using source port numbers). This requirement is illustrated in figure 3.15. Requests from clients (green path) arrive at the WCCP router on the client-side interface and are redirected to the optimizer by service group 61. Replies from servers (magenta path) arrive on the wireless-side interface and are redirected by service group 62. (Note that the requests and replies forwarded by the optimizer are not redirected by a service group.)

Figure 3.15. WCCP Service Groups

Here are some general recommendations for configuring service groups on a WCCP router. These guidelines may not apply to your situation, or they may be incompatible with your router. Please consult your router's documentation and consider your network's particular setup when defining your WCCP service groups. • Use ingress redirection ("redirect in") rules. The router processes these more efficiently than egress rules. Also, some routers require the use of ingress rules for Layer 2 forwarding.

35

Understanding XipLink Optimization

• Layer 2 forwarding may require the service group to be configured as "accelerated".

XipLink Optimizer WCCP Configuration The XipLink optimizer is responsible for defining which traffic gets redirected by a WCCP service group and whether that redirection uses GRE or Layer 2 forwarding. The optimizer specifies which traffic a service group redirects using the following criteria: • Protocol (TCP or UDP) • Port numbers (or "all ports") • Whether the port numbers should match source values (indicating a response) or destination values (indicating a request) Remember that each type of traffic the optimizer handles via WCCP requires two service groups, one for requests and one for responses. The optimizer's WCCP settings are associated with specific interfaces depending on whether the optimizer is configured in Single Interface or Router mode. Care must be taken to ensure that the service group numbers specified on each interface correspond to the groups configured on the WCCP router. Use the illustrations below to help guide your configuration. The following sections describe some basic WCCP configurations, showing what settings to use in different scenarios. Each of these examples has an illustration depicting the physical interfaces used on the WCCP router and the XipLink optimizer, as well as the settings applied to those interfaces. These configurations can be extrapolated for multiple WCCP routers and/or XipLink optimizers. Please contact XipLink Support for assistance.

HTTP Redirection on a Hub Optimizer in Router Mode In Router mode HTTP requests need to arrive at the optimizer's Routed interface, and replies need to arrive at its Wireless interface.

36

Understanding XipLink Optimization

This setup uses the following configuration settings: • The WCCP router's client-side interface is associated with service group 61. • The XipLink optimizer's Routed interface is also associated with service group 61. • The Routed interface's service group (number 61) specifies redirection of traffic destined to TCP port 80 (i.e. HTTP request traffic). • The WCCP router's server-side interface is associated with service group 62. • The XipLink optimizer's Wireless interface is also associated with service group 62. • The Wireless interface's service group (number 62) specifies redirection of traffic coming from TCP port 80 (i.e. HTTP response traffic). Note how the WCCP router interfaces connected to the XipLink optimizer are not associated with any service group. These interfaces do not need to perform any traffic redirection. XipLink optimizers only support WCCP in either Router or Single Interface mode. Bridge mode does not support WCCP.

UDP Redirection on a Remote Optimizer in Single Interface Mode In Single Interface mode all request and response traffic must be forwarded to the optimizer's Wireless interface.

This setup uses the following configuration settings: • The WCCP router's client-side interface is associated with service group 61. • The WCCP router's server-side interface is associated with service group 62. • The XipLink optimizer's Wireless interface is also associated with both service groups (61 and 62). • Service group 61 (associated with the router's client-side interface) specifies redirection of all UDP traffic coming from the clients. • Service group 62 (associated with the router's server-side interface) specifies redirection of all UDP traffic coming from the servers.

37

Understanding XipLink Optimization

Distributing Traffic Load Among Several Optimizers It is possible to have more than one optimizer in a service group. In this case the router will distribute the load among the optimizers. In XipLink's WCCP implementation, traffic is assigned according to the source IP address of the host initiating the connection. The main effect of this is that if most of the network traffic originates from a single host (or a group of hosts behind a NAT device) then that proportion of the overall traffic will be serviced by only one optimizer. XipLink optimizers only support WCCP load balancing with GRE packet forwarding. Support for load balancing with Layer 2 forwarding is currently not available. Optimizers participating in WCCP load balancing can not share quality-of-service (QoS) states, meaning that they may not be able to properly shape network traffic. If you need to use QoS with your WCCP deployment, please contact XipLink Support for assistance. For simplicity this example shows the optimizers in Single Interface mode. A Router mode setup is equivalent, with the service groups on each optimizer assigned to the appropriate interface (see the section called “HTTP Redirection on a Hub Optimizer in Router Mode”.)

WCCP load balancing requires all the optimizers to use the exact same service group parameters. An optimizer that defines a service group differently in any way will be ignored by the WCCP router. This setup uses three optimizers to share all TCP traffic: • The WCCP router's client-side interface is associated with service group 61. • The WCCP router's server-side interface is associated with service group 62. • All three optimizers define service groups 61 and 62 to redirect all TCP traffic.

38

Understanding XipLink Optimization

Assigning Different Traffic to Different Optimizers This configuration uses three XipLink optimizers to handle different types of traffic: • Optimizer A handles HTTP traffic. • Optimizer B handles all remaining (non-HTTP) TCP traffic. • Optimizer C handles all UDP traffic.

The service groups here make use of WCCP's priority parameter. In WCCP the priority is a number between 0 and 255 that specifies the order in which the router will evaluate service groups when matching network traffic. Service groups with a higher priority number are evaluated before those with a lower number (in other words, the groups are sorted by descending priority number before being evaluated). This setup uses three pairs of service groups. Each pair specifies the redirection of a different type of traffic, and each pair also has a different evaluation priority. • Optimizer A uses groups 61 and 62 to redirect HTTP traffic with a priority level of 20. • Optimizer B uses groups 98 and 99 to redirect all (other) TCP traffic with a priority level of 10. Since their priority level is lower than the priority of groups 61 and 62, groups 98 and 99 will be evaluated after groups 61 and 62. This makes the HTTP redirection take precedence. (If the priority of groups 98 and 99 was higher than that of groups 61 and 62, then no HTTP redirection would occur because the all-TCP redirection would match first.) • Optimizer C uses groups 75 and 76 to redirect all UDP traffic with a priority level of 50. In truth any priority value would work, since the other service groups don't deal with UDP traffic. However, giving groups 75 and 76 a higher priority means that UDP traffic redirection will occur slightly faster than TCP redirection (since the router doesn't need to match UDP traffic against the TCP service groups). This example could also use more than one optimizer to handle a single traffic type, using the method described in the section called “Distributing Traffic Load Among Several Optimizers”.

39

Understanding XipLink Optimization

Prioritizing Traffic Across Multiple Optimizers This example uses WCCP to implement a hot-standby configuration with two optimizers. Both optimizers are configured to handle all TCP traffic, but Optimizer A's service groups have a higher priority level than Optimizer B's.

Optimizer A's service groups (61 and 62) have priority level 20, while Optimizer B's service groups (81 and 82) have priority level 10. This means that the WCCP router will evaluate groups 61 and 62 before groups 81 and 82, and so TCP traffic will normally be redirected to Optimizer A. If Optimizer A goes offline, then the WCCP router will redirect TCP traffic to Optimizer B. The optimizers in this configuration can not share their Quality-of-Service (QoS) states, and this may lead to inaccurate traffic shaping when Optimizer 2 takes over from Optimizer 1. Please contact XipLink Support for details.

3.11. XipLink Wireless Optimizer Internals 3.11.1. Dynamic Socket Buffers XipLink’s Dynamic Socket Buffer allocation software provides full bandwidth scaleability while minimizing delay at all load profiles. Statically allocated buffers introduce buffering delay when the connection count increases, and they cannot scale to make full use of available bandwidth when there are only a few connections. XipOS wireless optimizer software uses advanced memory management technology that scales efficiently, from the smallest of handheld tactical radios and portable terminals to appliances that support tens of thousands of simultaneous connections at over 155 Mbps. The requirement to scale from the smallest of mobile roaming devices to very large hub sites is unique to wireless optimization and is engineered into the XipLink software from the very foundation. Use of Dynamic Socket Buffers is a key to delivering wireless optimization on a wide variety of third party devices running BSD, Linux or Windows operating systems, but is also what enables XipLink to deliver the most performance and the lowest cost on it’s XA-Series of scalable appliances.

3.11.2. Burst Connection Handling XipLink’s burst connection handling accommodates periods of high loads through highly efficient input / output processing techniques. Even on an already loaded system, high end XA-Series optimizer appliances

40

Understanding XipLink Optimization

can handle well over 2000 new connections per second and over 30,000 sessions at any one instance. Any traffic arriving once memory is full will follow a fast path through the XipOS kernel. Those sessions use standard TCP, but they are still subject to the configured XTC rate control mode.

3.11.3. Installation Flexibility XipLink optimizers must be placed in-line with a user's wireless traffic, and can be installed to operate as either a Layer 2 bridge or a full-function Layer 3 router. These two modes allow the greatest flexibility when deploying optimizers into existing or new networks. When operating as a bridge, some optimizer models have a “fail-to-wire” option that monitors the device. If it loses power or if the software detects a problem, the optimizer effectively removes itself from the network path. This ensure continuous connectivity at all times. When installed as a router, the XipLink optimizer can support the OSPF, BGP and RIP protocols. At larger sites, the wireless optimizer can be installed at Layer 3 in a fully redundant configuration. Two optimizers can use the Common Address Redundancy Protocol (CARP) to maintain a primary and backup relationship. If the backup optimizer detects any anomaly in the primary optimizer it automatically takes over, ensuring user traffic remains at the maximum capacity.

Figure 3.16. Bridge at remote - Router at hub

Remote site and embedded software optimizers typically operate in Layer 2 bridge mode, while most hub sites deploy the optimizer as a Layer 3 router in a fully redundant configuration.

3.11.4. Management and Monitoring XipLink optimizers, whether running as an embedded system or on an appliance, can be remotely configured, managed and monitored using SNMP. A local graphical user interface is accessible using HTTP and a command line interface is available via SSH.2 XipOS software can always be upgraded remotely, with each optimizer maintaining an active as well as a backup image and configuration file in case of primary image corruption.

2

Cryptographic security features are only available on "Crypto" product models.

41

Chapter 4. The XipOS Web Interface The XipOS web interface is the primary method of configuring your XipOS device(s). The user interface is designed to be friendly and efficient, with access to any configuration option only two mouse clicks away. This chapter focuses on the various configuration options available, but before you dive in and make changes you will need to understand the concepts and parameters that are configured through this interface. Please refer back to the chapter on Understanding XipLink Optimization if you are new to XipOS-based devices and are unsure as to what configuration changes you need to make. (Note that completing the XipOS Setup Wizard already places the unit in a functional state.) The following sections focus on the various areas of the web interface.

4.1. Dashboard The dashboard area at the top of the screen shows you a quick status of the XipLink optimizer.

4.1.1. Device Name The title bar at the top of the dashboard indicates the name allocated to this device (after the "Editing Device:" label). When working with multiple devices, this indicates the current device that you are configuring. This device name is configured under Networking Setup->Mode->Device Name.

4.1.2. Interface Status The upper-left area of the dashboard displays the status of the device's network interfaces. When the icon is green, this indicates that the interface is currently in the up state. The current IP address, and status of the interface is shown once the configuration has been applied. When the status indicator is yellow, this indicates that the interface is not currently enabled. When the status indicator is red, this means that the interface is currently disconnected or down. Please verify that the network cable is properly plugged into the correct ethernet port.

4.1.3. Service Status The central area of the dashboard displays the status of various optimizer services. The items that appear here differ depending on which features are enabled on the optimizer. These can include: • Optimizer deployment mode (e.g. Router or Bridge) • Lightweight tunnelling status • Redundancy status

42

The XipOS Web Interface

• Web cache status • DNS cache status • WCCP status The status indicator associated with a particular feature is described in that feature's section in this document.

4.1.4. Device Status The bottom of the dashboard displays status information about the device. Load Averages:

Shows the system load for the past 1, 5 and 15 minutes.

The load average is not based just on CPU load but on the culmination of the current processor load and the CPU run-queue length. A value of 1 generally indicates that a single-CPU system is under heavy load. Throughput performance may be degraded during periods of heavy load. If you continuously run on high load, you should consider upgrading to a more powerful unit. Uptime:

Indicates the time since the XA was last powered on or rebooted.

Software Version:

Shows the device's XipOS software version.

Model: Shows the device's product model. Crypto enabled units would always indicate -Crypto in the model name.

4.1.5. Sampling Rate The dashboard is updated periodically according to the Sampling slider bar. To disable dashboard updates, move the Sampling slider bar completely to the left.

4.2. Main Menu All configuration and systems options are accessible through the menu bar below the dashboard. (The menu bar is hidden when the Quick Config Wizard is open.)

The main menu contains the following items: • Networking Setup • Optimization • System • Apply Changes • Statistics • Quick Config Each item corresponds to an area of the UI, and selecting an item opens its area below the menu bar. The following sections explain each area in detail.

43

The XipOS Web Interface

4.3. Applying Changes Most changes you make in the web UI only take effect on the device when you apply them.1 The Apply Changes screen lets you write all of the settings to the device in one operation. This ensures the consistency of the settings in force on the device at any give time. XipOS has two layers of configuration. Both layers contain all XipOS settings, but one is ephemeral while the other persists across reboots: • The startup or permanent settings are loaded when the device boots up. These settings persist across device reboots. • The running or current settings are a copy of the startup settings stored in RAM. These are the settings that actually affect the device's behavior. You can change the running settings without changing the startup settings. This minimizes the risk of trying different configuration options, as you can restore your original settings simply by rebooting. Once you have a satisfactory running configuration, you can make it permanent by saving it to the startup settings.

The Apply Changes screen lets you save either to just the device's running settings, or to both the running and startup settings at one time. If changes are made to the device configuration, the Apply Changes Menu option is highlighted in red and the number of changes not yet applied will be indicated on this page. The Make changes permanent checkbox controls whether configuration information is written to the startup settings. If the box is checked, the device's startup settings are updated, and the device will use the new settings "permanently" even after rebooting. If the box is unchecked, only the running settings are changed and the device will revert to its startup settings the next time it reboots. To save your settings, check or un-check the Make changes permanent checkbox and click the Apply Changes button. 1

The few exceptions to this rule include the device backup, upgrade and reboot actions, as well as changing the administrative passwords.

44

The XipOS Web Interface

The text box below the Apply Changes button shows the progress of the configuration update. If you are making "permanent" changes, the system will first update its running settings. If those new running settings are valid, the device will save them to its startup settings. Should an error occur while applying the new settings, the system will roll back any changes it has made so that the device is restored to the state it was in before the reconfiguration attempt. The UI will display an error message indicating the nature of the failure. Refer to the troubleshooting section for advice. XipOS does not require a reboot to use updated settings. This allows for minimal reconfiguration downtime.

4.4. Networking Setup This section explains how to configure the XipOS network settings. XipOS network settings are highly dependent on how the XipLink optimizer fits into your network's topology. Before proceeding with network configuration, please ensure that you have all relevant information at hand, including: • Relevant subnet and IP addresses of devices that will interact through the optimizer • Gateway addresses and other routing information • A network topology diagram can be very helpful

4.4.1. Mode Settings under the Mode tab determine how the XipLink optimizer integrates with your network.

4.4.1.1. Router, Bridge or Single Interface Mode The XipLink optimizer can be configured either as a bridge, router, or in single interface mode.

45

The XipOS Web Interface

Router mode requires there to be two separate subnets on either side of the optimizer, while bridge mode allows the device to transparently optimize traffic within a single subnet. Single Interface mode uses only the Wireless network interface. This mode requires either lightweight tunnelling or an external router to redirect traffic to and from the optimizer. Redirection can be achieved using either Policy-Based Routing or Webcache Communication protocol Web Cache Communication Protocol. The following table summarizes the differences between the three modes.

Table 4.1. Differences Between Router, Bridge and Single Interface Modes Aspect

Router Mode

Routing influences

Requires separate subnets Transparent to network Requires tunnelling or for routing traffic redirection by an external router

Redundancy

Through a second device Fail-to-wirea Through a second device with CARP passthrough, or via a with CARP second device using STP

Network Translation

Bridge Mode

Address Supported

Not available

Single Interface

Not available

Dynamic routing Supported protocols (RIP, OSPF, BGP)

Can use RIP for route Can use RIP for route discovery only discovery only

Hybrid RX/TX interface Supported

Not available

VLANS

a

Not available

Can bind interface to a VLAN transparency Can bind interface to a particular VLAN may enabled to optimize particular VLAN multiple VLANS.b

Fail-to-wire is only available on selected models. Please review the product matrix for details. When enabling Light Weight Tunneling, only the active VLAN assigned can be tunneled

b

4.4.1.2. Enable Network Address Translation (NAT) With NAT you typically have a private network range behind the NAT Device. This enables devices on the private network to access the public network space. Any connections that traverse a NAT device have their source IP address changed to that of the NAT device. This way the connection's source has a routeable IP address on the public network. The NAT device keeps track of all translated connections and when it receives packets from the public network for a particular connection it translates the destination IP address back into the private network range and forwards the packet through. NAT is assigned to the interface facing the public IP network. Which interface that is often differs for hub and remote devices.

4.4.1.3. Enable GRE Transparency GRE tunnels encapsulate IP packets inside another IP tuple that represent both ends of the tunnel. Enabling this option will allow GRE encapsulated packets to de-capsulated, optimized by the accelerator and then re-encapsulated as GRE packets. There are a maximum number of separate GRE tunnels that may exist simultaneously at any given time. Right now we assume 100 GRE tunnels but this could be expanded through the use of a tunable sysctl.

46

The XipOS Web Interface

4.4.1.4. Enable VLAN Transparency Some networks are separated into different virtual networks using VLANs. VLANs modify the layer 2 (Ethernet) headers with an ID that identifies each virtual network. Enable this option to ensure that VLAN IDs are preserved as packets pass through the device. VLAN transparency is only relevant in bridge mode.

4.4.1.5. Management Interface The Management interface on the device can be configured to act either as a management interface or as a hybrid RX/TX interface. The selection here depends on your particular deployment requirements: Select the "Use as additional (management) interface" option when the Management interface will be used to manage the device. Typically this is used for out-of-band management, to ensure that management traffic is separate from routed traffic for security reasons. SNMP monitoring and traps are often sent via this interface to a central Network Monitoring System. Select the "Hybrid" option when you have two separate wireless channels, one for transmitting (TX) and once for receiving (RX). This is typically used for a remote deployment where you will have a dedicated SCPC transmission channel and a broadband shared downlink DVB channel. Terminating both channels in a single XipOS device does away with any requirement for an additional upstream router.

4.4.1.6. Hub or Remote "Hub" devices act as a gateway to a central network (or the Internet). A hub is connected to the central network on one side, and to the wireless link(s) on the other. A hub typically communicates with several remote XipLink optimizers over the wireless link(s), though a remote optimizer is not necessary for XHO deployments. (A "mesh" device is a hub that communicates with one or more other hubs.) In contrast, a "remote" device only communicates with one hub XipLink optimizer.

4.4.1.7. Device Name For ease of reference and administration, especially when configuring multiple devices, you should configure a unique name for this device. This name is displayed in the web UI, allowing visual confirmation of the device being configured. The name of the device must consist solely of alphanumeric characters without spaces or punctuation.

4.4.2. Interfaces The Interfaces tab allows you to configure the device's network interfaces. The optimizer cannot participate in your network unless its interfaces are properly configured. Please refer to the Redundancy setup section for a description of this page once redundancy has been enabled.

47

The XipOS Web Interface

The Wireless interface is always the interface that connects (directly or indirectly) to the wireless link. All traffic passing through this interface is optimized for transmission over any wireless or high latency network. The Routed (or Bridged) interface is always connected to the low latency, high bandwidth network. The Management interface can either connect to an out-of-band management network, or it can be part of a hybrid networking setup. The MTU (Maximum Transmission Unit) setting defines the maximum size of an IP packet that can be transmitted without fragmentation. Values can range from 576 to 1500. The Media type defines the type of cable that is connected to the Ethernet interface. The default is 'autoselect' which should work in most environments. Auto-detection may not work if you connect to any network equipment that uses a manually configured media type. In this case it is best to also manually configure the optimizer interface's media type, to avoid conflicts. The VLAN setting allows you to associate the interface with a particular VLAN. The default value is 1, which turns off explicit VLAN tagging on the interface. You have the following options for assigning an IP address to the device. • Static: Assign a fixed IP address to this interface. You also need to supply the netmask. • DHCP: Obtain an IP address from a DHCP server on this interface's network. • None: Assign no IP address to this interface. This is only useful when the device is in Bridge mode. More IPs button will popup a window as below that would allow you to assign additional alias IP's to the interface

4.4.3. DNS The DNS tab allows you to configure Domain Name System support on the optimizer.

48

The XipOS Web Interface

The Domain Name System (DNS) translates domain names meaningful to humans into IP addresses that can be routed across the network. It is an IP address directory, similar to a telephone directory, that holds domain name to IP address translations.

On this tab you can specify the IP address of your primary DNS server and, optionally, the address of a secondary/backup DNS server. You may also specify a doman name for the optimizer, although this is not normally required. If you have configured one of the optimizer's network interfaces to obtain its IP address from a DHCP server, you may select Use DNS information obtained from DHCP here to make the optimizer use the DNS settings provided by the DHCP server. Selecting this overrides any static DNS settings you might specify on this tab. If you configure the optimizer to also be a DHCP server (see the DHCP tab), the optimizer will provide DHCP clients with whatever DNS information you configure here. If the optimizer is configured as a DHCP client on one of its interfaces and as a DHCP server on another, selecting Use DNS information obtained from DHCP will make the optimizer serve its DHCP-obtained DNS settings to its DHCP clients.

4.4.3.1. Transparent DNS Caching Many DNS requests pass through the optimizer during regular network activity. Each DNS request is normally passed to one or more remote DNS servers, and the requesting application must wait for a response before continuing with its network activity. On a link with a 500ms delay, this process adds at least 1 second to each connection's establishment time. To accelerate DNS request resolution, you can enable transparent DNS caching to have the optimizer intercept DNS traffic and cache the responses provided by DNS servers. With transparent DNS caching, an initial DNS request must still be forwarded to the authoritative DNS server. However, subsequent requests can be served directly from the optimizer's cache, eliminating any delay. Transparent DNS caching is only available on Remote devices.

Transparent DNS caching is only applied to requests that arrive via the network interface shown. Which interface that is depends on how the optimizer is configured.

49

The XipOS Web Interface

The cache lifetime of a DNS reply is controlled by the upstream DNS server. Some servers on the Internet use very short lifetimes in their replies, and for these domains the caching benefit may be difficult to measure. The DNS cache's status is visible in the dashboard:

When you move you mouse cursor over the DNS cache status box in the dashboard, the status text is replaced by a button that allows you to clear the DNS cache:

4.4.4. Routes The Routes tab allows you to configure static routes for the optimizer. (Dynamic routes for optimizers in Router mode can be configured through the RIP, OSPF, or BGP tabs.) Static routes override dynamic routes. The order of precedence for routing is: 1. Static routes are matched first. 2. Dynamic routes are matched second. 3. The static default gateway is the route of last resort.

The optimizer routes all traffic for subnets that are not in the static or dynamic routing tables through the default gateway. The default gateway is normally the device's access point for upstream network connectivity. For a "remote" device, this is usually the IP address of the wireless link's router or modem. For a "hub" device, this is usually the IP address of the hub site's Internet router or modem.

50

The XipOS Web Interface

When one of the device's interfaces is configured to use DHCP, the default gateway text box is disabled, and "(DHCP)" appears next to the box. This indicates that the default gateway will be configured via DHCP. Click the Add button to add a static route. Each static route requires a subnet, mask and gateway. If any of these values is syntactically incorrect, its field will turn red. If the value is correct but otherwise invalid, an error code will appear to the right of the route's settings. Hover the mouse pointer over the error code to see an explanation of the problem. The error codes are: • S -- invalid subnet. The subnet must complement the mask: all unmasked bits must be 0. • M -- invalid mask. All the 1 bits in the mask must be contiguous. • G -- invalid gateway. A static route's gateway must be in the same local subnet as one of the device's interfaces. To delete a static route, select it and click the Del button. When there are multiple subnets that are reachable through a non-default gateway, each subnet must be added to the static routing table. When using only static routing, if you wish to manage the optimizer via telnet or SSH or the web UI from a PC that is not connected to one of the device's local subnets, then you must ensure that one of the static routes (or the default gateway) will provide access to that PC's subnet.

4.4.5. RIP The RIP tab contains settings that allow the optimizer to participate in the Routing Information Protocol. RIP is a dynamic routing protocol that calculates the next forward address to a destination using a distancevector routing algorithm. The distance to a destination is measured as the number of routers between the optimizer and the destination (this is called the "hop count").

Once RIP is enabled on the device, you can select which interfaces will advertise subnets, and also configure which subnets to advertise. RIP subnet masks must be a CIDR-style number of significant bits. A dot-style mask (e.g. 255.255.255.0) will not work.

51

The XipOS Web Interface

RIP is not interoperable with the following system services: • Tunnel Client • Tunnel Server: Route redistribution The Route redistribution settings control what additional routing information is advertised: • Connected. • Kernel. • Static.

Advertise all routes learned from other routers.

Advertise all routes learned by this device's kernel. Advertise all entries in the static routing table. Careful planning is required to ensure that invalid or duplicated routes are not included when using the Static option, as this may lead to routing loops if there is more than one border router implemented within the routing domain.

4.4.6. OSPF The OSPF tab contains settings that allow the optimizer to participate in the Open Shortest Path First routing protocol. OSPF is an interior gateway protocol that routes IP packets solely within a single routing domain (autonomous system). It gathers link state information from available routers and constructs a topology map of the network. The topology determines the routing table presented to the IP layer, which makes routing decisions based solely on the destination IP address found in IP datagrams. OSPF detects changes in the topology, such as link failures, very quickly and converges on a new loop-free routing structure within seconds. It computes the shortest path tree for each route using a method based on Dijkstra's algorithm, a shortest path first algorithm. The OSPF routing policies used to construct a route table are governed by cost factors (external metrics) associated with each routing interface. Cost factors may be the distance of a router (round-trip time), network throughput of a link, or link availability and reliability, expressed as simple unitless numbers. An OSPF network may be structured, or subdivided, into routing areas to simplify administration and optimize traffic and resource utilization. Stub areas are identified by 32-bit numbers, expressed either simply in decimal, or often in octet-based dot-decimal notation, familiar from IPv4 address notation. By convention, area 0 (zero) or 0.0.0.0 represents the core or backbone region of an OSPF network. The identifications of other areas may be chosen arbitrarily. Often, administrators select the IP address of a main router in an area as the area's identification. Each additional area must have a direct or virtual connection to the backbone OSPF area. Such connections are maintained by an interconnecting router, known as an Area Border Router (ABR). An ABR maintains separate link state databases for each area it serves and maintains summarized routes for all areas in the network.

52

The XipOS Web Interface

Once OSPF is enabled on the device, you can specify the device's Stub Area and also configure which networks and areas to advertise. The Route redistribution settings control what additional routing information is advertised: • Connected. • Kernel. • Static.

Advertise all routes learned from other routers.

Advertise all routes learned by this device's kernel. Advertise all entries in the static routing table. Careful planning is required to ensure that invalid or duplicated routes are not included when using the Static option, as this may lead to routing loops if there is more than one border router implemented within the routing domain.

4.4.7. BGP The BGP tab contains settings that allow the optimizer to participate in the Border Gateway Protocol. BGP is an exterior routing protocol used to connect various autonomous systems (ASes) together. This is the core routing protocol of the Internet. It maintains a table of IP networks or 'prefixes' which designate network reachability among autonomous systems. It is a path vector protocol. BGP does not use traditional IGP metrics, but makes routing decisions based on path, network policies and/or rulesets.

53

The XipOS Web Interface

Once BGP is enabled on the device, you can specify the device's AS Number, Network and Netmask, and also configure neighbor ASes. The Route redistribution settings control what additional routing information is advertised: • Connected. • Kernel. • Static.

Advertise all routes learned from other routers.

Advertise all routes learned by this device's kernel. Advertise all entries in the static routing table. Careful planning is required to ensure that invalid or duplicated routes are not included when using the Static option, as this may lead to routing loops if there is more than one border router implemented within the routing domain.

4.4.8. DHCP The DHCP tab controls the device's built-in Dynamic Host Control Protocol server. Manually assigning IP addresses on a network can quickly become cumbersome and error-prone. DHCP eases IP address management, as client workstations are automatically assigned a IP address when connecting to the network.

54

The XipOS Web Interface

Once enabled, the DHCP server will issue an IP address to any DHCP client that requests one. You can specify which Interfaces will provide the DHCP service. There can only be one DHCP server within a network segment.

For each interface, you can specify the range of IP addresses that should be assigned by the DHCP server. Make sure that the specified ranges do not overlap with any statically-assigned IP addresses.

The lease durations can be specified in hours, minutes or seconds. Once a client's lease expires, the client has to renew the lease or request a new IP address. This process helps keep the DHCP server's IP address tables clean of invalid IP leases. If your network does not change frequently, you can supply a larger value for the DHCP lease time.

4.4.9. SNMP The SNMP tab controls the device's support for the Simple Network Management Protocol. SNMP is a popular protocol for network management. It is used for configuring and collecting information from network devices such as servers, printers, hubs, switches, and routers. The XipOS SNMP service replies to SNMP status requests. It can also transmit critical status messages (traps) to one or more SNMP management systems. Device configuration via SNMP is not supported at this time.

55

The XipOS Web Interface

After enabling the SNMP service you must specify either SNMPv1/v2 or SNMPv3 and supply the appropriate authentication credentials. SNMPv1 and SNMPv2 both use a Community String for authentication. SNMPv3 uses a user ID and password. XipOS supports SNMPv3 message authentication using the SHA authentication protocol and the "authentication and no encryption" (auth/noPriv) security level. Enable SNMP Traps in order to set critical status alerts to one or more SNMP management systems. A comma-separated list of IP addresses identifies which hosts should receive traps. You can also specify a minimum time interval to wait between sending traps. XipOS includes additional XipOS-specific MIBs. To make this information available to your SNMP monitoring system, you will need to import the XIPLINK.txt MIB file into your SNMP application. This file is stored on the XipOS device as /share/snmp/mibs/XIPLINK.txt. You can use scp to copy the file locally (on Windows, use an scp application such as WinSCP.

4.4.9.1. XipOS SNMP Traps XipOS generates SNMPv1 traps with a community string of "public". The object identifier (OID) for XipOS SNMP trap messages is 1.3.6.1.4.1.22480.5 (iso.org.dod.internet.private.enterprise.xiplink.5). The following table lists the SNMP traps that XipOS can generate.

Table 4.2. XipOS SNMP Traps Trap # Name

Description

1

EXEC_FAILED

Failed to launch a critical process.

2

MISSED_HEARTBEAT

The XipOS monitoring system did not receive a regular signal from a critical process.

3

PROCESS_EXITED

A critical process terminated (and was restarted).

4

CONN_LIMIT_REACHED The device has reached its maximum supported number of optimized connections.

56

The XipOS Web Interface

4.4.10. WCCP WCCP settings must be applied to both the WCCP router and the XipLink optimizer. Please see Section 3.10, “Web Cache Communication Protocol” for more information. The WCCP tab configures the device to participate in the Web Cache Communication Protocol with a WCCP-compatible router. The XipLink device must specify one or more pairs of WCCP redirection service groups. Each service group in a pair is assigned to a network interface, and specifies the traffic that the WCCP router should redirect to that interface. The service groups in the pair should match each other, except that each has a different ID and specifies a different direction (requests or responses) for the redirected traffic. (In Single Interface mode the pair of service groups both configure the single interface). The WCCP tab automatically displays which interfaces are available for configuration, depending on the device's mode. Please refer to Section 3.10, “Web Cache Communication Protocol” for an overview of WCCP configuration.

After enabling WCCP, you may specify one or more redirection services on each available interface. A redirection service identifies: • How to redirect traffic (GRE or layer 2). • The load-balancing method (mask or hash) the router should use to share the redirected traffic among multiple optimizers. See below for more information. • What traffic to redirect (protocol and port numbers). • Which direction of traffic to redirect (requests or responses). When using GRE redirection in WCCP, it is not necessary to set up GRE tunnelling on the XipLink optimizer. When the device is configured in Router mode each redirection service specified on one interface must have a mirror redirection specified on the other interface. For example, if one interface specifies GRE redirection of HTTP request traffic, the other interface must specify GRE redirection of HTTP response traffic.

57

The XipOS Web Interface

When the device is in Single Interface mode, both the request and response redirection services must be specified on the single interface. Use the dropdown box to select a redirection service, then press the Add Service button to add the service to the interface. Each service has the following properties: • The optimizer's membership in the redirection service group can be enabled or disabled. • The ID field is the service group number. • The Priority field is the service group's priority compared to other service groups on the WCCP router. See the section called “Prioritizing Traffic Across Multiple Optimizers” for details. • The Ports list is a comma-separated list of port numbers. These ports identify which type of traffic the service group redirects. An empty list means the service should redirect all traffic for the specified protocol (TCP or UDP). WCCP only allows the ports list to contain up to 8 port numbers.

• The Router list is a comma-separated list of WCCP router IP addresses. These are the WCCP routers that the optimizer will attempt to register with for WCCP redirection. To delete a service from an interface, select it in the table then press the Delete Service button.

Configuring Multiple XipLink Optimizers with WCCP A single WCCP service group can contain multiple XipLink optimizers. This can allow the optimizers to share traffic load (see the section called “Distributing Traffic Load Among Several Optimizers”). XipLink's own redundancy feature (see section 4.4.11) is fully compatible with WCCP and does not require any special configuration. The WCCP router will only see the currently active optimizer of the redundant pair. A failover within the pair triggers a WCCP renegotiation, meaning network traffic will be momentarily interrupted while the WCCP router and the newly active optimizer shake hands. When configuring multiple optimizers in a WCCP group, please take into account the following caveats. You must ensure that all the XipLink devices in a service group have identical definitions of that group. Load sharing currently only works with GRE forwarding (not Layer 2 forwarding).

The optimizers in a WCCP group can not share quality-of-service (QoS) states, meaning that they may not be able to properly shape network traffic. If you need to use QoS with your WCCP deployment, please contact XipLink Support for assistance.

WCCP Status When WCCP is enabled, the optimizer's WCCP status is displayed in the dashboard:

58

The XipOS Web Interface

The optimizer's overall WCCP status can be either Down or Running. If WCCP is running, the status area also displays the IP addresses of any routers with which the optimizer has negotiated WCCP. These are the routers that the optimizer expects will redirect traffic to its interface(s). A router IP address may be displayed for the Wireless (W) interface and, if applicable, the Routed (R) interface. Clicking on the WCCP status area in the dashboard opens a detailed WCCP status report:

The detailed WCCP status report shows the state of the WCCP-specific GRE tunnels (if the WCCP setup uses GRE forwarding). The report also contains a Services table showing which routers and optimizers are visible on each interface. The table contains the following columns: • I/F:

The interface to which the service group (or groups) is (are) assigned.

• ID:

The service group ID number.

• Fwd:

The service group's packet forwarding method (l2 or gre).

• Assgn: The load-balancing method (mask or hash) the service group uses to assign traffic to different optimizers. • Routers:

The IP addresses of routers visible in the WCCP service group.

• Caches: The IP addresses of optimizers visible in the WCCP service group (including the current optimizer's own IP address).

4.4.11. Redundancy The Redundancy tab allows a device in Router mode to be configured for redundant operation. Redundancy requires a second XipOS device to be on hot standby, ready to take over should the primary device fail. Each device is configured with a single virtual IP address that is used for routing traffic. The standby device will take over if the primary device's Ethernet MAC address stops responding. Failover normally happens in a fraction of a second, with little to no packets being dropped while the standby device becomes available. A switch must also be deployed on either side of the redundant pair. See the Router Mode Redundancy Setup figure below. Redundancy configuration is only applicable for devices setup in router mode. Redundancy for devices in bridge mode is supported through the use of STP (Spanning Tree Protocol). Some XipLink optimizer models have a fail-to-wire feature that is compatible with Bridge mode and ensures connectivity if the device fails.

59

The XipOS Web Interface

Enable Clustering. checkbox'.

To configure device redundancy, you need to enable the 'Enable Clustering

To complete this setup, you must configure the device's network interfaces on the Interfaces tab.

To configure a redundant cluster you must specify, on each device: • The device's own physical (real) IP addresses. • The cluster's virtual IP address. • The physical (real) IP address of the other device in the cluster. All this information is configured for both the Wireless and Routed sides of the cluster. Redundancy requires that the virtual and physical IP addresses on one side of the cluster must be part of the same network subnet.

Figure 4.1. Router Mode Redundancy Setup

Procedure 4.1. Procedure to configure Redundancy 1.

Connect your XipLink optimizers and switches as shown in the figure above.

2.

Login to device A via the web UI.

3.

Under the Networking setup -> Redundancy tab, select the Enable clustering checkbox.

60

The XipOS Web Interface

4.

Select the Preferred master checkbox. The preferred master always routes the traffic whenever both devices are available.

5.

Specify a unique password that will be common between the two cluster members.

6.

Choose cluster member ID A.

7.

Select the Interfaces tab and configure the virtual IP address of this device (A) and also the real IP addresses of both devices (see screenshot below).

8.

Apply the changes, and make them permanent.

9.

Login to device B via the web UI.

10. Under the Networking setup -> Redundancy tab, select the Enable clustering checkbox. 11. As this is the cluster's secondary device, make sure that the Preferred master checkbox is unselected. 12. Specify the same password you configured for device A. 13. Choose cluster member ID B. 14. Select the Interfaces tab and configure the virtual IP address of this device (B) and also the real IP addresses of both devices (see screenshot above). 15. Apply the changes, and make them permanent. Most other settings on the two units should be identical, particularly the routing tables and DNS setups. When configuring the networks on either side of the redundant cluster, use the virtual IP addresses as the gateways for routing traffic. You cannot configure a device for redundancy if it is also configured as a database master for configuring remote devices.

61

The XipOS Web Interface

4.5. Optimization This section explains how to configure the XipOS optimization settings.

4.5.1. Optimization The Optimization tab allows you to configure the optimizer's optimization settings.

The Enable Optimization checkbox allows you turn all optimization on or off. When optimization is off the device will act as a standard router bridge, passing traffic through without any acceleration. When optimization is enabled traffic is transparently proxied and optimizations are applied according to the settings found on this tab and also on the Service Assignment tab. The Enable QoS checkbox controls the use of quality-of-service (QoS) on the optimizer. QoS is used not only for traffic shaping but also for classifying traffic for optimization. Therefore, disabling QoS also disable Optimization.

Optimization parameters Select the XipLink Transport Control (XTC) mode best suited for your wireless environment. Refer to the section on XipLink Transport Control (XTC) Modes for a detailed description on these options. • Fixed Rate Control Mode. This mode is ideally suited for dedicated fixed-rate links where the available bandwidth is not shared with other users. Best-effort throughput is maintained at the rates defined in the Service Assignment tab. • Dynamic Rate Control Mode. This is ideally suited for dynamic rate links where the available bandwidth is dependant on how many other users are currently using the network. For example on TDMA networks. • Enhanced TCP Mode. This is a less aggressive mode where QoS may be implemented on external networks and the above modes may then restrict the throughput performance. The Use Compression checkbox enables or disables TCP data compression on the optimizer.

62

The XipOS Web Interface

Hub-only HTTP Compression is configured independently of this setting.

Enable Black-hole Detection to have the optimizer suppress ICMP Destination Unreachable error messages. These messages are normally sent in response to an attempt to connect to a non-existing host or a closed TCP port. Suppressing them can help prevent some denial-of-service attacks.

SCPS-TP Options These options modify the behavior of the SCPS protocol. Please refer to the section on SCPS Acceleration for more information. Acknowledgement Frequency Reduction (AFR) Enabling AFR will reduce the number of acknowledgements the receiver will send back as data is received. This feature can reduce packet overhead by 33% or more while sustaining maximum throughput across the wireless link. AFR should be only selected if the gateway at the other end is configured to use either Fixed or Dynamic Rate Control. AFR only applies to traffic received by the device. That is, it controls how the device acknowledges the receipt of traffic. The ACK ratio can be specified with the selection box as the number of packets per ACK (PPA). On highly asymmetrical links (e.g. 10Mb upstream and 1Mb downstream), enabling AFR on the remote device (the one with the 1Mb uplink) will improve performance. Use the DupAck checkbox to enable AFR for duplicate ACK packets. Always enable Selective Negative ACKs (SNACKs) unless the wireless return channel suffers from high packet loss. XipLink optimizers auto-negotiate this setting between devices: If both have SNACKs enabled, then they'll use it. Otherwise, if one or both have SNACKs disabled, the devices will use selective acknowledgements (SACKs) instead. In high-loss conditions, the overhead of using SACKs is less detrimental than the problems caused by losing a SNACK. Select Enable Fast Start to allow the optimizer to include request data in the connection establishment handshake.

Hub-only Optimization Some XipLink optimizer models support hub-only optimizations. See the XipLink Hub Optimizations section for details. Hub optimizations only provide benefits if they are enabled on the "upstream" or "Internet" side of a wireless link.

63

The XipOS Web Interface

XiPix: Once XiPix is enabled, you can specify Minimum threshold and Maximum threshold image sizes, in bytes. XiPix ignores any images that are smaller than the minimum or larger than the maximum. You can also specify a Quality level using the slider control. The sample image shows you the visual impact of a particular quality setting. The percentage value shown below the slider is an estimate of the reduction in image size for the selected quality level. In order to enable XiPix you must provide a valid activation code. Please contact XipLink to obtain a code. HTTP Compression:

Use the checkbox to enable or disable HTTP compression.

Expert Only Options These options generally do not need to be modified unless so requested by support personnel in order to assist with debugging of the link. Perform MTU path discovery is enabled by default to automatically adjust each sessions MTU (Maximum Transmission Unit) based on the ICMP responses when the DF (Don't Fragment) bit has been set. In certain situations this may not be feasible when the 'ICMP(4) Fragmentation required' packets are not received by the sending XipOS. This can be due to firewalling restrictions upstream or perhaps a 3rd party tunnel that is being established in the path upstream. Disabling the Path MTU discovery option would effectively disable the DF bit in the SYN packet which can cause unnecessary fragmentation and de-fragmentation (degrades performance) if the interface MTU value or the maximum MSS values are incorrectly specified. Enforce maximum MSS value setting allows you to specify the MSS (maximum segment size) to be used for any new proxied connections established from the XipOS device. This allows you to overcome MTU black holes when ICMP(4) notification messages are not being received and the tcp packets are being dropped due to path MTU discovery DF enforcement. Preserve Connection Port Numbers will attempt to use the same tcp source port for new proxied connections. This is useful when known issues exist with current IDS (Intrusion Detection Systems) or advanced firewall expecting connections to be from a particular source port. Enabling this option when in bridge mode may cause a retransmission storm when the bridge XipOS goes into fail to wire, or when the proxies are disabled for whatever reason.

4.5.2. Networks The Networks tab allows you to define the various IP networks connected this device. These definitions form the basis of the service assignments that control how the device handles all the traffic that it sees.

64

The XipOS Web Interface

The primary purpose of the Networks tab is to help you easily define the links and sites that make up your network. While you can also manipulate links and sites on the Service Assignment tab, the tools available from the Networks tab are designed for convenience and to alleviate the tedium of creating many links or sites at one time. The first tool is the Link Editor, which lets you specify the properties of the link(s) connected to the optimizer. The second tool, the Links and Sites Wizard allows you to add new links and add sites that share a link. These tools are described in detail below. You can access either tool by clicking its button. The Networks tab also has a secondary purpose, which is represented by the controls found at the bottom of the tab: Select Standalone hub deployment if your optimizer is to be deployed as a pure XHO hub (i.e. without a remote XipOS device). Selecting this option disables SCPS acceleration and TCP-level compression. The optimizer still proxies all TCP connections, but only applies XHO optimizations to HTTP connections. If you have a hub where some sites have a remote XipOS device and others do not, you can override this setting on a per-site basis using a QoS queue for each site and configuring specific TCP optimizations on the Service Assignment tab. If your optimizer is a pure XHO hub, only select Adjust settings for an external Optimizer/PEP if you have an upstream Performance Enhancing Proxy (PEP) installed between this optimizer's Wireless interface and the wireless transmission equipment. This is required for any PEP that creates spoofed connections, such as a web cache. The 'Wireless' ethernet max speed setting controls the maximum speed of traffic on the Wireless interface. This is typically the speed at which the interface syncs to its switch. For example, set this to 1000Mb for 1000BaseTX Ethernet media.

Network Links and Sites A link is a logical connection between two or more sites on a network. A link can be as simple as a single network cable, or it can traverse a variety of network segments and equipment. Links have characteristics like bandwidth and round-trip-time. A site is a logical grouping of devices that use a link. A site is often a LAN connected to a link via a router. Several sites can share a link, and when they do they share the link's characteristics.

65

The XipOS Web Interface

A helpful tool for configuring your optimizer is a network diagram showing the links connected to the optimizer and the sites that share them. A sample network diagram appears below. It depicts a hub optimizer (on the left) connected to two links, and each link is shared by more than one site. Later sections will refer to this example.

Example 4.1. Multi-Link / Multi-Site Network Example

The links in this example have the following characteristics: Link 1

Link 2

• 16 Mbps maximum transmission speed

• 8 Mbps maximum transmission speed

• 8 Mpbs maximum receive speed

• 4 Mbps maximum receive speed

• 800ms round-trip time

• 650ms round-trip time

• Shared by three sites, each behind a XipLink optimizer:

• Shared by two sites without any other XipLink optimizer:

• Site 1:

• Site 4:

• 2Mb maximum transmission speed

• 4Mb maximum transmission speed

• 8Mb maximum receive speed

• 8Mb maximum receive speed

• 4Mb priority receive speed

• 3Mb priority receive speed

• Site 2:

• Site 5:

• 1Mb maximum transmission speed

• 4Mb maximum transmission speed

• 8Mb maximum receive speed

• 8Mb maximum receive speed

• 2Mb priority receive speed

• No priority receive speed

• Site 3: • 5Mb maximum transmission speed • 8Mb maximum receive speed • 6Mb priority receive speed

66

The XipOS Web Interface

4.5.2.1. Link Editor The link editor lets you change the properties of the links you've defined. Here the properties for Link 1 are set according to the values in Example 4.1.

Use the dropdown to select the link you wish to edit. Any changes you make are automatically saved (though not applied to the optimizer until you apply changes). Click the Close button to close the link editor. The Maximum Transmit Bandwidth is the maximum speed at which the device will transmit data over the link, while the Maximum Receive Bandwidth is the expected maximum speed that the device will receive data from the link. Bandwidth and rate values must be specified with a unit: • Mb = 1,000,000 bits per second • Kb = 1,000 bits per second • b = 1 bit per second These values can only be integer numbers (without commas); decimal points are ignored. The Link Round Trip Time is the total amount of time (in milliseconds) it takes for a packet to travel over the link in both directions. This critical value is used by the Rate Control algorithms and also ensures that sufficient buffer space is allocated to manage inflight data. If you have created more than one link on your device, a Delete all others button appears in the link editor. This button allows you to easily reset the device's configuration to contain only a single link and site. Clicking it deletes all other links except the selected link, including their sites, and it also deletes all but one of the selected link's sites. Please note that this button only resets the configuration you are editing in the UI. As usual, the update is not recorded on the device until you apply changes. If you mistakenly press this button (and have not applied the change), you can recover the original configuration by reloading the UI in your browser.

4.5.2.2. Links and Sites Wizard This wizard allows you to create new links and also quickly add several sites to a link. You can also create links and sites one at a time on the Service Assignment tab, but if you have many sites and links to set up this wizard will save you time.

67

The XipOS Web Interface

Use the controls in the Link information area to specify which link you want to contain the new sites. You can either add new sites to an existing link, or create a new link and its sites at the same time. The Define new Sites area provides two methods for adding new sites to a link. You can either Populate the site list using a formula or Paste a site list.

Defining Sites with a Formula The above screen shot shows the Wizard about to create Example 4.1's 3 sites for Link1 using the formula method. This method requires the following inputs: • The Number of sites to create according to the Template parameters. • An IP Address Template that defines how each site's subnet will be generated. Site subnets use CIDR notation, i.e. [IP address]/[bitmask size]. For example, 10.11.12.0/24. • A Site Name Template that defines how each site's name will be generated. The templates work by allowing you to define the pattern you want for the site subnets and names. Each pattern can contain a special token, {x}. When the site list is generated the {x} token is replaced by an integer value that is incremented for each site. If you omit the {x} token from a template the site list will contain identical entries.

The values shown in the screen shot include Site{x} for the Site Name Template, and 10.1.{x}.0/24 for the IP Address Template. These will generate 3 sites as follows: • Site1 and 10.1.1.0/24 • Site2 and 10.1.2.0/24 • Site3 and 10.1.3.0/24

68

The XipOS Web Interface

The IP Address Template and the Site Name Template both let you specify a starting value for {x}. This example used a starting value of 1 in both templates.

Previewing and Creating the Sites With the parameters of the site list formula defined you can now generate the list of sites to add. Click the Populate Site List button. This expands the wizard's window to show you a Preview of the sites that will be added.

You can edit the site names and subnets here before adding them to the configuration. When you are ready, click the Add site(s) to configuration button to add the sites to the link.

Defining Sites with a Site List The second method the Links and Sites Wizard provides for adding new sites is the Paste a site list method. When you select this option the Wizard presents you with a text box for you to copy-and-paste in a list of sites to add. This list is a simple text format, with one site per line and a tab character between the site's name and its subnet. For example, the site list for Example 4.1's Link2 would be: Site4 tab 10.2.4.0/24 Site5 tab 10.2.5.0/24

This format is applied automatically if you copy and paste cells from an Excel spreadsheet into the text box. The following screen shot shows the Wizard about to create Link2 from Example 4.1 with its two sites, after pasting in the site list from an Excel spreadsheet. The tab characters are replaced with the string {tab}. You can also type the site list directly into the text box. Instead of pressing the Tab key to enter a tab character, use the {tab} string instead. The screen shot also shows that the Wizard will add Link2 as a new link. The Wizard lets you edit the new link's name and properties.

69

The XipOS Web Interface

Click the Populate Site List button to preview the new sites and then create them, as described above.

4.5.3. Service Assignment The Service Assignment tab allows you to configure how the optimizer handles different types of traffic and traffic to or from particular sites. It is your primary tool for exercising fine-grained control over the traffic that flows through the optimizer. This control is achieved using quality-of-service (QoS) queues. Please see Section 3.4.4, “Quality of Service” for an overview of the QoS subsystem. The Service Assignment tab is essentially an editor for QoS queues. Before making QoS changes, we recommend that you first configure all of your network's links and sites, and that you test them thoroughly. Once you have a working network, it is much easier to implement and troubleshoot traffic shaping. The following screen shot shows the Service Assignment tab populated with the links and sites from Example 4.1.

70

The XipOS Web Interface

The QoS queues on this tab are arranged according to the links and sites that were initially configured in the device with the Networks tab. From here you can create new top-level queues or child queues, and edit or delete any queue. The tab is divided in two sections. The main part is a table containing all the QoS queues on the device. The lower part is a firewall rule editor you use to associate traffic with a particular queue. When you select a leaf queue in the upper table, the queue's associated firewall rules appear in the rule editor. The firewall rule editor is described in the Traffic Assignment tab section. Only bottom-most (leaf) queues have associated firewall rules.

Select a QoS queue by clicking on its name in the blue Queue Name column on the left. The selected queue is highlighted in red. If a queue has child queues, you can view (or hide) the children by first selecting the parent queue, then clicking on the parent queue's name a second time. When you select a queue, a context menu button appears to the left of the queue's name. Click on this button to open a context menu for the selected queue.

71

The XipOS Web Interface

The queue context menu has the following options: • Edit queue: Edit the queue's properties. You can also edit a queue by clicking on one of its values in the white columns. This places the queue's properties into editable controls:

• Add child queue: Creates a new queue as a child of the selected queue. • Clone queue: Creates a new queue as a sibling of the selected queue, and copies the selected queue's properties into its new sibling. • Delete queue: Removes the selected queue (and its associated firewall rules) from the system. • Add filter rule: Adds a new firewall rule associated with the selected queue.

4.5.3.1. Queue Properties Remember that queue properties apply to traffic transmitted from the optimizer over the Wireless interface. Queue Name: The name of the QoS queue. Normally queue names correspond to links and sites in your network, but you can use any names you like. Max TX:

The maximum speed at which the optimizer will transmit traffic in this queue.

Gtd TX: The guaranteed transmission speed that the optimizer will use for this queue when the link is congested. Pri TX: The priority transmission speed that the optimizer will both guarantee and prioritize to service real-time protocols. Use this in conjunction with the maximum queue delay (Max Q Dly) value to ensure sufficient response rates for traffic such as voice, streaming media or gaming. The optimizer will still make priority bandwidth available to other traffic if this queue does not need it. The priority speeds of a queue's children can not together exceed 80% of the queue's maximum speed. RTT: The round trip time, in milliseconds. This value is only used in top-level queues (which usually represent network links). Max RX: The expected maximum rate for traffic received in this queue. This value controls how many buffers the optimizer allocates to receive the queue's traffic. For optimum performance, the value here should match the corresponding Max TX value on the device sending traffic in this queue to this optimizer (or the sum of those values if more than one device is sending such traffic). Setting Max RX too low can reduce the rate at which the queue will receive traffic.

Max Q Dly: The queue's maximum packet latency, in milliseconds. Packets will not be held in this queue for longer than this time. Always use Auto here for TCP traffic. Enc Budgt: The encapsulation budget for packets in this queue. If you are using an external system that adds a per-packet overhead, enter the number of bytes that system adds to each packet here. Note that the optimizer automatically takes into account the encapsulation overhead of its own features (like XipLink's own Lightweight tunnelling), so you do not need to account for those here. Sess Rate:

The maximum transmission speed for TCP sessions associated with this queue.

72

The XipOS Web Interface

Per-class TCP Optimizations: Leaf queues associated with TCP traffic can override various systemwide TCP optimization settings. This allows you to apply different optimizations to different links in your network.

To configure class-specific TCP optimizations, select the TCP class in the Service Assignment table then click the context menu button on the right. The TCP optimizations you can override are: • The transport control algorithm. • The use of SCPS. • Slow-reader detection. • Acknowledgement frequency reduction (AFR).

4.5.4. Traffic Assignment The Traffic Assignment tab allows you to assign traffic to the various QoS queues defined in the Service Assignment tab. Traffic assignment is done using firewall rules, and so the Traffic Assignment tab is actually a firewall rule editor. In addition to creating and editing firewall rules associated with the QoS queues, you can also create your own firewall rules for your own purposes. The order of the rules is critical. Each rule is numbered, and rules with a lower number (i.e. that are higher in the list) are matched before the rules that follow. Therefore, the more specific rules must appear higher in the list than more general ones. You can rearrange the rules by dragging-and-dropping them using the green rule numbers on the left of the list.

To create a new firewall rule, click on either the Add First button (to insert a new rule at the top of the list) or the Add Last button (to add a new rule to the bottom of the list). At any time you can use the rule's number (in green) on the left to drag-and-drop the rule to where you want it in the overall list. When you move the mouse cursor over a rule, it is highlighted. Clicking on a rule's highlighted area selects the rule. You can also shift-click and control-click to select more than one rule.

73

The XipOS Web Interface

With one or more rules selected, you can remove and/or duplicate them with the Cut, Copy and Paste buttons. Pasted rules are inserted above the topmost currently selected rule. The Del button allows you to delete the selected rule(s). Firewall rule fields are described below. Editable fields have a control such as a dropdown box, a context button, or a check box.

Network Objects Network Objects provide a convenient method for naming and referring to various network entities, such as site subnets or protocol port numbers. With Network Objects you can use names to represent a value (or a list of values) in a firewall rule. For example, the name NET:Site3 can represent a subnet address such as 10.1.3.0/24. You can use the NET:Site3 name in firewall fields instead of the numeric subnet. This makes it easier to understand the firewall rules. If you later change the value of the NET:Site3 name, the new value will be applied wherever the name is used. This simplifies updating the optimizer's configuration as your network evolves. There are 2 types of Network Object: • NET objects represent a network, either as a subnet in CIDR notation or as a list of IP addresses. • PORT objects represent one or more protocol port numbers. Access to the Network Objects is through the context button associated with particular firewall fields. Clicking that button opens the Network Object window:

The Network Object window provides different methods for entering information in a firewall rule field: • Enter text allows you to edit the field directly. • Select Network Object allows you choose a network object you've already defined, such as when you create links and sites on the Networks tab. Double-click an entry in the list to edit it. You can also add new objects here or delete existing ones.

74

The XipOS Web Interface

When you select one of the items here, its name appears in the selected firewall rule's field. • Select Port Object allows you to choose a named protocol port number, such as http for port 80. Double-click an entry in the list to edit it. You can also add new port objects here or delete existing ones.

4.5.4.1. Firewall Rule Fields Many of a firewall rule's fields are used to match the rule against network traffic. When one of these fields is empty it means the rule matches against any value for that field.

^v:

Rule number and position bar. Drag-and-drop this green number to move the rule within the list.

Enbl: A checkbox indicating whether the rule is enabled or disabled. For testing or debugging, you can switch rules on or off without having to delete the them. Prot: Match the rule against a specific protocol. For more information on these protocols, refer to http:// www.protocols.com/. Source Addr: Match the rule against traffic arriving from a particular IP address or subnet. Click on the context button to specify a value via the Network Objects window. Src Port: Match the rule against traffic arriving from a particular protocol port number. (Note that some protocols don't use port numbers. Port number matching is typically useful with TCP or UDP.) Click on the context button to specify a value via the Network Objects window. Dest Addr: Match the rule against traffic going to a particular IP address or subnet. Click on the context button to specify a value via the Network Objects window. Dst Port: Match the rule against traffic going to a particular protocol port number. (Note that some protocols don't use port numbers. Port number matching is typically useful with TCP or UDP.) Click on the context button to specify a value via the Network Objects window. VLAN: (Only available in Bridge mode when VLAN Transparency is enabled.) Match the rule against traffic in a specific VLAN. Action: Allow or Deny traffic that matches the rule. Denied traffic is dropped. Rules that deny traffic are particularly useful when you want to prevent that traffic from passing through the device, or if you wish to reject connections to the device's web UI or SSH server2 from specific hosts or networks. Opt-TCP: (For TCP rules only.) Select this to apply TCP optimizations to the traffic that matches this rule. You may wish to disable TCP optimization for internal traffic that is not destined to go over the wireless link. QoS Queue: The fully-qualified name of the QoS queue associated with the rule. Traffic that matches the rule will be put into this QoS queue. This field can not be changed here; use the Service Assignment tab to associate rules with QoS queues. Note that this field is resizeable. DSCP In: value.

2

Match the rule against traffic marked with the specified Differentiated Services Code Point

Cryptographic security features are only available on "Crypto" product models.

For non-Crypto products you should instead restrict telnet access.

75

The XipOS Web Interface

DSCP out: This is not a traffic-matching field. Rather, this field allows you to specify that traffic matching the rule should be marked with the specified Differentiated Services Code Point value. This is useful if there are upstream devices that can prioritize traffic based on a DSCP value.

Fields for Lightweight Tunnelling Features The following firewall rule fields are only available when lightweight tunnelling is enabled. None of these are traffic-matching fields. XRT Action: Specifies the XipLink Real Time (XRT) optimization to apply to traffic in this QoS queue. The possible XRT optimizations are: • Tunnel: Pass the traffic through the lightweight tunnel, but do not apply any XRT optimizations. • Coalesce: Pass the traffic through the lightweight tunnel and coalesce the packets. • ROHC: Pass the traffic through the lightweight tunnel, coalesce the packets, and compress the IP and UDP packet headers. • RTP-ROHC: Pass the traffic through the lightweight tunnel, coalesce the packets, and compress the IP, UDP and RTP packet headers. See the section called “Header Compression” for details. • Do not Tunnel: Do not pass the traffic through the lightweight tunnel and do not apply any XRT optimizations. XRT Q: (Only available when XRT Action is Coalesce or higher.) Specifies the packet-coalescing queue to use for the traffic. The purpose of this field is to ensure that DSCP markings are preserved on coalesced packets. When packet coalescing combines several packets into one, only the first packet's DSCP field is preserved. If you're coalescing traffic with different DSCP classes, you need to associate each DSCP class with a different XRT Q so that the de-coalesced packets retain the correct DSCP markings. Opt-IP: Specifies whether or not to apply byte caching and packet compression to the traffic. Options are None to disable these features, and Max to enable both schemes. Packet compression includes Advanced Cellular Compression, if it is enabled.

4.5.5. Lightweight Tunnels Lightweight tunnelling allows optimizers to tunnel traffic between each other. Tunnelling is required for XipLink Real Time (XRT) optimizations, Advanced Cellular Compression (ACC), link balancing and is also necessary in certain deployments (see Section 3.4.6, “XipOS Tunnelling”). To use XRT and/or ACC features, you must enable lightweight tunnelling and then you must also specify which level of optimization to apply to different types of network traffic on the Traffic Assignment tab.

76

The XipOS Web Interface

An optimizer can be either a Tunnel Server or a Tunnel Client, but not both. The above screen shot depicts an optimizer with all lightweight tunnelling disabled (i.e. the optimizer is neither a Tunnel Server nor a Tunnel Client). Check Enable Tunnel Server to configure the optimizer as a Tunnel Server, or Enable Tunnel Client to configure the optimizer as a Tunnel Client. Enabling one form of tunnelling removes the controls for the other form from the UI. Simply uncheck the selected tunnelling form to once again see both sets of controls. A Tunnel Server can support many Clients, but a Client can only have one Server. All lightweight tunnels are protected by a Password. The Tunnel Server and all of its Clients must share the same tunnel password.

Packet Coalescing Tunnelling, whether as a Client or a Server, also allows for Packet Coalescing, a XipLink Real Time (XRT) optimization. Packets are coalesced as the optimizer sends them out via the tunnel. The coalescence settings on either end of the tunnel are independent: The Tunnel Server and its Clients can all have different packet coalescence settings. Global settings for packet coalescing are configured here in the Lightweight Tunnels tab. Furthermore, you can configure different levels of coalescing for different types of traffic in the Traffic Assignment tab. The Max capture delay is the maximum time the packet processing engine will spend accumulating UDP packets into a single coalesced packet before sending a coalesced packet through the tunnel. The higher the capture delay the higher the coalescence benefit, but delay also introduces jitter in the UDP streams. The default setting is 40ms. A smaller delay can be appropriate under light UDP load and/or with traffic that is especially sensitive to jitter. Larger values are better suited to heavy UDP loads, depending on the packet fill level setting. The Packet fill level specifies the maximum amount of bytes that can be coalesced into a single packet. Higher values reduce the packet-per-second rate of the UDP streams while maximizing throughput.

Advanced Cellular Compression To enable Advanced Cellular Compression, enter a valid Activation Code then tick the Enable ACC checkbox.

77

The XipOS Web Interface

After enabling Advanced Cellular Compression, you must also apply it to specific traffic on the Traffic Assignment tab. ACC is only applied to traffic that has its Opt-IP field set to Max.

Lightweight Tunnel Server

The only setting required for a Tunnel Server is the tunnel Password. The number of tunnels a Tunnel Server can support is limited by the resources available on the optimizer. For example, an XA-4000 can accommodate about 50 Tunnel Clients, but this depends on the current number of active TCP connections and also on the available bandwidth. If you enable both RIP and the Tunnel Server, do not advertise any routes from this optimizer. A Tunnel Server should only use RIP to receive routing updates.

Lightweight Tunnel Client Please ensure that your Tunnel Server is configured and operational before activating any Tunnel Clients.

78

The XipOS Web Interface

You must specify the Tunnel Server Address and also the Tunnel Server's tunnelling Password. The Tunnel Client tunnels all incoming traffic. However, in order for the tunnel traffic to reach its destination it is necessary to configure routes as if the traffic was not tunnelled. That is, the Tunnel Client must have the correct routes for the traffic that is being tunnelled. There are two ways to configure routing through the tunnel: explicitly by specifying tunnel subnets, or implicitly with network address translation (NAT). To use explicit tunnel routing, you must specify the subnets to route through the tunnel. Check Tunnel the Routed subnet (in Bridge or Single Interface mode, this option is called Tunnel the Wireless subnet) to automatically configure tunnel routing for whatever subnet is on the Routed (or Wireless) interface. You can also click the Add button to add a subnet to the tunnel routing table, and edit its IP address and netmask. Click the Del button to remove a selected subnet from the table. When using explicit tunnel routing you must also configure the correct routes on the hosts outside the tunnel at both ends. To use implicit tunnel routing, check Enable NAT in tunnel. This will make the optimizer translate source IP addresses into the Tunnel Client's tunnel IP address. You must also configure NAT on the Routed interface of the Tunnel Server. This method allows traffic to be tunnelled without the need to correctly configure routing throughout the network. Implicit tunnel routing with NAT will also let your Tunnel Server handle Clients with overlapping subnets. Otherwise, attempting to tunnel the same subnet through different Tunnel Clients will cause a routing conflict in the Tunnel Server. Although the Tunnel Client normally sends all the LAN-side traffic it receives through the tunnel, on the Traffic Assignment tab you can exclude traffic from the tunnel, based on the destination IP address and TCP or UDP port number. This can be useful, for example, when your subnets need to access a device that is on the wireless side of the optimizer.

4.5.6. Link Balancing Link balancing allows TCP sessions to share two physical links. See Link Balancing and Bonding for more information. Only traffic within a single QoS class may be balanced. The QoS class can be a leaf or an intermediate node in the QoS hierarchy. You must first enable lightweight tunnelling before you can enable link balancing.

79

The XipOS Web Interface

Select Enable Link Balancing to activate link balancing. Specify the balancing Algorithm and the algorithm's Config parameters. XipLink appliances ship with a single link balancing algorithm named default. The default balancing algorithm has several different configurations. Please contact XipLink Support for help configuring link balancing on your network. Specify the QoS Class for balancing to identify which traffic should be link-balanced. Link-balancing lightweight tunnel servers must specify the Number of tunnels to provision, which is the number of lightweight tunnel clients that will connect to the server. The Max TX specifies the aggregate bandwidth of a single tunnel over both links. Link-balancing tunnel clients must also specify the Gateway and bandwidth (TX B/W) of each physical link.

4.5.7. Web Cache This section is only applicable for particular web cache enabled products (those with a "C" in their model number). Please refer to the product matrix for a complete list of products and features. The web cache is typically deployed at a remote site to reduce the HTTP traffic on the wireless link. HTTP objects are cached locally on an internal hard drive so that subsequent requests may be satisfied directly. This improves web page response times and reduces traffic on the wireless link. The web cache also provides a simple web access control mechanism. This can be configured to either allow access only to specific sites, or to deny access to specific sites. Finally, the web cache can also display a specific page to welcome users when they first attempt to browse the web.

80

The XipOS Web Interface

The optimizer may take a few minutes to implement updates to these settings after you apply them. Use the Enable cache option to enable or disable the web cache. Once you apply your changes it may take a few minutes to initialize the cache store on the internal hard drive. This process must complete before the optimizer can begin to cache web objects. When disabling the cache, wait a few minutes before enabling it again to allow the cache to close its store properly. Use the Enable URL control option to allow access only to specific web sites, or to deny access to specific web sites. Enter the list of sites to control in the text box. Each line is a string that matches some or all of a URL you wish to control. For example, a line with example.com will control any URL that contains "example.com" anywhere inside it, including: • http://www.example.com/ • http://places.example.com/ • http://this-example.com/ • http://company.com/example.com.html This option only controls access to HTTP (port 80) web sites. Access to secure web sites (HTTPS) or sites that use other ports cannot be controlled with this option. To control access to such sites, you can block their DNS names or IP addresses directly on the firewall tab. Refer to the firewall section for further details. The Access denied URL is the web page which is displayed to the end user should a site be blocked. You can specify any web page here. Typically this page is hosted on one of your own web servers.

81

The XipOS Web Interface

Make sure that the Access denied URL is accessible to your users. In particular, when allowing access only to specific sites, make sure the Access denied URL matches an entry on the list on allowed sites. Use the Show a welcome page option to present the Welcome Page URL to a user the first time she accesses the web. As with the Access denied URL, the Welcome page can be any web page and is usually hosted on one of your own web servers. Make sure that the Welcome page URL is accessible to your users. In particular, if you are also configuring the web cache to allow access only to specific sites, make sure the Welcome page URL matches an entry on the list of allowed sites. The welcome page is redisplayed to users regularly. Use the Welcome timeout setting to control how many hours should elapse before a user sees the page again. Use a decimal value to enter fractions of an hour, down to a minimum of 0.02 hours. You can also specify exceptions to the welcome page mechanism. A user whose browsing session matches one of these exceptions will not see the welcome page, even if this is the first time the user is browsing the web. Use the Destination URL Exceptions text box to enter a list of sites (one per line). Users accessing one of these sites will not be shown the welcome page (but they will still be shown the welcome page the first time they access any site that is not on the list). Sites are matched to URLs in the same way as the URL control sites. For example, the screenshot above shows a destination URL exception for xiplink.com, meaning that there is a welcome page exception for any users accessing any URL containing "xiplink.com". Use the Source IP Exceptions text box to enter the IP addresses (one per line) of users who should never see the welcome page. You can use the * character as a wildcard for any of the octets in the IP address. For example: • 10.11.12.13 matches the user(s) with IP address 10.11.12.13. • 10.11.12.* matches any user(s) on the 10.11.12.0/24 subnet. • 10.11.*.* matches any user(s) on the 10.11.0.0/16 subnet. • 10.*.12.13 matches any users on the 10.0.0.0/8 subnet whose IP address also ends with 12.13. Only use the * wildcard character to represent an entire octet of an IP address. Using the wildcard to match part of an octet (for example, 10.2*3.4.5) is not supported and will have unpredictable results.

82

The XipOS Web Interface

4.6. System This section describes device settings unrelated to networking or optimization.

4.6.1. Support & Docs This tab displays contact information for XipLink's support department, and the device's XipOS version.

You can click on the Open User Guide button to download a copy of the XipOS User Manual. The Display Support Report button reveals a large amount of diagnostic information that XipLink can use to assist you. The Download Support Package will generate a compressed support file that can be analysed by support personnel. The Support package will contain all current configurations of the unit, including all IP addresses and any tunnel passwords. Care should be taken as to who has access to these files

4.6.2. Logs The Logs tab allows you to configure the device to act as a syslog server or client (or both). It also displays the last 10 lines of the device's system log (including log messages received from syslog clients). This is a prime resource for diagnosing problems. Use the troubleshooting guide to address any errors you see here. If errors persist, please provide the error information to XipLink's support department.

83

The XipOS Web Interface

To Send logs to a remote syslog server, specify the server's IP address. To Accept remote logs from one or more syslog clients, specify the client IP address(es) as a commaseparated list. You can specify individual IP addresses, or subnets using IP/bits notation. Specify "0.0.0.0/0" to accept logs from any client.

4.6.3. Stats The Stats tab configures the data monitoring service on the optimizer.

Select Collect additional statistics for QoS queues to record statistics for all the individual QoS classes. Enabling this option adds a "QoS queues" category to the main menu of the Optimizer Montoring Tool. Collecting QoS statistics can require a significant amount of disk space. XipLink recommends only enabling this option if your device has a small number of QoS classes, or if your device is equipped with a hard drive (such as a web cache enabled device). If collecting additional statistics for QoS queues is enabled, you can also select Collect additional DSB statistics for QoS queues to include Dynamic Socket Buffer statistics for each QoS queue.

84

The XipOS Web Interface

QoS statistics are only gathered for the bottom-most (leaf) queues.

Select Act as a server to collect statistics from other devices to allow this device to receive statistic data from other XipLink optimizers. Enabling this option affects the main menu of the Optimizer Montoring Tool. Collecting statistics from other devices can require a significant amount of disk space. XipLink recommends only enabling this option if your device will receive data from a small number of other optimizers, or if your device is equipped with a hard drive (such as a web cache enabled device). Select Save stats to this device to have this device record its own statistics. Automatically delete statistics after a specified amount of days in order to automatically remove statistics files that have become inactive. This is useful when collecting statistics from other devices, and some those devices have come and gone over time (perhaps as your network topology has changed). Select Send stats to to have this device send its statistics to another XipLink optimizer at the specified IP address. You can configure a device to not save its own statistics locally but still send them to another optimizer. Make sure the optimizer receiving the statistics is configured to act as a server to collect statistics, as described above. When gathering statistics in a central optimizer, please ensure that each device sending statistics has a unique name. If two or more devices share the same name, the statistics gathered in the central optimizer for those devices will be invalid.

4.6.4. Users The Users tab allows you to change the system administration password.

If this device is accessible from a public network, please ensure that you supply a secure password. The factory default password is insecure.

85

The XipOS Web Interface

To change the system password, supply the current password and the new password. The new password must be entered twice to confirm that it is correct. The password can contain any combination of uppercase and lowercase characters, numbers, and special characters. The new password's score reflects the password's complexity and is a rough guide to the password's level of security. A score of at least 50 is recommended for safe password practices. A password's score increases when it uses a mix of numbers, uppercase and lowercase letters, and punctuation. With the current and new passwords entered, click the Update Password button to change the system administration password. Should you forget the device's password, you must perform a factory reset via the serial port to restore the default password.

4.6.5. Time The Time tab allows you to configure the device's system clock. Changing the device's time can sometimes close active connections passing through the device. It can also cause your browser's session with the web UI to time out. You may need to reload the web UI after changing the time.

The device's current date, time and time zone are displayed in the blue section at the top of the tab. The time displayed updates according to the sampling rate setting in the dashboard.

Select Synchronize time using NTP to configure the device to set its time using the Network Time Protocol. Specify the NTP Server(s) as a comma-separated list of IP addresses and/or DNS names. When the device is not using NTP, you can set the date and time manually by entering the desired values and clicking the Set Date and Time button.

86

The XipOS Web Interface

Manual time configuration is performed instantaneously when you click the Set Date and Time button. There is no need to "Apply Changes" to set the time manually. You can change the device's time zone by selecting the desired zone in the dropdown and clicking the Change Time Zone button. The time zone is set instantaneously when you click the Change Time Zone button. There is no need to "Apply Changes" to set the time zone.

4.6.6. Backup The Backup tab allows you to collectively manage the device's configuration settings. Here you can save the device's current settings as a named configuration profile. Profiles can be downloaded for backup, uploaded, and restored (made active). Always backup and download the device's latest configuration profile to ensure minimum downtime in case of device failure or misconfiguration.

Every XipLink device comes with a pre-installed FactoryDefault profile, which is a copy of the device's initial configuration. You may install this profile to reset the device's configuration to its factory-default settings. To create a new configuration profile from the device's current configuration settings, enter a Title and Description for the profile and click on the Create a new Profile button. The new configuration profile is stored on the device. To backup a profile, select it and click Download selected profile. Your browser will prompt you to save the profile's file. The device can store several configuration profiles. Click the Refresh list button to view the device's current collection of profiles. Click on Upload a profile to upload a previously-downloaded profile. This opens a window for you to specify the profile's file and upload it. Once uploaded, the profile appears in the list where you can install it onto the device.

87

The XipOS Web Interface

To apply a configuration profile, select it and click Install selected profile. This replaces the device's current and permanent configuration with the profile's settings. Once the profile is installed, the device is rebooted for the new profile to take effect.

Installing a profile replaces the device's current configuration. To easily recover the current configuration, save it as a new profile before installing a different profile.

4.6.7. Upgrade The Upgrade tab allows you to update the device's XipOS version, undo an upgrade by reverting to the previous XipOS image, or reset the device to its factory defaults.

XipLink is continuously improving its products, and regularly releases XipOS updates. You can obtain XipOS updates from your XipLink distributor or from the XipLink customer support portal on our web site at http://www.xiplink.com/. Upgrading the device requires a significant amount of memory. If your device is particularly busy, you may not be able to upload the upgrade package to the device. To reduce the device's RAM usage, go to the Optimization tab in the Optimization settings and turn off compression. Allow a few minutes after applying this change for active connections to terminate, and the device's RAM usage should decrease. Once the upgrade is complete, you can turn compression back on.

4.6.7.1. Upgrading XipOS Click on the Upload upgrade image button to begin the upgrade. A new browser window appears to guide you through the upgrade process. You must first upload a XipOS upgrade package (.pkg) file.

88

The XipOS Web Interface

Click on Browse... to specify a XipOS upgrade package file on your browser's PC. Then click on Upload to upload the package. On slow links it may take a few minutes to upload the upgrade package. Please do not close the upgrade window until you see the following window, confirming that the upload succeeded.

Here you can choose to use the new XipOS version's factory default configuration instead of carrying over the device's current configuration. Using the new XipOS version's factory defaults will overwrite all of the device's settings, including IP addresses. Click on the Upgrade now button to begin the upgrade. The upgrades progress is displayed as the process proceeds. The device will automatically reboot when the upgrade is complete.

Do not shut off the device while the upgrade is in progress.

When the device reboots, you may receive a timeout error from the web UI. Simply reload the web page to reconnect the UI.

Upgrade Troubleshooting In rare cases an upgrade may fail. When this happens, the device will reboot itself to revert back to its preupgrade configuration. After a failed upgrade, a red "UPGRADE FAILED" message appears in dashboard:

89

The XipOS Web Interface

Click the "UPGRADE FAILED" message in the dashboard to open the Upgrade Failure window.

This window displays the Upgrade Failure Log, which records any problems that may have occurred while migrating your device's configuration during the upgrade. You can also click Download All Logs to download an archive of all the system logs taken during the upgrade. Please report any upgrade failures to XipLink Support, and include the log archive so that we may assist you as quickly as possible. Click Clear Upgrade Failure to remove the "UPGRADE FAILED" message from the dashboard.

4.6.7.2. Change Boot Partition The XipOS contains 3 separate boot partitions. The first two partitions are used for the running systems. The third partition contains the factory reset partition. Each time an upgrade is performed, the alternate of the first two partitions is upgraded, leaving the original (pre-upgrade) partition intact. This provides a failsafe should the upgrade not complete successfully or should a system corruption occur. To boot from the alternate partition, select the Change Boot Partition button and confirm the request. The device reboots immediately.

Please note that alternate boot partition may not contain the same system settings as currently set due to changes being applied to the current partition It is recommended that you do a system backup prior to proceeding so that these setting may be restored again once the alternate partition has booted.

90

The XipOS Web Interface

4.6.7.3. Perform Factory reset This option will put the unit in a factory reset state once the unit has rebooted, Please refer to the CLI factory reset section as a Console connection is still required to complete the factory reset. You will be presented with the following dialog advising you of the procedure.

4.6.8. Reboot The Reboot tab allows you to reboot or halt the device. You should halt the device before shutting off its power, to ensure that the system is shut down in a clean state.

You can reboot (or halt) the device immediately, or specify a number of minutes to wait before rebooting (or halting). This is useful if you wish to schedule the reboot (or shutdown) for a particular time. Rebooting the device reloads its last saved permanent configuration. Any settings that were only saved to the running configuration will be lost.

91

The XipOS Web Interface

It is not necessary to reboot the device to activate configuration changes.

4.6.9. Files The Files tab allows you to transfer files to and from the appliance. This provides an alternative to using the command-line interface's scp utility (which is only available on "Crypto" product models). XipLink appliances also provide an FTP client in the command-line interface, but you may find the facilities in the Files tab more convenient to use.

To upload a file, click Upload file. This opens the Upload File window.

92

The XipOS Web Interface

Use your web browser to Specify a file to upload, then Specify a directory to upload the file into. To download a file, click Download file. This opens the Download File window.

93

The XipOS Web Interface

Browser the directories to find the file you wish to download. If you browser knows how to display a file's Type, when you click on the file's link it will show the contents of the file to you. To download the file instead, right-click it and select "Save As..." (the exact phrasing of the menu option varies by browser).

4.6.10. Diagnostics The Diagnostics tab provides valuable information on the current state of the device. Click the Update Diagnostics Info button to view the current diagnostics.

94

The XipOS Web Interface

Refer to the diagnostics tools section of the manual for further explanation.

4.6.11. Debugging The Debugging tab is an aid for verifying communication between the browser and the device. It displays the messages the UI receives from the device.

95

Chapter 5. Redundancy Deployment Options This chapter focuses on the current options that can be used for redundancy deployments Three methods are available namely: • Router mode Redundancy using CARP • Bridge mode with STP failover • Bridge mode with fail to Wire

5.1. Router mode Redundancy using CARP The XipOS uses CARP (Common Address Redundancy Protocol) for Router mode redundancy. This is achieved much in a similar method than the Cisco VRRP protocol and operates on the same IP protocol level CARP though is not interoperable with VRRP when clustering with other Cisco Devices

Figure 5.1. Router Mode Redundancy Setup

Redundancy requires a second XipOS device to be on hot standby (referred too in above diagram as 'Cluster ID B'), ready to take over should the primary device fail. Each device then shares the same Virtual IP addresses on each side of the unit. The Virtual IP addresses are then to be used as the Gateway addresses for the adjacent equipment for proper routing to be take place. The Preferred master will continue doing a CARP broadcast for as long as it is available. The standby device will take over if the primary device stops broadcasting that is still available. CARP operates in preemptive mode whereby both sides interfaces will be promoted to Master or demoted as any status change is detected, thereby ensuring that traffic will flow bi-directionally through a particular unit. Failover normally happens in a fraction of a second, with little to no packets being dropped while the standby device becomes available. The redundancy current state of each devices is shown in the Dashboard section of the UI for quick reference It is important that a multicast capable switch is deployed on either side of the XipOS based devices.

5.2. Bridge mode with STP failover Spanning Tree Protocol (STP) is a network protocol that ensures a loop-free topology for any bridged network. Spanning tree protocol allows a bridged network design to include spare (redundant) links to

96

Redundancy Deployment Options

provide automatic backup paths if an active link fails, without the danger of bridge loops, or the need for manual enabling/disabling of these backup links.

Figure 5.2. Bridge Mode Redundancy Setup

The key in this topology are the STP capable switches. The backup route will have the switch port shutdown in order to prevent a bridging loop. Once the Primary route fails, A STP election takes place whereby the backup route will be activated. As the primary switch port will be shutdown, the only way to manage the device is through the management LAN port There is no UI configuration currently required for STP mode as this is enabled by default.

5.3. Bridge mode with fail-to-wire Fail-to-wire is not available on all models, please refer through to the product matrix for further information. Fail-to-wire is not strictly a redundancy option, but rather a failsafe method to ensure that traffic can still pass should there be any specific hardware or software related issues such as a kernel panic.

Figure 5.3. Fail-to-wire Diagram

Fail-to-wire is achieved through a hardware relay between the physical Bridge and wireless ethernet ports. The default state when the unit is powered off is to allow traffic to pass directly between the Bridge and Wireless interfaces.

97

Chapter 6. Monitoring and Statistics 6.1. Optimizer Montoring Tool The Optimizer Montoring Tool allows you to view graphs of real-time and historical statistics on your XipOS device. For ease of use, the tool can be opened either from the web management UI by selecting the Statistics option, or by directly accessing the tool's URL: http://[device-IP-address]/monitor.html

The statistics tool renders graphics as SVG files. Modern browsers such as Firefox and Opera can display SVG files natively. Should you wish to view the statistical graphs in Internet Explorer, you will need to install an SVG viewer plug-in such as Adobe's SVG Viewer.

The Optimizer Monitoring Tool contains a menu on the left for selecting graphs to view. The menu is divided into different categories. Clicking on a category's heading reveals the names of the graphs available within that category. Clicking on a graph's name in the menu displays the graph at the top of the page. Any other graphs that were already on the page are shifted down. The tool will only display as many graphs at one time as will fit in the browser window. If the browser window is full, adding a new graph will remove the oldest one (at the bottom) from the display.

98

Monitoring and Statistics

If you resize your browser's window, you must reload the page to have the tool recalculate the new display area. If your optimizer is configured to collect statistics from other devices, then the menu's top level lets you select which device's statistics you wish to view, with the available categories and graphs for that device below the device's menu entry.

6.1.1. Graph Controls Each graph has its own control menu to the left of the graph itself. Passing the mouse cursor over an option whose name ends with an ellipsis ("...") reveals a control panel for that option.

Each graph control menu contains the following options: • Info... Display detailed information about the data in the graph. • Show... Adjust the period of time covered by the graph. Note that the minimum and maximum values are not plotted in the 20-minute "realtime" graph. • Scale... Adjust the vertical scale of the graph. • Refresh... Adjust the graph's refresh rate. • Remove: Click this option to remove the graph from the display area. • Get as CSV: Click this option to download a comma-separated-value (CSV) file of the data underlying the graph.

6.2. Monitored Data Sets This section outlines the statistics a device can monitor. For details on a particular data set, refer to its corresponding graph's Info panel in the Optimizer Monitoring Tool. Many statistics come in uplink and downlink varieties. Uplink statistics measure traffic coming in from the LAN side (via the Routed or Bridged interface) and going out on the Wireless interface. Downlink statistics measure the opposite: traffic coming in on the Wireless interface and leaving on the LAN side. Overview statistics: Statistics in the Overview category cover aggregate traffic traversing the device. Graphs here display how much data is being saved in each direction, and also how many TCP connections the device is optimizing at a given time. TCP/HTTP compression statistics: XRT statistics: compression.

This category covers all TCP traffic, including HTTP traffic.

These statistics show the benefits derived from packet coalescing and header

IP-Optimization statistics:

These statistics show the benefits of packet compression and byte caching.

99

Monitoring and Statistics

Cache statistics:

(Cache enabled products only) These statistics cover HTTP traffic and the web cache.

LAN network statistics: These statistics show network traffic coming and going on the LAN side of the device (i.e. through the Routed or Bridged interface). Wireless network statistics: device's Wireless interface.

These statistics show network traffic coming and going through the

QoS queue statistics: (Only available if the device is configured to collect QoS statistics) This category contains a sub-category for each QoS queue configured on the device. Each queue's statistics show how much traffic is passing through the queue. QoS statistics are only gathered directly for the bottom-most (leaf) queues. These data are aggregated into statistics for parent queues. System statistics:

These statistics show system CPU load and memory usage.

Advanced statistics: This category contains statistics for low-level internal subsystems. This data is mainly used by XipLink support staff to help analyze problems. LWT statistics:

These statistics show lightweight tunnelling traffic, including link-balancing statistics.

100

Chapter 7. XipOS Command Line Interface 7.1. Introduction The preferred method of configuring your XipOS device is via the web interface. The web UI ensures that settings have valid values, and prevents invalid combinations of settings. However, the device also provides a command line interface (CLI) for use when the web interface is inaccessible, or to configure advanced settings not available in the web UI. The XipOS command line interface is for advanced users and should only be used under the guidance of XipLink support personnel. The XipOS CLI is based on a stripped-down and fine-tuned version of FreeBSD. Most standard FreeBSD commands are available, such as ls, less, grep, vi, etc.

CLI Login Credentials The factory-default login credentials are: Username: root Password: xiplink The CLI password is the same as the web UI's administration password. Changing the web administration password (see the System -> Users tab) also changes the CLI password.

Connecting via SSH Any standard SSH client can connect to the XipOS device on TCP port 22. Windows-based users can use clients such as PuTTY or Cygwin. Most *nix systems generally include an ssh command. SSH is not available on "NC" product models. To access the command line on "NC" products, use telnet instead.

Connecting via Serial Port The device's serial port allows you direct access to the CLI without having to connect through the network. This is the only way to connect to the CLI if the network interfaces become inaccessible. A DB9 serial cable was included with your optimizer for connecting a PC to the serial port. Please use the following communication settings: • Bits per second: 19200 • Data bits: 8 • Parity: None • Stop bits: 1

101

XipOS Command Line Interface

• Flow control: None Remote access via the serial port can be obtained by connecting the serial cable to another networked device that can be accessed remotely. An example of this is connecting the serial cable to a Windows PC and accessing the Hyperterminal program through an application such as VNC or Remote Desktop. The XA-10K and XA-30K devices come in redundant pairs, and the serial cable can be connected between the two. This allows either device to access the other's CLI, using the FreeBSD cu utility.

7.2. Factory Reset This section explains how to perform a factory reset of your XipOS device, returning the device to its initial, default settings. A factory reset requires you to interact with the device's bootup process and can only be done through the serial port.

7.2.1. Accessing the Factory Reset Menu To access the factory reset menu, you must change the device's boot partition. There are three ways to do this: • Firstly, to initiate the factory reset from the System->Upgrade Management->Factory Reset option in the Web UI • Secondly run /usr/local/bin/factoryReset.sh in the CLI, then reboot the device. • Or, reboot the device and use the serial port CLI to specify the partition during the bootup process: 1. During bootup, when you see the XipLink logo press 6 to interrupt the boot countdown. 2. At the OK prompt, use the set command to change the currdev parameter to disk0s3a OK set currdev=disk0s3a

3. Enter the boot command to continue the bootup process.

7.2.2. Factory Reset Menu The factory reset menu allows you to perform a factory reset, or change the default boot partition. Please enter one of the following options yes no 1 2

-----

run factory reset exit to command shell for manual reset set partition 1 as default boot set partition 2 as default boot

Run automatic system recovery [yes/no/1/2]:

Enter yes to reset the device to its factory defaults. If you enter no the device will boot into a read-only file system with minimal functionality.

102

Chapter 8. Advanced Upgrade Procedures This section describes some advanced upgrade procedures. The preferred upgrading method is through the web UI. The procedures described in this section should only be undertaken with the advice of a XipLink support representative. For XipOS versions prior to version 3.0.0 you will need to upgrade by replacing the Compact Flash card in the device, as the CF cards used in version 2.x products are not compatible with the newer versions of the XipOS.

8.1. Manual Upgrade via CLI This procedure only applies to XipOS versions 3.x and later, and should only be used if you are not be able to access the web UI on the device. 1.

Obtain the latest version of the XipOS via the downloads section of the XipLink customer portal.

2.

Copy the new image to the device. From a *nix host you can use the scp command: scp upgrade.image.pkg root@{device_ip}:/upgrade.image.pkg

3.

Connect to the device using ssh: ssh root@{device_ip}

4.

Issue the following command on the device: /usr/local/bin/upgrade.sh /upgrade.image.pkg yes The last parameter indicates whether the device's existing configuration should to be copied once the upgrade is complete or whether the new XipOS's factory default settings should remain: • yes - keep the device's existing configuration. • no - discard the device's existing configuration.

The device will automatically reboot once the upgrade completes. After the upgrade, please ensure that you can still connect via SSH to the device's IP address. If you specified no in the upgrade command to discard the device's settings, after upgrading the device will use the factory default IP addresses.

8.2. Replacing the Compact Flash Card This section describes how to replace the device's Compact Flash (CF) card. The procedure shown illustrates replacing the CF card on an XA-4000 or XA-10000 unit, but you can follow a similar procedure for other units.

103

Advanced Upgrade Procedures

If you are still within your maintenance period or have extended your maintenance contract, you are entitled to a free upgrade to the latest XipOS release. Please contact XipLink with your details and the serial number of your unit, and we will ship you the latest version of XipOS on a CF card.

8.2.1. Equipment Required The following equipment is required to perform this procedure: • The XipLink device • A Phillips or "star point" screwdriver • The replacement CF card, as shown here.

The manufacturer or model number on your CF card may differ from the one in the picture.

8.2.2. Procedure Before replacing the CF card, make sure that the device is switched off and that the power and network cables are disconnected (unplugged). 1.

Switch off and unplug the device.

2.

Open the device. • Use the phillips screwdriver to remove the 2 screws at the back of the unit, as indicated here:

• Remove the cover from the device by sliding it backwards. 3.

Remove the old CF card. • Locate the CF card on the motherboard, as shown in the following picture:

104

Advanced Upgrade Procedures

• Remove the CF card from the CF card slot on the motherboard by sliding it out.

4.

Install the new CF card. • Insert the new CF card in the CF card slot by sliding it in.

5.

Close the device.

105

Advanced Upgrade Procedures

• Slide the lid back onto the device. • Fasten the 2 screws. 6.

Reconnect the power and network cables.

The upgrade is now complete. Switch on the device and verify that it is working correctly.

106

Chapter 9. Troubleshooting and Diagnostic Tools This chapter contains information to assist in troubleshooting the XipLink optimizer.

9.1. Netconf Errors Netconf is the network configuration system that runs on XipOS devices. The web interface in your browser communicates with the netconf service through remote-procedure calls. When an error occurs, the netconf service returns an error detailing the reasons for for failure. The web UI displays the error message in a dialog box, for example:

This example shows an error that occurred while applying changes to the device. One of the settings contained an invalid IP address. The error messages show the invalid value, that the netconf Interface module failed to apply the bad value, and that the reconfiguration operation was aborted and successfully rolled back. Click on the Show detail button to see internal details of the error:

107

Troubleshooting and Diagnostic Tools

The following example shows an error that occurred when trying to apply a configuration with an invalid gateway address. The address is not reachable via the currently configured subnets.

Netconf error messages are designed to provide you the information you need to resolve misconfiguration issues. However, netconf will return a "Null" error message when it encounters an error condition it does not know how to describe. Should you receive such an error, we kindly request that you forward to XipLink the details and steps you took to produce the error. Please refer to the Support section of the manual for XipLink contact information.

9.2. System Logs In the web UI, you can use the System->Logs tab to view the last to messages in the device's system log. To view additional log messages, you must log into the device via the command line interface. Refer to the chapter on the XipOS Command Line Interface for detailed instructions.

9.2.1. The System Log File Any errors that occur are logged in the system's /var/log/messages log file. (This is the file that is displayed in the web UI.) You can also access this file via the CLI. To view the last 50 lines of the file, use the following command after logging into the device: tail -n 50 /var/log/messages The -n 50 parameter specifies the number of lines to display.

9.2.2. The Netconf Log File The netconf system logs its messages to the /var/log/netconf.log file.

108

Troubleshooting and Diagnostic Tools

Each netconf request is clearly identified by a log entry. All netconf log entries show: • A log level (DEBUG, ERROR, etc.) for the entry. • A source code file name and line number indicating where the entry was generated. • Particulars relating to the specific netconf session. By default netconf only logs messages with an ERROR level. If you wish netconf to record log entries for other levels, log into the device and create a file named /management/cgi-bin/netconf.dbg. The file should contain a single line with the desired logging level: error, warn, info, or debug. Here's a quick command that create the file with the debug logging level: echo debug > /management/cgi-bin/netconf.dbg The debug logging level records a lot of information. Be sure to restore regular logging (by deleting the /management/cgi-bin/netconf.dbg file) once you have finished working with the netconf logs. At the default (error) logging level, aside from error messages netconf also logs some bookkeeping information about the requests it receives, which modules it invokes and skips while processing the request, the result of each module's invocation, and whether netconf successfully created a reply. Some parts of the UI (the dashboard, the statistics tool) regularly poll the netconf system for their data. These requests can quickly create several irrelevant netconf log entries. While troubleshooting we recommend closing any statistics windows and turning off sampling in the web UI's dashboard.

9.3. Diagnostic Tools This section describes some of the command-line tools you can use to troubleshoot particular issues. Please refer to the XipOS CLI interface section for details on connecting to the command line interface. These tools are intended for advanced users or for use under the instructions of XipLink support personnel.

9.3.1. netstat The netstat tool displays network connections (both incoming and outgoing), routing tables and network interface statistics. The XipOS version understands the SCPS protocol and can display SCPS statistics. The standard netstat options are documented in the FreeBSD netstat(1) manual page [http://www.freebsd.org/cgi/man.cgi?query=netstat&manpath=FreeBSD+7.1-RELEASE]. The XipOS netstat has been extended in several ways.

Active Connections When displaying active connections, the XipOS netstat shows two sockets per connection: one representing the TCP side on the Routed (or Bridged) interface, and the other representing the SCPS side on the Wireless interface. The two sockets are used to proxy each connection through the device.

109

Troubleshooting and Diagnostic Tools

Example 9.1. netstat Active Connections Active Internet connections (including Proto Recv-Q Send-Q Local Address tcp4 0 0 10.246.76.73.64436 scps4 0 0 10.244.128.11.135 tcp4 0 0 10.246.76.73.63058 scps4 0 0 10.244.128.11.135 tcp4 0 0 10.246.76.77.53070 scps4 0 0 10.244.0.62.1149 tcp4 0 0 10.246.76.73.65050 scps4 0 0 10.244.128.11.135

servers) Foreign Address 10.244.128.11.135 10.246.76.73.64496 10.244.128.11.135 10.246.76.73.59796 10.244.0.62.1149 10.246.76.77.56199 10.244.128.11.135 10.246.76.73.60730

(state) ESTABLISHED ESTABLISHED ESTABLISHED ESTABLISHED ESTABLISHED ESTABLISHED ESTABLISHED ESTABLISHED

Note the full port spoofing: The Local and Foreign addresses and ports are the same for both TCP and SCPS, but tuples are reversed.

Dynamic Socket Buffer Data: -e The XipOS netstat also accepts a -e parameter, which adds information about each socket's dynamic socket buffer (DSB) to the display.

Example 9.2. netstat -e DSB Output Active Internet connections (including servers) Proto Local Address Foreign Address dsb rcv tcp4 10.246.76.73.64436 10.244.128.11.135 ENABLED--scps4 10.244.128.11.135 10.246.76.73.64496 DISABLED+tcp4 10.246.76.73.63058 10.244.128.11.135 ENABLED--scps4 10.244.128.11.135 10.246.76.73.59796 DISABLED+tcp4 10.246.76.77.53070 10.244.0.62.1149 ENABLED--scps4 10.244.0.62.1149 10.246.76.77.56199 DISABLED+tcp4 10.246.76.73.65050 10.244.128.11.135 ENABLED--scps4 10.244.128.11.135 10.246.76.73.60730 DISABLED+-

dsb snd DISABLED+ENABLED--DISABLED+ENABLED--DISABLED+ENABLED--DISABLED+ENABLED---

session eff cwnd c21f812c 2920 c21f812c 5580 c262b9c4 2920 c262b9c4 5580 c21f8ce4 5840 c21f8ce4 27900 c247b76c 2920 c247b76c 6975

The Recv-Q, Send-Q and (state) columns were removed in this example to improve legibility. The -e parameter adds the dsb rcv, dsb snd, session and eff cwnd columns. Each socket either has DSB ENABLED or DISABLED. Sockets with DSB disabled have two flags that explain why: • DISABLED+- The first + means DSB is disabled because the session is suspended. • DISABLED-+ The second + means DSB is disabled as part of the XipOS kernel's event suppression mechanism. Note how linked TCP and SCPS sockets are linked by a common session number. The eff cwnd column shows the size of each socket's current effective congestion window.

SCPS Statistics: -p scps In addition to keywords for the standard IP-based protocols, XipOS's netstat command also accepts the keyword scps for its -p option. Invoking netstat with netstat -s -p scps

displays statistics for all SCPS connections and packets on the Wireless interface alongside TCP statistics for the Routed (or Bridged) interface.

110

Troubleshooting and Diagnostic Tools

This can highlight discrepancies between the TCP and SCPS traffic. This example shows only the additional SCPS-related statistics that netstat displays.

Example 9.3. Sample netstat -s -p scps Output scps: 15462 packets sent 4297 data packets (163863 bytes) 32 data packets (33365 bytes) retransmitted 4 data packets unnecessarily retransmitted 1 resend initiated by MTU discovery 10937 ack-only packets (96 delayed) .... 3738 acks (for 162345 bytes) 11016 duplicate acks .... 87 connection requests 15 connection accepts (0 fast accepts) .... 2 short SNACKs received 6 SNACKs-caused retransmissions 4 segments is the largest hole received

Here we can see an unusually high number of duplicate ACKs. Further investigation is required into the routing configuration and the wireless link's latency.

9.3.2. Quality of Service Queue Control The pfctl utility lets you have fine control over the quality of service (QoS) packet queues. pfctl's options are documented in the FreeBSD pfctl(8) manual page [http://www.freebsd.org/cgi/man.cgi? query=pfctl&manpath=FreeBSD+7.1-RELEASE]. Use this command to view the current status of the QoS queues: pfctl -vs queue

Example 9.4. Using pfctl to View QoS Queue Status

queue root.BasicOpt on rl0 bandwidth 100 b qlimit 208 qdlimit 42 rtt 1000ms hfsc( upperlimit 2.50Mb ) [ pkts: 2847961 bytes: 1028853040 dropped pkts: 0 bytes: 0 ] [ qstate: PUSH tokens: 208 qlimit: 208 qdlimit 42 ] [ sessions: 1 active (scps: 0 tcp: 0) queued (scps: 0 tcp: 0 ] [ css: 0 tss: 312440 rss: 0 ctr: 0 ttr: 624880 ] [ cts: 0 tts: 64240 rts: 0 csr: 42 tsr: 128480 ] [ pigs: 87 cpm: 0 tpm: 624880 ] [ qlength: 0/209 ] [ measured: 2.9 packets/s, 3.47Kb/s ] queue root.Default on rl0 bandwidth 100 b priority 7 qdlimit 34 rtt 800ms hfsc( default upperlimit 2.5 [ pkts: 1075488 bytes: 434356797 dropped pkts: 0 bytes: 0 ] [ qstate: PUSH tokens: 50 qlimit: 50 qdlimit 34 ] [ sessions: 0 active (scps: 0 tcp: 0) queued (scps: 0 tcp: 0 ] [ css: 0 tss: 75920 rss: 0 ctr: 0 ttr: 151840 ] [ cts: 0 tts: 51100 rts: 0 csr: 0 tsr: 102200 ] [ pigs: 0 cpm: 0 tpm: 151840 ] [ qlength: 0/ 50 ] [ measured: 1.5 packets/s, 5.37Kb/s ]

111

Troubleshooting and Diagnostic Tools

The important parameters for each queue are its qstate, the number of sessions and, if acceleration is enabled, the number of SCPS connections in the queue. Each queue's buffer status is indicated by the css, tss, ctr and ttr flags. Any sessions that are inactive and suspended for a long period of time are moved to the pigs buffer to make more memory available to the current active sessions. An excess number of pig sessions could indicate that a denial of service attack is underway.

112

Chapter 10. Support This chapter details XipLink's support options and processes. To ensure premium customer service, all support cases are logged and tracked until resolved. Escalation procedures are in place to ensure that your support issues are resolved as quickly as possible.

10.1. Support Resources Email Support Please direct any support inquiries via email to the following address. Support email address: Please include in the email as much detailed information as possible pertaining to your support issue, including screenshots or log files. This will assist our support engineers in quickly identifying the source of the problem. For the subject line, please write a brief description of the problem you are experiencing. Please also include the following information: • Device model • Device serial number • XipOS version • Licensee company name • Primary technical contact • If you purchased your device via a XipLink reseller or partner, please also indicate from whom the equipment was purchased. Once we receive your email, you will automatically receive a reply with a support case reference number. You can track your support case online by clicking on the link included in the email. One of our support engineers will contact you soon with a response to your issue.

Online Customer Portal Our online customer portal is available to all customers whom have purchased any XipLink product(s). Many of our products include a 1-year Maintenance Pack which entitles you to download upgrades to your device firmware as soon as these become available. If you have not yet received your customer portal account details, please contact your XipLink representative who will be able to supply this information. Alternatively, kindly forward us your details via email and we will activate your Client Portal account. When sending us an email please include the details requested above.

113

Support

The Customer Portal login link is available on our website at www.xiplink.com [http://www.xiplink.com/]. The Client Login link is at the top of the page.

Telephone Contact Information You can reach our support department via telephone at: Toll Free: +1 855 408-2483 Direct :+1 514-848-9640 Please ensure you have the above information at hand when phoning XipLink support.

10.2. Return Procedures If you need to return a defective device to XipLink, please follow these Return Merchandise Authorization (RMA) steps. To ensure speedy repair of faulty equipment, XipLink requires that an RMA repair number be issued prior to accepting the defective unit for repair. You can track the progress of your equipment's repairs via the Customer Portal. You will receive an email as your unit passes through each stage of the RMA process.

Procedure 10.1. Steps Required for Successful RMA 1.

Send an email to with the following: • Make and Model of the defective unit • Serial number of the defective unit • Detailed description of the defect

2.

You will receive an automated reply with a support case number. A XipLink support engineer will contact you to identify the issue and confirm that the unit needs to be returned. If the problem can be isolated to software or a configuration issue, the support engineer will assist you in resolving the issue.

3.

Once a XipLink support engineer confirms that the device is faulty, the support case number becomes your RMA number. Return the device to your nearest XipLink distribution centre. (Contact your XipLink representative to determine the XipLink distribution centre closest to you.) Although you must bear the expense of shipping the unit to XipLink, we will bear the expense of shipping you the replacement unit.

4.

If the unit is still under warranty, it will be repaired or replaced as per the warranty terms and conditions. Should the unit no longer be under warranty, a quote for repair is issued needs to be accepted prior to commencing any repairs. In some cases XipLink may return the unit to its original manufacturer for repairs.

5.

Once the unit is repaired (or replaced), the RMA case is marked "resolved" and the unit is shipped back to you at XipLink's expense.

6.

The RMA case is only closed once you have received the repaired (or replaced) equipment.

114

Support

XipLink continually monitors its RMA process. Any cases that take an inordinate amount of time to complete are automatically escalated to our Directory of Operations.

10.3. Frequently asked Questions Here is a list of frequently asked questions that we have encountered. Should your question not be answered here, please send an email to XipLink support at . Q:

What kind of wireless networks can be combined at a hub site?

A:

A hub-side optimizer can support multiple logical wireless networks, decreasing the capital costs to support remote users that may be using different RF access technologies. Any combination of wireless networks can be defined on a single hub: TDMA, SCPC, Point to Multi-point, Mesh, Swift, BGAN, etc. By defining logical wireless networks, CPU and memory resources are fairly allocated across the wireless optimizer and under the policy control of the operator. Queues for various traffic types can be established and priorities assigned for each remote wireless network. XipOS rate control algorithms drive each individual logical wireless network to the maximum capacity without overdriving a downstream link or creating side effects to other networks and users.

Q:

Can remote devices running older (2.x) versions of XipOS operate with the new (3.x) software installed at the hub-site?

A:

Yes. One benefit to basing our wireless optimization solutions on the SCPS protocol is that the optimizers on each side of a wireless connection negotiate the strongest common set of functions they can support. So, while new devices gain access to new features, older devices will always continue to optimize based on the capabilities available to them. Even in partially built networks, optimized users experience better connection speeds and wireless network utilization while users from unoptimized sites continue to operate normally. Wireless optimization is completely transparent to all users.

Q:

Are hub site optimizers different from remote optimizers?

A:

No. There is no functional distinction between optimizers installed at hub site versus remote gateways, so the solution works well on meshed networks as long as they are sized appropriately.

Q:

Is XipLink wireless optimization derived from the Reference Implementation of SCPS-TP?

A:

XipLink was the first and remains the highest-performance implementation of SCPS-TP. It was implemented purely from the specification without any of the reference software. As a result of careful engineering, it has performance and capabilities far beyond the reference implementation or any derivative. The reference implementation is suited more for experimental purposes and is used by those trying to understand the SCPS-TP protocol.

Q:

How does XipLink software deal with SYN attacks or similar forms of denial of service attempts?

A:

A XipLink device operate as a split-connection TCP proxy. It implements SYN caching to protect the CPU from interrupt overloads, but is still vulnerable to some forms of SYN attacks. When an attack occurs, the maximum number of accelerated connections may be reached, at which point new connections bypass optimization, but continue using standard TCP communications, assuming the link itself is not denied. Once the source of an attack is determined, an optimizer can selectively bypass the optimization function according to operator-defined rules based using TCP ports and/or IP addresses.

115

Support

Q:

What are the maximum number of optimized sessions per unit, and what happens when that maximum is exceeded?

A:

The maximum number of sessions a XipLink wireless optimizer can handle is fundamentally determined by the CPU and memory available. XipLink’s XA-Series of scalable appliances range from the very low end of 2 Mbps and 50 simultaneous optimized TCP sessions to the XA-30K which can operate at 155 Mbps and supports 30,000 optimized TCP sessions. An embedded system using XipLink optimization may choose to restrict the amount of memory and processing cycles available to XipOS, thereby reducing the maximum number of optimized sessions the device can support. Once a unit reaches its maximum number of optimized sessions, and additional sessions are processed without optimization, and the unit acts as a standard router or bridge.

Q:

How many new sessions per second can the hardware appliances process?

A:

The XA-Series of appliances matches the CPU and memory with the anticipated network load and can easily handle over 500 TCP connection requests per second.

Q:

What happens when the network exceeds the bandwidth limitations on an optimizer?

A:

The XipLink wireless optimization software has been designed from the ground up to operate in a wide variety of networking environments. A key underlying capability of the software is to rapidly and fairly process as many connection requests as possible, up to a specified memory boundary. In some cases, the number of requests transiting an appliance (or transiting the software as it resides in a remote device) will exceed the available memory. When this happens the overflow sessions simply bypass the optimization function and pass transparently through the device, so these users will momentarily experience standard throughput until some memory again becomes available.

Q:

Is there a limit to the number XipLink Accelerators that can be deployed in a network?

A:

One of the key benefits of a XipLink deployment is that once the headquarters earth station or terrestrial hub site optimizers are deployed, any user that initiates sessions from a network (or a device containing the XipLink software) immediately gets the benefit of optimization. Full functionality is available over any topology and during partially completed deployments. Because there is no end-to-end configuration required in the XipLink architecture there are no technical limits to the number of sites that can communicate with one another or with a central site. There remains a need to properly identify the anticipated maximum TCP session count for each site, based on the aggregate load to and from each site.

Q:

The names of the congestion control schemes have changed after XipOS 2.x. Are there any underlying differences in how the schemes are implemented?

A:

There is indeed a significant difference between the current and 2.x congestion control schemes. Current XipOS does rate control per QoS queue at the device driver layer, so all congestion control mechanisms can benefit from the rate control mechanism embedded in QoS. Even with Enhanced TCP, in current XipOS the packets are still rate controlled. This means that the device will do standard TCP slow start, fast-retransmit / fast-recovery and congestion avoidance. But if the queue the packets are going through is set to a specific rate, then the device will not send faster than that. This also means that you now must create a QoS queue specifically for UDP (or other non-TCP protocols) if you want that traffic to get a non-default level of rate control, because every packet passing through a post-2.x XA goes through a QoS queue that does rate control. This is a significant departure from XipOS 2.x, where rate control was applied at the transport layer and if you selected Enhanced TCP the actual packets on the wire could go faster than their configured rate. They would in fact be sent at the link speed (e.g. 100Mbps for 100baseTX), which could cause

116

Support

bursts that other devices in the network would detect and tamper down through standard TCP rate control mechanisms. XipOS 2.x rate control would respect the configured rate on average, but if you looked closely (at a millisecond resolution) you would see those bursts. XipOS now has finer-grained rate control. Fixed rate control is close to XipOS 2.x's rate control, except that it falls back to standard TCP whenever it starts losing packets. Fixed rate control is roughly akin to replacing TCP's slow-start with rate control but with the standard congestion avoidance mechanism. Dynamic rate control in does the same thing as Fixed, but it also avoids "forcing" packets to a receiver with a small window. You can use Fixed rate control to defeat some packet shapers that shape based on advertised window size, or to gain better performance when there is no XA device on the other side of the link.

117

Chapter 11. Appendixes 11.1. XipLink Product Matrix This section lists all of the current XipLink products.

Table 11.1. XipLink XA Product Matrix Product

XA-Micro XA-500 (- XA-2000 C) (-C)

Application

SME

XA-4000 (-C)

XA-10000 XA-30000 XA-30000Rev3

SME

Enterprise Enterprise / Hub / Hub / Hub / Hub Datacenter Datacenter Datacenter

Max Bandwidth 2Mbps

4 Mbps

8 Mbps

16 Mbps

45 Mbps

155 Mbps 155 Mbps

Concurrent Connections

200

500

2,000

4,000

10,000

30,000

30,000

Fail to Wire

No

No

Yes

Yes

Yes

No

Yes

Web Cache

No

XA-500C XA-2000C XA-4000C No only only only

No

No

Interactive LCD No

No

No

Yes

Yes

Yes

Profile

Set-Top

Set-top

Set-top

1u 1u 2u 1u Rackmount Rackmount Rackmount Rackmount

Height

35mm

38mm

35mm

44mm

44mm

88mm

44mm

Width

115mm

290mm

156mm

430mm

430mm

430mm

442mm

Depth

115mm

170mm

225mm

393mm

393mm

393mm

520mm

Network Interfaces

2

4

4

4

4

4

4

10/100 Mbps

10/100/100010/100/100010/100/100010/100/100010/100/1000 Mbps Mbps Mbps Mbps Mbps

0.9kg

1.8kg

Network speed Weight

IF 10/100 Mbps 0.5Kg

6kg

Yes

6kg

13kg

12.2Kg

Operating Temp. 0°C - 60°C 0°C - 60°C 0°C - 60°C 5°C - 45°C 5°C - 45°C 5°C - 45°C 0°C - 40°C Power (max)

10W

14W

60W

350W

350W

500W

400W

Capabilities Supported by All XA Series Appliances • Intelligent dynamic buffering • Native SCPS-TP protocol gateway • Native layer 3 and 4 transparency, DSCP copy-through or marking • XipLink Adaptive Data Compression • IP QoS support and XipLink TCP Weighted Fair Queuing QoS • UDP / VoIP prioritization • HTTP acceleration • Selective acceleration/bypass

118

Appendixes

• DNS cache • Accelerates all TCP/IP applications • I-PEP (Satlabs) standard compatible • Anti-denial of service tools

119

Glossary of Terms This section contains definitions of terms found in this manual. Autonomous System

An Autonomous System is a collection of connected Internet Protocol (IP) routing prefixes under the control of one or more network operators that presents a common, clearly defined routing policy to the Internet.

Border Gateway Protocol

A routing protocol that maintains a table of IP networks or 'prefixes' which designate network reachability among autonomous systems.

Common Address Redundancy Protocol

The Common Address Redundancy Protocol or CARP is a protocol which allows multiple hosts on the same local network to share a set of IP addresses. Its primary purpose is to provide failover redundancy for devices in router mode (Layer 3).

Differentiated Services Code Point

This is a field in the header of IP packets for defined packet classification purposes.

Domain Name System

A hierarchical naming system for computers, services, or any resource participating in the Internet. It associates various information with domain names assigned to each of the participants. Most importantly, it translates domain names meaningful to humans into the numerical (binary) identifiers associated with networking equipment for the purpose of locating and addressing these devices world-wide.

Dynamic Host Configuration Protocol

A network application protocol used by devices (DHCP clients) to obtain configuration information for operation in an Internet Protocol network. DHCP reduces system administration workload, allowing devices to be added to the network with little or no manual intervention.

Generic Routing Encapsulation

Generic Routing Encapsulation (GRE) is a tunnelling protocol developed by Cisco Systems that can encapsulate a wide variety of network layer protocol packet types inside IP tunnels, creating a virtual point-to-point link to various brands of routers at remote points over an Internet Protocol (IP) internetwork.

Graphical User Interface

This refers to a graphical user interface that can be navigated by means of a mouse or directional keys.

Hyper Text Transfer Protocol

An application-level protocol for distributed, collaborative, hypermedia information systems. Its use for retrieving inter-linked resources led to the establishment of the World Wide Web.

Network Address Translation

This is the process of modifying network address information in datagram packet headers while in transit across a traffic routing device for the purpose of remapping a given address space into another.

Open Shortest Path First

OSPF is an interior gateway protocol that routes Internet Protocol (IP) packets solely within a single routing domain (autonomous system). It gathers link state information from available routers and constructs a topology map of the network. The topology determines the routing table presented to the Internet Layer which makes routing decisions based solely on the destination IP address found in IP datagrams.

Packet Per Second

The rate of packets measured in a single second.

120

Glossary of Terms

Real Time Transport Protocol

The Real-time Transport Protocol (RTP) defines a standardized packet format for delivering audio and video over the Internet. It was developed by the Audio-Video Transport Working Group of the IETF and first published in 1996 as RFC 1889, and superseded by RFC 3550 in 2003.

Robust Header Compression

Robust Header Compression is a standardized method to compress the IP, UDP, RTP, and TCP headers of Internet packets. This compression scheme differs from other compression schemes such as IETF RFC 1144 and RFC 2508 by the fact that it performs well over links where the packet loss rate is high, such as wireless links.

Scaleable Vector Graphics

Scalable Vector Graphics (SVG) is a family of specifications of an XML-based file format for describing two-dimensional vector graphics, both static and dynamic (i.e. interactive or animated). The SVG specification is an open standard that has been under development by the World Wide Web Consortium (W3C) since 1999.

Secure Shell

A network protocol that allows data to be exchanged using a secure channel between two networked devices.

Selective Acknowledgment

Negative

The receiver explicitly lists which packets, messages, or segments in a stream are not acknowledged.

Service Group

In a WCCP deployment, service groups identify which traffic the WCCP router should forward to the optimizer.

SNACK

See Selective Negative Acknowledgment.

Space Communications Protocol Specifications

A set of extensions to existing protocols and new protocols developed by the Consultative Committee for Space Data Systems (CCSDS) to improve the performance of Internet protocols in high-latency environments. See Also http://public.ccsds.org/publications/archive/714x0b2.pdf .

Spanning Tree Protocol

The Spanning Tree Protocol (STP) is a network protocol that ensures a loop-free topology for any bridged Ethernet local area network. The basic function of STP is to prevent bridge loops and ensuing broadcast radiation. Spanning tree also allows a network design to include spare (redundant) links to provide automatic backup paths if an active link fails, without the danger of bridge loops, or the need for manual enabling/disabling of these backup links. STP is a Data Link Layer protocol. It is standardized as IEEE 802.1D. As the name suggests, it creates a spanning tree within a mesh network of connected layer-2 bridges (typically Ethernet switches), and disables those links that are not part of the spanning tree, leaving a single active path between any two network nodes.

SYN Flood

A form of denial-of-service attack in which an attacker sends a succession of TCP SYN requests to a target system.

Time division multiple access

A channel access method for shared medium networks. It allows several users to share the same frequency channel by dividing the signal into different time slots. The users transmit in rapid succession, one after the other, each using his own time slot. This allows multiple stations to share the same transmission medium (e.g. radio frequency channel) while using only a part of its channel capacity.

Transmission Control Protocol

One of the core protocols of the Internet Protocol Suite. TCP is one of the two original components of the suite (the other being Internet Protocol, or IP), so the entire suite is commonly referred to as TCP/IP. Whereas IP handles lower-level transmissions from computer to computer as a message makes its way across the

121

Glossary of Terms

Internet, TCP operates at a higher level, concerned only with the two end systems, for example a web browser and a web server. Very Small Aperture Terminal

A small earth station for satellite transmission.

Virtual Local Area Network

A Virtual Local Area Network (VLAN) separates a single physical network into logically isolated virtual networks. The separation is implemented in layer 2 of the networking stack (i.e. Ethernet), and so is independent of Internet Protocol (layer 3) network partitioning.

Web Cache Communication Protocol

A protocol developed by Cisco that allows proxies such as web caches and accelerators to register with routers and have traffic redirected to them. WCCP supports load distribution and automatic failover, and enables non-inline deployments.

Window scaling

The TCP window size field controls the flow of data, and its value is limited to between 2 and 65,535 bytes. Since the size field cannot be expanded, a scaling factor is used. The TCP window scale option, as defined in RFC 1323, is used to increase the maximum window size from 65,535 bytes to 1 Gigabyte. Scaling up to larger window sizes is a part of tuning TCP for high-latency wireless links.

XipLink Real Time

Xiplink RealTime is a XipLink proprietary method of coalescing UDP packets .

XipLink Transport Control

Defines the congestion control method that is to be used on your wireless connection.

122