Bill,
The node came back up on the network, so this ended my conundrum for
now.  I removed and re-added the node to netview and restarted netmon.
I never found the device in trap.log.  Thanks for your feedback.
Eric

-----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 Stringfellow, William
Sent: Wednesday, May 18, 2005 6:03 PM
To: nv-l AT lists.us.ibm DOT com
Subject: RE: [nv-l] Failed ping stays green


Eric,
        I have seen cases where our primary and backup servers showed
opposite status for a given device.  But they were caused by a short
term failure that was caught by one server but not the other because of
the polling cycles being out of sync.  And they got back into agreement
on the next cycle.  Paul's idea to look for when the next poll will
occur is good so you can verify that the server has had the chance to
test the node/interface with it's own internal idea of what the object
looks like.  The fact that the node status is Normal/Up in the database
is consistent with the display.  With that condition in the database,
there would not be any other color than green displayed on the map.
         Yet you say that a manual ping fails on the box that has the
Normal/Up condition and green map color.  I would verify that the IP
address you are manually pinging agrees with the data for the specific
device in the NetView database.  Name resolution to IP address giving
you the expected results?  grep or search for the device name AND
address in the trap log and see if netmon has reported anything about
the device.  There has to be a reason unless magic is at work!

                Good luck,
                Bill

-----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 Paul
Sent: Wednesday, May 18, 2005 11:00 AM
To: nv-l AT lists.us.ibm DOT com
Subject: Re: [nv-l] Failed ping stays green

Eric,
Running a "netmon -a 12" will dump the ping status list into the
netmon.trace. This should show you the next time this device will be
polled, it will show you something like this:

---------- pingList [0x82ba2b0] ----------
** 94 elements on the IF list **
  3: 10.22.33.44 (test123) list = 0x82ba2b0

That shows 3 seconds until that interface will be polled.

Also, the ICMP vs SNMP, NetView will sometimes make that decision for
you. If the device has a unnumbered serial interface it should be being
polled via SNMP. You can check for sure by running an "ovtopodump
<selection name>" then looking for SNMP STATUS POLL and if it is MAXIMUM
TIME, then the device is being polled via ICMP. You can also look to see
when the last poll was by looking at the LAST SUCCESSFUL POLL in the
interfaces portion of the ovotpodump command.

Other then that, you would have to trace netmon to see what it is doing.

Paul


Zoeckler, Eric A. wrote:

>Paul,
>Thanks for your reply.  I'm not doing any snmp status polling, and the
>status of the object is Normal/Up.
>Eric
>
>-----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 Paul
>Sent: Wednesday, May 18, 2005 11:13 AM
>To: nv-l AT lists.us.ibm DOT com
>Subject: Re: [nv-l] Failed ping stays green
>
>
>Sounds like it might be being polled via SNMP instead of ICMP. Also,
>you can check the object properties to make sure the object is not in 
>Critical status and just incorrectly reprensented on the map....
>
>Paul
>
>
>Zoeckler, Eric A. wrote:
>
>  
>
>>NV 7.1.4 on AIX 5.2
>>
>>What would cause the map node to stay green when ping fails?
>>
>>Background:
>>On backup netview box node goes down.  On primary box node is up.
>>When
>>    
>>
>
>  
>
>>I do a manual ping from the primary box the ping fails, but the node
>>stays green.  IP address is the same on both boxes.
>>
>>Thank you,
>>Eric
>>
>>---------------------------------
>>Eric Zoeckler, IT Analyst, DCO/NCC
>>Niagara Mohawk-National Grid USA
>>Phone:  315-460-2519
>>Eric.Zoeckler AT us.ngrid DOT com
>>
>>
>>
>>This e-mail and any files transmitted with it, are confidential to
>>National Grid and are intended solely for the use of the individual or

>>entity to whom they are addressed.  If you have received this e-mail
>>in
>>    
>>
>
>  
>
>>error, please reply to this message and let the sender know.
>>
>>
>>
>> 
>>
>>    
>>
>
>
>
>This e-mail and any files transmitted with it, are confidential to
National Grid and are intended solely for the use of the individual or
entity to whom they are addressed.  If you have received this e-mail in
error, please reply to this message and let the sender know.
>
>
>
>  
>



This e-mail and any files transmitted with it, are confidential to National 
Grid and are intended solely for the use of the individual or entity to whom 
they are addressed.  If you have received this e-mail in error, please reply to 
this message and let the sender know.