1、S系列(xli)交換機CPU使用率高故障處理共二十四頁目錄(ml)診斷工具(gngj)display工具log工具報文沖擊導致的CPU使用率高問題CPU使用率高問題信息采集共二十四頁display cpu-usage slot x display cpu-usage CPU Usage Stat. Cycle: 60 (Second) CPU Usage : 40% Max: 54% CPU Usage Stat. Time : 2008-05-27 09:21:46 CPU utilization for five seconds: 50%: one minute: 49%: five mi

2、nutes: 47% Max CPU Usage Stat. Time : 2008-05-26 09:30:07. TaskName CPU Runtime(CPU Tick High/Tick Low) Task Explanation BOX 0% 0/ 35090 BOX Output _TIL 0% 0/ 0 Infinite loop event task _EXC 0% 0/ 0 Exception Agent Task bcmRX 2% 0/ 3b69a bcmRX VIDL 50% 0/af3cd700 DOPRA IDLE TICK 0% 0/ 1414bb FOAM 0%

3、 0/ 0 FOAM FTS 25% 0/ 416 FTS IPCQ 0% 0/ 10105f IPCQIPC task for single queue SOCK 10% 0/ ecb2fc SOCKPacket schedule and process 空閑(kngxin)任務任務(rn wu)描述共二十四頁display cpu-defend statisticsdisplay cpu-defend statistics all Statistics on slot 0: - Packet Type Pass(Bytes) Drop(Bytes) Pass(Packets) Drop(P

4、ackets) - arp-miss 0 0 0 0 arp-reply 384 0 6 0 arp-request 346825664 83619584 5419151 1306556 dhcp-client 0 0 0 0 dhcp-server 1427 0 4 0 igmp 2240 0 35 0 nap 0 0 0 0 nd 1424 0 16 0 snmp 0 0 0 0 tcp 0 0 0 0 telnet 0 0 0 0 ttl-expired 0 0 0 0 unknown-multicast 0 0 0 0 - 對于報文沖擊導致CPU高的情形，可進一步通過cpu-defen

5、d統計查詢功能確認具體的協議(xiy)類型。協議上送過多判斷標準：該協議對應的Drop列有大量計數，且相對于Pass計數占比較高，例如上表中的arp-request類型。共二十四頁display logbufferdisplay logbuffer Logging buffer configuration and contents : enabled Allowed max buffer size : 1024 Actual buffer size : 512 Channel number : 4 , Channel name : logbuffer Dropped messages : 0

6、Overwritten messages : 0 Current messages : 395 Feb 28 2012 16:37:40 Quidway %01SNMP/4/DECODE_ERR(l):Failed to login through SNMP, because of the decoded PDU error. (Ip=9, Times=4) Feb 28 2012 16:35:36 Quidway %01VOSCPU/4/CPU_USAGE_HIGH(l)126:Slot=5;The CPU is overloaded, and the tasks with top thre

7、e CPU occupancy are FTS(40%), SNPG(30%), bcmRX(5%). (CpuUsage=99%, Threshold=80%) CPU使用率高往往還伴有告警、日志出現，可以(ky)通過查看日志緩沖區的歷史記錄，搜索CPU_USAGE_HIGH日志，以便確認CPU占用率TOP 3的任務。共二十四頁目錄(ml)診斷工具報文沖擊導致的CPU使用率高問題(wnt)定位思路故障舉例第一步：檢查CPU占用率TOP任務第二步：檢查上送過多的協議類型第三步：按協議類型分別處理CPU使用率高問題信息采集共二十四頁定位(dngwi)思路CPU使用率檢查(jinch)確認TOP任

8、務確認報文類型協議分類處理其它情形信息采集最常見協議沖擊CPU致使用率高主要表現在bcmRX、FTS、SOCK等任務上。bcmRX是設備硬件中斷觸發的的收包任務，它會將收取到的報文立刻轉交軟件層面的FTS任務進行分發處理。對于屬于三層協議處理的報文，往往還伴隨有SOCK任務占用率高的情況出現。共二十四頁故障(gzhng)舉例故障描述(mio sh)：交換機產生CPU_USAGE_HIGH告警：備注：如果網管需要主動監測CPU使用率，可通過OID：..5獲取。Feb 28 2012 16:35:36 Quidway %01VOSCPU/4/CPU_USAGE_HIGH(l)126

