[comp.dcom.lans] Cisco terminal server

dyer@spdcc.COM (Steve Dyer) (06/05/89)

I'm considering buying a Cisco terminal server (actually a t-server/router)
to replace a SLIP line and hardwired dialins to a machine.  I'd like to know
whether people have had any success in using Cisco terminal servers for dialin
UUCP traffic.  I've used UUCP over Annex/rlogin tty lines for over a year
without any problems whatsoever.

I understand that the rlogin protocol isn't supposed to be transparent, but
it was literally never a problem in this particular installation.

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu

hedrick@geneva.rutgers.edu (Charles Hedrick) (06/05/89)

rutgers.edu is a major UUCP backbone node.  All of its dialup UUCP
traffic goes through cisco terminal servers.  At one point I
implemented a modification to uucpd that would allow you to connect
directly to it from the terminal server.  This would avoid having a
telnetd or rlogind sitting there copying characters.  I believe we got
this code working but I'm not sure we're using it very much.  telnetd
uses enough CPU time that I think you might want to consider this
approach if you expect to do a lot of traffic.  In order to get good
UUCP performance, you may want to use the "dispatch-timeout" parameter
so that you get reasonably full packets.  We use 8 for Trailblazers
and 35 for other modems.  If you are using telnet, you'll want to
configure "telnet-transparent" and probably "escape 0" (which makes
BREAK the escape character, rather than ^^ followed by x) for those
ports.  If you share the ports with normal dialins, you can have
people send "term download" as part of the login sequence.  This does
both telnet transparent and escape 0.  It is also the command to allow
xmodem to work over telnet connections.  That gives an 8-bit
transparent connection, if used with a BSD telnetd that doesn't have
the CRLF bug that was in early versions of 4.3.  (telnet-transparent
controls how CR is sent.  There are several reasonable interpretations
of the specs, so they let you control it.  I believe
telnet-transparent sends it as CR NUL, whereas the default is CR LF.
The problem with the default behavior is not the CR LF, which would be
OK, but the fact that they ignore any LF's typed in after a CR.)  I
assume rlogin would do the right thing as well, though you'd still
want to change the escape character I think.  

You indicate that you're going to run SLIP through this.  We use
cisco's for SLIP.  However there are some limitations, at least in
software release 7.1:

  - SLIP is not designed for use as a router.  That is, the system
	on the other end is assumed to be a single PC, not a gateway
	to another network.  There are several subtle things that
	this affects.

  - the MTU is 1500, and can't be changed.

  - at most 2 packets can be queued for output on any given line at a 
	time.	If this is exceeded, packets are dropped, without
	ICMP source quench.  This is reasonable for use in a PC
	environment, where you will set up a small window size anyway.

dyer@spdcc.COM (Steve Dyer) (06/05/89)

In article <Jun.4.21.28.05.1989.675@geneva.rutgers.edu> hedrick@geneva.rutgers.edu (Charles Hedrick) writes:
>You indicate that you're going to run SLIP through this.  We use
>cisco's for SLIP.  However there are some limitations, at least in
>software release 7.1:

I'm thinking of a new product which is supposed to be a combination
terminal server/router.  Hopefully their router would be using some
private synchronous serial protocol to talk with the Cisco on the
other end.  The box is going to replace my current setup which uses
SLIP.

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu

henry@utzoo.uucp (Henry Spencer) (06/05/89)

In article <3442@ursa-major.SPDCC.COM> dyer@ursa-major.SPDCC.COM (Steve Dyer) writes:
>I understand that the rlogin protocol isn't supposed to be transparent, but
>it was literally never a problem in this particular installation.

Transparency problems can be very data-specific.  Things go along fine with
normal traffic until some clever lad decides to use ~~~~~~~~~~~ as a divider
line in his mail, at which point the connection dies every time uucico tries
to transmit that line.  (The troublesome patterns vary, of course, depending
on what equipment and software is involved.)  Don't assume that you can get
away with it in future just because you got away with it in the past.
-- 
You *can* understand sendmail, |     Henry Spencer at U of Toronto Zoology
but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu

dyer@spdcc.COM (Steve Dyer) (06/06/89)

In article <1989Jun5.162118.10240@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>Transparency problems can be very data-specific. [...]Don't assume that you
>can get away with it in future just because you got away with it in the past.

Yeah, thanks for the sermon.

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu

henry@utzoo.uucp (Henry Spencer) (06/06/89)

In article <3449@ursa-major.SPDCC.COM> dyer@ursa-major.spdcc.COM (Steve Dyer) writes:
>>Transparency problems can be very data-specific. [...]Don't assume that you
>>can get away with it in future just because you got away with it in the past.
>
>Yeah, thanks for the sermon.

You're welcome.  No charge. :-)

Seriously, this is a real problem that I and others have encountered in
the field:  somebody tests his "transparent" channel with one or two
simple test files and assumes it works, and it does, until the right
data pattern comes along... at which time anything from a crash/reboot
to a hung channel occurs.  And occurs again.  And again.  And again.
It may sound so dumb that nobody would ever do it; not so.
-- 
You *can* understand sendmail, |     Henry Spencer at U of Toronto Zoology
but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu

ron@ron.rutgers.edu (Ron Natalie) (06/06/89)

All of our UUCP connections come in over CISCO terminal
servers.  We've been doing so for over a year with both
the trailblazers and the Vadic modems.  It works a whole
lot better than the Sun ALM card we were using before.
The only thing (you've probably noticed this if you are
using Annex servers already) is that some UUCP hosts
don't hang up the phone after the UUCP protocol ends.
Our host hangs up our end and that returns the user
to the terminal server prompt.  We just set the time
outs for people stairing at the prompt without being
connected very short on those lines.

-Ron