nv-l
[Top] [All Lists]

Re: Netmon Hanging and Demand Poll Hanging

To: nv-l@lists.tivoli.com
Subject: Re: Netmon Hanging and Demand Poll Hanging
From: James Shanks <James_Shanks@TIVOLI.COM>
Date: Wed, 7 Apr 1999 11:17:24 -0400
Reply-to: Discussion of IBM NetView and POLYCENTER Manager on NetView <NV-L@UCSBVM.UCSB.EDU>
Sender: Discussion of IBM NetView and POLYCENTER Manager on NetView <NV-L@UCSBVM.UCSB.EDU>
Jan -

I am no longer able to follow the thread of your problem.  Most of what you
are telling me is standard processing and has been since V4 when rulesets
were introduced.  I thought you said you had a netmon / demandpoll problem
and there is a fix package for that, so I advised you to get it or to get
5.1.1.  I am puzzled about what else is left to discuss until you get more
current maintenance as there is nothing else I can add which will solve or
alleviate that problem.  But to comment on what you said --

Demand polls result in traps, and these are processed by nvcorrd when there
are any rulesets running.  That is as it should be.  But the traps are
issued "after the fact" and don't affect the demandpoll process.  netmon
receives traps from trapd directly, not from nvcorrd, so whether you run
rulesets or not has no bearing on demandpoll.

Some processes, such as the event command, involve that process
establishing a socket connection to trapd, sending the trap over that
socket (so it does not go out over the network), and then disconnecting.
This is why, for example, if you type in      event -h test1
you will see three traps:  (1) application connecting, (2) Node Up for
test1, and (3) application disconnecting.  These are all processed by
nvcorrd when a ruleset is running.  This is also as it should be.

I haven't tried it, but changing forwardall.rs from an initial node of PASS
to BLOCK, seems self-defeating.  I wouldn't think it forward any traps
after that, since they would all be blocked.  In any case, it has no
bearing on demandpoll or netmon.

NetView 5.1.1 also has maintenance to improve the throughput of traps
through trapd, a process that was begun in NetView V5.1 to help satisfy the
demands of large customers.  Ultimately, that is the level of code you
need.

Hope this helps

James Shanks
Tivoli (NetView for UNIX) L3 Support



Jan Green <greenjan@YAHOO.COM> on 04/07/99 10:47:18 AM

Please respond to Discussion of IBM NetView and POLYCENTER Manager on
      NetView <NV-L@UCSBVM.UCSB.EDU>

To:   NV-L@UCSBVM.UCSB.EDU
cc:    (bcc: James Shanks)
Subject:  Re: Netmon Hanging and Demand Poll Hanging





Sorry about the duplicate message, this is my first
time.


James -


I have noticed that when one trap is sent is it
forwarded through my rulesets in 1 second.

However, when I send multiple traps. They hang while
processing by nvcorrd. I think this may be my problem.
They are the same rulesets that worked fine in 5.0.

I have noticed these differences.

1) Demand Polls are sent through the rulesets
2) Each time a trap is received two entries are logged
in the trapd.log ** "A netmon-related application
disconnected from trapd" then immediately "A
netmon-related application has connected to trapd".
Both of these traps are sent through the rulesets.

I have set my forwardall.rs to block not pass.

Is this fixed in the 5.1.1 patch or the "efix"?

Thanks Again!!


jan








--- James Shanks <James_Shanks@TIVOLI.COM> wrote:
> Three issues:
>
> (1) There were several problems with demand poll and
> netmon in 5.1 which
> were fixed in 5.1.1.  But they were so severe and
> annoying that an "efix"
> package was assembled for 5.1 customers, so they
> would not have to wait so
> long for relief.  If you want/need that package,
> please call Support
> (1-800-Tivoli-8 or whatever number you have used in
> the past) and ask for
> it.
>
> (2) Tivoli customers who have a current maintenance
> contract will be
> autoshipped 5.1.1.  But if you cannot wait, then
> call the Support number
> and ask them for help; or you can send a note to
> swdist@tivoli.com saying
> you want NetView 5.1.1 for UNIX or NT, and include
> the usual information:
> company name, customer number (preferably, a Tivoli
> cust# which starts with
> a T, but IBM cust# can work), mailing address,
> contact name (that's you
> presumably), and contact (your) telephone number.
>
> (3) trapd does not write an event to the log until
> the next event arrives,
> so your experience with the trapd.log is entirely
> normal
>
>
> James Shanks
> Tivoli (NetView for UNIX) L3 Support
>
>
>
> Jan Green <greenjan@YAHOO.COM> on 04/07/99 09:26:48
> AM
>
> Please respond to Discussion of IBM NetView and
> POLYCENTER Manager on
>       NetView <NV-L@UCSBVM.UCSB.EDU>
>
> To:   NV-L@UCSBVM.UCSB.EDU
> cc:    (bcc: James Shanks)
> Subject:  Netmon Hanging and Demand Poll Hanging
>
>
>
>
>
> Please Help!
>
> I am running Netview 5.1(I do not have the patch
> 5.1.1
> yet). We just upgraded the system. Since, have been
> having problems with netmon hanging and demand poll
> hanging.
>
> I forced a trap through my rulesets and logged it
> using the nvcdebug -d all command. It is finishing
> in
> about 1 second.
>
> When a node down comes through it is processed right
> away, no problem. Demand poll is working as well.
>
> However, when a node down/node up pair comes into
> trapd.log it takes 20-30 minutes to arrive in the
> ovevent.log. When many traps come in the problem is
> multiplied. At peak times I have seen the delay
> 10-12
> hours. During this time, demand poll is hanging.
>
> This has only started happening since the upgrade.
> It
> appears to be a netmon problem. Does anyone know
> what
> may be causing this? And is there a patch?
>
>
______________________________________________________
>
> This may or may not be related:
> I have noticed that trapd.log is always one trap
> behind. Almost like it holds one trap in a buffer
> until another comes in. Then the first trap in the
> buffer is displayed and the new one is held. Both
> show
> up in the ovevent.log though.
>
> For example; I send an event command at 11:15:00.
> The
> event shows up in the event log but not in
> trapd.log.
> Then I force another node up at 11:20:00. The second
> one shows up in the event log and the first shows up
> in trapd.log with the timestamp of 11:15:00. It is
> always one behind.
>
> I know this is confusing: I am out of ideas.
> Thanks for any ideas.
>
> Jan
>
>
>
_________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at
> http://mail.yahoo.com
>

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

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

Archive operated by Skills 1st Ltd

See also: The NetView Web