nv-l

RE: [nv-l] Authentication failure traps from Windows clients

2005-09-02 10:25:22
Subject: RE: [nv-l] Authentication failure traps from Windows clients
From: "Jon Austin" <AUSTINJ AT email.chop DOT edu>
To: <nv-l AT lists.us.ibm DOT com>
Date: Fri, 02 Sep 2005 10:23:04 -0400
I'm starting to get a little concerned here myself.

I'm getting ready in the next couple of months to set up an new
environment as a major upgrade.

Planning to use CIM agents to get my hardware traps from HP Gear.
I was planning to send them two places:  NetView and TEC
 -NetView for showing up on status maps, 
 -TEC for notificaitons/availability metrics. My plan at tec is to use
the HP Insight Manager for TEC kit, mainly for its adapter config, baroc
files, and rules. 

I can turn of Auth traps to start, but for due diligence, I figure at
some time in the future, we should get in there, find the offending
agents & push getting them fixed.

Anyone know if this is a problem inherent of the HP SIM agents or just
that they have to be re-configured over time? Maybe part of it is the
timing of when you install HP agents relative to when you set SNMP
configuration? 

Very interesting....... but not that much on a holiday weekend......





Jon Austin
Tivoli/Unix Administrator
Information Systems
Children's Hospital of Philadelphia
267-426-0433
austinj AT email.chop DOT edu

>>> dvanorder AT deloitte DOT com 9/2/2005 8:19 AM >>>
For grins have you unchecked the Send Authentication Trap box at each
agent? That will stop the agent from sending if NV is causing the
trouble during a poll. Otherwise it should just be a matter of
matching
the trap community string at the agent SNMP config versus trapd.conf
on
AIX. We tried the CIM for AIX plugin years ago as well. You gotta be
pulling your hair out with all the different variations/versions of
the
same trap. Hope you can get that HP SIM server so you only have to
deal
with updated MIBs in one place.

        -----Original Message-----
        From: owner-nv-l AT lists.us.ibm DOT com 
[mailto:owner-nv-l AT lists.us.ibm DOT com] On Behalf Of Glen Warn
        Sent: Wednesday, August 31, 2005 11:25 AM
        To: nv-l AT lists.us.ibm DOT com 
        Subject: RE: [nv-l] Authentication failure traps from Windows
clients
        
        
        No, we only send them to NV (no CIM server here)  We used to
have a ported version of CIM for NV AIX but they abandoned it and only
make a Solaris (I think) version now.  If I stop the Insight Agent
services - my auth failure traps stop!  I am still looking for a fix
to
this (nothing obvious appeared in my research yesterday)
         
        Glen Warn
        PEMCO Corporation Computer Services (PCCS)
        glen.warn AT pemcocorp DOT com 
        206-628-5770
         

________________________________

        From: owner-nv-l AT lists.us.ibm DOT com 
[mailto:owner-nv-l AT lists.us.ibm DOT com] On Behalf Of Van Order, Drew (US
-
Hermitage)
        Sent: Wednesday, August 31, 2005 7:30 AM
        To: nv-l AT lists.us.ibm DOT com 
        Subject: RE: [nv-l] Authentication failure traps from Windows
clients
        
        
        Your CIM agents send traps to NV as well as the HP SIM server?
If so you have my sincerest condolences! We thought about doing this
with our servers but HP changes MIBs more often than most and you
never
know which trap an agent is going to throw depending on the hardware
and
SSD version. Have you considered just having the SIM server forward
traps? We decided to use NetIQ AppManager to scrape CIM events from
the
event log, but I'm pretty sure you can forward traps. 

                -----Original Message-----
                From: owner-nv-l AT lists.us.ibm DOT com 
[mailto:owner-nv-l AT lists.us.ibm DOT com] On Behalf Of Glen Warn
                Sent: Tuesday, August 30, 2005 6:21 PM
                To: nv-l AT lists.us.ibm DOT com 
                Subject: RE: [nv-l] Authentication failure traps from
Windows clients
                
                
                Hi Drew,
                 
                I will definitely check into this but since I've sent
this message I've drawn closer (I think) to solving this issue.  As it
turns out, the boxes giving me grief all turned out to be HP/Compaq
Proliants - running various versions of Insight Manager Agents.  I am
trying to unlock the last missing piece of this puzzle by reading up
on
Insight Mgr.  In the short term, I can either stop the services (not
desirable) or temporarily disable the Auth Failure trap until I can ID
the issue (the path I'm taking)  Fortunately, it's less than 50
servers.
                 
                If anyone else has any ideas along these line, they'd
be
greatly appreciated.
                 
                Glen Warn
                PEMCO Corporation Computer Services (PCCS)
                glen.warn AT pemcocorp DOT com 
                206-628-5770
                 

________________________________

                From: owner-nv-l AT lists.us.ibm DOT com 
[mailto:owner-nv-l AT lists.us.ibm DOT com] On Behalf Of Van Order, Drew (US
-
Hermitage)
                Sent: Tuesday, August 30, 2005 1:04 PM
                To: nv-l AT lists.us.ibm DOT com 
                Subject: RE: [nv-l] Authentication failure traps from
Windows clients
                
                
                
                I just finished cleaning something like this up last
week. Your Windows servers are sending traps to the NV box and
something's not matching so NV is creating authentication traps.
You'll
be able to poll fine because that's not the issue. Is the NV server
trapping itself? In our case it was internal to the NV box and the NV
server was trapping itself every 5 seconds. There was a mismatch
between
snmpd.conf and snmpd.peers. 
                 
                 

                        -----Original Message-----
                        From: owner-nv-l AT lists.us.ibm DOT com 
[mailto:owner-nv-l AT lists.us.ibm DOT com] On Behalf Of Glen Warn
                        Sent: Tuesday, August 30, 2005 1:40 PM
                        To: nv-l AT lists.us.ibm DOT com 
                        Subject: [nv-l] Authentication failure traps
from Windows clients
                        
                        
                        Running 7.1.4 FP3 on Redhat AS2.1
                        I am being bombarded with auth failure traps
from some of my Windows 200x servers  (not even a majority).  Odd part
is I can do a demand poll and run a sniffer trace at the same time.  I
see the poll run successfully (using the appropriate RO community
string) then the same server issue an auth failure trap back to
Netview
(I have all my servers set to do this so I can detect rogue queries)
None of my traces reveal any other boxes trying to run queries (what I
had assumed in the beginning)
                         
                        
                        I think this has been happening for a long time
(all along?) but just became aware of a big problem because I
accidentally hidden from myself thru event configuration (setting to
"Don't display or Log") that I used a long time ago to debug something
but never reverted. 
                         
                        Any ideas?  I have tried changing the comm
strings to something basic, put in a host specific snmp config, etc.
The devices are scattered across 5 different companies and dozens of
subnets.
                         
                        In the mean time, I believe this flood of traps
is severely hampering Netviews ability to process other traps (because
there are so many coming in non-stop)
                         
                        Glen Warn
                        PEMCO Corporation Computer Services (PCCS)
                        glen.warn AT pemcocorp DOT com 
                        206-628-5770
                         



                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. [v.E.1]
                


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