Thanks Donavan - was the answer - was having an extremely bad hair week in
Spectrum terms - server database hanging and then terminating and so on.
Anyway no excuse for not remembering varbind 101 - always look up the
translation od varbind integer to value.
Especially silly as I have done this stuff before and should know it...
Anyway once again thanks and thanks to all on the list.
and yes looking forward to upgrading to Spec 9.0 - just trying to work out how
painful its going to be in the sense of how it deals with largely updated SSDB
and customised CsVendor files, Oneclick XML, notifiers and so on
Quoting Donavan Pantke <[EMAIL PROTECTED]>:
> Jason Hebron wrote:
> > Hello
> >
> > Looking for a pointer or two on this
> >
> > The alarm for OSPF IF State Change - event 0x22003f
> > is a generic one that reports on state change of the OSPF
> >
> > An average message (event) has a payload similar to this
> > An ospfIfStateChange trap has been received for router <router ip
> address>.
> > The interface is <interface ip address>, and the new state is
> OTHER-DESIGNATED-
> > ROUTER
> >
> > Its configured to send a minor alarm
> >
> > I need to have it process so that in the event of the new state being
> DOWN it
> > sends a major alarm
> >
> > I looked at the contents of CsVendor/Ctron_SNMP_Rtr/eventdisp and it
> has a
> > statement that has me a bit confued - especially when I match it to
> the Alert
> > map
> >
> If you are trying to backtrack and figure out what event variable you
> want to check is,
> you're missing a critical step. Instead of jumping into the EventDisp
> directly, you need to examine the EvFormat file for the event. That is
> what contains the message that you are seeing in your event log.
>
> When I pull up the EvFormat for 0x22003f, I get:
>
> {d "%w- %d %m-, %Y - %T"} - An ospfIfStateChange trap has been received
> for router {O 1}. The int
> erface is {O 2}, and the new state is {T ospfIfState 3}. (event [{e}])
>
> So, you see here that there are 3 event variables passed into this
> event. The router and the interface are displayed as OID fields. The
> new
> state is actually an enumeration, thus Spectrum uses a table mapping to
> resolve the enumeration. So, in continuing the trace, I look at the
> EventTable file that's being referenced. Here's the contents of that:
>
> 0x00000001 DOWN
> 0x00000002 LOOPBACK
> 0x00000003 WAITING
> 0x00000004 POINT-TO-POINT
> 0x00000005 DESIGNATED-ROUTER
> 0x00000006 BACKUP-DESIGNATED-ROUTER
> 0x00000007 OTHER-DESIGNATED-ROUTER
>
> So what we find is that the real event variable is really an integer,
> which gets enumerated to a string by the table for human readability
> when formatting the event message.
>
> So, if you want to drop an EventRule on that event to have special
> treatment of the DOWN status, you should get something like this:
>
> 0x0022003f E 30 A 1,0x0022003f \ R Aprisma.EventCondition, "{VARDATA
> 3} == { I 1 }", "0xffff0701 -:-", "default", "0xffff0700"
>
> Notice that I'm comparing to the original integer field, and not to the
> string anymore.
>
> Conclusion:
>
> If you want to track down events to create rules against, and you're not
> familiar with the MIB that's generating them, start with the event code
> in the event log. Then find the EvFormat file that corresponds to the
> event and look at what event variables are being displayed. Then head
> into the EventDisp file to add your rules.
>
> BTW: This all is much, MUCH easier with Spectrum 9.0 and EC on Linux.
>
> Hope this helps!
> Donavan
>
>
>
>
>
> > Alert Map has the following
> >
> > # The OIDs listed here are for an Alert Handler. The real generated
> > # events/alarms are found by adding 0x10 to the the event codes
> below.
> > ......
> > ...
> >
> >
> > 1.3.6.1.2.1.14.16.2.6.16 0x22002f 1.3.6.1.2.1.14.1.1(1,0)\
> > 1.3.6.1.2.1.14.7.1.1(2,0)\
> > 1.3.6.1.2.1.14.7.1.2(0,0)\
> > 1.3.6.1.2.1.14.7.1.12(3,0)
> >
> > So reading the above I take it to mean the trap above's real generated
> event
> > is in fact 0x22003f
> >
> > the EventDisp has the following info relevant
> >
> > 0x0022002f E 30
> > ....
> > ..
> > # The 16 events that follow are controlled by the OSPF Trap
> Configuration View
> > # off of the OSPF2RtrApp and are generated by an Alert Handler.
> >
> > 0x0022003f E 30 A 1,0x0022003f
> >
> > So by reading that I work on the assumption that the original trap is
> > recevied, generates an event 0x0022002f then the Alert Handler dishes
> out the
> > 0x22003f event
> >
> > All good so far
> >
> > I want to then differentiate the message received so that the "DOWN"
> state
> > generates a different payload - a Major alert
> >
> > So looking at that I am working on using an event conditoin rule
> > # 0x0022003f E 30 A 1,0x0022003f \ R Aprisma.EventCondition,
> "{VARDATA
> > 3} == { S \"DOWN\" }", "0xffff0701 -:-", "default", "0xffff0700"
> >
> > Based on varbind 3 of the original trap, however I can;t seem to get
> this
> > working, mainly I think because the varbind is probably not passed on
> to the
> > new event
> >
> > So wondering if anyone has good tips on best way of differentiating
> based on
> > the new state
> >
> > I'm on Linux so no Watch editor or ECeditor or Spectrograph
> >
> > Any pointers appreciated
> >
> >
> >
> >
> > Jason Hebron
> >
> >
> > ---
> > To unsubscribe from spectrum, send email to [EMAIL PROTECTED] with the
> body: unsubscribe spectrum [EMAIL PROTECTED]
> >
>
>
> ---
> To unsubscribe from spectrum, send email to [EMAIL PROTECTED] with the
> body: unsubscribe spectrum [EMAIL PROTECTED]
>
Jason Hebron
---
To unsubscribe from spectrum, send email to [EMAIL PROTECTED] with the body:
unsubscribe spectrum [EMAIL PROTECTED]
