--0__=BOkRIWgf4EchNdM3J30cJWl4t6M7rBysZ5ABG2wFiOjFpSHKnLDhntct
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Perhaps you should open a problem to Support -
>> additionally, every manual "demand poll" or "ping" causes netmon to generate
these events.
The code which did this in 5.1.2 was removed in 6.0 (and 5.1.3) I have verified
that.
So I don't see how this could be. I no longer have a 6.0 vanilla system to try
it on, but it certainly is not the case that every demand poll or ping to an
already Up interface causes a new Interface Up, nor will a demand poll of a
down one cause a new unnecessary down trap.
I haven't investigated the MLM issue with 6.0, but that was fixed for 5.1.3 as
well I am told, so if you are at 5.1.2, put the new one on.
James Shanks
Tivoli (NetView for UNIX and NT) L3 Support
FITZINGER Richard <richard.fitzinger@it-austria.com> on 05/10/2000 10:09:14 AM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
To: "'IBM NetView Discussion'" <nv-l@tkg.com>
cc: (bcc: James Shanks/Tivoli Systems)
Subject: AW: [NV-L] MLM floods NetView with interface up traps
we notice the same with Netview/AIX 6.0 and MLM 5.1.3. additionally, every
manual "demand poll" or "ping" causes netmon to generate these events.
will there be a change (back to good) from this behaviour? I can't tell our
network operators the use of "interface-up" without any "downs" before. and:
setting the traps to "don't log or display" will not prevent netview from
processing the trap flood.
regards, richard
-----Urspr
--0__=BOkRIWgf4EchNdM3J30cJWl4t6M7rBysZ5ABG2wFiOjFpSHKnLDhntct
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-transfer-encoding: quoted-printable
=FCngliche Nachricht-----
Von: Joel A. Gerber [mailto:joel.gerber@USAA.COM]
Gesendet: Montag, 8. Mai 2000 17:55
An: 'IBM NetView Discussion'
Betreff: RE: [NV-L] MLM floods NetView with interface up traps
I'm not sure if this is the same thing that Peter's referring to, but w=
e
noticed a change in the trap behavior after installing the 5.1.2 patch.=
The
netmon Interface Up traps are now generated and displayed in the Event =
Log
for EVERY MLM trap, instead of only when netmon detects a change in sta=
tus.
The traps from MLM are still Log Only, but the netmon traps do cause a
"flood". This happens not only when an MLM first initializes, but also=
whenever netmon "invalidates" the status polling table, and the MLM
re-initializes.
Joel Gerber - I/T Networking Professional - USAA Information Technology=
Co.
- San Antonio, TX
* (210)456-4231 * mailto:Joel.Gerber@USAA.com "
http://www.usaa.com
-----Original Message-----
From: James_Shanks@tivoli.com [SMTP:James_Shanks@tivoli.com]
Sent: Friday, May 05, 2000 15:56
To: IBM NetView Discussion
Subject: Re: [NV-L] MLM floods NetView with interface up traps
I must still be confused, or perhaps I don't understand your setup.
The question I have is "suppress them from where?". The event displa=
y?
Technically speaking NetView cannot suppress traps, only prevent them f=
rom
being
displayed or logged. They will still be processed. Any traps sent to=
NetView
will still be pulled in by trapd (he has no choice) and then sent to al=
l
connected applications, including netmon, snmpCollect, ipmap, and so on=
.
You
cannot do anything about that. And they will still all be in trapd.lo=
g.
By
default MLM status traps are all "Log Only" anyway, or so I thought, so=
they
do
not normally go to the event display. Did you change that? If so, the=
n you
could use a ruleset or a filter to suppress them, but as these are the =
same
traps that will be sent later, you would have to apply the filter/rules=
et
only
when you knew the MLMs were going to be rebooted, else they would alway=
s be
filtered.
So unless I miss my guess, you should just make them "Log Only" again i=
f
they
are not. netmon gets them from trapd and "re-issues" them as netmon tr=
aps
if
required, and those are what you should see in the event display.
Or am I still missing something?
James Shanks
Tivoli (NetView for UNIX and NT) L3 Support
Peter Cho <chop@tdbank.ca> on 05/05/2000 04:33:23 PM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
To: IBM NetView Discussion <nv-l@tkg.com>
cc: (bcc: James Shanks/Tivoli Systems)
Subject: Re: [NV-L] MLM floods NetView with interface up traps
MLMs are not booted at the same time.
The problem with MLM is that it sends interface up traps for everything=
it has in it's collection the first time it comes up. This is the part=
I
was
asking about. I wanted a way to suppress the flood of traps, just for
the MLM startup.
James_Shanks@tivoli.com wrote:
> As far as I know, what you are describing is normal behavior. When a=
n MLM
is
> rebooted, it starts from ground zero and sends status traps on all th=
e
nodes
it
> monitors to NetView. That's what it is supposed to do. It doesn't h=
ave a
> topology database like netmon does to store this information in, so i=
t
sends a
> level-set to netmon. It has no idea what happened to the nodes it mo=
nitor
when
> it is down, whether netmon was able to take over the polling successf=
ully
or
> not, so it has to start somewhere. Are you rebooting all your MLMs a=
t
once or
> something? If not, then the question becomes, why have MLMs monitor
status in
> the first place if you don't want them to send the traps?
>
> James Shanks
> Tivoli (NetView for UNIX and NT) L3 Support
>
> Peter Cho <chop@tdbank.ca> on 05/05/2000 02:03:12 PM
>
> Please respond to IBM NetView Discussion <nv-l@tkg.com>
>
> To: IBM NetView Discussion <nv-l@tkg.com>
> cc: (bcc: James Shanks/Tivoli Systems)
> Subject: [NV-L] MLM floods NetView with interface up traps
>
> Hello,
>
> Using NT MLMs with AIX NetView 5.12. When our MLM's are
> rebooted, it floods NetView with hundreds of interface up traps.
>
> Don't want to filter the trap as our network people want to see it.
> Does anyone have a work around? Is there a ruleset to handle this?
>
> Thanks,
>
> Peter
>
> _____________________________________________________________________=
____
>
> NV-L List information (unsubscribing, policies, posting, digest versi=
on,
> searchable archives): http://www.tkg.com/nv-l
>
> _____________________________________________________________________=
____
>
> NV-L List information (unsubscribing, policies, posting, digest versi=
on,
> searchable archives): http://www.tkg.com/nv-l
_______________________________________________________________________=
__
NV-L List information (unsubscribing, policies, posting, digest version=
,
searchable archives): http://www.tkg.com/nv-l
_______________________________________________________________________=
__
NV-L List information (unsubscribing, policies, posting, digest version=
,
searchable archives): http://www.tkg.com/nv-l
_______________________________________________________________________=
__
NV-L List information (unsubscribing, policies, posting, digest version=
,
searchable archives): http://www.tkg.com/nv-l
_______________________________________________________________________=
__
NV-L List information (unsubscribing, policies, posting, digest version=
,
searchable archives): http://www.tkg.com/nv-l
_______________________________________________________________________=
__
NV-L List information (unsubscribing, policies, posting, digest version=
,
searchable archives): http://www.tkg.com/nv-l
=
--0__=BOkRIWgf4EchNdM3J30cJWl4t6M7rBysZ5ABG2wFiOjFpSHKnLDhntct--
|