RE: [nv-l] 7.1.4 Is the hang in nvtecia or ruleset?

["Van Order, Drew \(US - Hermitage\)" <dvanorder@deloitte.com>]

Hope you're out there James--

 

I find myself stuck in the middle between what you have stated and what the current support engineer is telling me. I honestly think what you are telling me is more accurate, i.e. there is an issue with EEIF and nvserverd that this efix resolves, even though the abstract for the efix states it only enables NV by default sending severity info to TEC via tecint.conf changes. I've asked support for clarification but figure I can get an answer faster here.

 

I understand completely if you are uncomfortable commenting on the current situation; my concern is putting in a pretty big change (if NV severities are not set and ready to go for ALL traps feeding TEC_ITS you are in for a surprise as it turns that on and baroc severity slots are ignored. The abstract does not state that if you don't tweak tecint.conf immediately events will not make it through TEC) that doesn't address the core issue of events hanging up in the interface.

 

Thank you!--Drew

-----Original Message-----
From: owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com] On Behalf Of James Shanks
Sent: Monday, August 30, 2004 7:40 AM
To: nv-l@lists.us.ibm.com
Subject: Re: [nv-l] 7.1.4 Is the hang in nvtecia or ruleset?

Drew,

Do you have any post-FixPack1 maintenance applied?  There was a serious problem with the TEC EEIF library uncovered in Verification after 7.1.4  FixPack1 went out the door.  It had a memory leak which caused it to hang after some extended period of time.  TEC has since fixed the problem.  Every post-7.1.4 FP01 test fix which shipped nvserverd, and there were several, has the new  TEC EEIF library linked in.  If you haven't applied anything yet, I would just download the latest and greatest, IY60528, and install that until FP02 is available at the end of the quarter.

Also, I would stay away from using the nvtecia command for the time being, and just use ovstop/ovstart for nvserverd (Sorry).  The command "nvtecia -stop" seems to  work OK, but "nvtecia -reload" is hanging or failing to complete on most platforms.  There seems to be a re-initialization problem with State Correlation Engine after you stop it, but don't destroy the process.  I have some TEC guys looking at that now, so stay tuned.

HTH

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

"Van Order, Drew \(US - Hermitage\)" <dvanorder@deloitte.com>
Sent by: owner-nv-l@lists.us.ibm.com

08/29/2004 09:34 AM

Please respond to
nv-l

To	<nv-l@lists.us.ibm.com>
cc
Subject	[nv-l] 7.1.4 Is the hang in nvtecia or ruleset?

Hi all,
 
I'm back with another NV to TEC integration question/problem. Everything is centered around TEC in our organization; everything we tell NV to act upon is designed to generate a TEC event. We are seeing intermittent delays in receiving TEC events through our TEC_ITS ruleset. Sometimes it will resolve itself within an hour, other times a full daemon cycle is needed, and NV is fine afterwards. The ruleset in use is the core TEC_ITS ruleset provided with 7.1.4 and we have added 8 trap settings nodes to generate events from our routers/switches/eventually Compaq Insight Agents. We have no timer or decision making nodes, it's very basic.
 
The issue appears to be in ruleset processing or TEC forwarding. I say this because when you ovstop/ovstart, events from the ruleset suddenly appear at TEC. There are no trap storms occurring when these delays hit. We are getting ready to manage considerably more devices and will have to add even more trap nodes to TEC_ITS.rls, so we've got to get a handle on why this is occurring. Any troubleshooting ideas or places where we may have a configuration problem?
 
Thanks much--Drew
 
 

This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited.

This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited.