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

端口丢包原因解析及排查指南
2010-9-28
福建星网锐捷网络有限公司
版权所有侵权必究
修订记录
目录
1数据包处理流程说明 (3)
1.1交换机芯片结构 (4)
1.2数据包处理流程 (5)
1.3缓冲区 (6)
1.4IBP与HOL (6)
1.4.1IBP (6)
1.4.2HOL (6)
1.4.3IBP与HOL的联系 (7)
2端口丢包常见原因及处理办法 (9)
2.1端口计数器的说明 (10)
2.2底层常见计数器说明 (13)
2.3端口丢包常见原因 (15)
2.4端口丢包和转发丢包的联系与区别 (17)
3端口丢包故障处理案例 (18)
3.1S86端口下出现output方向的drop计数 (19)
3.2S26开启组播，组播画面出现马赛克 (22)
4常见FAQ (27)
4.1Storm-control控制的报文方向 (28)
4.2QOS限速导致的端口丢包是否会在show interface gi xx显示？ (28)
4.3生成树block的端口，output方向是否有丢弃包的计数？ (28)
1 数据包处理流程说明
1 1.1 交换机芯片结构
交换芯片是交换机的灵魂，交换芯片注定了交换机的数据转发性能及部分功能。

例如不同型号产品的芯片型号便有所不同，但芯片的总体逻辑架构基本都如下图所示，模块化的交换机也基本都是多线卡组合起来的，实质就是单芯片通过Hi-Gig口连接到背板形成星型结构，由引擎来进行集中管理和控制功能。

说明：强烈推荐大家阅读此篇文档，加深对交换机硬件的理解。

《千兆位以太网交换芯片BCM5690及其在交换机中的应用》
名词解释：
ASIC（MAC 芯片）：为所有端口提供线速交换，
ASIC：内部提供多种tables，如MAC地址表，VLAN表，MSTP表，链路聚合表，链路聚合流量平衡表，IPMC表（IP组播表），用于策略控制的FFP(Fast Filter Process)表等。

这些都是在MAC芯片内部存贮，以CAM或TACM的方式寻址，硬件实现，完全满足数据包需要线速处理和转发的需要。

MMU：memory management unit，管理和存贮交换缓存单元，并暂存数据帧。

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
公共缓冲池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公平性的原则，这是一种比较理想的设计。

目前的设计采用了静态+动态共享的方式（静态分配一部分缓冲区+动态全局共享一部分，智能调整）Mavell芯片系列可以进行人工调整，例如可以使用buffer manage FC|QOS来进行调整。

QOS模式可以共享缓冲区大小，并根据报文的COS优先传输高优先级的报文，低优先级的报文进行缓冲或给高优先级报文提供更多的缓冲空间，来不及缓冲的直接丢弃。

当采用FC模式时，平均分配缓冲区大小并通过发送Pause 帧，要求对方减少发送速率，从而避免丢弃。

（当出现no buffer丢包时，发送pause帧，需要两端开启Flow control）。

1.4 IBP与HOL
1.4.1 IBP
IBP（ingress black pressure）是一种关注每个Ingress入端口CBP Bufffer率用率的方法，当缓冲率用率达到一定比率时，一个Pause帧就由Ingress口发出，如果对端支持流控，那么就会暂停一段时间，从而宏观上减少了发送速率，从而可以减小本机缓冲区的利用率，达到不丢包的目的。

1.4.2 HOL
HOL（head of line 队头阻塞）是一种关注每个Egress出端口Buffer利用率的方法，当利用率达到一定
比率时，从CBP Buffer送到端口的TX 队列的报文就会被丢弃。

出端口其实并没有物理上的缓冲区，只是做了一个出端口的队列（Transaction Queue，其实就是我们的COS队列），这个队列的指针指向CBP缓冲区。

队列根据端口的速率固定分配了长度，当报文在经历Ingress—MMU阶段中，会决定报文的某个Egess 出接口，于是将TX队列尾指针指向CBP中此报文的缓冲区位置，HOL就是关注这个Transaction Queue的使用率，当在实际应用中，例如某个千兆口向百兆口快速发包就可能导致TX队列超出limit，那么后续需要将CBP报文写入TX队列的报文将会被丢弃，从而导致丢包，如果入接口开启了流控，HOL溢出也会在入接口发送Pause流控帧。

