Several modifications to the current buffering capabilities have been made over the last few releases of IOS software. This has raised questions on the interworking of buffering/queueing in Hierarchical Queueing Framework (HQF) based systems. This document will discuss the current structure of buffering, configuration options, and detail the interworking of the necessary configurations with respect to the ISR platform.
It should be noted that I/O memory size will vary per box, which is tied to the overall buffering capability. This document will cover the buffering process and will use cli for verification purposes.
The Process of Buffering
Cisco routers store packets in a few different locations depending on the congestion level:
1. Tx-Ring-hw queue or transmit ring
2. Interface buffers-public or private pools
As a packet enters a router, the packet is stored inside of the ingress buffer waiting to be processed.
The packet when sent to the egress for processing is still accounted for on the ingress interface. If the packet has exceeded the 1k buffers on the physical port, memory will be taken from the public pool.
Overview of System Buffers
The public pools of the mid-range routing series offers two possible locations to store packets: the Fast Switching buffers (F/S) and the normal pool buffers (depending on the IOS version, these buffers are used as the backup pool when the private interface pool is filled with packets). These buffers vary in size and access speed.
You can verify the buffers with the <show buffers> command:
Normal buffers, 1676 bytes (total 3840, permanent 3840):
3840 in free list (128 min, 4096 max allowed)
0 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
The public buffers (public particle pools) are used when the depth of the private buffers is reached.
The F/S buffer can provide memory for 2048 packets (512 packets in the cache and 1536 packets in the permanent memory). The soft limit is governed by the configured amount of fast switching buffers <buffers fastswitching permanent x>.
The normal buffers provide a maximum packet memory of 4096 packets (256 packets in the cache and 3840 packets in the permanent memory).
The ISR G1 and G2 platforms differ when using public buffer pools. The ISR G1 always uses the normal buffer pool. In IOS versions up to IOS 15.2T, the ISR G2 uses the Fast Switching buffer (F/S), beyond this release the normal pool buffers are used (CSCtq27141, CSCtw65356). This modification provides a larger backup pool that is useable for complex Quality of Service (QoS) configurations.
The public buffers are partially in cache, ready for use after the physical port is oversubscribed. At this point, if the router has filled up both the private and the cache public buffers, the router will request more public buffers from I/O memory. The upper value of physical I/O memory is governed by the amount of RAM on the platform.
HQF Architectural Integration
HQF (Hierarchical Queueing Framework) makes use of the physical buffering. The hold-queue parameter per interface governs the amount of buffer that the physical interface can use. The per-class queue-limit configuration limits the per-class buffering threshold. These values must be in alignment with the physical hardware limits, otherwise packet loss will occur.
Note: The aggregate queue-limit of the configured CBWFQ classes must be equal or smaller than the configured <hold-queue packets out> configured on the assigned interface. If the hold-queue limit is smaller than the configured aggregate queue-limits of the classes, the system will drop packets on the inbound interface appearing as <input queue drops> and <ignores> in the interface statistic.
After the packet is processed by HQF it is placed in the final FIFO queue, the TX-Ring. The TX-Ring provides a final queue for the physical FIFO prior to transmit onto the wire.
When congestion occurs at the egress interface i.e. the TX-Ring is full, the CBWFQ queues begin to buffer traffic based on their per class queue-limit allocations. Ideally, these queues will reach their full capacity, then will begin to tail drop additional traffic in excess of the queue-limit configured. If however the router configuration for queue-limit exceeds the physical hold-queue limit, or the hold-queue exceeds the available buffering capabilities (private pools + public pools + additional I/O MEM RAM), traffic will be dropped prior to reaching the full buffer size configured. We will cover a few different ways to address the above situations, while detailing specific commands that require configuration.
Default Settings and Configuration Parameters
The current structure of buffering on the ISR platform is as follows:
1. Each physical interface is allocated 1000 packets of buffer (hold-queue)
2. Each newly instantiated class is allocated 64 packets of buffer (queue-limit)
3. The Tx-Ring is allocated 128/256 Packets of buffer (tx-ring-limit)
4. Upon consumption of physical buffers, interfaces request buffer allocation from the F/S buffer in I/O memory
The above values are configurable and viewable via the show policy-map interface, show buffers, and show controllers commands in Cisco IOS:
Keep in mind that the architecture of the memory handling has changed during IOS development. The latest IOS releases use the normal buffer as the backup pool for the private memory pools.
IOS Versions < 15.2T
The F/S buffers allocate a fast cache value (512) available directly, a permanent value (1536) which requires a fetch action, and a max value (512+1536=2048).
IOS Versions > 15.2T
The normal pool buffers allocate a fast cache value (256) available directly, a permanent value (3840) which requires a fetch action, and a max value (256+3840=4096).
Note: The "in cache" illustrates the available buffers, when this equals 0 the pool is empty.
The physical interface pool is broken down into rx-ring (256) + remainder (768) = max allowed (1024).
The tx-ring-limit is configurable in the interface configuration mode and can be verified by the <show controller command>:
This shows the current TX-Ring value on the interface after configuration modification. The default will be either 128/256.
Router#sh run po
Building configuration...
Current configuration : 198 bytes
!
policy-map buffering
class cs4
bandwidth percent 25
queue-limit 128 packets
class cs3
bandwidth percent 10
class class-default
bandwidth percent 25
queue-limit 256 packets
Router#sh policy-map int
GigabitEthernet0/0
Service-policy output: buffering
Class-map: cs4 (match-all)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: ip dscp cs4 (32) af41 (34)
Queueing
queue limit 128 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
bandwidth 25% (250000 kbps)
Class-map: cs3 (match-all)
0 packets, 0 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: ip dscp cs3 (24)
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
bandwidth 10% (100000 kbps)
<snip>
Class cs4 has a modified queue-limit of 128 packets where class cs3 had a default of 64 packets.
Note: The aggregate of the queue-limits must be similar to the configured hold-queue limit (or the IOS default).
Router# sh int gi 0/0
GigabitEthernet0/0 is up, line protocol is up
Hardware is CN Gigabit Ethernet, address is 0026.cb27.6d60 (bia 0026.cb27.6d60)
Internet address is 10.70.1.1/24
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 1Gbps, media type is RJ45
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:07, output 00:00:00, output hang never
Last clearing of "show interface" counters 5d04h
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: Class-based queueing
Output queue: 0/1000/0 (size/max total/drops)
<snip>
The show interface command illustrates the physical limit of 1000 packets of buffer as well as flow control negotiation. This is important to note as the previous ISR G1 (2800/3800) forced flow-control on, the current ISR G2 (2900/3900) negotiates flow control. Flow control will send pause frames to the source if oversubscription is occurring, and may assist in the buffering capabilities of the platform.
Configuring Buffer Parameters
When configuring the aggregate per class queue-limit below the hold-queue setting on the physical interface the ISR will show queue-depth, and total drops via the show policy-map interface command. In this example, the router is receiving 50Mbps of traffic spread across 3 DSCP values (EF, AF41, BE). The configurations shown are not best practice and should be used for demonstration purposes only. The policy and output is shown below:
Router#sh run policy-map
Building configuration...
Current configuration : 298 bytes
!
policy-map buffering
class cs4
bandwidth percent 25
queue-limit 128 packets
class cs3
bandwidth percent 10
class class-default
bandwidth percent 25
queue-limit 256 packets
policy-map buffering-parent
class class-default
shape average 9000000
service-policy buffering
!
Router#sh policy-map int
GigabitEthernet0/1
Service-policy output: buffering-parent
Class-map: class-default (match-any)
2638885 packets, 3947650282 bytes
30 second offered rate 54131000 bps, drop rate 45133000 bps
The queue depth shown above correlates to the queue-limit, since the queue is being oversubscribed. Total drops demonstrates the tail drop on this specific queue.
In the following example, the aggregate queue-limit is configured above the hold-queue value, therefore the classes will not reach their full queue-limit capability.
Router#sh run policy-map
Building configuration...
Current configuration : 325 bytes
!
policy-map buffering
class cs4
bandwidth percent 25
queue-limit 1000 packets
class cs3
bandwidth percent 10
queue-limit 500 packets
class class-default
bandwidth percent 25
queue-limit 256 packets
policy-map buffering-parent
class class-default
shape average 9000000
service-policy buffering
The configuration above allows the per-class queue-limit to exceed the hold-queue (default 1000) on the interface. If this is the case, the classes are limited to the per interface hold-queue value, regardless of the per-class queue-limit configuration.
Router#sh policy-map int
GigabitEthernet0/1
Service-policy output: buffering-parent
Class-map: class-default (match-any)
531660 packets, 795340842 bytes
30 second offered rate 53062000 bps, drop rate 43406000 bps
The cs4 class will never reach the 1000 packet buffer that is configured due to the limiting hold-queue default of 1000 packets. The parent shaper shows the queue-depth is at 1000 packets. The queue-limit value at the parent does not show the actual aggregate queue-limit and should be ignored.
Increasing the hold-queue resolves this issue.
Router# sh run int gi 0/1
Building configuration...
Current configuration : 155 bytes
!
interface GigabitEthernet0/1
ip address 10.70.2.1 255.255.255.0
load-interval 30
duplex auto
speed auto
service-policy output buffering-parent
end
Router#config t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#int gi 0/1
Router(config-if)#hold-queue 2000 out
Router(config-if)#
Router#sh policy-map int
GigabitEthernet0/1
Service-policy output: buffering-parent
Class-map: class-default (match-any)
1268797 packets, 1898055018 bytes
30 second offered rate 21984000 bps, drop rate 15025000 bps
From the example above, we see that the aggregate queue-limit is now less than the hold-queue limit. This allows each class queue to reach its per-class queue-limit configuration.
To demonstrate the limits of the platform memory, below, the max values via cli have been configured. In this case, the policy will run the router out of physical memory. This example is using fast switching buffers after the private interface pool is depleted. The subsequent example will demonstrate the use of normal buffers, using the same configuration and the same results.
Router#sh run po
Building configuration...
Current configuration : 330 bytes
!
policy-map buffering
class cs4
bandwidth percent 25
queue-limit 32000 packets
class cs3
bandwidth percent 10
queue-limit 32000 packets
class class-default
bandwidth percent 25
queue-limit 32000 packets
policy-map buffering-parent
class class-default
shape average 9000000
service-policy buffering
!
end
Router#sh run int gi 0/1
Building configuration...
Current configuration : 178 bytes
!
interface GigabitEthernet0/1
ip address 10.70.2.1 255.255.255.0
load-interval 30
duplex auto
speed auto
service-policy output buffering-parent
hold-queue 240000 out
end
The configuration again shows excess buffering, and a hold-queue size that will stretch the capacity of the platform.
Router#sh int gi 0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is CN Gigabit Ethernet, address is 0026.cb27.6d61 (bia 0026.cb27.6d61)
Internet address is 10.70.2.1/24
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 2/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 1Gbps, media type is RJ45
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:08, output 00:00:00, output hang never
Last clearing of "show interface" counters 00:18:25
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1400771
From sh buffers we see the "in cache" equal to 0 on the ingress port, and the F/S buffers have also been consumed, therefore we will start to see ignores on ingress, as we reach for I/O memory buffers from the public pool.
At this point the egress interface has stopped dropping packets as "Total output drops", and the ingress interface is dropping packets as ignores, the buffers in the system are completely overrun, to the point that ingress traffic has no place to be buffered.
Router#sh int gi 0/0
GigabitEthernet0/0 is up, line protocol is up
Hardware is CN Gigabit Ethernet, address is 0026.cb27.6d60 (bia 0026.cb27.6d60)
Internet address is 10.70.1.1/24
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 2/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 1Gbps, media type is RJ45
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:03:40, output 00:00:01, output hang never
Last clearing of "show interface" counters 00:05:40
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 8949000 bits/sec, 748 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
254952 packets input, 381407120 bytes, 0 no buffer
The Fast Switching (F/S) buffers are limited to the permanent value seen above, if one wanted to increase the value, it would allow the system to take more buffers out of the I/O memory, providing the ability to buffer a larger amount of traffic.
Increasing the fast switching buffers is not recommended, unless there is an explicit reason to do so. This configuration could run the entire platform out of I/O memory, causing the router to crash or worse. providing non-deterministic behavior.
Using the same configuration as above with the latest image. the results are the same. Output drops are seen initially then when the public pool is depleted, ignores are seen on the ingress interface.
Router#sh int gi 0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is CN Gigabit Ethernet, address is 0026.cb27.6d61 (bia 0026.cb27.6d61)
Internet address is 10.70.2.1/24
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 2/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 1Gbps, media type is RJ45
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:18, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 40526
Below via sh buffers, we see the "in cache" equal to 0 on the ingress port, and the normal buffers have also now been consumed, therefore we will start to see ignores on ingress as we reach for I/O memory buffers from the public pool.
At this point, the egress interface has stopped dropping packets as "Total output drops", and the ingress interface is dropping packets as ignores, the buffers in the system are completely overrun to the point that ingress traffic has no place to be buffered.
Router#sh int gi 0/0
GigabitEthernet0/0 is up, line protocol is up
Hardware is CN Gigabit Ethernet, address is 0026.cb27.6d60 (bia 0026.cb27.6d60)
Internet address is 10.70.1.1/24
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 2/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 1Gbps, media type is RJ45
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:02, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 8957000 bits/sec, 1125 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
1588785 packets input, 1582429860 bytes, 0 no buffer
0 output buffer failures, 0 output buffers swapped out
Router#
After stopping the traffic, the public pool of memory shown via "show buffer" demonstrates free memory now available in the public pool. "In cache" value for normal buffers is back to 1024.
The fast switching buffers are used to control the public pool of memory on the ISR G2. This memory is used only when the private interface buffer is completely used. The hold-queue determines the amount of egress buffer used by HQF at the physical interface, along with the per-class queue-limit commands. The aggregate per-class queue-limit should equate to the hold-queue, in order to allow buffering up to the per-class queue-limit.
It is not recommended, unless specifically required, to adjust the fast switching buffers. This memory is public to the platform, and is used not only to store packets, but for normal operation of the router. If the memory of the platform is exceeded, I/O memory exceed messages will be seen on the platform, which could lead to a router failure.
IOS Versions > 15.2T
Moving forward, the normal buffer pool, as opposed to the F/S pool, will be used to allocate buffer when physical buffer has been depleted. This is listed in the known issues section below as CSCtq27141.
Related Issues:
• CSCtj55834-2900 unable to use public buffers like the 2800
• CSCtq16226-Huge buffer values in 'buffers fastswitching permanent' causes crash
• CSCtw65356-Unaccounted packets with QOS/HQF configuration
• CSCtq27141-Buffer exhaustion occurs handling different in 2900 than 2800