03-05-2012 08:00 AM
The system logs in my controllers are being overrun with the following message.
Mar 2 13:07:44 :301268: <WARN> |snmp| Reached the limit on Inform Notification queue for 18.104.22.168:162
Mar 2 13:10:14 :301268: <WARN> |snmp| Reached the limit on Inform Notification queue for 22.214.171.124:162
Mar 2 13:14:10 :301268: <WARN> |snmp| Reached the limit on Inform Notification queue for 126.96.36.199:162
Mar 2 13:16:16 :301268: <WARN> |snmp| Reached the limit on Inform Notification queue for 188.8.131.52:162
I have had a TAC case open for a couple of months to no avail. Has anyone else seen these messages?
03-05-2012 11:22 AM
On the CLI, do the following command - "show snmp inform stats". Do you see overflows?
Check the IP Address for the SNMP host. Are you sure it should be 184.108.40.206?
Is there anything that would block UDP/162?
Do you filter at the receiver (only allow certain IP addreses to send informs)? Make sure you are allowing the correct address to send them to your host.
Also, as chrisbrizzell said, make sure your receiver is not overloaded.
03-05-2012 12:00 PM
By default, unacknowledged informs will be sent every 60 seconds for up to 3 times before it is dropped. You can try changing the 60 second interval using the “interval” attribute in snmp-server host “eg. snmp-server host …. version 3 ….. interval <>”. You can also try changing the number of retries via retrycount attribute in snmp-server config. “snmp-server host <ip> version 3 <WORD> retrycount “. After the inform is dropped, the next inform in the queue is processed. If the inform queue is full new informs will not be added in the queue and will be dropped.If the controller is generating excessive traps faster than the trap receiver can acknowledge the traps then the queue will always be full. You can try disabling some traps or use non-inform v2/v3 hosts or v1 trap host.