1.4.3 IBP与HOL的联系
从上面IBP与HOL的描述，我们可以看出，IBP关注于：入接口的缓冲区率用率情况。

HOL关注于：出接口的队列使用情况（类似于缓冲区的率用率情况）。

两者的关联关系可以这样描述：
所以入丢包和出丢包时两个不同的阶段，HOL丢包，不一定回同时有IBP事件产生。

有IBP事件产生也不一定会导致HOL丢包，但有IBP存在的时候，HOL出现的几率更大。

因为某端口的入速率变大，那么往另外一个某出口的出速率也可能增大，导致HOL溢出丢包。

当入端口有限速（非QOS限速，即rate-limit）如果朝这个端口发包超过这个速率，也会导致此端口发送PAUSE流控帧，如果配置了出端口限速（即rate-limit），那么交换机转发到此端口的速率超出了限制，也会发生流控。

另外，广播包(组播、单播)限速（storm control）和COS限速不会导致发生流控，而是直接丢弃。

那么我们如何判定是否有IBP的情况呢？怎样又表明HOL存在溢出导致的丢包呢？
IBP导致的丢包，一般通过上层命令都可以查看到：
例如：
show interfaces gigabitEthernet 0/1结果：
Index(dec):1 (hex):1
GigabitEthernet 0/1 is DOWN , line protocol is DOWN
Hardware is marvell GigabitEthernet
Description: TO-ZGE-S8610-2_GE2/1
Interface address is: no ip address
MTU 1500 bytes, BW 1000000 Kbit
Encapsulation protocol is Bridge, loopback not set
Keepalive interval is 10 sec , set
Carrier delay is 2 sec
RXload is 1 ,Txload is 1
Queueing strategy: WFQ
Switchport attributes:
interface's description:"TO-ZGE-S8610-2_GE2/1"
medium-type is copper
lastchange time:0 Day: 0 Hour:45 Minute:26 Second
Priority is 0
admin duplex mode is AUTO, oper duplex is Unknown
admin speed is AUTO, oper speed is Unknown
flow control admin status is OFF,flow control oper status is Unknown
broadcast Storm Control is ON,multicast Storm Control is OFF,unicast Storm Control is ON
5 minutes input rate 0 bits/sec, 0 packets/sec
5 minutes output rate 0 bits/sec, 0 packets/sec
37167599 packets input, 2566418459 bytes, 45 no buffer, 45 dropped//丢包45个
Received 58764 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 abort
37210638 packets output, 2565322398 bytes, 0 underruns , 0 dropped
0 output errors, 0 collisions, 0 interface resets
show interfaces gigabitEthernet 0/1 counters
InOctets : 2566418459
InUcastPkts : 88649
InMulticastPkts : 37020186
InBroadcastPkts : 58764
OutOctets : 2565322398
OutUcastPkts : 1238
OutMulticastPkts : 37161052
OutBroadcastPkts : 48348
Undersize packets : 0
Oversize packets : 0
collisions : 0
Fragments : 0
Jabbers : 0
CRC alignment errors : 0
AlignmentErrors : 0
FCSErrors : 0
dropped packet events (due to lack of resources): 45 //丢包45个，由于CBP不足导致packets received of length (in octets):
64 : 70436041
HOL的丢包，一般需要在设备底层通过读取相关寄存器获取。

底层有HOL丢包在原来的版本中，show Interface counters的时候也有显示，但客户对drop计数会有不少抱怨，其实HOL溢出一般都是由于多端口向某端口发包速率太快所致，是由于环境原因引起的。

所以在后来的版本中，我们将HOL的计数都放在底层显示了，如有流控机制会自动进行调整改善。

