STP震荡日志一阵一阵刷、现场却抓不到？OIDS把历史翻出来对时间
本文整理自华为官方发布的典型配置案例，命令与步骤均按原始文档呈现，供现场实施参考。
网络里有一类故障很磨人：STP端口状态每隔一阵莫名震荡一次，日志里forwarding和discarding来回切，等你接到报障登上设备，现场早就风平浪静，什么都查不到。反复发生又无法复现，靠人守着看日志效率太低。华为设备的OIDS（集成自动诊断）功能专治这类历史谜案——它平时就在后台持续采集各监测对象的指标，出了事能把事发前后的关键事件按时间翻出来，和日志一对时间戳，真相就出来了。
前提是故障发生前设备已使能OIDS监控功能。动手排查分几步。第一步，双主控或集群设备先把OIDS数据库文件采集到主用主控板，数据在手再慢慢分析。第二步，查指定时间段内产生的OIDS事件：
<HUAWEI> display oids history-event before date-time 17:00:00 2018-04-21 period 24h
----------------------------------------------------------------------
Slot : 1
ObjectName : CPU_Que5
AttrName : CPU_Que_Drop_Pkt
Event : CPU Queue Drop Pkt
Time : 2018-04-21 16:57:38
State value: 3045
Slot : 1
ObjectName : CPU_Que5
AttrName : CPU_Que_Drop_Pkt
Event : CPU Queue Drop Pkt
Time : 2018-04-21 13:27:04
State value: 2830
----------------------------------------------------------------------
这条查询的意思是：查2018年4月21日17点之前24小时内的事件记录。回显显示CPU的5号队列（队列号对应STP这类协议报文的上送通道）在13点27分和16点57分各发生了一次丢包事件。把两个时间和STP震荡日志的时间一对照，基本吻合——路子就对上了：协议报文在CPU队列里被丢，生成树收不到报文，端口状态自然来回震荡。
第三步，顺着队列往下查。先看该队列给STP分配的带宽和令牌：
<HUAWEI> display cpu-defend configuration packet-type stp mcu
Car configurations on mainboard.
----------------------------------------------------------------------
Packet Name Status Cir(Kbps) Cbs(Byte) Queue Port-Type
----------------------------------------------------------------------
stp Enabled 512 96256 5 NA
----------------------------------------------------------------------
再查统计里STP报文的实际通过和丢弃计数：
<HUAWEI> display cpu-defend statistics mcu
Statistics on mainboard:
--------------------------------------------------------------------------------
Packet Type Pass(Packet/Byte) Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
stp 74929 0 -
9216267 0
……
CIR带宽512K、令牌桶容量也充足，统计里STP报文全部通过、零丢弃——说明本机这个环节目前没问题，震荡的根源在别的设备或链路上，排查方向立刻收窄。假如统计里看到Drop计数不为零、丢弃时间与震荡时间吻合，那就坐实了本机CPU通道丢包，下一步就是调整STP报文的CAR参数或排查为何协议报文量异常，两条路都摆在明面上。这套组合拳的思路是：历史事件定时间，队列丢包定环节，配置加统计定根源，把事后无从查起变成按时间戳对账。处理这类间歇性故障，OIDS留底是关键一手。欢迎搜索关注贵州诚鑫致达科技，了解更多交换机故障排查实战配置。
