HDTenEightyP/NetNews huggingface dataset:
From: craa85@ccsun.strath.ac.uk ( D.W.Stevenson)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Future of IP routers
Date: 1 Sep 92 16:44:51 GMT
Organization: University of Strathclyde


In article <1804f8INNk48@agate.berkeley.edu>, cliff@garnet.berkeley.edu (Cliff Frost) writes:

|> 
|> I'm new to this stuff and trying to learn, so that may explain why this seems
|> backwards to me.  
|> 
|> Here's my naive reasoning:  Say I want to do a DNS query to find a
|> VCI/VPI pair for a remote station.  You seem to be saying that the remote
|> station's DNS server will tell me about the remote station's VCI/VPI pair,
|> but that is meaningless to me--I need to know the VCI/VPI local to me, no?
|> 

I'm afraid the naive reasoning is on my part. You are of course correct. The
fact that DNS is a distributed database escaped my attention for a moment.

Using a centralised database would not cause any problems, but the fact
that queries can be answered by a remote DNS means that VCI/VPI pairs are useless
except to hosts local to an ATM network and DNS domain.
 
-- 
Dave Stevenson 				d.w.stevenson@strath.ac.uk
Computer Centre Communications		Tel : 44 41-552 4400 ext 3461
University of Strathclyde
Glasgow, Scotland, U.K.
From: shah@angelo.amd.com (Amit Shah)
Newsgroups: comp.dcom.cell-relay
Subject: Re: >>>>Future of IP routers
Date: 30 Aug 92 19:45:36 GMT
Organization: Advanced Micro Devices, Santa Clara, CA

In article <p6dueak@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In article <1992Aug28.164008.4015@sics.se>, craig@sics.se (Craig Partridge) writes:
>> ...
>> (any FDDI throughput test over a real ring that doesn't mention the TTRT
>> that the testers set for the network is worthless) ...
>
>While I agree with the rest of Craig's article, I disagree with this
>caveat.  FDDI TTRT by itself does not matter.  What matters is how
>often you get to transmit and consequently how much of the time the
>ring is idle.  Unless you are using TCP Large Windows (as Cray does and
>we all should), legal TTRT's do not crimp your style.  FDDI is less
>than 12.5KBytes/millisecond, the maximum standard TCP window is only
>64KBytes, and the minimum legal T_Req is on the order of 4 ms.
>
I have a slight disagreement with your statement that FDDI TTRT by itself
does not matter.  It depends on the type of traffic you put on the network.
If you are talking about bursting traffic in excess of 100 Mbps (such as
high-end imaging), with >2 stations on the ring then the
TTRT does matter (Lower TTRT will have lower throughput and buffer overflows).

However, if you are talking about normal traffic (burst rates not exceeding
100 Mbps) then you are correct within a few percent points.

>No interesting maximum-speed FDDI benchmark is going to be run on
>anything but a practically idle FDDI ring.  Very few FDDI rings have
>physical latencies large enough to matter, so that how frequently you
>must release the token mostly affects how frequently you need, expect,
>or hope to get TCP ACK's.
>
>
>Vernon Schryver,  vjs@sgi.com


--
Amit Shah
Sys. Engg. & Prod. Planning Engineer		Ph.:(408)987 2479
High Speed Networking   			Fax:(408)987 2814
901 Thompson Place, M/S 70			email:amit.shah@amd.com
Newsgroups: comp.dcom.cell-relay
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: Another Problem
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Mon, 31 Aug 1992 03:54:04 GMT