例如：
S26-Test(sd)#sh show cou
RUC.ge4 : 628,352 +130,128 519/s
RDBGC0.ge4 : 877,970 +180,898 700/s
RDBGC1.ge4 : 148,092 +29,930 150/s
GRMCA.ge4 : 159,845 +32,535 156/s
GRBCA.ge4 : 280,791 +57,243 207/s
GR64.ge4 : 785 +96
GR127.ge4 : 904,990 +186,772 721/s
GR255.ge4 : 9,873 +2,025 7/s
GR511.ge4 : 1,692 +360 2/s
GR1023.ge4 : 26,045 +5,336 25/s
GR1518.ge4 : 2,946 +576 2/s
GRMGV.ge4 : 122,657 +24,741 125/s
GR2047.ge4 : 122,657 +24,741 125/s
GRPKT.ge4 : 1,068,988 +219,906 882/s
GRBYT.ge4 : 273,630,102 +55,501,231 261,676/s
GRUC.ge4 : 628,352 +130,128 519/s
GRPOK.ge4 : 1,068,988 +219,906 882/s
GTMCA.ge4 : 60 +9
GTBCA.ge4 : 128 +1
GT127.ge4 : 1,555 +361 2/s
GT255.ge4 : 155 +18
GT511.ge4 : 69 +5
GT1023.ge4 : 448 +2
GT1518.ge4 : 24 +1
GTPKT.ge4 : 2,259 +387 2/s
GTBYT.ge4 : 555,542 +34,097 137/s
GTUC.ge4 : 2,071 +377 2/s
GTPOK.ge4 : 2,259 +387 2/s
RUC.fe1 : 2,071 +377 2/s
RDBGC1.fe1 : 65 +9
HOLD.fe1 : 5,604 +1,975 15/s 第一列是累计值，第二列是从上次show至今的累计值，第三列是每秒丢丢包个数。

BCM芯片一般Fe0代表第一个接口即fe1,hold.fe1代表第二个接口。

2 端口丢包常见原因及处理办法
2 2.1 端口计数器的说明
通过查看端口的计数器，我们可以知道端口的收发包统计状况。

端口counter输出：
Switch#show int fastEthernet 0/1 counters
Interface : Fa0/1
5 minute input rate : 0 bits/sec, 0 packets/sec //5分钟的平均速率
5 minute output rate : 0 bits/sec, 0 packets/sec
InOctets : 68023600 进入的包总数
InUcastPkts : 92842 单播包
InMulticastPkts : 36700 组播包
InBroadcastPkts : 75636 广播包
OutOctets : 3630373 出去的总包数
OutUcastPkts : 32053 单播包
OutMulticastPkts : 1059 组播包
OutBroadcastPkts : 13231 广播包
[1] Undersize packets : 0
[2] Oversize packets : 0
[3] collisions : 0
[4] Fragments : 0
[5] Jabbers : 0
[6] CRC alignment errors : 0
[7] AlignmentErrors : 0
[8] FCSErrors : 0
[9] dropped packet events (due to lack of resources): 0
[10] packets received of length (in octets):
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#show interfaces gigabitEthernet 2/1
Index(dec):1 (hex):1
GigabitEthernet 2/1 is UP , line protocol is UP
Hardware is Broadcom 5464 GigabitEthernet //phy型号
Interface address is: no ip address
MTU 1500 bytes, BW 1000000 Kbit //MTU 带宽
Encapsulation protocol is Bridge, loopback not set
Keepalive interval is 10 sec , set 链路脉冲
Carrier delay is 2 sec 载波延时，口链路的载波检测信号DCD从Down状态到Up状态的时间延时，如果DCD在延时之内发生变化，那么系统将忽略这种的状态的变化而不至于上层的数据链路层重新协商
RXload is 1 ,Txload is 1 //接口负载利用率 1/255，每5分钟统计。

Queueing strategy: FIFO //这些都是给路由器用的，交换机不应该show这些信息，目前在新版本
10.4（2b2）中已经不显示了。

Output queue 0/0, 0 drops;
Input queue 0/75, 0 drops
Switchport attributes:
interface's description:""
medium-type is copper
lastchange time:5 Day: 7 Hour:47 Minute:40 Second//接口自系统启动后发生link变化的相对时间，可以结合show ver 查看系统的启动时间，判断端口上次发生up/down的时间。

Priority is 0
admin duplex mode is AUTO配置的双工为auto, oper duplex is Full//实际的双工状态 admin speed is AUTO, oper speed is 1000M 配置与实际的速率
flow control admin status is OFF,flow control oper status is OFF 流控
broadcast Storm Control is OFF,multicast Storm Control is OFF,unicast Storm Control is OFF
5 minutes input rate 0 bits/sec, 0 packets/sec 5分钟平均值
5 minutes output rate 20523 bits/sec, 9 packets/sec 5分钟平均值
42388309 packets input, 2917143960 bytes, 0 no buffer, 0 dropped
重点关注no buffer 和droped统计，no buffer就是由于缓冲区不足。

