2. Status Critical Stale collections (41.483) has status Critical because there were more than 10 in the last 5 minutes. - - - - i think its related to Network Topology Autolayout Error. you need to remove some devices and rediscover them. i am having a document in which this info is present:
NNM will occasionally draw part of a network topology that varies with what you know is correct. This is NNMâ s way of telling you that it is having some sort of difficulty and is making the best of a bad situation. NNM is very conservative. It tends to make few assumptions and will retain old data that once was accurate over new data that is inconsistent or inconclusive. Usually, this is not a bug with NNM, and by exploring the circumstances surrounding the discovery and layout problems, the reason is almost always found. The remedy may not be as apparent.
Sometimes NNM doesnâ t lay out part of the network properly because it cannot get the information it needs from a buggy SNMP agent. For example, an Ethernet switch may not properly implement the bridge MIB, so NNM isnâ t able to correctly identify all of its ports. The discovery problem leads to an autolayout problem.
Since NNM tends to hang on to old configuration information, it may have difficulty when a device configuration radically changes. For example, inserting a new card into an Ethernet switch and restarting it often results in renumbered MIB instances for the ports. At the next configuration check, NNM may add all the new instances in but not delete the old ones. Sometimes the only way to rid the NNM database of this stale data is to delete the device and then ping it from the NNM system to force a rediscovery. Note that since maps wonâ t be affected by this until they are opened, the map count for this deleted object will be inconsistent.
NNMâ s IP-centric design will create a subnet container for every subnet it discovers. If a router interface has one primary address and three secondary addresses, then NNM will show the router as having four subnets attached. This is completely true from an IP viewpoint. Suppose that the additional subnets are needed to support an increasing number of devices. Each device discovered is situated into its proper subnet container. Now suppose that the switches are assigned IP address at random from the available four subnets. NNM will draw the physical topology in each subnet incorrectly. The fix is to readdress the switches to the same subnet. In this subnet, NNM will be able to correctly draw the physical topology. If some of the switches are addressed within the same subnet, they will be connected properly, but their peers will be lodged within the other subnet icons, ruining NNMâ s ability to lay out the correct topology.
What version and patch level of NNMi are you running? Patch 3 introduced a problem where bogus stale collections are reported. This is corrected in the NNMi consolidated STATEPOLLER hotfix which is available from support.
HP Support If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution, If you are satisfied with anyone’s response please remember to give them a KUDOS and show your appreciation.