Subject: (usr-tc) Comments on latest codes

From: Cheryl Johnson <[email-masked]>
Date: Mon, 21 Aug 2000 23:22:54 +0000

Before attempting to upgrade our USR chassis I thought it may be wise to ask
the list of their thoughts first. Is anyone running the following software
releases? If so, any input on stability or any known problems would be
greatly appreciated.

NMC 7.1.8
ARC 5.0.9
DSP 2.1.9

-Cheryl
Network Administrator
SEI Communications Data and Network Services

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

---

From: [email-masked]
Date: Tue, 22 Aug 2000 15:25:33 +0000

I'm running this on my test chassis and it appears to be fairly
stable, except for the fact that my ARC spontaneously reboots on
a random basis. I'm not sure if this is because of the new code
or if I need to reflash the card. I was advised by 3Com to
reflash and will probably do that at some point as I'd like to
upgrade my production pool soon...

>SEI Communications Data and Network Services

*********************************************************
Michelle M. Mogil
Network and Computing Systems
735 Rhodes Hall, Cornell University, Ithaca, NY 14853
vox: (607) 255-0516, fax: (607) 255-8521
email: [email-masked]
**********************************************

-

---

From: Kalev Nurklik <[email-masked]>
Date: Tue, 22 Aug 2000 20:09:55 +0000

> upgrade my production pool soon...

Hmm... noticed the same thing. I was to write about this to the list but
stumbled on other event couple of days ago. The ARC rebooted on the same time
when I used pmcom style utility on it.
After some figuring out I checked the telnet clients on HARC and got this:

hiper4> list telNET cliENTS 
 
TELNET CLIENT ADDRESSES 
IP Address        Netmask
1.1.1.1   CLI - Software Error - data flag print undefined: 0
 255.255.255.255

Checked a little further and seem that there's a problem with
host mask with telnet clients on ARC. If the network is bigger
than one host then the clients will stick and list normal.

I haven't confirmed in any reasonable way what exactly is to blame but
since I have turned the pmcom style access off to the ARC and also deleted
the host fields in telnet client list there has been no reboots.

__________________________________
Kalev Nurklik
Delfi Online
Pa"rnu mnt. 158, 11317 Tallinn, Estonia
Tel: +372 6501709
Fax: +372 6501708
E-mail: [email-masked]
http://online.delfi.ee

-

---

From: Mike Andrews <[email-masked]>
Date: Wed, 23 Aug 2000 06:39:04 +0000

Seems stable here, save one SNMP-related memory leak in the ARC code
(specific to walking a particular section of the tree; real obscure).  We
have not had any of the spontaneous reboots others have mentioned here.

Mike Andrews (MA12) * [email-masked] * http://www.bit0.com/
VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
Dialup/ADSL/ISDN/T1 Internet access for Frankfort KY and surrounding counties
www.fark.com: If it's not news, it's Fark.  (Or something like that.)

-

---

From: [email-masked]
Date: Wed, 23 Aug 2000 16:19:02 +0000

>1.1.1.1   CLI - Software Error - data flag print undefined: 0

I found the same thing on my ARC. Can you tell me in detail how you
turned this pmcom access off and how you deleted the host fields?
Thank you!

-

---

From: Kalev Nurklik <[email-masked]>
Date: Wed, 23 Aug 2000 17:15:43 +0000

> turned this pmcom access off and how you deleted the host fields?

Sorry. I kind of used a wrong name... 'pmwho' maybe rings the bell?
Or in other words what I meant with pmcom style access is
- any access that uses telnet to ARC for getting info with
ARCs CLI commands and outputing the result for instance to a shell user.

If I remember it correctly then there was a DOS attack possibility with
telnet access to ARCs couple of ARC software releases ago.

I myself and probably everybody else turned on at that time the telnet client
access feature on ARCs with 'enable telnet client_access' command.
Before that of course I defined telnet client list who were to be allowed
access to ARC. I did it with 'add telnet client x.x.x.x/y' command.
Some of them were with /32 bitmask.

So You have couple of possibilities to try if the client list is to be blamed
for ARC spontaneous reboots.
1. Just turn off the access checking with 'disable telnet client_access'
or
2. delete the host entries with 'delete telnet client x.x.x.x' and replace
them with 'add telnet client x.x.x.x/y' where y is less than 32.

I myself used the second option but in addition denied the usage of 'pmwho'
to our support people. For now.
I'll allow it eventually to see if pmwho is the guilty one...

Regards,

-

---

From: Charles Sprickman <[email-masked]>
Date: Wed, 23 Aug 2000 20:28:59 +0000

On Wed, 23 Aug 2000, Mike Andrews wrote:

> (specific to walking a particular section of the tree; real obscure).  

Hmmm...  What OID tickles it?  We run lots of monitoring on things that
may or may not be obscure every 10 minutes.

> We

Can anyone comment on any of these issues in the new code?

-the quads going into busy-out under 4.2.32 - fixed?
-OSPF - trust it?

Thanks,

Charles

-

---

From: Mike Andrews <[email-masked]>
Date: Thu, 24 Aug 2000 19:10:51 +0000

> may or may not be obscure every 10 minutes.

They're all new OIDs that weren't in 4.2.32.  The one in particular that
tripped me up is the 1.3.6.1.4.1.429.4.2.1.46.1.6 tree, or something else
in that area (if not .1.6, then .1.something).

> > have not had any of the spontaneous reboots others have mentioned here.

And I think several people hit on why here: it has to do with the telnet
client list table.  We don't use that feature; we let access lists on our
routers do that sort of thing.

> -the quads going into busy-out under 4.2.32 - fixed?

Haven't run into that one.  We had one Quad go out to lunch last week, but
that's the first time in over a year I've seen that happen.

