HDTenEightyP/NetNews huggingface dataset:
From: ssw@bronze.ucs.indiana.edu (steven wallace)
Subject: Re: Weird Ethernet Behavior
Organization: Indiana University
Date: Thu, 1 Oct 1992 02:48:25 GMT

A cisco will look at the IP header checksum, not the ethernet checksum,
when deciding whether to forward the packet or not.  For IPX, Appletalk,
and possibly others, the ethernet checksum is checked and only intact
packets are forwarded.  This can present other problems.  We recently
had a cbus card fail in such a way as to corrupt data in the packet
while it was being forwarded.  The packet came in to, and out of, the
router with a correct ethernet checksum but a corrupted payload.

LAN protocols, including UDP when checksuming is disabled, can be
dangerous in a routed or bridged environment.  These protocols don't do
end-to-end checksuming and must trust the network.  This has stung us
three times in the last two years.

It amazes me, considering the amount of mission critical data flying
around, that vendors don't offer good solutions to this.  Novell and
Apple should offer an end-to-end checksum version of their file serving
options.  Thank goodness that military command and control stuff isn't
using these protocols....



-- 
====================================================================
Steven Wallace, N9LKJ         |  wallaces@ucs.indiana.edu (internet)
Acting Associate Director     |  wallaces@iubacs          (bitnet)
Network Systems UCS           |  (812) 855 - 0960         (voice)
From: gbass@mitre.org (Jerry Bass)
Subject: What causes "Line up, Line protocol up?"
Organization: The MITRE Corporation
Distribution: na
Date: Wed, 30 Sep 1992 19:47:33 GMT

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: ercm20@festival.ed.ac.uk (Sam Wilson)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Multicast storms
Date: 5 Oct 92 13:18:49 GMT

bwolfe@rad.rpslmc.edu (Brian A. Wolfe) writes:
+ 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.  ...
+ |> 
+ |> Strange coincidence!  Just last weekend, we had *exactly* the same
+ |> problem and fixed it temporarily by turning off bridging on the backup
+ |> cisco ethernet interfaces and later, by rebooting the cisco's concerned.
+ |> 
+ 
+ Is it possible that 2 of the subnets that are connected through the router
+ may have been bridged together somewhere else?

In our case we believe not.  In most cases the spanning tree ought to have
been able to handle that anyway.

+ We've had datacomm people connect the same ethernet segment to 2 different 
+ router ports, its not all that hard to do when you are using 10BASET or 
+ 10BASEF and you have a lot of separate networks.
+ 
+ The thing that tipped us off was that Sparcstations running routed 
+ saw RIP packets from both Cisco ports and they logged something like 
+ "Unknown router packet received from ip adress xx.xx.xx.xx" to the console.

We've done that in the past too, with the only observable side effect
being pauses while routing tables got themselves into loops.  That was
most of two years ago and I've forgotten the exact details, but I
believe we had bridging on both affected nets and did not experience a
storm.  The nets were connected into different routers. 

+ We never experienced any bad side effects from the ethernet cycle that
+ I'm aware of, but then we aren't using nasty things like  LAVC or 
+ routing Appletalk.

Nothing we're running ought to be affected - LAVC ought to be handled by
the spanning tree; AppleTalk and other routable protocols should be
handled by their routing protocols. 


Sam Wilson
Network Services Division
Computing Services, The University of Edinburgh
Edinburgh, Scotland, UK
Newsgroups: comp.dcom.sys.cisco
From: Jesse Sales <jsales@last-call.cisco.com>
Subject: Re: serial interface disabled status
Date: 2 Oct 92 9:17:49 PDT

Your Case Number is:

	35472

We will begin working your problem shortly. Please reference this case
number in  all correspondence on  this subject. For  email, begin your
subject line with  "Case" followed by the  number above.  For example,
"Case ##### additional info".
	
You may  also contact  the   TAC   (Technical Assistance  Center)  via
telephone  at (800) 553-2447  or (415) 903-7209,   or by FAX  at (415)
903-8787. Our operating hours are 0500  to 1800 Pacific Standard Time,
USA. In all   cases,  providing your  service  contract    number will
accelerate our assistance.
	-------------------------------------------------------

> 
> 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: Ratilal.R.Haria@nrc.ca
Subject: Help with Collision Problem
Organization: NATIONAL RESEARCH COUNCIL OF CANADA
Date: 06 Oct 92 10:18:37 EDT

Hi,

  Since about a week, we have been getting lots of collisions.
  Seems to be about 2-5 collisions every 5 secs. To isolate the
  source of these collisions, we have disconnected segements of
  the backbone. But we have been unsuccesful in finding the
  source of collisions.

  Any help/cluses/pointer?

