Operating out of the box as a four-port transparent bridge, ipXpress can support Ethernet and Fast Ethernet networks and can be configured to support failover for individual servers and itself. A hot-standby feature lets ipXpress monitor a Phobos Internet traffic-management device's health and take over its tasks and identity in the event of a failure.

Security in ipXpress falls into two categories: configuration access and attach access. Two separate passwords can be enabled for a higher level of security, and you can set up access lists to indicate that a device can be configured and/or attached remotely only from specified computers. The command-line management software runs on Red Hat Linux 5.2, 6.0, 6.1 and Microsoft Windows NT 4.0.

When configured, ipXpress monitors the health of each physical server to ensure optimal performance and availability.

Getting Physical

Weary of admiring just ipXpress' good looks, I put the device to work. After plugging the product into my LAN, I sat down to install the management software and found that the process on Windows NT 4.0 was practically effortless. I started up the software, opened the user's guide, skipped the thorough introduction and the "before you begin" section, and beelined to the configuration directions.

The configuration--which is done completely via a command-line interface--was a breeze. Each one of the physical servers needed to be created and named for later inclusion in a virtual group. I created and enabled two physical servers, giving them the names "kenny" and "cartman."

During physical-server configuration, I was able to specify an allowable limit of three retransmitted SYN packets for each server--quite a handy security capability. The one thing I found annoying about the ipXpress management software, albeit a minor frustration, is its colors. The light-colored text against the bright blue background is hard on the eyes after a while. But I liked the ping and trace-route tools, as well as the ability to save different configurations to a file for later use.

Getting Virtual

Now that I had physical servers defined, I needed a virtual server. The user guide told me I first had to create and name a server group, so I dubbed a group "southpark" and associated "kenny" and "cartman" with it. (This is not your network--stop groaning.)

The most difficult aspect of the configuration was deciding what load-balancing policy to use. The ipXpress supports six load-balancing algorithms: round-robin, fastest response time, adaptive, least connections, weighted least connections and fixed. I chose round-robin at first and then later reconfigured the group to use fastest response times, because the "kenny" server isn't quite as powerful as "cartman."

Once the server group was configured, I could finally create a virtual front-end server. The virtual server is the IP address actually accessed by the client. This solution can pass all traffic on all ports by specifying that ports 1 through 65,535 be passed to a particular group of physical servers (that is, "southpark"), or configuration can be done via individual ports. On Windows NT, the ports must be specified by number, not service name.

Getting Monitored

Monitoring is an important feature of load-balancing solutions, and ipXpress handles it--along with all aspects of dynamic load-balancing--efficiently. Network management and switching are undertaken by background processes running within MaxOS, Phobos' embedded operating system. System diagnostics are readily accessible--system logs can be directed to remote systems, and informational messages are available on ipXpress.

Specific ports on a virtual server can be monitored for responsiveness by specifying the port and a time-out value in seconds. Monitoring is accomplished by an ipXpress connection attempt to the physical server in the group associated with the specified port. If the port is the default HTTP port (80), the device also checks for a valid response to an HTTP 1.0 get command. If a time-out occurs or a connection is refused, the port is marked as "down." Other services on the physical server are still available, providing the services respond to monitoring checks. Individual or a range of ports also can be made "sticky," which indicates that connections on that port are persistent.

Monitoring of the ipXpress can be done by network-management software, but to create a fault-tolerant server farm, you are best off introducing a second ipXpress that acts as a standby for the primary devices. The second device then listens and monitors the primary ipXpress, and takes over if the primary fails.

Send your comments on this article to Lori MacVittie at lmacvittie@nwc.com.