HDTenEightyP/NetNews huggingface dataset:
From: sater@cs.vu.nl (Hans van Staveren)
Subject: Re: FDDI board refuses to work, 100% cpu load to boot
Organization: Fac. Wiskunde & Informatica, VU, Amsterdam
Date: Mon, 11 Jan 1993 16:25:50 GMT

I wrote:

>I just installed our first FDDI board in our Cisco, and surprise..
>it doesn't work. It looks like it cannot enter into the ring. I had it
>installed at first in our ring with 3 Interphase FDDI boards, but when that
>didn't work I tried looping back the Cisco to itself. Even that did not
>work. I configured it:
>	interface fddi0
>	ip address 130.37.16.1 255.255.255.0
>	no shutdown

>The router is now very slow, the 'show proc' output shows that the PHY-A
>and PHY-B processes take all the time. I did a shutdown on the interface
>and the router is back to normal.

I received a number of replies from people within Cisco. Most of them pointed
to an internal cable problem and after confirming it with our vendor this
turned out to be the case. The problem was that our hardware manuals said
the cables from applique to interface board would be labelled 1,2,3 and 4,
and then gave a picture how these should be installed to connectors P1,P2,P3
and P4.

It turned out that the cables were labelled A,B,C and D, and the obvious
transformation I made was wrong. The A,B,C and D cables should be attached
to the connectors from left to right, in that order.

Everything works now. I am left with the impression however that installation
instructions for interface boards should be distributed with the interface
boards and not with the router itself. That makes it possible to change
the cabling after selling the router without inconveniencing customers.

	Hans van Staveren
	Vrije Universiteit
	Amsterdam, Holland
Newsgroups: comp.dcom.sys.cisco
From: Gary Kunis <gkunis@cisco.com>
Subject: RFC 951 and BOOTP (fwd)
Date: 5 Jan 93 18:26:16 PST
X-Mailer: ELM [version 2.3 PL11]
X-Note1: message-id generated by recnews
X-Note2: mail msgid was   <199301060229.AA16874@spot.Colorado.EDU>

William,

By default, the Cisco router will not forward BOOTP requests
(UDP broadcats).  You must configure the Cisco router to forward
these UDP broadcasts.

This can be done by using the ip forward-protocol global con-
figuration command and an ip helper-address.  The ip forward-
protocol command allows you to specify protocols and ports to
be forwarded by the router.  The ip helper-address defines the
destination host to receive the UDP broadcasts.

An example:

ip forward-protocol udp
!
interface ethernet 0
ip address 131.12.1.1 255.255.255.0
ip helper-address 131.12.4.12
> 
> FC 951 states that routers can be configured to forward BOOTP
> requests. How does cisco handle such requests? Are the packets
> forwarded as-is or are they altered in some way? Does the 
> router need any specific parameters set or is it a default
> process in the router software itself? I'm trying to determine
> how interoperable cisco is with other router vendors.
> 
> W. Smith	 575-2363	wildbill@lobby.ti.com
> 

  -- Gary Kunis --
PS - this is found on pages 13-13 and 13-14 in volume II of the
Configuration Reference Manuals


Newsgroups: comp.dcom.sys.cisco
From: Bill Chen <chen@watsun.cc.columbia.edu>
Subject: Routing Bug - cisco or Novell or 3com ?
Date: 6 Jan 93 11:11:51 EST
X-Note1: message-id generated by recnews
X-Note2: mail msgid was   <9301061611.AA04298@watsun.cc.columbia.edu>


Here at Columbia, we noticed the same thing happen when we went from
8.2.7 to 9.0(1-12). Cisco suggested that we upgrade to 9.0(3-3). We
had tried 9.0(3-0) before we noticed the Novell problem, but we had a
multibus timing problem with CSC-R token ring boards in the router, so
we dropped back to 9.0(1-12).  We're in the process of setting up
downtime to try out 9.0(3-3).

Bill Chen
Columbia University
From: syj@ecmwf.co.uk (Jean-Philippe Martin-Flatin)
Newsgroups: comp.dcom.sys.cisco
Subject: How reliable are 9.1 sub-releases ?
Date: 6 Jan 93 18:33:00 GMT
Organization: ECMWF

