V7系列交换机直连不通或者丢包问题排查前提:已通过流量统计或者抓包确定是交换机自身丢弃的报文,即设备收到了报文,但是发出的报文数目少于收到的报文数目,由于是直连丢包,那么报文肯定会上送CPU处理,因此也可以通过debug icmp packet来判断是否是设备本身丢弃了报文,由于报文会上送CPU,转发报文不上送CPU,所以和转发丢包排查思路稍有区别,排查思路如下:
二、流程相关操作说明:
通过命令display interface多次查看出入接口错包计数是否增长。
[6800]display interface GigabitEthernet8/0/2
GigabitEthernet8/0/2 current state: UP
IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: 00e0-fc00-9512
Description: GigabitEthernet8/0/2 Interface
1000Mbps-speed mode, full-duplex mode
Link speed type is autonegotiation, link duplex type is autonegotiation
Flow-control is not enabled
The Maximum Frame Length is 1552
Input (total): 19 packets, 1116 bytes
- unicasts, - broadcasts, - multicasts
Input (normal): 9 packets, 1116 bytes
0 unicasts, 0 broadcasts, 9 multicasts
Input: 10 input errors, 0 runts, 0 giants, 0 throttles
10 CRC, 0 frame, 0 overruns, - aborts
- ignored, - parity errors
Output (total): 9 packets, 1116 bytes
- unicasts, - broadcasts, - multicasts, - pauses
Output (normal): 9 packets, 1116 bytes
0 unicasts, 0 broadcasts, 9 multicasts, 0 pauses
Output: 23 output errors, - underruns, - buffer failures
0 aborts, 0 deferred, 0 collisions, 0 late collisions
- lost carrier, - no carrier
说明:在分析端口的收发包统计时,可以先通过命令reset counters interface清除原有计数。
如果接口有错包不停增加,那么可以怀疑是该问题导致网络丢包。各个错包解释如下:
(1)input errors:
各种输入错误的总数,显示范围是20bit。
(2)runts:
表示接收到的超小帧个数。超小帧即接收到的报文小于64字节,且包括有效的CRC字段,报文格式正确。
(3)giants:
表示接收到的超长帧个数。超长帧即接收到的有效报文字节长度大于1518(如果是带tag报文,大于1522),且小于设备能接收的超长帧最大值。
(4)CRC:
表示接收到的CRC校验错误报文个数,即接收到的报文在64~1518(带tag报文是1522)字节范围内,且字节是整数,而CRC校验错误。
(5)frame:
也是CRC校验出错报文个数,报文字节不是整数,其他同上。
(6)aborts:
不支持。
(7)ignored:
不支持。
4. 输出错误统计值详解
(1)output errors:
各种输出错误的总数,显示范围是20bit。
(2)aborts:
表示发送失败的报文总数,指已经开始发送,但由于各种原因(如冲突)而导致发送失败的报文。该项统计包括各类发送失败的报文,无论是二层或是三层转发。
(3)deferred:
表示延迟报文的总数。报文延迟是指因延迟过长的周期而导致发送失败的报文,而这些报文由于发送媒质繁忙而等待了超过2倍的最大报文发送时间。
(4)collisions:
表示冲突帧总数,即在发送过程中发生冲突的报文。冲突是指DO和RD信号同时出现,即发送和接收同时发生。
(5)late collisions:
表示延迟冲突帧,即发送过程中发生延迟冲突超过512bit时间的帧。
(6)lost carrier:
不支持。
(1)如果端口的CRC、frame、throttles错误统计频繁增加:
A.建议测试链路,链路质量差或者线路光衰大会导致报文在传输过程中出错。如果换过网线或光纤还是无效,有可能是连接器问题;
B.调整两端端口的工作模式;
C.排查对端设备或者中间的传输设备;
(2)如果端口的Overrun和ignored错误统计频繁增加:
Overrun和ignored是由于端口输入速率超过接受方处理能力,导致丢包。这需要通过链路聚合等方式规避。
如果现场有环路,并且环路会引起广播风暴,大量报文那么会占用接口带宽,CPU利用率增加,因此也会导致ping直连丢包。可以通过命令display mac-address mac-move来确定是否有环路。例如,下面000f-e207-f2e0这个MAC在VLAN1的GE3/0/10和GE3/0/34口漂移了几十万次,并且最近一次漂移时间为1月12号,因此判断这个时间点有环路。
<H3C>display mac-address mac-move
--- 0 MAC address moving records found ---
-------------------slot 2 MAC address moving information----------------
MAC address VLAN Current port Source port Last time Times
--- 0 MAC address moving records found ---
-------------------slot 3 MAC address moving information----------------
MAC address VLAN Current port Source port Last time Times
3ce5-a6c1-3d00 1 GE3/0/6 GE3/0/10 2018-01-05 09:44:08 5
3ce5-a6c1-3d00 1 GE3/0/10 GE3/0/6 2018-01-05 09:44:04 2
000f-e207-f2e0 1 BAGG13 GE3/0/10 2018-01-08 17:47:31 8
000f-e207-f2e0 1 GE3/0/10 BAGG13 2018-01-08 17:52:09 55
000f-e207-f2e0 1 GE3/0/34 GE3/0/10 2018-01-12 10:05:09 174088
000f-e207-f2e0 1 GE3/0/10 GE3/0/34 2018-01-12 11:04:29 175093
84d9-3123-a801 1 GE3/0/34 GE3/0/10 2018-01-09 15:22:18 13
84d9-3123-a801 1 GE3/0/10 GE3/0/34 2018-01-09 15:22:18 12
000f-e207-f2e0 1 GE3/0/33 GE3/0/10 2018-01-11 10:22:56 336
000f-e207-f2e0 1 GE3/0/10 GE3/0/33 2018-01-11 10:22:56 337
通过如上命令可以确定mac地址在哪些接口漂移,根据这些接口情况往下排查,确定环路原因。
如果现场开启了STP,有可能接口会被STP阻塞,导致直连不通,可以通过如下命令确定接口是否被阻塞。
命令:display stp brief
例如:查看是否存在STP端口被异常阻塞,例如Ge1/0/1接口的STP状态为DISCARDING。
<H3C>display stp brief
MST ID Port Role STP State Protection
0 GigabitEthernet1/0/1 DESI DISCARDING ROOT
1 GigabitEthernet1/0/2 ROOT FORWARDING NONE
……
通过如下命令可以确定接口被STP阻塞原因。
命令:display stp abnormal-port
例如:查看被生成树保护功能阻塞的端口信息。可以看到G1/0/1发生了Disputed导致接口阻塞。
<Sysname> display stp abnormal-port
MSTID Blocked Port Reason
1 GigabitEthernet1/0/1 Disputed
2 GigabitEthernet1/0/2 Loop-Protected
3 GigabitEthernet1/0/3 Loopback-Protected
4 GigabitEthernet1/0/1 Root-Protected
端口发生Dispute保护的原因如下:
交换机各端口的端口状态依靠不断接收上游交换机发送的BPDU来维持。但是由于链路拥塞或者单向链路故障,根端口会收不到上游交换机的BPDU。此时下游交换机会重新选择根端口,原来的根端口经过计算后会变为指定端口,而原来的阻塞端口重新计算后会变为根端口且迁移到转发状态,从而交换网络中会产生环路。Dispute机制会抑制这种环路的产生。
角色限制功能默认在所有端口生效,当端口收到这样的报文——报文中携带指定端口角色和Learning/Forwarding状态并且报文中的优先级向量低于接收端口的优先级向量,端口的Dispute机制生效,端口被设置为Discarding状态,阻止网络形成环路。
查看端口是否发生了Dispute保护,即端口收到了非阻塞指定端口发出的低优先级消息。如果被生成树保护功能阻塞端口的阻塞原因为Disputed,表示发生了Dispute保护。
命令:display stp abnormal-port
例如:查看被生成树保护功能阻塞的端口信息。
<SW1> display stp abnormal-port
MSTID Blocked Port Reason
0 GigabitEthernet1/0/1 Disputed
注意:H3C的V5平台设备的STP按照IEEE 802.1D-2004之前的标准实现,STP协议不具有dispute保护机制。
H3C的V7平台设备按照最新的协议标准IEEE 802.1D-2004,IEEE 802.1Q-2005和IEEE 802.1Q-2011实现的,实现了这个STP的增强特性: STP端口dispute保护。
常见的发生Dispute保护的拓扑如下:

