hedrick@TOPAZ.RUTGERS.EDU.UUCP (11/27/86)
A message that just appeared on this list gave a reasonably complete
description of the Encore terminal server. Since we have used Bridge
CS-100's extensively, and are now using cisco ASM's, I thought it
might be helpful to give a description of them as well. I hope the
following review isn't too long to read, but it seemed worth trying to
give a good feel for the products. There are a number of similarities
in what these two products do. Both of them implement telnet using
special-purpose software (i.e. they do not run Unix or a Unix-like
shell). The user interfaces look like a typical DEC command scanner:
keywords which can be abbreviated, you can type ? at any point to see
what is wanted there. (With Bridge you have to hit carriage return
after the ?. Cisco activates immediately.) A number of the keywords
are even similar: connect, resume, disconnect, and show (though the
things that show will show are different). In both cases, you can
have multiple sessions active. You switch by typing an escape
character to get back to the terminal server, and then resuming the
session that you want to go back to. Because they implement telnet
and not rlogin, they are not as optimized for use with Unix as it
sounds like Encore is. However they do implement telnet sync, so
things are not as bad as they might be. The big problem with terminal
servers is that ^C ^O ^S and ^Q tend to have very long delays unless
you do something special. The difficulty is that in general there are
large buffers at both ends, and several packets can be "in flight".
So after you type ^S, ^C or ^O, you can still get several thousand
characters. Rlogin solves the problem by integrating control
character handling on the terminal server and the host. The host uses
TCP out of band messages to keep the terminal server apprised of what
mode the tty is supposed to be in. Thus the terminal server handles
^S locally when appropriate. But when you are in Emacs, the host
tells it not to do ^S, and so that character works as the search
command. ^C and ^O are handled by cooperation between the server and
host. These features give rlogin a big advantage over a naive telnet
implementation. However it turns out that if you are careful, it is
possible to do nearly as well using telnet. The telnet protocol
includes the same out of band features as rlogin for implementing ^C
and ^O. It's just that most hosts and telnets don't bother to
implement these features. (In particular, 4.2 telnet and telnetd do
not.) Both Bridge and Cisco implement them in the terminal server.
So one need only repair the telnetd on your host. We have done this
on our primary timesharing machines. (Pyramid 90x systems. Alas, our
code may not be easy to import, since our telnetd is in the kernel,
for performance reasons.) This leaves ^S. It would be possible to
use telnet negotations to turn on and off local ^S handling.
Unfortunately, no one seems to have defined such a negotiation. Thus
we simply pick a character that is not used by Emacs for anything very
important (by default ^\ is used), and set up our terminal servers to
use that as a local XOFF. The same character is set as XON. I.e. it
is a toggle. [An editorial comment: Why did Berkeley define a new
proocol, rlogin, rather than simply implementing telnet fully, and
adding a negotiation to handle toggling XOFF.]
Enough of generic descriptions. Now down to details. I'll start with
Bridge, because that is what we have had for the longest. Bridge has
at least 3 different terminal servers: CS-1, CS-100, and CS-200. They
have different numbers of ports: 32 for the CS-1 (I have heard rumors
that they may allow more now), 14 for the CS-100, and some smaller
number for the CS-200. The CS-100 is the only one that I know, though
I think the CS-200 might be more attractive for a new installation.
The CS-100 uses several 68000's to get enough bandwidth to drive all
of the lines at full speed. It boots from a floppy (although it is
also possible to get diskless machines, which boot over the network
from a special server CS-100. This would be a nice idea for any
installation that intends to have a number of boxes. The server can
also be used to help monitor the network, and to diagnose problems.)
Major networking parameters are set via a sysgen, which must be done
standalone (i.e. the system is not in normal operation). This allows
you to set the network addresses, subnet masks, and servers used for
various purposes. The system uses IEN116 for name service. (This is
an older name server standard. There are Unix implementations
available.) You can use one or more of the boxes as name server --
they keep the name table on floppy, or set up one or more of your Unix
systems as a server. The terminal interface is highly configurable.
You can set up any characters to do character echoing, tailor the
prompts and greeting messges, etc. We set it up to have the same
control characters as TOPS-20 or VMS. It appears that they have
options oriented to half duplex, and every other conceivable kind of
terminal environment. Of course, you can choose parity, character
size, and all of that. The box is designed to allow you to support
machines that don't have their own TCP/IP implementations. You can
connect a group of ports from a CS-100 to ports on the host. You can
define those ports as a hunt group with its own Internet address.
Then anyone who telnets to that address will get the first free line
in the group. There is enough processing power in the box to be able
to handle 9600 baud output under normal circumstances. However the
CS-100 is short on memory, so certain combinations of uses can cause
trouble (e.g. if you are doing this, and using the same box to drive a
printer). I'll say a bit more about this below. The following
transcript will give you an idea of the configuration options, as well
as the available commands. (By the way, the mechanism that we used to
produce this transcript puts us into system manager mode from our
favorite Unix machine. We could do it to any box on the Internet,
without typing a password. Fortunately, it more than a simple telnet,
and the program does not appear to be widely distributed. There is
also a limit to the damage one could do, since serious configuration
changes have to be done with a sysgen.)
Remote: show parameters
...............................Global Parameters...............................
DATE = Thu Nov 27 05:52:54 1986
WelcomeString = "^G^J^MBridge CS/100, Rutgers LCSR Ethernet, Node Hill-SYS, Version 1.2000^J^M"
PROmpt = "Hill-Sys> " NMPrompt = "SYS> "
LocalPassWord = ... GlobalPassWord = ...
CONNectAudit = OFF ERRorAudit = ON
Remote: show allsessions [NB: It's before dawn on Thanksgiving Day]
Port/session# state Port/session# state
! 0 LISTEN ! 1 LISTEN
! 2 LISTEN ! 3 LISTEN
! 4 LISTEN ! 5 LISTEN
! 6 LISTEN ! 7 LISTEN
! 8 LISTEN ! 9 CONCTD with 128.006.005.107
!10 LISTEN !11 LISTEN
!12 LISTEN !13 LISTEN
Remote: show (!9) parameters
Parameters for PortId !9, current session
...................Port Transmission and VTP Characteristics...................
BUffersize = 82 DeVice = ( Terminal, Glass )
InterAction = ( Verbose, Echo, NoMacroEcho, BroadcastON, NoLFInsert )
InitMacro = "motd" MaxSessions = 6 PRIvilege = User
.........................Port Physical Characteristics.........................
BAud = 9600 BSPad = None CRPad = None FFPad = None
LFPad = None TabPad = None DataBits = 8 DUplex = Full
LinePRotocol = ASynchronous PARIty = None StopBits = 1
UseDCDout = ( AlwaysAssert, NoToggle ) UseDTRin = Ignore
.................Session Transmission and VTP Characteristics..................
BReakAction = ( InBand ) BReakChar = Disabled
DIsconnectAction = None DataForward = None ECHOData = OFF
ECHOMask = ( AlphaNum, CR, Term, Punct ) ECMChar = ^^
EOM = Disabled FlowControlFrom = Xon_Xoff
FlowControlTo = Xon_Xoff FlushVC = OFF IdleTimer = 2
LongBReakAction = IGnore LFInsertion = None MOde = Transparent
XOFF = ^\ XON = ^\
..................Sess
Remote: ?
BRoadcast ( <addr> ) <string>
Connect ( <addr> ) <address> [ ECM ]
DEFine <macro-name> = ( <text> )
DisConnect ( <addr> ) [<session number>]
DO <macro-name>
Echo <string>
Listen ( <addr> )
ReaD ( <addr> ) <option> <parameter>
ROtary !<rotary> [+|-]= !<portid>[-!<portid>] , ...
SAve ( <addr> ) <option> <filename>
SET <param-name> = <value> ...
SETDefault ( <addr> ) [<param-name> = <value>] ...
SHow ( <addr> ) <argument> ...
UNDefine <macro-name>
UNSave <filename>
ZeroStats
<BREAK> (to leave remote mode)
Remote: sho (!9) stat [This was done Thanksgiving day. Not very busy...]
PORT # 000.000.000.000 STATISTICS REPORT: -------------
DAILY-AVERAGE: CALL/D PKT/S BYTE/S ERROR/D
0 0 0 0
BUSIEST-MINUTE: CALL/M PKT/S BYTE/S ERROR/M
0 0 0 0
BUSIEST-SAMPLE: MAX#SN PKT/S BYTE/S ERROR
1 0 0 0
HOUR CALL/H PKT/S BYTE/S ERR/H HOUR CALL/H PKT/S BYTE/S ERR/H
0 0 0 0 0 1 0 0 0 0
2 0 0 0 0 3 0 0 0 0
4 0 0 0 0 5 0 0 0 0
6 0 0 0 0 7 0 0 0 0
8 0 0 0 0 9 0 0 0 0
10 0 0 0 0 11 0 0 0 0
12 0 0 0 0 13 0 0 0 0
14 0 0 0 0 15 0 0 0 0
16 0 0 0 0 17 0 0 0 0
18 0 0 0 0 19 0 0 0 0
20 0 0 0 0 21 0 0 0 0
22 0 0 0 0 23 0 0 0 0
Remote: sho ?
SHow ADDRess
SHow AllSessions [ p ]
SHow CONFigurationS [<filename>]
SHow ( <addr> ) DefaultParameters [<param-name> ...]
SHow GLobalParameters
SHow InternetPorts
SHow InternetServers
SHow MACros [<macro-name>]
SHow NAmes [<host name>]
SHow NetMAP
SHow ( <addr> ) PARAmeterS [<param-name> ...]
SHow <param-name> ...
SHow ROtaries
SHow ( <addr> ) SESsions [ P ]
SHow ( <addr> ) STATisticS [ Sample | Min | <hour> | Day ]
SHow VERSion
SHow VirtualPorts
<BREAK> (to leave remote mode)
Remote: ^C
The CS-100's are reasonably reliable when used as simple terminal
servers. However from time to time we have run into glitches in their
TCP, which make us wary of using it for anything unusual. For
example, at one point we ran a printer off a line on a CS-100. The
host would connect to that port in order to access the printer. The
box where we did this always seemed to crash more often than others.
Also, if there were problems, we had to reboot the box. Apparently,
they did not implement RST in TCP. If the host crashed, this could
lead the CS-100 to keep trying to send a character to a connection
that no longer existed. It would ignore the RST that was sent to tell
it to desist. At times, the rate of retry could be high enough to
noticably affect the performance of the machine being attacked.
Historically, we have had fairly long delays in getting TCP problems
of this sort fixed. TCP/IP was clearly a lower priority with them
than XNS. However over the last few months, they have apparently
raised the priority of TCP/IP, and we are now getting fixes to long-
standing problems. Whether the particular problem I just described
is now fixed, I don't know. The most serious problem is that the
boxes are short of memory.
- There is a limit to the number of sessions you can have active
at once. If you use all 14 ports on a CS-100, there are
only 4 extra sessions. I.e. 4 people can have two sessions,
or one person can have 4, but that's all.
- The TCP buffers are small. The packet sizes tend to be very
small. (I just telnetted to one, and got a send window
of 102.) This can increase the CPU overhead on the host
and the network traffic when doing such things as Emacs
screen refreshes.
This is a known problem, and may not be present with all of the models,
or even on newer CS-100's. So you should check with your salesman
to find out the current limits.
Note that Bridge has a large line of TCP/IP products. I don't know
the current product list, but it includes gateways of various sorts,
and I think also a box that can handle 3270's.
=============
The cisco ASM is one of a set of products that use the same chassis.
It is a standard Multibus backplane, into which various boards can be
inserted. Unlike Bridge, they don't actually have a finite set of
products. They have these things with product numbers, like ASM-32/S.
But in fact all they are is a certain set of boards plugged into the
box. You can add boards and produce objects that are a combination of
different announced products. (E.g. if you add a second Ethernet card
to a terminal server, you have a thing that works as both a terminal
server and a gateway.) There is a single CPU, a 68000 on a cisco
version of the SUN card. (No connection with Sun Microsystems. Sun
was one of several people who licensed the original SUN design from
Stanford. Cisco's card is most similar to the Forward Technology SUN
board.) The board has plenty of memory. (1MB, which is loads of
memory for this application.) Terminals are connected to terminal
interface cards that handle 16 ports. The 3Com Ethernet card is
currently used. Cisco supports up to 80 terminals on one box.
However if they are all active at once, there will not be enough CPU
power in the 68000. This would be used if you had lots of offices,
but you knew that not everybody was logged in at once. Cisco claims
that 32 ports can be in use at once with no problem. We have a number
of 32-port boxes, and have never seen any slowdowns. I think we are
probably going to start adding port cards so that we have 48-port
boxes. They have a packaging problem with all of these ports. How do
you put 80 RS232 connectors on the back of a box? Obviously, you
don't. Their preferred configuration uses 50-wire phone company
cables. They have the standard phone company connectors on the back
of the boxes. We run the cables to a board on the wall, where we fan
the wires out to phone company punch blocks. Other wires are then run
out to the terminals. We can then cross patch any terminal to any
port. This is certainly the best way to handle large installations.
It results in compact connectors and fewer cables. However if you
prefer RS232 connectors, they will put up to 32 on the back of their
box. I think they also have a kludge for putting extra ones near the
box, connected by ribbon cable. The boxes normally have their code in
ROM, though there are provisions to load it using TFTP from any host
system that supports that. (Cisco sends out new code by giving us new
ROM's.) When a machine comes up, it needs two services from some
server: (1) It has to find its Internet address. It sends out both
RARP and bootp requests. Bootp servers are available for 4.3. We
also run it on 4.2, but I think it needs one extra ioctl. RARP is
also widely available. However before buying one of these boxes, you
should verify that you can run one or the other of these. (2) It
attempts to load a configuration file using TFTP. This contains
information such as terminal speeds, host name, greeting message,
routing tables, etc. TFTP servers are widely available, and should
run on just about any system that supports TCP/IP. Host name can be
handled via either IEN116 (an older TCP/IP name server protocol), or a
domain server. It will broadcast, or you can give it a list of
servers to use.
System administration can be done using any terminal or an incoming
telnet connection. Simply enable (which requires a password). It
is possible to type any of the commands interactively that go in the
configuration file, though it would be more likely to update the
configuration file and request that it be reloaded. (This will not
disturb other users, as they won't change parameters of terminals
that are currently in use.) One slight security problem: the password
is defined in the configuration file. Most versions of TFTP will only
access files that are protected so that everyone can read them. This
means that some machine on your network will have the password in a
file that is readable by the world. (We have altered TFTP to allow
us to protect the file. It uses a slightly nonstandard interpretation
of .rhosts to let us limit access to just cisco terminal servers.)
The command language looks like a typical DEC command scanner. It's
modelled after TOPS-20, but would look familiar to any VMS user, and
indeed to most Unix users. It responds to rubout or backspace, ^U or
^X, ^W [word delete], and ^R [retype line]. If you just type a host
name, it will connect. We have not seen any limit to the number of
connections you can have active at once. The example below will give
a feeling for the commands and options available. (It was obtained by
a normal telnet connection.) One of the strong points of the system
is that they try to let you see as many internal tables and parameters
as possible. This can be very useful in debugging situations. Note
that no ? help is available for the configuration commands. However
the results of the "show" commands will give a good feeling for the
sorts of options that can be set. There are not quite as many
terminal options as with Bridge. In particular
- I don't think any attempt is made to handle half-duplex terminals
- You can't change the editing characters (backspace/rubout, etc)
- No padding is supported. (The host system is assumed to do that.)
However there are more network configuration options. There is also
access control. You can control incoming or outgoing connections on
any port. Access control lists can contain wildcards. You can also
use this mechanism in their gateways to control which hosts access a
given network. (We use it for Arpanet access control. If you list
individual hosts, a hash table is used, so it should not cause a
performance problem. A list with several wildcards might not be quite
so fast.) Cisco appears to have implemented the IEEE 802.whatever
encapsulation. In addition to the usual Ethernet encapsulation using
ARP's, they support two versions of IEEE/ISO encapsulation, one which
follows the newest proposed method, and the other which seems to be
peculiar to H-P.
Connected to hilltop.rutgers.edu.
Escape character is '^]'.
cisco ASM-32, Rutgers LCSR Computer Science Network, Node Hilltop.
Please type name of machine you wish to connect to, followed by a <CR>.
hilltop>enable
Password:
hilltop#?
banner Change message of the day banner
clear Reinitialization functions, type "clear ?" for list
configure Configure from terminal or over network
connect <host> Connect to host - same as typing just a host name
disconnect <cn> Break the connection specified by name or number
disable Turn off privileged commands
enable Turn on privileged commands
exit, quit Exit from the EXEC
name-connection Give a connection a logical name
ping Send ICMP Echo message
reload Halt and reload system
resume Make the named connection be current
send <line>|* Send message to a terminal line or lines
set <option> Set an option, type "set ?" for list
show <cmd> Information commands, type "show ?" for list
systat Show terminal lines and users
terminal Change terminal's hardware parameters, type "terminal ?"
unset <option> Clear an option, type "unset ?" for list
where Show open connections
<cr> To resume connection
hilltop#set ?
download.mode Optimize settings for using Kermit, etc.
egp-tracing Detailed printout of EGP transactions
escape <ch> Local escape character
event-watching Display special gateway events
gateway Gateway processing activity
hold <ch> Local hold character
imp-loopback Put any ARPA-1822 interfaces into self loopback
line-debugging Helpful debugging printout for RS232 lines
notify Notification of data pending on idle connections
tcp-debugging Debugging printout for TCP connections
tracing Print datagram routing information
hilltop#sho ?
access-lists Access control lists
arp ARP cache
buffers Network buffer utilization
controllers Serial network interface statistics
egp EGP neighbors
hardware Hardware configuration
hosts Host/address cache
imp-hosts Active IMP hosts
interfaces Network interface statistics
line <line> Line information, may specify a line
memory Memory utilization statistics
options Options configured via "set" and "unset"
printers Parallel printer status
processes Active system proceses
redirects ICMP redirect cache
routes Network routing table
stacks Process and interrupt stack use
terminal Terminal parameters
tcp <line> TCP information, may specify a line
traffic Network protocol statistics
users Summary of active lines and connections
hilltop#term ?
databits 5|6|7|8
flowcontrol none|hardware|software [in|out]
length <length>
parity none|even|odd|space|mark
speed 300|1200|2400|4800|9600|19200
start-character <decimal-number>
stop-character <decimal-number>
stopbits 1|2
terminal-type <string>
hilltop#sh line 14
Tty Typ Tx/Rx A Mode Status Capab Roty AccO AccI Uses Noise
* 14 TTY 1200/1200 L modem 100448 1100 - 1 - 139 79
Location: "Dialup x2970", Type: "", Length: 24 lines
TX/RX speeds are 1200/1200, 8 databits, 1 stopbits, no parity
No flowcontrol in effect.
Status currently=0x100448, default=0x100020, permanent=0x40
Capability currently=0x1100, default=0x1100, permanent=0x0
Idle EXEC timeout is 5 minutes.
Idle session timeout is 120 minutes.
Escape character is ^^ (30), default is ^^ (30)
Hold character is ^\ (28), default is ^\ (28)
Disconnect character is not set
Activation character is ^M (13)
hilltop#systat
TTY Host(s) Location
tty14 H008-19 Dialup x2970
tty22 TOPAZ Dialup x2976
tty34 TOPAZ Dialup x2954
*vty41 idle TOPAZ
vty42 idle 192.12.88.3
hilltop#sho traffic
IP statistics:
Rcvd: 3075505 total, 23 format errors, 79 checksum errors, 0 bad hop count
0 unknown protocol, 2998056 local destination, 77347 not a gateway
Frags: 0 reassembled, 0 timeouts, 0 fragmented, 0 couldn't fragment
Bcast: 974 received, 4 sent
Sent: 0 forwarded, 2395890 generated, 64 encapsulation failed, 0 no route
ICMP statistics:
Rcvd: 1 checksum errors, 85 redirects, 46 unreachable, 342 echo
0 echo reply, 35 mask requests, 20 mask replies, 0 other
Sent: 0 redirects, 0 unreachable, 0 echo, 342 echo reply
1 mask requests, 0 mask replies
UDP statistics:
Rcvd: 1526 total, 0 checksum errors, 1131 no port
Sent: 1653 total, 0 forwarded broadcasts
TCP statistics:
Rcvd: 2996037 total, 471 checksum errors, 716 no port
Sent: 2394255 total
--More--
ARP statistics:
Rcvd: 47699 requests, 1177 replies, 78 reverse, 69 other
Sent: 289 requests, 533 replies (0 proxy), 1 reverse
Xerox ARP statistics:
Rcvd: 0 requests, 0 replies
Sent: 0 requests, 0 replies
Probe statistics:
Rcvd: 16217 address requests, 81 address replies, 0 other
Sent: 289 address requests, 4 address replies (0 proxy)
hilltop#sho interface
Ethernet #0 is up, hardware address 0260.8C02.5606, IP address 128.6.4.56
MTU is 1504 bytes, encapsulation is ARPA, no access checking
Address determined by Reverse ARP from host 128.6.4.194
Time since last input is 0:00:00.000
Time since last successful output is 0:00:00.016
No output failure has occurred
3601442 input, 4119 with errors, 541 no input buffers
2401375 output, 3443 with errors, 0 congestion drops
202 resets, 0 runts rcvd, 0 giants rcvd
hilltop#sho ?
access-lists Access control lists
arp ARP cache
buffers Network buffer utilization
controllers Serial network interface statistics
egp EGP neighbors
hardware Hardware configuration
hosts Host/address cache
imp-hosts Active IMP hosts
interfaces Network interface statistics
line <line> Line information, may specify a line
memory Memory utilization statistics
options Options configured via "set" and "unset"
printers Parallel printer status
processes Active system proceses
redirects ICMP redirect cache
routes Network routing table
stacks Process and interrupt stack use
terminal Terminal parameters
tcp <line> TCP information, may specify a line
traffic Network protocol statistics
users Summary of active lines and connections
hilltop#sho line
Tty Typ Tx/Rx A Mode Status Capab Roty AccO AccI Uses Noise
0 CTY - direct 40 0 - - - 1 1
1 TTY 4800/4800 - direct 400040 0 - 2 - 0 107
2 TTY 4800/4800 - direct 400040 0 - 2 - 70 2757
3 TTY 4800/4800 - direct 400040 0 - 2 - 83 147
4 TTY 4800/4800 - direct 400040 0 - 2 - 70 13
5 TTY 4800/4800 - direct 400040 0 - 2 - 33 46
6 TTY 4800/4800 - direct 400040 0 - 2 - 54 2036
7 TTY 4800/4800 - direct 400040 0 - 2 - 0 2322046
10 TTY 2400/2400 - direct 40 0 - 1 - 39 8
11 TTY 2400/2400 - direct 400040 0 - 1 - 0 0
12 TTY 2400/2400 - direct 40 0 - 1 - 30 41
13 TTY 2400/2400 - direct 40 0 - 1 - 57 8
* 14 TTY 1200/1200 L modem 100448 1100 - 1 - 139 79
15 TTY 1200/1200 L modem 100020 1100 - 1 - 112 23
16 TTY 1200/1200 L modem 100020 1100 - 1 - 103 107
17 TTY 300/300 L modem 100020 1100 - 1 - 81 13
20 TTY 1200/1200 L modem 100020 1100 - 1 - 70 21
21 TTY 1200/1200 L modem 100020 1100 - 1 - 41 3
* 22 TTY 300/300 L modem 500600 1100 - 1 - 2 166
23 TTY 1200/1200 L modem 100020 1100 - 1 - 22 1
--More--
Tty Typ Tx/Rx A Mode Status Capab Roty AccO AccI Uses Noise
24 TTY 1200/1200 L modem 100020 1100 - 1 - 7 45
25 TTY 1200/1200 L modem 100020 1100 - 1 - 13 12
26 TTY 1200/1200 L modem 100020 1100 - 1 - 35 29
27 TTY 1200/1200 L modem 100020 1100 - 1 - 5 0
30 TTY 9600/9600 L modem 100020 1100 - 1 - 0 0
31 TTY 9600/9600 L modem 100020 1100 - 1 - 0 0
32 TTY 2400/2400 L modem 108000 1100 - 1 - 78 389
33 TTY 2400/2400 L modem 100020 1100 - 1 - 34 19
* 34 TTY 2400/2400 L modem 100448 1100 - - - 25 34
35 TTY 9600/9600 L modem 100020 1100 - 1 - 0 0
36 TTY 2400/2400 L modem 100020 1100 - 1 - 49 2258
37 TTY 2400/2400 L modem 100020 1100 - 1 - 9 0
40 TTY 9600/9600 L modem 100020 1100 - 1 - 0 0
* 41 VTY - virtual 120440 1 - 2 - 45 0
* 42 VTY - virtual 120440 0 - 2 - 3 0
43 VTY - virtual 120240 0 - 2 - 8 0
44 VTY - virtual 120020 0 - 2 - 0 0
45 VTY - virtual 120020 0 - 2 - 0 0
hilltop#quit
Connection closed by foreign host.
The primary issue with cisco is that they are a new and small company.
We have had problems show up, as you would expect with any new
product. They have all been fixed reasonably quickly. Simple coding
blunders are normally fixed within a couple of days. (I trust no one
expects a bug free product. We are not so concerned about finding
bugs in new products. We had at least as many bugs in the early days
of the CS-100's. We are more concerned with how hard it is to get
them fixed. As far as I know, there are no unfixed bugs at the moment
in the Cisco software.) Rutgers has, as usual, run into a few really
difficult problems. The most difficult ones turned out to be design
problems with two different boards used in the Arpanet gateway (both
from established vendors). The question that a few of us have is
whether they will be able to continue their good support when they
have hundreds of customers. The biggest problem we have with small
companies is that when they succeed, it is no longer practical for
everyone to talk to their wizards. Either they supply no support, or
they build up a large staff of turkeys to deal with the users. (We
have seen both strategies.) However we don't know of any more
established vendors that have really brilliant solutions to this
problem either. One of the stengths of the company is Len Bosack's
expertise in the area of TCP/IP and routing technology. The folks
at Bridge are certainly competent, but our evidence does not suggest
that they have anyone of his caliber. This shows up in how the
nooks and cranies of TCP are handled. (It is inconceivable that
cisco would put out a TCP that failed to implement RST.) It also
matters if you are thinking of building a large network, where
routing technology matters. (However Bridge has in the past tended
to license DEC's technology for routing. That is a perfectly
acceptable solution.)
In short, both Bridge and cisco make useful products. We think
cisco's software design is somewhat superior. But you have to balance
this against the dangers of dealing with a startup company, with
the details of what the particular products do and don't support,
and with the cost of the equipment needed for your particular
configuration. (E.g. the Bridge CS-200 would tend to be more
cost-effective for locations with very small numbers of terminals,
but in most situations, cisco would probably come out ahead.)