How reliable are 9.1 sub-releases ? We are currently hesitating between
the following to upgrade all our CISCOs:

	9.0(3.x)
	9.1(1.x)
	9.1(2.1)

Each of them fixes some bugs we suffer from. But the whole 9.1 release
has had a bad reputation so far, and our distributor seems quite afraid
to let us go beyond 9.0(3) ! Does anybody have some experience with these
sub-releases ? Positive or negative ?

The protocols we are interested in are IP, ARP, RARP, Decnet and Novell.

Thanks

/----------------------------------------------------\
| Jean-Philippe Martin-Flatin                        |
| European Centre for Medium-Range Weather Forecasts |
| Shinfield Park                                     |
| Reading RG2 9AX                                    |
| Great-Britain                                      |
\----------------------------------------------------/
Newsgroups: comp.dcom.sys.cisco
From: William "Chops" Westfield <billw@glare.cisco.com>
Subject: Re: Kermit file transfer thru cs-516
Date: 12 Jan 93 18:45:34 PST
X-Note1: message-id generated by recnews
X-Note2: mail msgid was   <CMM.0.90.2.726893134.billw@glare.cisco.com>

    We are using a cs-516 as a terminal server.  However there seems
    to be a file transfer buffer size limit imposed by the Cisco.
    The maximum packet size for downloads is about 530 (bytes) and
    for upload about 120.

I'm not sure what you mean.  The size of buffers used by the cisco should
not impose any limit on the size of buffers used by Kermit.  530 and 120
compare quite closely with the default TCP max segment size (536 bytes)
and the size of a cisco "small" packet buffer, but those are just tcp
packet sizes, and shouldn't have anything to do with the packet sizes
that kermit can use.

Can you tell me what software you are using?  The last version of
kermit software I used had "big" and "small" packet sizes, and I
didn't think you could vary them to anything else...

Bill Westfield
cisco Systems.

Newsgroups: comp.dcom.sys.cisco
From: martineau@MacMartineau.ccr.hydro.qc.ca (Alain Martineau)
Subject: Re: DECnet areas
Followup-To: comp.dcom.sys.cisco
Organization: Hydro Quebec
Distribution: world,local
Date: Tue, 12 Jan 1993 12:53:15 GMT

In article <93012.103138RHUNTER@ESOC.BITNET>, <RHUNTER@ESOC.BITNET> wrote:
> 
> I have done some more digging into the validity of 2 areas on 1 Ethernet.
> 
> Page 2-27 of VMS Networking Manual april 88 for VMS v5.0
> 
> "2.4.4.3 Area Routing on Ethernet
> All nodes on an Ethernet need not be in the same area; you can configure
> more than one area on a single ethernet. The areas on the same Ethernet are
> logically seperate from each other.....
> Section A.6 illustrates area routing on an Ethernet"
> 
> looks like everything will be OK.
> 
> Just a reminder of the problem:
> Is it possible to run more than 1 DECnet area in a Cisco?
> 
> I think you use the Address Translation Gateway to start two processes
> > decnet 0 routing
> > decnet 0 node-type area
> ...
> but you do NOT configure any translations....
> the 2 routing processes should then run seperately, and only communicate
> via the common Ethernet interfaces.
> 
> It then becomes a question of how many Ethernets you need to share areas
> on, as you need to use 2 interfaces per Ethernet.
> 
> Once again, a reminder that this comes untested!
> 
> Ray Hunter
> RHUNTER@ESOC.BITNET
> Cray Systems on Contract to the European Space Agency
> #include <std.disclaimer>

You may have many DECnet areas on the same segment, but each area
should have its own router. The cisco interface can only have one
DECnet address, thus can be the router for only one DECnet area, as
an area router must be in the same area that it is going to route
for. You could designate one of your VAXen an area router for the
other area though.

Alain Martineau
Hydro Quebec
amartineau@nccr.felix.hydro.qc.ca
Newsgroups: comp.dcom.sys.cisco
From: johnson@tigger.jvnc.net (Steven L. Johnson)
Subject: Re: IPX and NetBios routing/bridging?
Originator: johnson@tigger.jvnc.net
Organization: JvNCnet
Date: Sat, 9 Jan 1993 19:53:21 GMT

