Something that caught my attention is the fact that the file "messages" or sylog is filled with the following logs:
?
Jan 7 05:39:05 asw1-b12-drmrs fpc0 TVP_PROC_STAT_FILE_OPEN_ERR: Error opening /proc/stat file
?
This log has been addressed and reported via internal KBs and also through confidential PRs which have not been published yet.
In short, the error "TVP_PROC_STAT_FILE_OPEN_ERR" appears in logs or terminal output and repeated failures or abnormal behavior when running resource monitoring utilities.
?
The syslog message indicates dcpfe daemon can NOT access the file of /proc/stat in the linux host for some reason.
(/proc/stat is a virtual file in Linux that provides cumulative system activity statistics, like CPU time in various states (user, system, idle, iowait), page swaps, context switches, and interrupts, all counters that reset at boot time and are used by monitoring tools (like top, htop) to calculate real-time CPU usage and overall system health. It's crucial for performance analysis, showing how long the CPU spends on different tasks since the system started.)

There could be various reasons a file can NOT be accessed but in this case it's because too many FD(File Descriptor)s are already opened by dcpfe and its limit has been reached.
Opening a file in Linux requires one available FD to be assigned for it, but the dcpfe can't do so as it has all its available FDs already assigned opening too many /var/log/BRCM_PKT.log files.
?
The issue is tied to BRCM_PKT.log, and it occurs only when there are frequent DDoS violations in the system.

I extract the following information from internal resources:

    Each time a DDoS violation is triggered, the system creates a new file descriptor, which leads to an increasing number of open FDs.
    Currently, we cannot reduce the number of open file descriptors at runtime, and we also don't have a feature flag available to disable this behavior.
    Given these constraints, the only practical workaround for now is to prevent the switch from being subjected to DDoS attacks.

?
Looking at the logs, I see that there are also multiple notifications of ddos violations:
Jan 7 05:38:22 asw1-b12-drmrs jddosd[14006]: DDOS_PROTOCOL_VIOLATION_SET: Warning: Host-bound traffic for protocol/exception TTL:aggregate exceeded its allowed bandwidth at fpc 0 for 1109 times, started at 2026-01-07 05:38:22 UTC
Jan 7 05:38:22 asw1-b12-drmrs jddosd[14006]: DDOS_PROTOCOL_VIOLATION_SET: Warning: Host-bound traffic for protocol/exception L3MTU-fail:aggregate exceeded its allowed bandwidth at fpc 0 for 1109 times, started at 2026-01-07 05:38:22 UTC
?
According to further/internal resources, the permanent fix would be to upgrade the Junos software to a version with the fix for this issue: for instance 23.4R2-S7
?
Regarding the PFE commands that are timing out, I found the probable cause:
?
Workaround
?
First of all, let's confirm the BRCM_PKT handle ID:

root@QFX5120-48Y:RE:0% cprod -A fpc0 -c "show ukern_trace handles" | grep -E "Name|BRCM_PKT"
?
Then, apply the commands:
root@QFX5120-48Y:RE:0% cprod -A fpc0 -c "set ukern_trace 16 file-logging disable"
root@QFX5120-48Y:RE:0% cprod -A fpc0 -c "set ukern_trace 16 logging disable"
root@QFX5120-48Y:RE:0%
root@QFX5120-48Y:RE:0% cprod -A fpc0 -c "show ukern_trace handles" | grep -E "Name|BRCM_PKT"
ID Name Level Printf Logging Size Wrap Filter-id
*16 BRCM_PKT terse Off Off 0 1 - <========== Logging Off

This workaround will NOT work (commands will timeout) if the system is NOT rebooted and the dcpfe still is on its FD max limit.
You must apply this workaround after rebooting the system if you are already seeing the syslog message.
It is because for the workaround commands to be delivered to the dcpfe, it needs to establish new socket connections to cprod but since the dcpfe can't get any more FD assigned, no more socket opened.
(Every socket open requires a FD assigned).
?