From jwabik@msc.edu Wed Sep 2 10:33:07 1992 Subject: Remote Gear Support .. To: regional-techs@merit.edu I've been poking around (thru the Black Box catalog, for example) for equipment to help us support our remote network gear located near the NSS to which we attach. I've had little success at finding the right pieces. I'm wondering if any of you have implemented any of these (listed below) solutions, and if so, where you found the equipment to do it; then subsequent sucess/failure information. Not in any particular order, here are the functions I'd like to be able to perform remotely.. This is a "grandiose wish list", as it were. * Software switchable dial-up access to serial ports on all gear (several ports): To Device 1 +-------------> |+------------> || To Device 2 Phone line +-------+ +---------+++ . -----------------| Modem |---| Magic Box | . +-------+ +-----------+ . || To Device (n-1) |+------------> +-------------> To Device (n) In this scenario, I dial into the modem to the "magic box", and give it some character code or sequence to attach me to the specified port. I can escape back to the magic-box and request subsequent connections without having to redial. [Black box has one of these for 4 ports, but I hear its not too good. Any experiences?] * Power Cycle any of "n" pieces of remote hardware via RS232 interface and ASCII selection. Ideally, this box attaches to one of the ports of the serial switch above, and asks me which piece of the "n" attached pieces of hardware should be cycled. [Black box has one of these for a single piece of equipment. It requires a dedicated phone line, and uses telco tones to trigger a cycle.] Los Nettos as built a remote access system much like you describe. We use a Newbridge 1080 8 port ASCII async switch, a 9600 bps modem and a Dataprobe K10-A power relay. The Newbridge switch has the ability to configure any or all of their ports as source ports or destination ports or both source and destination ports. A CSU/DSU console is a destination port, while a local console terminal may only be a source port. You configure the switch with port speeds and many other port characteristics. Both source and destination ports can have password protection by option. The device has up to 128 bytes of buffering and can do speed conversion with two types of flow control. It has several options for responding to and providing control leads. It also does data format conversion. It has other options I have not mentioned as well. If 8 ports are not enough one can connect two or more together. The best part is that we get the Newbridge 1080 switch for about $650 each. The switch is configured with lots of parameters for each port. This configuration is maintained during power outages. The Dataprobe K10-A we use is a modified unit from what they have in their catalogue. Our version kills the power to an AC plug if we raise a control lead. Power remains on if there is a low signal or no signal. We plug a power strip into the power relay, plug our router and all of the CSU/DSU's. We thus power cycle everything all at once. We plug a cable between the switch and the power relay. When we select the power relay port our equipment is powered down. Because the switch port fails a DTE-DCE control lead handshake the switch aborts the connection to the power relay device and power is restored automatically. I wanted to be able to power cycle things individually but the only thing I found was a device which is no longer manufactured. I think it was an X-10 or something like that. The Dataprobe K10-A's cost about $150 each. We use NEC 9631 modems which have worked reliably at 9600, even cross country. Two of our Los Nettos members have duplicated our Los Nettos Remote Console Access (RCK) systems for their own corporate networks. I use Cisco routers. I connect both the console port and the AUX port to the switch. In this way I can telnet to the Cisco AUX port and talk to the switch and the CSU/DSU's. I can even connect to the modem through this telnet connection and dial a remote location without leaving my workstation. You can't appreciate how much easier it is to get T1's repaired when you can see both CSU/DSUs on an sick line until you've done it a few times. You can tell the phone company real time which half of a line will test good through a double loop somewhere in the middle. With our CSU/DSUs we can send the phone company a quasi-random signal their test equipment can look at. Testing in this mode goes so much quicker. * T1 line switch: Incoming T1 +--------+ +-----------+ | |-----------------| CSU/DSU 1 |----> To router 1 -----------------| Switch | +-----------+ | |-----------------| CSU/DSU 2 |----> To router 2 +--------+ +-----------+ ^ | V RS232 Input Ideally, this box also attaches to one of the ports on the n-by serial switch above, and has some sort of menu or ASCII code line selection mechanism. Being a software guy, I thought about wiring this up using a switch for RS232 from Black Box.. Hardware people informed me that this wasn't a good idea. I believe that a T1 line switch violates the T1 tarifs. The first thing the T1 is suppose to see is a CSU to protect the network from the customer equipment. I would like to hear that I am wrong because I have wanted to do just the same thing on multiple occasions. Again, these are the thoughts on my mind... and an "ideal wish list". I'd appreciate hearing about any implementations or similar tools that you have experience with. Thanks! -Jeff Cisco AGS+ routers come with an environmental monitor card. This card tests the power and the temperature and puts constant updates out as ASCII async data. If we connected that to the switch we could remotely receive this data when we selected that switch port as well. What I would like is to have the protocol used on the CSU/DSU port be more computer friendly. With our Datatel CSU/DSUs it is diffucult to teach a computer program how to interpret the output display. The data is context and position dependent. The base display format is unknown but dependent on how it was left from last time. There is no way to force the console port into a base mode where one can know that sending certain inputs to the console port will deliver a specific output, or initiate a loop without looking at the console output for feedback each step of the way. I would like an interface that would be easy to do testing under program control with a minimum of code development. I think some new CSU/DSUs have or will have this in the future. Of course these are the most expensive models. Give me a call if you have any specific questions. Walt Prue Los Nettos 310-822-1511