首页 > 代码库 > Process memory buffer分配机制——show buffers相关
Process memory buffer分配机制——show buffers相关
思科设备巡检过程中，往往要求工程师注意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。
| Packet尺寸（单位bytes） | 申请的buffer类型 |
| <104 | Small buffer |
| 104~600 | Middle buffer |
| 600~1536 | Big buffer |
| 1536~4520 | VeryBig buffer |
| 4520~5024 | Large buffer |
| 5024~18024 | Huge 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进行处理。
本文出自 “Thely” 博客，请务必保留此出处http://thely.blog.51cto.com/2695427/1559343
Process memory buffer分配机制——show buffers相关