HDTenEightyP/NetNews huggingface dataset:
From: djc@scimitar.unx.sas.com (David J. Cherveny)
Subject: Re: anyone using STUN to connect FEPs?
Originator: djc@scimitar.unx.sas.com
Date: Fri, 14 Aug 1992 00:42:43 GMT
Organization: SAS Institute Inc.


In article <ej.713727684@cc.univie.ac.at>, ej@cc.univie.ac.at (Ewald Jenisch) writes:
|> ssw@bronze.ucs.indiana.edu (steven wallace) writes:
|> 
|> >We're considering using STUN to connect a local 3725 to a remote
|> >3725.  Anyone have experience using STUN to connect IBM FEPs?
|> 
|> Yes, we've done exactly that -- at least with partial success. Our
|> only problem was that the SNA-tunnel can't get through frames larger
|> than about 1500 or 2000 bytes unfragmented.
|> 
|> If I remember right, this isn't actually a problem with the tunnel
|> itself, but rather a limit of the hardware of the serials: they are
|> limited to 1500 or 2000 bytes (don't remember the exact figure
|> though).
|> 
|> If fragmentation isn't a problem for your SNA-applications you should
|> be happy with the STUN connecting FEPs though. We've had no
|> configuration tuning besides proxy-poll in order to keep the WAN
|> responsive.
|> 
|> On the software-side we used 8.3(1) and 8.3(3). (we've done our tests
|> some months ago)
|> 
|> -ewald
|> 
|> --
|> Ewald Jenisch                      |  E-mail: ewald.jenisch@cc.univie.ac.at 
|> Vienna University Computer Center  |          z00ejr01@awiuni11.bitnet
|> Universitaetsstrasse 7             |  Tel: +43 (222) 43-61-11 x251  Fax x170
|> A-1010 Vienna, Austria             |  NIC-Handle: EJ63
|> 
|> 
|> 
|> 

We ( SAS Institute Inc ) tried STUN between FEPs and ran into the same
problem.  In particular, when we ran SAS ( our favorite program ), it
failed.  Other applications like SPF ran OK.

To improve performance, SAS apparently draws its screens with large writes.
4k or so it seems.   I haven't talked to the developers, this is from
analyzing the data stream.

We looked into adjusting some parameters on the FEPs to limit the max
data size but it was thought performance would suffer too much.

Due to various other considerations, and lack of a pair of FEPs to test
with, we punted and just multiplexed the circuit.  Sigh.


So, how did you get around the 2k limit?  Tweek some VTAM parameters?



David Cherveny				djc@unx.sas.com
Systems Programmer, networking
Network Support Dept
SAS Institute Inc.

( SAS is a registered trademark of SAS Institute Inc. )






Newsgroups: comp.dcom.sys.cisco
From: jpm@apple.fi (Jussi-Pekka Mantere)
Subject: rtr_90.psf.Z on ftp.cisco.com & fonts?
Date: Thu, 20 Aug 1992 15:29:54 GMT
Organization: Apple Computer Finland Oy

What's this font "Bembo" that's supposed to be used in the document
"rtr_90.psf.Z"??? At least a couple of LaserWriters just dump it for
Courier, and the doc really doesn't look too good...

Best Regards,

Jussi-Pekka Mantere
Newsgroups: comp.dcom.sys.cisco
From: rjberke@berke.itg.ti.com (Richard Berke)
Subject: TACACS
Organization: Texas Instruments Electronic Communications
Date: Mon, 17 Aug 1992 22:24:28 GMT

On what systems does TACACS run?  Do you get it as source code,
tailored for installation on a specific range of machines? 
or do you only get one base code, and have to tweak it yourself to fit your 
system?

I'd like not to re-invent a wheel others have solved already.

Is there a security related newsgroup to relay this as a more appropriate
discussion audience?

Thanks,
Richard Berke

Richard Berke   RBRK   rjberke@lobby.ti.com  (214) 575-2828
Texas Instruments      Plano, Texas
------------------------------------------------------------------------------
Newsgroups: comp.dcom.sys.cisco
From: martinr@mayo.edu (Robert Martin)
Subject: AGS+ and source-route bridging
Date: 21 Aug 92 10:56:18 -0500