rfranken@cs.umr.edu (Richard Brett Frankenberger) writes:

>Novell also makes an implementation of NetBIOS.  It uses IPX as the protocol
>for communication across the LAN between workstations.  Since IPX is routable
>(and you are already routing IPX), if you used Novell's NetBIOS, you would not
>have to change anything on the routers.

My understanding is that novell helper-address's must be configured to
properly route or flood NetBios broadcasts.  At least that is what
I had to do when users started running NetBios applications across a
Cisco WAN.  A minor but necessary change.

-Steve
Newsgroups: comp.dcom.sys.cisco
From: bbuess@chx400.switch.ch (Jeroen Houttuin)
Subject: work group services question
Organization: Swiss Academic and Research Network SWITCH
Date: Sat, 9 Jan 1993 16:17:20 GMT


Hi,

Could anybody explain me the following work group services?

- multiple helper addresses for Novell IPX
- NetBIOS Name Caching

Thank you for your help.

Juerg




-----------------------------------------------------------
bbuess@cosine-mhs.switch.ch

NetConsult AG, Mettlenwaldweg 20a, 
3037 Herrenschwanden, Switzerland.
Tel: +41 31 235 750, Fax: +41 31 235 792
Newsgroups: comp.dcom.sys.cisco
From: Peter Radig <peter@orfeo.rhein-main.de>
Subject: IGRP information on interfaces with secondary address
Phone: +49 69 746972
Keywords: igrp, x25, secondary address, 9.0, 9.1
Address: Palmengartenstr. 1, D-W6000 Frankfurt am Main 1, Germany
Organization: Peter Radig EDV-Beratung, Frankfurt am Main, Germany
Date: Fri, 8 Jan 1993 04:17:28 GMT
Fax: +49 69 7411443

Yesterday I searched for the reason our WAN connections didn't come
up for over three hours for the following reasons.

The configuration is a AGS running 9.0(1) / 9.0(2.6) / 9.1(1.3) 
(happens in either cases). The WAN connections run over a X.25
interface with multiple SVCs. We use IGRP between the ciscos.

The router was reloaded about six weeks ago.

After that reload I added dynamically a SVC to this interface pointing
to a site outside our company. For some reason the other site's
administrator requested I had give our X.25 interface a secondary
address with an IP number the others could deal with. So the
config looked like

	interface serial 3
	encapsulation x25
	ip address 192.125.1.9 255.255.255.252 secondary
	ip address 192.125.253.2 255.255.255.0