SW1、SW2、SW3互联后,SW1和SW3使能生成树协议,SW2不使能生成树协议。SW1生成树的优先级比SW2高。SW2 G1/0/1接口配置为trunk类型,且permit vlan all;G1/0/2接口配置为trunk类型,且permit vlan all,但undo trunk permit vlan 1。使能生成树的SW1和SW3设备,当SW3与SW2互联后(SW1与SW2之前已与SW2互联)业务出现不通。接口角色均为指定端口(DEST),但是作为根桥的SW1接口为Discarding状态。在SW3的display logbuffer中看到如下提示
%Aug 13 11:00:26:922 2017 H3C STP/5/STP_BPDU_RECEIVE_EXPIRY: Instance 0"s port GigabitEthernet1/0/2 received no BPDU within the rcvdInfoWhile interval.
由于SW2不使能生成树协议,因此当SW2从SW1、SW3收到BPDU报文后,不会将此类协议报文上送本地CPU解析处理,而是由交换机芯片依照普通的二层以太网报文进行转发。
对于生成树BPDU协议报文,按照协议定义,在链路上传输时,报文在PVID VLAN中传输,二层报头中不会携带VLAN-Tag字段。因此SW2分别从G1/0/1接口和G1/0/2接口收到了SW1、SW3的BPDU报文后(不携带VLAN-Tag),将根据其接口的PVID=1,加入SW2交换机内部的VLAN 1中,并在VLAN 1中进行转发。
因为SW2的G1/0/2不允许VLAN 1通过(undo port trunk permit vlan 1),因此SW3无法收到SW1的BPDU报文。SW1能够收到SW3的BPDU报文(G1/0/1 port trunk permit vlan all)。根据上述的分析,由于SW2的特殊配置,此网络逻辑上存在单通情况。这时,需要让SW1和SW3的BPDU报文能够被正常的相互接收,即在SW2交换机G1/0/2接口上配置port trunk permit vlan 1即可。
解决方法:修改端口VLAN配置
确保链路两侧端口的VLAN配置相同,包括PVID VLAN和放通的VLAN配置。对于MSTP,BPDU报文在PVID VLAN中转发,所以端口下需要放通PVID VLAN;对于PVST,BPDU报文在相应的数据VLAN中转发,所以要确保端口下放通的VLAN配置一致,并且本地存在这些VLAN。
注:其他STP阻塞原因及排查方法,请参考:《交换机STP端口状态异常问题排查云图》。这里就不过多说明。
通过display arp 命令查看ARP是否学习正常。
例如,查看10.2.2.14对应的ARP表项是否正确:
[PE2]display arp 10.2.2.14
Type: S-Static D-Dynamic A-Authorized
IP Address MAC Address VLAN ID Interface Aging Type
10.2.2.14 70f9-6d93-b688 N/A GE2/1/14 N/A D
如果现场ARP学习异常,可以通过配置静态ARP表项确定是否和ARP学习异常相关。
命令:arp static {ip-address mac-address vlanid interface-id}
例如:
[S10500]arp static 1.1.1.1 AAAA-AAAA-AAAA 100 Ten-GigabitEthernet 1/5/0/1
[S10500]dis arp
Type: S-Static D-Dynamic O-Openflow R-Rule M-Multiport I-Invalid
IP address MAC address VLAN Interface Aging Type
1.1.1.1 aaaa-aaaa-aaaa 100 XGE1/5/0/1 N/A S
如果配置静态ARP表项后恢复正常,那么可以确定是由于ARP学习异常导致。
ARP学习异常的原因,一般有两种:
第一:设备存在ARP攻击。
第二:设备ARP超规格。
对于ARP攻击排查方法如下:
一、确定ARP报文上送CPU的速率门限值:
通过要确定ARP报文上送CPU的速率门限值, 可以通过查看copp限速值的来确定,命令是:
display qos policy control-plane pre-define
通过命令,我们可以看到对arp的限速值是1000,表示每秒上送cpu的arp报文数目最大值是1000。
[S12508]dis qos policy control-plane pre-defined slot 2
Pre-defined policy information slot 2
Protocol Priority Bandwidth (pps) Group
ARP 2 1000 normal
BGP 5 2000 critical
DHCP 0 600 normal
DHCP Snooping 0 600 redirect
DHCPv6 0 600 normal
DLDP 7 100 critical
MVRP 7 100 critical
ICMP 6 500 monitor
ICMPv6 6 500 monitor
IGMP 3 2048 important
IS-IS 5 1500 critical
LACP 7 100 critical
LDP 4 600 critical
LLDP 7 200 important
MLD 3 500 important
NTP 4 200 important
OAM 7 100 critical
OSPF Multicast 5 1500 critical
OSPF Unicast 5 1000 critical
VRRP 4 2500 important
TELNET 4 700 management
……
对于S12500X/S10500/S7500E等其他中低端交换机
对于除了S12500以外的这些中低端交换机。进入probe视图可以通过命令debug rxtx softcar show后面加框号,槽位号。来确定arp报文上送cpu的阈值,以及报文是否已经超限速了。这里我们看到默认情况下arp的速率门限是750pps。
[S7500E-probe]debug rxtx softcar show slot 2
ID Type RcvPps Rcv_All DisPkt_All Pps Dyn Swi Hash ACLmax
0 ROOT 0 0 0 1000 S On SMAC 0
1 ISIS 0 0 0 200 D On SMAC 8
2 ESIS 0 0 0 100 S On SMAC 8
3 CLNP 0 0 0 100 S On SMAC 8
4 VRRP 0 0 0 300 S On SMAC 8
……
25 IPV6_LDP 0 0 0 100 S On SMAC 8
26 IPV6_VRRP 0 0 0 300 S On SMAC 8
27 RRPP 0 0 0 200 S On SMAC 8
28 IPV4_AUTORP 0 0 0 100 S On SMAC 8
29 ARP 0 0 0 750 S On SMAC 8
30 ARP_REPLY 0 2 0 100 S On SMAC 8
……
要查看ARP报文统计情况,首先进入probe视图,通过命令:
[probe] display hardware internal nst packet-statistic chassis 2 slot 2 clear ,连续查两次,主要看第二次的值。加clear参数表示读清计数,表示第一次和第二次查的这个时间段上送的报文个数。
第二次查看时cpu code 5的packet计数,这里可以看到ARP报文上送CPU的数目每秒肯定超过了1000,因此肯定存在ARP攻击。
[S12508-probe]dis hardware internal nst packet-statistic slot 2 clear
Code Packets Code Packets Code Packets Code Packets
0 0 1 0 2 0 3 0
4 0 5 830 6 0 7 0
8 0 9 0 10 0 11 0
……
[S12508-probe]dis hardware internal nst packet-statistic slot 2 clear
Code Packets Code Packets Code Packets Code Packets
0 0 1 0 2 0 3 0
4 0 5 1201 6 0 7 0
8 0 9 0 10 0 11 0
……
S12500X/S10500/S7500E等其他中低端交换机
对于除了12500/95E以外的这些中低端交换机。依旧进入probe视图可以通过命令debug rxtx softcar show chassis chassisid slot slotid (即在后面加框号、槽位号)。可以通过这个命令查是否有arp因为超过限速丢弃的情况。
这里看到目前该单板收到的arp报文的接收速率(RcvPps)是860。由于超过arp上送CPU的速率门限而丢弃报文的个数(DisPkt_All)为1123540。
[S7500E-probe]debug rxtx softcar show slot 2
ID Type RcvPps Rcv_All DisPkt_All Pps Dyn Swi Hash ACLmax
0 ROOT 0 0 0 1000 S On SMAC 0
1 ISIS 0 0 0 200 D On SMAC 8
2 ESIS 0 0 0 100 S On SMAC 8
3 CLNP 0 0 0 100 S On SMAC 8
4 VRRP 0 0 0 300 S On SMAC 8
……
25 IPV6_LDP 0 0 0 100 S On SMAC 8
26 IPV6_VRRP 0 0 0 300 S On SMAC 8
27 RRPP 0 0 0 200 S On SMAC 8
28 IPV4_AUTORP 0 0 0 100 S On SMAC 8
29 ARP 860 1123540 0 750 S On SMAC 8
30 ARP_REPLY 0 2 0 100 S On SMAC 8
……
首先打开调试开关,t d 和t m,打印完后需要关闭这两个开关。然后进入probe视图,命令是:display hardware internal rxtx rxpkt ,然后全局槽位号,然后加length,表示打印报文长度,然后是Number表示打印的报文的数目,这里我们打印报文长度为100,个数为20,queue 2 表示ARP报文位于2队列。
[H3C]probe
[H3C-probe] display hardware internal rxtx rxpkt slot 2 len 100 num 20 que 2
*May 20 16:29:32:169 2015 HS9508E-48-BJJDSJ-CORE-1F01 RXTX/5/DRV_RXTX:Slot=6;
Packet Print Time: 2015/05/20, 16:29:31:523
packet type: tx_vlan, Slot=2, VlanNo=615
PacketLen=46, left=999
0000: ff ff ff ff ff ff 00 00 00 00 00 01 08 06 00 01
0010: 08 00 06 04 00 01 00 00 e0 fc 01 01 1e 01 01 02
0020: 00 00 00 00 00 00 1e 01 01 07 00 00 00 00 00 00
0030: 00 00 00 00 00 00 00 //标粗的数据部分用wireshake打开
……
我们可以看到这些报文的类型是0806,表示arp报文,他的目的地址是全F,所有ARP源地址都是e0fc-0101-1e01,可以确定攻击源就是这个地址。如果不会看这个报文,可以用wireshake解析:

