Path: utzoo!attcan!uunet!lll-winken!ames!ucsd!rutgers!aramis.rutgers.edu!geneva.rutgers.edu!hedrick From: hedrick@geneva.rutgers.edu (Charles Hedrick) Newsgroups: comp.dcom.lans Subject: Re: Ethernet terminal servers Message-ID: Date: 17 Jan 89 01:43:01 GMT References: <6556@fluke.COM> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 31 We use cisco and Bridge terminal servers, with TCP/IP. Both allow connections incoming or outgoing. Incoming is used for driving printers or when you have a machine that doesn't support TCP/IP. In the latter case, you back up a group of terminal server ports to a group of serial lines from the machine, and configure the terminal server to front for the machine. You can set up a rotary so that one IP address gets you the first free line in the group. Both support modem control. cisco doesn't have enough lines coming out of their connectors to handle all of the modem control signals. However they have several combinations of signals that they support. One combination does do hardware flow control. I suggest contacting latzko@topaz.rutgers.edu for details on how our Telebits are set up. I think we are using hardware flow control, but wouldn't want to swear to it. Note that rutgers.edu, which is a major UUCP node, does all of its async traffic through a cisco terminal server. It has had reliability problems, but they have been due to the modems, not the terminal server. Both the cisco and the Bridge hardware have been reliable. In both cases we keep enough spares that we can afford to have a unit down. So we just send the unit or board back. A service contract doesn't seem worth it. cisco claims to have designed for one failure per 10 years. We certainly get better than a year MTBF, and I'm fairly sure it is more than 3 years. Some of our hardware folks might be able to calculate it more accurately. Certainly our modems are far more trouble than the boxes they are connected to. Somebody commented in a response about problems figuring out where a user is coming from. I believe Encore makes their TCP port number map to the line number, so finger or who could be modified to show the line number. cisco's servers respond to "finger" requests. However if several users are connected to the same machine, it may be hard to tell them apart.