Yesterday I had to power-on-reset the router after a hardware upgrade.
After that reload all WAN connections via X.25 didn't work. The
reason I found was that all IGRP pakets send via broadcast on
this interface had the secondary address as sender. (Before the
reload but with the same configuration the primary address was
was used to send the updates). But the remote routers were not prepared
to accept these IGRP updates because they are on net 192.125.253.0
only (they don't react on broadcasts with an other network address),
so our dynamic routing on this interface failed completely.

My question: Bug or feature? Or, more generally: If an interface
has one primary and more than one secondary address is it predictable
which address is used in the IGRP updates as sender?

Thanks in advance.

cu,
Peter
Newsgroups: comp.dcom.sys.cisco
From: C.Chaundy@its.unimelb.edu.au
Subject: Finding ROM version
Content-Transfer-Encoding: 7BIT
Mime-Version: 1.0
Date: 12 Jan 1993 16:59:10 +1100
X-Vms-To: IN%"cisco@spot.Colorado.EDU"
X-Note1: message-id generated by recnews
X-Note2: mail msgid was   <01GTFSQBHDGY8WXEBB@ucsvc.ucs.unimelb.edu.au>

If your system has been booted from Flash EEPROM, is there a way to
find out what version system is resident in the ROMs in the system
(without reloading the system of course :-)?

Regards, Chris Chaundy (Technical Manager, Networks)

Information Technology Services, Thomas Cherry Building,
The University of Melbourne, Parkville, Victoria 3052 Australia
Phone:    +61 3 344 7045                Fax:   +61 3 347 4803
Internet: C.Chaundy@its.unimelb.EDU.AU 	(X.121 505233430003)
From: warlock@ecst.csuchico.edu (John Kennedy)
Newsgroups: comp.dcom.sys.cisco
Subject: AppleTalk routing
Date: 6 Jan 93 07:17:07 GMT
Organization: California State University, Chico
NNTP-Posting-Host: amber.ecst.csuchico.edu


  Does anyone know of a way to get a AGS+ [running 9.1(1.5) ROMs, 9.1(2.1)
soon] to be more assertive with AppleTalk routing?

  A general setup for one of our interfaces is:

	appletalk routing
	appletalk lookup-type FastPath
	appletalk name-lookup-interval 30
	no appletalk permit-partial-zones

	interface Ethernet 1
	ip address 132.241.200.1 255.255.255.0
	ip helper-address 132.241.200.10
	appletalk cable-range 12080-12080 12080.1
	appletalk zone CHI_Campus subnet TEST
	appletalk send-rtmp
	novell network 2
	no novell route-cache
	no shutdown

  Now, by "assertive" I mean that it's willfully intolerant about the way
other AppleTalk devices are configured.  When it boots up, it doesn't care
about other AppleTalk devices, it doesn't verify it's configuration with
them, it doesn't cut itself off if someone disagrees, etc etc.  Suggestions?

-- 
p'ch'zarni'chiwkov:  the nasty little sound of a sword being unsheathed right
behind one at just the point when one thought one had disposed of one's enemies.
Newsgroups: comp.dcom.sys.cisco
From: Roland Acra <acra@cisco.com>
Subject: Re: Mixed traffic - x25 and Ethernet
Date: 5 Jan 93 7:12:10 PST
X-Mailer: ELM [version 2.3 PL11]
X-Note1: message-id generated by recnews
X-Note2: mail msgid was   <9301051512.AA24265@ash.cisco.com>

> We are considering a new network which connect all of our different
> sites through a WAN. We will probably buy some CISCO routers. 
> 
> The trafic which is routed through the CISCO equipment is split
> in two
> 
>        - FTAM trafic based on x25 connections             
>     
>        - Interactive terminal sessions based on TCP/IP on an Ethernet.
> 
> Like this:
> 
>                            IIIIIIIIIIIIIIII
>        FTAM/X25----------> I              I 
>                            I CISCO ROUTER I------- 2 MBit --->
>        TCP/IP/ETHERNET---> I              I
>                            IIIIIIIIIIIIIIII      
> 
>  
> The CISCO routers can mix these two kinds of input intp one 2Mbit channel
> which connects the different sites.
> 
> My concern is now : Will the interactive traffic suffer when a heavy
> FTAM transport is taking place ?. Will the file transfers affect the
> responsetimes for the interactive traffic to a large extend ?.
> 
> If YOU have any experience with this please E-mail (or fax) me the 
> information. Or if you have a reference to the litterature about this
> kind of setup I will appreciate that too. Or just youre opinion from
> your experience.

Hello Lars,

You can apply the "Priority Queueing" mechanisms on your outbound
interface on the router. With that, you can specify that, in case
of congestion, your IP traffic should take precedence over your OSI
traffic.

Priorities can be set based on protocol (IP, CLNS, DECNET, etc),
or application (specify TCP or UDP port numbers), or the interface
through which the packets entered the router, or the packet sizes.

Look for the keywords "priority-list" and "priority-group" in your
router manual.

Finally, please note that priority queueing is mostly useful on
"low-speed" interfaces (+/- up to 64Kbps), which are likely to
be congested. Be sure the extra overhead introduced by priority
queueing is worth it on a 2Mbps link.

Roland Acra
Cisco Systems, Europe
From: warlock@ecst.csuchico.edu (John Kennedy)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: How reliable are 9.1 sub-releases ?
Date: 8 Jan 93 07:57:45 GMT
Organization: California State University, Chico
NNTP-Posting-Host: amber.ecst.csuchico.edu

In article <C0G3J1.4sv@ecmwf.co.uk> Jean-Philippe Martin-Flatin writes:

-->  How reliable are 9.1 sub-releases ? We are currently hesitating between
-->  the following to upgrade all our CISCOs: ...
-->  The protocols we are interested in are IP, ARP, RARP, Decnet and Novell.

  We started out with an ancient 8.something release, got a maintenance
contract and started replacing things.  (:  We're routing three things... IP,
AppleTalk and Novell IPX.

  IP was semi-exciting, spurred on by network configurations changing under-
neath me.  I was very familiar with it, however, so it went (as far as the
router software was concerned) without a hitch.

  AppleTalk was exciting.  If the idea of a protocol behaving like a rabid,
diseased sex-crased bunny rabbit appeals to you, AppleTalk is for you.

  IPX was the worst so far because Novell was such an unknown.  Cisco provided
more useful information about Novell than all their manuals and engineers
could.  Quite disgusting.  One bug is making us upgrade from 9.1(1.5) to
9.1(2.1), which is the worst I've been dished.


  So far I've been really happy with the 9.1+ ROMs.  Being a University,
we're running everything from the ancient to the start of the art, new and
old, all at the same time.  I've been _very_ pleased with Cisco's tech
support.  Especially:

		Bob "the human protocol analizer" Albrightson
		Phillip Remaker			  John Wright
		Joanne Boyle			  David Stine

  These people have taken a lot of abuse from me and they've paid off.  If
you have a maintenance contract, go for it.  If not, I'd get one set of 9.1+
proms and one of the newer boot proms so you can load 9.1+ images via TFTP.

-- 
p'ch'zarni'chiwkov:  the nasty little sound of a sword being unsheathed right
behind one at just the point when one thought one had disposed of one's enemies.
Newsgroups: comp.dcom.sys.cisco
From: "David S.A. Stine" <dstine@cisco.com>
Subject: Re: Pre-FDDITalk compatibility.... 
             <1993Jan6.135537.3837@doug.cae.wisc.edu> 
Date: 06 Jan 93 14:24:59 PST
X-Note1: message-id generated by recnews
X-Note2: mail msgid was   <9301062223.AA09755@wolf.cisco.com>

On 6 Jan 93 19:55:36 GMT, wittmann@engr.wisc.edu (art wittmann) said:
> Originator: wittmann@muskie.engr.wisc.edu


> We're trying to get some netware servers on an FDDI ring.  Everything
> works except appletalk.  The router's FDDI interface reports that it
> is in pre-FDDITalk compatibility mode.  I suspect that this is the problem.
> The question is; how do I get the router into FDDITalk compatibility mode?

> Thanks,
> Art

Start up all netware AppleTalk FDDI devices before you start the cisco
routers.  Make sure all cisco routers are running 9.0(2) or later. Then
bring up the cisco routers on the FDDI ring. The cisco will go into
'pre-FDDITalk compatibility' if it hears any pre-9.0(2) cisco routers on
the ring. Once in 'pre-FDDItalk' mode, the cisco will not come back out
until the interface is restarted.

Admittedly, this is not a superior solution to this compatibilty
problem. The origin of this situation is that cisco provided AppleTalk
on FDDI before Apple had defined what AppleTalk on FDDI was going to
look like. So we have to be compatible with our installed base of
routers, yet implement the new FDDITalk specification to function with
other vendors (eg, Novell)

In the next major release, we plan to have a router be able to be
compatible with pre-9.0(2) routers and FDDItalk devices on the same
ring at the same time with no configuration flags.

dsa
Newsgroups: comp.dcom.sys.cisco
From: <henryc@oar.net>
Subject: Re:  Finding ROM version
Date: 12 Jan 1993 07:56:42 -0500
X-Note1: message-id generated by recnews
X-Note2: mail msgid was   <199301121256.AA07769@thor.oar.net>

>If your system has been booted from Flash EEPROM, is there a way to
>find out what version system is resident in the ROMs in the system
>(without reloading the system of course :-)?

The best thing I've found to do is to give the load useful names,
so when I do a "show flash" you can readily tell what's there.  For
example,

gwdlp1>show flash
4096K bytes of flash memory on MC+ card (via MCI).
  Contains:
    /cisco/gs3-k.91-2.1 (1348032)
    /cisco/gs3-k.91-1.5 (1341168)
  [1504912/4194304 bytes free]
gwdlp1>

The alternative is give them symbolic names, but remember what they
map to.  For example,

gwdlp1>show flash
4096K bytes of flash memory on MC+ card (via MCI).
  Contains:
    /cisco/test-9.1 (1348032)
    /cisco/production-9.1 (1341168)
  [1504912/4194304 bytes free]
gwdlp1>

This is really what our routers hold, and we remember that the
loads map as shown above.  This has the advantage that we don't have
to change names all the time in assorted config files :-).  It also
has the disadvantage that you can't readily tell what the load is, 
as in the first example, except by mapping the load size on the tftp 
server to the load.

Hope this helps,
Henry
Newsgroups: comp.dcom.sys.cisco
From: William "Chops" Westfield <billw@glare.cisco.com>
Subject: Bug reports, and this mailing list...
Date: 8 Jan 93 15:58:46 PST
X-Note1: message-id generated by recnews
X-Note2: mail msgid was   <CMM.0.90.2.726537526.billw@glare.cisco.com>

Just a reminder that the cisco@spot.colorado.edu mailing list (and the
associated comp.dcom.sys.cisco Newsgroup) are user mailing lists that are
NOT directly associated with cisco.  While the recent "what sort of troubles
have you had with 9.1" dicussions are entirely appropriate, issues like
"my router crashed and gave me this stack trace" would probably elicit
better results if reported directly to cisco customer engineering, either
by email (to customer-service@cisco.com), by phone, or by CIO.

Bill Westfield
cisco Systems.
Newsgroups: comp.dcom.sys.cisco
From: Tom_Karolyshyn@dgc.ceo.dg.com
Subject: MGS Power Supplies
Date: 8 Jan 93 12:22:26 est
X-Note1: message-id generated by recnews
X-Note2: mail msgid was   <9301081722.AE00038@rtp41.rtp.dg.com>

Message:
If the MAS-23 is an auto-ranging power supply from 110 to 240 volts, 
then why is there a separate power supply listed for the UK (MAS-26)?
 
Also, is there a place or a way to identify each of the many MGS 
power supplies floating around these days?  Most of them have only 
manufacturer's model #s (not cisco's) affixed to them, so once the 
shipping paperwork is discarded, you can't tell an MAS-23 from an 
MAS-26 from an MAS-28 from a ...
 
