手册下载
H3C SecCenter CSAP-NTA系列 网络全流量威胁分析探针
故障处理手册
资料版本:5W600-20210427
Copyright © 2021 新华三技术有限公司 版权所有,保留一切权利。
非经本公司书面许可,任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部,并不得以任何形式传播。
除新华三技术有限公司的商标外,本手册中出现的其它公司的商标、产品标识及商品名称,由各自权利人拥有。
本文档中的信息可能变动,恕不另行通知。
本文档介绍H3C SecCenter CSAP-NTA-V200、CSAP-NTA-V1000软、硬件常见故障的诊断及处理措施。
设备正常运行时,建议您在完成重要功能的配置后,及时保存并备份当前配置,以免设备出现故障后配置丢失。建议您定期将配置文件备份至远程服务器上,以便故障发生后能够迅速恢复配置。
在进行故障诊断和处理时,请注意以下事项:
· 设备出现故障时,请尽可能全面、详细地记录现场信息(包括但不限于以下内容),收集信息越全面、越详细,越有利于故障的快速定位。
¡ 记录具体的故障现象、故障时间、配置信息。
¡ 记录完整的网络拓扑,包括组网图、端口连接关系、故障位置。
¡ 收集设备的日志信息和诊断信息(收集方法见1.2 收集设备运行信息)。
¡ 记录现场采取的故障处理措施(比如配置操作、插拔线缆、手工重启设备)及实施后的现象效果。
¡ 记录故障处理过程中配置的所有命令行显示信息。
· 更换和维护设备部件时,请佩戴防静电手腕,以确保您和设备的安全。
为方便故障快速定位,请使用命令info-center enable开启信息中心。缺省情况下信息中心处于开启状态。
设备运行过程中会产生logfile、diagfile日志信息及记录设备运行状态的诊断信息。这些信息存储在主用主控板的Flash,可以通过FTP、TFTP等方式导出。
如果设备运行过程中发生过主备倒换,则日志文件将保存在设备多个主控板中,不同主控板中导出的logfile、diagfile、诊断信息文件请按照一定规则存放(如不同的文件夹:slotX),避免不同主控板的运行信息相互混淆,以方便查询。
表1-1 设备运行信息介绍
分类 |
文件名 |
内容 |
logfile日志 |
logfile.log |
命令行记录、设备运行中产生的记录信息 |
diagfile日志 |
diagfile.log |
设备运行中产生的诊断日志信息,如系统运行到错误流程时的参数值、单板无法启动时的信息、主控板与接口板通信异常时的握手信息 |
诊断信息 |
XXX.gz |
系统当前多个功能模块运行的统计信息,包括设备状态、CPU状态、内存状态、配置情况、软件表项、硬件表项等 |
(1) 执行logfile save命令将日志文件缓冲区中的内容全部保存到日志文件中。日志文件缺省存储在Flash的logfile目录中。
· 在vNTA上收集对应的日志文件。
<Sysname> logfile save
The contents in the log file buffer have been saved to the file flash:/logfile/logfile.log
(2) 查看日志文件名称。
<Sysname> dir flash:/logfile/
Directory of flash:/logfile
0 -rw- 27834 Mar 10 2021 15:53:23 logfile1.log
3126552 KB total (2537968 KB free)
(3) 使用FTP或者TFTP将日志文件传输到指定位置。
(1) 执行diagnostic-logfile save命令将诊断日志文件缓冲区中的内容全部保存到诊断日志文件中。诊断日志文件缺省存储在Flash的diagfile目录中。
· 收集诊断日志文件:
<Sysname> diagnostic-logfile save
The contents in the diagnostic log file buffer have been saved to the file flash:/diagfile/diagfile.log
(2) 查看诊断日志文件:
<Sysname> dir flash:/diagfile/
Directory of flash:/diagfile
0 -rw- 161321 Mar 10 2015 15:38:00 diagfile.log
1021104 KB total (421416 KB free)
(3) 使用FTP或者TFTP将日志文件传输到指定位置。
诊断信息可以通过两种方式收集:将诊断信息保存到文件,或者将诊断信息直接显示在屏幕上。为保证信息收集的完整性,建议您使用将诊断信息保存到文件的方式收集诊断信息。
(1) 需要注意的是,设备上单板越多,诊断信息收集的时间越长,信息收集期间不能输入命令,请耐心等待。执行screen-length disable命令,以避免屏幕输出被打断(如果是将诊断信息保存到文件中,则忽略此步骤)。
<Sysname> screen-length disable
(2) 执行display diagnostic-information命令收集诊断信息。
<Sysname> display diagnostic-information
Save or display diagnostic information (Y=save, N=display)? [Y/N] :
(3) 选择将诊断信息保存至文件中,还是将直接在屏幕上显示
· 输入“Y”,以及保存诊断信息的路径和名称,将诊断信息保存至文件中。
Save or display diagnostic information (Y=save, N=display)? [Y/N] : Y
Please input the file name(*.tar.gz)[flash:/diag.tar.gz]:diag_20150810_1702.tar.
gz
Diagnostic information is outputting to flash:/diag.tar.gz.
Please wait...
Save successfully.
<Sysname> dir flash:/
Directory of flash:
……
12 -rw- 99644 Mar 10 2015 17:03:04 diag_20150810_1702.tar.gz
1021808 KB total (259072 KB free)
· 输入“N”,将诊断信息直接显示在屏幕上。
Save or display diagnostic information (Y=save, N=display)? [Y/N] :n
==================================================================
===============display cpu===============
Slot 1 CPU 0 CPU usage:
0% in last 5 seconds
7% in last 1 minute
0% in last 5 minutes
Slot 2 CPU 0 CPU usage:
0% in last 5 seconds
0% in last 1 minute
0% in last 5 minutes
=================================================================
===============display cpu-usage history===============
100%|
95%|
90%|
85%|
80%|
75%|
70%|
65%|
60%|
55%|
50%|
45%|
40%|
35%|
30%|
25%|
20%|
15%|
10%| ##
5%|# # ##
------------------------------------------------------------
10 20 30 40 50 60 (minutes)
cpu-usage (Slot 1 CPU 0) last 60 minutes (SYSTEM)
100%|
95%|
90%|
85%|
80%|
75%|
70%|
65%|
60%|
55%|
50%|
45%|
40%|
35%|
30%|
25%|
20%|
15%|
10%|
5%|
------------------------------------------------------------
10 20 30 40 50 60 (minutes)
cpu-usage (Slot 2 CPU 0) last 60 minutes (SYSTEM)
=================================================================
===============display process===============
JID PID %CPU %MEM STAT PRI TTY HH:MM:SS COMMAND
1 1 0.0 0.0 S 120 - 00:00:03 scmd
2 2 0.0 0.0 S 115 - 00:00:00 [kthreadd]
3 3 0.0 0.0 S 99 - 00:00:00 [migration/0]
4 4 0.0 0.0 S 115 - 00:00:00 [ksoftirqd/0]
5 5 0.0 0.0 S 99 - 00:00:00 [watchdog/0]
6 6 0.0 0.0 S 115 - 00:00:01 [events/0]
7 7 0.0 0.0 S 115 - 00:00:00 [khelper]
8 8 0.0 0.0 S 115 - 00:00:00 [kblockd/0]
9 9 0.0 0.0 S 115 - 00:00:00 [kacpid]
10 10 0.0 0.0 S 115 - 00:00:00 [kacpi_notify]
11 11 0.0 0.0 S 115 - 00:00:00 [ata/0]
12 12 0.0 0.0 S 115 - 00:00:00 [ata_aux]
13 13 0.0 0.0 S 115 - 00:00:00 [ksuspend_usbd]
14 14 0.0 0.0 S 115 - 00:00:00 [khubd]
15 15 0.0 0.0 S 115 - 00:00:00 [kseriod]
16 16 0.0 0.0 S 120 - 00:00:00 [vzmond]
……
当故障无法自行解决时,请准备好设备运行信息、故障现象等材料,发送给H3C技术支持人员进行故障定位分析。
用户支持邮箱:service@h3c.com
技术支持热线电话:400-810-0504(手机、固话均可拨打)
针对客户的项目,提供有针对性的开局指导,规范开局配置,提前消除开局隐患,杜绝低级配置错误,保证项目的顺利进行。
另外,由于产品支持多种组网应用,各个局点的配置均不尽相同。本自检表检查一个比较全面的开局组网,实际开局时可以根据具体情况采用实际应用部分进行自检。
编码 |
检查项目 |
检查分项目 |
检查方法 |
结 果 |
备 注 |
1 |
设备状态检查 |
设备运行状况 |
display device |
□合格 □不合格 □不涉及 |
设备应该是Normal状态。 |
2 |
设备自检 |
引擎是否保存有配置文件? |
使用命令dir |
□合格 □不合格 □不涉及 |
如果不存在配置文件,请执行save命令(不加任何参数)。save命令会将当前配置保存到设备存储介质的根目录。此时保存的文件就是下次启动时的配置文件。 |
3 |
CPU占用率 |
连续多次观察CPU占用率,CPU占用率波动是否超过10%?或CPU占用率是否一直较高(CPU占用率是否超过60%?) |
连续多次使用display cpu-usage命令查看CPU占用率 |
□合格 □不合格 □不涉及 |
请打开debug ip packet查看上CPU报文,根据报文分析原因。 |
4 |
内存占用率 |
主用主控板和备用主控板内存占用率是否在60%以下? |
display memory |
□合格 □不合格 □不涉及 |
如果内存高于60%,需要通过Probe视图下的display system internal kernel memory pool slot命令确认哪个模块占用内存过大,以便排查。 |
10 |
OSPF自检 |
是否有设备Router ID设置成相同? |
display ospf peer |
□合格 □不合格 □不涉及 |
如果存在这个问题,会导致路由学习错误,需要修改Route ID后,执行reset ospf process命令重启OSPF进程。 |
是否有大量错误? |
display ospf statistics error |
□合格 □不合格 □不涉及 |
如果存在大量的OSPF统计错误信息记录,并且还在不断增加,需要抓取信息进一步分析。 |
||
路由是否存在较大震荡? |
display ip routing-table statistics 查看added和deleted数据与系统运行时间对应是否比较大 |
□合格 □不合格 □不涉及 |
如果有,请仔细分析变化的具体路由,然后根据该路由查找到路由的原设备,分析具体震荡原因。可以在出现故障时,使用display ospf lsdb命令多次查看路由的age信息,确认哪条路由在频繁振荡。 |
||
OSPF状态是否稳定? |
display ospf peer |
□合格 □不合格 □不涉及 |
查看OSPF邻居的UP时间。 |
||
11 |
ARP检查 |
是否存在大量ARP冲突? |
display logbuffer |
□合格 □不合格 □不涉及 |
检查冲突地址,根据IP地址排除该主机。 |
12 |
路由检查 |
缺省路由是否正常? 是否存在路由环路? |
使用tracert 1.1.1.1等明显不存在网段看是否存在路由环路,使用debug ip packet,打印部分报文,看是否存在TTL=1或者=0的报文 |
□合格 □不合格 □不涉及 |
如果存在路由环路,请检查对应的设备是否配置正确。调整路由,去掉路由环路。如果存在TTL超时报文,请分析对应网段路由是否正常。 |
连续使用命令display cpu-usage查看CPU的占用率。如果CPU占用率持续在80%以上,说明有某个任务长时间占用CPU,需要确认CPU高的具体原因。
图3-1 故障诊断流程图
通过Probe视图下的display process cpu命令观察占用CPU最多的任务。
[Device-probe]display process cpu
CPU utilization in 5 secs: 2.4%; 1 min: 2.5%; 5 mins: 2.4%
JID 5Sec 1Min 5Min Name
1 0.0% 0.0% 0.0% scmd
2 0.0% 0.0% 0.0% [kthreadd]
3 0.0% 0.0% 0.0% [migration/0]
4 0.0% 0.0% 0.0% [ksoftirqd/0]
5 0.0% 0.0% 0.0% [watchdog/0]
6 0.0% 0.0% 0.0% [migration/1]
7 0.0% 0.0% 0.0% [ksoftirqd/1]
8 0.0% 0.0% 0.0% [watchdog/1]
9 0.0% 0.0% 0.0% [migration/2]
10 0.0% 0.0% 0.0% [ksoftirqd/2]
11 0.0% 0.0% 0.0% [watchdog/2]
各列分别表示某任务平均5sec、1min、5min占用CPU的百分比和任务名。某任务占用率越高,说明相应的任务占用CPU的资源越多。正常情况任务对CPU的占用率一般低于5%,这个命令可以查看明显高出正常占用率的任务。
通过Probe视图下的follow job job-id命令确认异常任务的调用栈。
[Device-probe]follow job 143
Attaching to process 143 (getty)
Iteration 1 of 5
------------------------------
Thread (LWP 143):
Switch counts: 9
User stack:
#0 0x00007fa0b0a8002c in wait4+0x14/0x2e
#1 0x0000000000401b01 in PosternFatherDo+0x2a/0x41
#2 0x0000000000401b59 in CirculatePosten+0x41/0x57
#3 0x0000000000401c29 in PosternSection+0x5d/0x71
#4 0x0000000000401eac in RunGetty+0xed/0x111
#5 0x0000000000401c82 in main+0x45/0x51
#6 0x00007fa0b0aac8d0 in __uClibc_main+0x242/0x26c
#7 0x0000000000401909 in _start+0x29/0x2a
Kernel stack:
[<ffffffff8023eda9>] do_wait+0xad9/0xd80
[<ffffffff8023f0b6>] sys_wait4+0x66/0xd0
[<ffffffff8020919a>] system_call_after_swapgs+0x8a/0x8f
[<ffffffffffffffff>] 0xffffffffffffffff
Iteration 2 of 5
------------------------------
Thread (LWP 143):
Switch counts: 11
User stack:
#0 0x00007fa0b0a8002c in wait4+0x14/0x2e
#1 0x0000000000401b01 in PosternFatherDo+0x2a/0x41
#2 0x0000000000401b59 in CirculatePosten+0x41/0x57
#3 0x0000000000401c29 in PosternSection+0x5d/0x71
#4 0x0000000000401eac in RunGetty+0xed/0x111
#5 0x0000000000401c82 in main+0x45/0x51
#6 0x00007fa0b0aac8d0 in __uClibc_main+0x242/0x26c
#7 0x0000000000401909 in _start+0x29/0x2a
Kernel stack:
[<ffffffff8023eda9>] do_wait+0xad9/0xd80
[<ffffffff8023f0b6>] sys_wait4+0x66/0xd0
[<ffffffff8020919a>] system_call_after_swapgs+0x8a/0x8f
[<ffffffffffffffff>] 0xffffffffffffffff
Iteration 3 of 5
------------------------------
Thread (LWP 143):
Switch counts: 13
User stack:
#0 0x00007fa0b0a8002c in wait4+0x14/0x2e
#1 0x0000000000401b01 in PosternFatherDo+0x2a/0x41
#2 0x0000000000401b59 in CirculatePosten+0x41/0x57
#3 0x0000000000401c29 in PosternSection+0x5d/0x71
#4 0x0000000000401eac in RunGetty+0xed/0x111
#5 0x0000000000401c82 in main+0x45/0x51
#6 0x00007fa0b0aac8d0 in __uClibc_main+0x242/0x26c
#7 0x0000000000401909 in _start+0x29/0x2a
Kernel stack:
[<ffffffff8023eda9>] do_wait+0xad9/0xd80
[<ffffffff8023f0b6>] sys_wait4+0x66/0xd0
[<ffffffff8020919a>] system_call_after_swapgs+0x8a/0x8f
[<ffffffffffffffff>] 0xffffffffffffffff
Iteration 4 of 5
------------------------------
Thread (LWP 143):
Switch counts: 15
User stack:
#0 0x00007fa0b0a8002c in wait4+0x14/0x2e
#1 0x0000000000401b01 in PosternFatherDo+0x2a/0x41
#2 0x0000000000401b59 in CirculatePosten+0x41/0x57
#3 0x0000000000401c29 in PosternSection+0x5d/0x71
#4 0x0000000000401eac in RunGetty+0xed/0x111
#5 0x0000000000401c82 in main+0x45/0x51
#6 0x00007fa0b0aac8d0 in __uClibc_main+0x242/0x26c
#7 0x0000000000401909 in _start+0x29/0x2a
Kernel stack:
[<ffffffff8023eda9>] do_wait+0xad9/0xd80
[<ffffffff8023f0b6>] sys_wait4+0x66/0xd0
[<ffffffff8020919a>] system_call_after_swapgs+0x8a/0x8f
[<ffffffffffffffff>] 0xffffffffffffffff
Iteration 5 of 5
------------------------------
Thread (LWP 143):
Switch counts: 17
User stack:
#0 0x00007fa0b0a8002c in wait4+0x14/0x2e
#1 0x0000000000401b01 in PosternFatherDo+0x2a/0x41
#2 0x0000000000401b59 in CirculatePosten+0x41/0x57
#3 0x0000000000401c29 in PosternSection+0x5d/0x71
#4 0x0000000000401eac in RunGetty+0xed/0x111
#5 0x0000000000401c82 in main+0x45/0x51
#6 0x00007fa0b0aac8d0 in __uClibc_main+0x242/0x26c
#7 0x0000000000401909 in _start+0x29/0x2a
Kernel stack:
[<ffffffff8023eda9>] do_wait+0xad9/0xd80
[<ffffffff8023f0b6>] sys_wait4+0x66/0xd0
[<ffffffff8020919a>] system_call_after_swapgs+0x8a/0x8f
[<ffffffffffffffff>] 0xffffffffffffffff
记录上述步骤所获得的信息,并收集设备的运行信息。将所有信息反馈给H3C技术人员寻求技术支持。
使用display memory命令查看内存信息。如果内存占用率在持续的一段时间内(一般为30分钟)高于60%,那么可能存在内存异常问题,需要关注。
图3-2 故障诊断流程图
通过Probe视图下的display system internal kernel memory pool命令查看各块内存使用情况。
[Sysname-probe]display system internal kernel memory pool
Active Number Size Align Slab Pg/Slab ASlabs NSlabs Name
9126 9248 64 8 32 1 289 289 kmalloc-64
105 112 16328 0 2 8 54 56 kmalloc-16328
14 14 2097096 0 1 512 14 14 kmalloc-2097096
147 225 2048 8 15 8 12 15 kmalloc-2048
7108 7232 192 8 32 2 226 226 kmalloc-192
22 22 524232 0 1 128 22 22 kmalloc-524232
1288 1344 128 8 21 1 64 64 kmalloc-128
0 0 67108808 0 1 16384 0 0 kmalloc-67108808
630 651 4096 8 7 8 93 93 kmalloc-4096
68 70 131016 0 1 32 68 70 kmalloc-131016
1718 2048 8 8 64 1 31 32 kmalloc-8
1 1 16777160 0 1 4096 1 1 kmalloc-16777160
2 15 2048 0 15 8 1 1 sgpool-64
0 0 40 0 42 1 0 0 inotify_event_cache
325 330 16328 8 2 8 165 165 kmalloc_dma-16328
0 0 72 0 30 1 0 0 LFIB_IlmEntryCache
0 0 1080 0 28 8 0 0 LFIB_IlmEntryCache
0 0 1464 0 21 8 0 0 MFW_FsCache
1 20 136 0 20 1 1 1 L2VFIB_Ac_cache
0 0 240 0 25 2 0 0 CCF_JOBDESC
0 0 88 0 26 1 0 0 NS4_Aggre_TosSrcPre
0 0 128 0 21 1 0 0 IPFS_CacheHash_cachep
---- More ----
Active列表示使用中的内存对象数目,Number列表示可使用的内存对象的总个数。如第一行表示分配为64字节一块的内存总共9248个,使用中的9126个。若Active占Number的比例不断增加,说明可能存在内存泄漏情况。
通过Probe视图下的view /sys/kernel/slab/<modulename>/alloc_calls命令查看各内存块调研情况。此处以显示信息中kmalloc-2048模块为例。
[Sysname-probe]view /sys/kernel/slab/kmalloc-2048/alloc_calls
23 kque_create+0x58/0x260 age=4262117/4404939/4692659 pid=128-372 cpus=0,2-3
2 sys_init_module+0x1bdc/0x1e50 age=4746250/4748179/4750108 pid=109-128 cpus=9,12
4 __vmalloc_area_node+0x154/0x1b0 age=4652363/4677089/4747310 pid=128-166
cpus=0-1,12
16 percpu_populate+0x3c/0x60 age=4322758/4322758/4322758 pid=128 cpus=0
21 alloc_pipe_info+0x24/0x60 age=4/3888025/4320768 pid=1-564 cpus=0-4,9,11
29 alloc_pci_dev+0x18/0x40 age=4758366/4758366/4758368 pid=1 cpus=15
2 init_dev+0x1c0/0x870 age=510128/2630142/4750157 pid=1-542 cpus=0,2
1 init_dev+0x4dc/0x870 age=510128 pid=542 cpus=2
2 kobj_map_init+0x2c/0xd0 age=4758371/4758535/4758700 pid=0-1 cpus=0,15
2 usb_alloc_dev+0x38/0x200 age=4750540/4750605/4750671 pid=1 cpus=15
1 usb_create_hcd+0x34/0x120 age=4750540 pid=1 cpus=15
16 exception_notifier_init+0x298/0x4f8 age=4750380/4750380/4750381 pid=1 cpus=15
1 drv_port_module_varialbe_init+0x24/0x80 [system] age=4651959 pid=128 cpus=0
1 DRV_VLAN_BasicFunc_Init+0x1ec/0x700 [system] age=4651871 pid=128 cpus=0
1 drv_vlan_maccash_init+0x124/0x240 [system] age=4651869 pid=128 cpus=0
1 drv_ipmc_spec_init+0x54/0x840 [system] age=4650355 pid=128 cpus=0
1 drv_evb_add_broadcast_group+0x964/0xa50 [system] age=4264182 pid=312 cpus=1
2 DRV_EVB_MAP_AddRec+0x160/0x2a0 [system] age=4264142/4264175/4264209 pid=288 cpus=9
1 drv_evi_localmac_init+0x160/0x650 [system] age=4651896 pid=128 cpus=0
1 DRV_QINQ_Init+0x278/0x890 [system] age=4650270 pid=128 cpus=0
1 DRV_QINQ_Init+0x478/0x890 [system] age=4650270 pid=128 cpus=0
1 Drv_Qacl_InitAddUdfTemplate+0x68/0xb30 [system] age=4651968 pid=128 cpus=0
1 drv_qacl_sal_rsc_init+0xc8/0x210 [system] age=4651968 pid=128 cpus=0
---- More ----
上述显示信息中,第一列表示内存对象个数,后面是内存分配的调用关系。
从上述命令中可以找到分配数量明显不正常的项,或者记录完整的信息给H3C的技术支持工程师以供后续故障定位和排除使用。
通过上述步骤只是确定了问题的范围,但还需继续收集信息以确定具体是哪些代码有问题。由于后续信息收集要求较高,不建议用户操作,请与H3C的技术支持工程师联系。需要注意的是:此时,不得重启设备,否则设备重启后,由于缺少故障出现时的信息而给故障定位带来困难。
命令 |
说明 |
display cpu-usage |
显示CPU利用率的统计信息 |
display process cpu |
Probe视图下命令,显示各任务占用CPU的情况 |
display memory |
显示内存使用情况 |
display system internal kernel memory pool |
Probe视图下命令,查看各块内存使用情况 |
follow job job-id |
Probe视图下命令,显示异常任务的调用栈 |
view /sys/kernel/slab/<modulename>/alloc_calls |
Probe视图下命令,显示内存分配块数以及调用关系 |
端口状态为UP,但无法接收报文。
图4-1 故障诊断流程图
检查两端端口状态是否一直UP,并使用display interface命令查看入方向的报文统计是否增长。为方便查看,也可以使用reset counter interface清空当前端口的报文统计结果再进行观察。同时,查看对端是否有发送报文统计。检查端口错包统计是否持续增长。
可通过以下步骤检查端口配置是否影响报文的接收:
查看端口与服务器网口的绑定关系是否有异常,若有异常,请修改绑定关系,看故障端口是否恢复正常。如果故障端口仍未恢复正常,请先执行shutdown命令后,再执行undo shutdown命令,再次查看端口是否能恢复正常。
检查服务器网卡是否工作正常(查看网卡指示灯是否正常点亮等);更换互联中间链路设备或传输介质(网线、光纤、服务器网卡等)后查看故障端口是否恢复正常。收集信息并寻求技术支持
如果完成了上述排查后,故障现象仍未消除,请收集设备运行信息,并联系H3C的技术支持工程师
端口状态为UP,但不发送收报文。
图4-2 故障诊断流程图
检查两端端口状态是否一直UP,并使用display interface 命令查看出方向的报文统计是否增长。为方便查看,也可以使用reset counter interface命令清空端口当前的报文统计结果再进行观察。检查端口错包统计是否持续增长。
可通过以下步骤检查端口配置是否影响报文的发送:
查看端口与服务器网口的绑定关系是否有异常,若有异常,请修改绑定关系,看故障端口是否恢复正常。如果故障端口仍未恢复正常,请先执行shutdown命令后,再执行undo shutdown命令,再次查看端口是否能恢复正常。
检查服务器网卡是否工作正常(查看网卡指示灯是否正常点亮等);更换互联中间链路设备或传输介质(网线、光纤、服务器网卡等)后查看故障端口是否恢复正常。收集信息并寻求技术支持
如果完成了上述排查后,故障现象仍未消除,请收集设备运行信息,并联系H3C的技术支持工程师
命令 |
说明 |
display diagnostic-information |
显示或保存系统当前多个功能模块运行的统计信息 |
display interface |
显示以太网端口的相关信息 |
display interface brief |
显示接口的概要信息 |
display logbuffer |
显示系统日志缓冲区的状态和缓冲区记录的日志信息 |