Blaine is right.
You cannot modify the original traps, but you can issue snmptrap in a script in
an Action node in the ruleset to send a trap of your own devising, which has all
the mods you want, and have this trap set to forward from trapd. Or you could
do that same thing from automatic actions in trapd.conf as well, but from a
ruleset you have more control over correlation.
The reason that your rulesets have no effect on the forwarding of existing
traps is because it is trapd which is doing the forwarding, not nvcorrd, who
runs the ruleset. Trapd gets the trap and passes it on to all connected
receivers (nvcorrd is one) and then forwards the trap to another box or port, if
that is set up. Perhaps you were confused by the Forward Node in the ruleset
editor? That is a forward in the sense of "pass on to the next process" and in
this case, the next process is nvserverd, which controls what goes to the event
windows and to TEC, because "forward" in the sense of "pass the raw trap along
to another trap receiver" has already happened (as you found out).
Here's an snmptrap example to get you started:
#!/bin/ksh
# idwn.trap.sh
#
#
# sample shell script James Shanks 11/05/96 to send snmptrap
#
# we are not sending community name nor port (it defaults to 'public' and 162
udp)
# the first hostname is the trapd destination
# the second hostname is the agent sending the trap -- it cannot be bogus
# because it mut be translated into an IP address
# the contents of the 4th variable in real life are :
# Interface address -- timestamp -- object id of host -- object id of interface
#
/usr/OV/bin/snmptrap \
'racecar.raleigh.ibm.com' .1.3.6.1.4.1.2.6.3.1 \
'jshanks.raeligh.ibm.com' 6 58916867 1 \
.1.3.6.1.4.1.2.6.3.1.1.2.0 Integer 2 \
.1.3.6.1.4.1.2.6.3.1.1.3.0 OctetStringascii "racecar.raleigh.ibm.com" \
.1.3.6.1.4.1.2.6.3.1.1.4.0 OctetStringascii "Interface 123.456.789.01 down" \
.1.3.6.1.4.1.2.6.3.1.1.5.0 OctetStringascii "123.456.789.01 12345 2560 2559" \
.1.3.6.1.4.1.2.6.3.1.1.6.0 OctetStringascii "openview"
You can use this as a model to send whatever you like. And the object
identifiers preceeding the variables need not be real ones. Instead of
".1.3.6.1.4.1.2.6.3.1.1.2.0" I could have just used "1.2" , and then "1.3" and
so on. snmptrap doesn't care, it just requires that sort of format.
Good luck
James Shanks
Tivoli (NetView for UNIX) L3 Support
"Owens, Blaine C" <bowens@EASTMAN.COM> on 12/01/99 08:21:25 AM
Please respond to Discussion of IBM NetView and POLYCENTER Manager on NetView
<NV-L@UCSBVM.UCSB.EDU>
To: NV-L@UCSBVM.UCSB.EDU
cc: (bcc: James Shanks/Tivoli Systems)
Subject: Re: Forwarding events to CA-Unicenter
Gib, one suggestion. Instead of forwarding the native "untested" traps have
your automation generate a seperate "private" trap of your own invention
for failures only and forward this trap to CA. I do something along the same
lines using automatic actions and scripting.
Blaine Owens
Eastman Chemical Company
Phone - (423)-229-3579
Fax - (423)-229-1188
bowens@eastman.com
> -----Original Message-----
> From: Fendrick, Gib (CC-MIS) [SMTP:Gib.Fendrick@CONAGRA.COM]
> Sent: Tuesday, November 30, 1999 6:16 PM
> To: NV-L@UCSBVM.ucsb.edu
> Subject: Forwarding events to CA-Unicenter
>
> Environment is Netview/AIX 5.1.1
>
> My question: Is anyone using NetView/AIX rules and correlation to process
> network event and traps, and subsequently forwarding specific traps to
> CA-Unicenter?
>
> We use Netview to monitor the network, and use CA-Unicenter as our focal
> point for enterprise events. Unicenter is to correlate events from
> Netview,
> BMC Patrol, and other platform managers and does the paging, sends e-mail,
> and opens problem tickets. To Initially get started using Unicenter
> sending out network event pages, we set up the trapd configuration option
> in
> Netview to forward specific traps to our Unicenter host. Then in NetView,
> Options--> Event Configuration-->Trap Customization: SNMP... we
> configured
> specific traps/events for be forwarded. We forwarded events like NetView
> interface up/down and some selected Cisco traps. Now we want to get more
> sophisticated in our process, and establish some rules and correlation in
> NetView so we can forward one event to Unicenter rather than multiple, or
> don't forward any event if a device responds on the next Netview poll
> cycle.
>
> From my reading and experimenting, forward traps the way we currently do,
> it
> looks like the trap gets forwarded before nvcorrd rules are invoked. Thus
> we have no way to apply rules or correlation before the event is forwarded
> to Unicenter. Plus we would like to modify events to tell Unicenter the
> severity level of the problem, so it can either page or just send an
> e-mail
> to support. We are now looking at alternate ways to accomplish this. Any
> suggestions?
>
> Thanks,
> Gib Fendrick
|