1-8 Buffer Management

• Routers allocate memory into buffers to store and switch packets when routing.

• Router memory is structured into system memory and shared (I/O) memory. To determine how the memory is divided, use the show version command. Look for " xxx K/ yyy K bytes of memory," where xxx is the amount of system memory and yyy is the amount of shared memory.

• Buffer space is divided into public (system) buffers and interface buffers.

• Router hardware determines where the buffers are located:

  • Low-end models (such as the 1600, 2500, 4000, 4500, and 4700) All buffers are located in shared memory.

  • Particle-based models (such as the 2600, 3600, 7200, and Catalyst 6000 MSFC) Public buffers are used for process switching, and packets are split into particles in interface buffers for fast switching.

  • High-end models (such as the 7500) Interface buffers are used for fast switching; otherwise , system buffers are used.

• System buffers on a router are allocated in the following types and sizes:

  • Small 104 bytes

  • Middle 600 bytes

  • Big 1524 bytes

  • VeryBig 4520 bytes

  • Large 5024 bytes

  • Huge 18024 bytes (configurable)

• Buffers are allocated for use according to buffer type and the MTU or packet size needed.

• Buffer parameters define how and when buffers are allocated:

  • permanent The number of buffers allocated during router initialization.

  • min-free When the number of buffers falls below this number, the router attempts to allocate more from available memory.

  • max-free When the number of buffers rises above this number, as buffers are freed, the router deallocates them.

• If a buffer is needed, but none are free and available, the router flags a buffer miss before allocating a new buffer. If an additional buffer cannot be allocated due to a lack of available memory, the router flags a buffer failure. In the case of interface buffers, these conditions are flagged as fallbacks , and the router allocates additional buffers in the public buffer space instead.

CAUTION

System buffers can be tuned to improve certain router performance conditions. However, buffer tuning should be attempted with caution. Ideally, you should open a case with Cisco TAC to obtain engineering guidance before tuning the buffers.

Configuration

This section looks at system buffers, which are used to store packets for receiving and transmitting purposes. The first subsection deals with how to monitor and view the buffer information. The second subsection deals with how to modify and tune buffer performance. It is important to mention that although system buffers can be tuned to improve certain router performance conditions, the default buffers were designed with a great deal of study by Cisco. If you feel you need to tune the buffers, you should open a case with Cisco TAC to obtain engineering guidance before tuning the buffers.

Buffer Monitoring

1. Look for interface buffer problems:

    (exec)  show interface  [  type num  ] 

   If a particular interface is suspected of having buffer problems, it can be identified by type and num. Otherwise, information about all interfaces is displayed. Look for lines that list the number of "no buffer" conditions, as shown in the following example:

    Router#  show interface ethernet 9/4  Ethernet9/4 is up, line protocol is up   Hardware is cxBus Ethernet, address is 0000.0c45.2124     (bia 0000.0c45.2124)   Description: Engineering department   Internet address is 172.16.98.1/26   MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,      reliability 255/255, txload 2/255, rxload 1/255   Encapsulation ARPA, loopback not set   Keepalive set (10 sec)   ARP type: ARPA, ARP Timeout 04:00:00   Last input 00:00:06, output 00:00:00, output hang never   Last clearing of "show interface" counters never   Queueing strategy: fifo   Output queue 0/40, 811 drops; input queue 0/75, 36 drops   5 minute input rate 17000 bits/sec, 18 packets/sec   5 minute output rate 97000 bits/sec, 47 packets/sec  247323938 packets input, 2280365753 bytes, 108 no buffer  Received 5812644 broadcasts, 93 runts, 0 giants, 1 throttles   199 input errors, 101 CRC, 1 frame, 4 overrun, 0 ignored   0 input packets with dribble condition detected   861479969 packets output, 2668694324 bytes, 0 underruns   12 output errors, 6890760 collisions, 4 interface resets   0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 

   There were 108 times when packet buffers needed to be allocated, but there was not enough available memory.

