If this is the case, then how come in my simulations when I start an agent, and then netview notices its down, then I turn it back up, if I ping it right away the object in netview changes status, if not, it will eventually pick it up when “it feels like it”

 

 

The arp cache will only store the mac address of the local router that is forwarding packets on behalf of the IP address you are interested. The real mac address is not present in the arp table on the router (unless by coincidence, the router has another interface into the subnet where the device actually resides). I believe the same would be true for the netview box’s arp cache – it’s going to reflect the mac address of the device local to the NetView server (such as the local router) that can reach the end device IP address.

 

Short answer: I don’t think arp cache has anything to do with it. I could be wrong.

 

 

I have noticed that if a device goes down, and then comes back up before netmon “magically notices it”, if you ping the device, the object status will change in NetView. I assume this is because NetView is somehow monitoring the arp tables? We are using NetView 7.1.3 on Solaris and I am kind of curious to know how netmon and the arp cache works. It seemed like in my tests with my network simulator, If I took down 200 nodes, and then brought them up before netmon’s polling cycle kicked in, that if I pinged every one of them (with a script of course), about only 10 or so nodes would immediately have their object status changed in NetView. How does netmon divvy up the workload? Helper threads? Timeslicing ?

 

*** Note new e-mail address

--

Michael J. Freeman

Netco Government Services

mfreeman AT netcogov DOT com

--