H3C SecCenter CSAP-NTA系列 网络全流量威胁分析探针

故障处理手册

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

资料版本：5W600-20210427

 

目  录

1 简介··· 1

1.1 故障处理注意事项·· 1

1.2 收集设备运行信息·· 1

1.2.1 logfile日志·· 2

1.2.2 diagfile日志·· 2

1.2.3 诊断信息·· 2

1.3 故障处理求助方式·· 5

2 开局自检··· 5

2.1 自检目的·· 5

2.2 开局自检项·· 5

3 系统类故障处理··· 7

3.1 CPU占用率高问题处理方法·· 7

3.1.1 故障描述·· 7

3.1.2 故障处理流程·· 7

3.1.3 故障处理步骤·· 7

3.2 内存占用率高问题处理方法·· 10

3.2.1 故障描述·· 10

3.2.2 故障处理流程·· 10

3.2.3 故障处理步骤·· 10

3.3 故障诊断命令·· 12

4 端口类故障处理··· 13

4.1 端口不接收报文故障处理·· 13

4.1.1 故障描述·· 13

4.1.2 故障处理流程·· 13

4.1.3 故障处理步骤·· 13

4.2 端口不发送报文故障处理·· 14

4.2.1 故障描述·· 14

4.2.2 故障处理流程·· 14

4.2.3 故障处理步骤·· 15

4.3 故障诊断命令·· 15

 

1 简介

本文档介绍H3C SecCenter CSAP-NTA-V200、CSAP-NTA-V1000软、硬件常见故障的诊断及处理措施。

1.1  故障处理注意事项

 

在进行故障诊断和处理时，请注意以下事项：

·     设备出现故障时，请尽可能全面、详细地记录现场信息（包括但不限于以下内容），收集信息越全面、越详细，越有利于故障的快速定位。

¡     记录具体的故障现象、故障时间、配置信息。

¡     记录完整的网络拓扑，包括组网图、端口连接关系、故障位置。

¡     收集设备的日志信息和诊断信息（收集方法见1.2  收集设备运行信息）。

¡     记录现场采取的故障处理措施（比如配置操作、插拔线缆、手工重启设备）及实施后的现象效果。

¡     记录故障处理过程中配置的所有命令行显示信息。

·     更换和维护设备部件时，请佩戴防静电手腕，以确保您和设备的安全。

1.2  收集设备运行信息

 

设备运行过程中会产生logfile、diagfile日志信息及记录设备运行状态的诊断信息。这些信息存储在主用主控板的Flash，可以通过FTP、TFTP等方式导出。

如果设备运行过程中发生过主备倒换，则日志文件将保存在设备多个主控板中，不同主控板中导出的logfile、diagfile、诊断信息文件请按照一定规则存放（如不同的文件夹：slotX），避免不同主控板的运行信息相互混淆，以方便查询。

表1-1 设备运行信息介绍

分类	文件名	内容
logfile日志	logfile.log	命令行记录、设备运行中产生的记录信息
diagfile日志	diagfile.log	设备运行中产生的诊断日志信息，如系统运行到错误流程时的参数值、单板无法启动时的信息、主控板与接口板通信异常时的握手信息
诊断信息	XXX.gz	系统当前多个功能模块运行的统计信息，包括设备状态、CPU状态、内存状态、配置情况、软件表项、硬件表项等

 

1.2.1  logfile日志

