All,
I am attempting to determine how to remediate drops that I believe are caused by buffer failures on a 2921 ISR. The relevant interface statistics are:
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/377 (size/max/drops/flushes); Total output drops: 83
Queueing strategy: fifo
The relevant buffer data is:
2921#show buffer
Buffer elements:
1249 in free list
54679483 hits, 0 misses, 2268 created
Public buffer pools:
Small buffers, 104 bytes (total 95, permanent 50, peak 150 @ 6d15h):
89 in free list (20 min, 150 max allowed)
67415929 hits, 5810 misses, 6477 trims, 6522 created
572 failures (0 no memory)
Middle buffers, 600 bytes (total 20, permanent 25, peak 115 @ 1w0d):
16 in free list (10 min, 150 max allowed)
24912561 hits, 2150 misses, 4642 trims, 4637 created
148 failures (0 no memory)
Big buffers, 1536 bytes (total 133, permanent 50, peak 329 @ 3w0d):
132 in free list (5 min, 150 max allowed)
17161476 hits, 11530 misses, 34480 trims, 34563 created
1 failures (0 no memory)
VeryBig buffers, 4520 bytes (total 10, permanent 10, peak 11 @ 3w0d):
10 in free list (0 min, 100 max allowed)
1814389 hits, 0 misses, 1 trims, 1 created
0 failures (0 no memory)
Large buffers, 5024 bytes (total 1, permanent 0, peak 1 @ 3w0d):
1 in free list (0 min, 10 max allowed)
0 hits, 0 misses, 191 trims, 192 created
0 failures (0 no memory)
Huge buffers, 18024 bytes (total 5, permanent 0, peak 8 @ 5d13h):
5 in free list (4 min, 10 max allowed)
168001 hits, 1 misses, 383 trims, 388 created
0 failures (0 no memory)
Interface buffer pools:
CF Small buffers, 104 bytes (total 101, permanent 100, peak 101 @ 3w0d):
101 in free list (100 min, 200 max allowed)
0 hits, 0 misses, 191 trims, 192 created
0 failures (0 no memory)
Onboard DSPRM Pool buffers, 264 bytes (total 300, permanent 300):
0 in free list (0 min, 300 max allowed)
300 hits, 0 fallbacks
300 max cache size, 300 in cache
702738 hits in cache, 0 misses in cache
Cellular eHWIC IPC buffers, 512 bytes (total 257, permanent 257):
0 in free list (0 min, 257 max allowed)
257 hits, 0 misses
257 max cache size, 255 in cache
1437653 hits in cache, 0 misses in cache
Generic ED Pool buffers, 512 bytes (total 101, permanent 100, peak 101 @ 3w0d):
101 in free list (100 min, 100 max allowed)
0 hits, 0 misses
CF Middle buffers, 600 bytes (total 101, permanent 100, peak 101 @ 3w0d):
101 in free list (100 min, 200 max allowed)
0 hits, 0 misses, 191 trims, 192 created
0 failures (0 no memory)
The Interface showing these drops is configured as follows:
1#show run int g0/1
Building configuration...
Current configuration : 425 bytes
!
interface GigabitEthernet0/1
description Broadband Connection
ip address x.x.x.x x.x.x.x
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow monitor NTAmon input
ip flow monitor NTAmon output
ip flow ingress
ip flow egress
ip nat outside
ip virtual-reassembly in
ip virtual-reassembly out
cws out
zone-member security outside
duplex auto
speed auto
no cdp enable
no mop enabled
end
There are tunnel interfaces configured that use this interface as a source that show even more drops, but since those are virtual interfaces, I count those drops as virtual drops, etc - besides, tunnels always have screwy stats.
As I understand the mechanics of buffer failures and how they lead to drops - it's basically a result of packets getting lost as the CPU tries to find a buffer from which to transmit it from.
My understanding however, comes from this 13 year old document.
https://www.cisco.com/c/en/us/support/docs/interfaces-modules/channel-interface-processors/14620-41.html
The most recent "troubleshooting" document seemingly based on this information does not seem to cover the ISR platform - https://www.cisco.com/c/en/us/support/docs/routers/10000-series-routers/15091-buffertuning.html
And understandably, the old "buffer tuning tool" has been deprecated and is no longer available.
My big question is - how can I confirm that the current interface configuration is the cause of the buffer failures and in-turn that the buffer failures are the cause of the drops without removing configurations until the failures and drops stop. Is there a less primitive and intrusive method of verifying this?
