目錄

簡介

背景資訊

概觀

程式和核查

硬體更換

葉

骨幹

APIC

IPN裝置更換

全新重新載入APIC/枝葉/主幹

故障排除場景

問題：到達NXOS模式

驗證

解決方案

問題：枝葉/主幹EPLD/FPGA不正確，F1582

驗證

EPLD註釋

解決方案

簡介

本文檔介紹瞭解裝置更換方案並對其進行故障排除的步驟。

背景資訊

本文中的資料摘自 思科以應用為中心的基礎設施第二版故障排除 書，特別是Fabric Discovery - 裝置更換 章節。

概觀

在ACI交換矩陣的演化過程中，需要更換各種元件，包括：APIC、枝葉交換機、主幹交換機和IPN裝置。更換的最常見原因包括RMA和硬體升級。這些步驟已詳細記錄在「思科安裝/升級指南」中，在更換之前應閱讀最新的指南。本節將更深入地研究這些程式在引擎蓋下是如何工作的；並瀏覽幾個最常見的故障排除場景。

程式和核查

附註：自ACI交換機版本5.2(3)起，插入已發現的ACI交換矩陣交換機的NXOS交換機可以使用POAP轉換為ACI交換機。

硬體更換

葉

來自RMA倉庫的枝葉將運行NXOS軟體。請參考下面名為「問題：到達NXOS模式」以將枝葉正確轉換為ACI模式。如果使用不同交換矩陣或先前配置的枝葉，請確保使用「acidiag touch clean」和「reload」命令。

完成上述步驟並且新枝葉交換機準備註冊後，通過「從控制器中刪除」選項從交換矩陣中刪除要更換的枝葉。

「從控制器中移除」選項會將節點從APIC中完全移除，釋放由APIC分配的節點ID、SN關聯和TEP地址。更換交換機節點時需要這些過程。「停用」選項僅在預期相同節點將重新加入具有相同節點ID和SN的交換矩陣時才使用。

當在交換矩陣成員資格頁上不再看到要替換的枝葉交換機時，新的枝葉可以通過主幹介面連線到交換矩陣。一旦枝葉被APIC發現，它將顯示在交換矩陣清單中，並準備好進行註冊。如果待替換的裝置尚未釋放其節點ID，並且新交換機註冊了相同的節點ID，則會拋出錯誤，指出該ID已經與另一個枝葉節點相關聯。過一段時間後，故障應會清除。如果新節點未顯示在Fabric Membership子選單中，則可能存在佈線問題；要驗證這一點，可以在連線到新連線的枝葉交換機的主幹交換機上通過「show lldp neighbors detail」命令檢視LLDP鄰居。有關交換矩陣發現過程的詳細資訊，請參閱「初始交換矩陣設定」一章。

如果修改了基礎VLAN，則必須同時全新重新啟動所有枝葉節點。如果沒有同時清除所有枝葉交換機，則重新載入乾淨的交換機將聯機並通過LLDP從尚未清除的枝葉接收舊的內部VLAN，而重新載入乾淨的枝葉將無法向APIC註冊。有關詳細資訊，請參閱「Initial fabric setup」一章。

由於平台限制，VPC對不能混合使用Gen1和Gen2或更高版本的枝葉交換機。但是，在撰寫本文時，任何Gen2葉及更高版本均可與任何其他Gen2葉及更高版本混合。

骨幹

如枝葉，根據主幹（如模組化主幹）的硬體，它可以到達NXOS模式。使用「問題：在場景下到達NXOS模式「 」以執行轉換。

更換主幹交換器時，使用者必須考慮BGP路由反射器功能。作為最佳實踐，對於第3層思科ACI交換矩陣，必須至少有兩台主幹交換機配置為BGP路由反射器。此組態位於路由反射器節點下的「System > System Settings > BGP Route Reflectors」。更換或移除主幹交換機時，請確保進行適當的配置更改以維護一個活動路由反射器，並確保在完成更改後至少有兩個活動路由反射器。

有關BGP路由反射器的詳細資訊，請參閱「管理和核心服務」一章中的「Pod策略 — BGP RR/日期和時間/SNMP」一節。

APIC

執行APIC替換時，最重要的考慮因素是現有APIC群集的運行狀況。在更換之前，應將集群中的所有APIC報告為「完全適合」。在4.2中，引入了一個額外的工具來通過CLI驗證APIC群集的運行狀況：

apic1# acidiag cluster

Admin password:

Product-name = APIC-SERVER-L2

Serial-number = FCH2206W0RK

Running...

Checking Core Generation: OK

Checking Wiring and UUID: OK

Checking AD Processes: Running