Tom
 
Tom Karolyshyn
Data General Corp
Westboro, MA 01580
508-870-7936


Newsgroups: comp.dcom.sys.cisco
From: Alex Bochannek <abochann@brussels.cisco.com>
Subject: Re: Bug reports, and this mailing list...
Reply-To: abochann@cisco.com
Date: 12 Jan 93 7:47:14 MET
X-Mailer: ELM [version 2.3 PL11]
X-Note1: message-id generated by recnews
X-Note2: mail msgid was   <9301120647.AA27913@brussels.cisco.com>

> If you want an answer from Cisco the only ways to get a guaranteed
> response from Cisco is to call 800-553-2447 (24HR), or email sent
> to tac@cisco.com.

Please note, that in Europe a customer is supposed to contact his/her
distributor first. This guarantees responses in a timely manner as
there won't be any time zone problem. Furthermore the distributor
probably will be able to handle most of the easier requests right away
without calling us which reduces the answer times even more.

Thanks for noting this slight difference for our European customers.

-- 
Alex Bochannek                                   TAC   : +32 2 643 26-30
Technical Support Analyst                        Direct: +32 2 643 26-38
Cisco Systems International S.A.                 Fax   : +32 2 643 26-27
250 avenue Louise, 8th Floor                     RFC822: abochann@cisco.com
1050 Brussels, Belgium
Newsgroups: comp.dcom.sys.cisco
From: wildbill@lobby.ti.com (W. Smith)
Subject: RFC 951 and BOOTP
Date: 5 Jan 93 17:06:56 CST
X-Mailer: ELM [version 2.2 PL16]
X-Note1: message-id generated by recnews
X-Note2: mail msgid was   <9301052306.AA02151@lobby.ti.com>


FC 951 states that routers can be configured to forward BOOTP
requests. How does cisco handle such requests? Are the packets
forwarded as-is or are they altered in some way? Does the 
router need any specific parameters set or is it a default
process in the router software itself? I'm trying to determine
how interoperable cisco is with other router vendors.

W. Smith	 575-2363	wildbill@lobby.ti.com