HDTenEightyP/NetNews huggingface dataset:
From: Victor Reijs <Victor.Reijs@surfnet.nl>
Subject: V.35 DCE port on cisco
Phone: +31 30 310290
Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL
Organisation: SURFnet bv
Telefax: +31 30 340903
Date: 25 Sep 92 13:55:45 +0200

Hello all of you,

I have a problem with connecting a cisco to a Northern Telecom DTE V.35 X.25 port.
The cisco has been provided with the cisco appliques and cables, so that it is
configured as an DCE V.35.

The problem is that the cisco needs the DTR signal to function, while according
to the V.35 standard this DTR signal (108) is not needed (Table 1/V.35, page 241
of the Red Book of CCITT). Northern Telecom V.35 DTE does not provide the DTR
signal, so you can see that it does not work (we have a method of correcting
this: connect RTS to DTR), but at this moment I am more looking at the formal way
to go. Change the NT interface of change the cisco interface!

I hope somebody can help me with this problem. Does somebody has simular
problems, is the standard correct. etc...???

What is the position of cisco???


All the best,


Victor
Newsgroups: comp.dcom.sys.cisco
From: Vince Fuller <vaf@Valinor.Stanford.EDU>
Subject: Re: ip accounting
Usmail: Pine Hall 115, Stanford, CA, 94305-4122
Date: 2 Oct 92 10:29:11 PDT
Office: Spruce Hall F15, (415) 723-6860

    Now, you may say "Wow, 1MB for accounting!  That's too much!"  But, the
    street price is only $25 for this memory, so its not really expensive to
    use in this fashion.  (And yes, I know, memory in CSC/3's is starting to
    get a bit tight).

$25/meg? Yes in an absoluete sense, but definitely not when talking about
non-upgradeable cisco CPU's. A more reasonable number for cisco users is
$5000/12 = $416.66/Meg. This is based on the cost of adding 12Mb to a router
by replacing a CSC/3 with a CSC/4 (for which, if memory serves, cisco gives a
$1500 credit towards the purchase of a $6500 CSC/4).

Any chance that future cisco CPUs will have a field-upgradeable memory design?
It may bring in more $$$ to force customers to buy new CPUs every year or two
when all they need is more memory, but it certainly doesn't make long-time
customers very happy. It's also a good way to guarentee that many customers
will continue to use obsolete software versions for a very long time in the
interest of preserving installed base investment. For example, we simply
can't afford to replace the 50 or so CSC/2's we have, so we'll be running
pre-9.0 software for a very long time to come.

	--Vince
From: Jaap.vanGinkel@hto.rhij.nl (Jaap van Ginkel)
Newsgroups: comp.dcom.sys.cisco
Subject: Strange TCP problem
Date: 5 Oct 92 13:11:14 GMT
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R4).


We have a strange problem with a Cisco MGS, one of the 4 serial ports
on a 4S board breaks of TCP connection.
The strange thing is that ICMP pings of any size and any nummber
(even when I flood the interface) have no problems at all.
The same serial interface is used for IPX which works fine also.
Because IPX and ICMP work OK and TCP gives problems, I supposed it
would be a configuration problem. But all ports are configured the
same and only one malfunctions. I tried to swap two lines and
connected a different modem which serves a differnt location. The
problem moved to the new line which was connected to the bad serial
port.
The first few packets of a Telnet session find their way through they
should, but after about 5 or 6 packets the connection seems stuck
because the acknowledgments seem to get lost.
Can anyone point me out why this seems to be a hardwareproblem
(swapping ports moved the problem) though the serial port seems to be
fine (for IPX and ICMP) wich points to a configuration fault.

Jaap








**********************************************************************
Jaap van Ginkel              internet: Jaap.vanGinkel@hto.rhij.nl
Postbox 357                  bitnet:   SURF078@HTIKUB5
7400 AJ Deventer (Holland)   X400:     G=Jaap; S=vanGinkel; OU=hto;
phone     (..) 31 57 00 20917          O=rhij; PRMD=surf;
fax       (..) 31 57 00 37820          ADMD=400net; C=nl.
semaphone (..) 31 658707001
Newsgroups: comp.dcom.sys.cisco
From: martinr@mayo.edu (Robert Martin)
Subject: Multicast storms
Date: 29 Sep 92 13:27:25 -0500