Checking All Apics in Commission State: OK

Checking All Apics in Active State: OK

Checking Fabric Nodes: OK

Checking Apic Fully-Fit: OK

Checking Shard Convergence: OK

Checking Leadership Degration: Optimal leader for all shards

Ping OOB IPs:

APIC-1: 192.168.4.20 - OK

Ping Infra IPs:

APIC-1: 10.0.0.1 - OK

Checking APIC Versions: Same (4.2(1i))

Checking SSL: OK

Done!

更換APIC時，在執行APIC停用之前，請務必注意要更換的APIC的初始設定變數。

apic1# cat /data/data_admin/sam_exported.config

Setup for Active and Standby APIC

fabricDomain = POD37

fabricID = 1

systemName =apic1

controllerID = 1

tepPool = 10.0.0.0/16

infraVlan = 3937

GIPo = 225.0.0.0/15

clusterSize = 3

standbyApic = NO

enableIPv4 = Y

enableIPv6 = N

firmwareVersion = 4.2(1i)

ifcIpAddr = 10.0.0.1

apicX = NO

podId = 1

oobIpAddr = 10.48.176.57/24

使用正確的軟體版本準備新的APIC，然後重新輸入先前引用的初始設定值。初始設定完成並且APIC完全引導後，從群集中其他APIC之一的使用者介面將其重新委託到交換矩陣。

IPN裝置更換

在多Pod環境中，可能需要更換其中一個用於IPN(Inter-Pod Network)的裝置。 在更換之前，IPN網路必須以幻影RP的形式配置PIM雙向交匯點冗餘。如果沒有安裝幻影RP，如果替換的節點是RP，則會出現PIM收斂，並且對於通過IPN傳送的所有BUM流量會出現資料包丟失。

有關如何配置虛擬RP的詳細資訊，請參閱「多Pod發現」一章中的「RP配置」。

全新重新載入APIC/枝葉/主幹

在特定情況下，恢復不會加入交換矩陣的枝葉/主幹的最佳選擇是執行裝置的全新重新載入。

建議不要在等待升級的裝置上執行全新重新載入。清除重新載入任何裝置可能需要較長的時間。

「acidiag touch」命令有兩個選項：clean和setup。clean選項刪除所有策略資料，同時保留APIC網路配置（如交換矩陣名稱、IP地址、登入）。 setup選項刪除策略資料和APIC網路配置。設定選項在通過Pod流動裝置時最常用，因為Pod ID必須更改，並且通常還需要更新管理網路。

APIC

fab1-apic1# acidiag touch clean

This command will wipe out this device, Proceed? [y/N] y

fab1-apic1# acidiag reboot

This command will restart this device, Proceed? [y/N] y

枝葉/骨幹

fab1-leaf101# acidiag touch clean

This command will wipe out this device, Proceed? [y/N] y

fab1-leaf101# reload

This command will reload the chassis, Proceed (y/n)? [n]: y

「acidiag touch clean」命令通過將名為.clean的隱藏檔案放在/mnt/pss中的枝葉上來工作。引導枝葉時，會運行shell指令碼，檢查是否存在.clean檔案。如果.clean檔案存在於/mnt/pss下，策略配置將被擦除，並且配置將從APIC重新下載。如果輸入此命令且節點未重新載入，則無論輸入觸控清除後經過多長時間，檔案仍會存在，並且策略仍會在下次重新載入時擦除。

故障排除場景

問題：到達NXOS模式

驗證

有時，當交換機通過RMA發貨時，它可能隨尚未通過加電自動調配(POAP)流程配置的NXOS軟體一起送達。當使用者通過控制檯進入此裝置時，他們將看到以下某種形式的消息：

中止自動設定並繼續正常設定？(yes/no)

如果裝置已經通過POAP，則確定枝葉是否正在運行獨立NXOS代碼的最簡單方法是在「show version」輸出中查詢「NXOS image file」行。如果存在此類輸出，則枝葉運行獨立代碼，需要轉換為ACI模式。通過檢視映像本身，可以驗證Kickstart和系統映像是否存在，並且僅在運行ACI映像的枝葉上存在，獨立映像為n9000,ACI為aci-n9000。

獨立NXOS

nxos-n9k# show version

Cisco Nexus Operating System (NX-OS) Software

.

.

.

Software

BIOS: version 07.17

NXOS: version 6.1(2)I3(4)

BIOS compile time:  09/10/2014

NXOS image file is: bootflash:///n9000-dk9.6.1.2.I3.4.bin

NXOS compile time:  3/18/2015 0:00:00 [03/18/2015 07:49:10]

ACI