Thanks ... Ratilal
From: smee@bristol.ac.uk (Paul Smee)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Any clues on AGS+ 'clear'?
Date: 29 Sep 92 09:22:11 GMT
Reply-To: P.Smee@bristol.ac.uk (Paul Smee)
Organization: University of Bristol

In article <1992Sep28.163248.15677@den.mmc.com> jzwiebel@pgl-devsvr.den.mmc.com (John Zwiebel (303)977-1480) writes:
>In article <1992Sep24.155113.6767@bristol.ac.uk>, smee@bristol.ac.uk (Paul Smee) writes:
||> First, 'clear bridge 1' doesn't seem to do anything at all, neither
||> forgetting learned MACs in that bridge group, nor clearing XMIT and
||> RECV counts for permanent entries.  Is there some magic I'm missing, or
||> is this a bug.  
|
|	I'm running 9.1(0.22) (csc3) but "clear bridge 1" seems to work
|	just fine for me.  It also works on 8.2(8) (with a csc2 cpu)

Thanks for that info, you're about the only person to address that side
of the question.  (Thanks also to everyone who passed on info about my
other question.)

Anyone have any further info on this 'clear bridge 1' problem, then, as
it (honest guv) doesn't work here.  We're running 8.2(7) on a CSC3.
Fact that it works for you and not for us might reflect the different
version level.  Also occurs to me it might be a table-size problem
(we've got about 750 permanent entries in bridge group 1).  Is there
anyone else out there that 'clear bridge' DOESN'T work for, or anyone
from Cisco who recognizes this as a bug which has been fixed in later
versions than ours?

-- 
Paul Smee, Computing Service, University of Bristol, Bristol BS8 1UD, UK
 P.Smee@bristol.ac.uk - ..!uunet!uknet!bsmail!p.smee - Tel +44 272 303132
Newsgroups: comp.dcom.sys.cisco
From: buennema@fbihh.informatik.uni-hamburg.de (Thomas Buennemann)
Subject: ospf and NBMA configuration ?
Summary: Possible to configure OSPF NBMA stations ?
Keywords: ospf
Organization: University of Hamburg, FRG
Date: 30 Sep 92 13:15:19 GMT

Hi CISCO-wizards,
I'am just now doing some tests with downloaded CISCO-V9.0(1) software and
on an AGS+ and gated-alpha on a SUN-IPX with BGP 3 and OSPF 2, trying to
figure out, which of them would be the best choice for our Metropolitan
area network.
Because only Cisco-documentation V8.3 is available at the moment (the MAN-
routers will be new ones with V9.0), I've got some troubles with configuration
of OSPF (BGP was simple to configure) - our SUN's, DEC's and IBM's don't 
support multicast, so I've to set up a NBMA-connection (NonBroadcastMultiAccess)
but how to do this at the CISCO ??

Any hints (Cisco-OSPF-configurations) wellcome...

Regards,
Thomas Buennemann
University of Hamburg
Department of Computer Science
buennema@informatik.uni-hamburg.de

Newsgroups: comp.dcom.sys.cisco
From: morgan@leland.Stanford.EDU (RL "Bob" Morgan)
Subject: Secondary IPs not in ipAddrTable?
Organization: DSG, Stanford University, CA 94305, USA
Date: Tue, 29 Sep 92 00:59:32 GMT


Surely it is Substantially Bogus Behavior of the cisco GS software
that information about secondary IP addresses is not available in the
ipAddrTable section of its MIB?  Only primary addresses are listed.

Surely there are plans to fix this?

 - RL "Bob" Morgan
   Networking Systems
   Stanford University

Newsgroups: comp.dcom.sys.cisco
From: watt-alan@net.yale.edu (Alan Watt)
Subject: Re: ip accounting
Originator: swatt@mickey.CS.Yale.Edu
Organization: Yale University, Computing & Information Systems
Date: Wed, 30 Sep 1992 18:35:01 GMT


In article <9209301549.AA17146@drbob.corp.sgi.com>, "Bob Jaques - Network Engineering Manager 415-390-3819" <jaques@drbob.corp.sgi.com> writes:
|>  A few questions on ip-accounting:
|> 
|> 1. Does enbabling ip accounting have a significant impact on performance
|>    of the router?

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

Yes; see below.

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

We run with 4096 here and have plenty of memory available (and this on
a CSC/2).  I think processor time is more of a concern here than space.

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

Yes, I have several perl scripts which produce reports from the output
of "show accounting", including the ability to summarize by network/subnet.
Send me mail if you want them (watt-alan@net.yale.edu)

BTW: anyone want to sign an electronic petition to Cisco to get them to
	include DECNET and Appletalk accounting also?

Note to Cisco Tech folks:  convince your marketeers than adding DECNET,
	Appletalk, and whatever accounting will result in more sales
	of CSC/3 and CSC/4 processors.  Maybe even justify developing
	an Alpha-based CSC/5 :-) .
