nv-l
[Top] [All Lists]

Re: Forwarding events to CA-Unicenter

To: nv-l@lists.tivoli.com
Subject: Re: Forwarding events to CA-Unicenter
From: "Fendrick, Gib (CC-MIS)" <Gib.Fendrick@CONAGRA.COM>
Date: Wed, 1 Dec 1999 09:32:47 -0600
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


<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web