aci-leaf101# show version

Cisco Nexus Operating System (NX-OS) Software

.

.

.

Software

BIOS:      version 07.66

kickstart: version 14.2(1i) [build 14.2(1i)]

system:    version 14.2(1i) [build 14.2(1i)]

PE:        version 4.2(1i)

BIOS compile time:       06/11/2019

kickstart image file is: /bootflash/aci-n9000-dk9.14.2.1i.bin

kickstart compile time:  09/07/2019 10:25:16 [09/07/2019 10:25:16]

system image file is:    /bootflash/auto-s

system compile time:     09/07/2019 10:25:16 [09/07/2019 10:25:16]

解決方案

如果交換機出廠時運行的是NXOS代碼，則需要將其轉換為ACI模式。交換器應同時附帶bootflash中的NXOS和ACI映像，儘管情況並非總是如此。ACI映像將以「aci-n9000」開頭。 如果ACI映像不存在，則需要手動將其載入到bootflash中。這可以通過USB連線（需要本地訪問）或通過SCP直接從APIC執行（假設兩台裝置都通過管理網路連線）。 以下是通過SCP複製映像的說明：

1. nexus-9000(config)# feature scp-server

2. apic1# scp -r /firmware/fwrepos/fwrepo/switch-image-name admin@standalone_switch:switch-image-name

然後，需要將枝葉配置為不引導NXOS映像、儲存配置，並將引導語句更改為ACI。

1. (config)# no boot nxos

2. (config)# copy run start

3. (config)# boot aci bootflash:

4. (config)# reload

問題：枝葉/主幹EPLD/FPGA不正確，F1582

驗證

Nexus 9000 ACI交換機的故障中將顯示以下故障。

檢測到F1582 FPGA版本不匹配。運行版本：0x(z)預期版本：0x(y)

在APIC CLI中搜尋故障F1582的所有例項：

apic1# moquery -c faultInst -f 'fault.Inst.code=="F1582"'

EPLD註釋

Cisco Nexus 9000系列ACI模式交換機包含多個可程式設計邏輯裝置(PLD)，可在所有模組中提供硬體功能。思科提供電子可程式化邏輯裝置(EPLD)映像升級，以增強硬體功能或解決已知問題。PLD包括電子可程式設計邏輯器件(EPLD)、現場可程式設計門陣列(FPGA)和複雜可程式設計邏輯器件(CPLD)，但不包括ASIC。

EPLD一詞用於同時包含FPGA和CPLD。

對於某些模組功能使用EPLD的優勢在於，當需要升級這些功能時，只需升級其軟體映像，而不是更換硬體。

I/O模組的EPLD映像升級會中斷通過模組的流量，因為模組在升級過程中必須短暫關閉。在模組化機箱中，系統一次在一個模組上執行EPLD升級，因此在任何時候，升級都只會中斷通過一個模組的流量。

思科提供每個版本的最新EPLD映像。通常，這些映像與早期版本中提供的映像相同，但有時會更新其中一些映像。除非另有說明，否則這些EPLD映像更新不是強制性的。當思科提供EPLD映像升級時，這些版本說明會宣佈它們可用，並且可以從思科網站下載。

當有新的EPLD映像可用時，如果網路環境允許存在可以接受某種程度的流量中斷的維護期，則始終建議進行升級。通常，當軟體升級後新增新硬體功能時，需要EPLD升級。

當已經處於ACI模式時，可能需要升級EPLD韌體，這可能也有多種原因：

1. 在Cisco NX-OS到ACI引導模式轉換之前，需要升級EPLD版本，並且FPGA/EPLD未升級。

2. 枝葉/主幹已手動升級（而不是從APIC進行策略升級），其中不包括EPLD升級。

在枝葉或主幹新增到交換矩陣後，EPLD將自動升級為任何策略升級（從APIC韌體頁籤啟動正常升級），其中會提供新版本的EPLD。

解決方案

在較舊版本的ACI中，必須降級然後升級有問題的枝葉/主幹，但截至11.2(1m)，管理員使用者可使用兩個shell指令碼，大大簡化了流程。

fab1-leaf101# /bin/check-fpga.sh FpGaDoWnGrAdE

fab1-leaf101# /usr/sbin/chassis-power-cycle.sh

「/usr/sbin/chassis-power-cycle.sh」指令碼會硬重置電源，而與「reload」相比，後者只是簡單的軟體重啟。升級EPLD時，需要完全移除電源以重新程式設計線卡上的韌體。如果「/usr/sbin/chassis-power-cycle.sh」不可用或無法正常工作，則需要拔下電源線至少30秒，然後重新連線才能恢復電源。