Received 76899 broadcasts, 0 runts, 1 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 abort
69858478 packets output, 6534138835 bytes, 0 underruns , 116 dropped
重点关注 droped统计
0 output errors, 0 collisions, 0 interface resets
ZGE-S8610-1#
虽然是5分钟的平均值，但实际上是5秒钟更新一次，软件模块会5秒钟读取相关MIB并计算最近5分钟的数据然后进行更新。

大家一般对input 以及output方向的drop代表什么含义非常感兴趣，这里就和大家一起来分析一下。

端口的计数，我们实现都是根据RFC来进行定义的：
Inputdrop RFC1213的定义如下：
ifInDiscards OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of inbound packets which were chosen
to be discarded even though no errors had been
detected to prevent their being deliverable to a
higher-layer protocol. One possible reason for
discarding such a packet could be to free up
buffer space."
::= { ifEntry 13 }
这个值仅表示接口下资源不足导致的丢包统计, 资源不足主要是对端发包太快或HOL原因导致的入缓冲溢出引起的。

（HOL是出方向对头阻塞，但出方向对头阻塞的同时，可能会引起入缓冲溢出。

）
Outputdrop RFC1213定义如下：
ifOutDiscards OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of outbound packets which were chosen
to be discarded even though no errors had been
detected to prevent their being transmitted. One
possible reason for discarding such a packet could
be to free up buffer space."
::= { ifEntry 19 }
这个值可以表示任何原因导致的出口丢包统计，所以描述不是特别详细，目前我们也是根据RFC定义的出口丢帧的原因以及产品芯片定义的一些出口丢帧的原因，出方向的Drop原因种类很多，总结包括如下可能：
报文老化（因为出口HOL等原因，导致报文在出口队列中待太久没有被调度到）
VLAN出口检查错误，接口不属于要转发报文的vlan（极少见到）
还有一些属于应用策略丢弃的，比如需要用出口转换表，结果报文在该表中无法查找到导致报文被丢弃的（如PVLAN的一些应用），还例如STP的端口BLOCK。

报文超过MTU长度的，出口MTU检查超出了MTU限制。

所以仅从表面无法能够知晓Drop丢包的原因，通常情况下这种丢包也不会对网络正常使用造成影响，从目前已有的故障案例中，排除例如端口阻塞的正常原因，基本都是环境因素导致的MMU资源不足。

遇到此类问题时，需要参考2.3的方法进行详细的信息收集来综合判断。

2.2 底层常见计数器说明
底层的寄存器计数非常真实的反映了芯片实时或累计的相关数据，具有非常好的参考意义，上层的所有数据统计其实都来源于底层的数据。

底层丢包我们重点关注有无HOLD溢出，并关注其累计值，实时值。

其他数据仅作为参考网络环境中的报文流情况。

进入底层后Show counter all可以查看到所有的寄存器的值，show c只显示字段有变化的值，通常我们
show c就可以了。