2. Look for general buffer problems:

    (exec)  show buffers  

   Each type of buffer is displayed with its size, along with counters for a variety of buffer activities. Pay close attention to the "Public buffer pools" and "Public particle pools" sections. Here are some of the more interesting counters:

   • total The total number of buffers in the pool type (used and unused).

   • permanent The number of buffers always in the pool.

   • in free list The number of buffers currently available for use.

   • min The minimum number of buffers that are maintained in the free list. If this number falls below min, an attempt is made to allocate more.

   • max allowed The maximum number of buffers in the free list. If this number rises above the maximum, some buffers are " trimmed " or unallocated .

   • hits The number of buffers allocated successfully from the free list.

   • misses The number of times a buffer was needed but was unavailable in the free list.

   • trims The number of buffers that have been trimmed from the free list.

   • created The number of buffers that have been created to maintain the min number in the free list.

   • failures The number of times a buffer was unavailable and could not be allocated. This reflects packets that were dropped.

   • no memory The number of times an attempt was made to allocate new buffers but the router was out of memory.

   The following example shows the output from the show buffers command. You should be suspicious of buffer problems if you see both failures and no memory numbers greater than 0.

    Router#  show buffers  Buffer elements:      499 in free list (500 max allowed)      140186641 hits, 0 misses, 0 created Public buffer pools: Small buffers, 104 bytes (total 480, permanent 480):      467 in free list (20 min, 1000 max allowed)      353917332 hits, 1867 misses, 402 trims, 402 created  1347 failures (0 no memory)  Middle buffers, 600 bytes (total 360, permanent 360):      305 in free list (20 min, 800 max allowed)      1755872447 hits, 1660 misses, 48 trims, 48 created  1608 failures (0 no memory)  Big buffers, 1524 bytes (total 360, permanent 360):      324 in free list (10 min, 1200 max allowed)      50506313 hits, 700 misses, 11 trims, 11 created  664 failures (0 no memory)  VeryBig buffers, 4520 bytes (total 40, permanent 40):      40 in free list (5 min, 1200 max allowed)      3119206 hits, 565 misses, 6 trims, 6 created  537 failures (0 no memory)  Large buffers, 5024 bytes (total 40, permanent 40):      40 in free list (3 min, 120 max allowed)      178 hits, 363 misses, 4 trims, 4 created  361 failures (0 no memory)  Huge buffers, 18024 bytes (total 9, permanent 0):      7 in free list (3 min, 52 max allowed)      13212271 hits, 361 misses, 0 trims, 9 created  352 failures (0 no memory)  

   Here, failures were reported , indicating that some buffers were needed but the router could not allocate them in time to route a packet. This was not necessarily due to a lack of memory, but rather to circumstances that required packets to be dropped before buffers were allocated. The 0s reported for no memory show that there was not a shortage of buffer memory. Also, notice that the number of failures is a very small percentage of the number of hits reported.

   Buffer tuning might be required if nonzero no memory counters are seen. Tuning can also be appropriate if the number of failures is a noticeable percentage of the number of hits. (This percentage is a subjective one, and it might not apply in all situations. Assistance from the Cisco TAC can help determine whether buffer tuning is necessary.)

Tuning the Buffers

Use the following command to tune the buffers:

 (global)  buffers  {  small   middle   big   verybig   large   huge   type   number  }   {  permanent   max-free   min-free   initial  }  value  

Parameters can be set for a specific type of public buffer pool. The type of buffer pool is given as small, middle, big, verybig, large, or huge. The pool parameter is given with the permanent, max-free, min-free, or initial keywords, along with the desired number value.

NOTE

You can also tune the interface buffer pools using the interface type and number values. You should not attempt to change the values associated with interface buffers. These values were carefully calculated by Cisco for proper operation.

Tune only the buffer type that exhibited problems in the show buffers command. As a general rule of thumb, a new permanent value should be about 20% larger than the total number of buffers in the pool. A new min-free value should be about 25% of the number of permanent buffers, and max-free should be greater than the sum of permanent and min-free.

Example

According to the show buffers command, the number of small buffers initially was:

 Small buffers, 104 bytes (total 480, permanent 480): 467 in free list (20 min, 1000 max allowed) 353917332 hits, 1867 misses, 402 trims, 402 created 1347 failures (0 no memory) 

The new parameters for small buffers are set to the following values: permanent 576, min-free 144, and max-free 750.

 buffers small permanent 576 buffers small min-free 144 buffers small max-free 750