On all Junos platforms, if the device is up for a long period (e.g. several weeks or months), there might be a slow memory leak happening in some error scenarios where an application tries to send some data on a stale TCP socket (e.g. short-lived TCP connections used by the mgd process), and this issue might lead to FPC reboot with vmcore files.

The below command output helps us in identifying the system buffer usage, the maximum buffer (mbuf) usage is currently 1079:

user@device> show system buffers

fpc0:

--------------------------------------------------------------------------

1079/1456/2535 mbufs in use (current/cache/total) <<<<< current usage is 1079

1028/1038/2066/32000 mbuf clusters in use (current/cache/total/max)

1025/746 mbuf+clusters out of packet secondary zone in use (current/cache)

Over a period of time, mbuf increased:

user@device> show system buffers

fpc0:

--------------------------------------------------------------------------

1105/1430/2535 mbufs in use (current/cache/total) <<<<< slow increase for current mbuf in use

1030/1036/2066/32000 mbuf clusters in use (current/cache/total/max)

1026/745 mbuf+clusters out of packet secondary zone in use (current/cache)

When all the mbuf is used up, the following logs might be seen:

kernel: %KERN-2: [zone: mbuf] kern.ipc.nmbufs limit reached

FPC crash might be observed and the core files could be seen by "show system core-dumps".

As a workaround: To avoid this issue, please keep monitoring mbuf usage by the show command of "show system buffer", and reboot the device by the following command "request system reboot" before the mbuf reach 100% usage in the maintenance window.

Possible Triggers:
This issue might be seen if the following conditions are met:
* Junos device is up for a long period (e.g. several weeks or months)
* There is a memory leak in a case when an application tries to send some data on a stale TCP socket.

2023-1130-019954