|
|
ARCHIVE: TCP-IP Distribution List - Archives (1990)
DOCUMENT: TCP-IP Distribution List for October 1990 (463 messages, 278793 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1990/10.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Mon, 1 Oct 90 14:55:35 CDT From: darrel beach <beach@ddnuvax.af.mil> To: tcp-ip@nic.ddn.mil Cc: beach@ddnuvax.af.mil Subject: TCP/IP for DEPCA boards
Another plea for info... Can anyone point me to drivers, software, vendors to let me run TCP/IP on PCs which have a DEPCA (Digitals Ethernet PC bus Adapter) cards. Packet drivers compatible with NCSA, KA9Q, or even a commercial package would be appreciated. Thanx in advance... Darrel Beach
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Mon, 1 Oct 90 15:34:00 EDT From: Tom Seto <Seto%UNCAMULT.bitnet@ugw.utcs.utoronto.ca> To: tcp-ip@NIC.DDN.MIL Subject: TCP/IP products
Hello. We are currently putting together a RFP to obtain more computing
power of the UNIX variety. While we were reviewing the various aspects
of the request, a question came up: Is there a measure for the
"Goodness" of a particular tcp/ip product, ie how well does it conform
to the standards, how well does it perform, etc? We have in the passed
tossed a package from one vendor and purchased one from another on our
VAX/VMS. The UNIX systems presumably comes with a tcp in the system,
but is there anyway to measure whether a vendor has done a particularly
good or bad job of it? I would also welcome comments regarding products
that are out there, especially products that come with a particular
brand of hardware.
Thanks for your time.
Tom Seto
Mgr, Data Comm
ACS
U of Calgary
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: 1 Oct 90 13:55:07 GMT From: mailrus!sharkey!cfctech!alexb@uunet.uu.net (Alex Beylin) To: tcp-ip@nic.ddn.mil Subject: SLIP, IP Routers and Named Pipes
A project have come up around here that require multiple PCs to get dial-in access to the TCP/IP network. One of the major requirements is support for Named Pipes down to the PC. Current plan is to use SLIP and a router with dial-in ports. Would someone care to recommend a PC package that would do good SLIP emulation and a router that would be suitable for this job? Comments, suggestions are most welcome. Thanks in advance, -- Alex Alex Beylin, Unix Specialist | +1 313 948-3386 alexb@cfctech.cfc.com | Chrysler Financial Corp. sharkey!cfctech!alexb | MIS, Distributed Systems ATT Mail ID: attmail!abeylin | Southfield, MI 48034
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: 1 Oct 90 15:19:10 GMT From: bu.edu!rpi!zaphod.mps.ohio-state.edu!mips!ultra!wayne@bloom-beacon.mit.edu (Wayne Hathaway) To: tcp-ip@nic.ddn.mil Subject: Re: Question on forwarding broadcasts
Thanks to all who responded to my "Question on forwarding broadcasts"
posting. Two quickies.
One, I apologize for over-simplifying the picture. In the real life
situation both hosts do in fact have other network connections, so
they really SHOULD be forwarding packets. If I had drawn a couple
more lines it would have been clearer.
But mostly, I should have read RFC 1009 more carefully, 'cause sure
enough, there it is right on page 36:
In general, a gateway must not forward a datagram which
arrives via local network broadcast, and must not send
an ICMP error message when dropping the datagram. A
discussion of the rules will be found in Appendix A;
see also [50].
(Interesting that this specific situation does NOT seem to be
mentioned anywhere in Appendix A, however!)
Now the only question is when the support for the above requirement
(that is, Data Link telling IP whether a packet arrived via broadcast
or multicast) will get out in the various host implementations. And
THAT is what I should/would have asked, if I had read RFC 1009 better!
Anyway, apologies for the wasted net bandwidth on red herrings. Now,
about the REAL question ... ?
Wayne Hathaway domain: wayne@Ultra.COM
Ultra Network Technologies uucp: ...!ames!ultra!wayne
101 Daggett Drive phone: 408-922-0100 x132
San Jose, CA 95134 direct: Hey, you!
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: Tue, 2 Oct 90 03:49:22 -0700 From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) To: tcp-ip@nic.ddn.mil Subject: Maintainability of TELNET Sessions Over Marginal Circuits
A site that I'm involved with has an interesting problem involving TELNET,
specifically, and TCP/IP, in general, over encrypted and/or marginal links.
I'm interested in comments from this group that might suggest a solution
to this problem.
For want of a better description, the organization of this network might
be described as a WAN. It consists of a number of LANS each of which has,
at least, one router with, at least, two direct links to other LANS. Each
of the links is encrypted. The purpose of multiple direct links is to pro-
vide redundant paths to a central system that provides a common database
and a common set of services for the workstations on each of the LANS.
When the user wishes to make use of the central system, the user establishes
a TELNET connection to the central system through a process that also provides
an emulation of a terminal supported by the central system.
They had expected the router on loss of a circuit (loss of crypto synch)
to switch over to an alternate circuit and maintain the TELNET connection.
When they brought up the first LAN, they encountered two problems--the link
was of poorer quality than they had thought and continually looses synch
and the router did not switch circuits as they thought it would. When the
TELNET connection is re-established, they are not reconnected to their pre-
vious session.
When crypto synchronization is lost, random data will appear on the circuit
until both crypto units detect the loss of synchronization and have re-synched.
The questions:
1. Do routers generally have the capability to re-route traffic over
an alternate circuit?
2. How robust is IP in dealing with corrupted data streams when crypto
synch is lost in the header? In the body?
3. How robust is TCP in dealing with corrupted data streams?
4. Would fudging IP, TCP, or TELNET timers by a "crypto resync constant"
alleviate problems?
Any comments would be appreciated.
Merton
,
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: 1 Oct 90 17:08:58 GMT From: kdb@macaw.intercon.com (Kurt Baumann) To: comp.protocols.appletalk,comp.protocols.tcp-ip,comp.dcom.lans Subject: Re: MAC MS-MAIL to SMTP gateway?
In article <546@fciva.FRANKLIN.COM>, dag@fciva.FRANKLIN.COM (Daniel A. Graifer) writes: > I thought the GatorMail products were software to run on the GatorBox. Am I > mistaken? Hard to believe that products designed for a GatorBox would run > on Kinetics-oops-Novell-oops-Shiva FastPath. I might be mistaken, but they do sell it as a seperate product. The last I knew it ran with any AppleTalk-IP gateway product. Course this might have changed as well. Anyone listening from Cayman, Brad? Kurt -- Kurt Baumann InterCon Systems Corporation 703.709.9890 Creators of fine TCP/IP products 703.709.9896 FAX for the Macintosh.
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 90 01:31:00 GMT From: adelphi!news@uunet.uu.net (News Feed) To: tcp-ip@nic.ddn.mil Subject: Re: Please boycott Xircom
In article <NELSON.90Sep28233146@image.clarkson.edu>, nelson@sun.soe.clarkson.edu (Russ Nelson) writes: > > [2] I have also been advised that, lacking copyright registration, all > that I could accomplish is to force you to stop distributing the driver, > which you have already agreed to do. > > -- > --russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667 > It's better to get mugged than to live a life of fear -- Freeman Dyson I myself hold 3 copyrights on software I developed for the printing industry dealing with CAM and I remember posing the following question to my lawyer: How long do I have to register my copyright, and when does the copyright take effect? According to him and the form TX as well as the related booklet on filing form TX from the Library of Congress, you have up to 2 years to file your copyright registration, and the code that comes off ones pen is copyright by him/her, as long as it is not a work for hire or contracted oherwise. The implied registration covers the period before registration. As a matter of fact my lawyer told me, and I did in all cases, to just file the docuemtation and a binary listing of the code, thus leaving the source to be considered "trade secret". He stated this gives better protection. My point is, why is the above listed driver not copyright in the same manner. I certainly am confused now. Can anyone state the facts? I hate to see people get burned like that.
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 90 01:41:47 GMT From: brooks@apple.com (Kevin Brooks) To: tcp-ip@nic.ddn.mil Subject: HP TCP/IP router/bridge?
Does anyone know of a bridge or router that will allow HP hosts running
TCP/IP which speak IEEE style packets (802.2 encapsulated) to
communicate with ethernet style IP implementations? Do most of the
router/bridge vendors support both IEEE and ethernet style IP packets?
Thanks in advance
Kevin
--
Kevin Brooks A/UX Specialist, Apple Computer
UUCP: {mtxinu,sun,nsc,voder}!apple!brooks
APPLELINK: AUX.DUDE@applelink.apple.com
Internet: brooks@apple.com
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 90 01:48:56 GMT From: news@ncsuvx.ncsu.edu (Shahrooz A Alavi) To: tcp-ip@nic.ddn.mil Subject: >>> Internetworking with TCP/IP book FOR SALE <<<
NEW "Internetworking with TCP/IP. Principles, Protocols and Arch." by D Comer [Prentice Hall] $35 (includes shipping) Send me an email with your daytime mailing address and I will send it to you UPS/COD. ----------------------------------------------------------- S. Alavi (919) 467-7909 ssa@eceugs.ece.ncsu.edu
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Tue, 02 Oct 90 09:21:09 -0400 From: H. Craig McKee <mckee@chance.mitre.org> To: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) Cc: tcp-ip@nic.ddn.mil Subject: Re: Maintainability of TELNET Sessions Over Marginal Circuits
>When they brought up the first LAN ... the link was of poorer quality >than they had thought and continually looses [crypto] synch .... Is the link protocol synchronous (eg, HDLC) or asynchronous (start/ stop bits)? My experience with synchronous links is that a crypto like the KG-84 rarely looses synch (because modem clock recovery circuits are generally very good). For some cryptos there is a mode of operation called CTAC that is self-synchronizing; it does not require loss-of- synch logic in another box. The site can get expert advice from their cryptologic support center or the National Security Agency. >2. How robust is IP in dealing with corrupted data streams when crypto > synch is lost in the header? In the body? >3. How robust is TCP in dealing with corrupted data streams? Corrupted data will be detected and discarded by error detection logic at the link, IP, and TCP layers. >4. Would fudging IP, TCP, or TELNET timers by a "crypto resync constant" > alleviate problems? Give it a try; it's not a good hack, but I've done some bizarre things when trying to get a circuit up. Regards - Craig
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: Tue, 2 Oct 90 11:39:51 -0500 From: jbvb@ftp.com (James B. Van Bokkelen) To: darrel beach <beach@ddnuvax.af.mil> Cc: tcp-ip@nic.ddn.mil Subject: Re: TCP/IP for DEPCA boards
I'm posting to the list because this question gets asked awfully frequently: DEC's PCSA and DECNet/DOS products currently use a hardware-independent interface-sharing driver spec called "DLL". It is documented in the VaxMate Tech Ref. DEC supplies DLL drivers for various interfaces (theirs and 3Com's, I think) with PCSA and DECNet/DOS, and a number of other board vendors (e.g. Western Digital, Interlan that I know of) also offer DLL drivers for their own boards. FTP's PC/TCP (part PC-223) and Wollongong's WIN/PC can use DLL drivers. In addition, DEC has or will soon release an NDIS driver for the DEPCA. If you have this, you can use it with our freeware NDIS to Packet Driver adapter module (in pub/packet.driver/NDIS on vax.ftp.com, I won't mail it to you) and any of the TCP/IPs that support the Packet Driver (PC/TCP, WIN/PC, BWTCP, PCIP, KA9Q, NCSA, CUTCP, PCRoute, etc.). James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 90 05:22:52 GMT From: swrinde!zaphod.mps.ohio-state.edu!rpi!clarkson!news.clarkson.edu!nelson@ucsd.edu (Russ Nelson) To: tcp-ip@nic.ddn.mil Subject: Re: TCP/IP for DEPCA boards
In article <CMM.0.88.654810935.beach@ddnuvax.af.mil> beach@DDNUVAX.AF.MIL (darrel beach) writes:
Can anyone point me to drivers, software, vendors to let me run
TCP/IP on PCs which have a DEPCA (Digitals Ethernet PC bus Adapter)
cards. Packet drivers compatible with NCSA, KA9Q, or even a commercial
package would be appreciated.
Not yet, but the picture is coming into focus. We've gone from
"Digital refuses to release programming information" (that was just a
rumor) to "How may I help get you the information you need to write a
packet driver?"
Maybe in a couple of months...
--
--russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667
It's better to get mugged than to live a life of fear -- Freeman Dyson
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Tue, 2 Oct 90 15:23:14 MDT From: <wbaggett@NMSU.Edu> To: tcp-ip@sri-nic.arpa
subscribe Tim Baggett
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 90 12:23:34 GMT From: ingr!b11!usenet@uunet.uu.net (Usenet Network) To: tcp-ip@nic.ddn.mil Subject: Re: SLIP, IP Routers and Named Pipes
in article <1990Oct1.135507.27559@cfctech.cfc.com>, alexb@cfctech.cfc.com (Alex Beylin) says:
>
> Would someone care to recommend a PC package that would do good
> SLIP emulation and a router that would be suitable for this job?
---
The company I work for sells PC/NFS. I do not have experiance with
the product over serial lines, but PC/NFS (from Sun) does support SLIP.
SUN US SALES is listed as:
1-800-821-4643
For routers see cisco or there are terminal servers that support SLIP.
I worked for an outfit that sold cisco and the company I work for now
sells the Encore Annex II.
cisco
415-326-1941
encore (terminal server with slip)
617-460-0500
NOTE: I am not endorsing these products, but they are worth investigation.
--
* John E. Allen - Intergraph Corporation - (205) 730-8627 *
* System Sales Support *
* ingr!b23b!allen!jallen@uunet.uu.net *
**************************************************************
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 90 13:28:35 GMT From: sdd.hp.com!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!rphroy!cfctech!sharkey!fmsrl7!slee01!hugh@ucsd.edu (Hugh Fader) To: tcp-ip@nic.ddn.mil Subject: Is there a program like telnet, but driven by a script?
I need to duplicate UNIX-to-UNIX rsh functionality going UNIX-to-VMS. I am running a Sun Sparcstation and can communicate with the VAX using telnet and ftp via an ULTRIX gateway (the VAX only runs DECNET). One solution to my problem would be a telnet-like program which accepts a script containing expect/send pairs much like UUCP and some PC communications programs. Does such a program exist? I would also appreciate any suggestions of alternate solutions. Thanks in advance. -- Hugh Fader hugh@slee01.srl.ford.com
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 90 14:20:36 GMT From: pacbell.com!pacbell!varian!vaxwaller!phil@ucsd.edu (Phil Newton) To: tcp-ip@nic.ddn.mil Subject: HOW CAN I GET ON THE INTERNET???
I am interested in finding out HOW to gain access to the Internet.
Would anyone out there who knows how to so this please let me know, too?
Thanks in advance for your assistance!
--
Philip T. Newton (415)945-2272
Varian Instruments 2700 Mitchell Drive Walnut Creek, CA. 94598
{zehntel,pacbell,lll-winken}!varian!phil
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 90 17:51:49 GMT From: prang!marciano@lll-winken.llnl.gov (marciano pitargue) To: tcp-ip@nic.ddn.mil Subject: Re: SNMP comparison
>Something? Vitalink ( I think it's a repackaged HP product ) ... >-- >Per Andersson (perand@admin.kth.se, perand@stacken.kth.se) >Trying a new job at Bofors Electronics, >still reading news at the Royal Institute of Technology >Time, got the time tick tick tickin' in my head - Joe Jackson it's called the Wan Manager. it's is _not_ a repackaged HP product. /marciano marciano@vitalink.com vitam6!marciano@uunet.uu.net ...uunet!!vitam6!marciano disclaimer: noun. 1. a denial or disavowal of legal claim: relinquishment of or formal refusal to accept an interest or estate. 2. a writing that embodies a legal disclaimer.
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 90 18:25:41 GMT From: HANK@TAUNIVM.BITNET (Hank Nussbacher) To: comp.protocols.tcp-ip Subject: Router scorecard V1.6
CAVEATS
-------
The following scorecard tries to compare various multi-protocol
routers. The current scorecard mainly contains information for
cisco and Wellfleet but any other vendor is welcome to send me a
complete set of manuals for their equipment so that I can analyze
and update the scorecard.
The fact of the matter is that certain features and "gotchas"
only appear when testing the actual equipment. I hope that the user
population of multi-protocol routers will assist me in making this
scorecard as comprehensive as possible so that people who follow do
not have to go through what I have gone through.
It was difficult to decide whether to include future release
notes in this scorecard. I trust the user population in the
Internet to take each promise for a "future feature" with a grain of
salt and to keep watch on the vendors that indeed they follow
through with their promises. All too often vendors state certain
features will be available in a certain release and sometimes their
deadlines slip. It is advised that people should not base their
decisions on the future release notes. [That was a long caveat].
If you have comments, suggestions, additions, or subtractions
or corrections, please send them to:
HANK@VM.TAU.AC.IL or HANK@TAUNIVM.BITNET (but not to both!)
The scorecard will be updated on a monthly basis. This report
may be freely reproduced as long as nothing is altered or removed.
If you read this report and are not connected to the Internet,
you can send your comments to:
Hank Nussbacher
Computer Center
Tel Aviv University
Ramat Aviv
Israel
[The above employer has nothing to do with this scorecard so if
something bothers you about it, I take full responsibility.]
END OF CAVEATS
--------------------------------------------------------------------
V1.6 update: Various vendors have been in contact with me but after
expressing interest in having an entry for their machine they disappear.
Other vendors have tried to change the particular hardware box that
is being compared to another box. I hope that vendors will participate
in keeping this scorecard up-to-date.
--------------------------------------------------------------------
Distribution:
cisco@spot.colorado.edu
wellfleet@nstn.ns.ca
tcpip@nic.ddn.mil
ripe@mcsun.eu.net
p4200@devvax.tn.cornell.edu
Usenet: comp.dcom.lans
--------------------------------------------------------------------
Comparison of Multiprotocol Routers
Henry Nussbacher
October 1990
Version 1.6
+--------------+--------------+---------------+
Multiprotocol | cisco AGS+ | Wellfleet LN | Proteon p4200 |
Router | Rel. 8.1(14) | Rel. 5.35 | |
+--------------+--------------+---------------+
1. General | | | |
- # of slots | 9 | 4 | 7 |
- Processor | 68020 | 68020 | 68020 |
- Memory | 4Mbyte | 4Mbyte | 2Mbyte |
- Updates via | ROM, TFTP | diskette,TFTP| diskette,TFTP |
- Speed of bus | 530Mb/sec (a)| 320Mb/sec | |
- Boot from | | | |
- ROM | Yes | No | No |
- Net-boot | | | |
- IP | Yes | No | Yes |
- Decnet (MOP) | No | No | No |
- Diskette | No | Yes | No |
- Another router | Yes | No | No |
- Volatile changes | Yes (b) | No | Yes (h) |
- CPU statistics | Yes (c) | No | Yes |
- Memory stats | Yes | No | Yes |
- Ease of install | Very easy | menu driven | |
- Documentation | Difficult | Skimpy | Clear, orderly|
- Autorestart (d) | Yes | Yes | Yes |
- Restart for | | | |
config changes | No | Yes | Yes |
- Watchdog timer | Yes | | Yes |
- Reboot time (e) | 29 sec (f) | 60 sec | 32 sec (i) |
- Power-up time (g)| 29 sec | 120 sec | 32 sec (i) |
Notes:
a. Speed of old AGS bus is 160Mb.
b. Volatile changes represents the ability of the router to accept a
configuration change that is dynamic that only affects the current
running system and once the system is rebooted, the change
disappears.
c. CPU statistics refers to the ability of the router to provide
a monitoring facility to see what the CPU is doing and how often
it is doing it.
d. Autorestart in the event of a power failure.
e. Reboot time refers to the amount of elapsed time needed to
perform a logical restart (reboot) from the fastest available
media.
f. cisco timings are for older AGS system.
g. Power-up time refers to the amount of elapsed time needed from
the time of a power failure and recovery until the router is up and
operational.
h. Only available for DECnet and OSPF, and only for a subset of
available parameters.
i. Booting via Proteon's Intergrated Boot Device, with running
diagnostics.
2. Interfaces (a) | | | |
- Ethernet | | | |
(802.3 10Base5) | 24x10Mb | 8x10Mb | 7x10Mb |
- Thin Ethernet (b)| | | |
(802.3 10Base2) | No | 8x10Mb | No |
- 4Mb Token Ring | 3x4Mb (i) | 4x4Mb | 7x4Mb |
- 16Mb Token Ring | Rel 8.2 (j) | Rel 5.40 (c) | No |
- RS232 | 24x64kb | 16x64kb | 14x64kb |
- RS449 | 12x64kb | 16x64kb | 14x64kb |
- V.35 | 12x64kb | 16x64kb | 14x64kb |
- T1 | 12x1.544Mb | 8x1.544Mb | 14x1.544Mb |
- CEPT DS1 (2Mb) | 12x2Mb | 8x2Mb | 12x2Mb |
- FDDI | 2x100Mb | Rel 5.50 (d) | 2x100Mb |
- DAS (Dual) (e)| Yes | Yes | Yes |
- SAS (Single) | Yes | No | Yes |
- Ultranet | Rel 8.2 (k)| | |
- X.25 | | | |
- Max # of VCs | Unlimited (f)| 254 | 255 |
- Card types (g) | 6E, 1E2S, | 2E, 1E1S, | 1E, 2S, 4S, |
per slot | 2E2S, 4S, | 1E2S, 2E2S, | 1TR, .5F |
| 1TR, 1F (h)| 1TR2S, 4S, | |
| | 1TR | |
Notes:
a. Each interface subsection represents the maximum number of LANs
or WANS that can be configured for that particular subsection.
It is possible to "mix and match" various subsections by reducing
the upper limit.
b. Thin Ethernet refers to a standard BNC connector available directly
on the router.
c. 4x16Mb.
d. 1x100Mb.
e. Dual is also known as Type A and Single is also known as Type B.
f. Depends on memory limitations.
g. Card types: E: Ethernet, S: Serial/Synchronous line
TR: Token-Ring, F: FDDI
h. The 6E and 1F cards are for the faster cBus only.
i. The AGS can take 4 Token Rings while the AGS+ can only take 3.
j. To be supported in later release of Version 8.2.
k. Ultranet support will be in a later release of 8.2 but will
only support a 125Mb full-duplex connection to Ultranet's 1Gb LAN.
3. Interface part II | | | |
- Frame Relay (a) | Rel 8.2 | | |
- Ethernet | | | |
encapsulation | | | |
- Standard v2.0 | Yes | | Yes |
- IEEE 802.3 | Yes | | Yes |
- SNAP 802.2 | | | |
(RFC1042) | Yes | Yes | No |
- Serial | | | |
encapsulation | | | |
- HDLC | Yes | | Yes |
- LAPB | Yes | | No |
- PPP (RFC1134) | Yes | | |
- DDCMP | No | No | No |
- X.25 | Yes | | Yes |
- SVC | Yes | Yes | Yes |
- PVC | Yes | Yes | Yes |
- Encryption (b) | Pulse-time | | |
- Filtering by | | | |
source/dest | Yes | Yes | Yes |
Notes:
a. CCITT standards Q.931 (Frame Relay) and I.122 (Lap-D)
b. Encryption refers to the ability of the router to compensate for
encrypting devices on various interfaces or circuits.
c. For CLNP only.
4. IP | | | |
- Subnetting | | | |
(RFC950) | Yes | Yes | Yes |
- ARP (RFC826) | Yes | Yes | Yes |
- RARP (RFC903) | Yes | No | No |
- BOOTP (RFC951) | Yes | No | No |
- proxy ARP | | | |
(RFC1027) | Yes | Yes | Yes |
- ICMP | Yes | Yes | Yes |
- Name-server | Yes | No | No |
- Accounting | Yes | No | No |
- MTU | Yes | No | No |
- Security - IPSO | Yes | No | |
- Static routing | Yes | Yes | Yes |
- Source routing | Yes | No | Yes |
- Filters | | | |
- source/dest | Yes | Yes | Yes |
- TCP | Yes | | |
- UDP | Yes | | |
- ICMP | Yes | | |
- by protocol (b)| Yes (a) | Yes | |
- Routing protocols| | | |
- RIP (RFC1058) | Yes | Yes | Yes |
- EGP (RFC904) | Yes | Yes | Yes |
- BGP (RFC1105) | Yes | No | |
- Proprietary | IGRP | eRIP | No |
- Filtering | Yes | No | Yes |
- Default routes | Yes | Yes | Yes |
- OSPF | Rel 9.0 | Rel 5.6 | Yes |
Notes:
a. Can be done but is difficult and requires advanced knowledge of the
specific protocols.
b. Filtering by protocol can also be viewed as filtering by port
number.
5. DECNET | | | |
- Phase IV Router | Yes | Yes | Yes |
- Area Router | Yes | No | Yes |
- Phase IV+ (a) | Rel 8.2 | No | |
- Phase IV-V | | | |
Transitional gty | Rel 8.2 | | |
- Phase V | Yes (b) | No | Yes (b) |
- Address xlation | | | |
gateway (c) | Yes | No | No |
- NCP | | | |
- area-max-cost | Yes | Yes | Yes |
- area-max-hops | Yes | Yes | Yes |
- max-address | Yes | Yes | Yes |
- max-area | Yes | Yes | Yes |
- max-cost | Yes | Yes | Yes |
- max-hops | Yes | Yes | Yes |
- max-visits | Yes | Yes | Yes |
- router-priority| Yes | Yes | Yes (e) |
- hello-timer | Yes | Yes | Yes |
- routing-timer | Yes | Yes | Yes |
- Filtering | | | |
- source/dest | Yes | No | Yes |
- by protocol | No | No | No |
- by object | No | No | No |
- routing | Yes (d) | No | Yes (d) |
- MOP | Bridged | Bridged | Yes (f) |
- Static routing | No | No | No |
- Max routing table| 1023 | 1023 | 1023 |
- Max # of broad. | | | |
router adjencency| 32 | | |
Notes:
a. Phase IV+ refers to path-split capability. This means "normal" and
not "interim". Normal allows out-of-sequence packets to arrive.
Interim does not allow out-of-sequence packets to arrive.
b. cisco claims that it's ISO CLNS support is compatible with Decnet
Phase V.
c. Address Translation Gateway is the ability to connect two separate
Decnet networks with overlapping addresses.
d. It is not possible to filter out of area addresses. It is only
possible to filter an entire area or addresses within one's area.
e. On a per circuit basis, as required by DECnet specs.
f. MOP System ID.
6. Bridging | | | |
- Local bridging | Yes | Yes | No |
- LAVC (a) | Yes | Yes | No |
- Remote bridging | Yes (b) | Yes | No |
- Transparent | | | |
- Learning | Yes | Yes | No |
- Spanning tree | | | |
(IEEE 802.1) | Yes | Yes | No |
- Priority (c) | Rel 8.2 | No | No |
- Filtering | | | |
- Multicast | Yes | Yes | No |
- Protocol | Yes | Yes | No |
- Source/dest | Yes | Yes (g) | No |
- Masking (d) | No | No | No |
- Load sharing | Yes (e) | Yes | |
- Token Ring | | | |
- Source route | Yes | | Yes |
- Multi-ring (f) | Yes | | No |
Notes
a. LAVC refers to the ability to act as a local bridge between two Vax
clusters using the DEC LAVC protocol.
b. cisco does not support bridging over X.25 or LAPB.
c. Priority refers to the ability to assign a priority to a specific
protocol so that that protocol is sent faster than any other
protocol over a specific circuit/interface.
d. Masking refers to the ability to specify some pattern string to be
matched within the packet, so that the user can specify almost any
filter.
e. cisco load sharing (balancing) is on a per-node basis and not on
a per packet basis. That means that over 2 parallel serial lines
the cisco will automatically allocate 50% of the learned Ethernet
addresses to one line and the other 50% to the other line.
f. Multi-ring refers to bridging between multiple Token Ring networks
(all hosts must understand RIF).
g. Wellfleet can only filter on destination address and not on source
address.
7. Other protocols | | | |
(ability to route) | | | |
- XNS | Yes (a) | Yes | Yes |
- UB derivitive | Yes | | Yes |
- Appletalk | | | |
- Phase 1 | Yes | Yes | Yes |
- Phase 2 | Rel 8.2 | Rel 5.40 | No |
- Tokentalk | Rel 8.2 | Yes | No |
- Ethertalk | Yes | Yes | Yes |
- Localtalk | No | | No |
- RTMP | Yes | Rel 5.40 | Yes |
- AARP | Yes | Rel 5.40 | Yes |
- NBP | Yes | Rel 5.40 | Yes |
- EP | Yes | Rel 5.40 | Yes |
- ATP | Yes | | Yes |
- ZIP | Yes | Rel 5.40 | Yes |
- DDP | Yes | Yes | Yes |
- ISO | | | |
- ISO 8473 CLNP | Yes | No | Yes |
- ISO 9542 ES-IS | Yes | No | Yes |
- Apollo Domain | Yes | No | Yes |
- Novell IPX | Yes (a) | Yes | Yes |
- Banyan Vines | Rel 8.2 | | |
- X.25 | Yes | Yes | Yes |
- bridging | Rel 9.0 | Yes | No |
- routing | Yes | Yes | Yes |
- switching | Yes | Yes ??? | No |
- Security | Yes (b) | | |
Notes:
a. With cisco equipment, if there are both Ethernet and Token Ring
interfaces, then DECnet cannot be run simultaneously with either
Novell IPX or XNS. This restriction will be removed in Release 8.2.
b. cisco provides filtering/permitting/denying certain packets
only for IPX, XNS and Appletalk in the section listed above.
8. Management | | | |
- Central managed | Yes | Yes | Yes |
- SNMP | | | |
- Platform | Sun 3, Sparc | Sun 3 | 80286 AT |
- External | | | |
software (b) | No (c) | No | No |
- X netmap | Yes | Yes | |
- Telnet to | | | |
device (d) | Yes | No | |
- X interactive | Yes | | |
performance | | Yes | |
- History stats | Yes | No | |
- Report writer | Yes (c) | No | |
- Alerts (e) | No | No | |
- User defined | | | |
extensions (m) | Yes | No | |
- Usage stats | Yes | Yes (f) | |
- Direct MIB access| No | Yes | |
- PING | Yes | Yes (g) | No |
- Traceroute | Yes | No | |
- Telnet | Yes (h) | Yes (i) | Yes (n) |
- MOP Remote Cons. | Rel. 8.2 | Bridged | No |
- NICE (j) | No | No | No |
- Decnet connect | No | No | No |
- Passwords (k) | Yes | Yes | Yes |
- Netview support | | | |
- Disable lines | | | |
dynamically | Yes (l) | Yes | Yes |
Notes:
b. External software refers to the need to have some external
software package available in order to run SNMP monitoring.
c. cisco requires the Sybase database system in order to run their
NMS software. This package is bundled with their NMS.
d. Ability to click on an icon on the X-11 network map and open
a telnet connection to the device in question.
e. Alerts refers to the ability to define a preset limit for a
specific MIB variable at which point the SNMP monitoring software
will present a window on top of the network map informing the
network operator of the problem.
f. Wellfleet interactive usage statistics are only for (ISO model)
level 2. Upper level statistics (such as RIP, UDP, TCP, Decnet
HELLO, ARP) are not available.
g. Wellfleet PING command stops after first failure and waits for
user response. This makes it very hard to check the total
percentage of line failures over a short period of time.
h. cisco is limited to 5 incoming Telnet sessions but has no
limitation on outgoing Telnet sessions.
i. Wellfleet Telnet is limited to one incoming and one outgoing
session.
j. NICE refers to the ability of the router to accept "SET EXECUTOR"
as well as initiate a "SET EXECUTOR" to a remote host.
k. Passwords refers to the ability to limit certain configuration and
customization options only to those users who supply a password.
l. cisco command is not an EXEC command but actually requires a
configuration change to disable a line.
m. The ability for the NMS software to add other vendor MIBs to their
database, in order to manage these particular hardware units.
n. Proteon is limited to 2 incoming and no outgoing sessions.
9. Debugging & | | | |
Monitoring | | | |
- Data-Link Layer | Yes | Yes | Yes |
- LAN | Yes | Yes | Yes |
- Link | Yes | Yes | Yes |
- Decnet | Yes | Yes | Yes |
- Tcp/Ip | Yes | Yes | Yes |
- Event log | Yes | Yes | Yes |
- Environmentals | Yes | No | No |
Notes:
a. Environmentals refers to the monitoring of variables such as
fan, power supply, memory, temperature, etc.
10. Performance (a) | | | |
- Router forward | 2917 (b) | 3757 (c) | 902 |
- Router filter (d)| 2279 (b) | 3757 | 902 |
- Bridge forward | | | |
- Bridge filter | | | |
- LAT compression | Yes | No | |
Notes:
a. Performance based on 256 byte packets, between separate
interface cards, with no packet loss. Numbers listed are in
packets per second. Numbers based on Bradner report, Harvard
University, Sept 1989. A revised benchmark is expected sometime in
Sept 1990.
b. cisco performance numbers based on AGS and CSC2 hardware.
c. Wellfleet numbers may be higher but equipment was not able to
generate packets faster than the LN.
d. Filter is based on 10 packet filters enabled.
11. Survivability | | | |
- alternate power | | | |
supply | No | Yes (d) | No |
- standby line (a)| No | No | No |
- fault tolerant(b)| No | No | No |
- field tolerant(c)| No | No | No |
- broadcast storms | Yes | No | Yes |
Notes:
a. Standby line refers to the ability to define a line that is to be a
hot standby, in the event that the primary line goes down. The
software switches all traffic automatically to the backup line.
b. Fault tolerant refers to having redundent systems that are normally
in standby mode, and that are only called into active mode in the
event that the primary system fails. Various systems are the power
supply, the fan, the bus, the controller cards, etc.
c. Field tolerant refers to the ability to withstand harsh elements
and conditions out in the "field."
d. Alternate power supply only available in large Concentrator model.
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: Tue, 02 Oct 90 15:03:34 IST From: Hank Nussbacher <HANK%TAUNIVM.BITNET@CUNYVM.CUNY.EDU> To: cisco@spot.colorado.edu, wellfleet@nstn.ns.ca, tcp-ip@nic.ddn.mil, ripe@mcsun.EU.NET, p4200@devvax.tn.cornell.edu Subject: Router scorecard V1.6
CAVEATS
-------
The following scorecard tries to compare various multi-protocol
routers. The current scorecard mainly contains information for
cisco and Wellfleet but any other vendor is welcome to send me a
complete set of manuals for their equipment so that I can analyze
and update the scorecard.
The fact of the matter is that certain features and "gotchas"
only appear when testing the actual equipment. I hope that the user
population of multi-protocol routers will assist me in making this
scorecard as comprehensive as possible so that people who follow do
not have to go through what I have gone through.
It was difficult to decide whether to include future release
notes in this scorecard. I trust the user population in the
Internet to take each promise for a "future feature" with a grain of
salt and to keep watch on the vendors that indeed they follow
through with their promises. All too often vendors state certain
features will be available in a certain release and sometimes their
deadlines slip. It is advised that people should not base their
decisions on the future release notes. [That was a long caveat].
If you have comments, suggestions, additions, or subtractions
or corrections, please send them to:
HANK@VM.TAU.AC.IL or HANK@TAUNIVM.BITNET (but not to both!)
The scorecard will be updated on a monthly basis. This report
may be freely reproduced as long as nothing is altered or removed.
If you read this report and are not connected to the Internet,
you can send your comments to:
Hank Nussbacher
Computer Center
Tel Aviv University
Ramat Aviv
Israel
[The above employer has nothing to do with this scorecard so if
something bothers you about it, I take full responsibility.]
END OF CAVEATS
--------------------------------------------------------------------
V1.6 update: Various vendors have been in contact with me but after
expressing interest in having an entry for their machine they disappear.
Other vendors have tried to change the particular hardware box that
is being compared to another box. I hope that vendors will participate
in keeping this scorecard up-to-date.
--------------------------------------------------------------------
Distribution:
cisco@spot.colorado.edu
wellfleet@nstn.ns.ca
tcpip@nic.ddn.mil
ripe@mcsun.eu.net
p4200@devvax.tn.cornell.edu
Usenet: comp.dcom.lans
--------------------------------------------------------------------
Comparison of Multiprotocol Routers
Henry Nussbacher
October 1990
Version 1.6
+--------------+--------------+---------------+
Multiprotocol | cisco AGS+ | Wellfleet LN | Proteon p4200 |
Router | Rel. 8.1(14) | Rel. 5.35 | |
+--------------+--------------+---------------+
1. General | | | |
- # of slots | 9 | 4 | 7 |
- Processor | 68020 | 68020 | 68020 |
- Memory | 4Mbyte | 4Mbyte | 2Mbyte |
- Updates via | ROM, TFTP | diskette,TFTP| diskette,TFTP |
- Speed of bus | 530Mb/sec (a)| 320Mb/sec | |
- Boot from | | | |
- ROM | Yes | No | No |
- Net-boot | | | |
- IP | Yes | No | Yes |
- Decnet (MOP) | No | No | No |
- Diskette | No | Yes | No |
- Another router | Yes | No | No |
- Volatile changes | Yes (b) | No | Yes (h) |
- CPU statistics | Yes (c) | No | Yes |
- Memory stats | Yes | No | Yes |
- Ease of install | Very easy | menu driven | |
- Documentation | Difficult | Skimpy | Clear, orderly|
- Autorestart (d) | Yes | Yes | Yes |
- Restart for | | | |
config changes | No | Yes | Yes |
- Watchdog timer | Yes | | Yes |
- Reboot time (e) | 29 sec (f) | 60 sec | 32 sec (i) |
- Power-up time (g)| 29 sec | 120 sec | 32 sec (i) |
Notes:
a. Speed of old AGS bus is 160Mb.
b. Volatile changes represents the ability of the router to accept a
configuration change that is dynamic that only affects the current
running system and once the system is rebooted, the change
disappears.
c. CPU statistics refers to the ability of the router to provide
a monitoring facility to see what the CPU is doing and how often
it is doing it.
d. Autorestart in the event of a power failure.
e. Reboot time refers to the amount of elapsed time needed to
perform a logical restart (reboot) from the fastest available
media.
f. cisco timings are for older AGS system.
g. Power-up time refers to the amount of elapsed time needed from
the time of a power failure and recovery until the router is up and
operational.
h. Only available for DECnet and OSPF, and only for a subset of
available parameters.
i. Booting via Proteon's Intergrated Boot Device, with running
diagnostics.
2. Interfaces (a) | | | |
- Ethernet | | | |
(802.3 10Base5) | 24x10Mb | 8x10Mb | 7x10Mb |
- Thin Ethernet (b)| | | |
(802.3 10Base2) | No | 8x10Mb | No |
- 4Mb Token Ring | 3x4Mb (i) | 4x4Mb | 7x4Mb |
- 16Mb Token Ring | Rel 8.2 (j) | Rel 5.40 (c) | No |
- RS232 | 24x64kb | 16x64kb | 14x64kb |
- RS449 | 12x64kb | 16x64kb | 14x64kb |
- V.35 | 12x64kb | 16x64kb | 14x64kb |
- T1 | 12x1.544Mb | 8x1.544Mb | 14x1.544Mb |
- CEPT DS1 (2Mb) | 12x2Mb | 8x2Mb | 12x2Mb |
- FDDI | 2x100Mb | Rel 5.50 (d) | 2x100Mb |
- DAS (Dual) (e)| Yes | Yes | Yes |
- SAS (Single) | Yes | No | Yes |
- Ultranet | Rel 8.2 (k)| | |
- X.25 | | | |
- Max # of VCs | Unlimited (f)| 254 | 255 |
- Card types (g) | 6E, 1E2S, | 2E, 1E1S, | 1E, 2S, 4S, |
per slot | 2E2S, 4S, | 1E2S, 2E2S, | 1TR, .5F |
| 1TR, 1F (h)| 1TR2S, 4S, | |
| | 1TR | |
Notes:
a. Each interface subsection represents the maximum number of LANs
or WANS that can be configured for that particular subsection.
It is possible to "mix and match" various subsections by reducing
the upper limit.
b. Thin Ethernet refers to a standard BNC connector available directly
on the router.
c. 4x16Mb.
d. 1x100Mb.
e. Dual is also known as Type A and Single is also known as Type B.
f. Depends on memory limitations.
g. Card types: E: Ethernet, S: Serial/Synchronous line
TR: Token-Ring, F: FDDI
h. The 6E and 1F cards are for the faster cBus only.
i. The AGS can take 4 Token Rings while the AGS+ can only take 3.
j. To be supported in later release of Version 8.2.
k. Ultranet support will be in a later release of 8.2 but will
only support a 125Mb full-duplex connection to Ultranet's 1Gb LAN.
3. Interface part II | | | |
- Frame Relay (a) | Rel 8.2 | | |
- Ethernet | | | |
encapsulation | | | |
- Standard v2.0 | Yes | | Yes |
- IEEE 802.3 | Yes | | Yes |
- SNAP 802.2 | | | |
(RFC1042) | Yes | Yes | No |
- Serial | | | |
encapsulation | | | |
- HDLC | Yes | | Yes |
- LAPB | Yes | | No |
- PPP (RFC1134) | Yes | | |
- DDCMP | No | No | No |
- X.25 | Yes | | Yes |
- SVC | Yes | Yes | Yes |
- PVC | Yes | Yes | Yes |
- Encryption (b) | Pulse-time | | |
- Filtering by | | | |
source/dest | Yes | Yes | Yes |
Notes:
a. CCITT standards Q.931 (Frame Relay) and I.122 (Lap-D)
b. Encryption refers to the ability of the router to compensate for
encrypting devices on various interfaces or circuits.
c. For CLNP only.
4. IP | | | |
- Subnetting | | | |
(RFC950) | Yes | Yes | Yes |
- ARP (RFC826) | Yes | Yes | Yes |
- RARP (RFC903) | Yes | No | No |
- BOOTP (RFC951) | Yes | No | No |
- proxy ARP | | | |
(RFC1027) | Yes | Yes | Yes |
- ICMP | Yes | Yes | Yes |
- Name-server | Yes | No | No |
- Accounting | Yes | No | No |
- MTU | Yes | No | No |
- Security - IPSO | Yes | No | |
- Static routing | Yes | Yes | Yes |
- Source routing | Yes | No | Yes |
- Filters | | | |
- source/dest | Yes | Yes | Yes |
- TCP | Yes | | |
- UDP | Yes | | |
- ICMP | Yes | | |
- by protocol (b)| Yes (a) | Yes | |
- Routing protocols| | | |
- RIP (RFC1058) | Yes | Yes | Yes |
- EGP (RFC904) | Yes | Yes | Yes |
- BGP (RFC1105) | Yes | No | |
- Proprietary | IGRP | eRIP | No |
- Filtering | Yes | No | Yes |
- Default routes | Yes | Yes | Yes |
- OSPF | Rel 9.0 | Rel 5.6 | Yes |
Notes:
a. Can be done but is difficult and requires advanced knowledge of the
specific protocols.
b. Filtering by protocol can also be viewed as filtering by port
number.
5. DECNET | | | |
- Phase IV Router | Yes | Yes | Yes |
- Area Router | Yes | No | Yes |
- Phase IV+ (a) | Rel 8.2 | No | |
- Phase IV-V | | | |
Transitional gty | Rel 8.2 | | |
- Phase V | Yes (b) | No | Yes (b) |
- Address xlation | | | |
gateway (c) | Yes | No | No |
- NCP | | | |
- area-max-cost | Yes | Yes | Yes |
- area-max-hops | Yes | Yes | Yes |
- max-address | Yes | Yes | Yes |
- max-area | Yes | Yes | Yes |
- max-cost | Yes | Yes | Yes |
- max-hops | Yes | Yes | Yes |
- max-visits | Yes | Yes | Yes |
- router-priority| Yes | Yes | Yes (e) |
- hello-timer | Yes | Yes | Yes |
- routing-timer | Yes | Yes | Yes |
- Filtering | | | |
- source/dest | Yes | No | Yes |
- by protocol | No | No | No |
- by object | No | No | No |
- routing | Yes (d) | No | Yes (d) |
- MOP | Bridged | Bridged | Yes (f) |
- Static routing | No | No | No |
- Max routing table| 1023 | 1023 | 1023 |
- Max # of broad. | | | |
router adjencency| 32 | | |
Notes:
a. Phase IV+ refers to path-split capability. This means "normal" and
not "interim". Normal allows out-of-sequence packets to arrive.
Interim does not allow out-of-sequence packets to arrive.
b. cisco claims that it's ISO CLNS support is compatible with Decnet
Phase V.
c. Address Translation Gateway is the ability to connect two separate
Decnet networks with overlapping addresses.
d. It is not possible to filter out of area addresses. It is only
possible to filter an entire area or addresses within one's area.
e. On a per circuit basis, as required by DECnet specs.
f. MOP System ID.
6. Bridging | | | |
- Local bridging | Yes | Yes | No |
- LAVC (a) | Yes | Yes | No |
- Remote bridging | Yes (b) | Yes | No |
- Transparent | | | |
- Learning | Yes | Yes | No |
- Spanning tree | | | |
(IEEE 802.1) | Yes | Yes | No |
- Priority (c) | Rel 8.2 | No | No |
- Filtering | | | |
- Multicast | Yes | Yes | No |
- Protocol | Yes | Yes | No |
- Source/dest | Yes | Yes (g) | No |
- Masking (d) | No | No | No |
- Load sharing | Yes (e) | Yes | |
- Token Ring | | | |
- Source route | Yes | | Yes |
- Multi-ring (f) | Yes | | No |
Notes
a. LAVC refers to the ability to act as a local bridge between two Vax
clusters using the DEC LAVC protocol.
b. cisco does not support bridging over X.25 or LAPB.
c. Priority refers to the ability to assign a priority to a specific
protocol so that that protocol is sent faster than any other
protocol over a specific circuit/interface.
d. Masking refers to the ability to specify some pattern string to be
matched within the packet, so that the user can specify almost any
filter.
e. cisco load sharing (balancing) is on a per-node basis and not on
a per packet basis. That means that over 2 parallel serial lines
the cisco will automatically allocate 50% of the learned Ethernet
addresses to one line and the other 50% to the other line.
f. Multi-ring refers to bridging between multiple Token Ring networks
(all hosts must understand RIF).
g. Wellfleet can only filter on destination address and not on source
address.
7. Other protocols | | | |
(ability to route) | | | |
- XNS | Yes (a) | Yes | Yes |
- UB derivitive | Yes | | Yes |
- Appletalk | | | |
- Phase 1 | Yes | Yes | Yes |
- Phase 2 | Rel 8.2 | Rel 5.40 | No |
- Tokentalk | Rel 8.2 | Yes | No |
- Ethertalk | Yes | Yes | Yes |
- Localtalk | No | | No |
- RTMP | Yes | Rel 5.40 | Yes |
- AARP | Yes | Rel 5.40 | Yes |
- NBP | Yes | Rel 5.40 | Yes |
- EP | Yes | Rel 5.40 | Yes |
- ATP | Yes | | Yes |
- ZIP | Yes | Rel 5.40 | Yes |
- DDP | Yes | Yes | Yes |
- ISO | | | |
- ISO 8473 CLNP | Yes | No | Yes |
- ISO 9542 ES-IS | Yes | No | Yes |
- Apollo Domain | Yes | No | Yes |
- Novell IPX | Yes (a) | Yes | Yes |
- Banyan Vines | Rel 8.2 | | |
- X.25 | Yes | Yes | Yes |
- bridging | Rel 9.0 | Yes | No |
- routing | Yes | Yes | Yes |
- switching | Yes | Yes ??? | No |
- Security | Yes (b) | | |
Notes:
a. With cisco equipment, if there are both Ethernet and Token Ring
interfaces, then DECnet cannot be run simultaneously with either
Novell IPX or XNS. This restriction will be removed in Release 8.2.
b. cisco provides filtering/permitting/denying certain packets
only for IPX, XNS and Appletalk in the section listed above.
8. Management | | | |
- Central managed | Yes | Yes | Yes |
- SNMP | | | |
- Platform | Sun 3, Sparc | Sun 3 | 80286 AT |
- External | | | |
software (b) | No (c) | No | No |
- X netmap | Yes | Yes | |
- Telnet to | | | |
device (d) | Yes | No | |
- X interactive | Yes | | |
performance | | Yes | |
- History stats | Yes | No | |
- Report writer | Yes (c) | No | |
- Alerts (e) | No | No | |
- User defined | | | |
extensions (m) | Yes | No | |
- Usage stats | Yes | Yes (f) | |
- Direct MIB access| No | Yes | |
- PING | Yes | Yes (g) | No |
- Traceroute | Yes | No | |
- Telnet | Yes (h) | Yes (i) | Yes (n) |
- MOP Remote Cons. | Rel. 8.2 | Bridged | No |
- NICE (j) | No | No | No |
- Decnet connect | No | No | No |
- Passwords (k) | Yes | Yes | Yes |
- Netview support | | | |
- Disable lines | | | |
dynamically | Yes (l) | Yes | Yes |
Notes:
b. External software refers to the need to have some external
software package available in order to run SNMP monitoring.
c. cisco requires the Sybase database system in order to run their
NMS software. This package is bundled with their NMS.
d. Ability to click on an icon on the X-11 network map and open
a telnet connection to the device in question.
e. Alerts refers to the ability to define a preset limit for a
specific MIB variable at which point the SNMP monitoring software
will present a window on top of the network map informing the
network operator of the problem.
f. Wellfleet interactive usage statistics are only for (ISO model)
level 2. Upper level statistics (such as RIP, UDP, TCP, Decnet
HELLO, ARP) are not available.
g. Wellfleet PING command stops after first failure and waits for
user response. This makes it very hard to check the total
percentage of line failures over a short period of time.
h. cisco is limited to 5 incoming Telnet sessions but has no
limitation on outgoing Telnet sessions.
i. Wellfleet Telnet is limited to one incoming and one outgoing
session.
j. NICE refers to the ability of the router to accept "SET EXECUTOR"
as well as initiate a "SET EXECUTOR" to a remote host.
k. Passwords refers to the ability to limit certain configuration and
customization options only to those users who supply a password.
l. cisco command is not an EXEC command but actually requires a
configuration change to disable a line.
m. The ability for the NMS software to add other vendor MIBs to their
database, in order to manage these particular hardware units.
n. Proteon is limited to 2 incoming and no outgoing sessions.
9. Debugging & | | | |
Monitoring | | | |
- Data-Link Layer | Yes | Yes | Yes |
- LAN | Yes | Yes | Yes |
- Link | Yes | Yes | Yes |
- Decnet | Yes | Yes | Yes |
- Tcp/Ip | Yes | Yes | Yes |
- Event log | Yes | Yes | Yes |
- Environmentals | Yes | No | No |
Notes:
a. Environmentals refers to the monitoring of variables such as
fan, power supply, memory, temperature, etc.
10. Performance (a) | | | |
- Router forward | 2917 (b) | 3757 (c) | 902 |
- Router filter (d)| 2279 (b) | 3757 | 902 |
- Bridge forward | | | |
- Bridge filter | | | |
- LAT compression | Yes | No | |
Notes:
a. Performance based on 256 byte packets, between separate
interface cards, with no packet loss. Numbers listed are in
packets per second. Numbers based on Bradner report, Harvard
University, Sept 1989. A revised benchmark is expected sometime in
Sept 1990.
b. cisco performance numbers based on AGS and CSC2 hardware.
c. Wellfleet numbers may be higher but equipment was not able to
generate packets faster than the LN.
d. Filter is based on 10 packet filters enabled.
11. Survivability | | | |
- alternate power | | | |
supply | No | Yes (d) | No |
- standby line (a)| No | No | No |
- fault tolerant(b)| No | No | No |
- field tolerant(c)| No | No | No |
- broadcast storms | Yes | No | Yes |
Notes:
a. Standby line refers to the ability to define a line that is to be a
hot standby, in the event that the primary line goes down. The
software switches all traffic automatically to the backup line.
b. Fault tolerant refers to having redundent systems that are normally
in standby mode, and that are only called into active mode in the
event that the primary system fails. Various systems are the power
supply, the fan, the bus, the controller cards, etc.
c. Field tolerant refers to the ability to withstand harsh elements
and conditions out in the "field."
d. Alternate power supply only available in large Concentrator model.
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 90 18:56:14 GMT From: bu.edu!buit13!kwe@uunet.uu.net (Kent England) To: tcp-ip@nic.ddn.mil Subject: Re: Maintainability of TELNET ...
In article <9010021049.AA06180@WLV.IMSD.CONTEL.COM> mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes: >... > 1. Do routers generally have the capability to re-route traffic over > an alternate circuit? ... > 4. Would fudging IP, TCP, or TELNET timers by a "crypto resync constant" > alleviate problems? > One problem with routing fallback has to do with the time constants of the routing protocols (and link level fault protocols, if any) and the time constant of the failure. Sounds to me like crypto sync loss is a fast time constant sort of error. This begs the question of whether the routing protocol should spend the time required to re-route or whether it should hold off and wait for the link to come back up. With the advent of open link state protocols which converge "instantly", perhaps this point is becoming moot, but with distance vector protocols it is very hard to deal with link level state "flapping" side effects and still keep routing traffic down. Same thinking applies to TCP or Telnet timers. Should they wait a short time or a long time? How should they treat redirects and black holes? I think that should be up to the application, since mail usually has a different idea than telnet would. Put me in the "hate TCP/IP keepalives" camp. --Kent
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 90 20:58:54 GMT From: crash!ncr-sd!ncrcae!wingo@nosc.mil (Dave Wingo) To: tcp-ip@nic.ddn.mil Subject: network file backup
Does anyone know of a network based (TCP/IP) file system back-up/restore product that is currently available for UNIX 5.3 or 5.4. How about one that would also be available on OS/2 based systems..... We are very interested in this type of product.... Thanks in advance for your help..... David Wingo, NCR Corp System 3000 voice 803-791-6476 email: wingo@Columbia.NCR.COM
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 90 21:46:58 GMT From: julius.cs.uiuc.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!wls@apple.com (Bill Stapleton) To: tcp-ip@nic.ddn.mil Subject: IBM 9000 TCP/IP, lpr?
Another campus entity is looking into purchasing an IBM 9000 system, which
would run VM, and comes with some sort of TCP/IP package. They want to be
sure it works with our (BSD) network, especially for printing. Does anybody
know if it's possible for an IBM 9000 VM system to talk Berkeley lpr protocol?
Any information is most appreciated.
--
Bill Stapleton
wls@csd4.csd.uwm.edu
uwmcsd4!wls
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 3 Oct 90 00:58:36 GMT From: snorkelwacker!usc!zaphod.mps.ohio-state.edu!uwm.edu!srcsip!pserv!stevem@bloom-beacon.mit.edu (Steve Mestad) To: tcp-ip@nic.ddn.mil Subject: Looking for Rarpd
I am looking for source for the rarp daemon. I would like it for HP-UX 7.0 on the HP 9000 series 300 systems but at this point I would be willing to take any source and hope for the best. Please let me know where I can find this beastie. Thanks. SM stevem@cfsmo.honeywell.com stevem%pserv@src.honeywell.com (if the above is ill from your location)
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Wed, 03 Oct 90 08:34:49 MDT From: Greg Satz <satz@cisco.com> To: brooks@apple.com (Kevin Brooks) Cc: tcp-ip@nic.ddn.mil Subject: Re: HP TCP/IP router/bridge?
The cisco router will do this and has for the last three year. Drop a note to customer-service@cisco.com for more information. Greg
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Wed, 3 Oct 90 11:42:22 -0500 From: jbvb@ftp.com (James B. Van Bokkelen) To: mailrus!sharkey!cfctech!alexb@uunet.uu.net (Alex Beylin) Cc: tcp-ip@nic.ddn.mil Subject: Re: SLIP, IP Routers and Named Pipes
If you want Named Pipes, you need LAN Manager, which means Netbios, which means RFC 1001/1002 if you want it over TCP/IP. I don't know of any RFC 1001/1002 Netbioses which implement "p-nodes" or "m-nodes", so you can't use a conventional router. TWG has a hack which uses static client configuration to avoid this problem, but a cleaner alternative (IMHO) is to use the cisco SLIP concentrator, which keeps the clients on the same net/subnet as its attached ethernet (fine as long as your servers are on that ethernet). If you use the latter approach, you can use our PC/TCP as well as TWG's WIN/PC. I can never remember if Beame & Whiteside has an RFC Netbios, but none of the others (Excelan, U-B, CMC, Interlan, Bridge) support SLIP. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: Wed, 03 Oct 90 13:12:12 PST From: "Donald R. Proctor" <SPGDRP%UCCVMA.UCOP.EDU@CORNELLC.cit.cornell.edu> To: Alex Beylin <mailrus!sharkey!cfctech!alexb@UUNET.UU.NET>, tcp-ip@nic.ddn.mil Subject: Re: SLIP, IP Routers and Named Pipes
>A project have come up around here that require multiple >PCs to get dial-in access to the TCP/IP network. One of the >major requirements is support for Named Pipes down to the PC. >Current plan is to use SLIP and a router with dial-in ports. > >Would someone care to recommend a PC package that would do good >SLIP emulation and a router that would be suitable for this job? > Alex: We intend on implementing a similar system here, although we don't have the named pipes requirement. We have a cisco terminal server that can be configured with several dial-in ports. The software angle is a bit more complex. As I understand it, the remote PC user will need to use a communications package like kermit or xmodem to connect to the terminal server. A commercial (such as FTP's PC/TCP) or public domain (such as NCSA telnet) TCP-IP package can then be run over SLIP. FTP's package can be ordered with SLIP, and there is a SLIP driver in Clarkson's pd packet driver distribution. I should point out that cisco's box can provide the telnet connection itself, so that a remote PC user can dial in and start a telnet session from the server without having the TCP-IP software installed on the PC. However, if need 3270 emulation (as we do), the current release of the cisco's software won't do the job. I hope my more knowledgeable colleagues will correct me if I have made any egregious errors... Don Proctor <spgdrp@uccvma.ucop.edu> Information Systems & Computing <spgdrp@uccvma.bitnet> University of California 415/987-0356
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: 3 Oct 90 05:27:08 GMT From: munnari.oz.au!mtiame!ubeaut!mwp@uunet.uu.net (Michael Paddon) To: tcp-ip@nic.ddn.mil Subject: Re: TCP segment size -- user defined?
From article <266@aldetec.oz.au>, by mawson@aldetec.oz.au (Graeme Mawson): > > We are presently experimenting with the TCP/IP protcol suite over an Ethernet > LAN. A useful guide to TCP/IP by Comer seems to suggest that TCP segment > size is user-definable. Is this true? Does anyone know how to define it? It surely is. On BSD based systems, the macro TCP_MSS is defined in /usr/include/netinet/tcp.h. This may be changed with impunity since the negotiation undergone at connection setup time chooses the smaller of the segment sizes supported by each implementation. There is not much point setting TCP_MSS to be greater than (maximum IP packet size - IP header size - TCP header size) [536 octets] since IP fragmentation will take place. Receipt of a fragmented packet is an all or nothing proposition; a good thing to avoid for throughput reasons. In general, the BSD TCP parameters in tcp.h and tcp_timers.h are close to optimal for ethernet (default RTT is a little pessimistic, but that is so the latter stages of backoff work properly). I found I had to do a fair bit of tuning to get everything right for a SLIP environment with flakey link hardware. Michael ------------------------------------------------------------------- | | Internet: paddon@meo78b.enet.dec.com | | | ACSnet: mwp@ubeaut.oz.au | | Michael Paddon | ACSnet: mwp@munnari.oz.au | | | EasyNet: meo78b::paddon | | | Voice: +61 3 895 9392 | -------------------------------------------------------------------
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Wed, 03 Oct 90 13:36:01 PST From: "Donald R. Proctor" <SPGDRP%UCCVMA.UCOP.EDU@CORNELLC.cit.cornell.edu> To: tcp-ip-relay@NIC.DDN.MIL, tcp-ip@nic.ddn.mil Subject: Re: Is there a program like telnet, but driven by a script?
>I need to duplicate UNIX-to-UNIX rsh functionality going UNIX-to-VMS. >I am running a Sun Sparcstation and can communicate with the VAX using >telnet and ftp via an ULTRIX gateway (the VAX only runs DECNET). One >solution to my problem would be a telnet-like program which accepts a >script containing expect/send pairs much like UUCP and some PC >communications programs. Does such a program exist? > >I would also appreciate any suggestions of alternate solutions. > We run TGV's MultiNet on our VMS machine. It does a remarkable job of bringing Unix/Ultrix connectivity to the VMS world. Don Proctor <spgdrp@uccvma.ucop.edu> Information Systems & Computing <spgdrp@uccvma.bitnet> University of California 415/987-0356 Office of the President The opinions expressed do not necessarily reflect the opions of my employer. The University of California does not endorse any commercial products mentioned.
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: Wed 3 Oct 90 14:26:43-PDT From: VANCE@TGV.COM (Icarus) To: sdd.hp.com!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!rphroy!cfctech!sharkey!fmsrl7!slee01!hugh@ucsd.edu Cc: tcp-ip@nic.ddn.mil Subject: Re: Is there a program like telnet, but driven by a script?
>I need to duplicate UNIX-to-UNIX rsh functionality going UNIX-to-VMS. >I am running a Sun Sparcstation and can communicate with the VAX using >telnet and ftp via an ULTRIX gateway (the VAX only runs DECNET). One >solution to my problem would be a telnet-like program which accepts a >script containing expect/send pairs much like UUCP and some PC >communications programs. Does such a program exist? One solution would be to put a TCP/IP package that supports rsh on your VAX. There are several that do (MultiNet, WIN/TCP, Fusion, possibly others...) Scripted TELNET is another issue. I don't know of any of the IP for VMS (or for other platforms for that matter) that support this. -----Stuart -------
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Wed, 3 Oct 90 18:48 MST From: WIMMER@Arizona.edu To: TCP-IP@NIC.DDN.MIL Subject: UN-Subscribe
Apologies to the Network for posting this here.
Please drop me from this list.
Terry Wimmer
Wimmer@rvax.ccit.arizona.edu (old account address)
or
Wimmer@Arizona.edu (current address)
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: 3 Oct 90 16:24:46 GMT From: usc!snorkelwacker!ai-lab!ai.mit.edu!dms@ucsd.edu (David M. Siegel) To: tcp-ip@nic.ddn.mil Subject: Heathkit Weather Computer (IDW5001)
We have just ordered a Heathkit IDW5001 weather computer. Our plans are to make the readings from the computer available over our network. It would be nice to use a "standard" weather TCP/UDP protocol for this purpose. Ideally, all Internet sites with weather data could support this protocol. The protocol should be extensible, since it is hard to anticipate all types of weather data that people might have. I'm wondering, does such a protocol exist? Also, does anyone else have IDW5001 weather computers. We'd be interested in obtaining your software to interface to the computer, and for client programs. Our plans are to run it on a Unix box, connected via the RS232 port. -Dave
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: 3 Oct 90 19:23:49 GMT From: eru!hagbard!sunic!dkuug!resam!andrew@bloom-beacon.mit.edu (Leif Andrew Rump) To: tcp-ip@nic.ddn.mil Subject: Does anybody know LM-X or Lackman?
Do any one of you know where we can get LM-X (Lan Manager) software for the 386-UNIX System V rel 4 running on top of TCP/IP. We would also like to know the address of a company called Lackman who supplies TCP/IP software for UNIX systems. Thank you in advance Leif Andrew Leif Andrew Rump, AmbraSoft A/S, Stroedamvej 50, DK-2100 Copenhagen OE, Denmark UUCP: andrew@ambra.dk, phone: +45 39 27 11 77 / Currently at Scandinavian Airline Systems =======/ UUCP: andrew@resam.dk, phone: +45 32 32 22 79 \ SAS, RESAM Project Office, CPHML-V, P.O.BOX 150, DK-2770 Kastrup, Denmark > > Read oe as: o <backspace> / (slash) and OE as O <backspace> / (slash) < <
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: 3 Oct 90 20:07:49 GMT From: att!cbnewsk!lih@ucbvax.Berkeley.EDU (andrew.a.lih) To: tcp-ip@nic.ddn.mil Subject: Re: quick check for available host
In article <771@tiamat.fsc.com>, jim@tiamat.fsc.com (Jim O'Connor) writes: > What is a quick way for a shell script to find out if a networked > host is currently available? If you just want to know if the host is alive, then the 'ping' program will suffice. It basically sends packets over to the host you specify and returns the round trip time for the packet. Most of the time it is used to detect delays and transmission times, but in this case you can use it to see if the machine is up. /lih AT&T Bell Labs Middletown, NJ
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 3 Oct 90 20:15:35 GMT From: swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!kriger@ucsd.edu (Sidney Kriger) To: tcp-ip@nic.ddn.mil Subject: Re: SLIP, IP Routers and Named Pipes
In article <8879@allen.ingr.com> usenet@b11.ingr.com (Usenet Network) writes: >For routers see cisco or there are terminal servers that support SLIP. >I worked for an outfit that sold cisco and the company I work for now >sells the Encore Annex II. > >encore (terminal server with slip) >617-460-0500 > > * John E. Allen - Intergraph Corporation - (205) 730-8627 * > * System Sales Support * > * ingr!b23b!allen!jallen@uunet.uu.net * Xylogics now manufactures the Annex II terminal server and has for about 2 years, not Encore. 800-225-3317 Sidney Kriger Xylogics, Inc. voice: 617-272-8140 53 Third Ave. fax: 617-273-5392 Burlington, MA 01803 email: kriger@Xylogics.COM
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 3 Oct 90 20:27:45 GMT From: bcstec!bcstec.uucp@uunet.uu.net (Charles Derykus) To: tcp-ip@nic.ddn.mil Subject: Nameservice questions
I have several questions regarding nameserver:
(1) Can nameservice resolve reverse translation queries "up the tree"
towards the root domain if the domains of the requested node and
the requesting node are at the same level, e.g.
Nameserver Node Domain
--------------- ------
cabbage vegetable
parsley herb.vegetable
carrot underground.vegetable
can "carrot" ask "cabbage" to reverse translate an I.P. in
"herb.vegetable" and if so, how?
We have gotten it to work only by specifying in the named.boot
on carrot a line like the one below where 192.33.72.10 is the
I.P. of parsley
secondary 72.33.192.in-addr-arpa 192.33.72.10 herb.bak
In other words, carrot seems to have to know that parsley is
authoratative for the herb.vegetable domain and doesn't seem to be
able to pull it down from a server such as cabbage in a higher
domain.
(2) A named.rev with multiple $ORIGIN lines worked fine on out primary
nameserver for a while but then the secondary nameserver starting
breaking. The only way we get it working now is by specifying separate
reverse translation files for each $ORIGIN line, e.g.
in the primary's named.boot:
primary 207.128.in-addr.arpa herb.207.128.in-addr.arpa
primary 79.33.192.in-addr.arpa herb.79.33.192.in-addr.arpa
in the secondary's named.boot: (primary's I.P. is 128.207.254.44)
secondary 207.128.in-addr.arpa 128.207.254.44
secondary 79.33.192.in-addr.arpa 128.207.254.44
Does nameservice break if these separate reverse files exceed some
limit- either in number of files or memory capacity- as the
"named.rev" file apparently does?
Thanks for listening. Any help greatly appreciated.
Charles DeRykus Internet: ced@bcstec.boeing.com
Boeing Computer Services UUCP: ...!uunet!bcstec!ced
Renton, WA. M/S 6R-37 (206) 938-4520 (home)
(206) 234-9223
-----------[000035][next][prev][last][first]----------------------------------------------------
Date: 3 Oct 90 21:12:12 GMT
From: SPGDRP@UCCVMA.UCOP.EDU ("Donald R. Proctor")
To: comp.protocols.tcp-ip
Subject: Re: SLIP, IP Routers and Named Pipes>A project have come up around here that require multiple >PCs to get dial-in access to the TCP/IP network. One of the >major requirements is support for Named Pipes down to the PC. >Current plan is to use SLIP and a router with dial-in ports. > >Would someone care to recommend a PC package that would do good >SLIP emulation and a router that would be suitable for this job? > Alex: We intend on implementing a similar system here, although we don't have the named pipes requirement. We have a cisco terminal server that can be configured with several dial-in ports. The software angle is a bit more complex. As I understand it, the remote PC user will need to use a communications package like kermit or xmodem to connect to the terminal server. A commercial (such as FTP's PC/TCP) or public domain (such as NCSA telnet) TCP-IP package can then be run over SLIP. FTP's package can be ordered with SLIP, and there is a SLIP driver in Clarkson's pd packet driver distribution. I should point out that cisco's box can provide the telnet connection itself, so that a remote PC user can dial in and start a telnet session from the server without having the TCP-IP software installed on the PC. However, if need 3270 emulation (as we do), the current release of the cisco's software won't do the job. I hope my more knowledgeable colleagues will correct me if I have made any egregious errors... Don Proctor <spgdrp@uccvma.ucop.edu> Information Systems & Computing <spgdrp@uccvma.bitnet> University of California 415/987-0356
-----------[000036][next][prev][last][first]----------------------------------------------------
Date: 3 Oct 90 21:36:01 GMT
From: SPGDRP@UCCVMA.UCOP.EDU ("Donald R. Proctor")
To: comp.protocols.tcp-ip
Subject: Re: Is there a program like telnet, but driven by a script?>I need to duplicate UNIX-to-UNIX rsh functionality going UNIX-to-VMS. >I am running a Sun Sparcstation and can communicate with the VAX using >telnet and ftp via an ULTRIX gateway (the VAX only runs DECNET). One >solution to my problem would be a telnet-like program which accepts a >script containing expect/send pairs much like UUCP and some PC >communications programs. Does such a program exist? > >I would also appreciate any suggestions of alternate solutions. > We run TGV's MultiNet on our VMS machine. It does a remarkable job of bringing Unix/Ultrix connectivity to the VMS world. Don Proctor <spgdrp@uccvma.ucop.edu> Information Systems & Computing <spgdrp@uccvma.bitnet> University of California 415/987-0356 Office of the President The opinions expressed do not necessarily reflect the opions of my employer. The University of California does not endorse any commercial products mentioned.
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: 3 Oct 90 21:48:47 GMT From: issm!wraith.wtp.contel.com!powell@uunet.uu.net (Mike Powell "CFS Net Ops") To: tcp-ip@nic.ddn.mil Subject: Network Monitors/Managment ... again (repost)
Since the first one appears to have gone to /dev/null due to a missing
Date:, we will try again....
We are in the process of evaluating Network Monitor/Management packages.
I missed most of the previous discussion.
We have looked at/read glossies from Cisco, Cabletron, Excelan (Novell),
Silicon Graphics, ACC, and Micro Technologies (inhouse demo, high
pressure salesman). I've only read a short article about the HP stuff.
MT is the only one we have taken an in-depth look at, but we are
working on others.
Three Questions:
1) anybody out there dealt with or have installed and operating any of
these packages? how was the sales and technical staff? MT seems like
they will eventually have a good product, but the level of the
visible technical personnel is less than what I would expect of a
major player in this game.
2) are the respective companies product groups reading this stuff?
I would like to hear from you (I've already heard from two).
3) has anyone considered piecing one entity from one vendor with another?
Direct replys appreciated, I will post a summary.
Thanks,
Mike
--
Mike Powell PPASEL
"arp, arp, arp" The mating call of the lonely packet.
Disclaimer: I speak for myself. No relation to the DUAT folks.
internet: powell@wraith.wtp.contel.com Usenet: {contel-fss}!powell
-----------[000038][next][prev][last][first]---------------------------------------------------- From: ljm@mercury.twg.com To: tcp-ip@nic.ddn.mil Cc: Subject: Re: SLIP, IP Routers and Named Pipes
>A project have come up around here that require multiple >PCs to get dial-in access to the TCP/IP network. One of the >major requirements is support for Named Pipes down to the PC. >Current plan is to use SLIP and a router with dial-in ports. > >Would someone care to recommend a PC package that would do good >SLIP emulation and a router that would be suitable for this job? > Given your Named Pipes requirement, you actually have a much more fun problem to solve. You need a TCP/IP with support for not only SLIP but also NetBIOS over TCP/IP which works through IP routers. I think we are currently the only TCP/IP product with both, but I think FTP Software will be able to provide a NetBIOS which works through routers in the near to medium future. By the way, I do have to ask. Why Named Pipes? enjoy, leo j mclaughlin iii ljm@twg.com
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: Thu, 4 Oct 90 09:40:01 pdt From: Walter Underwood <wunder@hpsdel.sde.hp.com> To: tcp-ip@nic.ddn.mil, comp.protocols.tcp-ip Subject: Re: HP TCP/IP router/bridge?
Does anyone know of a bridge or router that will allow HP hosts running
TCP/IP which speak IEEE style packets (802.2 encapsulated) to
communicate with ethernet style IP implementations?
I've answered Kevin separately, but here is the info for everyone
else:
1. The old-style HP 802.2/802.3 encapsulation pre-dates SNAP. It
uses the SAP originally reserved for IP (06) and uses a separate
protocol for address resolution (Probe). All this design was
done back in 1981-82, when no one but the 802 committee and HP
were interested in 802.
2. HP does not encourage new implementations of HP 802 and Probe,
because there are standard, and thus better, alternatives.
3. All HP products now support Ethernet and ARP, so no one has to
worry about the HP 802 encapsulation anymore. Just upgrade to
the latest networking bits.
wunder
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Thu, 4 Oct 90 10:26:00 MDT From: cpw%snow-white@LANL.GOV (C. Philip Wood) To: issm!wraith.wtp.contel.com!powell@uunet.uu.net Cc: tcp-ip@nic.ddn.mil Subject: Re: Network Monitors/Managment ... again (repost)
My experience is with Sun Microsystems, Inc. Sun Network Management product (SNM) and HP's network management system. I have spent a lot of time using SNM and find it useful. It is especially good at allowing for the incorporation of user defined applications. However, it's many features and seemingly infinite configuration capabilities are not for the novice. HP has a good product which should be the network management answer for 85 percent of the networks out there. The user interface is easy. It can learn about the networks it is attached to and provides a number of useful problem solving features. Phil
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 90 14:02:43 GMT From: eagle!news@ucbvax.Berkeley.EDU (Keith Jackson) To: tcp-ip@nic.ddn.mil Subject: Re: IBM MVS TCP/IP info wanted
NASA Lewis has the KNET product running on our VM system and from what I gather it has not been entirely happy. TCP/IP was just installed on the MVS system and the same product was also installed on VM replacing KNET. Sorry about being so vaque, but I not in charge of those systems. If you would like more info, give my a call and I can get you in touch with the appropriate system people. -- ----------------------------------------------------------------------------- Keith Jackson | phone: 216-433-5105 or Sverdrup Technology, Inc | 216-891-2946 NASA Lewis Research Center | email: vvkmj@spica.lerc.nasa.gov
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Thu, 4 Oct 90 18:32:40 EDT From: fillmore%emrcan.bitnet@ugw.utcs.utoronto.ca To: TCP-IP@NIC.DDN.MIL Subject: Reply to network file backup
We back up our two Sun 3/60 workstations to a CDC Cyber 840 by using the standard "dump" command with the output directed to a NFS-mounted file on the Cyber. We do incremental dumps every night and full dumps once per week. It's all automatic - controlled by a crontab entry. This is a very efficient way of doing it - we can back up 100 megabytes in about 25 minutes, all unattended. You also have to back up the root partition to tape once in a while in case you have to do a full restore. Try it, you'll like it! - Bob Fillmore
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 90 15:38:42 GMT From: uokmax!munnari.oz.au!bruce!merlin!morgana!ianh@apple.com (Ian Hoyle) To: tcp-ip@nic.ddn.mil Subject: Re: TCP/IP for DEPCA boards
nelson@sun.soe.clarkson.edu (Russ Nelson) writes:
>In article <CMM.0.88.654810935.beach@ddnuvax.af.mil> beach@DDNUVAX.AF.MIL (darrel beach) writes:
> Can anyone point me to drivers, software, vendors to let me run
> TCP/IP on PCs which have a DEPCA (Digitals Ethernet PC bus Adapter)
> cards. Packet drivers compatible with NCSA, KA9Q, or even a commercial
> package would be appreciated.
>Not yet, but the picture is coming into focus. We've gone from
>"Digital refuses to release programming information" (that was just a
>rumor) to "How may I help get you the information you need to write a
>packet driver?"
Wollongong's TCP for DOS has appropriate drivers etc. for DEPCA cards *but*
like PCSA, they only seem to provide full functionality on the supported PC
platforms ie IBM, Compaq etc. Clones of various types (with their myriad
BIOS's) just don't work at all sometimes. This seems to occur with
monotonous regularity.
When it does work it's just fine :-)
ian
--
Ian Hoyle
/\/\ Image Processing & Data Analysis Group
/ / /\ BHP Melbourne Research Laboratories
/ / / \ 245 Wellington Rd, Mulgrave, 3170
/ / / /\ \ AUSTRALIA
\ \/ / / /
\ / / / Phone : +61-3-560-7066
\/\/\/ FAX : +61-3-561-6709
E-mail : ianh@bhpmrl.oz.au
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 90 16:01:28 GMT From: swrinde!zaphod.mps.ohio-state.edu!samsung!ernie.viewlogic.com!curly!alan@ucsd.edu (Alan Medsker) To: tcp-ip@nic.ddn.mil Subject: Re: network file backup
I think Legato, or some company with a similar name, has such a product. I don't see the ad in Sun Tech Journal that I think might have been the last issue. Alan -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alan Medsker Viewlogic Systems, Inc. Voice: (508) 480-0881 293 Boston Post Road West Fax: (508) 480-0882 Marlboro, MA 01752 Internet: amedsker@Viewlogic.COM cc:Mail: Alan Medsker at Viewlogic CI$: 76376,662 BIX: amedsker 2 Meters: WB0SQR =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= My opinions, of course. And don't hold me to them. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 90 16:14:35 GMT From: bywater!arnor!news@uunet.uu.net To: tcp-ip@nic.ddn.mil Subject: RE: IBM 9000 TCP/IP, lpr?
> Another campus entity is looking into purchasing an IBM 9000 system, which > would run VM, and comes with some sort of TCP/IP package. They want to be > sure it works with our (BSD) network, especially for printing. Does anybody > know if it's possible for an IBM 9000 VM system to talk Berkeley lpr protocol? > Any information is most appreciated. > > -- > Bill Stapleton IBM's TCP/IP Version 2 for VM product, due out at the end of the year, includes an LPR client and LPD server. They have been written to interoperate with 4.3 LPR/LPD and work fine. If you're running our Version 1 product, I believe there is at least one LPR/LPD implementation available, from Columbia University. I believe it is free, but you'd have to contact them directly. Bill Rubin IBM TJ Watson Research rubin@ibm.com
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: Thu, 04 Oct 90 14:35:48 +0100 From: Denis.Russell@newcastle.ac.uk To: tcp-ip@nic.ddn.mil Subject: IP over X.25
I have an interest in routing IP datagrams over an X.25 network,
and would like some information on the characteristics actual
products (routers) that do this. The kind of completely
hypothetical (!) setup that interests me is a set of say 50 to
100 mainly Ethernet LANs connected by a wide-area X.25 network
with X.25 speeds in the 9.6kbps-64kbps-2Mbps range.
In the worst case one might imagine a permanent 2 * N^2
network of X.25 calls, and clearly some intermediate plan using
an hierarchy of routers would be preferable.
However, I am primarily interested in an intermediate
scenario where the X.25 calls are established and cleared down
as required. Clearly the practicality of this this would depend
on the traffic pattern - but that is not the primary focus of
this query. The primary focus is to find out whether routers
that support X.25 as an IP bearer have the right sort of
characteristic for such an application. For example, one would
require support for a substantial number of such calls (10, 20,
30?), and the automatic clearing down of calls after some
inactivity timeout. What speed X.25 is supported (preferably
well beyond 64kbps)? Does a router exploit already existing
inbound X.25 calls to send outbound datagrams or does traffic
always result in two calls, one used in each direction? What
other questions are important?
As some examples of the clarifications we would value are
that we understand that Sunlink supports only 4 X.25 calls by
default, but can be configured for any larger number. On the
other hand, the calls are never cleared due to inactivity. We
don't know whether any routers exploit X.25 in a duplex manner
or whether two calls are always/sometimes/never set up.
I'll summarise to the list if there is interest in the
results.
Denis Russell JANET: Denis.Russell@uk.ac.newcastle
Computing Laboratory Internet: Denis.Russell@newcastle.ac.uk
The University
Claremont Road Tel: (+44) 91 222 8243
Newcastle upon Tyne Fax: (+44) 91 222 8232
NE1 7RU Telex: 53 65 4 UNINEW G
ENGLAND
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 90 16:18:09 GMT From: munnari.oz.au!murdu!viccol!gjocc@uunet.uu.net To: tcp-ip@nic.ddn.mil Subject: Assigning IP addresses
What is the best method for dynamically assigning IP addresses to PC's that are directly on our main ethernet? I have heard of the BOOTP and RARP protocols, so I guess what I need is BOOTP or RARP server software. Our main machines are VAX running VMS with 6.4 CMU TCP/IP and a Sequent S27 with DYNIX (BSD 4.2 UNIX). The PCs will probably be running NCSA telnet (which does RARP I believe). Any pointers to cheap software that can assign IP addresses to the PCs on our ethernet would be welcome. Greg O'Sullivan (gjocc@csv.viccol.edu.au)
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 90 17:10:05 GMT From: hub.ucsb.edu!spectrum.CMC.COM!lars@ucsd.edu (Lars Poulsen) To: tcp-ip@nic.ddn.mil Subject: Re: Does anybody know LM-X or Lackman?
In article <1990Oct3.192349.781@resam.dk>
andrew@resam.dk (Leif Andrew Rump) writes:
>We would also like to know the address of a company called Lackman
>who supplies TCP/IP software for UNIX systems.
Results of WHOIS LACHMAN.COM:
----------------------------
Lachman Associates, Inc. (LACHMAN-DOM)
1901 North Naper Boulevard
Naperville, IL 60540-1031
Domain Name: LACHMAN.COM
Administrative Contact:
Goldman, Ezra (EG56) ez%laidbak@SUN.COM
(312) 505-9100 ext 233
Technical Contact, Zone Contact:
Alexander, Steve (SA65) stevea@i88.isc.com
(708) 505-9100 ext 256
Record last updated on 01-Sep-88.
Domain servers in listed order:
LAIZY.LACHMAN.COM 192.35.52.1
LAIDBAK.LACHMAN.COM 192.35.52.2
--
/ Lars Poulsen, SMTS Software Engineer
CMC Rockwell lars@CMC.COM
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 90 18:14:00 GMT From: van-bc!ubc-cs!news-server.csri.toronto.edu!utgpu!cunews!bnrgate!bwdls49!linegar@ucbvax.Berkeley.EDU (Derick Linegar) To: tcp-ip@nic.ddn.mil Subject: Ethernet Address Uniqueness...
In trying to debug a problem we are having here with our file server with 2 ethernet boards connected to 2 *different* subnets on the same network, our vendor eluded to us that the 2 ethernet cards assume the *same* Ethernet address, obtained from the primary ethernet board. Of course, warning bells are going of here. Now I've been searching the RFC and IEEE docs and I cannot find any documentation that sort of says that Ethernet Addresses are assigned to Ethernet boards, not hosts. Anyone have an idea where it might be. I cannot go back to the vendor and say " .... well everyone *knows* that ethernet addresses *must* be unique..." -derick- -- #include <disclaimer.h> Derick Linegar, Internet Systems 4P27, Bell-Northern Research BITNET: LINEGAR@BNR.ca P.O. Box 3511 Station C UUCP: ...uunet!bnrgate!bwdls49!linegar Ottawa ONT. K1Y 4H7
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 90 19:01:08 GMT From: synoptics!sblair@decwrl.dec.com (Steven Blair) To: tcp-ip@nic.ddn.mil Subject: Re: network file backup
We here use a very nive networked backup system called "budtool(BackUp Daemon Tool) from Delta Microsystems in Livermore Calif. Their phone is (415) 449-6881. We do nightly -0- backups of 10 Gbytes of machines. Without a hitch. Has an incredibly felxible timing mechanism, history mechanisms, scheduling tools, labeling tools, tape testing tools, and is affordable. We've got no releationship with them, than a very satisfied customer<->vendor relationship. They have always answered calls promptly, provided bug fixes promptly, and are generally very nice folks. The Legato Networker was evaluated here. We already had too much invested in Delta Micro's solution to justify using it. -- Steven C. Blair Network Operations Center SynOptics Communications Inc. Mountain View, California INTERNET: sblair@synoptics.com sblair@excalibur.synoptics.com PROBLEMS/EMAIL: HOSTMASTER@SYNOPTICS.COM postmaster@synoptics.com ---->>RIP Stevie Ray Vaughan 1954-1990 You Will Be *Missed*<<----
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 90 19:59:18 GMT From: eplrx7!mcneill@louie.udel.edu (Keith McNeill) To: tcp-ip@nic.ddn.mil Subject: Where is latest/greatest version of proxyarpd?
Subject says it....I tried comp.sources.wanted but I got no replies.
Thanks,
Keith
--
Keith D. McNeill | E.I. du Pont de Nemours & Co.
eplrx7!mcneill@uunet.uu.net | Engineering Physics Laboratory
(302) 695-9353/7395 | P.O. Box 80357
| Wilmington, Delaware 19880-0357
--
The UUCP Mailer
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: Fri, 05 Oct 90 09:40:12 -0700 From: jqj@hogg.cc.uoregon.edu To: fillmore%emrcan.bitnet@ugw.utcs.utoronto.ca Cc: tcp-ip@nic.ddn.mil Subject: Re: Reply to Ethernet Address Uniqueness...
Having the same MAC-level address for all interfaces (phrased differently, associating the MAC-level address with the NODE rather than with the INTERFACE) is part of the spec for both DECNET IV and XNS. It falls out of a design that has an algorithmic link between the MAC address and the protocol address. Many people believe that having a protocol address that belongs to the node rather than to the interface is a Good Idea, and that doing it the other way was a bad decision in the IP suite. I don't have a strong opinion, but I do know that the XNS/DECNET way of doing things makes routing to multihomed hosts easier. In the IP world there is no unambiguous way to decide whether 2 IP addresses refer to the same host; sure I can look in the DNS, but there is no guarantee that either or both addresses will be in the in-addr.arpa tree. Other people like the idea of algorithmic mapping from protocol to MAC address. It means that you don't need something like ARP, but it also limits your flexibility substantially, especially on physical networks like arcnet or 3mb Ethernet where the range of MAC addresses is very limited or hardwired in the interface. And it of course fails to generalize to cases where one needs to support multiple protocol stacks that each want to change the MAC address based on the protocol address!
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 90 23:36:19 GMT From: pilchuck!amc-gw!morpho!erik@uunet.uu.net (Erik Vollemaere) To: tcp-ip@nic.ddn.mil Subject: R/S 6000 raw I/O on Ethernet
We're attempting to establish communications between an IBM
R/S 6000 and a remote host with a CMC-20 board through Ethernet.
The communication must be done through non-encapsulated Ethernet
packets. The idea is to send it a packet of type AM and to
wait untill we receive a -broadcast- packet from it of type
PU. Then we send it a packet of type BS with the bootstrap
program. The first portion of this works fine. We open the
device (in this case /dev/ent0) and write() the packet. The
remote host responds with alternating BR - and PU type packets
(verified through an Ethernet analyzer). The problem is that
we do not "recognize" the packets from the remote host. Reads
fail with an EIO error ("An I/O error occurred while reading
from the file system"). Even if we get the read to succeed
(suggestions?), we prefer not to have to analyze every packet
looking for our target.
The question is: what call(s) do we use and how do we set it up
to return an Ethernet broadcast packet of type PU and ignore
everything else? We can accomplish this on different platforms
using raw socket I/O but those same calls fail on the R/S 6000.
The error messages are "Can't assign requested address" or
"Destination address required" (protocol interference). IBM
recommended using the device driver directly (/dev/ent0) and
that works fine for the write portion of the problem, but we're
now stuck on the read portion. We've been waiting for a solution
from IBM but so far their suggestions have not given us the
desired result.
___________________________________________________________________________
Standard disclaimer... the above opinions are mine, all mine.
Erik J.P. Vollemaere (B) / (VL)
____________________________________________________________________________
amc-gw!morpho!erik
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 01:20:32 GMT From: agate!linus!philabs!ttidca!quad1!srhqla!avatar!kory@ucbvax.Berkeley.EDU (Kory Hamzeh) To: tcp-ip@nic.ddn.mil Subject: Need a RARP Demon
Does anyone know where I can get my hands on source code for a Reverse
ARP demon to work on a Sun Sparcstation? I know Sun already has one, but
we have a special application where we need to slightly modify the Sun
version.
Thanks,
--kory
--
-------------------------------------------------------------------------------
Kory Hamzeh UUCP: avatar!kory or ..!uunet!avatar!kory
INTERNET: kory@avatar.com
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 90 01:23:19 GMT From: bacchus.pa.dec.com!mogul@decwrl.dec.com (Jeffrey Mogul) To: tcp-ip@nic.ddn.mil Subject: Re: 9 interesting & challenging problems for Netman
In article <9009210641.AA20321@ucbvax.Berkeley.EDU> J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) writes: >1. given the trace of packets between two end points on a LAN, >and a FSM, petri net, lotos/csp/ccs/Estelle spec for the protocol, >detect protocol (elements of procedure) errors. (easier, do the same >given ASN or XDR for packet formats:-) > >2. Given same data, automatically ascribe performance problems >to incorrect packet size, timeout, window etc... > This is similar to research reported on by Bruce L. Hitson in "Knowledge-