This KB document the LDP leak issue on ACX710 if PFE never responds
Customer might observe ldp_stats_cache_req is continuously increasing in certain race condition.
root@GP-WVPK-AGN01> show task memory detail | grep stats | refresh 3
---(refreshed at 2025-11-20 10:44:16 SAST)---
ldp_stats_cache_entr 112 128 - - 29 3712
ldp_stats_cache 24 28 1 28 1 28
ldp_stats_cache_req 28 32 7380 236160 7381 236192
ldp_stats_ctx 64 68 1 68 1 68
ldp_p2mp_bstats_ctx 16 20 1 20 1 20
ldp_ppm_stats_group 24 28 1 28 1 28
dyn_tunnels_stats_bg 20 24 - - 1 24
---(refreshed at 2025-11-20 10:44:19 SAST)---
ldp_stats_cache_req 28 32 7382 236224 7383 236256
tunnel_stats_t 24 28 1 28 1 28
---(refreshed at 2025-11-20 10:44:22 SAST)---
ldp_stats_cache_req 28 32 7385 236320 7386 236352
labroot@GP-WVPK-AGN01> request pfe execute command "show nhdb management ipc" target fpc0 | refresh | match bulk
---(refreshed at 2025-11-21 06:17:39 SAST)---
get_bulk_stats 2750647 0 0 0
---(refreshed at 2025-11-21 06:17:48 SAST)---
get_bulk_stats 2750937 0 0 0
---(refreshed at 2025-11-21 06:17:57 SAST)---
get_bulk_stats 2751182 0 0 0
also some of the other error during the issue is as follow
MIB2D_RTSLIB_READ_FAILURE: check_rtsock_rc: failed in reading mac_db
This is bug which is fixed through PR.
when snmp request arrives in LDP and because of a cache miss, a request is send to the kernel/pfe. if the update from kernel never responds back, there is a timeout which will result in re-requesting for the same/next (same if the fec is still present in LDP, next if fec is deleted) set of fecs again and this will go on till a response comeback. this can result wasting ldp kernel and pfe resources is sending and listening for kstat responses. external trigger is huge scale and huge churn in the network, along with snmp polling for the ldp statstics oids can result in this issu