目錄

簡介

背景資訊:

系統報告與交換機報告

收集系統/交換機報告的位置

系統報告中的相關部分

失敗型別

重置原因：[stack-manager]請求重置/重新載入。[ISSU不相容]

重置原因：服務[iosd] pid:[xyz]異常終止[11]。

hap_sup_reset:重置原因：[stack-manager]請求重置/重新載入。[堆疊合併]

hap_sup_reset:原因代碼：[4]重置原因：由[stack-manager]重置/重新載入。[由於不相容而導致堆疊合併]

重置原因：[stack-manager]請求重置/重新載入。[在ASIC投票後遇到錯誤的鄰居]

hap_sup_reset:原因代碼：[4] [stack-manager]請求重置原因：重置/重新載入。[主用和備用均丟失]

hap_sup_reset:原因代碼：[1]重置原因：由[stack-manager]請求重置/重新載入。[Keepalive_Timeout]

hap_sup_reset:重置原因：[stack-manager]請求重置/重新載入。[Reload命令]

相關錯誤

診斷潛在的堆疊佈線/連線埠問題

其他提示

1.  存檔Crashinfo目錄

2.恢復不穩定堆疊

3.手動生成系統報告

簡介

使用stackwise技術的NGWC交換平台通常會在無崩潰的情況下通過系統報告對堆疊重新載入進行故障排除。當前文檔僅對系統報告的使用進行了限制，本指南旨在說明您可以如何利用這些報告來診斷通常與堆疊問題相關的問題。本指南特別適合運行支援堆疊功能的IOS-XE的Catalyst 3650/3850交換架構。

stackwise技術的大部分問題源自堆疊內成員之間的通訊問題。成員之間的任何資訊不一致或連線中斷都可能會導致問題遍及整個堆疊，最終導致使用堆疊管理器進行重設。本文重點介紹在重新載入堆疊管理器時常見的一些故障型別、系統報告的使用以及可用於診斷的相關CLI和不同型別的故障。

背景資訊:

系統報告與交換機報告

系統報告是成員根據其如何感知堆疊狀態的綜合報告。這不是crashinfo（將轉儲記憶體以供進一步調試），而是包含在IOS-XE下運行的各種服務的日誌和調試資訊的報表，對於跟蹤該服務狀態的開發非常有用。當堆疊管理器重新載入交換機、發生進程崩潰或者使用者在即時操作期間手動生成系統報告時，可以生成系統報告。

在許多情況下，單個交換器可能會在堆疊中發生故障，但其餘成員可能保持不變。為了收集在給定時間堆疊狀態的相關資訊，引入了switch_reports，以便其餘成員在其檢測到某個成員已關閉時生成一個報告。switch_report將是該成員如何感知堆疊當前狀態的本地報告。

附註：這些報告被編寫和壓縮，因此不能使用「more」列印到終端。它們需要從交換機傳輸並解壓縮以檢視日誌。

收集系統/交換機報告的位置

系統報告通常寫在crashinfo中：堆疊中成員的目錄。例如，如果存在x成員交換器堆疊，則每個交換器都會有自己的crashinfo目錄，可以使用「dir crashinfo-x」存取該目錄，其中「x」對應於堆疊中的那個成員。

3850#dir crashinfo-1:

crashinfo目錄：/

11 -rwx 355 Aug 14 2015 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 Aug 14 2015 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檔案。請務必提供該堆疊中每個成員的完整圖片。更新：從較新的IOS-XE版本>3.6E開始，show tech將反映「dir crashinfo：」 + 「show file systems」輸出。請參閱CSCun50428 .

系統報告中的相關部分

從TAC的角度來看，這些是系統報告中比較常見的一些條目，可幫助診斷特定問題的事件。這裡包含的其他服務也有開發者可能需要檢查的日誌。

日誌檔案：/mnt/pss/sup_sysmgr_reset.log

這是一個簡短的輸出，非常一般地理解了為什麼會出現重置。請參見下面的失敗型別部分，以瞭解這些原因的意義和具體情況。