In article <1992Aug30.164226.2031@iscnvx.lmsc.lockheed.com>, bantha.decnet.lockheed.com!young writes:
> This newsgroup continues to debate the interface between TCP/IP routers
> and ATM. Must be an important application.
> 
> Now here is another problem which ATM might solve.
> 
> As I look around this company I see hundreds of little cubic foot computers
> on each desktop, exactly alike, distributed geographically.  Some companies
> literally have thousands of these things.
> 
> Imagine that an account executive wants to read into his spread sheet the
> entire daily summary of mail orders spread over a number of distributed
> offices.  Thus, he wants to extract a particular file located in each of
> a large set of desktop machines.  
> 
> Here are some restrictions to the solution:
> 
> 1) This problem applies to about 80% of the USA's largest companies, who
> spend some 1 trillion dollars on solutions each year.
> 
> 2) The only host address this account executive wants to deal with is 
> "computers on the desktops of account clerks".
> 
> 3) This company swears by twisted pair wiring, as do 80% of all users.
> 
> 4) This applications requires low latency.
> 
> 5) This customer would prefer to have his entire computer system composed
> of the distributed coordination of these small machines, he hates 
> mini/maxi/mainframe computers.
> 
> 6) This customer hates the hassle of maintaining servers, although he is 
> willing to tolerate some file backup facilities.



Are you sure that ATM is an obvious part of a solution to this kind of
problem?

Wouldn't a naive ATM based solution involve setting up virtual circuits
to each of the target machines, some fixed number at a time, probably
one, with the consequent terrible response times?  And wouldn't a naive
ATM based system involve a lot of manual configuring?

Doesn't this sound more like an application for a multicast based
"distributed" application?  Perhaps some kind of multicast remote
procedure call?  Using UDP/IP multicast?

That is not to say that the layers below UDP/IP might not involve one
or more wide area or local ATM circuits.


Vernon Schryver,  vjs@sgi.com
From: de@fokus.gmd.de (Dirk Elias)
Newsgroups: comp.dcom.cell-relay
Subject: still AAL5-CRC32
Date: 3 Sep 92 16:53:55 GMT
Organization: GMD-Fokus (Berlin)

Sorry, I touched the wrong button! :-)

Still I'm talking about "on-the-fly" and "fly-by".

I just want to point out that "context-switching" after every cell is
lots of work, just to calculate CRC.  
Has anybody knowledge of CRC hardware, performing "context-switching" on
it's own? (something with integrated memory and some kind of control interface)
Concerning the "fly-by" method: 
If I would like to have about 100 VC's using AAL5 and I had to store every packet 
till it'scompleted, I would have to allocate 64 KBytes for every VC. Since there is 
still no CPCS-PDU header defined for AAL5, where a packet-size information could be
transmitted, I have to assume the maximum CPCS-PDU size! This would result in
several MBytes of interface-board memory. (Sometimes I remember that S-BUS card
size in my nightmares)

Dirk


-- 
------------------------------------------------------------------------------
From: Dirk Elias                     Tel. ++49-30-25499-245
      c/o GMD-Fokus                  FAX  ++49-30-25499-202
      Hardenbergplatz 2              e-mail: elias@fokus.berlin.gmd.dbp.de
      1000 Berlin 12
      F.R.G.
-----------------------------------------------------------------------------
Newsgroups: comp.dcom.cell-relay
From: brian@dxcern.cern.ch (Brian Carpenter   CERN-CN)
Subject: Re: Future of IP routers
Organization: CERN European Lab for Particle Physics
Date: Mon, 31 Aug 1992 13:30:20 GMT

In <1992Aug31.091218.21819@fokus.gmd.de> icarus!mbu@fokus.gmd.de (M. Burak) writes:

Markus:

>Brian Carpenter writes:

>>Sorry, as usual CCITT and their friends are too far behind reality.
>>IETF and the ATM Forum will have resolved all these questions before
>>CCITT even formally votes on AAL5.

>Sounds very good. But please tell me how will IP work over an ATM network with
>AAL type 5? What is the concept of this approach? 
>Is connection setup required prior to sending CL-data or do you assume a fully
>meshed network? What function in the ATM network will perform routing of IP packets if you 
>only have ATM switches providing an ATM layer? 
>I have no idea. Is there anybody who can help me to answer these questions?

