I would say that it depends. Do you want your trap displayed in the NetView
events window as well as being handled by CA? If so, then you will want to
send to the NetView host and have it in turn forward to Unicenter. If the
display of your special trap in the events window is not necessary it would
be more efficient to send it directly to Unicenter.
Assuming you want to display in the events window AND send to CA, as an
alternative you could issue snmptrap twice - once to send the trap to
NetView and again to send the trap to CA - no forwarding by NetView
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: Wednesday, December 01, 1999 10:33 AM
> To: NV-L@UCSBVM.ucsb.edu
> Subject: Re: Forwarding events to CA-Unicenter
>
> Blaine/James,
> Thanks for the input. When issuing the snmptrap, would you send the trap
> directly to the Unicenter node? Or would you send the trap to the Netview
> node itself and have trapd set to forward that trap to the Unicenter node?
> Gib.
>
>
> -----Original Message-----
> From: James Shanks [mailto:James_Shanks@TIVOLI.COM]
> Sent: Wednesday, December 01, 1999 9:00 AM
> To: NV-L@UCSBVM.UCSB.EDU
> Subject: Re: Forwarding events to CA-Unicenter
>
> 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
|