客户在进行设备性能指标SNMP监控时，发现华三S9850-4C设备ifInDiscards(1.3.6.1.2.1.2.2.1.13)和ifOutDiscards (1.3.6.1.2.1.2.2.1.19)节点设备监控计数存在不断增长。对此产生了疑问，为何此计数增长，但是display interface却显示无错包信息。
ifindiscards和ifoutdiscards包括转发类错误和系统特殊处理报文等多种丢包计数，这类丢包出现时，芯片底层会进行丢包计数，以inDiscards为例，包含两种报文丢弃原因，主要罗列如下
1：报文转发类错误统计，包括：
a、收到端口不属于该端口vlan的报文、mac错误、无法识别的报文
b、端口非转发状态收到的报文（含stp discarding、learning、Listening；lacp unselect；rrpp STANDBY）
c、三层转发丢弃报文（直连没有arp进入黑洞丢弃、路由黑洞丢弃）
d、ACL限制转发的报文（比如限速丢弃、带宽抑止丢弃、广播抑制丢弃、acl过滤）
e、报文找不到出接口的。
2：系统特殊处理报文
a、协议报文本地终结，且上cpu处理（比如ospf报文等等）
b、ttl超时报文、重定向报文等本地不转发报文。
c、内部协议带宽限制的，比如stp等协议报文，系统内部做带宽保证和限制。
d、组播处理报文
当前客户反馈的针对FGE1/3/2端口SNMP采集上述指标有较明显计数增长的情况，对设备的FGE1/3/2口底层芯片丢包进行了检查，具体检查结果如下，可见FGE1/3/2端口存在RDBGC1和RDBGC3类型丢包，并且以RDBGC3丢包为主
===============debug port mapping slot 1===============
FGE1/3/2 0 37 xe25 no no 0x5a 16 up 0
===============bcm slot 1 chip 0 show/c===============
RIPD4_64.xe25 : 5,248 +459
RIPC4_64.xe25 : 176,803,197 +2,118,211
RIPHE4_64.xe25 : 14,853 +448
RIPHE6_64.xe25 : 79,091,416 +2,529,675
RUC_64.xe25 : 715,133,753,354 +8,829,735,845 1,050/s
RDBGC1_64.xe25 : 79,111,516 +2,530,582
RDBGC3_64.xe25 : 29,648,685,341 +74,029,549
ING_NIV_RX_FRAMES_VLAN_TAGGED_64.xe25: 734,142,399,083 +9,776,382,897 1,239/s
设备芯片底层对各种场景的报文丢弃动作进行了分类，设备常见收包错误类型如下：
RDBGC:
RDBGC1：交换芯片上是L3丢包计数 ，网片/SCROPION上则表示HG tag错误，比如HIGIG+/HIGIG2不一致
RDBGC2 ：组播相关丢包计数
RDBGC3：找不到出端口
RDBGC4：芯片MMU丢包计数
RDBGC5：L2相关丢包计数
RDBGC6：ACL丢包计数
RDBGC7：端口STP block丢包计数
RDBGC8：VLAN检查丢包计数
设备常见发包错误类型如下：
TDBGC：
TDBGC1：L3丢包计数
TDBGC2：组播丢包计数
TDBGC3：VLAN丢包计数
TDBGC4：STP丢包计数
TDBGC5：包老化丢包计数
TDBGC6：any reason
接口的RDBGC3的丢包含义为“找不到出接口”，这种情况在二层转发和三层转发场景中均存在。
二层转发时，典型场景为如下两种：
1) 从二层接口收到的报文源mac为本设备其他无关up端口的接口mac时，报文会丢弃并记录为RDBGC3丢包。
2) 从二层接口收到的报文目的mac为本二层口如端口学习到的mac时，报文会丢弃，并记录为RDBGC3丢包。
三层转发时，典型场景为如下一种：
1) 从二层口收到的报文目的mac命中vlan-interface 的接口mac，触发三层转发流程，但是目的ip找不到对应的出接口：如目的ip为vlan-interface同网段则发送ARP广播请求，超过三次无法收到回应，触发ARP黑洞机制，这个黑洞老化时间内再收到同类型报文丢弃并记录RDBGC3丢包；如目的ip非vlan-interface同网段，则查询路由表，如无法找到对应路由信息，则报文丢弃并记录RDBGC3丢包。
上述情况的报文，在发包终端arp学习机制和报文构造程序正常，交换机组网正常以及网络路由规划合理时基本不会产生，且收到此类报文产生丢包时并不会影响正常转发的业务。目前现场监控的ifInDiscards(1.3.6.1.2.1.2.2.1.13)和ifOutDiscards (1.3.6.1.2.1.2.2.1.19)其数量值不具有设备指标监控的参考意义。
1、建议客户对网管监控oid进行调整，目前我司建议使用如下oid进行错包和丢包监控：
接口拥塞丢包统计：
Name:hh3cifPktBufEgDrop
OID: 1.3.6.1.4.1.25506.8.35.1.5.1.6。
接口出入向错包统计：
Name: ifInErrors
OID:1.3.6.1.2.1.2.2.1.14
Name: ifOutErrors
OID:1.3.6.1.2.1.2.2.1.20
2、后续版本已经针对ifInDiscards 的数据统计范围进行优化调整，已经在ifInDiscards节点去除去掉indrop里RDBGC3统计。上述调整在R6635H29和R6710H22以后的版本已经完成。
3、如客户需要现网环境实际探究具体丢包报文，可在监控丢包端口增长端口长期抓包，针对抓包的结果进行筛选，结合设备配置寻找具备上述特征的报文。