日誌檔案：IOS

這是從IOSd中維護的日誌緩衝區。使用者發出的任何命令或在IOSd中生成的系統日誌都可以在本節中找到。最近的日誌將接近此輸出的結尾。

跟蹤緩衝區：stack-mgr-events

追蹤從堆疊管理器中看到的事件，當其他成員加入/從堆疊中移除時，或消息通過哪個堆疊埠傳入時，將包含在內。

跟蹤緩衝區：redundancy-timer-ha_mgr

顯示堆疊中交換機之間的保持連線事件。時間戳可以幫助確定通訊故障開始的時間。

失敗型別

本節將突出顯示系統報告中通常由堆疊管理器進程呼叫的某些常見重置。堆疊管理器是一個Linux進程，用於管理堆疊中的成員，並監控堆疊中交換機之間角色的任何更改。如果堆疊管理員在初始化或角色選擇期間偵測到問題，便會向個別交換器傳送重新載入訊號，以便堆疊重設。下面還將列出與各故障型別相關的已知錯誤。

附註：並非所有堆疊管理員重新載入都會歸結為軟體問題。事實上，更常見的是將這些問題視為底層硬體問題的次要/受害者問題。

重置原因：[stack-manager]請求重置/重新載入。[ISSU不相容]

嘗試在堆疊中的所有成員之間同步作用中上的組態時，如果發生批次同步失敗，可能會看到這種型別的重設。正在檢查日誌檔案：IOS或活動交換機的日誌可能會突出顯示導致此重置的配置。

重置原因：服務[iosd] pid:[xyz]異常終止[11]。

當交換器在IOSd過程中崩潰時會出現這種情況。檢視crashinfo目錄中的任何crashinfo檔案+核心轉儲可用於進一步調試此故障。

hap_sup_reset:重置原因：[stack-manager]請求重置/重新載入。[堆疊合併]

當有兩台或多台交換器相信自己是堆疊的作用中交換器時，就會發生堆疊合併。當堆疊的環中有中斷時（即兩根纜線從堆疊中斷開），就會看到這種情況，因此作用中及待機都會與其他成員失去通訊。將已開啟電源的交換器新增至現有堆疊可能導致堆疊合併，因為堆疊中將有兩個作用中交換器。

CSCuh58098 — 存在堆疊佈線問題時，3850堆疊可能會重新載入

CSCui56058 — 啟用堆疊電纜的反退回邏輯

CSCup53338 - 3850 IOSD崩潰 | Signal=SIGSEGV(11)@ pm_port_data_from_swidb

hap_sup_reset:原因代碼：[4]重置原因：由[stack-manager]重置/重新載入。[由於不相容而導致堆疊合併]

在堆疊中存在作用中交換器和備用交換器時，會看到這種情況。如果主用交換機與備用交換機失去通訊，則備用交換機將嘗試接管主用交換機，即使主用交換機仍然處於開啟狀態也是如此。

CSCuo49555 /CSCup58016 — 管理埠上的單播泛洪導致3850/3650崩潰

CSCur07909 — 由於主用和備用連線斷開而導致堆疊合併

重置原因：[stack-manager]請求重置/重新載入。[在ASIC投票後遇到錯誤的鄰居]

啟動期間，交換器會參與ASIC投票，以確定堆疊中的相鄰交換器。如果計時器到期時鄰居需要宣告自身，或者廣播會話期間出現邏輯錯誤，則會顯示此重置。這會在堆疊纜線發生錯誤的情況下看到，已通過更換解決。

CSCun60777 — 由於在ASIC投票後遇到錯誤的鄰居，交換機重新載入

CSCud93761 — 由於在ASIC投票後遇到錯誤的鄰居，交換機重新載入

hap_sup_reset:原因代碼：[4] [stack-manager]請求重置原因：重置/重新載入。[主用和備用均丟失]