有时候并非所有的arp攻击都会发送大量的arp报文来消耗cpu性能。如果发现arp学习错误也可以打印上送cpu的ARP报文,所有的ARP攻击都可以把报文打印出来看看是什么类型的arp攻击。然后再根据打印出来的报文类型来作攻击防范。
S12500X/S10500/S7500E等其他中低端交换机
对于S12500X/S10500/S7500E以及其他中低端交换机,打印上送cpu的的命令也有区别,也需要先进入probe视图,先设置打印的报文类型是arp类型:dis rxtx etype 0806,然后命令是debug rxtx -c 100 -s 100 pkt chassis 2 slot -c表示打印的报文的数目,-s表示打印报文的长度,pkt后面加框号和槽位号。打印之前也需要先开启t d和t m开关,打印完后关闭。
[H3C-probe]dis rxtx etype 0806 //设置报文打印的类型为arp
[H3C-probe]debug rxtx -c 100 -s 100 pkt slot 2
Debug RxTx packet is on!
1)开启源MAC固定的arp防攻击功能
我们确定了有arp扫描攻击,也找到了攻击源,对于源地址固定的ARP扫描攻击,我们需要打开设备的ARP防攻击功能:(下面是输入命令行时,预留50S)
(命令是:arp anti-attack source-mac { filter | monitor }
参数filter表示:检测到攻击后,对该源MAC地址对应的ARP报文进行过滤,对这个地址下发防攻击表项。
参数monitor表示:检测到攻击后,只打印告警信息,不对该源MAC地址对应的ARP报文进行过滤。
可以通过dis arp anti-attack source-mac 查看防攻击表项里的内容:
[H3C]dis arp anti-attack source-mac slot 5
Source-MAC VLAN ID Interface Aging-time
0000-e0fc-0101 30 GE5/0/32 292
如果认为收到的某个MAC地址的ARP报文是正常的而不需要下发防攻击表项,可以用下面的命令来处理:
[H3C] arp source-mac exclude-mac 0000-e0fc-0101
2)开启ARP速率限制配置
源MAC地址随机变化的ARP报文攻击比较难以防范,建议在端口配置ACL规则对ARP报文进行速率限制,确保一个端口受到攻击不会影响该单板其他端口的用户正常使用网络。可以在端口视图下使用命令行:
[H3C-GigabitEthernet5/0/32]arp rate-limit 10
源MAC地址变化的ARP报文攻击,一般情况下只能根据报文入端口信息确定攻击源所在端口,无法定位到具体的用户。如果需要定位到具体的用户,需要沿着攻击源所在端口继续排查。
对于ARP攻击,也可以通过配置静态ARP临时规避恢复业务,规避后再去排查攻击源。
3)开启ARP主动确认功能
对于ARP欺骗攻击,可以通过配置静态ARP临时规避,但是受静态ARP表项数量限制,建议使用如下方法:
可以在系统视图下使用命令行使能ARP主动确认功能:
[H3C] arp active-ack enable
使能ARP主动确认功能之后,当收到的ARP报文中的源MAC地址和对应ARP表项中的不同时,设备首先判断ARP表项刷新时间是否超过1分钟,如果没有超过1分钟,则不更新ARP表项。否则向ARP表项对应的源发送一个单播ARP请求报文,如果在随后的5秒内收到ARP应答报文,则忽略之前收到的ARP攻击报文;如果没有收到ARP应答报文,则向之前收到的ARP报文对应的源发送一个单播ARP请求报文,如果在随后的5秒内收到了ARP应答报文,则根据之前收到的ARP报文更新ARP表项,否则ARP表项不会被修改。
ARP报文中的源MAC地址信息包括以太网源地址和发送端以太网地址,这两个地址都表示请求发起者的MAC地址,网络设备和主机根据发送端以太网地址学习ARP表项。在正常情况下,这两个MAC地址是一致的。而在攻击源构造的地址扫描攻击报文中,由于以太网源地址是网卡驱动程序产生的,比较难以构造,通常攻击报文(病毒报文)的以太网源地址都是固定的,而发送端以太网地址是变化的,网络中经常存在该类型的ARP报文攻击。
如果是这种攻击,可以在系统视图下使用命令行开启ARP源MAC一致性检查功能:
[H3C]arp valid-check enable
注:缺省情况下, ARP报文源MAC一致性检查功能是关闭的
5)其他原因
ARP攻击的原因多种多样,需要根据网络的实际情况做进一步分析和排查。如果上述方法无法解决,建议拨打400-810-0504联系H3C技术支持工程师处理。
对于ARP超规格:
这种情况,问题表现就是ARP学习不到。
如果排除确定没有ARP攻击,那么建议拨打400-810-0504联系H3C技术支持工程师处理。
交换机依靠交换芯片硬件转发,一些协议报文,比如STP、OSPF和PING设备虚接口的ICMP报文需要上送CPU处理。而CPU的处理能力是有限的,为了防止网络终端设备恶意通过PING设备接口造成CPU高的情况,交换机对ICMP报文做了如下处理:
设置ICMP报文优先级最低;设置软硬件限速。其中软硬件限速就是我们说的PING保护机制。
如果现场有大量的ICMP上送CPU,超过上送CPU的ICMP报文速率阈值,那么会导致正常ICMP报文丢失,可能就存在直连ping不通或者丢包的情况。确定上送CPU报文多的方式如排查ARP报文多的方式一样。
对于S12500系列交换机:
要查看ICMP报文统计情况,首先进入probe视图,通过命令:
[probe] display hardware internal nst packet-statistic chassis 2 slot 2 clear ,连续查两次,主要看第二次的值。加clear参数表示读清计数,表示第一次和第二次查的这个时间段上送的报文个数。ICMP上送CPU的报文速率阈值是500PPS。
第二次查看时cpu code 217的packet计数,这里可以看到ICMP报文上送CPU的数目每秒肯定超过了500,因此肯定存在ICMP攻击情况。
[S12508-probe]dis hardware internal nst packet-statistic slot 2 clear
Code Packets Code Packets Code Packets Code Packets
0 0 1 0 2 0 3 0
4 0 5 830 6 0 7 0
……
216 0 217 2 218 0 219 0
220 0 221 12698 222 0 223 0
[S12508-probe]dis hardware internal nst packet-statistic slot 2 clear
Code Packets Code Packets Code Packets Code Packets
0 0 1 0 2 0 3 0
4 0 5 830 6 0 7 0
……
216 0 217 13221 218 0 219 0
220 0 221 98 222 0 223 0
S12500X/S10500/S7500E等其他中低端交换机
对于除了S12500系列以外的其他中低端V系列交换机。依旧进入probe视图可以通过命令debug rxtx softcar show {chassis-id slot-id}{对应框号、槽位号}。可以通过这个命令查是否有ICMP因为超过限速丢弃的情况。
这里看到目前该单板收到的ICMP报文的接收速率(RcvPps)是512。由于超过ICMP上送CPU的速率门限(500PPS)而丢弃报文的个数(DisPkt_All)为354732。
[H3C-probe]debug rxtx softcar show slot 2
ID Type RcvPps Rcv_All DisPkt_All Pps Dyn Swi Hash ACLmax
0 ROOT 0 0 0 1000 S On SMAC 0
1 ISIS 0 0 0 1000 D On SMAC 8
2 ESIS 0 0 0 300 S On SMAC 8
3 CLNP 0 0 0 300 S On SMAC 8
4 VRRP 0 0 0 1000 S On SMAC 8
……
29 ARP 0 3536 0 1000 S On SMAC 8
30 ARP_REPLY 0 16 0 1000 S On SMAC 8
38 GVRP 0 0 0 300 S On SMAC 8
39 HGMP 0 0 0 300 S On SMAC 8
40 BGP 0 533 0 1000 S On SMAC 8
41 ICMP 512 52351434 354732 200 S On SMAC 8
……
通过debug ip icmp或者打印上送CPU的报文来确定ICMP报文的源地址,确定是否是攻击,通过配置包过滤等方式过滤掉攻击源。
如果CPU利用率高,可能导致上送CPU的报文不能及时处理,所以会引起直连ping不通。通过命令display cpu查看CPU利用率是否高。
[H3C]display cpu
Slot 2 CPU 0 CPU usage:
12% in last 5 seconds
8% in last 1 minute
8% in last 5 minutes
通过display process cpu 来判断CPU高的任务。
H3C]display process cpu slot 2
CPU utilization in 5 secs: 9.4%; 1 min: 8.6%; 5 mins: 8.3%
JID 5Sec 1Min 5Min Name
1 0.0% 0.0% 0.0% scmd
……
130 0.0% 0.0% 0.0% [GLD1]
131 0.1% 0.1% 0.1% [MSGR0]
133 0.0% 0.0% 0.0% [DPCIE]
134 0.0% 0.0% 0.0% [bDPC]
135 0.0% 0.0% 0.0% [D_P0]
136 0.5% 0.5% 0.3% [bPAR]
138 0.0% 0.0% 0.0% [des0]
139 0.1% 0.0% 0.0% [bMS0]
140 0.0% 0.0% 0.0% [bcmS]
142 1.6% 1.6% 1.6% [L2X0]
143 0.0% 0.0% 0.0% [bcmL]
144 1.8% 1.6% 1.6% [bC.0]……
……
由于不同产品的任务有差异,如果有些任务不知道具体含义,并且经过排查后CPU利用率始终无法降下来,请拨打4008100504寻求帮助。
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作