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
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.
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
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
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.
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
Technology Overview
RFC
Title
RFC 2616
Hypertext Transfer Protocol -- HTTP/1.1
XipLinks 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.
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.
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.
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
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
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
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
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
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
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
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
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. XipLinks 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
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
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
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
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
XipLinks 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
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
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
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
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
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
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
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
8%
G.729 (8 Kbps)
20 ms
33%
G.729 (8 Kbps)
20 ms
47%
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%
G.729 (8 Kbps)
10 ms
10
47%
G.729 (8 Kbps)
15 ms
10
50%
G.729 (8 Kbps)
20 ms
10
52%
10
30
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
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
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
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
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
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
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 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
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:
All three optimizers define service groups 61 and 62 to redirect all TCP traffic.
38
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
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
XipLinks 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 its XA-Series of scalable appliances.
3.11.2. Burst Connection Handling

XipLinks 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
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.
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
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 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
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
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
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
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 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 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 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
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
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
Once OSPF is enabled on the device, you can specify the device's Stub Area and also configure which
networks and areas to advertise.
Connected.
Kernel.
Static.

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
Once BGP is enabled on the device, you can specify the device's AS Number, Network and Netmask,
and also configure neighbor ASes.
Connected.
Kernel.
Static.

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
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
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
EXEC_FAILED
Failed to launch a critical process.
MISSED_HEARTBEAT
The XipOS monitoring system did not receive a regular signal from
a critical process.
PROCESS_EXITED
A critical process terminated (and was restarted).
CONN_LIMIT_REACHED The device has reached its maximum supported number of

optimized connections.
56
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
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 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
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
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
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
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
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 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
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
8Mb maximum receive speed
4Mb priority receive speed
Site 2:
Site 5:
No priority receive speed
Site 3:
66
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
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 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
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 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 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
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
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
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
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
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.
Match the rule against traffic marked with the specified Differentiated Services Code Point
For non-Crypto products you should instead restrict telnet access.
75
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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: <support@xiplink.com>
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 <support@xiplink.com> 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 <support@xiplink.com>.
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. XipLinks 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
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. 0C - 60C 0C - 60C 0C - 60C 5C - 45C 5C - 45C 5C - 45C 0C - 40C

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

XIPLink User Guide XIP OS

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

XIPLink User Guide XIP OS

Hochgeladen von

Copyright:

Verfügbare Formate

XipOS

XipOS: User Manual

3.6. XipLink Real-Time (XRT) ...................................................................................

5. Redundancy Deployment Options .................................................................................... 96

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

Chapter 1. XipLink Optimization

Figure 1.1. XipLink Interoperability between devices

XipLink Mission Statement

1.3. The XipLink Advantage

Figure 1.2. XipOS

Prot ocol Accelerat ion

1.3.1. Protocol Acceleration

1.3.2. Advanced Compression

1.3.3. Internet Optimization

1.3.5. Quality of Service

1.4. Supported Capabilities

1.4.2. UDP Acceleration Techniques

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

1.4.3. Compression and Application Acceleration

1.4.4. Tunnelling Options

1.4.5. Network Appliance Benefits

Fail-to-wire support with certain hardware platforms

1.4.6. Standards Support and Interoperability

Table 1.1. SCPS-TP Capabilities

Table 1.2. HTTP RFC's

Hypertext Transfer Protocol -- HTTP/1.0

Hypertext Transfer Protocol -- HTTP/1.1

1.4.7. RFC and TCP Enhancements Support

Transmission Control Protocol

Requirements for Internet Hosts - Communication Layers

Path MTU Discovery RFC

TCP Extensions for High Performance

TCP Extensions for Transactions Functional Specification

TCP Selective Acknowledgment Options

Virtual Router Redundancy Protocol

Enhancing TCP Over Satellite Channels using Standard Mechanisms

TCP Congestion Control

The New Reno Modification to TCP's Fast Recovery Algorithm

Computing TCP's Retransmission Timer

Increasing TCP's Initial Window

Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations

The New Reno Modification to TCP's Fast Recovery Algorithm

1.5. Document Overview

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

Chapter 3 Understanding XipLink Optimization.

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

Chapter 7 Advanced Upgrade Procedures.

Contains information about how to work with

1.5.1. Conventions used in this Manual

Chapter 2. Quick Start - XA Series

2.1. Unpacking and Box Contents

2.2. Placing the Optimizer in the Network

Figure 2.1. Placement of the Optimizer

Quick Start - XA Series

2.2.1. Physical Connections

2.2.1.1. Product Labels

Figure 2.3. XA-2000

Figure 2.4. XA-4000 | XA-10K

Figure 2.5. XA-30K

Quick Start - XA Series

2.3. Accessing the XipOS Web User Interface

Table 2.1. Factory default IP addresses

Quick Start - XA Series

2.5. XipLink Setup Wizard