AFAIK there is interface buffer allocated to each interface for I/O traffic. When packets enters to the interface, it occupies the buffer and when leaves releases the buffer and same gets added to the free-list again otherwise free-list will keep on reducing and we will see buffer misses and packet drops. That could be condition during buffer leak. There is also process who checks on max-allowed value. Definition given below. You can also refer below link
When I had the checkup for the Cisco 2811, I got these output below:
show buffers Buffer elements: 1072 in free list (1119 max allowed) 104055923 hits, 0 misses, 619 created
Public buffer pools: Small buffers, 104 bytes (total 191, permanent 50, peak 264 @ 7w0d): 21 in free list (20 min, 150 max allowed) 168577974 hits, 214695 misses, 36670 trims, 36811 created 4799 failures (0 no memory) Middle buffers, 600 bytes (total 25, permanent 25, peak 37 @ 7w0d): 15 in free list (10 min, 150 max allowed) 28090344 hits, 2522 misses, 259 trims, 259 created 1254 failures (0 no memory) Big buffers, 1536 bytes (total 50, permanent 50): 50 in free list (5 min, 150 max allowed) 4280928 hits, 0 misses, 0 trims, 0 created 0 failures (0 no memory) VeryBig buffers, 4520 bytes (total 10, permanent 10): 10 in free list (0 min, 100 max allowed) 0 hits, 0 misses, 0 trims, 0 created 0 failures (0 no memory) Large buffers, 5024 bytes (total 0, permanent 0): 0 in free list (0 min, 10 max allowed) 0 hits, 0 misses, 0 trims, 0 created 0 failures (0 no memory) Huge buffers, 18024 bytes (total 0, permanent 0): 0 in free list (0 min, 4 max allowed) 0 hits, 0 misses, 0 trims, 0 created 0 failures (0 no memory)
The "Public buffer pools" refers to the process memory that handled by RP as I know.
Since most packets hit the Small buffers in the process memory, I think they belong to the control plane.
Now the device works normally both the hardware and system, and I could tell from the output that there are 170 buffers in Small buffers pool that are in use, 21 in the free list and consider these statistics are the normal state of the device.
But there was also a burst of traffic at 7w0d that pushed the RP to create 264 buffers and met a number of failures.
Is it right to say that there could probably be a burst of control plane traffic such as routing protocol convergence at 7w0d since the device started about 1 year ago?
If advices needed, though it might not be serious, is it right to give more Small buffers by tuning the min-free parameter to prevent "a might happen again burst" (the memory usage is about 7%)?
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...