LMS2.6 - DFM alarm notification get's delayed

[ptrigueira]

Hi to all,

We have DFM configured to send trap notifications towards an external machine, and we see that sometimes the alarms that arrives to the external NMS are delayed. some o them are sent only days after it were received in CW .

Any clue ??... correlation issues maybe ?

Cheers,

Pedro

[Joe Clarke]

I would still need to see a nos.log with debug showing an example of this delay.

[ptrigueira]

HI JC,

Here you have. Yesterday 12/04/2007 we have delay issues during all afternoon because i was applying the "unmanageip.pl" script on two class C subnets that created outbound queueing (the "unresponsive" clear alarms ..)

[Joe Clarke]

There are a lot of events here. Please provide an example of one trap that was delayed so I can focus on that. I'm going through the first log, and so far I don't see any delays.

[ptrigueira]

Hi JC,

Please check you internal mailing list for DFM, you will see a post from Tarpley Adams, he's here with us at the costumer site, and he has better example...

Tks

P

[Joe Clarke · Accepted solution]

The attachment didn't come through, but I'm not sure how useful it would have been. It sounds like he sent a screenshot of a sniffer trace which isn't very helpful. We would need to see the binary sniffer trace file. In any event, I think I found an example in the log, and it looks like address resolution might be the culprit.

Basically, DFM takes the IP address that is configured and performs a lookup on the address. So, DFM tries to use the system resolver to resolve 192.168.168.134. This takes about three seconds to complete. The way Windows address resolution works can cause excessive delays when performing these kind of operations. As a workaround, try adding this address to DNS or your server's hosts file, and see if this problem improves.

[ptrigueira]

Hi JC,

It worked, now i see several traps being sento to notification server in the same second ...tks for your precious assistance.

Cheers,

Pedro