9、:Slot=5;The CPU is overloaded, and the tasks with top three CPU occupancy are FTS(27%), VPS(15%), bcmRX(5%). (CpuUsage=99%, Threshold=80%)共二十四頁第一步：檢查(jinch)CPU占用率及TOP任務display cpu-usage slot x CPU Usage Stat. Cycle: 60 (Second) CPU Usage : 85% Max: 99% CPU Usage Stat. Time : 2001-04-25 16:15:00 CPU

10、utilization for five seconds: 90%: one minute: 85%: five minutes: 86% Max CPU Usage Stat. Time : 2001-04-24 17:17:07. TaskName CPU Runtime(CPU Tick High/Tick Low) Task Explanation BOX 0% 0/ dad772 BOX Output _TIL 0% 0/ 0 Infinite loop event task _EXC 0% 0/ 0 Exception Agent Task VIDL 15% 8/b51c8f1b

11、DOPRA IDLE TICK 0% 0/ 91e2d7f CLKI 0% 0/ 0 CLKI DEV 0% 0/ 12202d9 DEV Device bcmRX 5% 0/ cb817af bcmRX CHAL 0% 0/ 0 CHAL FTS 23% 0/ 5a876 FTS MOD 0% 0/ 0 MOD Module Management 通過故障(gzhng)現象中的告警信息，可以確認CPU占用率TOP任務中包含有bcmRX、FTS報文收取任務，基本可以確認屬于協議收報過多導致CPU占用率上升。可以通過CPU使用率查詢功能進一步核實TOP任務中是否包含有收包任務；可以通過slot指

12、明查詢的槽位號。共二十四頁第二步：確認(qurn)報文類型通過cpu-defend統計查詢功能，確認哪類協議存在沖擊(chngj)情形，可以通過各類協議的Drop列計數進行確認。如果某類協議Drop計數非常大，且Drop列計數相對于Pass列計數占比較高(例如達到20%以上)，則認為屬于此類協議存在沖擊CPU情況。例如上表中的arp-request，后續按照第三步中的ARP協議對應處理方式進行處理。注意，查看統計時，需要關注協議沖擊位于哪個槽位，即“Statistics on slot x”。display cpu-defend statistics all Statistics on slo

13、t 0: - Packet Type Pass(Bytes) Drop(Bytes) Pass(Packets) Drop(Packets) - arp-miss 0 0 0 0 arp-reply 384 0 6 0 arp-request 346825664 83619584 5419151 1306556 dhcp-client 0 0 0 0 dhcp-server 1427 0 4 0 dhcpv6-reply 0 0 0 0 dhcpv6-request 0 0 0 0 icmp 0 0 0 0 icmpv6 0 0 0 0 igmp 2240 0 35 0 共二十四頁第三步：按協

14、議(xiy)類型分別處理-1ARP通過(tnggu)display interface檢查哪些接口存在Broadcast數量異常，并在此接口配置廣播流量抑制，限制單個接口廣播速率(例如限制為50pps)：#broadcast-suppression pps 50.#DHCP請確認本機是否需要開啟DHCP，如果不需要請在全局undo dhcp enable；如果需要，建議在下行接口開啟dhcp error-down功能(具體信息請參考用戶手冊)：#dhcp snooping check dhcp-rate enabledhcp snooping check dhcp-rate trigger e

15、rror-down# 并建議通過基于dhcp報文的流量統計功能，來發現哪個接口發送了過多的DHCP報文。共二十四頁第三步：按協議(xiy)類型分別處理-2TCP/ARP-MISS此種情況一般是由于網絡中存在針對不存在的某些直連網段IP地址進行掃描導致的. 當有數 據報文發送到這些不存在的IP地址時，會將數據上送CPU處理，以觸發ARP學習過程，建議此時在每個vlanif接口下調整ARP學習延遲時間：#interface vlanif1000 arp-fake expire-time 30#TTL-EXPIRED如果不需要(xyo)本機在tracert中顯示，建議丟棄此類報文：#cpu-defe

16、nd policy test deny packet-type ttl-expired#Cpu-defend-policy test globalCpu-defend-policy test#共二十四頁第三步：按協議(xiy)類型分別處理-3Reserved-multicast 此類報文一般屬路由協議報文，目的IP地址224.0.0.X，如果設備不需要此類報文(或者啟用OSPF路由但未起組播功能)，可以(ky)直接丟棄處理(或者升級到最新版本)：#cpu-defend policy test deny packet-type reserved-multicast#Cpu-defend-poli