(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.2.2  diagfile日志

(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.2.3  诊断信息

诊断信息可以通过两种方式收集：将诊断信息保存到文件，或者将诊断信息直接显示在屏幕上。为保证信息收集的完整性，建议您使用将诊断信息保存到文件的方式收集诊断信息。

(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]                    

……

1.3  故障处理求助方式

当故障无法自行解决时，请准备好设备运行信息、故障现象等材料，发送给H3C技术支持人员进行故障定位分析。

用户支持邮箱：service@h3c.com

技术支持热线电话：400-810-0504（手机、固话均可拨打）

2 开局自检

2.1  自检目的

针对客户的项目，提供有针对性的开局指导，规范开局配置，提前消除开局隐患，杜绝低级配置错误，保证项目的顺利进行。

另外，由于产品支持多种组网应用，各个局点的配置均不尽相同。本自检表检查一个比较全面的开局组网，实际开局时可以根据具体情况采用实际应用部分进行自检。

2.2  开局自检项

编码	检查项目	检查分项目	检查方法	结    果	备  注
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超时报文，请分析对应网段路由是否正常。

 

3 系统类故障处理

3.1  CPU占用率高问题处理方法

3.1.1  故障描述

连续使用命令display cpu-usage查看CPU的占用率。如果CPU占用率持续在80％以上，说明有某个任务长时间占用CPU，需要确认CPU高的具体原因。

3.1.2  故障处理流程

图3-1 故障诊断流程图

 

3.1.3  故障处理步骤

1. 确定CPU占用率高的任务

通过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%，这个命令可以查看明显高出正常占用率的任务。

2. 确认异常任务的调用栈

通过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

3. 收集信息并寻求技术支持

记录上述步骤所获得的信息，并收集设备的运行信息。将所有信息反馈给H3C技术人员寻求技术支持。

3.2  内存占用率高问题处理方法

3.2.1  故障描述

使用display memory命令查看内存信息。如果内存占用率在持续的一段时间内（一般为30分钟）高于60％，那么可能存在内存异常问题，需要关注。

3.2.2  故障处理流程

图3-2 故障诊断流程图

 

3.2.3  故障处理步骤

1. 确定各内存块使用情况

通过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的比例不断增加，说明可能存在内存泄漏情况。

2. 确定内存异常的具体模块

通过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的技术支持工程师以供后续故障定位和排除使用。

3. 收集信息并寻求技术支持

通过上述步骤只是确定了问题的范围，但还需继续收集信息以确定具体是哪些代码有问题。由于后续信息收集要求较高，不建议用户操作，请与H3C的技术支持工程师联系。需要注意的是：此时，不得重启设备，否则设备重启后，由于缺少故障出现时的信息而给故障定位带来困难。

3.3  故障诊断命令

命令	说明
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视图下命令，显示内存分配块数以及调用关系

 

4 端口类故障处理

4.1  端口不接收报文故障处理

4.1.1  故障描述

端口状态为UP，但无法接收报文。

4.1.2  故障处理流程

图4-1 故障诊断流程图

 

4.1.3  故障处理步骤

1. 查看端口报文统计结果

检查两端端口状态是否一直UP，并使用display interface命令查看入方向的报文统计是否增长。为方便查看，也可以使用reset counter interface清空当前端口的报文统计结果再进行观察。同时，查看对端是否有发送报文统计。检查端口错包统计是否持续增长。

2. 检查端口配置是否影响报文的接收

可通过以下步骤检查端口配置是否影响报文的接收：

查看端口与服务器网口的绑定关系是否有异常，若有异常，请修改绑定关系，看故障端口是否恢复正常。如果故障端口仍未恢复正常，请先执行shutdown命令后，再执行undo shutdown命令，再次查看端口是否能恢复正常。

3. 检查端口及链路介质是否正常

检查服务器网卡是否工作正常（查看网卡指示灯是否正常点亮等）；更换互联中间链路设备或传输介质（网线、光纤、服务器网卡等）后查看故障端口是否恢复正常。收集信息并寻求技术支持

如果完成了上述排查后，故障现象仍未消除，请收集设备运行信息，并联系H3C的技术支持工程师

4.2  端口不发送报文故障处理

4.2.1  故障描述

端口状态为UP，但不发送收报文。

4.2.2  故障处理流程

图4-2 故障诊断流程图

 

4.2.3  故障处理步骤

1. 查看端口报文统计结果

检查两端端口状态是否一直UP，并使用display interface 命令查看出方向的报文统计是否增长。为方便查看，也可以使用reset counter interface命令清空端口当前的报文统计结果再进行观察。检查端口错包统计是否持续增长。

2. 检查端口配置是否影响报文的发送

可通过以下步骤检查端口配置是否影响报文的发送：

查看端口与服务器网口的绑定关系是否有异常，若有异常，请修改绑定关系，看故障端口是否恢复正常。如果故障端口仍未恢复正常，请先执行shutdown命令后，再执行undo shutdown命令，再次查看端口是否能恢复正常。

3. 检查端口及链路介质是否正常

检查服务器网卡是否工作正常（查看网卡指示灯是否正常点亮等）；更换互联中间链路设备或传输介质（网线、光纤、服务器网卡等）后查看故障端口是否恢复正常。收集信息并寻求技术支持

如果完成了上述排查后，故障现象仍未消除，请收集设备运行信息，并联系H3C的技术支持工程师

4.3  故障诊断命令

命令	说明
display diagnostic-information	显示或保存系统当前多个功能模块运行的统计信息
display interface	显示以太网端口的相关信息
display interface brief	显示接口的概要信息
display logbuffer	显示系统日志缓冲区的状态和缓冲区记录的日志信息