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(a)moonstar.com> on 01/06/2000 09:19:15 AM
Please respond to usr-tc(a)lists.xmission.com
Sent by: "Lon R. Stockton, Jr." <lon(a)moonstar.com>
To: usr-tc(a)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(a)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(a)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.
