S9850-4C SNMP采集ifindiscards和ifoutdiscards节点的计数不断增长问题

客户在进行设备性能指标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、如客户需要现网环境实际探究具体丢包报文，可在监控丢包端口增长端口长期抓包，针对抓包的结果进行筛选，结合设备配置寻找具备上述特征的报文。