(1)Process Switching
基于进程的转发,数据流量的处理需要依赖RP(Routing Processor)。
(2)Fast Switching
类似于MLS技术,数据流量在第一次被转发时,是基于进程的转发方式,需要依赖RP。
在第一次转发时,建立起转发缓存,之后处理相关数据流量时,直接查询缓存项转发,而不用依赖RP。
(3)CEF
直接根据RIB、ARP转发表等信息,构建起FIB以及Adjacency Table,不用依赖RP。
对于需要RP处理的数据,其转发过程这里进行大致介绍。
①Ingress Traffic
某个端口收到入站流量,该流量需要交给RP处理。
②Ask for buffer
InterfaceProcessor向RP发出请求,申请一块ProcessorMemory中的buffer,以待RP处理。
③Response
RP根据Processor Memory的实际情况进行回复。
如有buffer可容纳该待发packet,则其将被发送至Processor Memory的buffer中;否则则会产生丢包。
在Cisco路由器中,Processor Memory被划分为了6种不同尺寸的pools,每种pool中包含相同大小的blocks,这些blocks即被称为buffers。
①Small buffer――104 bytes
②Middle buffer――600 bytes
③Big buffer――1536 bytes
④VeryBig buffer――4520 bytes
⑤Large buffer――5024 bytes
⑥Huge buffer――18024 bytes
一个pool中可能存在如下情况:
(1)已分配空间
已分配空间中,是已经被创建的、占据了memory的buffers。这些buffers可能正有packet待处理,也有可能正等待packet进驻。
(2)未分配空间
未分配空间指的是,该部分空间没有buffer,当需要创建buffer时,可从中划分出buffer以供packet使用。
注意:
①Pool中所能创建的buffers总量是有限定的,该限定可能来自于memory本身的容量,也可能来自于管理员的指定。
②Buffer是按需创建而非固定充满于pool中的,因此pool没有固定的大小。
③Pool的类型决定了其中buffer的尺寸。
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 |
(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,并不意味着丢包。
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累加。
(1)配置buffer参数
Router(config)#buffer small/middle…permanent/min-free/max-free/initial <num>
initial指的是设备刚启动时分配的临时buffer数量,之所以有这个参数,是因为设备刚启动时有建立大量控制层面会话的潜在可能,这种潜在的可能都是直接需要RP进行处理的。因此,在稳定运作之前,临时分配较大的buffer数量是合理的。
(2)如何清除buffer统计数据
目前,只能通过重启设备实现。
以下为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。
(1)模拟环境
IOU-WEB1.2.2-23
(2)拓扑概述
①三台路由器如上图互联,运行EIGRP保证全网全通。
②R1、R2、R3的串口均使用mtu命令调整MTU值为最大值4072。
(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。
(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
(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进行处理。