月度归档： 2023 年 8 月

排查流程图

一、检查抓拍像素、角度

抓拍像素：

相机网页登录后再预览界面勾选接收图片，过车会产生实时抓拍信息，通过抓拍的车牌大小（像素）可以判断抓拍效果

如下左图：车牌像素是167X57，说明抓拍效果正常；

如下右图：抓拍评级C的就是存在场景以及调试不合理

 

车牌宽度小于140：

证明抓拍距离过远，或者车头较斜，需要调整抓拍线距离，以及相机角度

 

车牌抓拍角度大于5°：

需要顺时针或者逆时针调整相机的角度，使车牌抓拍照片角度小于5°

 

注：相机抓拍都是通过识别车模型来识别抓拍的，如果只用车牌做测试是无法抓拍的

二、抓拍车牌模糊因素

情况一：补光问题

Step1

进入【设置】-【相机设置】-【图形参数】-【快门设置】，图像选项里面启用宽动态适当调整数值

Step2

进入【设置】-【相机设置】-【图形参数】-【快门设置】-【曝光】，适当调整快门

Step3

红外补光值调的太高，可以调低一点，支持白光补光可以切换白光补光

情况二：画面模糊

1. 定焦的相机若实时画面和抓拍都模糊为设备调焦问题，需要售后处理

2. 变焦的相机可以在预览界面点击安装调试手动调整变倍以及焦距，达到最佳抓拍效果

三、车牌是否是标准车牌

下图是相机可以正常识别的车牌类型，请确认对应型号版本是否已经是最新的程序

如：省区AA段的新能源车牌识别不了，优先升级到最新版本

注：除下图以外的车牌，是不支持抓拍识别的，如果有需要，请在采购前提供素材后提需求评估

 

 

故障排查流程

步骤一：查看主板或红外转接板上的红外灯状态

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收敛。