17、cy test globalCpu-defend-policy test#共二十四頁第三步：按協議類型(lixng)分別處理-4ND/ICMPV6/DHCPV6如果(rgu)本機不需要IPV6功能，建議直接丟棄此類報文：#cpu-defend policy test deny packet-type nd deny packet-type icmpv6 deny packet-type dhcpv6-request deny packet-type dhcpv6-reply#Cpu-defend-policy test globalCpu-defend-policy test#共二十四頁第三步

18、：按協議類型(lixng)分別處理-5OSPF請檢查是否存在路由表項過大，或者OSPF PEER過多情形，并根據實際情況考慮對路由進行(jnxng)優化，以降低路由表項數目或OSPF PEER數目。SNMP檢查是否存在頻繁的網管操作，例如獲取接口流量，建議適當降低網管獲取交換機信息的頻率。如果不屬于上述常見協議類型，或者其它情況導致的CPU高情形，建議立刻搜集設備當前診斷信息、日志信息、本次定位過程的操作記錄等，并返回華為服務處理。共二十四頁目錄(ml)診斷工具(gngj)報文沖擊導致的CPU使用率高問題CPU使用率高問題信息采集共二十四頁信息(xnx)搜集搜集cfcard中的logfile目

19、錄(ml)下的日志信息，針對沒有cfcard的盒式設備，請通過如下命令搜集：display logbufferdisplay trapbuffer搜集設備診斷信息，命令為： display diagnostic-information 搜集cpu-defend統計信息(10分鐘內多搜集幾次) display cpu-defend statistics all共二十四頁信息(xnx)搜集搜集TOP任務的監控(jin kn)信息：1. 通過_hidecmd或diagnose進入診斷視圖；2. 通過display cpu-usage檢查cpu占用較高任務，例如EOAM較高：Quidway-hidec

20、md display cpu-usage slot x - 可指定槽號檢查CPU Usage Stat. Cycle: 10 (Second)CPU Usage : 38% Max: 99%CPU Usage Stat. Time : 2013-01-06 03:08:57 CPU utilization for five seconds: 38%: one minute: 33%: five minutes: 35%.TaskName CPU Runtime(CPU Tick High/Tick Low) Task ExplanationBOX 0% 0/ 18f78e BOX Output

21、 _TIL 0% 0/ 0 Infinite loop event task _EXC 0% 0/ 0 Exception Agent Task VIDL 61% 0/b7abe65c DOPRA IDLE TICK 0% 0/ 143074e STND 0% 0/ b3412 STNDStandby task EOAM 24% 0/4994c174 EOAMEthernet OAM 802.1ag 共二十四頁信息(xnx)搜集3. 通過display task查找任務對應的taskid，例如(lr)EOAM的taskid為79:Quidway-hidecmd display task slo

22、t x - 可指定槽號name Tid VOS_Tid priority Status CPU Total(Millsecs)=BOX 0 x6ec5230 1 8 sleep 36830_TIL 0 x6ebaf90 2 250 eventblock 0_EXC 0 x6eb0cf0 3 135 eventblock 0VIDL 0 x6ea6a50 4 1 preemptready 79669745TICK 0 x6e9c7b0 5 205 preemptready 476396STND 0 x6daa8b0 6 80 eventblock 18097FTPS 0 x6dbc240 7 1

23、00 sleep 230536DEV 0 x6e7ffd0 8 140 eventblock 14818TCTL 0 x6c6a460 77 100 eventblock 45NAP 0 x6c601c0 78 100 eventblock 45EOAM 0 x6c55f20 79 100 eventblock 29468818TRAF 0 x6c4bc80 80 100 eventblock 25659SLAG 0 x6c419e0 81 100 eventblock 56共二十四頁信息(xnx)搜集4. 根據taskid設置監控閥值。閥值的設置可參考相應任務的現有占用率，如上面的EOAM模塊CPU利用率為24，那么(n me)我們設置監控比這個值低一點，例如設置成20，具體命令為: set task-monitor-record threshold threshold taskid taskidQuidway-hidecmdset task-monitor-record threshold 20 taskid 79 slot x 可指定槽號Task Monitor has been set on slot 5, TaskId is 79, Threshold is 55. 查看任