思科设备巡检过程中，往往要求工程师注意show buffers输出的failures及misses，出于对buffer以及其中各项参数的意义的好奇，特进行了探究，遂编写此文档。

1.路由器数据转发机制

1.1 转发机制概述

（1）Process Switching

基于进程的转发，数据流量的处理需要依赖RP（Routing Processor）。

（2）Fast Switching

类似于MLS技术，数据流量在第一次被转发时，是基于进程的转发方式，需要依赖RP。

在第一次转发时，建立起转发缓存，之后处理相关数据流量时，直接查询缓存项转发，而不用依赖RP。

（3）CEF

直接根据RIB、ARP转发表等信息，构建起FIB以及Adjacency Table，不用依赖RP。

1.2 数据被路由器转发的过程

对于需要RP处理的数据，其转发过程这里进行大致介绍。

①Ingress Traffic

某个端口收到入站流量，该流量需要交给RP处理。

②Ask for buffer

InterfaceProcessor向RP发出请求，申请一块ProcessorMemory中的buffer，以待RP处理。

③Response

RP根据Processor Memory的实际情况进行回复。

如有buffer可容纳该待发packet，则其将被发送至Processor Memory的buffer中；否则则会产生丢包。

2.Cisco Buffer分配机制

2.1 Buffer概述

2.1.1 什么是Buffer

在Cisco路由器中，Processor Memory被划分为了6种不同尺寸的pools，每种pool中包含相同大小的blocks，这些blocks即被称为buffers。

2.1.2 不同Pool类型中Buffer的尺寸

①Small buffer——104 bytes

②Middle buffer——600 bytes

③Big buffer——1536 bytes

④VeryBig buffer——4520 bytes

⑤Large buffer——5024 bytes

⑥Huge buffer——18024 bytes

2.1.3 Pool与Buffer的关系

一个pool中可能存在如下情况：

（1）已分配空间

已分配空间中，是已经被创建的、占据了memory的buffers。这些buffers可能正有packet待处理，也有可能正等待packet进驻。

（2）未分配空间

未分配空间指的是，该部分空间没有buffer，当需要创建buffer时，可从中划分出buffer以供packet使用。

注意：

①Pool中所能创建的buffers总量是有限定的，该限定可能来自于memory本身的容量，也可能来自于管理员的指定。

②Buffer是按需创建而非固定充满于pool中的，因此pool没有固定的大小。

③Pool的类型决定了其中buffer的尺寸。

2.2 Buffer请求过程

2.2.1 Interface Processor如何请求

InterfaceProcessor根据待转发packet的大小，确定需申请的buffer。

2.2.2 Routing Processor如何处理

（1）情况一：当前pool中有free buffer

RP将该buffer授权给interface processor。

（2）情况二：当前pool中没有free buffer，但有free space

①RP从free space中创建buffer。

②RP为该pool记录一个miss。

③RP将该buffer授权给interfaceprocessor。

（3）情况三：当前pool中无free buffer，无freespace

①RP为该pool记录一个miss。

②RP为该pool记录一个failure。

③RP检查下一等级（更大）的pool，查看是否有buffer能承载该packet。

注意：

如果各级pool中都没有可分配的buffer，该过程会一直持续到huge buffer后，被丢弃。产生failure，并不意味着丢包。

2.3 相关配置

2.3.1 show相关

showbuffers示例：

从Public buffer pools往下开始计数：

（1）第一行——buffer总数相关

①Total

当前pool中总共的buffers数量，包括inusedbuffer以及free buffer。

②Permanent

永久留存在pool中的buffer数量， pool中的buffer数量是直接受到permanent影响的，permanent应理解为buffers总数的一个下限。

（2）第二行——free buffer相关

①in free list

记录了free buffer的总数。

②min

指定了free list中最少的buffer数量，当buffer数量小于min值时，RP将主动创建buffer。

③max allowed

指定了free list中最多的buffer数量，当buffer数量达到max allowed值以上时，RP开始主动对buffer进行修剪。

注意：

①Buffer的总数受到permanent参数影响，min与max allowed影响的是freelist中的buffer数量。

②当inused buffer数量与free buffer数量之和并未超过permanent指定的buffer数时，即便free buffer数量超过了max allowed，这些buffers也不会被修剪——保证总数。

③当min值大于permanent指定的buffer总数时，RP会保证free buffer的数量至少达到min指定的buffer数量。此时buffer总数实际上直接受到min值的影响。

（3）第三行——buffer处理相关

①hits

当前pool收到buffer请求时，hits值累加。hits直观地反映了6个pools的利用情况。