RIPHE4.ge21 : 0 +0
IMRP4.ge21 : 0 +0
RIPD6.ge21 : 0 +0
RIPC6.ge21 : 0 +0
RIPHE6.ge21 : 0 +0
IMRP6.ge21 : 0 +0
RDISC.ge21 : 0 +0
RUC.ge21 : 0 +0 收到的单播包
RPORTD.ge21 : 0 +0
RDBGC0.ge21 : 0 +0
RDBGC1.ge21 : 0 +0
RDBGC2.ge21 : 0 +0
RDBGC3.ge21 : 0 +0
RDBGC4.ge21 : 0 +0
RDBGC5.ge21 : 0 +0
RDBGC6.ge21 : 0 +0
RDBGC7.ge21 : 0 +0
RDBGC8.ge21 : 0 +0
HOLD.ge21 : 0 +0 HOL对头拥塞丢帧计数
TDBGC0.ge21 : 0 +0
TDBGC1.ge21 : 0 +0
TDBGC2.ge21 : 0 +0
TDBGC3.ge21 : 0 +0
TDBGC4.ge21 : 0 +0
TDBGC5.ge21 : 0 +0
TDBGC6.ge21 : 0 +0
TDBGC7.ge21 : 0 +0
TDBGC8.ge21 : 0 +0
TDBGC9.ge21 : 0 +0
TDBGC10.ge21 : 0 +0
TDBGC11.ge21 : 0 +0
TPCE.ge21 : 0 +0
GR64.ge21 : 0 +0 收到的报文字节大小64
GR127.ge21 : 0 +0 收到的报文字节大小65-127
GR255.ge21 : 0 +0 收到的报文字节大小128-255 GR511.ge21 : 0 +0 收到的报文字节大小256-511 GR1023.ge21 : 0 +0 收到的报文字节大小512-1023 GR1518.ge21 : 0 +0 收到的报文字节大小1024-1518 GRMGV.ge21 : 0 +0 收到的1519-1522带tag的报文GR2047.ge21 : 0 +0 收到的报文字节大小1519-2047 GR4095.ge21 : 0 +0
GR9216.ge21 : 0 +0
GRPKT.ge21 : 0 +0 收到的报文数
GRBYT.ge21 : 0 +0 收到的字节数
GRMCA.ge21 : 0 +0 收到的组播报文
GRBCA.ge21 : 0 +0 收到的广播报文
GRFCS.ge21 : 0 +0 FCS error帧统计
GRXCF.ge21 : 0 +0 收到的控制帧统计（例如流控协商）GRXPF.ge21 : 0 +0 收到的pause帧统计
GRXUO.ge21 : 0 +0 不支持的opcaode控制帧GRALN.ge21 : 0 +0 Alignment error帧
GRFLR.ge21 : 0 +0 长度不符的异常帧，相见参考表GRCDE.ge21 : 0 +0 Code error
GRFCR.ge21 : 0 +0 收到的载波计数
GROVR.ge21 : 0 +0 oversize帧统计
GRJBR.ge21 : 0 +0 Jabber统计
GRMTUE.ge21 : 0 +0 MTU检查失败统计
RRPKT.ge21 : 0 +0 runt帧统计
GRUND.ge21 : 0 +0 undersize帧统计
GRFRG.ge21 : 0 +0 fragment帧统计
RRBYT.ge21 : 0 +0 runts字节数统计
GT64.ge21 : 0 +0 GT发送
GT127.ge21 : 0 +0
GT255.ge21 : 0 +0
GT511.ge21 : 0 +0
GT1023.ge21 : 0 +0
GT1518.ge21 : 0 +0
GTMGV.ge21 : 0 +0
GT2047.ge21 : 0 +0
GT4095.ge21 : 0 +0
GT9216.ge21 : 0 +0
GTPKT.ge21 : 0 +0
GTMCA.ge21 : 0 +0
GTBCA.ge21 : 0 +0
GTXPF.ge21 : 0 +0
GTJBR.ge21 : 0 +0
GTFCS.ge21 : 0 +0
GTXCF.ge21 : 0 +0
GTOVR.ge21 : 0 +0
GTDFR.ge21 : 0 +0
GTEDF.ge21 : 0 +0
GTSCL.ge21 : 0 +0
GTMCL.ge21 : 0 +0
GTLCL.ge21 : 0 +0
GTXCL.ge21 : 0 +0
GTFRG.ge21 : 0 +0
GTNCL.ge21 : 0 +0
GTBYT.ge21 : 0 +0
详细解释参考如下文档：
5601X-Counters.pd
f
2.3 端口丢包常见原因及信息收集
导致端口丢包的原因总结起来包括如下几种可能性：
1．由于某些接口、链路、双工异常导致的CRC错误、Algiment 帧bit丢失等常见错误，此类报文交换机将予以丢弃-------查看端口计数，是否由较多CRC、冲突帧等。

2．QOS限速、Rate-limit配置导致的数据包正常丢弃。

（不计入端口统计计数）
3．端口BLOCK（STP、RLDP）导致的数据包正常丢弃。

（计入端口统计计数）--查看端口生成树状态
4．对端设备发送的速率过快导致本端交换机buffer 不足，而又没有流控导致的丢包—尝试两端打开流控，观察。

