nv-l

RE: [nv-l] Cursed Cisco Trap Formats

2002-10-03 17:59:13
Subject: RE: [nv-l] Cursed Cisco Trap Formats
From: "Allison, Jason (JALLISON)" <JALLISON AT arinc DOT com>
To: "'nv-l'" <nv-l AT lists.tivoli DOT com>
Date: Thu, 3 Oct 2002 17:59:13 -0400
I am getting ready to leave for the day and wont be back till Monday, but I
wanted to tell you what -I- would love to do.  As funny as it sounds, I
would like for our AOC to have complaints like this, it keeps things
interesting.

1. Configure trapd.conf for 'Log Only' for your Cisco Specific Link Up/Down
Traps

This is just a basic example:

-- Begin pseudo (copied/pasted) code here!! --
// Example of filter, you will need to determine applicable ID's
// for your Cisco Link Up/Down Traps.  The format of it is a little
confusing,
// but when you get the hang of it, its easy.
char filter[] =
  "SNMP_SPECIFIC=58916865 || SNMP_SPECIFIC=58916864 ||
SNMP_SPECIFIC=58916866 || SNMP_SPECIFIC=58916867 ||
CLASS=1.3.6.1.4.1.36.2.15.11.12.1";

void main ()
{

  char hostname[MAXHOSTNAMELEN];
  OVsnmpSession  *trapSession;
  OVsnmpVarBind  *var_ptr;
  OVsnmpPdu      *readPdu;
    
  /* Open Session */
  trapSession = nvSnmpTrapOpenFilter(NULL,
                                     NULL,
                                     filter);    /* callback data */

  if (trapSession == NULL)
  {
    exit(1);
  }
    
  num_snmp_fds = trapSession->sock_fd + 1;
  FD_ZERO(&read_fds);
        
  for ( ; ; )
  {
    /* Turn the sock_fd bit on for read_fds */
    FD_SET(trapSession->sock_fd, &read_fds);
        
    count = select(num_snmp_fds,
                   (int *) read_fds.fds_bits,
                   NULL,
                   NULL,
                   NULL);
                       
    if (count < 0)
    {
      printf("Error in select call.\n");           
      OVsnmpClose(trapSession);
      exit(errno);
    }
    else
    {
      readPdu = OVsnmpRecv(trapSession);

// Fun begins here
// Look in /usr/OV/include/OV/OVsnmpApi.h, you will find the definition of
the
// OVsnmpPdu.  You can access the PDU data, specifically the 'variables'
list
// and you have all of the data you need to manipulate it as you see fit.

// Next (which I dont have snippets for), initialize a PDU with the
information
// you care about and send it to yourself using
status = OVsnmpSend(newSnmpSession, newPDU);
// If you wanted to be boring, you could just make a system call and use one
// of the built in trap/event senders.  Either way, you get to specify the
// information displayed in the events window.
-- End pseudo code here!! --

Now, a lot of people look down on the API, but I find it very robust and
useful.  I cant begin to explain the things I have done to some of our
legacy systems here to 'tweak' Netview for our operators.

Examples can be found in "/usr/OV/prg_samples".

Best of luck,

Jason Allison
Principal Engineer
ARINC Incorporated
Office:  (410) 266-2006
FAX:  (410) 573-3026


-----Original Message-----
From: James Shanks [mailto:jshanks AT us.ibm DOT com]
Sent: Thursday, October 03, 2002 4:11 PM
To: Barr, Scott
Cc: nv-l AT lists.tivoli DOT com
Subject: RE: [nv-l] Cursed Cisco Trap Formats


I'm a bit confused here.  The error message about variables accessed is 
from trapd and only affects the way the trap is shown in the trapd.log and 
the event window.  The PDU structure passed to the ruleset should be 
unaffected.  As has been noted, you can get around the error  by using $* 
to display all the variables or by making multiple copies of the trap with 
slightly different names and specifying a host list for which nodes each 
definition applies to.

As for the rulesets, there was a new variable introduced called 
$NVATTR_COUNT  which may help, but I don't remember what release it was 
introduced in, but it is available to scripts launched from an action 
node. It counts what is passed in.  Note that when you use this in an 
action node, it will be three variables higher than what was sent in the 
original trap, because nvcorrd adds on three more elements from 
trapd.conf, when the action node is called, so that you can reference them 
as environment variables.  In order they are
(1) event category ( 0= "Threshold Events", 3= "Status events", etc. see 
the man page on trapd.conf)
(2) event source-id  (A=agent, N=netmon, etc. see the man page on 
trapd.conf)
(3) event severity  (0=cleared, 1=indeterminate, 2=warning, 3=minor, 
4=critical, 5==major) 

Does this help?

James Shanks
Level 3 Support  for Tivoli NetView for UNIX and NT
Tivoli Software / IBM Software Group




"Barr, Scott" <Scott_Barr AT csgsystems DOT com>
10/03/2002 03:15 PM

 
        To:     <nv-l AT lists.tivoli DOT com>
        cc: 
        Subject:        RE: [nv-l] Cursed Cisco Trap Formats

 

Once again GREAT idea. However see my original post

We do NOT used command for automatic action we use rulesets. In an action 
node I can call the script (which I do) but the trap data is not passed as 
command line arguments, it exists as environment variables and I have no 
way to know how many environment variables exist.

I'm not adverse to scripting. I have already tackled a number of other 
issues this way - the problem I have is determining how many variables are 
the trap environment data when I call my script to handle the variable 
format trap.


> -----Original Message-----
> From: Todd H. [mailto:netview AT toddh DOT net]
> Sent: Thursday, October 03, 2002 1:59 PM
> To: Barr, Scott
> Cc: nv-l AT lists.tivoli DOT com
> Subject: Re: [nv-l] Cursed Cisco Trap Formats
> 
> 
> 
> "Barr, Scott" <Scott_Barr AT csgsystems DOT com> writes:
> > 
> > So, let me go back to my original request - how can I handle this
> > with automation?
> 
> Use $* in the trap format for that OID/generic/specific that comes in.
> That'll shut trapd up and let it gracefully deal with the variability.
> 
> Then script a command (using ksh, Perl, or even C if ya like) for
> automatic action that handles 3 4 or 5 varbinds appropriately as you
> wish.  Send an event to TEC then with postemsg. 
> 
> The scripting is left as an (albeit fairly straightfoward) exercise to
> the user.   You have a situation that requires some customization via
> scripting, and I'm afraid no one can shield you from having to do that
> scripting. 
> 
> Best Regards,
> -- 
> Todd H.
> http://www.toddh.net/
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe AT lists.tivoli DOT com
For additional commands, e-mail: nv-l-help AT lists.tivoli DOT com

*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)





---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe AT lists.tivoli DOT com
For additional commands, e-mail: nv-l-help AT lists.tivoli DOT com

*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)