②misses

当收到buffer请求，而pool中没有可用freebuffer时，misses累加。

③trims

当buffer被修剪时，trims累加。

④created

当RP创建buffer时，created累加。当收到buffer申请或free buffer数量少于min指定值时，buffer都有可能被创建。

（4）第四行——分配buffer失败相关

①failures

当没有free buffer又无法创建新的buffer时，failures累加。

RP此时将该packet移交给下一级pool。

②no memory

当由于memory空间不足而导致buffer创建失败时，此时no memory累加。

2.3.3 配置

（1）配置buffer参数

Router(config)#buffer small/middle…permanent/min-free/max-free/initial <num>

initial指的是设备刚启动时分配的临时buffer数量，之所以有这个参数，是因为设备刚启动时有建立大量控制层面会话的潜在可能，这种潜在的可能都是直接需要RP进行处理的。因此，在稳定运作之前，临时分配较大的buffer数量是合理的。

（2）如何清除buffer统计数据

目前，只能通过重启设备实现。

2.4 现象分析

以下为Cisco 2811的show version和show buffers输出：

（1）现象

从上图中可以看到，当期设备在7w0d时出现过buffer利用的高峰，并且出现了failures。

（2）流量类型判断

该设备为Cisco 2811，支持CEF并能实现硬件转发，且failures是从Small buffers开始。因此可以推断是由于control plane的流量过大而导致的buffers利用率偏高。

（3）进一步分析

buffers创建的峰值出现在7w0d时，而设备已运行了1 year，8weeks。现状态下，总共buffers 191，其中21个为free buffer；而达到峰值时，buffers数量为264，要高出现状态1.4倍。因此推断，这是由突发状况导致的（比如新启用协议、新开服务等）。

由于处理控制流量和创建buffer都依赖RP，因此，如果需要应对突发状况防止CPU利用率过高，建议的做法就是在memory中预留更多的Small buffers，牺牲内存来换保障CPU。

3.实验-Buffer不足导致的丢包

3.1 环境概述

（1）模拟环境

IOU-WEB1.2.2-23

（2）拓扑概述

①三台路由器如上图互联，运行EIGRP保证全网全通。

②R1、R2、R3的串口均使用mtu命令调整MTU值为最大值4072。

3.2 实验思路

（1）目标

通过修改中间转发的路由器R2的buffer值参数，模拟出R2由于buffer不足对实际流量的影响。

（2）使R2收到的packet尺寸尽可能大

由于某个pool中无法创建buffer时，packet是逐级向下提交的，应当尽可能保证R2收到的packet大小匹配buffer容量较高的pool——通过修改所有设备接口的MTU值到最大，可以防止由于IP分片导致的R2实际接收流量包大小过小的情况。

在模拟流量产生的设备R1、R3上，通过指定packet大小，使得生成的流量尺寸尽可能大（至少达到本地接口MTU）

（3）使R2对流量都经过RP转发

关闭CEF以及fast switching，防止R2接收到的流量不经过RP而被直接转发。

（4）使R2尽可能出现buffer短缺情况

调整R2的permanent buffer、minbuffer、max allowed buffer都为0。

3.3 关键步骤

（1）调整MTU

R2(config)#interfaces0/0

R2(config-if)#mtu4072

（2）关闭CEF及fastswitching

R2(config)#noip cef

R2(config)#interfaces0/0

R2(config-if)#noip route-cache

（3）调整buffer参数

R2(config)#buffersverybig permanent 0

R2(config)#buffersverybig min-free 0

R2(config)#buffersverybig max-free 0

R2(config)#bufferslarge permanent 0

R2(config)#bufferslarge min-free 0

R2(config)#bufferslarge max-free 0

R2(config)#buffershuge permanent 0

R2(config)#buffershuge min-free 0

R2(config)#buffershuge max-free 0

（4）R1与R3互ping

R1#ping31.31.23.3 repeat 1000000 size 18024

R3#ping31.31.12.1 repeat 100000 size 18024

3.4 实验现象

（1）R1&R3现象

（2）R2现象

可以看到从VeryBig buffers开始出现大量的failures，该failures一直延续到了Huge buffers，导致了最终丢包。

（3）R2开启CEF

R2(config)#ipcef

开启后R1、R3现象：

可以很明显地看到，开启CEF后，R1、R3上都不再丢包。

R2现象：

在开启CEF后，R2的VeryBigbuffer往下不再有hits、misses、failures的增加。

以上现象出现的原因是：开启CEF后，ICMP流量直接通过硬件转发而不再需要RP进行处理。