5．多端口向一个端口发送报文，超出这个端口的转发能力，导致的HOL队头阻塞丢包。

--尝试调整端口速率和打开流控，观察。

6．由于环境因素（例如异常帧较多），导致MMU资源溢出（参见故障处理案例1）。

---前文讲到此类故障导致的原因很多，此类故障多需要底层计数信息，进行详细分析判断。

参考下面的信息收集方法。

其中最常见的4/5两种类型的溢出，通过查看端口的计数器定位受影响的端口并打开两端的流控一般都能解决问题。

从目前实际遇到的案例来看，也基本都是由于以上两种原因导致的丢包故障。

如仍无法解决，请收集上层计数与底层计数信息提供后台分析判断。

注意：收集上下层信息的同时，注意收集信息的充分性，多次收集的上层信息必须有发现drop计数的递增，这几次收集间隔中底层的信息都必须相应收集到。

上层信息：show interface （多次获取）
show interface xx counter （多次获取，需要捕捉到drop的计数或其他异常计数的变化）
show interface status
show mac-address-table
底层信息：sd （进入sd调试界面）
su xx (参考各产品SD手册)
console on
ps (查看端口工作状态)
show c （查看端口计数，多次获取）
get egrdroppktcount （查看端口出口丢包计数及相关寄存器）
//5750，26产品支持此命令
l2 show
dump port （查看端口相关属性，可选）
console off
dexit
2.4 端口丢包和转发丢包的联系与区别
我们常见的丢包一种是比较明显的某端口存在丢包，另外较为常见的是转发不通或转发丢包。

转发丢包又分二层转发丢包和三层转发丢包。

二层转发是基于VID+MAC的转发，所以不仅端口存在丢包会导致二层转发丢包，还包括其他较多复杂因素导致的丢包，总结起来有如下几种原因：
（1）端口双工、速率、流控等导致的双工不匹配、缓存不足导致的丢包。

----------通过查看接口的工作状态，查看端口计数和底层ps(查看端口工作状态、show c 查看端口计数)来确定是否存在端口丢包。

（2）端口接触不良或频繁震荡导致数据无法被转发导致的丢包
--------通过查看日志或更换端口进行对比测试
（3）链路存在问题导致CRC、Jabber等的丢包
------通过查看端口计数确认并更换链路进行测试
（4）端口STP逻辑状态的频繁变化，导致的数据转发中断。

-----通过查看日志和show spanning-tree 查看生成树的统计情况或打开debug开关进行查看。

（5）端口限速导致的正常丢包
----查看QOS配置或调整限速大小进行对比测试
（6）MAC表或VLAN表或安全表（FFP）导致的转发不通。

---通过收集上层及底层的L2、VLAN、端口、FFP表进行确认对比。

也可以调整相关安全功能进行打开或关闭。

二层转发丢包的关键是必须提前确定丢包是在哪里产生的，可以通过分段测试法，充分利用镜像捉包的功能。

二层转发的终极手段是清空设备配置，保留最单纯的环境，进行转发测试，如有仍然有丢包等情况，经底层show c查看后，一般为硬件故障。

三层转发丢包
三层转发丢包由于涉及到查找路由和打通路由（ARP）的过程，所以除了刚才二层转发丢包的可能性原因以外，还新增了如下几种可能的原因：
（1）路由频繁震荡（例如动态路由频繁震荡、路由频繁发生切换或底层路由溢出）
-------可以查看相关日志，并收集路由表项（上层与底层表项），或尝试静态制定相关表项。

（2）ARP表频繁发生变化，需要重现打通（例如Tc change导致的三层设备清除ARP地址表）-------可以查看相关STP日志并优化配置或打印相关debug 日志，也可以尝试静态绑定相关表项。

（3）安全过滤，例如ACL、URPF等某些安全策略将部分报文过滤导致的丢包
-----------可从配置上、log上进行相关分析及查看。

排查三层转发故障的时候第一要求也是必须确定丢包点在哪个地方，然后根据如上的可能性进行逐一排查。

举个例子：我们通常ping某个目的地址的时候，都会发现ping 5个包，会丢包一个包，原因就是由于第一个包由于目标机器没有源主机的ARP，ARP打通的时间超过ICMP timeout 2s的原因。

