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]