這通常從堆疊上不處於作用中或待命角色的成員中看到。當作用中發生失敗時，如果沒有備用交換器承擔堆疊的作用中，整個堆疊都會重設。如果堆疊處於不穩定狀態或尚未同步冗餘策略，可以看到這種情況。這可能是活動/備用交換機關閉的原因的受害者，也可能表明冗餘同步不正確。在半環設定中設定堆疊時也可看到這種情況。

CSCup53882 - 3850堆疊重新啟動中的成員交換器 — [失去主動和備用]

hap_sup_reset:原因代碼：[1]重置原因：由[stack-manager]請求重置/重新載入。[Keepalive_Timeout]

從堆疊中的交換器未收到「keep alive」訊息時發生。檢視「跟蹤緩衝區：redundancy-timer-ha_mgr"應顯示保持活動消息的交換，並提供通訊開始中斷的時間透視。從堆疊的其餘部分收集交換機報告並在該時間段內檢視日誌可能會對此有所幫助。

hap_sup_reset:重置原因：[stack-manager]請求重置/重新載入。[Reload命令]

這是相當直觀的重設原因 — 當堆疊管理器收到可以透過CLI或在外部透過管理裝置(SNMP)進行呼叫的重新載入要求時，就會發生這種情況。 對於CSCuj17317 ，這也會顯示為發出的「reload命令」。在日誌檔案中：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

相關錯誤

CSCur76872 — 系統耗盡SDP緩衝區時，堆疊管理器關閉。

CSCup49704 - 3850 FED崩潰 — 正在等待SPI通道FED_SPI_FLCD，FED_SPI_FAST..

診斷潛在的堆疊佈線/連線埠問題

症狀1)在重置之前，堆疊埠的任何擺動都明顯反映了堆疊佈線問題。檢視「logfile:重置前的「 IOS 」報告通常是一個很好的起點。以下是您在當前SW2和備用SW1上註冊的堆疊埠擺動的示例。在重置的每個例項中，此相同的堆疊埠都在擺動，並且通過更換堆疊電纜解決了這個問題：

=====================  log file: 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和plus），每個埠ASIC的傳輸環數會有所不同。這些命令將輪詢全域性暫存器，以保持每個傳輸環可見的讀取錯誤總數的運行總數。「Port-asic 0」對應堆疊連線埠1，「port-asic 1」對應堆疊連線埠2。這應該會針對每台交換器發出，且遞增計數的任何訊號可以隔離連線埠或堆疊纜線是否出現問題。

可以在幾分鐘內收集數次，以比較計數中的增量：

show platform port-asic <0-1>讀暫存器SifRacDataCrcErrorCnt switch <switch#>

- 具有資料CRC錯誤的段

show platform port-asic <0-1>讀取暫存器SifRacRwCrcErrorCnt switch <switch#>

- 任何失敗的CRC檢查均遞增

show platform port-asic <0-1>讀暫存器SifRacPcsCodeWordErrorCnt switch <switch#>

- 在無效PCS代碼、未知PCS代碼字上遞增，檢測到運行差異錯誤

show platform port-asic <0-1>讀取暫存器SifRacInvalidRingWordCnt switch <switch#>

- 堆疊上的位元錯誤導致環字CRC錯誤

對於Polaris（16.X代碼），命令如下：

show platt hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacDataCrcErrorCnt asic <0-1>

show platt hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacRwCrcErrorCnt asic<0-1>

show platt hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacPcsCodeWordErrorCnt asic <0-1>

show platt hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacInvalidRingWordCnt asic <0-1>

在以下範例中，發生堆疊合併事件時，兩個2成員堆疊中的成員均未出現堆疊埠擺動的跡象。您會看到環[0]隨著交換器1的堆疊連線埠–1上的CRC遞增，最終會取代堆疊纜線來克服此問題。

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.手動生成系統報告

手動建立系統報告需要啟用「service internal」。這會將系統報告寫入一個文本檔案，該檔案可基於交換機完成。

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>