三层转发故障定位到单台箱式设备时，当排除了环境因素或功能模块导致的问题后，可能由于内部数据通道之间连接异常导致的丢包，也可以进行槽位更换、线卡替换的排查工作。

总结：端口丢包只是二三层转发的一种可能性原因，如遇到二三层转发故障还是需要按照上面的可能性原因进行排查。

3 端口丢包故障处理案例
3 3.1 S86端口下出现output方向的drop计数
客户反馈如下故障：
S8606 24SFP/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个。

========================== GigabitEthernet 2/24 ========================
Index(dec):24 (hex):18
GigabitEthernet 2/24 is UP , line protocol is UP
Hardware is Broadcom 5464 GigabitEthernet
Description: <<<<<<Port For Switch NorthCore>>>>>>
Interface address is: no ip address
MTU 1500 bytes, BW 1000000 Kbit
Encapsulation protocol is Bridge, loopback not set
Keepalive interval is 10 sec , set
Carrier delay is 2 sec
RXload is 2 ,Txload is 1
Queueing strategy: FIFO
Output queue 0/0, 0 drops;
Input queue 0/75, 0 drops
Switchport attributes:
interface's description:"<<<<<<Port For Switch NorthCore>>>>>>"
medium-type is fiber
lastchange time:0 Day: 0 Hour: 0 Minute:45 Second
Priority is 0
admin duplex mode is AUTO, oper duplex is Full
admin speed is AUTO, oper speed is 1000M
flow control admin status is OFF,flow control oper status is OFF
broadcast Storm Control is OFF,multicast Storm Control is OFF,unicast Storm Control is OFF
5 minutes input rate 9259908 bits/sec, 1851 packets/sec
5 minutes output rate 4859219 bits/sec, 1400 packets/sec
4341039 packets input, 2653085485 bytes, 0 no buffer, 0 dropped
Received 18696 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 abort
3370598 packets output, 1559492555 bytes, 0 underruns , 182704 dropped
0 output errors, 0 collisions, 0 interface resets
故障分析如下：
在端口未看到有QOS、生成树配置的情况下，可以尝试开启流控，对比观察情况是否有所缓解。

Output方向的丢包有较多原因，见2.1端口计数器说明中的解释。

为了确定具体的丢包原因需要收集线卡底层ps 、以及show c的计数，收集底层信息的同时，上层端口计数同样需要收集，以用作对比和观察端口丢包的数量变化，从而找到源头。

端口统计值打印：
RIPC4.ge23 : 98,634,664 +493,305 1,464/s
RIPC6.ge23 : 480 +2
RIPHE6.ge23 : 131 +3
RUC.ge23 : 185,768,405 +848,899 2,680/s
RDBGC0.ge23 : 290 +1
RDBGC1.ge23 : 405,621 +590 1/s
TDBGC3.ge23 : 9,643,536 +138,313 355/s
TDBGC4.ge23 : 74,292,306 +435,204 1,346/s
TPCE.ge23 : 9,643,536 +138,313 355/s
GR64.ge23 : 4,303 +12
GR127.ge23 : 99,645,788 +497,059 1,737/s
GR255.ge23 : 15,622,015 +89,831 353/s
GR511.ge23 : 4,178,502 +14,312 63/s
GR1023.ge23 : 4,711,031 +33,066 112/s
GR1518.ge23 : 12,457,766 +42,340 123/s
GRMGV.ge23 : 50,043,152 +174,803 622/s
GR2047.ge23 : 50,043,152 +174,803 622/s
GRPKT.ge23 : 186,664,487 +851,501 2,787/s
GRBYT.ge23 : 107,826,433,988 +400,365,097 1,371,273/s
GRMCA.ge23 : 405,632 +600
GRBCA.ge23 : 484,711 +2,210 10/s
GT64.ge23 : 804,885 +2,769 4/s
GT127.ge23 : 84,665,646 +313,498 1,038/s
GT255.ge23 : 5,917,893 +28,948 104/s
GT511.ge23 : 2,173,565 +13,821 94/s
GT1023.ge23 : 5,625,348 +52,302 152/s
GT1518.ge23 : 26,009,843 +207,156 595/s
GTMGV.ge23 : 4,266,102 +45,250 129/s
GT2047.ge23 : 4,266,102 +45,250 129/s
GTPKT.ge23 : 129,465,293 +664,204 2,140/s
GTMCA.ge23 : 296,875 +1,041 4/s
GTBCA.ge23 : 3,976,782 +10,958 53/s
GTBYT.ge23 : 53,927,105,479 +427,113,523 1,216,833/s
查阅芯片寄存器计数文档：
TDBGC3的统计值即为端口outputdrop的统计值，本案例中TDBGC3=TPCE
TPCE： Egress Purge and Cell Error Drop counter.
Incremented for each Packet drop due to a purge or
cell error per egress port.
查阅文档资料：
For TPCE getting incremented, in our device, we attempt to drop packets
in the ingress when there are insufficient MMU resources. However, if an
incoming packet makes it past the ingress check (there are resources at
the time) but subsequently hits a limit in the MMU stage (the threshold
is crossed), the MMU will drop this packet by setting the “purge“ bit.
This will result in an egress purge counter incrementing.Therefore, a
purge condition is actually quite normal.
设备实现中，当MMU资源不足时，我们通常会在报文进入MMU阶段将报文丢弃。

