The SystemConsoleSwitch is an intelligent switch that allows a single text (RS-232) terminal to control and monitor an entire data center from one central location. It's modular design accommodates data centers of various sizes and future growth. Each SystemConsoleSwitch allows for viewing of 12 console ports and is easy expandable to view up to 120 ports
Optimize systems management with the SystemConsoleSwitch's Remote Access feature, devices can be accessed from home or on the road via modem dial-up. The SystemConsoleSwitch also features a Audit Trail, providing a 32k (40 screen) buffer for each port, this proves to be invaluable for diagnostics.
Click here for a Free Serial / Console Management Switch Project Evaluation
- Flexible Access - Telnet capability when connected to a networked device. For more information, Read our Telnetting Technical Tips.
- Security & Confidentiality - SystemConsoleSwitch may operate separately from your network and has password protection for remote users.
- Easy Printing - One printer serves all ports!
- Independence - Each device port operates independently, so failure of any of the attached devices will not affect the monitoring and control capabilities for other attached machines.
- Compatibility - Plug compatible with every type of computer system through the console port.
- Name Your Devices - Assign system names and locate devices instantly.
- Cost Savings - Eliminate costly terminal and keyboard expenditures while saving valuable space.
- Easy to Use - Controlled through the terminal keyboard.
- Flexibility - Choose the chassis that best fits your system, desktop or rack mount.
Specifications of: SystemConsoleSwitch
Physical Size:
Desk-top Chassis - 9" H x 4.3" W x 10.25" D
Rack-mount Chassis - 5.25" H x 19" W x 10.25" D
Shipping Weight: 8 lb.
Power Requirements: Universal input, 25 Watts
Operating Temperature: 32F to 125F
Console Ports Specifications
Baud Rate: 300 to 19,200 dip switch selectable
Memory: 32Kb per port
Maximum number of ports per chassis: 12
Connectors
Terminal Port: DB25F
Printer Port: DB25F
Modem Port: DB25F
Console Port Connections: RJ45
Warranty: 12 months from date of purchase. Extended warranties available.
* Chassis includes Universal Power Adapter and 6 foot Cascade Cable.
** Dual Port Modules must be ordered separately.
SystemConsoleSwitch FAQs
Q: Is telnetting into the SystemConsoleSwitch the same as being physically at the SystemConsoleSwitch for management purposes? Can we reboot the system, and when it comes back up are we still connected? Or do we have to establish a new telnet session through the modem port again?
A: Telnetting into the SystemConsoleSwitch will be the same as being physically at the console by the computer. If you reboot you will not lose the telnet session and will remain connected. In this scenario you are telnetting to the switch and not directly to the server.
Q. How can I Telnet with the SystemConsoleSwitch?
A. There are only 3 ways to access server system logs and other machine diagnostics. They are: (1) through the keyboard/mouse/monitor (2) through the serial (TTY) port (3) through the network port, typically an Ethernet or other network interface.
Being able to access the audit trail and other functions of the SystemConsoleSwitch through the network connection is most convenient, whenever the network is up and running. When the network is unavailable, for whatever reason, the contingency solutions are that the SystemConsoleSwitch audit trail and all attached devices can be remotely accessed directly through the SystemConsoleSwitch modem port, OR by connecting the SystemConsoleSwitch terminal cable to a local dumb terminal. In this instance, the sys/admin has alternatives and is not captive to the network when there is a network problem, AND he has maximum convenience when all is well with the network. The key to maximizing the benefits of the SystemConsoleSwitch is to understand the contingency aspects of the product in a typical application.
Accessing Terminal Ports through the Network, SystemConsoleSwitch vs. Terminal Servers
Terminal Servers:
Terminal servers are devices which permit access to serial devices (TTY ports) through a direct network connection. A client will access the terminal server and instruct it to access a particular port, which is connected to a file server or other such device. This is a very easy way to telnet to a desired serial port. There are looming problems with this method, however.
If a server has crashed, the system logs cannot be accessed even if you can get to its serial port. There is no audit trail in a terminal server, so the sys/admin is "blind" to the root cause. The SystemConsoleSwitch retains the most recent 30-50 screens (32K) of information for the troubled device, showing panics and other important messages, enabling faster decisions to be made regarding corrective action.
If the attached devices happen to be Suns, they could all be in peril if the terminal server fails or looses power. Terminal servers are notorious for sending garbage data out as they fail. This may be interpreted by the Suns as a "break" or halt command. The SystemConsoleSwitch will NOT send any signal to attached servers if it fails.
SystemConsoleSwitch:
The SystemConsoleSwitch attaches to a network through the serial port of a device which is already on the network. This could be a Sun or other computer, or even a terminal server. In this way, the SystemConsoleSwitch is "indirectly" connected to the network. By the way, if a terminal server crashes while attached to a SystemConsoleSwitch, the servers and devices connected to the SystemConsoleSwitch will not be affected. If the terminal server puts out "garbage," the attached Suns will not see it because the SystemConsoleSwitch will be in monitor mode.
SystemConsoleSwitch vs. Terminal Server
Item
Captive to Network
Telnet Access
Audit Trail
Passes Intended Break
Passes Unintended Break
Single Point of Failure
Modem Access
| Terminal Server
Yes
Yes
No
Yes
Yes
Yes
No | SystemConsoleSwitch
No
Yes
Yes
Yes
No
No
Yes |
Q. How can you send a break (L1-A) remotely?
A. Administrating a system remotely can be done for a workstation booted off its serial port A or port B. This can be done with direct connections (dumb terminal or SPARCstation) or indirectly using telnet. In the latter case, a serial connection from A or B must be made to a Network Terminal Server or Concentrator. (Telnetting to a pseudo-tty will not allow sending a break signal as it is not a console device.)
1) Using telnet:
Telnet to host and log in.
To get to the 'telnet>'prompt press:
(ctrl)-]
Then type:
send brk
or
send break (depending on terminal concentrator requirements)
2) Using a direct connection to generate a BREAK signal on the line: Use either 'kermit'or 'tip'(in a shell tool) to connect to /dev/cua/a. The connection is made via a null-modem serial cable to the A or B port of the workstation to be administered.
If using 'tip', press (RETURN)(TILDE)(POUNDSIGN) (CR)~#
In 'kermit', the sequence is control-backslash-B
^\B
See also the OpenBoot Command Reference Manual - Appendix A, "setting Up a TIP Connection"
PRODUCT AREA: Gen. Network
PRODUCT: break
SUNOS RELEASE: any
SUN HARDWARE: any
Q. Using the remote break-in protocol, is there some kind of menu system that lets you break the connection? After you establish a new connection through the modem port, and then disconnect. Will this cause the Unix server to crash?
A: First, the server(s) will not crash. The break-in protocol is designed to be used in the event a SystemConsoleSwitch is left in direct mode at an unmanned site. You dial in, enter password, and have a brief dialogue with the switch. You will know the system is busy and ask if you want to break in, Y/N. If you say yes, it will return the switch to monitor mode and remote connects with you. If you say no to breaking in, the switch will indicate system busy and disconnect remote.
Q. How do you configure a SystemConsoleSwitch to an HP/9000?
A. 1. The terminal port on the SystemConsoleSwitch needs to be connected to a serial port on the HP/9000. Be sure to use a serial port designed to work with both modems and terminals as not all HP Serial MUX devices will work.
Serial MUX P/N J2085A from HP should work
Serial port on an HP/9000 Series 700 workstation does work
2. Add the following entry at the end of the file /etc/uucp/Devices:
Direct ttyIpP - 19200 direct
Where ttyIpP coresponds to the device file for the serial port (I=Instance of the interface | P=Port). This information can be determined by using ioscan.
# ioscan -fnC tty
Sample output from ioscan:
Class H/W Path Driver S/W State H/W Type Description
tty 0 10/4/0 mux2 CLAIMED INTERFACE MUX
/dev/cua0p6 /dev/diag/tty0p4 /dev/tty0p14
/dev/cul0p6 /dev/diag/tty0p5 /dev/tty0p15
/dev/diag/mux0 /dev/diag/tty0p6 /dev/tty0p2
/dev/diag/tty0p0 /dev/diag/tty0p7 /dev/tty0p3
/dev/diag/tty0p1 /dev/diag/tty0p8 /dev/tty0p4
/dev/diag/tty0p10 /dev/diag/tty0p9 /dev/tty0p5
/dev/diag/tty0p11 /dev/mux0 /dev/tty0p6
/dev/diag/tty0p12 /dev/tty0p0 /dev/tty0p7
/dev/diag/tty0p13 /dev/tty0p1 /dev/tty0p8
/dev/diag/tty0p14 /dev/tty0p10 /dev/tty0p9
/dev/diag/tty0p15 /dev/tty0p11 /dev/ttyd0p6
/dev/diag/tty0p2 /dev/tty0p12 /dev/wwvb1
/dev/diag/tty0p3 /dev/tty0p13
The column labeled I is the interface instance. The number at the end of /dev/tty0pNN is the port number.
This can be checked with the command lssf:
# lssf /dev/tty0p1
mux2 card instance 0 port 1 hardwired at address 10/4/0 /dev/tty0p1
3.Use cu to control the switch:
# cu -l/dev/ttyIpP -s19200
**Note: To exit cu enter ~..
Q. What prevents the Unix servers from crashing if the SystemConsoleSwitch fails?
A. As long as a physical connection is maintained between the server (or other device) and the SystemConsoleSwitch there will be no interruptions or crashes associated with a missing terminal connection in the event of power loss.
Q. Will the SystemConsoleSwitch work with any TTY connection, regardless of platform or device type?
A: Yes.
Q. Can you lock the SystemConsoleSwitch, with a password, so that no unauthorized users can hack at the console?
A: The SystemConsoleSwitch does have password protection when accessed via modem. Since it is an "out-of-band" device, it is co-located physically in the server room (assumed to be secure). If it is accessed via an external networked device, such as a computer or terminal server, the security hooks will be resident to that device.
Q: If someone forgets to log out of a Unix session from the SystemConsoleSwitch - can you program the SystemConsoleSwitch to terminate the session after a specified period of time?
A: The session will remain open until the switch is accessed and the direct mode is terminated intentionally.
PC ServerSwitch Plus
Q: Do you require special cabling?
A: NO. There is no proprietary cabling needed. Our box uses standard HD15 video, and 6 pin mini-din keyboard/mouse connections.
Q: How far can the monitor, keyboard and mouse be from switch?
A: You should really not go more than 25'. This is not a limitation of the switch, but rather a limitation of PS/2 interface. Several thousand feet can be attained with Lightwave's VDE/200 Extension Kit.
Q: Do you have to reboot every time you switch to another server?
A: No, there is constant keyboard emulation to all CPU's. Therefore, the switch constantly thinks there is a keyboard attached and active.
Q: How far can the switches be from each other when they are cascaded?
A: We use an RS-232 serial connection to cascade, so the distance can go up to 100'.
Q: Do you loose a port when you cascade?
A: No, on our PC ServerSwitch Plus, there is a separate port for cascading.
Q: What is the maximum resolution the switch can handle?
A: 1620 X 1280
Q. How is the switch controlled?
A. The PC ServerSwitch Plus can be controlled from the front panel buttons or by using the "hot keys" to activate the on screen menu.
Click here for a Free Serial / Console Management Switch Project Evaluation
