Howdy, Are these on a HiPer or NetServer? What SW version? PRI or CT1? I don't know about trap settings, but if you use snmpwalk to take a look at the following MIBs, you should get the status: #ds0-level items (PRI/T1 card only) $oid_ds0_stat=".iso.org.dod.internet.private.enterprises.usr.nas.ds0.ds0StatTable.d s0StatEntry.ds0StatDs0"; $oid_ds0_statmodem=".iso.org.dod.internet.private.enterprises.usr.nas.ds0.ds0StatTa ble.ds0StatEntry.ds0StatModem"; I'm sorry I don't have the numeric OID's, this box has all the USR MIBs loaded up. This is a snippet from a general TC health monitor we put together. When I get the symptoms you describe, the modem status shows "modem busy out". We are running CT1's and ARCs, and this problem did not appear until an upgrade of the Hiper software to 4.2.32... Just putting together a perl script that walks those snmp values once a day and mails you the output should be enough to alert you to problems before customers start to complain. As to the root cause, I have no idea; we don't have a support contract so I can't open a ticket. Something in the HiPer code broke it though, as this started as soon as we upgraded the Arc. If anyone knows the OIDs to reset channels on the quads, that would be great. I'd love to have my script do this rather than having to fire up TCM. If anyone is curious about my monitoring script, let me know. It's very ugly as it was one of my first perl projects. I need to basically rewrite it to use the perl snmp module... Charles | Charles Sprickman | Internet Channel | INCH System Administration Team | (212)243-5200 | spork@inch.com | access@inch.com On Fri, 17 Nov 2000, D. W. Piper wrote:
I've searched through the 3Com documentation, online knowledgebase, etc. for information or help on this without success.
The symptoms:
- customers complain about experiencing busy signals, and/or RNA, and/or dead air; - we discover that one of the quad modems on the relevant chassis is showing a flashing red LED when a call comes in; - resetting the modem using TCM generally resolves the problem.
The questions:
What causes this to occur? Is there any way to test for this situation (perhaps using Alarm Server, if there's any trap setting that would detect this kind of problem) sooner, before we have irate customers calling in to complain?
Thanks for any help,
David (at wits' end - or is that witless?)
- 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.