-- 
  Alan S. Watt
  Yale University			Computing and Information Systems
  Box 2112 Yale Station			(203) 432-6602
  New Haven, CT  06520-2112		Watt-Alan@Yale.Edu
From: tli@skat.usc.edu (Tony Li)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: IGRP updates: what in, where to?
Date: 28 Sep 1992 23:26:00 -0700
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: skat.usc.edu

In article <19920928.123821820180.NETNEWS2@BLEKUL11> pirard@vm1.ulg.ac.be (Andre' Pirard) writes:

    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
    
Andre,

We perform split horizon on a per interface basis.  If you would like
to disable this, use "no ip split-horizon"

Tony
-- 
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: bwolfe@rad.rpslmc.edu (Brian A. Wolfe)
Subject: Re: Multicast storms
Reply-To: user@machine.domain
Organization: Rush Presbyterian-St. Lukes Medical Center
Date: Fri, 2 Oct 1992 19:51:20 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.
|> 
|> Strange coincidence!  Just last weekend, we had *exactly* the same
|> problem and fixed it temporarily by turning off bridging on the backup
|> cisco ethernet interfaces and later, by rebooting the cisco's concerned.
|> 

Is it possible that 2 of the subnets that are connected through the router
may have been bridged together somewhere else?

We've had datacomm people connect the same ethernet segment to 2 different 
router ports, its not all that hard to do when you are using 10BASET or 
10BASEF and you have a lot of separate networks.

The thing that tipped us off was that Sparcstations running routed 
saw RIP packets from both Cisco ports and they logged something like 
"Unknown router packet received from ip adress xx.xx.xx.xx" to the console.

We never experienced any bad side effects from the ethernet cycle that
I'm aware of, but then we aren't using nasty things like  LAVC or 
routing Appletalk.

regards,

Brian

-------------------------------------------------------------------------
Brian Wolfe						
Associate Director
Depts of Diagnostic and Therapeutic Radiology
Rush Presbyterian-St. Lukes Medical Center 
Chicago,  IL   USA 
Internet: bwolfe@rad.rpslmc.edu    
Voice:    (312)-942-2141          FAX:  (312)-942-2114
Newsgroups: comp.dcom.sys.cisco
From: subbarao@nmsu.edu (Ravi Subbarao)
Subject: cisco snmp mib compatibilty with SunNet Manager
Keywords: cisco snmp SNM
Organization: New Mexico State University
Date: Fri, 2 Oct 1992 23:12:47 GMT

I have down loaded the cisco mib (one for 8.3 ver) from ftp.cisco.com

I have tried to get this mib to work on the SunNet Manager platform.
Usually I have to convert the mib to a schema file. When I get this done
and try to use this schema file to retrieve information from the 
remote server, only a few "groups" work. The groups like

		lifTable
		lipAddrTable
		decnet
		

never work. When queried for data, the snmp.get-request call returns
with a "No Data" response. Some other groups return "errors" of
various types...

There is something wrong in the mibs? If yes, is there is patched
version of it somewhere?  

Please reply back as soon as possible. I cannot get any of the mibs
of cisco to work properly.  It is really frustrating.

Any SNMP guru, who knows this?

Thanks in advance....

-Ravi

-------------------------------------------------------------------------------
Ravi Subbarao	  | New Mexico State University	| Internet: subbarao@nmsu.edu
Network Engineer  | Dept 3AT, Box 30001		| Bitnet:   rsubbara@nmsuvm1
		  | Las Cruces NM 88003		| UUCP:     nmsu.edu!subbarao
		  | Phone: (505) 646-5779	| My Host:  flintstone.nmsu.edu
		  | FAX:   (505) 646-5278	|
-------------------------------------------------------------------------------
Newsgroups: comp.dcom.sys.cisco
From: Victor Reijs <Victor.Reijs@surfnet.nl>
Subject: Re: please give your remarks
Phone: +31 30 310290
Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL
Organisation: SURFnet bv
Telefax: +31 30 340903
Date: 30 Sep 92 16:44:15 +0100


==> From: Jimo

> 
> 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.
> 
>
Hello Jimo,

As the NT network is a DTE (and the cisco is a DCE), I do not expect that a DTE
network will listen to a V.25bis signaling. That is more the work for a DCE!

My mean question is, will it be possible to implement in the cisco hardware some
jumper so that it will conform to the CCITT when needed???

All the best,


Victor

P.S. it seems that modem eliminators (RAD) and some V.35 modems (Telindus) do not
need the DTR signal (and is also not implemented).
From: ssw@bronze.ucs.indiana.edu (steven wallace)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Weird Ethernet Behavior
Date: 1 Oct 92 13:55:17 GMT
Article-I.D.: usenet.BvG405.Jp0
Organization: Indiana University

In <1aee3aINNfgk@early-bird.think.com> barmar@think.com (Barry Margolin) writes:

>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

Yep, I pretty sure.  I've seen very direct evidence of this.  Maybe
cisco will chime in here and explain.  Of course the router doesn't
need to validate the ethernet address to correctly route an IP
packet.  It does need to validate the IP header checksum, but the
upper layer (the non-broken ones) do end-to-end checksuming.  IP
was designed to work well over media that doesn't do any MAC layer
checksums (example SLIP).


We've had broken repeaters that destroyed the tail of ethernet
frames (thus the checksum), but not the headers.  The symptoms are
IP will works just fine, but Novell or Appletalk packets don't pass
through the router and are counted as input error on the interface
stats.



-- 
====================================================================
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: Gerry Gysbers <gysbers@mcmail.cis.mcmaster.ca>
Subject: macts2 (fwd)
Date: 25 Sep 1992 16:01:52 -0400 (EDT)


Can anyone offer some input on this?

Our ASM/3 terminal server is experiencing a few problems:

    (1) the clear line command does not work properly: either it does not 
    clear the line at all or the terminal server will reboot (with error
    message - see "sh ver" mssg below). 
    
    (2) the terminal server does not appear to terminate sessions
    properly - as a consequence, users can "continue on" using  
    other users' improperly dropped sessions. This is a rather 
    serious problem as it seriously undermines security.
                                  
Product info: 
             Model: ASM0991  
             S/N# : 100002X
             
Connected to: (a) IBM 7171 Protocol Converter ports
              (b) ROLM DataCom Modules 

Version and Configuration listing:     
(Password, IP#, host-name info has been edited out for security reasons)

sh ver
TS Software (TS3-S), Version 8.3(3)
Copyright (c) 1986-1992 by cisco Systems, Inc.
Compiled Mon 30-Mar-92 15:35 by mlw

System Bootstrap, Version 4.4(2) 

macts2 uptime is 15 hours, 54 minutes
System restarted by error condition - Software forced crash, PC 0x2DACA
Running default software

CSC3 (68020) processor with 4096K bytes of memory.
1 MCI controller.
1 Ethernet/IEEE 802.3 interface.
80 terminal lines.
32K bytes of non-volatile configuration memory.
Configuration register is 0x101

macts2#sh config

Using 19990 out of 32768 bytes
!
!
interface Ethernet 0
snmp-server community
ip alias 130.xxx.xxx.xxx 3001
ip alias 130.xxx.xxx.xxx 2032
!
!
line vty 0 4
login
line con 0
padding 13 3
!
! ---- lines setup for ethernet to 7171 access ---- (only 1 out of 64 shown)
!
line 1
location Communications Room
no exec
exec-timeout 0 0
flowcontrol software in
flowcontrol software out
modem DTR-Active
modem answer-timeout 0
rotary 1
session-timeout 60 
stopbits 1
no vacant-message
dispatch-timeout 70
!
!           -----sample ROLM>>7171 port (1 of 16 shown)---------
!
ine 61
location CNH 109 Rolm-to-Mail1
autobaud
exec-timeout 5 0
flowcontrol hardware in
flowcontrol hardware out
modem RI-is-CD
modem answer-timeout 30
session-timeout 60 
stopbits 1
no vacant-message
autohost Mail1
!
!
line vty 0
no exec
exec-timeout 0 0
flowcontrol software in
flowcontrol software out
password xxxxxxxxxxxxx
session-timeout 15 
no vacant-message
!
end


Any help would be appreciated.
Thanks,

Gerry Gysbers
gysbers@mcmail.cis.mcmaster.ca
McMaster University
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Weird Ethernet Behavior
Date: 1 Oct 1992 20:00:26 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <BvG405.Jp0@usenet.ucs.indiana.edu> ssw@bronze.ucs.indiana.edu (steven wallace) writes:
>  Of course the router doesn't
>need to validate the ethernet address to correctly route an IP
>packet.

Sure it does, because ethernet is a broadcast medium.  An ethernet node
should ignore any packets that weren't addressed to its ethernet address
(or the broadcast address or the address of a multicast group it's a member
of), unless it's in promiscuous mode.  If the CRC doesn't check, the node
shouldn't believe that the destination ethernet address is correct, so
shouldn't accept it even if it appears to have its address.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar