首页 > 代码库 > 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处理的数据,其转发过程这里进行大致介绍。

wKiom1Qo2qmzn-LGAADwZ__pWsI674.jpg

       ①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


wKioL1Qo23HQSdCNAAFOc7lOVs0664.jpg

       在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的关系

wKiom1Qo29Tic26fAAB-z7xxD0g830.jpg

       一个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类型
<104Small buffer
104~600Middle buffer
600~1536Big buffer
1536~4520VeryBig buffer
4520~5024Large buffer
5024~18024Huge 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示例:

wKiom1Qo3VORirYyAAORyreXma0352.jpg

       从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输出:

wKioL1Qo3lOg6Mp6AAGjHkpCdJE421.jpg


wKiom1Qo3juQUC2jAAIUnm0lSVE333.jpg

       (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 环境概述


wKiom1Qo3q2zjw_fAAD7QeIUn9c382.jpg

       (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现象

wKiom1Qo32_xnKfIAAFrdg1JF9k554.jpg


wKiom1Qo333QvlB7AAIIaicrmYQ770.jpg

       (2)R2现象

wKiom1Qo35GSHuPrAANo5WRTi2E116.jpg

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

       (3)R2开启CEF

            R2(config)#ipcef

            开启后R1、R3现象:

wKioL1Qo3_HBmjf7AAK8YHbCrHU966.jpg


wKioL1Qo3__CBNC9AANw591N1vA466.jpg

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

            R2现象:

wKiom1Qo3__ip5VPAANpDoMIuOo057.jpg

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

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


本文出自 “Thely” 博客,请务必保留此出处http://thely.blog.51cto.com/2695427/1559343

Process memory buffer分配机制——show buffers相关