Thank you to all who responded.  Unfortunately, the hard lesson was taught
to us again.  The problems were attributed mostly to T-1 line errors!
With our Ethernet load on a weak T-1, things worked ok.  When the Token-
ring traffic was added (a substantial amount), the T-1 errors caused a
massive number of packets to be dropped.  Not all traffic died, but the
"new" Token-ring traffic was unusable, therefore, we concentrated too much
on this.  I am still pondering why this was not obvious, but at least what
we wanted to accomplish is much nearer, now.

(The more things change, the more they stay the same.)
From: grega@math.uakron.edu (Greg Akers)
Newsgroups: comp.dcom.sys.cisco
Subject: cisco Provided DNS
Date: 19 Aug 92 21:58:36 GMT
Article-I.D.: news.1992Aug19.215836.8100
Organization: University of Akron, Department of Mathematical Sciences
Originator: grega@zippysun

Maybe I was dreaming this, but, awhile back I was playing around and
seemed to discover that our AGS could act as limited DNS. It could
provide staticly config`ed host ip-addresses. This was probably around
8.2(4). I tried to do this now that the router is running 8.3(3)+
and it doesn't seem to function anymore. Am I wrong ? If so is there
any plans to do such a thing in the future ?

Greg Akers

grega@zippysun.math.uakron.edu
Newsgroups: comp.dcom.sys.cisco
From: J045820@LMSC5.IS.LMSC.LOCKHEED.COM
Subject: Cisco Information
Organization: Lockheed Missiles & Space Company, Inc.
Date: Tue, 18 Aug 92 15:08:11 GMT

I need information on Cisco Routers. Is it possible to FTP information
on this subject. We are attempting to do research on the units before
they arrive on site. Any assistance would be greatly appreciated!!!
                                 Billy Smith LMSC Co.
From: gig@ejs.is (Gudjon Ingi Gestsson)
Newsgroups: comp.dcom.sys.cisco
Subject: NetCentral on a IPX
Date: 18 Aug 92 11:22:34 GMT
Organization: Einar J. Skulason, Iceland


Hi!

I have a problem in running NetCentral 1.2 on a IPX.
When I start any of the options in the DBS Management I get
big black stripes from top to bottom of the screen.



Gudjon Ingi Gestsson

gig@ejs.is
Newsgroups: comp.dcom.sys.cisco
From: jzwiebel@pgl-devsvr.den.mmc.com (John Zwiebel 303-977-1480 jzwiebel@pgl-devsvr.den.mmc.com)
Subject: RS6000 FDDI/IP disconnect
Organization: PAGE @ Martin-Marietta
Date: Thu, 20 Aug 1992 17:11:15 GMT

 
I have a FDDI ring with about 20 RS6000's and 4 cisco AGS routers on it.  If I "bounce" the ring the FDDI stack and the IP stack on the RS6000 will stop talking to each other.

"Bouncing the ring" means:
	-disconnecting and reconnecting an FDDI cable on any system on the ring.
	-rebooting one of the RS6000's (or several of them)
	-issuing the command "clear int fddi 0" on one of the routers.
	-or any combination of these.

Performing one of these actions and waiting for a period of at least five minutes does not cause any problem.  Performing several of these actions in a fairly short time will cause one or more of the RS6000's to exhibit the 'disconnect' systems.

"FDDI/IP disconnect" means the RS6000 with the problem:
	-can not communicate via IP over the FDDI interface meaning:
		NO response to ping queries sent to the problem host
		NO response to ping queries sent from the problem host
		NO LLC FDDI packets from the problem host recorded on a 
			lanalyzer.
	-the upstream and downstream neighbors of the problem host show normal 
		FDDI connections.  (thru, etc)
	-the command 'fddistate 0' on the problem host shows normal FDDI 				connections.
	-there is no change in the ARP table on the problem host or any other
		system connected to the network.
	-there is no change in the routing table on the problem host or any
		other system connected to the network.
	-a FDDI lanalyzer continues to record some packets from the 
		problem host.
	-After a period of about 20 minutes, without any operator actions, 
		normal IP traffic will resume.
	-If the problem host is rebooted, normal traffic will resume.

The cisco routers are now running OS 8.3(3.2) but they have run other newer and older versions of the OS.  The cisco systems never have any trouble maintaining communication over the ring.

Recording traffic when the problem shows that the ring enters a token claim state and then a beacon state.  The DTI lanalyzer buffer is filled almost immediatly having captured over 50K packets in about a second.  It is filled before the renegotiation process is completed so I can't provide much more information on what is really happening on the ring.
 
Has anyone else seen this problem? 

Does anyone have any suggestions on what additional information I should try to gather so I can make an intelligent problem report to IBM?

Please send Email
Thanks
jzwiebel@pgl-devsvr.den.mmc.com
Newsgroups: comp.dcom.sys.cisco
From: Tom_Karolyshyn@dgc.mceo.dg.com
Subject: 9.0(1) summary
Date: 10 Aug 92 13:46:04 edt


Thanks to all who responded to my inquiry about the stability of 
9.0(1) software. 
The responses were varied, to say the least.  Most users who 
responded said they were running 9.0(1) just fine using TCP/IP 
routing and transparent bridging.  This is the real world side.
However, feedback from cisco reps ranged from "there are bugs" and 
"be cautious" to it's "probably the stablest release cisco has 
shipped".
 
So go figure.  It sounds like there are bugs, but each one is 
configuration dependent (as always).  If you're running 9.0(1) and it 
works, don't knock it.  If you try 9.0(1) and it doesn't work, well 
there is probably a known bug.  Personally, I haven't had the best of 
luck lately with new software.  Maybe it's because we push each 
feature to the limit; I don't know.  But given our recent history of 
bug encounters, we would probably uncover every one.  So I will opt 
to delay until 9.0(2), unless I get adventurous :-) 
Tom
 
Tom Karolyshyn  Data General Corp  Westboro, MA  01580  508-870-7936
From: p667343@austin.lockheed.com (p667343)
Newsgroups: comp.dcom.sys.cisco
Subject: CGS serial loopback test help needed
Date: 12 Aug 92 17:46:57 GMT
Distribution: usa
Organization: "Lockheed Austin Division, 6800 Burleson Rd, Austin, TX 78744"

I am preparing to move our router from its present location to
another facility located several miles away.  The two locations are
networked together with an ethernet bridge over a serial line.
To minimize down time, I intend to install a spare router in the new
facility, and use a separate leased line to our routing neighbor.  
Before bringing down the old connection, I want to be certain the new 
one will work.

Here is the problem.  Although the CSU/DSU passes its remote loopback test
with the other end, I cannot ping my own serial interface and get a response.
To eliminate problems with the CSU/DSU setup (internal vs. external timing,
etc.), I want to loop the CGS serial interface back upon itself and try to
get a valid ping response.  What are the proper signal connections,  are there
any special config commands necessary, and does the ethernet port need to
be connected?

Serial port 0 has a male connector, so it is DTE according to the hardware
manual.  Apparently the operating router gets it's clock from the CSU/DSU, as
it has no clockrate commands in the config.  The spare router's TXC light does
not come unless the config line <clockrate 56000> is entered.

I have made an attempt I thought should work.  The following pin groups
were connected.

	pins 2,3	(TX,RX)
	pins 4,5	(RTS,CTS)
	pins 15,17	(TXC,RXC)
	pins 6,8,20	(CD, ,DTR)

According to the cisco manual, pin 8 is unused, however leaving pin 8
unconnected extinguishes the red Rx line signal detect LED.
                                  
If anyone can tell me how to do this, I will be grateful, and ready to
tackle the next piece of hardware in the chain.

Thanks for any and all advice.

Tom Benjamin
Computer/Network Support
Lockheed Austin Division
(512)-386-2887
thomasb@austin.lockheed.com     (don't use the <From:> address)
From: apollo@buengc.bu.edu (Doug A. Chan)
Newsgroups: comp.dcom.sys.cisco
Subject: Will this circuit backup solution work?
Date: 13 Aug 92 04:33:48 GMT
Distribution: na
Organization: College of Engineering, Boston University, Boston, MA, USA
Originator: apollo@buengc.bu.edu

I'm going to have two MGS connected over a dedicated 56Kbps circuit.
Currently I've got enough equipment around to setup a backup circuit using
switched-56/ISDN-BRI but it all hinges on whether the router can be 
configured to work with it.

 [ROUTER_A]                                                [ROUTER_B]
     #                                                       #    #
     #                                                       #    #
     #    /--{ded-56}----------//------------{ded-56}---[CSU_B]   #
  [CSU_A]<                                                        #
          \--{sw-56}-----------//-----------{ISDN}--[TERMINAL_ADAPTER]

CSU_A can pull up a switched circuit when the dedicated line is down.
Suppose router_A's serial port IP address is 200.200.200.1 and router_B
has 200.200.200.2 and 200.200.200.3 for it's interfaces.  Obviously,
router_B will be talking thru either one of two serial ports depending
on the state of the dedicated circuit.
Will either/both routers run into problems with sudden changes of it's
"path"?

FYI, Router_A is running 8.3.3 while router_B has 8.2.7.

-Doug
apollo@buengc.bu.edu
Newsgroups: comp.dcom.sys.cisco
From: Paul Traina <pst@CISCO.com>
Subject: Re: Problems using unnumbered serial interfaces in 9.0(1) 
             <9208122209.AA5f0@GARFY.nil.yu> 
Date: 12 Aug 92 09:31:58 PDT
X-From: <pst@cisco.com>

-Excellent- diagnosis.  I rarely see a customer report as detailed as the one
you submitted.  You're absolutely correct.  The split horizon logic put into
8.3(3) and 9.0(1) broke routing updates exactly as you specified.

I wrote a fix for it (CSCdi06205) a couple of weeks ago,  but it hasn't been
included in any production release yet.

Please contact a CE and ask them to keep an eye on this bug and ship you
a copy of the next beta-release with this fix in it.  I'm surprised that
this hasn't made it into 8.3 and 9.0 yet.

Regards,
Paul

  From: Ivan Pepelnjak <Ivan.Pepelnjak@nil.yu>
  Subject: Problems using unnumbered serial interfaces in 9.0(1)
  Hello !
  
  I have encountered a serious IP routing problem when using unnumbered
  serial interfaces with RIP in release 9.0(1). Consider the following
  simple network :
  
    network A (192.84.104.0)              network B (192.84.105.0)
  ===========================             ============================
               !                                   !                 
           +---------+     serial link         +---------+           
           |  IGS/R  | <---------------------> |  IGS/R  |           
           +---------+                         +---------+           
  
  With SW release 8.3 all you have to do was a simple setup similar to
  
  	interface ether 0
  	ip address 192.84.104.10
  	interface serial 0
  	ip unnumbered ether 0
  	router rip
  	network 192.84.104.0
  	network 192.84.105.0
  
  However, when using the same configuration with release 9.0(1), the
  Ethernet network is not announced across the serial link. Evidently
  the router thinks that the serial interface belongs to the same network
  and thanks to new split-horizon logic does not announce network A or B
  across the serial line (debug ip-rip output shows "RIP update suppressed").
  
  Turning the split-horizon off helps a bit, but not when you are in 
  mixed versions environment (a mixture of 8.3 and 9.0). Numbering the
  serial line with IP addresses from yet another class-C network solves
  the problem (technically but surely not organisationally).
  
  Has anybody encountered anything like that with 9.0(1) or am I doing
  something wrong ?
  
  Ivan
  
  Ivan Pepelnjak					Phone : +38 61 372-713
  Technical manager				FAX:	+38 61 372-809
  NIL, Systems integration and Consulting		E-Mail:	pipi@nil.yu
>>	
  Ljubljana, Slovenia

Newsgroups: comp.dcom.sys.cisco
From: Jim Young <jyoung@cisco.com>
Subject: Problems hooking Cisco to T1 line
Date: 19 Aug 92 14:29:16 -0700


Tim,

You say your using 1.424M, this is not a common speed for DSU's that I have 
worked with in the past. 
What kind of line encoding does GTE have setup for you?
Is it possibly AMI?
If it is AMI and you are using HDLC, then I would suggest inverting the data
at the DSU. This will garuanty your 1's density.

The thing that bothers me the most was you said you have a cable that goes from
RS449 (39 pin D conn.) to a DB25 conn. Do you know if this is actually an RS530
interface or is it some modified hybrid?

If you are still having problems, please feel free to send email to tac@cisco.com
and a case will be opened for you. If you include the info I asked then it will
help speed the troubleshooting of your problem. Please also include "show hard",
"show int ser x" and "show cont mci".


I hope some of this helps. (-:

Jim Young
cisco CE
Newsgroups: comp.dcom.sys.cisco
From: ej@cc.univie.ac.at (Ewald Jenisch)
Subject: Re: anyone using STUN to connect FEPs?
Organization: Vienna University
Date: Thu, 13 Aug 1992 17:41:24 GMT

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

>We're considering using STUN to connect a local 3725 to a remote
>3725.  Anyone have experience using STUN to connect IBM FEPs?

Yes, we've done exactly that -- at least with partial success. Our
only problem was that the SNA-tunnel can't get through frames larger
than about 1500 or 2000 bytes unfragmented.

If I remember right, this isn't actually a problem with the tunnel
itself, but rather a limit of the hardware of the serials: they are
limited to 1500 or 2000 bytes (don't remember the exact figure
though).

If fragmentation isn't a problem for your SNA-applications you should
be happy with the STUN connecting FEPs though. We've had no
configuration tuning besides proxy-poll in order to keep the WAN
responsive.

On the software-side we used 8.3(1) and 8.3(3). (we've done our tests
some months ago)

-ewald

--
Ewald Jenisch                      |  E-mail: ewald.jenisch@cc.univie.ac.at 
Vienna University Computer Center  |          z00ejr01@awiuni11.bitnet
Universitaetsstrasse 7             |  Tel: +43 (222) 43-61-11 x251  Fax x170
A-1010 Vienna, Austria             |  NIC-Handle: EJ63



	
Newsgroups: comp.dcom.sys.cisco
From: Alex Bahoor <bahoor@last-call.cisco.com>
Subject: Re: RS6000 FDDI/IP disconnect
Date: 21 Aug 92 10:22:24 PDT



John, it dosn't seem that you can do much more. A trace on the ring from start
to finish of claim process will surely tell something, but you get filled up
buffer before the process is ended. May be if you start logging toward the
end of the claim process may tell you a clue. The fact that you saw claim and
then beaconing process started may have been caused by either a defective
cable which should cause more than one machine to beacon or the defective IBM
host thought there was a cable problem, a buggy host.

Take a  look at the cisco fddi interface (show int fddi 0): look for
bursts of carrier transitions when the IBM host is not functional. Turn debug
fddi-cmt on the upstream and downstream ciscoes from the IBM host if any and
monitor the fddi ring activity. I doubt you would see much, yet it may
suppliment your claim to IBM.


Good Luck!

Alex Bahoor
Customer Engineering
cisco Systems Inc
Mountain View CA 94043
Newsgroups: comp.dcom.sys.cisco
From: Allan Leinwand <leinwand@cisco.com>
Subject: cisco information
Date: 18 Aug 92 10:01:46 PDT
X-Mailer: ELM [version 2.3 PL11]

>I need information on Cisco Routers. Is it possible to FTP information
>on this subject. We are attempting to do research on the units before
>they arrive on site. Any assistance would be greatly appreciated!!!
                                 Billy Smith LMSC Co.

Hello Billy,

   If you need information on cisco Systems products, please send
e-mail to cs@cisco.com.  I have forwarded your original request to the
appropriate people.

   You can also grab the README file from ftp.cisco.com via anonymous
ftp to see what we offer for public consumption.

-- 
Thanks,

Allan Leinwand
cisco Systems
(415) 688-7653
leinwand@cisco.com
Newsgroups: comp.dcom.sys.cisco
From: evan@is.rice.edu (Evan R. Wetstone)
Subject: Tacacs-server authneticate slip
Date: 12 Aug 92 12:35:32 CDT
X-Mailer: ELM [version 2.3 PL11]

Has anyone gotten the command "tacacs-server authenticate slip" to work?

I'm trying to find some mechanism to allow and control SLIP access to our
terminal server on the same lines that I allow unauthenticated (but address-
filtered) telnet access.  The manual suggests that "tacacs-server
authenticate slip" would be the way to do this.

I can't get it to work at all.  On some of our lines (which require tacacs
authentication to log into) the terminal server will send a "SLIPON" message
to the tacacs server.  Watching this with our Sniffer, I can see that it 
sends the tacacs message with just a userid.  On our other lines, which do
not require tacacs logins, no message gets sent at all.  In no case does
the terminal server ever prompt for a userid and password to enable SLIP.

Our terminal server is a CSC/2 running 8.3(3.1 )

Any pointers will be appreciated.

-- 
Evan 
Newsgroups: comp.dcom.sys.cisco
From: TOSDRST@ge1vm.schdy.ge.com
Subject: TOKEN Ring sessions dropping
Date: 11 Aug 92 11:02:53 EDT

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
From:
Subject: TOKEN Ring sessions dropping
Hello list,
 Please any suggestions.
Suddenly two of our seriAL IGS remote connected sites ..3174 and attachmnet
gateway commuities started dropping...(bull and corps)

bull----------rt1
corps --------rt1____ethernet____rts---token ring---ncp

 rt1 buffer=400-500   ... 14 serial lines connected  to rt1
 rts buffers= 90-100
We have been told that rt1 is too loaded.
therefore we must remove load from rt1 or move lines to rts...
 or increase the t1 timers on the remote equipt...
Can anyone tell me how to confirm that this is the problem ?
 Is there anything else that I should look into ??
Thanks,
 Don Smith -- GE Schenectady Megacenter

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
From The Desk of Don Smith.
From: rob@cs.aukuni.ac.nz (Rob Burrowes )
Newsgroups: comp.dcom.sys.cisco
Subject: Does appletalk distribute-list work under 8.3(3)?
Summary: Does appletalk distribute-list work under 8.3(3)?
Keywords: distribute-list appletalk 8.3(3)
Date: 21 Aug 92 02:30:14 GMT
Organization: Computer Science Dept. University of Auckland


I have been trying to understand the appletalk distribute-list command on a
router running 8.3(3). I thought I had it worked out but...

The router has 6 ports. I set up an access-list 601
access-list 601 permit 205
access-list 601 permit 206
access-list 601 permit 210
access-list 601 permit 211
...
access-list 601 permit 229
access-list 601 permit 230
and have set up some of the interface
!
interface Ethernet 2
ip address 130.216.33.1 255.255.255.0
ip broadcast-address 130.216.33.255
appletalk cable-range 205-205 205.84
appletalk zone CS-GRAD-2
appletalk distribute-list 601 out
!
interface Ethernet 3
ip address 130.216.34.1 255.255.255.0
ip broadcast-address 130.216.34.255
appletalk cable-range 200-200 200.168
appletalk zone CS-Staff
!
interface Ethernet 4
ip address 130.216.35.1 255.255.255.0
ip broadcast-address 130.216.35.255
appletalk cable-range 210-210 210.36
appletalk zone CS.UGL_1
appletalk distribute-list 601 out
!
interface 2 has net 206 off of it via a KFP IV running 8.01 software
interface 3 has net 201 off of it via a KFP IV running 8.01 software
interface 4 has nets 211 - 229 (with some gaps) connected again through KFP IV's.

I believed I should be able to see from interface 3 CS-Staff into CS.UGL_1 and
into CS-GRAD-2 but not the other way.
This is almost true. I can't see CS-Staff from CS.UGL_1 or CS-GRAD-2. I can
see the directly connected Mac's on CS.UGL_1 and CS-GRAD-2 but not the ones
connected to it via the KFP IV's.

Is this what I should expect? I had hoped to be able to see all of the
CS.UGL_1 and CS-GRAD-2 zones from CS-Staff.

If I add
access-list 601 permit 200
then I can see all of the CS.UGL_1 and CS-GRAD-2 zones from CS-Staff, but they
can also see CS-Staff.
-- 

Rob Burrowes                   rob@cs.aukuni.ac.nz.
System Admin
Computer Science Dept., Auckland University, Private Bag, Auckland, New Zealand