Does NCM switch to an aggressive polling method when nodes go down?

Question

I have a remote location that has a router and two switches behind it. Today the router wan connection went down and Orion reported all three devices down and then later up.

I don't want to discuss event correlation (at this time).

I noticed that the down detection of the three devices took an elapsed 3:01 while the up detection only took 0:10.

Question: Does NCM switch to an aggressive polling method when nodes go down?  That is the only reason I can think of that would result in the up detection being so close together in time.

Question: Why did the up alerts come in the reverse order? Shouldn't they be in the same order that they are generated?

AlarmDeviceTimeStampdownloc-sw-1.example.com14:21:11downloc-sw-2.example.com14:22:13downloc-rtr.example.com14:24:12 elapsed time0:03:01

uploc-rtr.example.com15:05:35uploc-sw-2.example.com15:05:38uploc-sw-1.example.com15:05:45 elapsed time0:00:10

cgregors · Answer

I can accept that.

In the case I was referring to above, the actual problem was a wan link that went down. The actual nodes that reported down were actually up for the whole duration.

I still have some problem visualizing how the polling engine queue management works but it is a minor point.

mcbridea · Answer

It would be FILO if we assume all devices have the same boot cycle duration. The time required to reboot will be a larger factor on when you will get an up status compared to relitive time into the fast polling cycle.

ecklerwr1 · Answer

I think cdh was right in saying it all depends on where in the polling cycle NPM was and also timing on responses coming back etc.  I would expect the order of the nodes being reported down and coming back to vary depending on multiple variables.