4. The XipOS Web Interface
4.6. System
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.
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
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.
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.
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: This category covers all TCP traffic, including HTTP traffic.
XRT statistics: These statistics show the benefits derived from packet coalescing and header compression.
IP-Optimization statistics: These statistics show the benefits of packet compression and byte caching.
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: These statistics show network traffic coming and going through the device's Wireless interface.
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.
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
• 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 -- run factory reset
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.
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.
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:
• 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.
• 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.
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:
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.
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.
The XipOS netstat has been extended in several ways.