> -OSPF - trust it?

No big difference that I can tell.  Search the mailing list archives and
you'll see many many many posts about one particular problem I had, with
OSPF getting confused about subnet masks in a particular case.  MR12019 is
3Com's bug id for it.  This wasn't fixed during the beta, or in the 5.0.9
release, though I was told it was "very close".  Anyway, I got tired of
waiting for a fix, so I gave up and worked around it by moving my ARCs to
another subnet.

Modulo that little problem, OSPF works fine for us.

I didn't have much luck setting up authenticated OSPF, but I'll admit I
didn't try very hard. :)  I'm going to give it another crack in the next
month or two.

-

---

From: Jeff Mcadams <[email-masked]>
Date: Thu, 24 Aug 2000 19:21:37 +0000

Also sprach Mike Andrews
>This wasn't fixed during the beta, or in the 5.0.9 release, though I
>was told it was "very close".

While on the note of beta bugs...don't use the DHCP support in 5.0.9.
While the idea is cool, and it *will* be implmented here when it works,
that's the issue...it doesn't work yet.  Specifically, lease renewals
are totally broken.  I've not had any update on this, nor do I even have
an MR number on it.  :/
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Kalev Nurklik <[email-masked]>
Date: Mon, 18 Sep 2000 17:12:52 +0000

The HARCs still reboot here spontaneously even with minimal telnet
access and 'telnet client list' set to disabled. They do it less
often but still do it.

BTW, does the statement 'Any Hiper ARC software prior to
4.1.13 and 4.2.73 is not backward compatible. The downgrade procedure
will cause a complete loss of configuration on the cards and require
the use of the "DELETE CONFIGURATION" command when going to any
older code.' in HARC 5.0 release notes PDF file hold water?
Do I really have to configure the cards from scratch if I don't
have prior version bulk configuration handy?

Only thing I have is HARCs crashdump but I don't know if anybody
on this list can help me with that.
Here it is -

<start>
EXCEPTION 0200 CRASH DUMP  (mm-dd-yy : 09-16-2000  hr-min-sec : 10-50-17)
 
AppVer: 5.0.9-1  KernVer: 0x0000002d
 
GPRs:
R0:  0x0079006C  R1:  0x07F55B78  R2:  0x000EED24  R3:  0x0A93FA04  
R4:  0x01FCFFAB  R5:  0x01FCFFAB  R6:  0x00000001  R7:  0x00000000  
R8:  0x00000050  R9:  0x00000024  R10: 0x00000000  R11: 0x00FEE460  
R12: 0x4C69734D  R13: 0x000F8D58  R14: 0x009275F4  R15: 0x009275D8  
R16: 0x009275E0  R17: 0x009275CC  R18: 0x009275D4  R19: 0x009275E4  
R20: 0xFFFFFEFF  R21: 0x00AB8E30  R22: 0x002DFBA8  R23: 0x00AAF020  
R24: 0x0237BE60  R25: 0x01FCFFAB  R26: 0x00000024  R27: 0x00000004  
R28: 0x00790B1C  R29: 0x00FC2C78  R30: 0x07F55C70  R31: 0x0A93F9E0  
 
CR:    0x40000404  XER:   0x00000018  LR:    0x00790B34  CTR:   0x0079CAF4
SRR0:  0x0007BF64  SRR1:  0x00089030  DSISR: 0x40000000  DAR:   0x5C88495F
 
82660 Registers:
Err Status 1: 0x20, Err Status 2: 0x00, CPU Err: 0x72, PCI Err: 0x06
CPU/PCI Addr: 0x0A93FA00,  Sys Error Addr: 0x0A93FA00

Call Stack:
    0x0007BF64    (Exception return address - SRR0)
    0x00790B34
    0x0079006C
    0x007901D0
    0x0079CB58
    0x0079CE10
    0x00460D14
    0x0045FE68
    0x0045AC08
    0x0045649C
    0x00458880
    0x00459124
    0x004592AC
    0x00457830
    0x005AEA7C
    0x005B0264
    0x005BABDC
    0x0061C18C
    0x00619668
    0x005F84C4
    0x005F56B8
    0x002DFBFC
<end>

BTW, Michelle, have You had any better luck explaining this behaviour?

Regards,

From:           	"Kalev Nurklik" <[email-masked]>
Organization:   	Delfi Online
To:             	[email-masked]
Date sent:      	Wed, 23 Aug 2000 17:11:45 +0200
Subject:        	Re: (usr-tc) Comments on latest codes
Send reply to:  	[email-masked]

-

---

From: [email-masked]
Date: Mon, 18 Sep 2000 17:54:33 +0000

>access and 'telnet client list' set to disabled. They do it less

Ugh...I've been struggling with the ARC on our testpool for months 
now. We were having problems with it choking up; I observed that the 
DSP would suddenly have all 23 channels 'local-out-of-service' and 
the only way to get it to take calls again was to 1] 'Restore' the 
channels, and 2] do a software reset on the ARC (why???). I upgraded 
it (the ARC) to 5.0.9 and began having major trouble with
it rebooting itself almost daily. A 3Com technician managed to 
finally install 5.0.88 (engineering release) on it after a struggle 
and now it's back to its old trick of choking up and requiring a 
software reset. I'm very tempted to back off to the previous 
version--4.1.59--which has been running on the production pool with 
no problems.

-

---

From: [email-masked]
Date: Mon, 18 Sep 2000 17:56:44 +0000

Quoting Kalev Nurklik <[email-masked]>:
Hi 
I was wondering if you can help be I'm loking for the flash codes to change my 
TC to E1 is flashed for T1 access at the moment! NMC and Netserver cards!!

Craig

-