Bug ID 801525: With large config, SNMP response times may be long due to processing burden of requests

Last Modified: Apr 21, 2022

Bug Tracker

Affected Product:  See more info
BIG-IP TMOS(all modules)

Known Affected Versions:
12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 12.1.3,,,,,,,, 12.1.4,, 12.1.5,,,, 12.1.6, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0,,,,,,,,, 13.1.1,,,,, 13.1.3,,,,,,, 13.1.4,, 13.1.5, 14.0.0,,,,,, 14.0.1,, 14.1.0,,,,,, 14.1.2,,,,,,,,, 14.1.3,, 14.1.4,,,,,,, 15.0.0, 15.0.1,,,,, 15.1.0,,,,,, 15.1.1, 15.1.2,, 15.1.3,, 15.1.4,, 15.1.5,, 16.0.0,, 16.0.1,,, 16.1.0, 16.1.1, 16.1.2,,

Opened: Jul 02, 2019
Severity: 3-Major
Related AskF5 Article:


On devices with large configurations, it is possible to make SNMP requests that require a lot of processing to gather the statistics needed to respond to the request. Possible symptoms include slow responses to SNMP gets, and high mcpd utilization.


Increased load on mcpd and snmpd. SNMP clients might time out and the BIG-IP system may become unresponsive.


-- Large configurations. -- SNMP queries to large tables (e.g., a large number of pool members, or a large number of virtual servers). -- High mcpd utilization.


-- If you are experiencing slow response time, it can help to use SNMP client options of long timeouts and less retries so that SNMP requests do not keep restarting each time the previous request times out. -- If you are querying statistics information, it is more efficient to just query the specific table you are interested in rather than doing a full snmpwalk of multiple tables. -- If you are making bulk requests, you should avoid requesting from multiple different tables in the same request. -- Avoid having multiple different clients querying different tables simultaneously.

Fix Information


Behavior Change