The IETF has to develop answers to these questions, and this will
most likely take place in a bottom-up process. My guess is "yes", i.e.
routers, fully-meshed subnets and dynamic call setup will coexist.
In the dynamic case each host has to contain call setup logic
and a timer to tear down calls that have been idle for too long.

The work done in IETF so far is on the lowest level, how IP packets
will be mapped onto AAL5 PDUs. Once this draft is stable it could
be used immediately in pre-configured networks between hosts and/or
routers - i.e. in any context where the VCI/VPI to reach the next
system is known.  (It would also work for CLNP, IPX etc as far as
I know.)

The next stage is "for further study" and I suspect that not much
will happen until Q.93B is stable. I have personally developed the
view that the next stage in the bottom-up design process is to enhance
DNS to be capable of returning arbitrary switched network addresses
as well as IP addresses: initially these could be VCI/VPI values,
later on E.164 or whatever. Then the procedure to establish an IP
based session to foo@bar.sna.fu would be
 - issue DNS request for that address
 - if reply indicates a specific VCI/VPI pair, use it immediately
 - if reply indicates an E.164 address/subaddress, invoke Q.93B
   to establish VC/VP (unless already open)
 - else go to non-ATM processing

You will notice this does not need ARP (see my previous posting)

Comments on this are wanted!

Regards,
	Brian Carpenter CERN, brian@dxcern.cern.ch
			voice +41 22 767 4967, fax +41 22 767 7155
Newsgroups: comp.dcom.cell-relay
From: lcz@dptspd.sat.datapoint.com (Lee Ziegenhals)
Newsgroups: comp.dcom.sys.cisco
Subject: Errors on IGS/R console
Date: 24 Aug 92 03:30:04 GMT
Organization: Datapoint Corporation, San Antonio, TX

I am getting a lot of the following errors on my IGS/R.  So far they do not
appear to be effecting the operation of the unit.  I am simply curious to
their significance and whether I should be concerned about them.  The error
message is clear enough as to *what* is happening, but it doesn't say much
about *why* :-).  I usually get 40 or 50 of these message a day.  Always the
same error, although the last few addresses in the traceback differ.

%SYS-3-INVMEMINT: Invalid memory action (malloc) at interrupt level
-Process= "*Sched*", ipl= 4
-Traceback= 161F4 201FE 67084 1B0F4 4510 104C 1000632 1008C98
%SYS-3-INVMEMINT: Invalid memory action (malloc) at interrupt level
-Process= "*Sched*", ipl= 4
-Traceback= 161F4 201FE 67084 1B0F4 4510 38B52 104C 1000632
%SYS-3-INVMEMINT: Invalid memory action (malloc) at interrupt level
-Process= "*Sched*", ipl= 4
-Traceback= 161F4 201FE 67084 1B0F4 4510 38EE4 38B52 104C
Newsgroups: comp.dcom.sys.cisco
From: skl@wimsey.bc.ca (Samuel Lam)
Subject: Re: Router Problem Caused by Errant Host
Reply-To: skl@wimsey.bc.ca (Samuel Lam)
Date: Sun, 30 Aug 1992 22:15:45 GMT

In article <9vdnx8#.badboy@netcom.com>, badboy@netcom.com (Jay Keller) wrote:
>what troubleshooting techniques would have led our team to
>discover the exact nature of the problem more quickly?

When things stop working, try the following on a host that's
inside the isolated part of the network:

 1) use "ping" to see where you can't reach, then
 2) use "tracroute" to see where that path stops, then
 3) use "arp" to see if the IP address of the next router
    maps to the correct Ethernet address.

If the test in 3) fails, the router's IP address had been stolen
by another host on the same Ethernet.

...Sam
-- 
<skl@wimsey.bc.ca>
Newsgroups: comp.dcom.sys.cisco
From: ray@nmt.edu (Ray Piworunas)
Subject: Using a high-speed modem on an ASM terminal server.
Organization: New Mexico Institute of Mining and Technology (NM Tech).
Date: Wed, 2 Sep 1992 20:39:48 GMT


