Up

Is the Xyplex 1600 Right For You?

Back to Xyplex Resources

This may seem like a strange comment from the person who maintains this web site, but are you sure you really want to use the Xyplex 1600? If you're using it to control a modem pool, it may be perfectly suitable (I don't know; I've never used them in such a mode.)

If, however, you're using it as a console server, then I'd suggest that most organizations would be further ahead to purchase a more modern piece of equipment. Some of the reasons for this are:

• Serial Break

  Some servers, particular earlier Sun machines, respond to a serial break signal by stopping the OS dead in its tracks and dropping to the PROM monitor. This in general isn't a good thing for a production server.

  When the Xyplex first boots there is a fair amount of noise on the serial ports which can be interpreted by an attached machine as a serial break signal. One can usually avoid this problem on Sun machines by configuring the Sun to ignore console breaks after the kernel has booted.

  However this system breaks down during one of the most critical times: You've just taken an extended power outage in your data center, and your UPS has run out of battery time. You've configured your servers to recognise this situation and they've shut themselves down. (You did, right? :) The Xyplex has lost power too, but that's fine because you remembered to save your most recent changes to the flash card. (You did, right? :) Now the power has come back and your Xyplex is booting at the same time that your Sun machines are coming up. The Solaris kernels have not yet fully booted, so they're not ignoring break signals. *thonk* Your servers are now all waiting at the PROM prompt until someone pages you out of your nice warm bed at 3AM to say that your network is dead ...

• Dependancy on External Components

  Unless you're using a flash card to store information locally, the Xyplex is very dependant on other machines on your network, such as a TFTP server. This may be ok when using it to serve a modem pool, however it just isn't good enough when acting as a console server. (If your TFTP server won't boot after an extended power outage, you won't be able to access its serial port to figure out why if you need the Xyplex to get there. Chicken and egg ...)

• Ease of Configuration

  Let us just say that, by modern standards, configuring a Xyplex 1600 is convoluted, prone to error, and difficult to validate. By the time that you get around to having a working configuration, the time you spent may have been more expensive than purchasing a more modern unit.

• Hardware Compatibility

  The network connection for the Xyplex 1600 requires an AUI in order to connect it a TP (eg 10bT) hub. AUIs are becoming difficult to find, and not all models work.

• Security

  The Xyplex 1600 does not support ssh access, so in order to deploy it securely you should:

  1. Deploy your Xyplex(es) such that they are on a separate administrative network that is not generally reachable.
  2. Deploy one or two bastion hosts as gateways to the administrative network.
  3. Permit access to the bastion hosts only via secure protocols such as ssh.

• Support

  Hardware support and software upgrades are no longer available for the Xyplex 1600.

If you're a hobbiest or your organization's financial circumstances are such that purchasing newer equipment is not an option, then you can of course still use a Xyplex, but be aware of the pitfalls.

There are now many vendors of console server and terminal server products. Out of respect for MRV Communications, who provided much information on the Xyplex 1600 when they bought that product line, I mention them as one such vendor. However you can find many other such vendors by doing a search for "console server" in your favorite search engine.

If you need to control x86-based machines that don't have serial consoles, then check out the PC Weasel 2000 as related hardware. Many x86 rack mount hardware vendors are now also providing similar cards as options.

Back to Xyplex Resources