(usr-tc) Comments on latest codes
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 "majordomo@xmission.com" 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.
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...
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
********************************************************* Michelle M. Mogil Network and Computing Systems 735 Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8521 email: mmm3@cornell.edu ********************************************** - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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...
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: k.nurklik@delfi.ee http://online.delfi.ee - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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...
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.
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! ********************************************************* Michelle M. Mogil Network and Computing Systems 735 Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8521 email: mmm3@cornell.edu ********************************************** - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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!
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, __________________________________ Kalev Nurklik Delfi Online Pa"rnu mnt. 158, 11317 Tallinn, Estonia Tel: +372 6501709 Fax: +372 6501708 E-mail: k.nurklik@delfi.ee http://online.delfi.ee - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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" <kalev@mail.lbi.ee> Organization: Delfi Online To: usr-tc@lists.xmission.com Date sent: Wed, 23 Aug 2000 17:11:45 +0200 Subject: Re: (usr-tc) Comments on latest codes Send reply to: usr-tc@lists.xmission.com
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!
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, __________________________________ Kalev Nurklik Delfi Online Pa"rnu mnt. 158, 11317 Tallinn, Estonia Tel: +372 6501709 Fax: +372 6501708 E-mail: k.nurklik@delfi.ee http://online.delfi.ee
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
__________________________________ Kalev Nurklik Delfi Online Pa"rnu mnt. 158, 11317 Tallinn, Estonia Tel: +372 6501709 Fax: +372 6501708 E-mail: k.nurklik@delfi.ee http://online.delfi.ee - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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.
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. ********************************************************* Michelle M. Mogil Network and Computing Systems 735 Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8521 email: mmm3@cornell.edu ********************************************** - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
Quoting Kalev Nurklik <kalev@mail.lbi.ee>: 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
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" <kalev@mail.lbi.ee> Organization: Delfi Online To: usr-tc@lists.xmission.com Date sent: Wed, 23 Aug 2000 17:11:45 +0200 Subject: Re: (usr-tc) Comments on latest codes Send reply to: usr-tc@lists.xmission.com
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!
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, __________________________________ Kalev Nurklik Delfi Online Pa"rnu mnt. 158, 11317 Tallinn, Estonia Tel: +372 6501709 Fax: +372 6501708 E-mail: k.nurklik@delfi.ee http://online.delfi.ee
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
__________________________________ Kalev Nurklik Delfi Online Pa"rnu mnt. 158, 11317 Tallinn, Estonia Tel: +372 6501709 Fax: +372 6501708 E-mail: k.nurklik@delfi.ee http://online.delfi.ee
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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) * mandrews@dcr.net * 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.) On Mon, 21 Aug 2000, Cheryl Johnson wrote:
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 "majordomo@xmission.com" 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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
On Wed, 23 Aug 2000, Mike Andrews wrote:
Seems stable here, save one SNMP-related memory leak in the ARC code (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 have not had any of the spontaneous reboots others have mentioned here.
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
Mike Andrews (MA12) * mandrews@dcr.net * 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.)
On Mon, 21 Aug 2000, Cheryl Johnson wrote:
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 "majordomo@xmission.com" 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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
On Wed, 23 Aug 2000, Charles Sprickman wrote:
On Wed, 23 Aug 2000, Mike Andrews wrote:
Seems stable here, save one SNMP-related memory leak in the ARC code (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.
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).
We 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.
Can anyone comment on any of these issues in the new code?
-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. Mike Andrews (MA12) * mandrews@dcr.net * 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.) - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
participants (7)
-
blacksea＠pumba.cheep.net.ua -
Charles Sprickman -
Cheryl Johnson -
Jeff Mcadams -
Kalev Nurklik -
Mike Andrews -
mmm3＠cornell.edu