I have an ASM-32 that I am trying to get a "FaxModem" made by ZOOM
Telephonics, Inc. to work on.  I can't seem to establish a connection
above 9600-baud.  I would appreciate any help readers of this group
could give.  I'm not trying to do FAX transfers, just ordinary data
connections.

The serial line of the ASM the modem is on is setup as follows.
#
#  Fast modem.
#
line 40
access-class 1 out
no private
exec-timeout 2
session-timeout 45
modem ri-is-cd
flowcontrol hardware
autobaud
databits 8
parity none
stopbits 1
length 24
width 80
terminal-type dialup
location TCC 2B - 14400-baud (MNP) dialup.


I have wired the serial connection as shown below.
	ASM-32		Modem
	---------------------
	SG (7)		SG (7)
	TD (2)		RD (2)
	RD (3)		TD (3)
	RI (22)		CD (8)
	DTR (20)	DTR (20)
	CTS (5)		CTS (5)

The modem has the following settings (other than the factory defaults):
&C1	Have CD follow condition of modem carrier.
&D3	Reset modem after DTR drops.
S0=1	Set for auto-answer.
S36=5	Attempt an MNP connection, if it fails attempt an asynchronous
	(direct mode -- don't buffer data) connection.
These settings were saved as configuration zero.

I have been able to establish connections to the ASM at:
	2400-baud, using a 2400-baud modem (Practical Peripherals PM2400SA),
	4800-baud, using a Prometheus ProModem 9600-EC,
	9600-baud, using a Prometheus ProModem 9600-EC.
Once at the ASM prompt things work as they should.

I can't establish a connection to the ASM at 19200-baud, nor at
38400-baud.  From looking at the ASM port (using sh li 40) at various
times during the connection attempt it appears the ASM is in its
autobauding mode.  It can't seem to lock on to the right speed.
Occasionally it will show that the line has received a BREAK.

I have tried setting the ASM line to a speed of 38400 instead of
autobauding but that didn't help any with the attempt to connect at
38400.  (I didn't try a slower speed connection with the ASM port at
38400 since the 38400 connection didn't work).

I'm not sure if the error correction, or compression, at the higher
speeds might be messing things up since I've never worked with these
features before.  It seems that that shouldn't be a problem in just
getting to the terminal server prompt though.

Well that's as far as I've gotten with it.  I'm pretty well stuck right
now.  If you need more information please ask (I know I do!).

Thank you,
Ray Piworunas (ray@nmt.edu).
From: taylorb@fcs280s.ncifcrf.gov (Brent Taylor)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Decnet traffic seeing intermittent delay across two routers.
Date: 27 Aug 92 13:02:25 GMT
Organization: Frederick Cancer Research and Development Center

We are seeing the same kind of problems.  We have an AGS+ connected to two
CGS's serialy routing IP and bridging DECnet.  All three routers are running
9.0(1).  All three routers (or mainly the AGS+) goes out to lunch for a few 
seconds every hour.  When the router(s) goes out, no IP or DECnet traffic flows
and I can't login to the routers.
Anybody know what's going on??  Cisco has sent new microcode but still the 
same results.

-- 
----------------------------------------------------------------------
| later,                   B-|            (TAYLORB @ NCIFCRF.GOV)    |
----------------------------------------------------------------------
Newsgroups: comp.dcom.sys.cisco
From: tannerc@cu18.crl.aecl.ca (Chris Tanner)
Subject: PPP to Wellfleet routers
Organization: AECL-Research
Date: Fri, 28 Aug 1992 22:54:03 GMT

Greetings

I sent this question to TAC but have not recieved a reply (except for a
message assigning a case number).

We would like to connect a Cisco router with a Wellfleet router using
PPP protocol. According to the manual, PPP can only pass IP traffic.
Is Cisco planning to support other traffic such as NOVELL over such a
link. If so, When?

Also, how does one find out when new releases are issued, and what they
conatain.

THanks for your help.

Chris
-- 
Chris Tanner                  Email: tannerc@CU18.CRL.AECL.CA
AECL Research                 Phone: (613) 584-3311 X4053       
Chalk River, Ont.             FAX:   (613) 584-1082
Canada, K0J 1J0
Newsgroups: comp.dcom.sys.cisco
From: Phil Remaker <remaker@cisco.com>
Subject: Assigned numbers RFC
Date: 2 Sep 92 12:45:40 PDT
X-Mailer: ELM [version 2.3 PL11]

> RFC 1060 is very useful, but there are other
> lists, as well.  
>

FYI:  RFC1060 is obsoleted by RFC1340, which is more extensive.

 
> - Andrew E. Birner, Zenith Electronics Corporation -
> 
> 


-- 
Phillip A. Remaker remaker@cisco.com  
cisco Systems Customer Engineering  800-553-24HR
1525 O'Brien Drive  Menlo Park, CA 94025 
Newsgroups: comp.dcom.sys.cisco
From: Jim Forster <forster@cisco.com>
Subject: Re: SMDSs & cisco 
             <1992Aug25.235612.28179@umbc3.umbc.edu> 
Date: 31 Aug 92 22:54:15 PDT

> Are there any cisco models which will not support SMDS?
> I know the AGS+ is ok, what about the rest of the product line?

All models support it.  For T-1 SMDS an RS-449 interface is required.
For T-3 SMDS an AGS+ with an HSSI is required.

  -- Jim
Newsgroups: comp.dcom.sys.cisco
From: Peter Hakanson <peter@cyklop.volvo.se>
Subject: bug in 9.0(1) ?
Mailer: Elm [revision: 66.33]
Date: 31 Aug 92 11:11:27 METDST

Recently we discovered strange behaviour in 9.0(1).
We route tcp/ip decnet and appletalk and bridge LAT in a 
newly installed MGR. 
ARP requests done on lan-s connected to this router are
FORWARDED to all interfaces! Even worse, since they are
forwarded to a AGS with 8.3(3), the AGS has no way of
protecting himself, but instead the AGS will put the ARP-s
to all of hi's interfaces. In one case he substituded the
original ip-address with the AGS ip-address.

Looking on the faulty MGS with 'debug arp' shows:
ARP req filtered src 131.97.100.21 0800.0101.68c1, dst 131.97.21.15 0000.0000.0000 wrong cable
ARP req filtered src 131.97.100.23 0800.200f.2991, dst 131.97.23.11 0000.0000.0000 wrong cable
IP ARP: rcvd req src 131.97.100.26 0800.0101.6e3d, dst 131.97.100.99

The 'wrong cable' is an indication of the problem.

A 'fix' is to define a output-type list that explicity defines 
which types are to be forwarded(and not including ARP).
-
Peter Hakanson  VolvoData Dep 2230 phone +46 31 66 74 27
From: badboy@netcom.com (Jay Keller)
Newsgroups: comp.dcom.sys.cisco
Subject: Router Problem Caused by Errant Host
Date: 28 Aug 92 16:50:19 GMT
Organization: Netcom - Online Communication Services (408 241-9760 guest)

If my questions are naive, I apologize, but I am fairly new to the
science of networking.
 
We recently experienced a failure of our Cisco router due to the following
scenario:

One of our workstations, running IBM TCP/IP for OS/2, was improperly
configured.  The file that controls the IP address and the default routing
was typo'ed such that the machine was accidentally assigned the same IP address
as the Cisco router.  This brought down a major part of our network as the
Cisco stopped routing.  Several hours were spent finding the problem.

First of all, what troubleshooting techniques would have led our team to
discover the exact nature of the problem more quickly?

Secondly, is there any way to protect against this sort of thing?

Regards,
 
Jay Keller
ROLM Systems
Santa Clara, CA, USA
badboy@netcom.com
Newsgroups: comp.dcom.sys.cisco
From: rv@deins.informatik.uni-dortmund.de
Subject: Re: Subnetting and class B nets 
             <7897.714929735@munnari.oz.au> 
Date: 27 Aug 92 19:21:34 N

  >     Date:        27 Aug 92 16:36:57+0200
  >     From:        Peter Merdian <merdian@rus.uni-stuttgart.dbp.de>
  >     Message-ID:  <2299*merdian@rus.uni-stuttgart.dbp.de>
  > 
  >     According to RFC 950 only one subnetmask is allowed for an IP network:
  > 
  > I don't think this is true - RFC950 is not highly clear on
  > the point, but it does seem to suggest that different masks
  > on different interfaces is possible - and it never says that
  > that should only happen if the different interfaces are on
  > different nets.
  > 
  > The problem was never really the spec, but the implementations,
  > which with any luck will be gradually getting fixed.
well, I hear of systems manufactured today (but not by Cisco:-) still
not supporting subnet masks - so fixing can take quite some while.

Regarding the subnet support on Cisco routers:

- I remember old releases that copied the subnet mask specified from the
  "address" config command to all interfaces connected to subnets of the
  same common net - thus enforcing a common mask

- I think recent releases allow to configure different masks;

I think I did not see any documentation telling about
- the old restriction
- removal of the restriction
- explanation what the routers actually are doing now with different masks
  (just straight forward the right thing?)
  
- Ruediger


Ruediger Volk
Universitaet Dortmund, Informatik IRB				DE-NIC
Postfach 500 500
D-W-4600 Dortmund 50
Germany

E-Mail: rv@Informatik.Uni-Dortmund.DE
Phone:  +49 231 755 4760                 Fax:  +49 231 755 2386
From: battle@umbc4.umbc.edu (Rick)
Newsgroups: comp.dcom.sys.cisco
Subject: SMDSs & cisco
Date: 25 Aug 92 23:56:12 GMT
Distribution: usa
Organization: Univ. of MD, Baltimore County

Are there any cisco models which will not support SMDS?
I know the AGS+ is ok, what about the rest of the product line?

Thanks,


Rick
Newsgroups: comp.dcom.sys.cisco
From: Tom Sheppard <toms@bnr.ca>
Subject: Re: AGS fan noise
Organization: Bell-Northern Research, Ltd.
X-Useragent: Nuntius v1.1
     <1992Aug18.151833.24096@magnus.acs.ohio-state.edu>
     <1992Aug18.175631.28045@texhrc.uucp>
Date: Thu, 27 Aug 1992 14:45:16 GMT

Actually, I worry about the abrasion that's occurring to the equipment
from the airborne dust particles impacting on the chips and cables and
supersonic speeds. Does the cisco incorporate micrometeorite protection?
Newsgroups: comp.dcom.sys.cisco
From: exubho@exu.ericsson.se
Subject: X.25 line utilization???
Date: 21 Aug 92 08:47:57 -0500


Hi,

I have some statistics I have been gathering from one of my packet
switch nodes within my company's private X.25 network.  I have been
monitoring the incoming and outgoing bit/sec data rates between
Richardson Texas and Stockholm Sweden.

We have a full duplex communications link capable of 112
kilobits/sec of data throughput.  We have recently gotten into a
quarrel over what the utilization of the link is.  

Here is the scenario.  My statistics tell me that I have the
following:

40,000 bits/sec input data rate
60,000 bits/sec output data rate

I think that the utilization of our line during this time (expressed
as a percentage) is ((40,000 + 60,000)/112000) * 100%

while some others here think that the utilization of our line
(expressed as a percentage) is gotten by taking the higher of the
two data rate figures and dividing that by the maximum data rate, or
(60,000/112000)*100%.

Does anyone have any input on which is the right way to express the
utilization of our link?  Any input would be appreciated.

Blake Holman
Ericsson Network Systems, Inc.
Richardson, Texas
(214) 997-6784
Newsgroups: comp.dcom.sys.cisco