簡介
本檔案介紹如何利用系統報告來診斷堆疊問題。
必要條件
需求
本文件沒有特定需求。
採用元件
本文件所述內容不限於特定軟體和硬體版本。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除(預設)的組態來啟動。如果您的網路運作中,請確保您瞭解任何指令可能造成的影響。
背景資訊
如果在沒有崩潰的情況下透過系統報告對堆疊重新載入進行故障排除,通常是在NGWC交換平台上完成的,則使用stackwise技術。目前的說明檔案僅限於系統報告的使用,本指南說明如何利用這些報告來診斷通常與堆疊問題相關的問題。本指南特別針對運行具有支援堆疊功能的Cisco IOS® XE的Catalyst 3650/3850交換機架構。
stackwise技術的大部分問題都源於堆疊中成員之間的通訊問題。成員之間的任何資訊不一致或連線中斷都可能導致貫穿整個堆疊的問題,並最終導致使用堆疊管理員進行重設。本文檔重點介紹堆疊管理器重新載入時常見的一些故障型別、系統報告的使用,以及可用於診斷不同型別的問題的相關CLI。
系統報告與交換機報告
系統報告是成員從其對堆疊狀態的看法中得出的綜合報告。這不是 crashinfo(可轉儲記憶體以進行進一步調試),而是包含在Cisco IOS XE下運行的各種服務的日誌和調試資訊的報告,對於跟蹤該服務狀態的開發來說非常有用。當堆疊管理員重新載入交換器、發生程式當機,或使用者在即時作業期間手動產生系統報告時,就會產生系統報告。
在許多情況下,單一交換器可能會在堆疊中發生故障,但其餘成員可能保持不變。為了收集有關給定時間堆疊狀態的as資訊,引入了switch_reports,以便當前成員可以在檢測到某個成員已關閉時生成一個報告。switch_report可以是一個本地報告,記錄該成員如何感知堆疊的當前狀態。
註:這些報告經過編寫和壓縮,因此不能使用更多內容列印到終端。它們需要從交換機上傳輸並解壓縮才能檢視日誌。
收集系統/交換機報告的位置
系統報告通常可以寫入該堆疊中成員的crashinfo:目錄中。例如,如果有x成員交換機堆疊,則每個交換機都可以有自己的crashinfo目錄,可以使用dir crashinfo-x訪問,其中x對應於堆疊中的成員。
3850#dir crashinfo-1:
crashinfo的目錄:/
11 -rwx 355 2015年8月14日07:48:17 -04:00 last_systemreport_log
12 -rwx 724015 2014年10月15日07:14:32 -04:00 system-report_1_20141015-111342-UTC.gz
3850#dir crashinfo-2:
crashinfo-2的目錄:/
11 -rwx 357 2015年8月14日07:50:49 -04:00 last_systemreport_log
12 -rwx 751340 2014年10月15日06:41:12 -04:00 system-report_1_20141015-104022-UTC.gz
注意:請務必為該堆疊中的每個交換機收集dir crashinfo-x的輸出,因為show tech無法列出可用的檔案系統或crashinfo檔案。請務必提供該堆疊中每個成員的完整圖片。更新:從較新的Cisco IOS XE版本>3.6E開始,show tech命令可以反映dir crashinfo: + show file systems輸出。請參閱Cisco bug ID CSCun50428。
注意:只有已註冊的思科使用者才能訪問內部思科錯誤資訊和工具。
系統報告中值得注意的部分
從TAC的角度來看,這些是系統報告中最常檢視的條目,可幫助診斷特定問題的事件。此處包含其他服務的日誌,開發人員可以發現想要檢視這些日誌。
記錄檔: /mnt/pss/sup_sysmgr_reset.log
這是一個簡短的輸出,非常籠統地解釋了為什麼會看到重置。請參閱以下失敗型別一節,瞭解這些原因可能如何不同的含義和背景。
日誌檔案:Cisco IOS
這是從Cisco IOSd中維護的日誌緩衝區。使用者發出的任何命令或在Cisco IOSd中生成的系統日誌都可以在本節中找到。最近的記錄已接近此輸出的結尾。
跟蹤緩衝區:stack-mgr-events
追蹤從堆疊管理員發現的事件,這些事件可能包括其他成員何時加入/從堆疊中移除,或是郵件透過哪個堆疊連線埠進入。
跟蹤緩衝區:redundancy-timer-ha_mgr
顯示堆疊中交換機之間的保持連線事件。時間戳可以幫助確定通訊中斷的開始時間。
失敗型別
此部分可以突出顯示系統報告中通常由堆疊管理器進程呼叫的某些常見重置。堆疊管理員是一種Linux程式,可管理堆疊中的成員,並可監督堆疊中交換器之間角色的任何變更。如果堆疊管理員在初始化或角色選擇期間偵測到問題,便會向個別交換器傳送重新載入訊號,以便堆疊重設。下一個清單也會列出與各自失敗型別相關的已知錯誤。
注意:並非所有堆疊管理器重新載入都歸因於軟體問題。事實上,更常見的情況是,這些問題表現為核心硬體問題的次要/受害者問題。
重設原因:由[堆疊管理員]要求重設/重新載入。[ISSU不相容性]
當您嘗試在堆疊中的所有成員之間同步作用中的組態時,如果發生大量同步失敗,就會看到這種型別的重設。檢查日誌檔案:Cisco IOS或活動交換機的日誌可以突出顯示導致此重置的配置。
重置原因:服務[iosd] pid:[xyz]異常終止[11]。
當交換機在Cisco IOSd進程中崩潰時,會出現這種情況。檢視crashinfo目錄,查詢任何crashinfo檔案+核心轉儲都可用於進一步調試此故障。
hap_sup_reset: [stack-manager]請求重置原因:重置/重新載入。[堆疊合併]
當有兩台或多台交換器相信自己是堆疊的作用中交換器時,就會發生堆疊合併。當堆疊的環中有中斷時(也就是有兩條纜線從堆疊中斷開),就會看到這種情況,因此作用中及待命都會失去與其他成員的通訊。將已開啟電源的交換器新增至目前的堆疊可能會導致堆疊合併,因為堆疊中可能會有兩個作用中的交換器。
思科漏洞ID CSCuh58098 - 存在堆疊佈線問題時,3850堆疊可能會重新載入
思科漏洞ID CSCui56058 - 啟用堆疊電纜的反跳邏輯
思科漏洞ID CSCup53338 - 3850 IOSD崩潰 | Signal=SIGSEGV(11) @ pm_port_data_from_swidb
hap_sup_reset:原因代碼:[4] Reset Reason:Reset/Reloadrequested by [stack-manager]。[堆疊合併因為不相容]
在堆疊中有作用中及待命交換器時,就會發生這種情況。如果主用交換機失去與備用交換機的通訊,備用交換機可以嘗試接管主用交換機,即使主用交換機仍處於接通狀態。
思科漏洞ID CSCuo49555
思科漏洞ID CSCup58016 -管理埠上的單播泛洪導致3850/3650崩潰
思科漏洞ID CSCur07909 -因活動和備用連線丟失導致堆疊合併
重設原因:由[堆疊管理員]要求重設/重新載入。[ASIC投票後遇到錯誤的鄰居]
啟動期間,交換器會參與ASIC投票,以判斷堆疊中的鄰近交換器。當鄰居宣告自己的計時器過期或廣播會話期間出現邏輯錯誤時,即可看到此重置。這已發生在堆疊電纜故障的情況下,該故障已透過更換得到解決。
思科漏洞ID CSCun60777 - 在ASIC投票後,由於出現錯誤鄰居,交換機重新載入
思科漏洞ID CSCud93761 - 在ASIC投票後,由於出現錯誤鄰居,交換機重新載入
思科漏洞ID CSCun17506 - Amur:ng3k:在3成員堆疊的兩個堆疊埠上都看到相同的鄰居
hap_sup_reset:原因代碼:[4] [stack-manager]請求重置原因:重置/重新載入。[主用和備用均丟失]
通常從堆疊上不是處於作用中或待命角色的成員中看到這種情況。當作用中堆疊失敗時,如果沒有待命交換器擔任堆疊的作用中角色,整個堆疊都可以重設。如果堆疊處於不穩定狀態或冗餘策略尚未同步,則會看到這種情況。這可能是因為主用/備用交換機發生故障的原因,也可能是因為冗餘無法正確同步。在半環設定中配置堆疊時也可以看到這種情況。
思科錯誤ID CSCup53882 - 3850堆疊重新開機中的成員交換器- [失去作用中及待命狀態]
hap_sup_reset:原因代碼:[1] [stack-manager]請求重置原因:重置/重新載入。[保持連線超時]
從堆疊中的交換器未收到保持連線訊息時發生。檢視Trace Buffer: redundancy-timer-ha_mgr,其中顯示了保持連線消息的交換,並提供了開始通訊中斷的時間。如果從堆疊的其餘部分收集交換機報告,並檢視整個時間範圍內的日誌則有幫助。
hap_sup_reset: [stack-manager]請求重置原因:重置/重新載入。[Reload命令]
這是一個相當直覺的重置原因-當堆疊管理器收到可以透過CLI或外部透過管理裝置(SNMP)呼叫的重新載入請求時,就會出現這種情況。在思科漏洞ID CSCuj17317出現的情況下,這也顯示為發出了reload命令。從日誌檔案:Cisco IOS可以看到:
CMD: 'reload'
%SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload command.
%STACKMGR-1-RELOAD_REQUEST: 1 stack-mgr: Received reload request for all switches, reason Reload command
%STACKMGR-1-RELOAD: 1 stack-mgr: Reloading due to reason Reload command
相關錯誤
思科漏洞ID CSCur76872 - 當系統耗盡SDP緩衝區時,堆疊管理器會關閉。
思科漏洞ID CSCup49704 - 3850 FED崩潰-等待SPI通道FED_SPI_FLCD、FED_SPI_FAST ...
診斷潛在的堆疊纜線或連線埠問題
症狀1)堆疊電纜出現問題的任何跡象時,堆疊埠在重置前都會出現抖動。檢視日誌檔案:重置前的Cisco IOS報告通常是一個很好的起點。以下範例顯示了在目前SW2和待命SW1上註冊的堆疊連線埠的抖動。 在重設的每個例項中,此同一堆疊埠都在抖動,更換堆疊電纜時,已解決該問題:
===================== log file: Cisco IOS =====================
.
.
Aug 8 21:40:14.532 UTC: %STACKMGR-1-STACK_LINK_CHANGE: STANDBY:1 stack-mgr: Stack port 1 on switch 1 is down (SW1-1)
Aug 8 21:40:17.242 UTC: %STACKMGR-1-STACK_LINK_CHANGE: STANDBY:1 stack-mgr: Stack port 1 on switch 1 is up (SW1-1)
Aug 8 21:46:11.194 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr: Stack port 2 on switch 2 is down
Aug 8 21:46:12.937 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr: Stack port 2 on switch 2 is up
Aug 8 21:48:23.063 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr: Stack port 2 on switch 2 is down
Aug 8 21:48:24.558 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr: Stack port 2 on switch 2 is up
Aug 8 21:50:40.666 UTC: %STACKMGR-6-SWITCH_REMOVED: 2 stack-mgr: Switch 1 has been removed from the stack.
Aug 8 21:50:40.671 UTC: Starting SWITCH-DELETE sequence, switch 1
症狀2)根據使用的Stackwise設定(180、480,加上),每個埠ASIC的傳輸環數會有所不同。這些命令輪詢全局暫存器,這些全局暫存器會維護一個總數,該總數會隨著每個傳輸環出現讀取錯誤的數量而增加。Port-asic 0對應堆疊連線埠1,而port-asic 1對應堆疊連線埠2。必須對每台交換機發出此命令,計數的任何增加跡象可以確定埠或堆疊電纜是否存在問題。
這些資料可在數分鐘內收集數次,以比較計數中的增量:
show platform port-asic <0-1>讀暫存器SifRacDataCrcErrorCnt switch <switch#>
show platform port-asic <0-1> read register SifRacRwCrcErrorCnt switch <switch#>
show platform port-asic <0-1> read register SifRacPcsCodeWordErrorCnt switch <switch#>
- 在運行檢測到的差異錯誤的無效PCS代碼(未知PCS碼字)上遞增。
show platform port-asic <0-1>讀暫存器SifRacInvalidRingWordCnt switch <switch#>
對於Polaris (16.X代碼),以下為指令:
show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacDataCrcErrorCnt asic <0-1>
show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacRwCrcErrorCnt asic<0-1>
show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacPcsCodeWordErrorCnt asic <0-1>
show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacInvalidRingWordCnt asic <0-1>
此範例顯示發生堆疊合併事件的位置,該堆疊中有2個成員堆疊的兩個成員,且沒有任何堆疊連線埠擺動的跡象。您會看到交換機1的堆疊埠1上的CRC導致環路[0]增加,為了克服此問題,請更換堆疊電纜。
3850#$show platform port-asic 0 read register SifRacRwCrcErrorCnt switch 1
Load for five secs: 11%/4%; one minute: 11%; five minutes: 12%
Time source is NTP, 14:02:49.119 EDT Thu Aug 20 2015
For asic 0
SifRacRwCrcErrorCnt on Asic 0
[0]
count 0x00000031 <<
[1]
count 0x00000001
[2]
count 0x00000000
[3]
count 0x00000001
[4]
count 0x00000000
[5]
count 0x00000001
3850#$show platform port-asic 0 read register SifRacRwCrcErrorCnt switch 1
Load for five secs: 9%/4%; one minute: 11%; five minutes: 12%
Time source is NTP, 14:02:53.550 EDT Thu Aug 20 2015
For asic 0
SifRacRwCrcErrorCnt on Asic 0
[0]
count 0x000000c9 <<
[1]
count 0x00000001
[2]
count 0x00000000
[3]
count 0x00000001
[4]
count 0x00000000
[5]
count 0x00000001
注意:根據檢視的暫存器,每種情況下掩碼都可能不同。在上一個範例中,遮色片可以在最後14位元上換行。因此,當計數器達到0x00003FFF時,它可以回圈為0x00000000。
其他提示
1. 存檔Crashinfo目錄
堆疊中的交換器越多,表示可以收集更多的報表檔案。生成的報告數量之多,很容易讓人措手不及。組織對於排除故障至關重要。如果可能,確定每台交換機寫入給定事件報告檔案的時間戳是否一致。然後,從給定交換機要求這些非常具體的報告,以便客戶端不上傳多個檔案。也可以將crashinfo目錄存檔,以便思科使用者可傳送包含相關報告的單個存檔。下一個示例可在flash目錄中建立一個名為crashinfo-archive.tar的存檔:
F340.03.10-3800-1#archive tar /create ?
WORD Tar filename
F340.03.10-3800-1#archive tar /create crashinfo-archive.tar ?
WORD Dir to archive files from
F340.03.10-3800-1#archive tar /create crashinfo-archive.tar crashinfo ?
WORD File or Dir
<cr>
F340.03.10-3800-1#archive tar /create crashinfo-archive.tar crashinfo:
2. 恢復不穩定堆疊
在某些情況下,進行堆疊選擇程式後,開機期間會在堆疊重新載入中看到多個成員。如果重新載入的交換器認為自己處於作用中狀態,那麼這通常會導致堆疊合併事件,並可能進入開機回圈狀態。在這種情況下,建議詢問思科客戶端:
- 關閉整個堆疊的電源,並牢固地重置所有堆疊電纜。
- 逐一開啟堆疊中每個成員交換器的電源,直到所有成員都已收斂到其預期狀態為止。
- 如果成員無法加入堆疊,請從堆疊中移除此成員,並嘗試將此成員作為獨立成員開機,以進行進一步的疑難排解。
3. 手動產生系統報表
手動建立的系統報告要求啟用內部服務。這會將系統報告寫入為文本檔案,此操作可基於每台交換機完成。
3800-1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
3800-1(config)#service internal
3800-1(config)#exit
3800-1#resource create_system_report ?
WORD system report filename
3800-1#resource create_system_report sysreport.txt ?
switch Switch number
<cr>
3800-1#resource create_system_report sysreport.txt switch ?
<1-1> Switch number
3800-1#resource create_system_report sysreport.txt switch 1 ?
<cr>
相關資訊