We had some Ethernet instability at the time we were trying to replace
our Vitalink bridge/routers with Cisco systems.  We never found all of
causes, but some corrective actions finally provided a stable network.
This also caused us to review our use of multiport transceivers including
DELNIs from DEC.  Articles in recent months and our move to 10baseT has
prompted us to try and "over-engineer" our Ethernet in the near future.
This conservative approach served us well on Token-ring.  Labor is always
hard to come by, so we need to avoid quick and easy changes.

Just because you can do something doesn't mean you should.

"Networking is not a thing to do.  It exists on its own."
Newsgroups: comp.dcom.sys.cisco
From: Jimo <jimo@cisco.com>
Subject: Re: please give your remarks 
             <"survis.sur.503:28.08.92.16.22.14"@surfnet.nl> 
Date: 28 Sep 92 13:14:46 PDT


Amazing as it seems, DTR is not in fact called out
in the v.35 specification.  However most implementations
do in fact have this signal including cisco.  One 
specific feature actually requires DTR: dial demand
routing via v.25bis.  Without DTR this feature would 
not be supportable on the northern telecom device.

I recommend the workaround you've used, or connecting
DSR and DTR together.

-Jim O'Neil
cisco Systems

> Return-Path: Victor.Reijs@SURFnet.nl
> Received: from dirt.cisco.com by stout.cisco.com with TCP; Mon, 28 Sep 92 09:23:38 -0700
> Received: by dirt.cisco.com; Mon, 28 Sep 92 09:23:24 -0700
> Resent-Date: Mon, 28 Sep 92 17:22:10 +0100
> Received: from survis.surfnet.nl by wolf.cisco.com with TCP; Mon, 28 Sep 92 09:22:19 -0700
> Received: from localhost by survis.surfnet.nl with SMTP (PP) 
>           id <12500-0@survis.surfnet.nl>; Mon, 28 Sep 1992 17:22:12 +0100
> To: cs@cisco.com
> Subject: please give your remarks
> Organisation: SURFnet bv
> Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL
> Phone: +31 30 310290
> Telefax: +31 30 340903
> Date: Mon, 28 Sep 92 17:22:10 +0100
> From: Victor Reijs <Victor.Reijs@SURFnet.nl>
> Message-Id: <"survis.sur.503:28.08.92.16.22.14"@surfnet.nl>
> Resent-From: CS-Forward@cisco.com to Appliques-Cables     (weight-800)
> 
> 
> Hello all of you,
> 
> I have a problem with connecting a cisco to a Northern Telecom DTE V.35 X.25 po
> rt.
> The cisco has been provided with the cisco appliques and cables, so that it is
> configured as an DCE V.35.
> 
> The problem is that the cisco needs the DTR signal to function, while according
> to the V.35 standard this DTR signal (108) is not needed (Table 1/V.35, page 24
> 1
> of the Red Book of CCITT). Northern Telecom V.35 DTE does not provide the DTR
> signal, so you can see that it does not work (we have a method of correcting
> this: connect RTS to DTR), but at this moment I am more looking at the formal w
> ay
> to go. Change the NT interface of change the cisco interface!
> 
> I hope somebody can help me with this problem. Does somebody has simular
> problems, is the standard correct. etc...???
> 
> What is the position of cisco???
> 
> 
> All the best,
> 
> 
> Victor
> 
> 
> P.S. Also send over cisco@spot.colorado.edu (but still no reactions:-(

Newsgroups: comp.dcom.sys.cisco
From: Lee Pang <pang@cisco.com>
Subject: Re:  serial interface disabled status
Date: 6 Oct 92 11:49:32 -0700


We will disable the interface momentarily if we see a lot of input errors within
a certain time window. Please check your input errors.

Lee Pang

>  We had a strange situation occur where the status of
>a cisco serial interface showed
> Serial 0 is up, Line Protocol is UP (disabled)
>The T1 line (IDNX - mux) showed all the right lights
>(transmit and receive) and data seemed to be going through
>intermittently. What does the disabled status mean?
>Thanks,
>Bill Rippon         Phone: 914-784-7479
>IBM Watson Research Center     Email: bjripp@watson.ibm.com
Newsgroups: comp.dcom.sys.cisco
From: jmueller.pad@sni.de (Joerg Mueller)
Subject: IP-Accounting
Organization: Siemens Nixdorf Info.Sys. AG, Paderborn, Germany
Date: Fri, 2 Oct 1992 15:04:50 GMT

Hallo,

does anybody know, if an snmp-object exists to clear the ip-accounting
table?  I've nothing found in the cisco mib but it may be i have overlooked
something.

The version of the router is 8.2.4.

Thanks in advance for any reply,

Joerg Mueller
--
E-Mail: jmueller.pad@sni.de                 Snail-Mail: Joerg Mueller
USA   : jmueller.pad@sni-usa.com            c/o SNI AG, STO SI 325
					    Riemekestr. 160
					    DW-4790 Paderborn
Newsgroups: comp.dcom.sys.cisco
From: William Rippon <bjripp@watson.ibm.com>
Subject: serial interface disabled status
Date: 02 Oct 92 11:51:44 -0500


Hello,
  We had a strange situation occur where the status of
a cisco serial interface showed
 Serial 0 is up, Line Protocol is UP (disabled)
The T1 line (IDNX - mux) showed all the right lights
(transmit and receive) and data seemed to be going through
intermittently. What does the disabled status mean?
Thanks,
Bill Rippon         Phone: 914-784-7479
IBM Watson Research Center     Email: bjripp@watson.ibm.com
Newsgroups: comp.dcom.sys.cisco
From: hens@snipe.cray.com (Tom Stephens)
Subject: Re: What causes "Line up, Line protocol up?"
Organization: Cray Research, Inc.
Distribution: na
Date: 1 Oct 92 13:49:41 CDT


In article <1992Sep30.194733.17064@linus.mitre.org>, gbass@mitre.org (Jerry Bass) writes:
> When  I do a 'show interfaces' command,  what is it that causes the display to
> show 'line up' or 'line protocol up'?  (This is for serial ports)  Is it the
> state of the DTR line or DSR line?
> 
> Thanks,
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Jerry Bass                                                              
> gbass@mitre.org
> The MITRE Corporation                                             Bedford, MA
> 


From the Cisco Gateway Syatem Manual, page 5-55....

If the interface hardware is usable, the interface is marked "up".  If the interface can establish a two way communication, the line protocol is marked "up".  

Tom.
--
---------------------------------
Tom Stephens
Corporate Computing and Networks, Chippewa Falls, WI
Cray Research Inc.  hens@cray.com
Newsgroups: comp.dcom.sys.cisco
From: ikewh@usafa.af.mil (William H. Eichenberger)
Subject: Re: Multicast storms
Organization: United States Air Force Academy
Date: Tue, 6 Oct 1992 18:48:41 GMT

In article <01GPE7PPPRYU8WWOMC@ucsvc.ucs.unimelb.edu.au> C.Chaundy@its.unimelb.edu.au writes:

>>Date: 29 Sep 1992 17:01:28 -0300 (BST)
>>From: Sam Wilson <ercm20@festival.ed.ac.uk>
>>Subject: Multicast storms
>>
>>Three times recently we have experienced a kind of multicast storm,
>>apparently because of a breakdown in the bridge spanning tree.  We have
>>Cisco AGS+/3s running 8.2(7) and routing IP, DECnet, Novell and
>>AppleTalk and bridging other stuff (LAVC, LAT, ISO CONS/UK Pink
>>Book/LLC2).  We have a meshed network of ethernets and FDDI and a leased
>>line (which was installed after the first storm).  During the storms we
>>saw large amounts of multicast traffic (LAVC and LAT mostly) apparently
>>being looped within the network.  Traffic peaked at between 1000 and
>>2000 pps, never falling below 1000pps, presumably the peak rate that the
>>routers could forward the traffic on the the attached ethernets.

We had a very similar problem, and FOUND out the CAUSE.....
Well, We and Cisco Tech Support.

We called it a broadcast storm, because that is what triggers it.
It had to do with broadcasting request for service (Banyan) on our
Tripply redundant backboned network.  As it happened, We had
multiple Ethernet routes between routers, and the routers would
choose what their default routes were, on their own.

A broadcast would go out on one ethernet, get to a router who
then reset the count to 0or1 and sent it out on the other ethernet
which would of course arrive back at the first, with a count that
indicated that it was not the same broadcast it sent out in the first
place, and would thus rebroadcast the packet again on its other 
backbone.........

Fix was to specify a higher metric for one of the two ethernet backbones,
don't let the Cisco's assign their default metric of 2.  Piece of Cake

Ike
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Weird Ethernet Behavior
Date: 1 Oct 1992 08:49:46 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: gandalf.think.com

In article <BvF94p.9CA@usenet.ucs.indiana.edu> ssw@bronze.ucs.indiana.edu (steven wallace) writes:
>A cisco will look at the IP header checksum, not the ethernet checksum,
>when deciding whether to forward the packet or not.

Are you sure about this?  On most systems, the ethernet CRC is checked by
the interface, not the host software.  In particular, if the CRC is
invalid, how can the router trust the ethernet address when determining
whether the packet is for this host, or the ethertype field when deciding
whether it's an IP packet or some other protocol?  Passing a packet up to
the next level without applying all of the lower level's validity checks is
extremely unsafe, and I find it difficult to believe that cisco does this.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.dcom.sys.cisco
From: ssw@bronze.ucs.indiana.edu (steven wallace)
Subject: Re: Weird Ethernet Behavior
Organization: Indiana University
Date: Sun, 4 Oct 1992 14:48:26 GMT

In <Oct.3.14.28.11.1992.4370@geneva.rutgers.edu> hedrick@geneva.rutgers.edu (Charles Hedrick) writes:

>ssw@bronze.ucs.indiana.edu (steven wallace) writes:

>>Only cisco can ansere this, but we've got over 50 ciscos and all supported
>>media but token ring and I've seen this several times.

>I suggest that you report it to Cisco support as a bug.  Networks are
>complex enough that you may be getting misled, but what you are seeing
>seems worth pursuing.  At any rate, I'm quite sure that accepting
>packets with bad Ethernet CRC's, if it is occurring, is a bug.

Good point.  This wouldn't be the first time things aren't what they
seem.  I've sent cs@cisco a short note asking them to enlighten us.  I
did see some evidence in the show ip/novell/appletalk traffic commands
that does suggest a cisco may ignore the ethernet CRC for IP and not for
Appletalk and IPX.  On all of our busy routers, 0 checksum errors are
recorded for Appletalk and IPX, but IP has some recorded.  We do have
services that actually use the checksum mechanisms for IPX (not sure
about Appletalk).

-- 
====================================================================
Steven Wallace, N9LKJ         |  wallaces@ucs.indiana.edu (internet)
Acting Associate Director     |  wallaces@iubacs          (bitnet)
Network Systems UCS           |  (812) 855 - 0960         (voice)
Newsgroups: comp.dcom.sys.cisco
From: "Bob Jaques - Network Engineering Manager 415-390-3819" <jaques@drbob.corp.sgi.com>
Subject: ip accounting
Date: 30 Sep 92 08:49:55 -0700

 A few questions on ip-accounting:

1. Does enbabling ip accounting have a significant impact on performance
   of the router?

2. Ip accounting does host counts. Is there a way to get it to summarize
   at a network level?

3. ip accounting does 512 hosts.  How much memory would be used say for
   4000 hosts maximum possible?

4. Does anyone have scripts that massage ip accounting data?

thanks

bob




Newsgroups: comp.dcom.sys.cisco
From: Jim Forster <forster@cisco.com>
Subject: Re: ip accounting 
             <9209301549.AA17146@drbob.corp.sgi.com> 
Date: 01 Oct 92 21:13:00 PDT

>> 1. Does enbabling ip accounting have a significant impact on performance
>>    of the router?

We haven't measured in a while, but based on old numbers I expect it would
cause a 20% - 40% drop in fast-switching performance, and much less if
you're process switching.  Accounting automatically disables Autonomous
switching. 

>> 2. Ip accounting does host counts. Is there a way to get it to summarize
>>    at a network level?

Massage the data in a host program.

>> 3. ip accounting does 512 hosts.  How much memory would be used say for
>>    4000 hosts maximum possible?

The space for each entry is about 20 bytes.  An entry is used for each IP
source-dest addresss pair.  In theory, 512 hosts could generate 2**18
entries (256k), but in practice the matrix is sparse.

If you were real intersted in accounting, you could dedicate about 1MB to
this function.  This would hold 50,000 entries total, or 25,000 in each
table (active and inactive buckets).  If you pull the data every 15
minutes, and assume each host talks to only 25 other hosts in that 15
minute period (very rash assumption, so if you don't like it, make up your
own number), then you can support 1000 hosts.

But you really need to do some experiments.  It all depends on the average
number of hosts each host talks to in the sampling period (5-15 minutes).

Now, you may say "Wow, 1MB for accounting!  That's too much!"  But, the
street price is only $25 for this memory, so its not really expensive to
use in this fashion.  (And yes, I know, memory in CSC/3's is starting to
get a bit tight).

>> 4. Does anyone have scripts that massage ip accounting data?

See ftp.cisco.com.

  -- Jim

Newsgroups: comp.dcom.sys.cisco
From: Bill Chen <chen@watsun.cc.columbia.edu>
Subject: accounting 
Date: 2 Oct 92 13:56:24 EDT


Does anyone know if cisco plans to extend IP accounting type info to
IPX? 

- bill
Date: Monday, 28 Sep 1992 12:38:21 +01
Newsgroups: comp.dcom.sys.cisco
Subject: IGRP updates: what in, where to?
From: Andre' Pirard <pirard@vm1.ulg.ac.be>
X-UserAgent: Nuntius v1.1.1d9
X-XXMessage-ID: <A6ECB59E8501180A@ampa.segi.ulg.ac.be>
X-XXDate: Mon, 28 Sep 92 11:14:06 GMT
Distribution: world
Organization: University of Liege (Belgium)

The cisco gateways documentation, chapter 14, "Multiple Interface
Addresses" says:
"Secondary addresses are treated like primary addresses, except that the
system never generates datagrams other than routing updates with
secondary source addresses".

This makes me think that updates are sent once per interface address. But
with 8.3(3):
interface Serial 1
ip address 223.254.253.2 255.255.255.0 secondary
ip address 139.165.112.1 255.255.255.0
router igrp 1
network 139.165.0.0
network 223.254.253.0

All I see is one update:
IGRP: sending update to 255.255.255.255 via Serial1 (139.165.112.1)
        subnet 139.165.48.0, metric=158250
... more subnets
        network 149.133.0.0, metric=160350
... more nets, no sign of network 139.165.0.0

I find the documentation poor in explaining where updates are sent and
what they contain.
Yet, all I am trying to do is connect two networks and arranging so that
each send no subnet (I've had bad experience with update storms and
unnumbered interfaces).

------
Andre' Pirard         SEGI, Universite' de Lie`ge  139.165 IP coordinator
B26 - Sart Tilman     B-4000 Lie`ge 1 (Belgium)           +32 (41) 564932
pirard@vm1.ulg.ac.be  alias PIRARD@BLIULG11.BITNET
From: harper@geocub.greco-prog.fr
Newsgroups: comp.dcom.sys.cisco
Subject: X25 compressedtcp
Date: 3 Oct 92 08:23:21 GMT
Organization: Greco Programmation du CNRS

I have two IGS ethernet-X.25 machines running 9.0(1) and the header
compression over X.25 doesn't seem to work...

Is this a known bug? If so when will it be fixed?
-- 

	Frank Harper :  Bien le bonjour de la France
	anthes@geocub.greco-prog.fr
From: hedrick@geneva.rutgers.edu (Charles Hedrick)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Weird Ethernet Behavior
Date: 3 Oct 92 03:09:45 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

I'm sort of surprised that no one from Cisco has stepped in to
authoritatively stop this rumor.  I guess a bug is possible, but as
far as I can tell, Cisco Ethernet support checks the Ethernet CRC for
all protocol types.  It also checks the HDLC CRC for serial lines that
use HDLC.  There was a bug in one version of MCI microcode that caused
it not to check the HDLC CRC.  We did in fact see errors due to this
(in Novell, I believe), and they stopped when the microcode was fixed.
I do not believe we've seen undetected errors otherwise, and our
network is complex enough (and uses NFS enough) that I think we would
have.  One reasonable indication is that we do see CRC errors counted
on Ethernet interfaces that are handling only IP traffic.

The original evidence was that someone had a repeater that was
destroying the end of packets, including the CRC, and IP still worked.
I suspect IP worked because the TCP or NFS was retransmitting the
packets after they were discarded because of CRC failure.  I assume
some packets were OK.  If not, then you'd expect that at least TCP
would fail, since the TCP checksum would cause the packet to be
discarded even if the Ethernet checksum would not.  If all packets are
discarded, the user is going to complain that he can't connect.

I can believe that some microcode rev of some Ethernet interface might
have had a problem of not reporting CRC failures.  But not that there
is a general problem with all Cisco equipment, nor an intentional
design choice to ignore CRC (as one posting implied).
From: tazumar@bcsaic.boeing.com (Ronald Tazuma)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Weird Ethernet Behavior
Date: 6 Oct 92 01:03:17 GMT
Organization: Boeing Computer Services AI Center, Seattle

Beware of some cisco routers that actually mangle data within the
Ethernet packet.  We have seen this with occur on 2 different cisco
routers, one altering DEC MOP packets and the other altering Novell
IPX packets.  The problem was isolated using a two sniffer analyzers
that could capture the packets as they traversed the WAN.   

I believe the problem ciscos were changing a single byte and
releasing the packet with a new CRC. The change of the byte was
demonstrated but the thought about the new CRC is just speculation
, since the analyzer used could not tell us what the Ethernet CRC 
values were, it can only report an Ethernet CRC error for the packet
if it was present but didn't.

-ron
Newsgroups: comp.dcom.sys.cisco
From: tli@skat.usc.edu (Tony Li)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Priorities and Frame Relay
Date: 3 Oct 1992 00:33:56 -0700
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: skat.usc.edu

In article <1992Oct2.173601.10814@cbnewsk.cb.att.com> appa@cbnewsk.cb.att.com (ravi.ramaswamy) writes:
    Folks,
    
    	This is regarding the Priority Output Queueing feature in 
    	Cisco routers. My understanding is that one can prioritize
    	by protocol and by interface type. One can also assign
    	priorities by TCP socket numbers. Thus, for instance, in an
    	SNA environment one can give STUN traffic higher priority than
    	telnet and ftp.
    
	[...]

    	As far as I know there is no way to map TCP socket numbers to
    	distinct DLCIs (nor is there a way to assign priorities by
    	DLCIs directly). 

True.

	The conclusion is that, if one had a mixture
    	of STUN traffic and TCP/IP (telnet,ftp) at a location, you 
    	cannot prioritize STUN over TCP/IP going over frame relay.
    
    	Is this correct or am I missing something here?

You can prioritize STUN using the TCP transport over telnet and ftp.
You cannot place it over a different DLCI as at that point it's just
IP traffic, and it will follow the best route to get to the other end
of the TCP connection.  You should still be able to see significant
prioritization of the STUN session while doing this.

-- 
Tony Li - Escapee from the USC Computer Science Department          tli@usc.edu
		       The net is not what it seems.
Newsgroups: comp.dcom.sys.cisco
From: Lee Pang <pang@cisco.com>
Subject: Re:  serial interface disabled status
Date: 6 Oct 92 11:44:37 -0700


Newsgroups: comp.dcom.sys.cisco