The "Annotation" field can be used as a comment. You can check that the NMC is sending traps by pulling out or inserting a card (other than the NMC)- The card insert traps are enabled by default and are a quick test (as long as you have a card you can play with). The Fan Failure Trap is also enabled by default... HiperDSP trap or log settings at the modem level require a template refresh to take affect (a good reason to have been setting the modem parms using templates instead of directly on the modems). The Span level stuff should not need this though. See if you can get ANY trap out of the NMC to start with. STeve Valiunas "Lon R. Stockton, Jr." <lon@moonstar.com> on 01/06/2000 09:19:15 AM Please respond to usr-tc@lists.xmission.com Sent by: "Lon R. Stockton, Jr." <lon@moonstar.com> To: usr-tc@lists.xmission.com cc: (Steve Valiunas/MW/US/3Com) Subject: (usr-tc) trapped with snmp Now that I've (locally) discovered the use of perl and the Net:SNMP module to talk to my TC (HiPer) chassis, I've recently been feeling all godlike and stuff. Of course, when a human experiences a taste of godhood, the PowersThatBe quickly queue up a lesson in humility. Anyway, I'm trying to play with SNMP traps and I must be missing something obvious. Here's the deal: 1) I run snmptrapd (from cmu-snmp-utils-3.5-3) on a handy linux box, telling it to both print the trap and dump inbound packets. 2) I verify operation of #1 by running snmptrap to generate a couple of arbitrary traps. Works great. 3) I go into TCM, pick a HiPerDSP card (selecting the LEDs on the span), and click "Fault->Trap Settings" and select "Trap Enables" 4) There, I set a few choice ones to "enableTrap". Specifically, "Red Alarm", "Loss of Signal", and "Physical State Change". Then I click "Set" and "Ok" to set it and exit. 5) Next, I click "Fault->Trap Destinations", and add an entry for the aforementioned linux box running snmptrapd. 6) I physically unplug the span from the HiPerDSP. Amazingly enough, the LEDS suddenly reflect a Red Alarm. (: 7) The amazement turns to disappointment when I see that my snmptrapd didn't hear anything. Due to my lack of real understanding of the trap destination configuration (umm, not the need for, you understand *grin*), I tried a few different things there. Even though snmptrapd appears to not give a whit about the community string, I tried three: nothing, junk, and the same as my NMC's community. And since I can't find anything in the docs that explains the "Annotation" entry, I also tried nothing, an integer '1', and an arbitrary string. I also verified that the linux box had a listener on the udp:snmp-trap port. All else failed, so it was time to consult the documentation. (: The docs basically told me to do all the stuff I did already. And, typical of docs, stopped short from answering the real question (like WTF is expected for "Annotation"). So, before I scrap the whole idea for now (being unwilling to go to the bother of sticking a hub in between the TC and the linux box so I can stick another packet-sniffin' box in there (a PIA that needs to be done because my LAN is point2point switched ethernet...useless to sniff from other segments)), I thought I'd ask here in case there was anything obvious that I'm leaving out (like maybe the NAC needs a reboot for the trap destination change to take effect or some other tripe). Or if I'm falling into some sort of a hidden, umm, trap. If anyone can slap me with a clue stick, I'd be grateful. (: - 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.