首页 端口丢包原因解析与排查指南

端口丢包原因解析与排查指南

举报
开通vip

端口丢包原因解析与排查指南 密级:受控 维护与故障排查 mi文件类型:故障类 版本号:V1.0(28/09/08) 文档作者:王雁 文档密级:受控(和页面一致) 内审人: 使用对象:一线工程师 端口丢包原因解析及排查指南2010-9-28福建星网锐捷网络有限公司 版权所有侵权必究 修订记录 日期 修订说明 执行人 2010-9-28 第一次发布 王雁 目录1 数据包处理流程说明 41.1 交换机芯片结构 41.2 数据包处理流程 51.3 缓冲区 61.4 IBP与HOL 71.4.1 IBP 71.4.2 HO...

端口丢包原因解析与排查指南
密级:受控 维护与故障排查 mi文件类型:故障类 版本号:V1.0(28/09/08) 文档作者:王雁 文档密级:受控(和页面一致) 内审人: 使用对象:一线工程师 端口丢包原因解析及排查指南2010-9-28福建星网锐捷网络有限公司 版权所有侵权必究 修订 记录 混凝土 养护记录下载土方回填监理旁站记录免费下载集备记录下载集备记录下载集备记录下载 日期 修订 说明 关于失联党员情况说明岗位说明总经理岗位说明书会计岗位说明书行政主管岗位说明书 执行人 2010-9-28 第一次发布 王雁 目录1 数据包处理流程说明 41.1 交换机芯片结构 41.2 数据包处理流程 51.3 缓冲区 61.4 IBP与HOL 71.4.1 IBP 71.4.2 HOL 71.4.3 IBP与HOL的联系 82 端口丢包常见原因及处理办法 122.1 端口计数器的说明 122.2 底层常见计数器说明 142.3 端口丢包常见原因 172.4 端口丢包和转发丢包的联系与区别 173 端口丢包故障处理案例 203.1 S86端口下出现output方向的drop计数 203.2 S26开启组播,组播画面出现马赛克 244 常见FAQ 314.1 Storm-control控制的报文方向 314.2 QOS限速导致的端口丢包是否会在showinterfacegixx显示? 314.3 生成树block的端口,output方向是否有丢弃包的计数? 31数据包处理流程说明交换机芯片结构交换芯片是交换机的灵魂,交换芯片注定了交换机的数据转发性能及部分功能。例如不同型号产品的芯片型号便有所不同,但芯片的总体逻辑架构基本都如下图所示,模块化的交换机也基本都是多线卡组合起来的,实质就是单芯片通过Hi-Gig口连接到背板形成星型结构,由引擎来进行集中管理和控制功能。说明:强烈推荐大家阅读此篇文档,加深对交换机硬件的理解。《千兆位以太网交换芯片BCM5690及其在交换机中的应用》http://www.360doc.com/content/08/0824/22/494_1572961.shtml#名词解释:ASIC(MAC芯片):为所有端口提供线速交换,ASIC:内部提供多种tables,如MAC地址表,VLAN表,MSTP表,链路聚合表,链路聚合流量平衡表,IPMC表(IP组播表),用于策略控制的FFP(FastFilterProcess)表等。这些都是在MAC芯片内部存贮,以CAM或TACM的方式寻址,硬件实现,完全满足数据包需要线速处理和转发的需要。MMU:memorymanagementunit,管理和存贮交换缓存单元,并暂存数据帧。数据包处理流程以上图片中是最常见的数据处理逻辑。所有的数据流通过交换芯片都要经过输入部分(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阶段完成。了解以上数据在芯片中的调度转发流程有助于我们理解数据在哪些地方可能会被丢弃。缓冲区涉及到缓冲区的两个概念就是:CBP和MMU公共缓冲池CBPCBP实际上是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-LineHOL阻塞预防和Backpressure两种方式.缓冲区的大小由芯片决定,但缓冲区的分配方式可以进行调整。例如每端口固定分配或动态共享。BCM芯片系列一般采用平均分配的方式,因为考虑到Fair公平性的原则,这是一种比较理想的 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 。目前的设计采用了静态+动态共享的方式(静态分配一部分缓冲区+动态全局共享一部分,智能调整)Mavell芯片系列可以进行人工调整,例如可以使用buffermanageFC|QOS来进行调整。QOS模式可以共享缓冲区大小,并根据报文的COS优先传输高优先级的报文,低优先级的报文进行缓冲或给高优先级报文提供更多的缓冲空间,来不及缓冲的直接丢弃。当采用FC模式时,平均分配缓冲区大小并通过发送Pause帧,要求对方减少发送速率,从而避免丢弃。(当出现nobuffer丢包时,发送pause帧,需要两端开启Flowcontrol)。IBP与HOLIBPIBP(ingressblackpressure)是一种关注每个Ingress入端口CBPBufffer率用率的 方法 快递客服问题件处理详细方法山木方法pdf计算方法pdf华与华方法下载八字理论方法下载 ,当缓冲率用率达到一定比率时,一个Pause帧就由Ingress口发出,如果对端支持流控,那么就会暂停一段时间,从而宏观上减少了发送速率,从而可以减小本机缓冲区的利用率,达到不丢包的目的。HOLHOL(headofline队头阻塞)是一种关注每个Egress出端口Buffer利用率的方法,当利用率达到一定比率时,从CBPBuffer送到端口的TX队列的报文就会被丢弃。出端口其实并没有物理上的缓冲区,只是做了一个出端口的队列(TransactionQueue,其实就是我们的COS队列),这个队列的指针指向CBP缓冲区。队列根据端口的速率固定分配了长度,当报文在经历Ingress—MMU阶段中,会决定报文的某个Egess出接口,于是将TX队列尾指针指向CBP中此报文的缓冲区位置,HOL就是关注这个TransactionQueue的使用率,当在实际应用中,例如某个千兆口向百兆口快速发包就可能导致TX队列超出limit,那么后续需要将CBP报文写入TX队列的报文将会被丢弃,从而导致丢包,如果入接口开启了流控,HOL溢出也会在入接口发送Pause流控帧。IBP与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):1GigabitEthernet0/1isDOWN,lineprotocolisDOWNHardwareismarvellGigabitEthernetDescription:TO-ZGE-S8610-2_GE2/1Interfaceaddressis:noipaddressMTU1500bytes,BW1000000KbitEncapsulationprotocolisBridge,loopbacknotsetKeepaliveintervalis10sec,setCarrierdelayis2secRXloadis1,Txloadis1Queueingstrategy:WFQSwitchportattributes:interface'sdescription:"TO-ZGE-S8610-2_GE2/1"medium-typeiscopperlastchangetime:0Day:0Hour:45Minute:26SecondPriorityis0adminduplexmodeisAUTO,operduplexisUnknownadminspeedisAUTO,operspeedisUnknownflowcontroladminstatusisOFF,flowcontroloperstatusisUnknownbroadcastStormControlisON,multicastStormControlisOFF,unicastStormControlisON5minutesinputrate0bits/sec,0packets/sec5minutesoutputrate0bits/sec,0packets/sec37167599packetsinput,2566418459bytes,45nobuffer,45dropped//丢包45个Received58764broadcasts,0runts,0giants0inputerrors,0CRC,0frame,0overrun,0abort37210638packetsoutput,2565322398bytes,0underruns,0dropped0outputerrors,0collisions,0interfaceresetsshowinterfacesgigabitEthernet0/1countersInOctets:2566418459InUcastPkts:88649InMulticastPkts:37020186InBroadcastPkts:58764OutOctets:2565322398OutUcastPkts:1238OutMulticastPkts:37161052OutBroadcastPkts:48348Undersizepackets:0Oversizepackets:0collisions:0Fragments:0Jabbers:0CRCalignmenterrors:0AlignmentErrors:0FCSErrors:0droppedpacketevents(duetolackofresources):45//丢包45个,由于CBP不足导致packetsreceivedoflength(inoctets):64:70436041HOL的丢包,一般需要在设备底层通过读取相关寄存器获取。底层有HOL丢包在原来的版本中,showInterfacecounters的时候也有显示,但客户对drop计数会有不少抱怨,其实HOL溢出一般都是由于多端口向某端口发包速率太快所致,是由于环境原因引起的。所以在后来的版本中,我们将HOL的计数都放在底层显示了,如有流控机制会自动进行调整改善。例如:S26-Test(sd)#shshowcouRUC.ge4:628,352+130,128519/sRDBGC0.ge4:877,970+180,898700/sRDBGC1.ge4:148,092+29,930150/sGRMCA.ge4:159,845+32,535156/sGRBCA.ge4:280,791+57,243207/sGR64.ge4:785+96GR127.ge4:904,990+186,772721/sGR255.ge4:9,873+2,0257/sGR511.ge4:1,692+3602/sGR1023.ge4:26,045+5,33625/sGR1518.ge4:2,946+5762/sGRMGV.ge4:122,657+24,741125/sGR2047.ge4:122,657+24,741125/sGRPKT.ge4:1,068,988+219,906882/sGRBYT.ge4:273,630,102+55,501,231261,676/sGRUC.ge4:628,352+130,128519/sGRPOK.ge4:1,068,988+219,906882/sGTMCA.ge4:60+9GTBCA.ge4:128+1GT127.ge4:1,555+3612/sGT255.ge4:155+18GT511.ge4:69+5GT1023.ge4:448+2GT1518.ge4:24+1GTPKT.ge4:2,259+3872/sGTBYT.ge4:555,542+34,097137/sGTUC.ge4:2,071+3772/sGTPOK.ge4:2,259+3872/sRUC.fe1:2,071+3772/sRDBGC1.fe1:65+9HOLD.fe1:5,604+1,97515/s第一列是累计值,第二列是从上次show至今的累计值,第三列是每秒丢丢包个数。BCM芯片一般Fe0代表第一个接口即fe1,hold.fe1代表第二个接口。端口丢包常见原因及处理办法端口计数器的说明通过查看端口的计数器,我们可以知道端口的收发包统计状况。端口counter输出:Switch#showintfastEthernet0/1countersInterface:Fa0/15minuteinputrate:0bits/sec,0packets/sec//5分钟的平均速率5minuteoutputrate:0bits/sec,0packets/secInOctets:68023600进入的包总数InUcastPkts:92842单播包InMulticastPkts:36700组播包InBroadcastPkts:75636广播包OutOctets:3630373出去的总包数OutUcastPkts:32053单播包OutMulticastPkts:1059组播包OutBroadcastPkts:13231广播包[1]Undersizepackets:0[2]Oversizepackets:0[3]collisions:0[4]Fragments:0[5]Jabbers:0[6]CRCalignmenterrors:0[7]AlignmentErrors:0[8]FCSErrors:0[9]droppedpacketevents(duetolackofresources):0[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/1Index(dec):1(hex):1GigabitEthernet2/1isUP,lineprotocolisUPHardwareisBroadcom5464GigabitEthernet//phy型号Interfaceaddressis:noipaddressMTU1500bytes,BW1000000Kbit//MTU带宽EncapsulationprotocolisBridge,loopbacknotsetKeepaliveintervalis10sec,set链路脉冲Carrierdelayis2sec载波延时,口链路的载波检测信号DCD从Down状态到Up状态的时间延时,如果DCD在延时之内发生变化,那么系统将忽略这种的状态的变化而不至于上层的数据链路层重新协商RXloadis1,Txloadis1//接口负载利用率1/255,每5分钟统计。Queueingstrategy:FIFO//这些都是给路由器用的,交换机不应该show这些信息,目前在新版本10.4(2b2)中已经不显示了。Outputqueue0/0,0drops;Inputqueue0/75,0dropsSwitchportattributes:interface'sdescription:""medium-typeiscopperlastchangetime:5Day:7Hour:47Minute:40Second//接口自系统启动后发生link变化的相对时间,可以结合showver查看系统的启动时间,判断端口上次发生up/down的时间。Priorityis0adminduplexmodeisAUTO配置的双工为auto,operduplexisFull//实际的双工状态adminspeedisAUTO,operspeedis1000M配置与实际的速率flowcontroladminstatusisOFF,flowcontroloperstatusisOFF流控broadcastStormControlisOFF,multicastStormControlisOFF,unicastStormControlisOFF5minutesinputrate0bits/sec,0packets/sec5分钟平均值5minutesoutputrate20523bits/sec,9packets/sec5分钟平均值42388309packetsinput,2917143960bytes,0nobuffer,0dropped重点关注nobuffer和droped统计,nobuffer就是由于缓冲区不足。Received76899broadcasts,0runts,1giants0inputerrors,0CRC,0frame,0overrun,0abort69858478packetsoutput,6534138835bytes,0underruns,116dropped重点关注droped统计0outputerrors,0collisions,0interfaceresetsZGE-S8610-1#虽然是5分钟的平均值,但实际上是5秒钟更新一次,软件模块会5秒钟读取相关MIB并计算最近5分钟的数据然后进行更新。大家一般对input以及output方向的drop代表什么含义非常感兴趣,这里就和大家一起来分析一下。端口的计数,我们实现都是根据RFC来进行定义的:InputdropRFC1213的定义如下:ifInDiscardsOBJECT-TYPESYNTAXCounterACCESSread-onlySTATUSmandatoryDESCRIPTION"Thenumberofinboundpacketswhichwerechosentobediscardedeventhoughnoerrorshadbeendetectedtopreventtheirbeingdeliverabletoahigher-layerprotocol.Onepossiblereasonfordiscardingsuchapacketcouldbetofreeupbufferspace."::={ifEntry13}这个值仅表示接口下资源不足导致的丢包统计,资源不足主要是对端发包太快或HOL原因导致的入缓冲溢出引起的。(HOL是出方向对头阻塞,但出方向对头阻塞的同时,可能会引起入缓冲溢出。)OutputdropRFC1213定义如下:ifOutDiscardsOBJECT-TYPESYNTAXCounterACCESSread-onlySTATUSmandatoryDESCRIPTION"Thenumberofoutboundpacketswhichwerechosentobediscardedeventhoughnoerrorshadbeendetectedtopreventtheirbeingtransmitted.Onepossiblereasonfordiscardingsuchapacketcouldbetofreeupbufferspace."::={ifEntry19}这个值可以表示任何原因导致的出口丢包统计,所以描述不是特别详细,目前我们也是根据RFC定义的出口丢帧的原因以及产品芯片定义的一些出口丢帧的原因,出方向的Drop原因种类很多,总结包括如下可能:报文老化(因为出口HOL等原因,导致报文在出口队列中待太久没有被调度到)VLAN出口检查错误,接口不属于要转发报文的vlan(极少见到)还有一些属于应用策略丢弃的,比如需要用出口转换表,结果报文在该表中无法查找到导致报文被丢弃的(如PVLAN的一些应用),还例如STP的端口BLOCK。报文超过MTU长度的,出口MTU检查超出了MTU限制。所以仅从表面无法能够知晓Drop丢包的原因,通常情况下这种丢包也不会对网络正常使用造成影响,从目前已有的故障案例中,排除例如端口阻塞的正常原因,基本都是环境因素导致的MMU资源不足。遇到此类问 快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题 时,需要参考2.3的方法进行详细的信息收集来综合判断。底层常见计数器说明底层的寄存器计数非常真实的反映了芯片实时或累计的相关数据,具有非常好的参考意义,上层的所有数据统计其实都来源于底层的数据。底层丢包我们重点关注有无HOLD溢出,并关注其累计值,实时值。其他数据仅作为参考网络环境中的报文流情况。 字段 说明 第一列 各个端口的各种计数器 第二列 计数器累计值 第三列 从上次执行showcounters到当前,计数器的该变量 第四列 每秒速率进入底层后Showcounterall可以查看到所有的寄存器的值,showc只显示字段有变化的值,通常我们showc就可以了。RIPHE4.ge21:0+0IMRP4.ge21:0+0RIPD6.ge21:0+0RIPC6.ge21:0+0RIPHE6.ge21:0+0IMRP6.ge21:0+0RDISC.ge21:0+0RUC.ge21:0+0收到的单播包RPORTD.ge21:0+0RDBGC0.ge21:0+0RDBGC1.ge21:0+0RDBGC2.ge21:0+0RDBGC3.ge21:0+0RDBGC4.ge21:0+0RDBGC5.ge21:0+0RDBGC6.ge21:0+0RDBGC7.ge21:0+0RDBGC8.ge21:0+0HOLD.ge21:0+0HOL对头拥塞丢帧计数TDBGC0.ge21:0+0TDBGC1.ge21:0+0TDBGC2.ge21:0+0TDBGC3.ge21:0+0TDBGC4.ge21:0+0TDBGC5.ge21:0+0TDBGC6.ge21:0+0TDBGC7.ge21:0+0TDBGC8.ge21:0+0TDBGC9.ge21:0+0TDBGC10.ge21:0+0TDBGC11.ge21:0+0TPCE.ge21:0+0GR64.ge21:0+0收到的报文字节大小64GR127.ge21:0+0收到的报文字节大小65-127GR255.ge21:0+0收到的报文字节大小128-255GR511.ge21:0+0收到的报文字节大小256-511GR1023.ge21:0+0收到的报文字节大小512-1023GR1518.ge21:0+0收到的报文字节大小1024-1518GRMGV.ge21:0+0收到的1519-1522带tag的报文GR2047.ge21:0+0收到的报文字节大小1519-2047GR4095.ge21:0+0GR9216.ge21:0+0GRPKT.ge21:0+0收到的报文数GRBYT.ge21:0+0收到的字节数GRMCA.ge21:0+0收到的组播报文GRBCA.ge21:0+0收到的广播报文GRFCS.ge21:0+0FCSerror帧统计GRXCF.ge21:0+0收到的控制帧统计(例如流控协商)GRXPF.ge21:0+0收到的pause帧统计GRXUO.ge21:0+0不支持的opcaode控制帧GRALN.ge21:0+0Alignmenterror帧GRFLR.ge21:0+0长度不符的异常帧,相见参考表GRCDE.ge21:0+0CodeerrorGRFCR.ge21:0+0收到的载波计数GROVR.ge21:0+0oversize帧统计GRJBR.ge21:0+0Jabber统计GRMTUE.ge21:0+0MTU检查失败统计RRPKT.ge21:0+0runt帧统计GRUND.ge21:0+0undersize帧统计GRFRG.ge21:0+0fragment帧统计RRBYT.ge21:0+0runts字节数统计GT64.ge21:0+0GT发送GT127.ge21:0+0GT255.ge21:0+0GT511.ge21:0+0GT1023.ge21:0+0GT1518.ge21:0+0GTMGV.ge21:0+0GT2047.ge21:0+0GT4095.ge21:0+0GT9216.ge21:0+0GTPKT.ge21:0+0GTMCA.ge21:0+0GTBCA.ge21:0+0GTXPF.ge21:0+0GTJBR.ge21:0+0GTFCS.ge21:0+0GTXCF.ge21:0+0GTOVR.ge21:0+0GTDFR.ge21:0+0GTEDF.ge21:0+0GTSCL.ge21:0+0GTMCL.ge21:0+0GTLCL.ge21:0+0GTXCL.ge21:0+0GTFRG.ge21:0+0GTNCL.ge21:0+0GTBYT.ge21:0+0详细解释参考如下文档:端口丢包常见原因及信息收集导致端口丢包的原因总结起来包括如下几种可能性:1.由于某些接口、链路、双工异常导致的CRC错误、Algiment帧bit丢失等常见错误,此类报文交换机将予以丢弃-------查看端口计数,是否由较多CRC、冲突帧等。2.QOS限速、Rate-limit配置导致的数据包正常丢弃。(不计入端口统计计数)3.端口BLOCK(STP、RLDP)导致的数据包正常丢弃。(计入端口统计计数)--查看端口生成树状态4.对端设备发送的速率过快导致本端交换机buffer不足,而又没有流控导致的丢包—尝试两端打开流控,观察。5.多端口向一个端口发送报文,超出这个端口的转发能力,导致的HOL队头阻塞丢包。--尝试调整端口速率和打开流控,观察。6.由于环境因素(例如异常帧较多),导致MMU资源溢出(参见故障处理案例1)。---前文讲到此类故障导致的原因很多,此类故障多需要底层计数信息,进行详细分析判断。参考下面的信息收集方法。其中最常见的4/5两种类型的溢出,通过查看端口的计数器定位受影响的端口并打开两端的流控一般都能解决问题。从目前实际遇到的案例来看,也基本都是由于以上两种原因导致的丢包故障。如仍无法解决,请收集上层计数与底层计数信息提供后台分析判断。注意:收集上下层信息的同时,注意收集信息的充分性,多次收集的上层信息必须有发现drop计数的递增,这几次收集间隔中底层的信息都必须相应收集到。上层信息:showinterface(多次获取) showinterfacexxcounter(多次获取,需要捕捉到drop的计数或其他异常计数的变化)showinterfacestatusshowmac-address-table底层信息:sd(进入sd调试界面)suxx(参考各产品SD手册)consoleonps(查看端口工作状态)showc(查看端口计数,多次获取)getegrdroppktcount(查看端口出口丢包计数及相关寄存器)//5750,26产品支持此命令l2showdumpport(查看端口相关属性,可选)consoleoffdexit端口丢包和转发丢包的联系与区别我们常见的丢包一种是比较明显的某端口存在丢包,另外较为常见的是转发不通或转发丢包。转发丢包又分二层转发丢包和三层转发丢包。二层转发是基于VID+MAC的转发,所以不仅端口存在丢包会导致二层转发丢包,还包括其他较多复杂因素导致的丢包,总结起来有如下几种原因:(1)端口双工、速率、流控等导致的双工不匹配、缓存不足导致的丢包。----------通过查看接口的工作状态,查看端口计数和底层ps(查看端口工作状态、showc查看端口计数)来确定是否存在端口丢包。(2)端口接触不良或频繁震荡导致数据无法被转发导致的丢包--------通过查看日志或更换端口进行对比测试(3)链路存在问题导致CRC、Jabber等的丢包------通过查看端口计数确认并更换链路进行测试(4)端口STP逻辑状态的频繁变化,导致的数据转发中断。-----通过查看日志和showspanning-tree查看生成树的统计情况或打开debug开关进行查看。(5)端口限速导致的正常丢包----查看QOS配置或调整限速大小进行对比测试(6)MAC表或VLAN表或安全表(FFP)导致的转发不通。---通过收集上层及底层的L2、VLAN、端口、FFP表进行确认对比。也可以调整相关安全功能进行打开或关闭。二层转发丢包的关键是必须提前确定丢包是在哪里产生的,可以通过分段测试法,充分利用镜像捉包的功能。二层转发的终极手段是清空设备配置,保留最单纯的环境,进行转发测试,如有仍然有丢包等情况,经底层showc查看后,一般为硬件故障。三层转发丢包三层转发丢包由于涉及到查找路由和打通路由(ARP)的过程,所以除了刚才二层转发丢包的可能性原因以外,还新增了如下几种可能的原因:(1)路由频繁震荡(例如动态路由频繁震荡、路由频繁发生切换或底层路由溢出)-------可以查看相关日志,并收集路由表项(上层与底层表项),或尝试静态制定相关表项。(2)ARP表频繁发生变化,需要重现打通(例如Tcchange导致的三层设备清除ARP地址表)-------可以查看相关STP日志并优化配置或打印相关debug日志,也可以尝试静态绑定相关表项。(3)安全过滤,例如ACL、URPF等某些安全策略将部分报文过滤导致的丢包-----------可从配置上、log上进行相关分析及查看。排查三层转发故障的时候第一要求也是必须确定丢包点在哪个地方,然后根据如上的可能性进行逐一排查。举个例子:我们通常ping某个目的地址的时候,都会发现ping5个包,会丢包一个包,原因就是由于第一个包由于目标机器没有源主机的ARP,ARP打通的时间超过ICMPtimeout2s的原因。三层转发故障定位到单台箱式设备时,当排除了环境因素或功能模块导致的问题后,可能由于内部数据通道之间连接异常导致的丢包,也可以进行槽位更换、线卡替换的排查工作。总结:端口丢包只是二三层转发的一种可能性原因,如遇到二三层转发故障还是需要按照上面的可能性原因进行排查。端口丢包故障处理案例S86端口下出现output方向的drop计数客户反馈如下故障:S860624SFP/12GT线卡某几个端口下在output方向出现较多dropped包。例如gi2/24接口。(590659 packets output, 360419425 bytes, 0 underruns , 48497 dropped  ,用户怀疑24SFP/12GT故障。gi2/24接口下只配置了trunk口,都有dropped包;将24SFP/12GT更换槽位后,接到网络中gi2/15仍然有丢弃包,并不断递增,每秒新增丢包100-200个。==========================GigabitEthernet2/24========================Index(dec):24(hex):18GigabitEthernet2/24isUP,lineprotocolisUPHardwareisBroadcom5464GigabitEthernetDescription:<<<<<<PortForSwitchNorthCore>>>>>>Interfaceaddressis:noipaddressMTU1500bytes,BW1000000KbitEncapsulationprotocolisBridge,loopbacknotsetKeepaliveintervalis10sec,setCarrierdelayis2secRXloadis2,Txloadis1Queueingstrategy:FIFOOutputqueue0/0,0drops;Inputqueue0/75,0dropsSwitchportattributes:interface'sdescription:"<<<<<<PortForSwitchNorthCore>>>>>>"medium-typeisfiberlastchangetime:0Day:0Hour:0Minute:45SecondPriorityis0adminduplexmodeisAUTO,operduplexisFulladminspeedisAUTO,operspeedis1000MflowcontroladminstatusisOFF,flowcontroloperstatusisOFFbroadcastStormControlisOFF,multicastStormControlisOFF,unicastStormControlisOFF5minutesinputrate9259908bits/sec,1851packets/sec5minutesoutputrate4859219bits/sec,1400packets/sec4341039packetsinput,2653085485bytes,0nobuffer,0droppedReceived18696broadcasts,0runts,0giants0inputerrors,0CRC,0frame,0overrun,0abort3370598packetsoutput,1559492555bytes,0underruns,182704dropped0outputerrors,0collisions,0interfaceresets故障分析如下:在端口未看到有QOS、生成树配置的情况下,可以尝试开启流控,对比观察情况是否有所缓解。Output方向的丢包有较多原因,见2.1端口计数器说明中的解释。为了确定具体的丢包原因需要收集线卡底层ps、以及showc的计数,收集底层信息的同时,上层端口计数同样需要收集,以用作对比和观察端口丢包的数量变化,从而找到源头。端口统计值打印:RIPC4.ge23      :            98,634,664            +493,305           1,464/sRIPC6.ge23      :                   480                  +2RIPHE6.ge23     :                   131                  +3RUC.ge23        :           185,768,405            +848,899           2,680/sRDBGC0.ge23     :                   290                  +1RDBGC1.ge23     :               405,621                +590               1/sTDBGC3.ge23     :             9,643,536            +138,313             355/sTDBGC4.ge23     :            74,292,306            +435,204           1,346/sTPCE.ge23       :             9,643,536            +138,313             355/sGR64.ge23       :                 4,303                 +12GR127.ge23      :            99,645,788            +497,059           1,737/sGR255.ge23      :            15,622,015             +89,831             353/sGR511.ge23      :             4,178,502             +14,312              63/sGR1023.ge23     :             4,711,031             +33,066             112/sGR1518.ge23     :            12,457,766             +42,340             123/sGRMGV.ge23      :            50,0
本文档为【端口丢包原因解析与排查指南】,请使用软件OFFICE或WPS软件打开。作品中的文字与图均可以修改和编辑, 图片更改请在作品中右键图片并更换,文字修改请直接点击文字进行修改,也可以新增和删除文档中的内容。
该文档来自用户分享,如有侵权行为请发邮件ishare@vip.sina.com联系网站客服,我们会及时删除。
[版权声明] 本站所有资料为用户分享产生,若发现您的权利被侵害,请联系客服邮件isharekefu@iask.cn,我们尽快处理。
本作品所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用。
网站提供的党政主题相关内容(国旗、国徽、党徽..)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。
下载需要: 免费 已有0 人下载
最新资料
资料动态
专题动态
is_135896
暂无简介~
格式:doc
大小:2MB
软件:Word
页数:36
分类:互联网
上传时间:2012-01-12
浏览量:123