Unable to successfully collect response path data after upgrade (Legacy KB ID CNC TS30559 )
Article ID: 52051
Updated On:
Products
Issue/Introduction
The issue documented above has been resolved in the following release(s):
eHealth 6.0 Service Pack 6
eHealth 6.1 Service Pack 1
eHealth Service Packs are available for download at: Service Pack and Product Downloads. Please review the README file for each Service Pack prior to installing. CA recommends that users always keep eHealth current by installing the latest Service Pack available.
Related Issues/Questions:
Unable to successfully collect response path data after upgrade
response paths stopped collecting data
Error: the request referenced an incorrect community or index, or an unsupported MIB) (Try checking that the latency partner 0.0.0.0 is reachable from the router. Cisco RttMon polling received snmp error noSuchName while in state CrmSentNormalPoll).,None,Received an SNMP Error
Response paths return polling errors
Problem Environment:
eHealth 6.1
eHealth 6.0
Causes of this problem:
The problem was that not having a uniqueDeviceId set on an element means the polling of that element does not follow the usual statistics poller SNMP throttling rules. A primary throttling rule is that we should not have more than 5 outstanding SNMP requests to any given device. This throttling parameter is in addition to the usual NH_STAT_POLLS_PER_SECOND parameter. So if NH_STAT_POLLS_PER_SECOND is set to 300, then we send ~30 SNMP requests every 100 milliseconds. For elements that do not have a uniqueDeviceId value, it is therefore possible that their agent could get 30 SNMP requests every 100 milliseconds, which would likely overflow the UDP input queue on the router in question, leading to dropped requests.
Additional Information:
The problem is that the Path Manager is creating paths without uniqueDeviceId attribute values. This prevents the polls to these routers from using agent throttling, resulting in an overload of the udp input queues on the routers in question, and missed polls.
The order in which these requests are sent out is indeterminate, so factors that could have changed the impact of this issue when upgrading include:
- if the NH_STAT_POLLS_PER_SECOND value was increased
- if additional tests were recently added to the routers
Any new instances that do not have the uniqueDeviceId value set will not be throttled and not count towards that maximum of 5 outstanding requests per agent (NH_POLL_AGENT_THROTTLE). A few is not a problem. The more there are for a router, the more likely the problem is to pop up again. Deleting the instances will not cause a problem.
(Legacy KB ID CNC TS30559 )
Environment
Component: EHCON
Feedback
