故障排查流程
步骤一：查看主板或红外转接板上的红外灯状态
1. 查看闸机主板或红外转接板上红外指示灯是否亮灯，部分闸机亮红灯，部分闸机亮蓝灯，具体指示灯颜色以实物为准，灯灭代表红外未触发
2. 如果亮灯，就根据指示灯编号找到对应红外，检查闸机安装是否水平、垂直、被遮挡
如果安装正常且红外未遮挡：继续检查辅机侧发射红外供电是否正常
如果闸机施工安装不标准：重新调整闸机位置
3. 完成以上排查步骤无异常，接着按照步骤二继续排查
步骤二：检查主板或红外转接板和网线
检查主板或红外转接板是否进水腐蚀，检查网线是否接触良好
若主板或网线损坏：更换主板或网线
若主板和网线正常：按照步骤三继续排查
步骤三：近距离测试红外
将红外对射传感器从闸机中取出，近距离对射观察是否正常
如果不正常，则更换红外
如果正常，可以拨打4006728166进入5号线咨询人工客服
背景信息
交换机用作PSE，给PD设备供电，连接完成后，PD无法正常上电。
问题现象
PD无法上电。
处理方法
通过现象描述判断，此类问题属于PD完全无法上电，处理的流程如下：
1、检查设备的PoE功能是否可用。其中包括设备是否支持PoE功能、PoE电源状态是否正常、PoE功能是否已开启。
2、检查PSE能否检测到PD。PSE可能由于网线故障、交换机没有接地、PD不兼容、PD故障等原因导致无法正常检测到PD。
3、检查PSE能否对PD进行供电。需要确认供电距离是否在100m以内、供电模式、设备是否处于下电时间段、电源功率是否充足、是否开启强制供电。
Step1：检查设备的PoE功能是否可用。
1、查看设备型号为S2700-9TP-PWR-EI，为内置PoE电源设备，确认设备支持PoE功能且电源状态正常。
2、进入连接PD的接口GigabitEthernet0/0/6下，查看是否有去使能PoE功能的配置，经确认，PoE功能已使能。
<HUAWEI> system-view
[HUAWEI] interface GigabitEthernet0/0/6
[HUAWEI-GigabitEthernet0/0/6] display this
port link-type access
port default vlan 100
Step2：检查PSE能否检测到PD。
1、检查是否网线故障。用一根确认正常的网线，使用原接口重新连接此AP，发现现象描述仍然存在，排除原网线故障的可能性。
2、检查PD设备是否良好接地。查看交换机接地点，已经使用黄绿色接地线有效接地。
3、检查是否PD不兼容。在交换机上查看告警信息，发现设备上报非标PD告警：POE/4/NONSTANDARDPD:An invalid or non-standard PD is connected to the interface [gigabitEthernet0/0/6].
Step3：使能供电设备PSE对PD的兼容性检测功能。
在连接非标准PD设备的接口下，进入接口视图，执行命令poe legacy enable，使能设备接口对于非标准PD设备的兼容性检测功能。例如
<HUAWEI> system-view
[HUAWEI] interface gigabitethernet0/0/6
[HUAWEI-GigabitEthernet0/0/6] poe legacy enable
Step4：使能了交换机对非标准PD的兼容性检测功能后，确认交换机能正常供电，PD工作状态正常，故障排除。
总结
由于D种类繁多，有很多不符合标准的PD设备在市面流通。如果非标准PD接入设备后，设备将无法检测到满足要求的特性电阻，无法识别PD。
使能兼容性检测功能，能够使设备检测到不符合802.3af、802.3at或802.3bt标准的PD设备，从而实现给非标准PD供电。
背景信息
S5700EI用作PSE，给下挂AP供电。由于现场环境限制，交换机没有安置在机架上，而是放在地面地毯上，使用网线连接AP。
问题现象
交换机连接AP的端口频繁Up/Down。
处理方法
通过现象描述判断，此类问题属于PD频繁上下电，可能的原因为：
1、网线是否故障。
2、PD设备是否良好接地。
3、PoE供电不稳。
Step1：检查网线是否故障。
用一根确认正常的网线，使用原接口重新连接此AP，发现现象描述仍然存在，排除原网线故障的可能性。
Step2：检查PD设备是否良好接地。
由于交换机所处环境较为混乱，设备没有保证良好接地，并且设备直接放在地毯上，容易产生较大的静电干扰，影响到检测、分级的判断，导致不能正常给AP上电。怀疑这是导致故障的原因。
Step3：将交换机接地，检查端口状态和AP状态是否恢复正常。
Step4：将交换机接地后，确认交换机能正常供电，AP工作状态正常，故障排除。
总结
在PoE上电阶段，需要对下挂的PD进行检测、分级，如果有外界干扰，可能会影响到PSE对检测、分级的判断，导致不能给PD上电，因此，请对PoE交换机可靠接地。
组网情况
如图所示， RRPP主节点不停被破环，然后网络又成环。
现象描述
RRPP环协议震荡，持续时间1个多小时，在日志中未见有异常（比如接口震荡），也没有发现在RRPP环上的接口有出入方向的FCS等异常计数。
原因分析
根据测试的结果来看，RRPP的HELLO报文在端口的未知单播流量增大的时候会被丢弃。连续丢弃3个报文后，RRPP的环状态为Failed，待收到下一个HELLO报文时，又恢复正常。RRPP的环状态就在Failed和Complete之间震荡。
操作步骤
1、按照现网的配置搭建测试环境，S3328上的RRPP状态正常。
2、测试仪向S3328发送携带RRPP的control-vlan的未知单播流量。
3、查看设备的RRPP状态，出现协议震荡，且恢复时间间隔为与现网的现象相同。
4、由复现结果可以断定，现网中由于配置未知单播抑制引发协议震荡，可执行命令undo unicast-suppression，删除未知单播抑制功能。
建议与总结
客户在RRPP环上的端口不要配置未知单播抑制。否则，未知单播流量增大的时，有可能造成RRPP的HELLO报文丢弃，影响RRPP环状态的稳定，造成协议震荡。
组网情况
如图所示，SwitchA作为RRPP环的主节点，正常情况下GE1/0/0为Primary port、GE2/0/0为Secondary port（block）。
现象描述
RRPP环组网中，主节点不停被破环，然后网络又成环。
原因分析
设备上配置了未知单播抑制功能，而RRPP的协议报文的目的MAC为未知单播MAC。在端口未知单播流量较多时，RRPP协议报文会被抑制掉，从而导致设备认为RRPP的环链路出现故障，从而放开阻塞，导致成环。
操作步骤
通过display rrpp statistics命令查看到，设备不时发送或者接收到LINK DOWN报文，并且设备上的主端口和负端口的HEALTH报文Send和Rcv计数不一致。
查看配置，设备上面配置了未知单播抑制命令unicast-suppression。
接口视图下执行命令undo unicast-suppression，删除未知单播抑制功能，故障解除。
建议与总结
在使用RRPP、SEP、ERPS等协议，协议报文目的MAC为单播MAC时，请您不要配置未知单播抑制。
组网情况
如图 所示，SwitchA、SwitchB、SwitchC、SwitchG、SwitchF、SwitchE构成Segment 1，SwitchC、SwitchD和SwitchE构成Segment 2。
现象描述
SwitchC和SwitchD之间链路发生故障，将SwitchD故障端口的SEP配置删除，造成SwitchD脱管。
原因分析
SwitchC和SwitchD之间的链路发生故障后，SEP Segment 2的之前的阻塞口将放开，两个故障口为Discarding状态，当删除SwitchD故障端口的SEP配置后，SEP Segment 2将在SwitchD和SwitchE的两个端口上选择一个新的阻塞口，导致SwitchD的上下方向的链路都不通，设备脱管。
操作步骤
通过命令display sep topology segment segment-id查看当前的拓扑信息，确认故障端口。
开放环场景下，在需要删除SEP配置并重新部署SEP时，建议从开放环的一端开始删除配置，剩余最后一个SEP接口时，Shutdown该端口，再删除该端口的SEP配置。
建议与总结
在删除SEP配置时，需要考虑SEP段上业务VLAN的部署情况，防止在操作的过程中产生多点阻塞造成设备托管或业务不通。
现象描述
MSTP网络中出现交换机CPU使用率高。
原因分析
MSTP环网中，因各类原因引起拓扑重新计算，网络中会发布大量拓扑改变BPDU报文，使得设备占用CPU进行计算，从而导致CPU使用率高。
操作步骤
1、执行命令display interface brief，查看端口带宽使用率是否较高。
<HUAWEI> display interface brief
…………
Interface PHY Protocol InUti OutUti inErrors outErrors
GigabitEthernet4/0/1 up up 0.72% 81% 0 0
GigabitEthernet4/0/2 up up 81% 0.73% 2 0
2、执行命令display stp tc-bpdu statistics，查看端口TC/TCN报文收发计数，发现设备收到大量的TC报文。
<HUAWEI> display stp tc-bpdu statistics
————————– STP TC/TCN information ————————–
MSTID Port TC(Send/Receive) TCN(Send/Receive)
0 GigabitEthernet4/0/1 3/2 0/0
0 GigabitEthernet1/0/10 14/9 0/0
由于网络中无法确定引起拓扑改变的故障点，为解决本设备CPU使用率高的问题，可进行如下操作：
使能arp topology-change disable，即当网络的拓扑变化的时候，系统的ARP表项不再进行老化或者删除操作的功能
使能mac-address update arp，即当MAC地址的出接口变化时，通知更新ARP表项的出接口。
注：V100R006版本开始支持mac-address update arp，V200R001版本开始支持arp topology-change disable命令。
CPU使用率明显下降，问题解决。
建议与总结
当在MSTP网络中发现设备使用率高的问题时，应首先查看设备是否收到大量TC报文。若收到大量TC报文，可以采用关闭ARP随拓扑变化老化删除功能，启用MAC地址出接口变化同步更新ARP表项的功能来解决。
现象描述
1、通过网管监控的CPU利用率情况，如图所示：
2、同时设备上还出现CPU占用率过高的日志信息。
Switch %%01VOSCPU/4/CPU_USAGE_HIGH(l)[31]:The CPU is overloaded(CpuUsage=96%, Threshold=95%), and the tasks with top three CPU occupancy are:
FTS total : 18%
SRMT total : 11%
SOCK total : 8%
Switch %%01VOSCPU/4/CPU_USAGE_HIGH(l)[60]:The CPU is overloaded(CpuUsage=100%, Threshold=95%), and the tasks with top three CPU occupancy are:
PPI total : 41%
SRMT total : 10%
FTS total : 8%
3、同时设备上还有大量的ARP报文超过CPCAR后丢弃的日志记录。
Switch %%01DEFD/4/CPCAR_DROP_MPU(l)[56]:Rate of packets to cpu exceeded the CPCAR limit on the MPU. (Protocol=arp-miss, ExceededPacketCount=016956)
Switch %%01DEFD/4/CPCAR_DROP_MPU(l)[57]:Rate of packets to cpu exceeded the CPCAR limit on the MPU. (Protocol=arp-reply, ExceededPacketCount=020699)
Switch %%01DEFD/4/CPCAR_DROP_MPU(l)[58]:Rate of packets to cpu exceeded the CPCAR limit on the MPU. (Protocol=arp-request, ExceededPacketCount=0574
4、采集端口TC（Topology Change）报文收发情况。
使用命令display stp tc-bpdu statistics查看所有使能STP的端口接收到的TC报文计数。间隔5秒再次获取一次，可以看出所有端口接收到的TC报文计数在均在增长。
原因分析
通过查看端口的TC报文计数，发现端口收到大量的TC报文，且在不断增长。触发MAC删除、ARP表项刷新，设备处理大量arp-miss、arp-request和arp-reply报文，导致CPU升高，OSPF Hello报文、VRRP心跳报文不能及时处理，出现震荡。
问题判断方法
1、全局配置stp tc-protection。
配置此命令后可以保证设备频繁收到TC报文时，每2秒周期内最多只处理1次表项刷新，从而减少MAC、ARP表项频繁刷新对设备造成的CPU处理任务过多。
2、全局配置arp topology-change disable及mac-address update arp。
当设备收到TC报文后，默认会清除MAC、老化ARP。当设备上的ARP表项较多时，ARP的重新学习会导致网络中的ARP报文过多。配置arp topology-change disable、mac-address update arp后，在网络拓扑变化时，可以根据MAC地址的出接口变化刷新ARP表项出接口。可以减少大量不必要的ARP表项刷新。
注：V100R006版本开始支持mac-address update arp命令，V200R001版本开始支持arp topology-change disable命令。
建议与总结
在部署STP时，建议配置TC保护功能，所有连接终端的接口配置成边缘端口，这样可以避免某些端口的状态变化引起整个STP网络震荡而重新收敛。在处理CPU高的问题时，多关注CPCAR丢包情况。
组网情况
如图所示，Switch-A和Switch-B通过Eth-Trunk链路直连，配置VRRP协议，Switch-A为VRRP主设备，Switch-B为VRRP备设备。Switch-A和Switch-B做三层网关，下挂多台接入交换机做二层，均使能了STP协议进行破环。二层交换机与接入用户相连。
现象描述
Switch-A交换机上ARP学习异常，有很多Incomplete的ARP表项，下面用户终端的ARP时有时无，业务不稳定。
原因分析
Switch下挂的二层交换机上，STP域的边缘端口均没有配置stp edged-port enable，这些端口状态发生变化时会发送TC报文，Switch收到后进行STP收敛处理，立即清除ARP表项或进行老化探测处理Switch上因为ARP数量比较多，发送大量ARP请求报文进行探测，收到用户的ARP应答报文比较多，超过了cpcar值，部分ARP应答报文丢弃，这些ARP将被老化删除，对应用户业务不能使用。Switch频繁收到这样的TC报文，业务更加不稳定。
操作步骤
1、登录设备进行观察，查看VLANIF27接口下的ARP。该VLANIF接口接入的是经常在线的用户的服务器。长时间观察，发现接口下的ARP总数有时在50个左右，有时在20个左右，数量不稳定。同时还有Incomplete状态的ARP，IP地址也不固定。学习到的ARP表项的老化时间有时都为0。
<Switch-A> display arp interface vlanif 27
IP ADDRESS MAC ADDRESS EXPIRE(M) TYPE INTERFACE VPN-INSTANCE
VLAN/CEVLAN
——————————————————————————
10.212.4.3 0025-9e7f-fd01 I – Vlanif27
10.212.4.129 0014-38b9-73c3 0 D-0 Eth4/0/42
27/-
10.212.4.133 00e0-fc94-cddd 0 D-0 Eth4/0/42
27/-
10.212.4.203 0018-7172-5901 0 D-0 Eth4/0/42
27/-
10.212.4.107 0011-43a3-388f 0 D-0 Eth4/0/42
从现象看，Switch应该是收到了TC报文，进行了老化ARP的操作。
2、通过display stp tc命令也可以看到端口收到的TC报文情况：
[Switch-A-hidecmd] display stp tc
———- Stp Instance 0 tc or tcn count ———-
Port GigabitEthernet1/0/0 0
Port GigabitEthernet1/0/1 0
Port GigabitEthernet1/0/2 0
Port GigabitEthernet1/0/3 0
Port GigabitEthernet1/0/4 87
Port GigabitEthernet1/0/5 123
Port GigabitEthernet1/0/6 99
Port GigabitEthernet1/0/8 71
Port GigabitEthernet1/0/9 173
Port GigabitEthernet1/0/10 146
Port GigabitEthernet1/0/13 8
Port GigabitEthernet1/0/21 0
3、分析日志，日志中也显示收到TC报文、进行ARP表项老化处理的记录：
Apr 19 2011 09:59:58 DCN_S9306_A %%01MSTP/6/RECEIVE_MSTITC(l): MSTP received BPDU with TC, MSTP process 0 instance 0, port name is Ethernet4/0/46.
同时有arp-reply报文的cpcar丢弃记录：
Apr 19 2011 09:28:13 DCN_S9306_A %%01QOSE/4/CPCAR_DROP_LPU(l): Some packets are dropped by cpcar on the LPU in slot 1. (Protocol=arp-reply, Drop-Count=061)
基于上面的信息，分析得出：Switch频繁收到TC报文，进行老化ARP表项的操作。设备需要发送大量ARP探测报文，用户终端回应arp-reply报文的数量也很多，超过了cpcar的car值，部分应答报文丢弃，ARP表项就会老化删除，影响到业务应用。
Switch收到的TC报文是下面的接入交换机发送的。接入交换机直接连接PC，端口使能了STP，但是没有配置stp edged-port enable。PC在开机和关机时，很多边缘端口UP、DOWN，交换机就会反复发送TC报文。
将这些边缘端口配置stp edged-port enable后，经过几天的观察，没有再出现问题了，业务运行正常。
建议与总结
类似的问题出现过很多次，交换机做网关，下挂二层交换机接入用户，网络中使用STP协议破环。通常，二层交换机上的STP边缘端口都没有配置stp edged-port enable。用户PC上线、下线，端口就会反复UP/DOWN，设备向STP根节点发送TC报文。网关设备频繁进行STP收敛，清除ARP，导致ARP学习异常。
这种应用场景下，推荐配置：
交换机上配置stp converge normal，这样交换机收到TC报文，不会立即清除ARP，而是发起ARP探测，探测失败才会删除ARP，对流量转发不会造成很大的影响；
二层交换机的STP边缘端口上配置stp edged-port enable，这样边缘端口的状态变化不会引起网络反复进行STP收敛。
一、确认是否为近期操作导致
1、确认是否由于近期施工操作引入环路
如果环路问题是由于近期施工操作引入，可以和施工方确认，了解施工的过程，特别是新增线路、新增接入设备的细节，结合拓扑结构，确认后排除物理环路。
2、确认是否由于近期修改配置引入的环路
常见的由于修改配置引入环路的命令行如下图：
二、确认是否属于典型环路问题
1、交换机单端口自环出现环路
在网络部署的过程中，经常出现接口Tx-Rx（Tx表示光纤发送端，Rx表示光纤接收端）自环的问题，比如光纤插错、本接口被高压击坏等情况都可能导致接口Tx-Rx自环。如图所示，Switch的接口发生自环，从而导致从接口发出的报文又环回到本接口，导致流量异常、MAC地址漂移等问题。
前置条件：交换机未配置STP等破环协议以及LDT环路检测功能
问题现象：端口出方向和入方向流量持续增加。
问题原因：端口自环或者链路环回，即光纤或者网线误接造成单端口收发环回或者设备上两个端口环路。
处理方法：
在端口下去使能loopback internal。
拆除误接的连线。
2、交换机下游设备自环出现环路
如图所示，Switch下挂的网络或设备发生环路，从接口Interface1发出的报文经过Switch下挂网络或设备后被环回至本接口。
前置条件：交换机未配置STP等破环协议以及LDT环路检测功能，本端设备未环回。
问题现象：端口入方向和出方向流量持续增大，环回链路在下游设备。
问题原因：下游链路环回或者自环，即下游设备单端口收发环回或者下游设备上两个端口环路
处理方法：
逐跳向下游寻找环路的链路。
在下游设备端口下去使能loopback internal。
拆除误接的连线。
3、交换机双端口环路导致协议震荡
如图所示，Switch所在的网络或Switch不同接口之间形成了环路，从Interface1发出的报文被环回至Interface2。
前置条件：设备部署STP、RRPP、SEP或者SMLK等破环协议。
问题现象：环路一段时间收敛正常，一段时间收敛失败，或者持续震荡。
问题原因：网络上链路存在震荡，导致环网协议报文转发失败，反复超时震荡。比如：
链路存在丢包、错包，即协议报文被丢弃。
未知单播抑制、不合理的QoS等配置导致协议报文被丢弃。
处理方法：
如出现错包、丢包，建议更换问题网线、光纤或者光模块。
如因为被配置抑制功能导致丢包，建议修改单播抑制和不合理的QoS配置。
观察当前网络带宽，确认是否是网络流量拥塞，导致协议报文丢失，超时放开堵塞端口导致临时环路，此类问题需要进行网络优化。
4、下游设备报文转发异常导致伪环路问题
上面列举的二层环路现象描述主要是由于组网和配置产生了环路。现网中还存在由于单产品报文特殊转发或者是和其他厂商对接产生了类似环路的现象描述，例如出现流量突发、MAC地址漂移告警、协议报文拥塞等，但故障本质并非环路，这类现象被称为伪二层环路类故障，如下图所示。
前置条件：二层网络环路收敛正常，堵塞端口状态下发正常
问题现象：在交换机LSW3形成频繁的MAC地址漂移告警，出现疑似环路现象描述。
问题原因：二层网络的边缘设备，由于个别厂家实现差异，对于无法处理的报文，会反弹转发，常见的对端设备有机顶盒等。
处理方法：由于报文反弹，此类问题非交换机自身问题，需要客户更换边缘设备解决。
