Remote Gear Support ..

prue at ISI.EDU prue at ISI.EDU
Wed Sep 2 21:35:26 UTC 1992

	From jwabik at Wed Sep  2 10:33:07 1992
	Subject: Remote Gear Support .. 
	To: regional-techs at

	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
	                 +--------+                 +-----------+
			 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.



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

More information about the NANOG mailing list