但当某个报文进入的时候，还有资源存在，但在在后续的处理阶段遇到遇到了MMU的阀值（溢出），MMU将会将此包置为“清除”位，这样出口的drop计数就会增加，这是一种比较正常的实现。

这种溢出和HOL队头阻塞还是有所差别的，所以本案例中底层没有HOLD计数。

查看底层计数
GR2047.ge15 : 54,704,700 +230,448 749/s
GR2047.ge18 : 17,132,972 +68,464 249/s
说明网络中存在大量大于1518的报文（以太网要求的报文长度最长为1518），这样就会导致MMU资源耗尽。

为了验证这种情况导致的MMU溢出，我们进行了模拟，使用测试仪表模拟客户背景流（根据show c 的计数进行模拟）和普通报文进行模拟对比，确认为网络中出现大量MTU大于1518的报文时可能导致MMU溢出，最终导致出口计数丢包。

最终解决办法：通过端口计数，来查找哪些端口的这种报文较多并查找来源。

故障处理总结：
初步判断是否为常规的缓存丢包或HOL丢包，并进行流控的调整
收集上层及底层的信息（show interface xx,show interface counter ,底层ps/ show c
对show c的结果按照表格进行初步分析，查看有哪些异常并提交TAC分析
3.2 S26开启组播，组播画面出现马赛克
客户反馈如下故障：
S26做组播环境测试，测试环境较为简单：组播源—S86—S57—千兆—S26—百兆—PC，用户网关在PC上，S26的配置仅开启了组播监听，风暴控制关闭，组播会出现马赛克现象，但看CCTV1视频不卡，看CCTV5才会卡。

Building configuration...
Current configuration : 5120 bytes
!
version RGOS 10.4(2) Release(75955)(Mon Jan 25 19:46:06 CST 2010 -ngcf31)
hostname S_262_211_RG_2628A
!
!
!
!
nfpp
!
!
vlan 1
!
vlan 2
!
vlan 12
!
vlan 13
name test
!
vlan 18
!
vlan 461
!
!
service password-encryption
!
!
!
ip default-gateway 10.0.1.1
!
!
logging
enable secret level 1 5 $1$J34Q$Btt3537vv5BCyCrt enable secret 5 $1$khi7$swut2z2w4CrAxsD6
!
!
!
!
interface FastEthernet 0/1
switchport access vlan 18
no storm-control broadcast
no storm-control unicast
spanning-tree bpduguard enable
spanning-tree portfast
!
interface FastEthernet 0/2
switchport access vlan 18
no storm-control broadcast
no storm-control unicast
spanning-tree bpduguard enable
spanning-tree portfast
!
interface FastEthernet 0/3
switchport access vlan 18
no storm-control broadcast
no storm-control unicast
spanning-tree bpduguard enable
spanning-tree portfast
!
interface FastEthernet 0/4
switchport access vlan 18
no storm-control broadcast
no storm-control unicast
spanning-tree bpduguard enable
spanning-tree portfast
!
interface FastEthernet 0/5
switchport access vlan 12
no storm-control broadcast
no storm-control unicast
spanning-tree bpduguard enable。