端口丢包原因解析与排查指南文档格式.docx
《端口丢包原因解析与排查指南文档格式.docx》由会员分享,可在线阅读,更多相关《端口丢包原因解析与排查指南文档格式.docx(35页珍藏版)》请在冰点文库上搜索。
ASIC:
部提供多种tables,如MAC地址表,VLAN表,MSTP表,链路聚合表,链路聚合流量平衡表,IPMC表(IP组播表),用于策略控制的FFP(FastFilterProcess)表等。
这些都是在MAC芯片部存贮,以CAM或TACM的方式寻址,硬件实现,完全满足数据包需要线速处理和转发的需要。
MMU:
memorymanagementunit,管理和存贮交换缓存单元,并暂存数据帧。
1.2数据包处理流程
以上图片中是最常见的数据处理逻辑。
所有的数据流通过交换芯片都要经过输入部分(Ingress)、存管理单元(MMU)和输出部分(Egress)这三个流程.其数据流程如上图。
Ingress(输入逻辑)是数据包在每端口上的逻辑流程.每端口都有自己的输入逻辑,输入逻辑负责所有包的转发(交换)策略,(例如进行MAC表查询、路由表查询、FFP过滤(ACL、QOS染色)等)决定将包送给哪个端口,根据转发信息将数据包发送给MMU,进行缓冲和调度,并以线速对包进行处理.输入逻辑与大部分交换功能关联。
MMU(存管理单元)主要负责数据包的缓冲与调度,它接收从输入逻辑过来的数据包并缓冲这些包,同时对这些包进行调度并将它们送给输出逻辑.数据包进入MMU时将存储在CBP里.CBP有1MB(不同芯片容量不一致)的大小供所有端口共用.MMU主要有四部分功能:
资源计数、背压、HOL预防机制、调度.其中资源计数主要是统计当前消耗的CBP单元数或CBP数据包个数,决定数据包什么时候进入背压或HOL预防;
调度则是根据优先级和COS的多种调度准则(也就是我们常见的QOS调度)来确定包发送的先后顺序和权重。
Egress(输出逻辑)主要从MMU获取数据包并将其送入各个端口,这是整个流程中最简单的一环.它先将包发给输出端口,然后确定是否在发送的数据包上添加tag.具体流程如下:
首先从MMU请求数据包,如果发送的包要求不带tag,则负责将tag去掉;
然后计算数据包的CRC;
最后将包交给MAC发送(特殊情况下,CMIC(CPU管理接口)将直接把数据包以DMA方式发送给CPU),基于端口的限速功能也在Egress阶段完成。
了解以上数据在芯片中的调度转发流程有助于我们理解数据在哪些地方可能会被丢弃。
1.3缓冲区
涉及到缓冲区的两个概念就是:
CBP和MMU
公共缓冲池CBPCBP实际上是1M共享的包缓冲区.本案例中以BCM5690为参考进行介绍。
CBP由8192(8K)个单元组成,每个单元128字节。
设备里的每个数据包消耗一至多个单元。
存管理单元MMU:
BCM5690有一个单独的存管理单元。
每个MMU与设备的功能块(GPIC、IPIC等)相关联。
GIGA接口控制器GPIC:
用于提供GE口与交换逻辑之间的接口。
联端口(HiGig)控制器IPIC:
主要提供HiGig口与部交换逻辑之间的接口,有时也被用于多片BCM5690之间的堆叠操作}
MMU负责数据包的缓冲和调度.它首先接收数据包,然后再将数据包缓冲,并在发送时加以调度,同时它还管理交换单元的流控特性.概括来说,就是缓冲逻辑、调度逻辑、流控逻辑.缓冲逻辑从CP-BUS(总线)接收包并存放在CBP,同样也从CBP获取包并将它们发送到CP-BUS(总线)上去。
包的发送顺序由调度逻辑根据包的优先级别确定。
流控逻辑包括Head-of-LineHOL阻塞预防和Backpressure两种方式.
缓冲区的大小由芯片决定,但缓冲区的分配方式可以进行调整。
例如每端口固定分配或动态共享。
BCM芯片系列一般采用平均分配的方式,因为考虑到Fair公平性的原则,这是一种比较理想的设计。
目前的设计采用了静态+动态共享的方式(静态分配一部分缓冲区+动态全局共享一部分,智能调整)
Mavell芯片系列可以进行人工调整,例如可以使用buffermanageFC|QOS来进行调整。
QOS模式可以共享缓冲区大小,并根据报文的COS优先传输高优先级的报文,低优先级的报文进行缓冲或给高优先级报文提供更多的缓冲空间,来不及缓冲的直接丢弃。
当采用FC模式时,平均分配缓冲区大小并通过发送Pause帧,要求对方减少发送速率,从而避免丢弃。
(当出现nobuffer丢包时,发送pause帧,需要两端开启Flowcontrol)。
1.4IBP与HOL
1.4.1IBP
IBP(ingressblackpressure)是一种关注每个Ingress入端口CBPBufffer率用率的方法,当缓冲率用率达到一定比率时,一个Pause帧就由Ingress口发出,如果对端支持流控,那么就会暂停一段时间,从而宏观上减少了发送速率,从而可以减小本机缓冲区的利用率,达到不丢包的目的。
1.4.2HOL
HOL(headofline队头阻塞)是一种关注每个Egress出端口Buffer利用率的方法,当利用率达到一定比率时,从CBPBuffer送到端口的TX队列的报文就会被丢弃。
出端口其实并没有物理上的缓冲区,只是做了一个出端口的队列(TransactionQueue,其实就是我们的COS队列),这个队列的指针指向CBP缓冲区。
队列根据端口的速率固定分配了长度,当报文在经历Ingress—MMU阶段中,会决定报文的某个Egess出接口,于是将TX队列尾指针指向CBP中此报文的缓冲区位置,HOL就是关注这个TransactionQueue的使用率,当在实际应用中,例如某个千兆口向百兆口快速发包就可能导致TX队列超出limit,那么后续需要将CBP报文写入TX队列的报文将会被丢弃,从而导致丢包,如果入接口开启了流控,HOL溢出也会在入接口发送Pause流控帧。
1.4.3IBP与HOL的联系
从上面IBP与HOL的描述,我们可以看出,IBP关注于:
入接口的缓冲区率用率情况。
HOL关注于:
出接口的队列使用情况(类似于缓冲区的率用率情况)。
两者的关联关系可以这样描述:
所以入丢包和出丢包时两个不同的阶段,HOL丢包,不一定回同时有IBP事件产生。
有IBP事件产生也不一定会导致HOL丢包,但有IBP存在的时候,HOL出现的几率更大。
因为某端口的入速率变大,那么往另外一个某出口的出速率也可能增大,导致HOL溢出丢包。
当入端口有限速(非QOS限速,即rate-limit)如果朝这个端口发包超过这个速率,也会导致此端口发送PAUSE流控帧,如果配置了出端口限速(即rate-limit),那么交换机转发到此端口的速率超出了限制,也会发生流控。
另外,广播包(组播、单播)限速(stormcontrol)和COS限速不会导致发生流控,而是直接丢弃。
那么我们如何判定是否有IBP的情况呢?
怎样又表明HOL存在溢出导致的丢包呢?
IBP导致的丢包,一般通过上层命令都可以查看到:
例如:
showinterfacesgigabitEthernet0/1结果:
Index(dec):
1(hex):
1
GigabitEthernet0/1isDOWN,lineprotocolisDOWN
HardwareismarvellGigabitEthernet
Description:
TO-ZGE-S8610-2_GE2/1
Interfaceaddressis:
noipaddress
MTU1500bytes,BW1000000Kbit
EncapsulationprotocolisBridge,loopbacknotset
Keepaliveintervalis10sec,set
Carrierdelayis2sec
RXloadis1,Txloadis1
Queueingstrategy:
WFQ
Switchportattributes:
interface'
sdescription:
"
TO-ZGE-S8610-2_GE2/1"
medium-typeiscopper
lastchangetime:
0Day:
0Hour:
45Minute:
26Second
Priorityis0
adminduplexmodeisAUTO,operduplexisUnknown
adminspeedisAUTO,operspeedisUnknown
flowcontroladminstatusisOFF,flowcontroloperstatusisUnknown
broadcastStormControlisON,multicastStormControlisOFF,unicastStormControlisON
5minutesinputrate0bits/sec,0packets/sec
5minutesoutputrate0bits/sec,0packets/sec
37167599packetsinput,2566418459bytes,45nobuffer,45dropped//丢包45个
Received58764broadcasts,0runts,0giants
0inputerrors,0CRC,0frame,0overrun,0abort
37210638packetsoutput,2565322398bytes,0underruns,0dropped
0outputerrors,0collisions,0interfaceresets
showinterfacesgigabitEthernet0/1counters
InOctets:
2566418459
InUcastPkts:
88649
InMulticastPkts:
37020186
InBroadcastPkts:
58764
OutOctets:
2565322398
OutUcastPkts:
1238
OutMulticastPkts:
37161052
OutBroadcastPkts:
48348
Undersizepackets:
0
Oversizepackets:
collisions:
Fragments:
Jabbers:
CRCalignmenterrors:
AlignmentErrors:
FCSErrors:
droppedpacketevents(duetolackofresources):
45//丢包45个,由于CBP不足导致
packetsreceivedoflength(inoctets):
64:
70436041
HOL的丢包,一般需要在设备底层通过读取相关寄存器获取。
底层有HOL丢包在原来的版本中,showInterfacecounters的时候也有显示,但客户对drop计数会有不少抱怨,其实HOL溢出一般都是由于多端口向某端口发包速率太快所致,是由于环境原因引起的。
所以在后来的版本中,我们将HOL的计数都放在底层显示了,如有流控机制会自动进行调整改善。
S26-Test(sd)#shshowcou
RUC.ge4:
628,352+130,128519/s
RDBGC0.ge4:
877,970+180,898700/s
RDBGC1.ge4:
148,092+29,930150/s
GRMCA.ge4:
159,845+32,535156/s
GRBCA.ge4:
280,791+57,243207/s
GR64.ge4:
785+96
GR127.ge4:
904,990+186,772721/s
GR255.ge4:
9,873+2,0257/s
GR511.ge4:
1,692+3602/s
GR1023.ge4:
26,045+5,33625/s
GR1518.ge4:
2,946+5762/s
GRMGV.ge4:
122,657+24,741125/s
GR2047.ge4:
GRPKT.ge4:
1,068,988+219,906882/s
GRBYT.ge4:
273,630,102+55,501,231261,676/s
GRUC.ge4:
GRPOK.ge4:
GTMCA.ge4:
60+9
GTBCA.ge4:
128+1
GT127.ge4:
1,555+3612/s
GT255.ge4:
155+18
GT511.ge4:
69+5
GT1023.ge4:
448+2
GT1518.ge4:
24+1
GTPKT.ge4:
2,259+3872/s
GTBYT.ge4:
555,542+34,097137/s
GTUC.ge4:
2,071+3772/s
GTPOK.ge4:
RUC.fe1:
RDBGC1.fe1:
65+9
HOLD.fe1:
5,604+1,97515/s第一列是累计值,第二列是从上次show至今的累计值,第三列是每秒丢丢包个数。
BCM芯片一般Fe0代表第一个接口即fe1,hold.fe1代表第二个接口。
2端口丢包常见原因及处理办法
2.1端口计数器的说明
通过查看端口的计数器,我们可以知道端口的收发包统计状况。
端口counter输出:
Switch#showintfastEthernet0/1counters
Interface:
Fa0/1
5minuteinputrate:
0bits/sec,0packets/sec//5分钟的平均速率
5minuteoutputrate:
0bits/sec,0packets/sec
68023600进入的包总数
92842单播包
36700组播包
75636广播包
3630373出去的总包数
32053单播包
1059组播包
13231广播包
[1]Undersizepackets:
[2]Oversizepackets:
[3]collisions:
[4]Fragments:
[5]Jabbers:
[6]CRCalignmenterrors:
[7]AlignmentErrors:
[8]FCSErrors:
[9]droppedpacketevents(duetolackofresources):
[10]packetsreceivedoflength(inoctets):
64:
119136,65-127:
75769,128-255:
12663,
256-511:
3149,512-1023:
1955,1024-1518:
38849
[1]长度小于64字节,校验和正确的报文:
和Fragment帧对应,区别在于校验和。
[2]帧超长且校验和正确的报文:
和Jabber帧对应,区别在于校验和。
[3]冲突帧:
多站点同时试图发送信息导致冲突,单双工遇到较多。
[4]长度小于64字节,校验和错误的报文:
和Undersize帧对应,区别在于校验和。
[5]帧超长且校验和错误的报文:
和Oversize帧对应,区别在于校验和。
[6]非超常帧且校验和错误的报文:
和FCS相同,CRC是发送方本地进行校验,对端收到后重新进行计算,然后比对FCS字段。
[7]接收的帧有重组错误:
没有通过帧校验且没有边界字节结束(非整字节)的帧,bit丢失。
[8]帧的容改变或者丢失:
帧校验FCS错误
[9]丢弃报文统计:
总和
[10]根据长度统计接收的报文
以上原因基本都是由于网卡、端口、线路故障或接触不良导致的。
可以先进行链路、端口的替换测试。
对于以上容需要了解更深入的,可以在线搜索相关详细解释。
端口输出:
switch#showinterfacesgigabitEthernet2/1
Index(dec):
GigabitEthernet2/1isUP,lineprotocolisUP
HardwareisBroadcom5464GigabitEthernet//phy型号
MTU1500bytes,BW1000000Kbit//MTU带宽
Keepaliveintervalis10sec,set链路脉冲
Carrierdelayis2sec载波延时,口链路的载波检测信号DCD从Down状态到Up状态的时间延时,如果DCD在延时之发生变化,那么系统将忽略这种的状态的变化而不至于上层的数据链路层重新协商
RXloadis1,Txloadis1//接口负载利用率1/255,每5分钟统计。
FIFO//这些都是给路由器用的,交换机不应该show这些信息,目前在新版本10.4(2b2)中已经不显示了。
Outputqueue0/0,0drops;
Inputqueue0/75,0drops
5Day:
7Hour:
47Minute:
40Second//接口自系统启动后发生link变化的相对时间,可以结合showver查看系统的启动时间,判断端口上次发生up/down的时间。
adminduplexmodeisAUTO配置的双工为auto,operduplexisFull//实际的双工状态
adminspeedisAUTO,operspeedis1000M配置与实际的速率
flowcontroladminstatusisOFF,flowcontroloperstatusisOFF流控
broadcastStormControlisOFF,multicastStormControlisOFF,unicastStormControlisOFF
5minutesinputrate0bits/sec,0packets/sec5分钟平均值
5minutesoutputrate20523bits/sec,9packets/sec5分钟平均值
42388309packetsinput,2917143960bytes,0nobuffer,0dropped
重点关注nobuffer和droped统计,nobuffer就是由于缓冲区不足。
Received76899broadcasts,0runts,1giants
69858478packetsoutput,6534138835bytes,0underruns,116dropped
重点关注droped统计
ZGE-S8610-1#
虽然是5分钟的平均值,但实际上是5秒钟更新一次,软件模块会5秒钟读取相关MIB并计算最近5分钟的数据然后进行更新。
大家一般对input以及output方向的drop代表什么含义非常感兴趣,这里就和大家一起来分析一下。
端口的计数,我们实现都是根据RFC来进行定义的:
InputdropRFC1213的定义如下:
ifInDiscardsOBJECT-TYPE
SYNTAXCounter
ACCESSread-only
STATUSmandatory
DESCRIPTION
"
Thenumberofinboundpacketswhichwerechosen
tobediscardedeventhoughnoerrorshadbeen
detectedtopreventtheirbeingdeliverabletoa
higher-layerprotocol.Onepossiblereasonfor
discardingsuchapacketcouldbetofreeup
bufferspace."
:
:
={ifEntry13}
这个值仅表示接口下资源不足导致的丢包统计,资源不足主要是对端发包太快或HOL原因导致的入缓冲溢出引起的。
(HOL是出方向对头阻塞,但出方向对头阻塞的同时,可能会引起入缓冲溢出。
)
OutputdropRFC1213定义如下:
ifOutDiscardsOBJECT-TYPE
SYNTAX