HyperIP®
IP Accelerator
Release 4.0
Support Reference Manual
Page 1
MAN-HYPSUP-4.0
Revision Record
Revision / Date / Description1.0 / Manual released (TBD)
4.0 / April, 2004 / Manual updated with various corrections, added information on High Availability (Fail Over), release level updated to correspond to software release level.
© 2004 by Network Executive Software, Inc. Reproduction is prohibited without prior permission of Network Executive Software, Inc. Printed in the U.S.A. All rights reserved.
The U.S. Department of Commerce restricts the distribution of technical information contained in this document when exported outside the U.S. Therefore, careful attention should be given to compliance with all applicable U.S. Export Laws if any part of this document is to be exported.
You may submit written comments using the comment sheet at the back of this manual to:
Network Executive Software, Inc. (NESi)
Publications Department
6420 Sycamore Lane, Suite 300
Maple Grove, MN 55369
USA
Comments may also be submitted over the Internet by addressing e-mail to:
or, by visiting our web site at:
Always include the complete title of the document with your comments.
Preface
This manual contains reference information for Network Executive Software’s (NESi) HyperIP product. It is intended for NESi agents and support personnel.
Notice to the Reader
The material contained in this publication is for informational purposes only and is subject to change without notice. Network Executive Software, Inc. is not responsible for the use of any product options or features not described in this publication, and assumes no responsibility for any errors that may appear in this publication. Refer to the revision record (at the beginning of this document) to determine the revision level of this publication.
Network Executive Software does not by publication of the descriptions and technical documentation contained herein, grant a license to make, have made, use, sell, sublicense, or lease any equipment or programs designed or constructed in accordance with this information.
Corporation Trademarks and Products
Network Executive Software (NESi)NETEX, HyperIP
These references are made for informational purposes only.
Document Conventions
The following notational conventions are used in this document.
Format / Descriptiondisplayed information / Information displayed on a display terminal (or printed) is shown in this font.
user entry / This fontis used to indicate the information to be entered by the user.
UPPERCASE / The exact form of a keyword that is not case-sensitive or is issued in uppercase.
MIXedcase / The exact form of a keyword that is not case-sensitive or is issued in uppercase, with the minimum spelling shown in uppercase.
bold / The exact form of a keyword that is case-sensitive and all or part of it must be issued in lowercase.
lowercase / A user-supplied name or string.
value / Underlined parameters or options are defaults.
<label> / The label of a key appearing on a keyboard or a button on a web browser page. If "label" is in uppercase, it matches the label on the key or button (for example: <ENTER>). If "label" is in lowercase, it describes the label on the key (for example: <up-arrow>).
<key1<key2> / Two keys to be pressed simultaneously.
No delimiter / Required keyword/parameter.
Glossary
ACK: An acknowledgment of a message returned to the message sender.
ASCII: Acronym for American National Standard Code for Information Interchange.
asynchronous: A class of data transmission service whereby all requests for service contend for a pool of dynamically allocated bandwidth and response time.
buffer: A contiguous block of memory allocated for temporary storage of information in performing I/O operations. Data is saved in a predetermined format. Data may be written into or read from the buffers.
header: A collection of control information transmitted at the beginning of a message, segment, datagram, packet, or block of data.
host: A data processing system or storage controller that is connected to the network and with which devices on the network communicate. In the context of Internet Protocol (IP), a host is any addressable node on the network.
Internet Protocol (IP): A protocol suite operating within the Internet as defined by the Requests For Comment (RFC). This may also refer to the network layer (level 3) of this protocol stack (the layer concerned with routing datagrams from network to network).
ISO: Acronym for International Standards Organization.
link: The communications facility used to interconnect two networks.
NAK: A negative acknowledgment of a message returned to the sender of the message. This indicates that the message was not properly received or could not be received.
Network Executive (NetEx): A family of software designed to enable two or more application programs on heterogeneous host systems to communicate. NetEx is tailored to each supported operating system, but can communicate with any other supported NetEx, regardless of operating system. However, a special version of NetEx is tightly integrated into the HyperIP product, which can only communicate with other HyperIP products.
NetEx is a registered trademark of Network Executive Software.
NRB: The NetEx Request Block. This is a block of parameters used to pass information between calling programs and NetEx.
Open Systems Interconnection (OSI): A seven-layer protocol stack defining a model for communications among components (computers, devices, people, etc.) of a distributed network. OSI was defined by the ISO.
RCT: Route Control Table used to define all of the HyperIP routes that are on the network. It is used in conjunction with the Session Name Table to determine message routes into and out of each node in the system.
SCLOSE: A NetEx interface request to gracefully terminate a NetEx session.
SCONNECT: A NetEx interface request to establish a NetEx session.
SDISCONNECT: A NetEx interface request to abruptly terminate a NetEx session.
SNT: Session Name Table used to provide the basic information for session initialization and session control.
SOFFER: A NetEx interface request to make session services from the calling program available to the network.
SREAD: A NetEx interface request to receive data written to the network by another program.
SWAIT: A NetEx interface request to wait on a NetEx event or events.
SWRIT: A NetEx interface request to write data to the network.
TCP/IP: An acronym for Transmission Control Protocol/Internet Protocol. These communication protocols provide the mechanism for inter-network communications, especially on the Internet. The protocols are hardware-independent. They are described and updated through Requests For Comment (RFC). IP corresponds to the OSI network layer 3, TCP to layers 4 and 5.
Contents
Revision Record......
Preface......
Notice to the Reader......
Corporation Trademarks and Products......
Document Conventions......
Glossary......
Contents......
Figures......
Introduction......
The Problem......
The Solution......
Troubleshooting Features......
Statistics......
Informational Logs......
System Dumps......
Idle Traffic Processing......
Advanced Session Configuration......
Intercept Configuration......
Operator Interface......
Aggregation......
IP "Friendly"......
SNMP......
Web Browser Interface......
Help......
Support (Hidden) Pages......
HyperIP Hidden Commands Page......
Display Commands......
Set Commands......
HyperIP Commands......
NetEx Commands......
DISPLAY TRANSPORT......
Issue Linux Command......
Problem Resolution......
Hardware Problem......
Configuration......
High Availability (Failover) Configuration......
Applications Not Communicating Across the Network......
Poor Performance across the Network......
Dialog Details......
Configuring a HyperIP Appliance......
Configuration via Wizard/Expert......
HyperIP Password......
Lost/Forgotten Admin Password......
Software Updates and Upgrades......
Update Files......
Using the Dialog Interface......
Structure of the Dialog Configuration Menus......
Configuration Database......
Complete Upgrade from CD......
Dump File Processing......
Resources......
Logs......
Papers......
Links......
Figures
Figure 1. Dump File Contents (Uncompressed Listing)......
Figure 2. Typical System Log Display......
Figure 3. Typical NetEx Log Display......
Figure 4. Typical Support HyperIP Command Page......
Figure 5. Common Support Display Commands......
Figure 6. Common Set Commands......
Figure 7. Output from HyperIP Command ‘help’......
Figure 8. Output from HyperIP Command ‘d help’......
Figure 9. Output from NETEX Command ‘help’......
Figure 10. NETEX Commands......
Figure 11. Typical Display Transport Output......
Figure 12. Typical Display Specific Transport Output......
Figure 13. Linux Command Example of ‘ifconfig'
Figure 14. Typical Point-to-Point Configuration......
Figure 15 Failover (AHS) Configuration......
Page 1
MAN-HYPSUP-4.0
Introduction
HyperIP is an appliance that is used to enhance business continuity application performance when running over long-distance IP networks. HyperIP is based on RFC3135 which describes techniques used to mitigate TCP performance problems over long-distance wide-area networks. These techniques are collectively known as "TCP Performance Enhancing Proxies" (PEP).
Due to the anticipated usage of this device in providing IP acceleration to corporate mission critical, high-volume data, it is best-suited for use in corporate private IP (intranet) networks, rather than over public IP (internet) networks.
The Problem
Several characteristics of TCP/IP cause it to perform poorly over long distances:
- Window Size - To utilize the full available bandwidth of a data session, enough data must be sent to "fill the pipe". Generally, TCP implementations are limited to 65KB (a few enhanced versions may use up to 512KB) "windows", or amount of data allowed to be outstanding ("in the air") at any given moment. The total round-trip time for a 3000 mile connection is approximately 60 msecs, creating an available data "pipe" at 100 Mbps of 750 Kbytes. A satellite connection (540 ms round-trip) at 45 Mbps creates a 3 MByte pipe. Obviously, there is a large amount of "dead air" even using the enhanced TCP window size in these cases.
- Acknowledgement Scheme - TCP causes the entire stream beginning with the lost portion to be retransmitted in its entirety. In high bit-error-rate (BER) scenarios this can cause large amounts of bandwidth to be wasted in resending data that has already been successfully received, all with the long latency time of the path.
- Slow Start - TCP data transfers start slowly to avoid congestion due to possible large numbers of sessions competing for the bandwidth, and ramp-up to their maximum transfer rate, resulting in poor performance for short sessions.
- Session free-for-all - Each TCP session is throttled and contends for network resources independently, which can cause over-subscription of resources relative to each individual session.
The Solution
HyperIP is a network appliance that is added into the network to provide transparent "acceleration" of TCP/UDP traffic across a long distance WAN. It consists of the following software components:
HyperIP Application
- Edge Intercept: Intercepts IP packets, optimizes them for performance, and reroutes them over the HyperIP network.
- Edge Interface: Provides the interface between the Edge Intercept and the NetEx/IP interface component.
Transport
- NetEx/IP Interface: Provides the interface between the Edge Interface and NetEx/IP components.
- NetEx/IP: Provides the transport protocol that is used for delivery of optimized HyperIP packets
HyperIP provides the following benefits:
- Window size - NetEx protocol will keep the available network bandwidth pipe full, resulting in more efficient utilization (minimizing the dead-air situation explained above) (send rate * round-trip-time)
- Acknowledgement scheme - NetEx retransmits only NAK'ed segments and not all the subsequent data that has already been successfully sent.
- Fast Start - Configuration parameters allow NetEx to start transmissions at a close approximation of the available session bandwidth.
- Dynamic adjustments - based on feedback from the receiver in the acknowledgement protocol, allows NetEx to quickly "zero-in" on the appropriate send rate for current conditions.
- Session pipeline - HyperIP design allows traffic from multiple TCP sessions to be aggregated over a smaller set of connections between the HyperIP devices, enabling a more efficient use of the bandwidth and less protocol overhead acknowledging many small messages for individual connections.
Troubleshooting Features
Statistics
HyperIP provides session-level statistics. Input/Output character counts, message counts, and session establishment requests are maintained. Statistics may be gathered while HyperIP is running by issuing the command (from the Commands page on the browser interface) “DisplayHyperIPState.” With HyperIP running, if you issue subsequent DisplayHyperIPState commands, the numbers of bytes in and out should be incrementing. Rexmits and rcvdups are indications that there are errors on the network.
When compression is active, compression ratio(s) are also displayed. Compression ratios are calculated over a 6 second interval. The display includes; current compression ratio, in and out, and for the last 6 second interval and the previous (to the last) 6 second interval. Intercept status is displayed as well as the number of bytes per protocol type (TCP/UDP/ICMP).
Informational Logs
There are several logs being maintained in HyperIP. Each component maintains a separate log. The system (Linux OS) uses the syslog, NETEX uses netex.log and the HyperIP application uses hyperip.log to record related events. These logs are instrumental in diagnosing a customer problem. The syslog and HyperIP logs are accessible via the HyperIP web browser interface from the Commands page (misc commands). The NETEX log is only available via the hidden page. All the logs are extracted and found in the ‘dumpdiags’ output as well. The HyperIP and NetEx logs are located in /var/log/hyperip.
System Dumps
System dumps are created by using the “DumpDiagInfo” button on HyperIP’s Command browser screen. Once the dump is taken, it should be uploaded to Network Executive Software’s web site using the “DumpMove” button. Thiscommand ftp’s the dump to NESi, where it is placed in the HyperIP Uploads directory.
For service personnel examining these dumps, the format of an uploaded dump file name is, for example: hou-emc-netex1-20040325_172318-diaginfo.tar.gz.20311. Where:
- hou-emc-netex1 = Hostname of this HyperIP (as seen using the Linux “hostname” command)
- 20040325_172318 = Time stamp of the dump. In this example the dump was taken at 172318 (18 seconds past 5:23 PM)
- diaginfo.tar.gz.20311 = filetype identifier
To examine a dump with a file name such as the one illustrated above, from a Windows XP workstation, the filename must first be changed to a format that Windows will accept. Note also that WinZip must be installed on the PC. For the above file, open the dump using the following steps:
- Change the file name as follows:
- From - hou-emc-netex1-20040325_172318-diaginfo.tar.gz.20311
- To - hou-emc-netex1-20040325_172318-diaginfo-20311_tar.gz (Note – no trailing “.”)
- Open the file by double-clicking.
- When the WinZip dialog box opens, asking for the file name, change the name to:
- : hou-emc-netex1-20040325_172318-diaginfo-20311.tar - again removing the trailing “.”
- WinZip will now prompt if you would like to uncompress the file to a temporary folder, respond Yes and WinZip will display the individual files.
In this example, the first screen of the WinZip expansion is shown in Figure 1 following:
Figure 1. Dump File Contents (Uncompressed Listing)
For an explanation of the contents and meanings of some of the files included in the dump, please see the section Dump File Processing on Page 37.
System Log
The Linux OS system logs events in the syslog. These events may indicate errors or merely normal events. Typically, when there is a problem at a customer site, this log should be scanned to determine if there are unusual events logged, or missing. Events such as driver events, logins, interface changes, service changes are logged here. Support personnel should become familiar with the syslog on a normal operational HyperIP. In the following display the” mgetty[xxx]: failed dev=ttyS0…” message only means that the login on the serial port has timed out and is not in itself a ‘significant’ event.
In order to find the last time the system was restarted, go to the bottom and scroll up until “restart” is located. That will be the last restart, and new events follow the restart.
Figure 2. Typical System Log Display
In an uploaded HyperIP dump file, the system log is found in “messages.” The “messages” log file is aged out when full, i.e., when “messages” is full (or on operator command), the name is changed to “messages.1” and a new “messages” file is opened.“If messages.1” already exists, it is renamed “messages.2” etc, until “messages.5” is discarded and “messages.4” is renamed “messages.5.”
HyperIP Log
The HyperIP application logs events in the hyperip.log. Like syslog, these events may indicate errors or merely normal events. Typically, when there is a problem at a customer site, this log should be scanned to determine if there are unusual events logged, or missing. Events such as HyperIP startup and shutdown events, TCP events, configuration changes, license changes are logged here. Support personnel should become familiar with the hyperip.log on a normal operational HyperIP.
Figure 3. Typical NetEx Log Display
In an uploaded dump file, the HyperIP log is found in hyperip.log. As with the system log (in messages file(s)), there may be multiple instances of the HyperIP log. Up to 5 log files are saved in HyperIP.
Idle Traffic Processing
HyperIP maintains session contact with idle-traffic messages. When data traffic is active on a session, idle-traffic messages are not transmitted. If a session has had no traffic activity, idle-traffic messages will be used to assure that the destination HyperIP is still available. If no response from the destination HyperIP is detected, within the output time-out period configured for the system, the path to that destination HyperIP is assumed to be inoperative and the session is placed in recovery mode.
Advanced Session Configuration
The HyperIP configuration is defined in a configuration file. When HyperIP is initialized, it automatically establishes connections with the specified HyperIP node(s). Configurations on each side must be complementary; i.e. each must know how to reach the other. The sessions “know how” to reach each other by the IP address(es) and routes set up during the configuration process.