The process for the command is not responding or is otherwise unavailable after %SNMP-3-INPUT_QFULL_ERROR message on logg

[Mic_Hael]

Hello,

I have a problem, "The process for the command is not responding or is otherwise unavailable" is shown on the shell. I create a cisco TAC (it is running) but after 5 webex sessions I think cisco also do not know what this error is or know the source of the problem...

Platform: Catalyst 3650

IOS-XE Version: 16.12.4

I configured a 802.1x configuration on my systems. After few days, weeks or month there is the message "%SNMP-3-INPUT_QFULL_ERR" in the log an no communication via SNMP is available. For dot1x ==> no client can connect the ISE and is able to authenticate. The line "The process for the command is not responding or is otherwise unavailable" is the output on "show access-session" and all the other commands of dot1x checking. A "show netconf-yang" command also have this output. We found no process until today who create that issue.

Before dot1x configuration everything works fine for month and years and this error do not occure.

My questions are:

- Which process can fill the SNMP Queue to full? It is set to max. count from 5000 too.

- Why the output "The process for the command is not responding or is otherwise unavailable" is comming on commends like:

"show access-session ... "; "show netconf-yang session..."; and possible more?

- Why this error occured after days, weeks or month because everthing works fine after configuration? I think that the number of clients is crucial for the entry point.

Thanks for help

Michael

[marce1000]

 - Check resolving reply : https://community.cisco.com/t5/network-management/snmp-3-input-qfull-err/td-p/2019289

 M.

[Mic_Hael]

Hello and thanks, but all these bug ID's are went to the wrong platform or IOS-XE.

We are really sure, that the problem is deeper the programming of the platform. Actually the platform team from cisco is involved to find somthing out. 

We do not know how the Queue is filling to full, because there is no process which can do that found. Maybe the ISE, or any process, requests etc. is the problem, maybe other monitoring tools which gather snmp information from the platform is the reason(?), but in fact, no one of the bug-id's describe our problem correctly and the cisco TAC Team checked it too ;).