適用於高可用性網路的Cisco IOS管理：最佳實踐白皮書

簡介

在當今的業務關鍵型網路環境中，部署和維護可靠的Cisco IOS®軟體是一項優先任務，需要重新關注思科和客戶來實現不間斷的可用性。雖然思科必須專注於對軟體品質的承諾，但網路設計和支援團隊也必須關注Cisco IOS軟體管理的最佳做法。目標是提高可用性和軟體管理效率。此方法是一種用於共用、學習和實施軟體管理最佳實踐的組合夥伴關係。

本文檔為企業和服務提供商客戶提供有效的Cisco IOS管理實踐操作框架，有助於提高軟體可靠性、降低網路複雜性和提高網路可用性。此框架還通過在思科版本操作與思科客戶群之間確定軟體管理測試和驗證的職責範圍和重疊部分，幫助提高軟體管理效率。

Cisco IOS最佳實踐概述

下表提供了Cisco IOS最佳實踐的概述。這些表可用作已定義最佳實踐的管理概述、差距分析核對表以稽核當前Cisco IOS管理實踐，或用作圍繞Cisco IOS管理建立流程的框架。

下表定義了Cisco IOS管理的四個生命週期元件。每個表格都以識別生命週期區域的策略和工具摘要開頭。戰略和工具摘要後是僅應用於定義的生命週期區域的特定最佳做法。

規劃 — 構建Cisco IOS管理框架 — 規劃是Cisco IOS管理的初始階段，可幫助組織確定何時升級軟體、升級何處以及用什麼流程來測試和驗證可能的映像。

設計 — IOS版本的選擇和驗證 — 通過明確定義的選擇和驗證Cisco IOS版本的流程，幫助組織減少由於不成功的升級嘗試和計畫外的軟體缺陷而造成的計畫外停機。

實施 — Cisco IOS快速成功部署 — 明確定義的實施流程允許組織快速成功部署新的Cisco IOS版本。

操作 — 管理高可用性Cisco IOS實施 — Cisco IOS操作的最佳實踐包括軟體版本控制、Cisco IOS系統日誌管理、問題管理、配置標準化和可用性管理。

軟體生命週期管理流程概述

Cisco IOS軟體生命週期管理是指為可靠軟體實施和高可用性網路推薦的一組規劃、設計、實施和操作流程。其中包括在網路中選擇、驗證和維護Cisco IOS版本的流程。

Cisco IOS軟體生命週期管理的目標是通過降低產品識別出的軟體缺陷或軟體相關更改/升級失敗的可能性，提高網路可用性。根據許多思科客戶和思科高級服務團隊的實際經驗，本文檔中定義的最佳實踐已證明可以減少此類缺陷和更改失敗。軟體生命週期管理最初可能會增加費用，但是，減少中斷和簡化部署和支援機制可以降低總體擁有成本。

規劃 — 構建Cisco IOS管理框架

規劃是Cisco IOS管理的初始階段，可幫助組織確定何時升級軟體、升級位置以及測試和驗證潛在映像的流程。

最佳實踐包括軟體版本跟蹤定義、升級週期和定義，以及建立內部軟體認證過程。

Cisco IOS規劃策略和工具

開始進行Cisco IOS管理規劃，誠實評估當前實踐、制定可實現的目標以及專案規劃。應該通過將本文檔中的最佳做法與組織中的流程進行比較來完成自我評估。基本問題應包括以下方面：

• 我的組織是否有包括軟體測試/驗證的軟體認證流程？

• 我的組織是否具有在網路中運行有限數量的Cisco IOS版本的Cisco IOS軟體標準？

• 我的組織在確定何時升級Cisco IOS軟體時遇到困難嗎？

• 我的組織是否難以高效部署新的Cisco IOS軟體？

• 我的組織在部署後是否存在Cisco IOS穩定性問題，嚴重影響停機成本？

評估之後，您的組織應開始定義Cisco IOS軟體管理的目標。首先將跨職能部門的經理和/或來自架構規劃組、工程設計、實施和運營的線索集合起來，以幫助定義Cisco IOS目標和流程改進專案。初始會議的目標應是確定總體目標、角色和責任，分配行動專案，並定義初始專案時間表。另外，定義關鍵的成功因素和衡量標準以確定軟體管理優勢。潛在指標包括：

• 可用性（由於軟體問題）

• 軟體升級成本

• 升級所需的時間

• 生產中運行的軟體版本數

• 軟體升級更改成功/失敗率

除了總體Cisco IOS管理框架規劃外，一些組織還定義每月或每季度召開的持續軟體規劃會議。這些會議的目標是審查當前的軟體部署並開始規劃任何新的軟體需求。規劃可能包括重新訪問或修改當前的軟體管理流程，或者簡單地為不同的軟體管理階段定義角色和職責。

規劃階段的工具僅包括軟體清單管理工具。CiscoWorks 2000 Resource Manager Essentials(RME)清單管理器是此領域使用的主要工具。CiscoWorks2000 RME Inventory Manager通過基於Web的報告工具（基於軟體版本、裝置平台、記憶體大小和裝置名稱，對Cisco IOS裝置進行報告和排序）大大簡化了Cisco路由器和交換機的版本管理。

軟體版本跟蹤定義

第一個Cisco IOS軟體管理規劃最佳實踐確定可在何處保持軟體一致性。軟體路徑被定義為獨特的軟體版本分組，通過獨特的地理位置、平台、模組或功能要求與其他區域區分開來。最佳情況下，網路應只運行一個軟體版本。這大大降低了與軟體管理相關的成本，並提供一致且易於管理的環境。但是，現實情況是，由於特定區域內的功能、平台、遷移和可用性問題，大多陣列織必須在網路中運行多個版本。在許多情況下，同一版本無法在異構平台上運行。在其他情況下，組織不能等待一個版本支援其所有要求。目標是確定網路最少的軟體路徑，並考慮測試/驗證、認證和升級要求。在許多情況下，組織可能還有更多的路徑，以整體降低測試/驗證、認證和升級成本。

第一個與眾不同的事實是平台支援。通常，LAN交換機、WAN交換機、核心路由器和邊緣路由器都有獨立的軟體路徑。特定功能或服務(例如資料連結交換(DLSw)、服務品質(QoS)或IP電話)可能需要其他軟體追蹤，尤其是當此要求可本地化在網路中時。

另一個標準是可靠性。許多組織都嘗試運行面向網路核心和資料中心的最可靠的軟體，同時提供面向邊緣的較新的高級功能或硬體支援。另一方面，在核心或資料中心環境中，通常最需要可擴充性或頻寬功能。特定平台可能需要其他路徑，例如具有不同WAN路由器平台的較大分佈站點。下表是大型企業組織的軟體跟蹤定義示例。

跟蹤分配也可以隨時間而更改。在許多情況下，功能或硬體支援可能整合到更多的主線軟體版本中，從而允許不同路徑最終一起遷移。一旦定義了跟蹤定義，組織就可以使用其他定義的流程遷移至新版本的一致性和驗證。跟蹤定義也是一項持續的工作。只要發現新功能、服務、硬體或模組需求，就應考慮新路徑。

希望啟動跟蹤過程的組織應從新定義的跟蹤要求開始，在某些情況下，應啟動現有網路的穩定專案。企業或機構還可能具有與現有軟體版本的一些可識別的共性，使當前跟蹤定義成為可能。在大多數情況下，如果客戶有足夠的網路穩定性，則不需要快速遷移到確定的版本。網路架構或工程組通常擁有軌跡定義流程。在某些情況下，一個人可能負責磁軌定義。在其他情況下，專案負責人負責開發軟體需求和基於單個專案的新路徑定義。每季度審查一次磁軌定義也是一個好主意，以決定是否需要新的磁軌，或者舊磁軌是否需要合併或升級。

已經證明，標識和維護具有嚴格版本控制的軟體跟蹤的組織在生產網路中軟體版本數量不斷減少的情況下取得了最大的成功。這通常可以提高軟體穩定性和整體網路可靠性。

升級週期和定義

升級週期定義被定義為軟體和變更管理中的基本品質步驟，用於確定何時應該啟動軟體升級週期。升級週期定義允許組織正確規劃軟體升級週期並分配所需的資源。如果沒有升級週期定義，組織通常會遇到由於當前穩定版本中的功能要求而導致軟體可靠性問題的增加。另一個風險可能是公司缺少在需要生產使用前正確測試和驗證新版本的機會。

這一做法的一個重要方面是確定軟體規劃過程應啟動的時間和啟動程度。這是因為軟體問題的主要原因是在未進行盡職調查的情況下開啟了生產中的功能、服務或硬體功能，或者升級到新的Cisco IOS版本，而無需考慮軟體管理。另一個問題是不升級。由於忽略了正常軟體週期和要求，許多客戶面臨著通過多種不同的主要版本來升級軟體的艱鉅任務。困難在於映像大小、預設行為更改、命令級直譯器(CLI)更改以及協定更改。

思科建議根據本文中定義的最佳實踐，在需要新的主要功能、服務或硬體支援時啟動明確定義的升級週期。應分析認證和測試/驗證的程度（基於風險），以確定精確的測試/驗證要求。風險分析可以按地理位置、邏輯位置（核心、分佈層或接入層）或受影響的人員/客戶估計數量來進行。如果當前版本包含主要功能或硬體功能，還應啟動一些簡化的升級週期流程。如果該功能相對較小，請考慮風險，然後決定應啟動哪些進程。此外，應該在兩年或更短時間內升級軟體，以幫助確保您的組織保持相對最新的狀態，以及升級過程不會過於繁瑣。

客戶還應考慮以下事實，即不會針對已超過壽命終止(EOL)狀態的軟體系列執行錯誤修正。另外還應該考慮業務需求，因為許多環境可以容忍（甚至歡迎）更多的功能新增，而測試/驗證過程很少甚至沒有，而且會造成宕機。客戶在考慮測試要求時，還應考慮在思科版本操作中收集到的較新的資料。對錯誤和根本原因的分析顯示，絕大多數錯誤根本原因都是開發人員在受影響的軟體區域內進行編碼的結果。這表示如果組織是在現有版本中將特定功能或模組新增到其網路，則有可能遇到與該功能或模組相關的錯誤，但新功能、硬體或模組影響其他區域的可能性要低得多。在新增現有版本支援的新功能或模組時，此資料應允許組織通過僅測試新服務或功能與其他啟用的服務結合使用來降低測試要求。根據網路中發現的幾個重要錯誤來升級軟體時，也應考慮這些資料。

下表顯示了大型高可用性企業組織的建議升級要求：

緊急升級

在某些情況下，組織會由於出現災難性的錯誤而需要升級軟體。如果組織沒有緊急升級方法，這可能會導致問題。軟體問題可能包括非託管軟體升級（即軟體升級時無需軟體生命週期管理），也可能包括網路裝置不斷崩潰，但組織不會升級，因為尚未完成下一個候選版本的認證/測試。思科建議對網路中業務不太重要的區域執行有限測試和試用的情況實施緊急升級流程。

如果出現災難性錯誤，沒有明顯的解決方法，並且問題與軟體缺陷相關，思科建議全面聯絡思科支援人員以隔離缺陷，並確定是否有可用的修復程式。如果有可用的修復程式，思科建議緊急升級週期，以快速確定在有限停機時間內是否能修復問題。在大多數情況下，組織運行的是受支援的代碼版本，並且可以在軟體的現有較新的過渡版本中修復問題。

組織還可以為可能的緊急升級做準備。準備工作包括遷移至支援的Cisco IOS版本，以及在與認證版本相同的Cisco IOS系列中識別/開發候選替代版本。受支援的軟體非常重要，因為這意味著思科開發部門仍在向確定的軟體系列新增錯誤修復。通過在網路中維護支援的軟體，組織由於更熟悉和穩定的代碼庫而減少了驗證時間。通常，候選替代是同一Cisco IOS系列中新的臨時軟體映像，沒有新增任何功能或硬體支援。如果組織處於特定軟體培訓的早期採用者階段，則候選替換策略尤為重要。

認證流程

認證過程有助於確保經驗證的軟體始終在組織的生產環境中部署。認證流程步驟應包括跟蹤識別、升級週期定義、候選管理、測試/驗證以及一些試生產使用。不過，簡單的認證過程仍有助於確保已確定的路徑中部署一致的軟體版本。

從架構、工程/部署和運營方面確定人員，以啟動認證流程，擬定和管理認證流程。小組應首先考慮業務目標和資源能力，以確保認證過程持續成功。接下來，指定個人或組全面負責認證過程中的關鍵步驟，包括跟蹤管理、生命週期升級定義、測試/驗證和試用。每個領域都應在組織內進行定義、批准和正式交流。

還包括認證過程各階段的品質或批准指南。這有時稱為品質門過程，因為必須滿足某些品質標準，該過程才能進入下一步。這有助於確保認證過程有效並且值得分配資源。一般而言，當發現一個領域的品質問題時，該過程會將努力推後一步。

由於軟體品質或意外行為，軟體候選可能不符合定義的認證標準。當發現影響環境的問題時，組織應採用更簡化的流程來認證以後的臨時版本。這有助於減少資源需求，並且如果組織能夠瞭解發生了什麼變化以及哪些缺陷已解決，總體而言是有效的。組織遇到初始候選版本的問題並認證後續過渡期Cisco IOS版本的情況並不少見。如果存在某些問題，組織還可以執行有限的認證或提供警告，並且可以在新的過渡版本通過驗證後升級到經過完全認證的版本。下面的流程圖是一個基本認證流程，包括品質門（每個模組後都會有回顧）：

設計 — 選擇和驗證Cisco IOS版本

通過明確定義的方法來選擇和驗證Cisco IOS版本，可幫助組織減少由於失敗的升級嘗試和計畫外的軟體缺陷而導致的計畫外停機時間。

設計階段包括候選管理和測試/驗證。候選管理是用來為定義的軟體路徑識別特定版本的過程。測試/驗證是認證過程的一部分，它確保確定的軟體版本在要求的路徑內成功。測試/驗證應在具有摺疊拓撲和配置且非常類似於生產環境的實驗室環境中進行。

Cisco IOS選擇和驗證的策略和工具

每個組織都應該有一個選擇和驗證網路標準Cisco IOS版本的流程，從選擇Cisco IOS版本的流程開始。來自架構、工程和運營的跨職能團隊應定義並記錄候選管理流程。批准後，應將流程移交給相應的交付組。此外還建議建立標準候選管理模板，該模板可在標識出候選資訊時進行更新。

並不是所有組織都有可以輕鬆模擬生產環境的複雜實驗室環境。有些組織會跳過實驗室測試，因為這樣不僅費用高，而且可以在網路中試用新版本，而不會對業務產生重大影響。但是，我們鼓勵高可用性組織構建模擬生產網路的實驗室，並開發測試/驗證流程，以確保新Cisco IOS版本獲得高測試覆蓋率。一個組織應該允許大約6個月的時間來建造實驗室。在此期間，組織應制定具體的測試計畫和流程，以確保實驗室能夠充分發揮其優勢。對於Cisco IOS，這意味著為每個所需的軟體路徑建立特定的Cisco IOS測試計畫。這些流程在大型組織中非常關鍵，因為許多實驗室未用於新產品和軟體的引入。

以下各節簡要介紹用於選擇和驗證Cisco IOS的候選管理和測試/驗證工具。

候選人管理工具

注意：要使用下面提供的大多數工具，您必須是註冊使用者，而且必須登入。

• 發行說明 — 提供有關發行版的硬體、模組和功能支援的資訊。應在候選管理期間檢查發行說明，以確保在可能的發行版中存在所有必需的硬體和軟體支援，並瞭解任何遷移問題，包括不同的預設行為或升級要求。

測試和驗證工具

測試和驗證工具用於測試和驗證網路解決方案，包括新的硬體、軟體和應用程式。

• Traffic Generator — 生成多協定流量流和原始資料包速率，用於模擬使用特定協定的任何特定鏈路的速率。使用者可以指定源、目標MAC和套接字型大小，這些值可以按指定步驟遞增，也可以配置為靜態/固定或隨機遞增。流量生成器可以為以下協定生成資料包：

  • IP

  • 網際網路封包交換(IPX)

  • DECnet

  • 蘋果

  • 施樂網路系統(XNS)

  • 網際網路控制訊息通訊協定 (ICMP)

  • 網際網路群組管理協定(IGMP)

  • 無連線網路服務(CLNS)

  • 使用者資料包通訊協定 (UDP)

  • 虛擬整合網路服務(VINES)

  • 資料鏈路資料包

  Agilent 和Spirent Communications 提供了工具。

• Packet Counter/Capture/Decoder(Sniffer) — 允許客戶選擇性地在所有資料包和資料鏈路層捕獲和解碼資料包。該工具能夠允許使用者指定過濾器，從而僅捕獲指定的協定資料。過濾器還允許使用者指定捕獲與特定IP地址、埠號或MAC地址匹配的資料包。Sniffer Technologies 中提供了工具。

• Network Simulator/Emulator — 允許客戶根據生產網路要求填寫特定路由器的路由表。支援生成IP路由資訊協定(RIP)、OSPF、中間系統到中間系統(IS-IS)、內部網關路由協定(IGRP)、增強型IGRP(EIGRP)和邊界網關協定(BGP)路由器。PacketStorm Communications和Spirent Communications提供了工具。

• Session Emulators — 生成滑動視窗多協定流量流，並能夠跨測試網路向接收裝置傳送多協定流量流。接收裝置將資料包回應要求源。源裝置驗證傳送、接收、亂序資料包和錯誤資料包的數量。該工具還提供在傳輸控制協定(TCP)中定義視窗引數的靈活性，從而密切模擬實驗網路中的客戶端/伺服器流量會話。Empirix 提供了這些工具。

• 大型網路模擬器 — 幫助測試大型環境的可擴充性。這些工具能夠建立並輕鬆將控制型別流量注入到實驗拓撲中，以便更接近地模擬生產環境。功能包括路由注入器、協定鄰居和第2層協定鄰居。Agilent 和Spirent Communications 提供了工具。

• WAN模擬器 — 非常適合測試頻寬和延遲可能成問題的企業應用流量。藉助這些工具，組織可以在本地測試具有估計延遲和頻寬的應用程式，以瞭解應用程式如何在WAN上運行。這些工具通常用於應用程式開發以及企業組織內的應用程式分析測試型別。Adtech是Spirent Communications和Shunra的一個分 ，提 供WAN模擬工具。

候選人管理

候選管理是確定特定硬體和已啟用的功能集的軟體版本要求和潛在風險的過程。建議組織先花四至八個小時適當研究軟體要求、版本說明、軟體缺陷和潛在風險，然後再試運行版本。以下概述了候選人管理的基礎：

• 通過思科線上連線(CCO)工具識別軟體候選者。

• 風險分析軟體成熟度、新功能或代碼支援。

• 在整個生命週期中識別和跟蹤已知軟體錯誤、問題和要求。

• 確定所選映像的預設配置行為。

• 維護潛在候選人更改的退出和前滾候選。

• 蟲子清理。

• 思科高級服務支援。

隨著思科產品和軟體培訓的數量不斷增加，識別軟體候選軟體變得更加複雜。CCO現在擁有多種工具，包括Cisco IOS升級規劃工具、軟體搜尋工具、軟體 — 硬體相容性矩陣，以及可幫助組織識別潛在版本候選的產品升級工具。這些工具位於http://www.cisco.com/cisco/software/navigator.html。

其次，分析潛在候選軟體的風險。這是瞭解軟體當前位於成熟度曲線上的位置，然後權衡部署要求與發行候選的潛在風險的過程。例如，如果組織希望將早期部署(ED)軟體置於關鍵的高可用性環境中，應考慮成功認證所需的相關風險和資源。組織應至少為高風險環境新增軟體管理資源，以確保成功。另一方面，如果通用部署(GD)版本能夠滿足組織的需求，那麼需要的軟體管理資源就會減少。

識別到潛在版本和風險後，請執行錯誤清理，以確定是否存在任何可能妨礙認證的已識別災難性錯誤。思科的Bug Watcher、Bug Navigator和Bug Watcher Agent可幫助識別潛在問題，應在整個軟體生命週期內使用，以識別潛在的安全性或缺陷問題。

還應檢查新的候選軟體，看其是否存在潛在的預設配置行為。這可以通過檢視新軟體映像的發行說明以及檢視與指定平台上載入的潛在映像的配置差異來完成。候選者管理還可以包括識別退出版本或轉至版本（如果選擇的版本在流程中的某個點不符合認證標準）。通過檢視與指定路徑的功能相關的錯誤，組織可以維護潛在的認證候選人。

思科高級服務也是候選管理的一個優秀工具。該團隊可以進一步洞察許多不同垂直市場環境中的大量行業專家之間的開發過程和合作。通常，由於對其他組織中運行的生產軟體版本具有專業知識和可見性，思科支援部門內存在最佳的錯誤清除或候選管理功能。

測試和驗證

總的來說，測試和驗證是管理最佳實踐和高可用性網路的一個重要方面。正確的實驗室測試可以顯著減少生產停機時間，幫助培訓網路支援人員，並幫助簡化網路實施流程。然而，為了有效運行，組織必須分配必要的資源來構建和維護合適的實驗室環境，應用必要的資源進行正確的測試，並使用建議的測試方法體系（包括測量收集）。如果沒有上述任何方面，測試和驗證流程可能無法滿足組織的期望。

大多數企業組織沒有推薦的測試實驗室環境。因此，許多組織都錯誤地部署了解決方案，遇到了網路更改故障，或者遇到了可能在實驗室環境中隔離出來的軟體問題。在某些環境中，這是可以接受的，因為停機的成本無法抵消複雜的實驗室環境的成本。但是，在許多組織中，不能容忍停機。強烈建議這些組織開發推薦的測試實驗室、測試型別和測試方法以提高生產網路品質。

測試實驗室和環境

實驗室應是一個獨立區域，有足夠的空間容納辦公桌、工作台、測試裝置和裝置機櫃或機架。大多數大型組織需要4到10個機架的裝置來模擬生產環境。建議在測試進行期間使用某些物理安全措施來幫助維護測試環境。這有助於防止實驗室測試因其他實驗室優先事項（包括硬體借用、培訓或實施預演）而中斷。建議使用邏輯安全來防止偽造路由進入生產網路或不希望的流量離開實驗。在實驗網關路由器上使用路由過濾器和擴展訪問清單即可完成此操作。連線到生產網路有助於從生產環境中下載軟體並訪問實驗室網路。

實驗室拓撲應能模擬任何特定測試計畫的生產環境。建議再現硬體、網路拓撲和功能配置。當然，複製實際拓撲幾乎是不可能的，但可以做的是複製網路層次和生產裝置之間的互動。這對於多個裝置之間的協定或功能互動非常重要。某些測試拓撲會因軟體測試要求而有所不同。例如，WAN邊緣Cisco IOS測試不應需要LAN型別裝置或測試，而且可能僅需要WAN邊緣路由器和WAN分佈路由器。關鍵是模擬軟體功能而不重複生產。在某些情況下，甚至可以使用工具來模擬大規模行為，如協定鄰居計數和路由表。

還需要一些工具來改進模擬生產環境和收集測試資料的能力，從而幫助處理一些測試型別。有助於模擬生產的工具包括流量收集器、流量發生器和WAN模擬裝置。Smartbits是能夠收集和重放網路流量或生成大量流量的裝置的良好示例。組織也可以從有助於收集資料的裝置（如協定分析器）中獲益。

實驗室還需要一些管理。許多大型組織都有一位全職實驗室經理負責管理實驗室網路。其他組織利用現有的架構和工程團隊進行實驗室驗證。實驗室管理職責包括訂購實驗室裝置和資產跟蹤、佈線、物理空間管理、定義實驗室規則和方向、實驗室計畫、實驗室文檔、設定實驗室拓撲、編寫測試計畫、執行實驗室測試以及管理潛在的已發現問題。

測試型別

總體而言，可以執行許多不同型別的測試。在建立完整的測試實驗室和測試計畫以測試多種配置中的所有內容之前，組織應瞭解不同型別的測試、測試的意圖，以及思科工程、技術行銷或客戶支援部門是否應該或可能負責某些各種測試。客戶測試計畫通常涵蓋更暴露的測試型別。下表幫助理解不同的測試型別、應在何時執行測試以及測試責任方。

在下面的測試中，正確測試組織的特定功能集、拓撲和應用組合通常是最有價值的。瞭解思科執行完整的功能和回歸測試很重要，但思科無法用您的特定拓撲、硬體和配置功能組合測試您組織的應用配置檔案。事實上，測試所有功能、硬體、模組和拓撲排列是不可行的。此外，思科無法測試與第三方裝置的互操作性。思科建議組織測試其環境中發現的硬體、模組、功能和拓撲的精確組合。本測試應在實驗室中進行，使用摺疊拓撲來表示貴組織的生產環境，以及其他支援的測試型別，如效能、互操作性、中斷和燒錄。

測試方法

一旦組織知道他們在測試什麼，就應該為測試過程開發一種方法。最佳實踐測試方法的目的是幫助確保議定的測試是全面的、有完整文檔記錄的、易於複製的，並且在發現潛在的生產問題方面是很有價值的。為測試較新版本或測試實驗室環境中發現的錯誤修正，文檔記錄和重新建立實驗場景尤其重要。測試方法的步驟如下所示。某些測試步驟也可以同時執行。

1. 建立模擬測試生產環境的測試拓撲。WAN邊緣測試環境可能只包含幾個核心路由器和一個邊緣路由器，而LAN測試可能包含更多最能代表環境的裝置。

2. 配置模擬生產環境的功能。實驗裝置的配置應與預期的生產裝置硬體和軟體配置緊密匹配。

3. 編寫測試計畫、定義測試和目標、記錄拓撲並定義功能測試。測試包括基本協定驗證、show命令驗證、中斷測試和老化測試。下表列出了測試計畫內的特定測試的示例。

4. 驗證路由和協定功能。記錄或基線預期的show命令結果。協定應包括第2層協定(如ATM、幀中繼、思科發現協定(CDP)、乙太網和生成樹)以及第3層協定（如IP、IPX和組播）。

5. 驗證功能功能。記錄或基線預期的show命令結果。功能可能包括全域性配置命令和任何關鍵功能，如身份驗證、授權和記帳(AAA)。

6. 模擬負載，這應在生產環境中實現。可以使用流量收集器/生成器進行負載模擬。通過調查任何資料包丟失，驗證預期網路裝置利用率變數，包括CPU、記憶體、緩衝區利用率和介面統計資訊。記錄或基線預期的show命令結果。

7. 執行需要裝置和軟體處理或防止負載不足時的中斷測試。例如，卡移除、鏈路擺動、路由擺動和廣播風暴。確保根據網路中正在使用的功能生成正確的SNMP陷阱。

8. 將測試結果和裝置測量記錄為測試應該可重複。

裝置測量

在測試階段，執行並記錄以下測量結果，以確保裝置正確運行：

• 記憶體使用情況

• CPU負載

• 緩衝區使用情況

• 介面統計資訊

• 路由表

• 特定調試

測量資訊因執行的具體測試而異。還可能提供其他計量資訊，這取決於所解決的具體問題。

對於要測試的每個應用程式，測量引數以確保對給定應用程式沒有不利的效能影響。這通過利用可用於比較部署前和部署後效能的效能基線來完成。應用測量測試的示例包括：

• 登入到網路所用的平均時間。

• 網路檔案系統(NFS)複製一組檔案所用的平均時間。

• 啟動應用程式並收到第一個螢幕提示的平均時間。

• 其他特定於應用程式的引數。

實施 — Swift和成功的Cisco IOS部署

一個明確定義的實施流程允許組織高效地部署新的Cisco IOS版本。

實施階段包括試點過程和實施過程。試點過程確保Cisco IOS版本在環境中成功，而實施過程則允許快速、成功地進行更大規模的Cisco IOS部署。

Cisco IOS部署的策略和工具

Cisco IOS部署的策略是通過試用流程執行最終認證，並使用升級工具和明確定義的實施流程快速部署。

在啟動網路試運行流程之前，許多組織會制定一般試運行准則。試點指南應包含對所有試點的期望值，例如成功標準、可接受的試點位置、試點文檔、試點所有者期望值、使用者通知要求和預期的試點持續時間。來自工程、實施和操作的跨職能團隊通常參與構建整體試點指南和試點流程。試點過程建立後，各實施小組通常可以使用確定的最佳做法方法成功實施試點。

一旦新軟體版本獲得部署批准和最終認證，組織需要開始規劃Cisco IOS升級。規劃首先要確定新的映像要求，包括平台、記憶體、快閃記憶體和配置。架構和工程團隊通常在Cisco IOS管理生命週期的候選管理階段定義新的軟體映像要求。確定要求後，每個裝置都必須由實施組進行驗證，並可能進行升級。CiscoWorks2000 Software Image Manager(SWIM)模組還可以通過根據裝置清單驗證Cisco IOS要求來執行驗證步驟。當所有裝置都經過驗證並升級為正確的新映像標準後，實施組可以利用CiscoWorks2000 SWIM模組作為軟體部署工具，開始緩慢啟動實施流程。

成功部署新映像多次後，組織可以使用CiscoWorks SWIM開始快速部署。

Cisco IOS清單管理

CiscoWorks2000 Resource Manager Essentials(RME)清單管理器通過基於網路的報告工具（基於軟體版本、裝置平台和裝置名稱，對Cisco IOS裝置進行報告和排序），大大簡化了Cisco路由器和交換機的版本管理。

Cisco IOS SWIM

CiscoWorks2000 SWIM可幫助降低升級過程中容易出錯的複雜性。CCO的內建連結將軟體修補程式的思科線上資訊與網路中部署的Cisco IOS和Catalyst軟體相關聯，突出顯示相關技術說明。新的規劃工具可找到系統要求，並在需要硬體升級（啟動ROM、快閃記憶體RAM）以支援建議的軟體映像更新時傳送通知。

在開始更新之前，系統會根據目標交換機或路由器的清單資料驗證新映像的前提條件，以確保成功升級。當更新多個裝置時，SWIM會同步下載任務，並允許使用者監視作業的進度。計畫任務通過簽核流程進行控制，使經理能夠在啟動每個升級任務之前授權技術人員的活動。RME 3.3具有分析思科IGX、BPX和MGX平台軟體升級的功能，從而大大簡化並減少了確定軟體升級的影響所需的時間。

試點流程

為了最小化潛在風險並更安全地捕獲任何剩餘生產問題，建議使用軟體試運行。對於新技術部署而言，試用通常更為重要，但許多新軟體部署將連結到新服務、功能或硬體，而在這些方面，試用更為重要。個別試點計畫應考慮試點選擇、試點持續時間及衡量標準。試點選擇是確定應在何時何地開展試點工作的過程。試點測量是收集所需資料以識別成功和失敗或潛在問題的過程。

試點選擇確定試點將在何處以及如何完成。導頻可以從低影響區域中的一台裝置開始，並擴展到高影響區域中的多個裝置。在選擇可以減少影響的試運行時，需要考慮以下事項：

• 安裝在網路的一個區域內，可恢復單個裝置因冗餘造成的影響。

• 在所選裝置後面使用者數量最少的網路區域中，這些使用者能夠處理一些可能的生產影響。

• 考慮按照架構界線分隔試運行。例如，在網路的接入層、分佈層和/或核心層進行試運行。

此引導的持續時間應基於充分測試和評估所有裝置功能所需的時間。這應該包括老化以及正常流量負載下的網路。持續時間還取決於代碼升級中的步驟以及運行Cisco IOS的網路區域。如果Cisco IOS是新的主要版本，則首選較長的試用期。然而，如果升級是僅包含最低新功能的維護版本，則只需較短的試用期即可。

在試驗階段，以與初始測試相似的方式監控和記錄結果非常重要。這可能包括使用者調查、試運行資料收集、問題收集以及成功/失敗標準。個人應直接負責跟蹤和監測試點進展，以確保發現所有問題，並確保參與試點的使用者和服務對試點結果滿意。如果在試用或生產環境中成功發佈版本，大多陣列織將對其進行認證。此步驟在某些環境中是一個嚴重故障，因為在沒有確定或記錄衡量標準或成功標準時，您認為它取得了成功。

實現

在生產網路中完成試運行階段後，開始Cisco IOS實施階段。實施階段包括幾個步驟來確保軟體升級成功和實施效率，包括實施緩慢啟動、最終認證、升級準備、升級自動化和最終驗證。

實施緩慢啟動是指緩慢實施新測試的版本，以確保映像在最終認證和完全規模轉換之前完全暴露在生產環境中。有些組織可能從一台裝置和一天暴露後開始，然後第二天再進入兩個裝置升級，也許第二天還會再升級幾個。在將大約10台裝置投入生產後，組織可能需要等待1到2週才能對特定Cisco IOS版本進行最終認證。在最終認證後，組織可以更快速地部署已識別的版本，同時具有更高的可信度。

在緩慢啟動過程之後，應使用裝置清單和載入程式、DRAM和快閃記憶體的最低Cisco IOS標準矩陣來檢視和驗證所有確定為升級的裝置，以確保滿足要求。資料可通過內部工具、第三方SNMP工具或使用CiscoWorks2000 RME獲取。CiscoWorks2000 SWIM在實施之前會檢查或檢查這些變數。但是，瞭解在實施嘗試期間預期的結果始終是一個好主意。

如果計畫升級的類似裝置超過100台，強烈建議採用自動化方法。自動化已證明，在大型部署期間，通過內部升級1000台裝置（包括和不包括SWIM），可提高升級效率和裝置升級成功率。鑑於升級期間執行的驗證程度，思科建議將CiscoWorks 2000 SWIM用於大型部署。如果檢測到問題，SWIM甚至會退出Cisco IOS版本。SWIM通過建立和安排升級作業來發揮作用，其中，為作業配置了裝置、所需的升級映像和作業的運行時間。每個作業應包含12個或更少的裝置升級，並且最多可以同時運行12個作業。SWIM還驗證計畫的Cisco IOS升級版本在升級後是否成功運行。建議每次裝置升級大約需要20分鐘（包括驗證）。 使用此公式，組織可以每小時升級三十六台裝置。思科還建議每晚最多升級100台裝置，以減少潛在的問題暴露風險。

在自動升級之後，應進行一些驗證以確保成功。CiscoWorks2000 SWIM工具可在升級後運行自定義指令碼以執行進一步的成功驗證。驗證包括驗證路由器是否具有適當數量的路由、確保邏輯/物理介面已啟動並處於活動狀態，或驗證裝置是否可訪問。以下示例核對表可以完全驗證Cisco IOS部署是否成功：

• 裝置是否正確重新載入？

• 裝置是否可通過網路管理系統(NMS)平台執行ping操作並可以訪問？

• 裝置上的預期介面是否啟動並處於活動狀態？

• 裝置是否具有正確的路由協定鄰接關係？

• 是否填寫路由表？

• 裝置是否正確傳遞流量？

運營 — 管理高可用性Cisco IOS實施

Cisco IOS環境的高可用性最佳實踐操作有助於降低網路複雜性、縮短問題解決時間並提高網路可用性。Cisco IOS管理的操作部分包括用於管理Cisco IOS的策略、工具和最佳實踐方法。

Cisco IOS操作的最佳實踐包括軟體版本控制、Cisco IOS系統日誌管理、問題管理、配置標準化和可用性管理。軟體版本控制是指跟蹤、驗證和改進已識別軟體路徑內的軟體一致性的過程。Cisco IOS系統日誌管理是主動監控和對Cisco IOS生成的更高優先順序系統日誌消息採取行動的過程。問題管理是指快速高效地收集軟體相關問題的關鍵問題資訊，以便幫助防止將來再次發生問題的做法。配置標準化是標準化配置的過程，標準化配置可以減少未經測試的代碼在生產中執行的可能性，並標準化網路協定和功能行為。可用性管理是根據度量、改進目標和改進專案來改進可用性的過程。

Cisco IOS操作策略和工具

有許多品質策略和工具可以幫助管理Cisco IOS環境。Cisco IOS操作的第一個關鍵策略是使環境儘可能簡單，儘可能避免配置和Cisco IOS版本中的變化。已經討論了Cisco IOS認證，但配置一致性是另一個關鍵領域。架構/工程組應負責建立配置標準。然後，實施和操作組負責通過Cisco IOS版本控制和配置標準/控制來配置和維護標準。

Cisco IOS操作的第二個策略是能夠識別和快速解決網路故障。通常，在使用者撥入網路問題之前，應由操作組確定網路問題。問題也應儘快解決，不對環境造成進一步影響或改變。此領域的一些關鍵最佳實踐是問題管理和Cisco IOS系統日誌管理。Cisco Output Interpreter是一種可幫助快速診斷Cisco IOS軟體崩潰的工具。

第三個策略是持續改進。主要過程是改進基於品質的可用性改進計畫。通過對所有問題（包括Cisco IOS相關問題）執行根本原因分析，組織可以改進測試覆蓋範圍、縮短問題解決時間，並改進消除或減少中斷影響的流程。組織還可以檢視常見問題並構建流程以更快地解決這些問題。

Cisco IOS操作工具包括用於軟體版本控制的清單管理(CiscoWorks2000 RME)、用於管理Syslog消息的Syslog管理，以及用於管理裝置配置一致性的裝置配置管理器。

系統日誌管理

系統日誌消息是裝置傳送到收集伺服器的消息。這些消息可能是錯誤（例如，連結斷開），或者可能是資訊性消息，例如某人已進入裝置配置終端的時間。

系統日誌管理工具記錄並跟蹤路由器和交換機接收的系統日誌消息。某些工具具有過濾器，允許刪除可能從重要郵件中刪除的有害郵件。系統日誌工具還應允許根據收到的消息建立報告。報告可以按時間段、裝置、消息型別或消息優先順序顯示。

CiscoWorks2000 RME系統日誌管理器是最常用的Cisco IOS管理系統日誌工具。其他可用工具包括SL4NT，一個來自Netal的共用軟體程式 ，和來自OpenSystems的Private I。

CiscoWorks裝置組態管理員

CiscoWorks2000裝置配置管理器維護活動存檔，並提供跨多個思科路由器和交換機更新配置更改的簡單方法。Configuration manager會監視網路以瞭解配置更改，在檢測到更改時更新存檔，並將更改資訊記錄到「更改稽核服務」中。基於Web的使用者介面允許您搜尋歸檔檔案以查詢特定的配置屬性，並比較兩個配置檔案的內容，以便輕鬆識別差異。

思科輸出直譯器

思科輸出直譯器是用於診斷軟體強制崩潰的工具。此工具可幫助識別軟體缺陷，而無需致電思科技術協助中心(TAC)，也可在軟體強制崩潰後用作TAC的主要資訊。這一資訊一般有助於加快問題的解決，至少就所需資訊收集而言是如此。

軟體版本控制

軟體版本控制是僅實施標準化的軟體版本並監控網路以驗證或可能由於不滿足版本要求而更改軟體的過程。一般而言，軟體版本控制是通過認證過程和標準控制完成的。許多組織在中央Web伺服器上發佈版本標準。此外，實施人員還接受培訓，以審查正在運行的版本，並在該版本不符合標準時對其進行更新。有些組織有品質門程式，通過審計完成二級驗證，以確保標準在執行期間得到遵守。

在操作過程中，經常會看到網路中的非標準版本，尤其是在網路和操作人員很大時。這可能是因為未受過培訓的新員工、配置錯誤的引導命令或未檢查的實施。建議定期使用CiscoWorks 2000 RME等工具驗證軟體版本標準，這些工具可以按Cisco IOS版本對所有裝置分類。識別出非標準後，應立即標籤這些標準，並啟動故障單或更改單，以使版本符合所識別的標準。

主動式系統日誌管理

系統日誌收集、監控和分析是推薦的故障管理流程，用於解決難以或無法通過其他方法識別的更多Cisco IOS特定網路問題。系統日誌收集、監控和分析有助於縮短解決問題的時間，方法是在出現更嚴重的網路問題或由使用者報告之前，主動識別和解決許多故障。與對大量MIB變數進行一致SNMP輪詢相比，系統日誌還提供了收集各種問題的更有效方法。通過使用正確的Cisco IOS配置、CiscoWorks2000 RME等系統日誌關聯工具和/或Syslog事件管理完成系統日誌收集、監控和分析。系統日誌事件管理是通過以下方法完成的：分析收集的系統日誌資料，找出關鍵消息，然後將警報或陷阱轉發到事件管理器，以便進行即時通知和解決。

系統日誌監控需要NMS工具支援或指令碼來幫助分析和報告系統日誌資料。這包括按日期或時間段、裝置、系統日誌消息型別或消息頻率對系統日誌消息進行排序的功能。在大型網路中，可以實施工具或指令碼來分析系統日誌資料，並向事件管理系統或操作人員和工程人員傳送警報或通知。如果未使用各種系統日誌資料的警報，組織應至少每天檢視優先順序較高的系統日誌資料，並為潛在的問題建立故障單。為了主動檢測通過正常監控可能看不到的網路問題，應定期檢視和分析歷史系統日誌資料，以檢測可能並不表示立即出現的問題，但可以在問題影響服務之前提供其指示的情況。

問題管理

許多客戶由於缺少問題管理流程而經歷額外的停機時間。如果網路管理員嘗試結合使用影響服務的命令或配置更改來快速解決問題，而不是花時間進行問題識別、資訊收集和分析良好的解決方案路徑，則可能會發生額外的停機。在此區域觀察到的行為包括重新載入裝置，或者在調查問題及其根本原因之前清除IP路由表。在某些情況下，這是由第一級支援問題解決目標導致的。所有軟體相關問題的目標都應該在恢復連線或服務之前快速收集進行根本原因分析所需的必要資訊。

建議在較大環境中執行問題管理流程。此過程應包含一定程度的預設問題描述和適當的show命令集合，然後再升級到第二層。第一層支援絕不應清除路由或重新載入裝置。最理想的是，第一層組織應快速收集資訊並上報到第二層。通過在最初花費幾分鐘時間識別問題或描述問題，發現根本原因的可能性大大增加，從而允許權宜之計、實驗室識別和錯誤報告。第二級支援應精通思科可能需要的資訊型別，以便診斷問題或提交錯誤報告。其中包括記憶體轉儲、路由資訊輸出和裝置show命令輸出。

組態標準化

全域性裝置配置標準代表跨同類裝置和服務維護標準全域性配置引數的實踐，從而實現企業範圍的全域性配置一致性。全域性配置命令是應用於整個裝置而不是單個埠、協定或介面的命令。全域性配置命令通常會影響裝置訪問、常規裝置行為和裝置安全性。在Cisco IOS中，這包括服務命令、IP命令、vty命令、控制檯埠命令、logging命令、AAA/TACACS+命令、SNMP命令和標語命令。在全域性裝置配置標準中，另一個重要問題是適當的裝置命名約定，管理員可以根據裝置的域名系統(DNS)名稱識別裝置、裝置型別和裝置位置。全域性配置一致性對網路環境的總體可支援性和可靠性非常重要，因為它有助於降低網路複雜性和增強網路可支援性。由於不正確或不一致的裝置行為、SNMP訪問和常規裝置安全，通常會在沒有配置標準化的情況下遇到支援困難。

維護全域性裝置配置標準通常由為類似網路裝置建立和維護全域性配置引數的內部工程或操作組完成。在TFTP目錄中提供一個全域性配置檔案的副本也是一種很好的做法，這樣就可以將它們首先下載到所有新調配的裝置。此外，一個可訪問Web的檔案也非常有用，它為標準配置檔案提供了每個配置引數的說明。有些組織甚至會定期全域性配置類似的裝置，以幫助確保全域性配置一致性，或定期檢查裝置是否達到正確的全域性配置標準。協定和介面配置標準代表維護介面和協定配置標準的實踐。

協定和介面配置的一致性通過降低網路複雜性、提供預期的裝置和協定行為以及提高網路可支援性提高了網路可用性。協定或介面配置不一致可能導致意外的裝置行為、流量路由問題、連線問題增加以及反應性支援時間延長。介面配置標準應包括CDP介面描述符、快取配置和其他特定於協定的標準。協定特定的配置標準可能包括：

• IP路由配置

• DLSW配置

• Access-list configuration

• ATM組態

• 幀中繼配置

• 生成樹配置

• VLAN分配和配置

• 虛擬主幹通訊協定(VTP)

• HSRP

注意：根據網路中的配置，可以採用其他協定特定的配置標準。

IP標準的示例可能包括：

• 子網大小

• 已使用的IP地址空間

• 使用的路由協定

• 路由協定配置

維護協定和介面配置標準通常由網路工程和實施小組負責。工程小組應負責識別、測試、驗證和記錄標準。然後，實施組負責使用工程文檔或配置模板來調配新服務。工程小組應編制所需標準所有方面的檔案，以確保一致性。還應建立配置模板以幫助實施配置標準。操作組還應接受有關標準的培訓，並能夠發現非標準配置問題。在測試、驗證和認證階段，配置一致性有很大幫助。事實上，如果沒有標準化的配置模板，幾乎不可能對中等規模網路的CIsco IOS版本進行充分的測試、驗證或認證。

可用性管理

可用性管理是以網路可用性作為品質改進指標的品質改進過程。許多組織現在都在測量可用性和中斷型別。中斷型別可能包括硬體、軟體、鏈路/載波、電源/環境、設計或使用者錯誤/過程。通過識別停機並在恢復後立即執行根本原因分析，公司可以確定提高可用性的方法。幾乎所有已經實現高可用性的網路都存在一些品質改進過程。

附錄A - Cisco IOS版本概述

Cisco IOS軟體發佈策略是圍繞著健全的軟體開發、品質保證和快速的上市時間而制定的，這些對於思科客戶網路的成功至關重要。

該流程圍繞四類版本定義，具體解釋如下：

• 早期部署版本(ED)

• 主要版本

• 有限部署版本(LD)

• 通用部署版本(GD)

思科建立並維護一個IOS規劃，其中包含有關各個版本、目標市場、遷移路徑、新功能說明等的資訊。

下圖說明Cisco IOS軟體版本的生命週期：

ED版本

Cisco IOS ED版本是給市場帶來新發展的工具。ED版本的每個維護版本不僅包括錯誤修復，還包括一組新功能、新平台支援，以及對協定和Cisco IOS基礎設施的一般增強功能。ED版本的功能和平台每隔一到兩年移植到下一個主線Cisco IOS版本。

有四種型別的ED版本，每種版本的發佈模型和生命週期里程碑略有不同。ED版本可分為：

• 整合技術早期部署(CTED)版本 — 新的Cisco IOS版本模型使用整合的ED版本系列（也稱為「T」系列）來引入Cisco IOS的新功能、新硬體平台和其他增強功能。它們被稱為整合技術，因為它們超越了內部業務單元(BU)和業務線(LOB)的定義。整合技術版本的示例包括Cisco IOS 11.3T、12.0T和12.1T。

• Specific Technology Early Deployment(STED)版本 — STED版本與CTED版本具有類似的功能承諾特徵，但它們針對特定技術或市場領域。它們始終在特定平台上發佈，並且僅受思科業務部門的監管。STED版本使用主版本附加的兩個字母來標識。STED版本的示例包括Cisco IOS 11.3NA、11.3MA、11.3WA和12.0DA。

• 特定市場早期部署(SMED)版本 — Cisco IOS SMED與STED的區別在於它們面向特定的垂直市場領域（ISP、企業、金融機構、電信公司等）。中小型企業(SMED)只對目標垂直市場所使用的特定相關平台有特定的技術功能要求。它們可以與CTED區別開來，因為它們只是為與垂直市場相關的特定平台而構建，而CTED則是根據更廣泛的技術要求為更多的平台而構建。Cisco IOS SMED版本由附加在主發行版本上的一個字母字元標識（與CTED一樣）。 SMED的示例包括Cisco IOS 12.0S和12.1E。

• 壽命短的早期部署版本，也稱為X版本(XED)- Cisco IOS XED版本向市場引入新的硬體和技術。它們不提供軟體維護版本，也不提供常規軟體臨時版本。如果在與CTED收斂之前在XED中發現缺陷，則啟動軟體重建並將數字附加到名稱中。例如，Cisco IOS版本12.0(2)XB1和12.0(2)XB2是12.0(2)XB重建的範例。

主要版本

主要版本是Cisco IOS軟體產品的主要部署工具。它們由Cisco IOS技術部門管理，並整合了之前的ED版本中的功能、平台、功能、技術和主機激增功能。Cisco IOS主要版本追求更高的穩定性和品質。因此，主要版本不接受新增功能或平台。每個維護版本僅提供錯誤修正。例如，Cisco IOS軟體版本12.1和12.2為主要版本。

主要版本已安排維護更新，稱為完全回歸測試的維護版本，包含最新的錯誤修復，並且不支援新的平台或功能。主要版本的版本號標識主要版本及其維護級別。在Cisco IOS軟體版本12.0(7)中，12.0是主要版本的編號，7是其維護級別。完整的版本號是12.0(7)。 同樣，12.1是主要版本，12.1(3)是主要思科IOS軟體版本12.1的第三個維護版本。

有限部署(LD)版本

LD是從FCS到主版本常規部署的Cisco IOS成熟階段。Cisco IOS ED版本僅處於有限的部署階段，因為它們從未獲得GD認證。

常規部署(GD)版本

在發行週期內的某個時間點，思科將宣佈主要發行版為GD認證做好準備。只有主版本才能達到GD狀態。當思科確信該版本符合以下條件時，它符合GD認證里程碑：

• 通過在不同網路中廣泛接觸市場而得到證明。

• 通過穩定性指標和錯誤趨勢分析指標進行鑑定。

• 通過客戶滿意度調查獲得資格。

• 客戶發現該版本中的缺陷與之前四個維護版本相比呈減少趨勢。

由TAC工程師、高級工程服務(AES)工程師、系統測試工程和Cisco IOS工程組成的客戶宣傳GD認證跨職能團隊，將評估該版本的所有未決缺陷。該團隊最終批准GD認證。一旦發行版本達到GD狀態，該發行版本的每個後續版本都為GD。因此，一旦發佈宣告為GD;它會自動進入受限維護階段。在此階段，對代碼的工程修改（包括主要代碼重做的錯誤修復）受到程式經理的嚴格限制和控制。這可確保不會在GD認證的Cisco IOS軟體版本中引入任何不良錯誤。GD通過特定的維護版本實現。該版本的後續維護更新也是GD版本。例如，Cisco IOS軟體版本12.0獲得12.0(8)的GD認證。 因此，Cisco IOS軟體版本12.0(9)、12.0(10)等是GD版本。

實驗或診斷影象

實驗或診斷映像有時也稱為工程特別計畫，只有在發現關鍵軟體問題時才會建立。這些影象不是正常釋放過程的一部分。此類別中的映像是專為協助診斷問題、測試錯誤修正或提供即時修正的客戶特定版本。如果不能等待下一個臨時或維護版本，則可以立即進行修復。實驗或診斷映像可以在任何受支援的軟體基礎上構建，包括任何發行型別的維護或過渡版本。沒有正式的命名約定，但在很多情況下，開發者會向基本映像名稱新增首字母、exp（用於實驗）或附加數字。這些映像僅暫時與思科開發一起受支援，因為Cisco TAC和Cisco IOS版本操作不維護支援文檔（如符號表或基本映像歷史記錄）。這些映像不經過思科內部測試。

發佈生命週期里程碑

在某個時候，GD版本將被最新網路技術所取代。因此，已建立釋放報廢流程，其中包含以下三個主要里程碑：

• 銷售結束(EOS) — 對於主要版本，EOS日期為首次商業發貨(FCS)日期後的三年。這將設定購買新系統版本的最終日期。EOS版本仍可從思科線上連線(CCO)下載，以進行維護升級。

• 工程結束(EOE)- EOE版本是GD版本的最後一個維護版本，通常在EOS版本發佈後三個月後發佈。客戶可以繼續從Cisco TAC獲得技術支援，也可以從CCO下載EOE版本。宣佈EOS和EOE版本和日期的產品公告將在計畫EOS日期之前一年發佈。此時，客戶應開始調查如何升級其Cisco IOS軟體以利用最新的網路技術。

• 壽命終止(EOL) — 在發行週期結束時，對Cisco IOS軟體版本的所有支援都已終止，並且在EOL日期無法下載。通常，EOL日期是EOE日期後的五年。EOL產品公告將在實際EOL日期前大約一年發佈。

Cisco IOS版本命名約定

Cisco IOS映像命名約定提供所有已發佈映像的完整配置檔案。名稱始終包括主版本識別符號和維護版本識別符號。該名稱還可以包括列車標誌符、重建標誌符（用於維護版本）、業務單元(BU)特定功能標誌符和BU特定功能標誌符重建識別符號。該格式可按如下方式細分：

A = Access Server/Dial technology (example:11.3AA)
B = Broadband (example:12.2B)
D = xDSL technology (example:12.2DA)
E = Enterprise feature set (example:12.1E)
H = SDH/SONET technology (example:11.3HA)
N = Voice, Multimedia, Conference (example:11.3NA)
M = Mobile (example:12.2MB)
S = Service Provider (example:12.0S)
T = Consolidated Technology (example:12.0T)
W = ATM/LAN Switching/Layer 3 (example:12.0W5)

以下圖表為Cisco IOS命名約定的不同部分新增標籤：

附錄B - Cisco IOS可靠性

Cisco IOS可靠性是思科不斷努力提高的一個領域。在討論以客戶為導向的最佳實踐之前，需要瞭解思科內部IOS品質和可靠性工作。這些部分主要旨在概述思科最近在Cisco IOS軟體品質方面所做的努力，以及客戶在軟體可靠性方面應做出哪些假設。

Cisco IOS品質計畫

思科有一個定義明確的IOS開發流程，稱為GEM Great Engineering Methodology(GEM)。 此過程分為三個階段：

• 戰略和規劃

• 執行

• 部署

生命週期中的一般領域包括功能介紹優先順序、開發、測試流程、軟體介紹階段、首次客戶發貨(FCS)、GD以及持續工程。思科還遵循許多來自諸如國際標準組織(ISO)、Telcordia（前身為Bellcore）、IEEE和卡內基梅隆軟體工程研究所等組織的軟體品質最佳實踐指南。這些准則已納入思科的GEM流程。思科軟體開發流程經過ISO 9001(1994)認證。

Cisco IOS軟體品質改進的主要過程是一個由客戶驅動的過程，思科通過此過程傾聽客戶意見、定義目標和指標、實施最佳實踐並監控結果。致力於提高軟體品質的跨組織團隊推動了這一過程。Cisco IOS品質改進過程的示意圖如下所示：

2002財年及以後，品質改進過程有著明確的可衡量的目標。這些目標的主要重點是通過在測試週期早期識別軟體問題來減少缺陷，減少缺陷積壓，提高功能一致性和軟體版本清晰度，並提供一致的可預測發佈計畫和軟體品質。解決這些領域的計畫包括新的測試覆蓋工具（確定較弱測試覆蓋的領域）、測試糾正措施流程改進以及Cisco IOS系統回歸測試增強功能。已應用其他資源來解決這些問題，並且所有主要Cisco IOS軟體版本均承諾執行任務和跨職能部門。

Cisco IOS版本測試

測試品質、範圍和覆蓋範圍是思科軟體可靠性品質工作的重要組成部分。總而言之，思科有以下IOS品質目標：

• 減少發現的思科內部回歸缺陷。這包括提高開發品質，以及識別靜態/動態分析中的更多問題。

• 減少客戶發現的缺陷

• 減少所有未解決的缺陷

• 提高軟體版本清晰度和功能一致性

• 提供具有計畫和品質的功能和維護版本

思科內部測試可視為一個流程，在此流程中，不同測試階段會識別出不同的缺陷。總體目標是找到正確的實驗室中的正確型別缺陷。這很重要，原因有幾個。第一個也是最重要的一點是，在隨後的測試階段中可能不存在足夠的測試覆蓋範圍。由於能夠在早期階段實現自動化，並且以後需要的複雜性和專業技能不斷增加，測試成本也逐級大幅增加。下圖說明了Cisco IOS的測試頻譜。

第一階段是軟體開發。思科在此領域進行了多項努力，幫助提高初始軟體品質。開發小組還會執行代碼審查，甚至是多次代碼審查，以確保其他開發人員批准軟體更改或新功能代碼。

下一步是單元測試。單元測試利用無需實驗即可檢查軟體互動的工具。DevTest是實驗室測試，包括功能/功能測試和回歸測試。特徵/功能測試旨在檢查給定特徵的功能。其中包括配置、取消配置和測試功能規範中定義的所有功能排列。回歸測試在自動測試設施中進行，旨在持續驗證功能性和行為。測試主要針對使用ping和有限流量生成的許多不同網路拓撲中的路由、交換和功能功能。由於可能的排列數量極多，因此回歸測試只能在功能、平台、軟體版本和拓撲的有限組合上完成，但是現在使用超過4000個回歸測試指令碼。整合測試旨在擴展實驗室測試功能，以獲得更全面的產品和互操作性。整合測試還通過將測試擴展到包括互操作性測試、壓力和效能測試、系統測試和否定測試（測試意外事件），增加了測試代碼覆蓋範圍。

下一實驗階段提供常見客戶環境的端到端測試。在上圖中，它們分別顯示為Financial Test Lab(FTL)和NSITE（客戶場景測試）。FTL是為關鍵任務金融界提供測試而建立的。NSITE是一個針對不同的Cisco IOS技術提供更深入測試的分組。NSITE和FTL實驗室專注於可擴充性和效能測試、可升級性、可用性和恢復能力、互操作性和可維護性等領域。可維護性側重於批次調配問題、事件管理/關聯和負載下的故障排除。思科針對不同的垂直市場還進行了其他實驗，以幫助測試這些領域。

上圖中顯示的最後一個實驗稱為客戶實驗。客戶測試是品質工作的延伸，建議對高可用性環境進行測試，以確保功能、配置、平台、模組和拓撲的準確組合已經過充分測試。測試覆蓋範圍應包括已識別拓撲中的網路可擴充性和效能、特定應用測試、已識別配置中的負面測試、非Cisco裝置的互操作性測試以及老化測試。

軟體MTBF

總可靠性最常見的指標之一是平均無故障時間(MTBF)。軟體可靠性的MTBF非常有用，因為已開發用於硬體可靠性的分析功能。使用一些現有標準可以更準確地確定硬體可靠性。思科利用基於Telcordia Technologies的標準MTBF資料的部件計數方法。然而，MTBF軟體沒有相應的分析方法，必須依靠現場測量進行MTBF分析。

在過去的三年中，思科對思科內部IT網路進行了軟體可靠性現場測量，此項工作在思科內部都有記錄。此工作基於軟體強制的Cisco IOS裝置崩潰，這可以通過網路管理SNMP陷阱資訊和正常運行時間資訊來衡量。研究使用識別軟體版本的統計對數常態分佈模型來識別軟體可靠性。軟體故障的平均修復時間(MTTR)基於平均路由器重新啟動和恢復時間。企業環境使用六分鐘的恢復時間，大型網際網路服務提供商(ISP)使用十五分鐘的恢復時間。 這項持續研究的結果表明，軟體在發佈或維護幾個版本後通常達到良好的九可用性，隨著時間的推移，軟體故障率會更高，因為軟體強制崩潰是唯一的停機原因。研究確定早期部署軟體的MTBF值範圍為從5,000小時到一般部署軟體的50,000小時。

對此工作最常見的反駁是，軟體強制崩潰不包括由於軟體可靠性問題導致的所有停機時間。如果將此度量用於品質改進工作，它可能有助於提高軟體強制崩潰的發生率，但可能忽略軟體可靠性的其他關鍵方面。由於使用統計方法難以準確預測軟體可靠性，這一評論在很大程度上仍未得到答覆。思科軟體品質統計人員得出的結論是，需要使用更大範圍的準確資料樣本集，才能使用更廣泛的中斷型別可靠地預測軟體MTBF。此外，由於網路複雜性、員工解決軟體相關問題的專業知識、網路設計、啟用的功能以及軟體管理流程等變數，理論統計分析將變得困難。

目前，由於難以準確收集這類敏感資料，還沒有完成工業界用現場測量手段更準確地預測軟體可靠性的工作。此外，由於可用性資料的專有性，大多數客戶都不希望思科直接從其網路收集可用性資訊。但是，有些組織確實會收集有關軟體可靠性的資料，思科鼓勵組織收集有關軟體中斷導致的可用性的指標，並對這些中斷執行根本原因分析。具有更高軟體可靠性的組織已採用這種主動式姿態，通過他們可以控制的許多實踐提高軟體可靠性。

軟體可靠性假設

根據客戶反饋、思科IOS技術小組執行的主動式研究和思科高級服務團隊執行的根本原因分析，已形成了有助於提高軟體可靠性的某些較新的假設和最佳實踐。這些假設以測試職責、軟體成熟度或存在時間、啟用的功能以及部署的軟體版本數量為中心。

測試職責

第一個新假設涉及測試責任。思科始終負責測試/驗證新特性和功能，以確保它們在新產品中正常工作。思科還負責回歸測試，以確保新軟體版本向後相容。但是，思科無法針對客戶環境可能帶來的每個潛在警告（設計特性、負載和流量配置檔案）驗證每個功能、拓撲和平台。 適用於客戶的高可用性最佳實踐包括：使用客戶定義的功能、設計、服務和應用流量在模擬生產網路的摺疊式實驗室拓撲中進行測試。

可靠性與軟體成熟度

軟體可靠性主要是一個軟體成熟度的因素。軟體會在收到暴露（使用量）和已識別錯誤被修正後趨於成熟。思科版本操作採用的是培訓版本架構，以確保軟體成熟而不增加新功能。需要高可用性的客戶正在尋找具有他們現在需要的功能的更成熟的軟體。因此，在軟體的成熟度、可用性要求以及新功能或功能的業務驅動因素之間存在著一種折衷。許多組織制定了可接受成熟度的標準或准則。有些人只接受第五輛臨時釋放的火車。對於其他人來說，它可能是第九個GD認證。最終，組織需要決定軟體成熟度方面可接受的風險水準。

可靠性與功能和標準的數量

軟體可靠性也是衡量代碼在生產環境中測試和使用的程度的一個因素。隨著不同硬體平台和模組數量的增加，執行代碼的數量也隨之增加，這通常會增加軟體缺陷的風險。所配置的協定數量、配置的多樣性，甚至所實施的拓撲或設計的多樣性也是如此。設計、配置、協定和硬體模組因素可能導致所執行的代碼量以及軟體缺陷風險或風險增加。

軟體版本操作現在具有特殊用途的軟體，通常限制特定區域中可用的代碼。業務部門推薦的設計和配置在思科內部經過更全面的測試，並被客戶更廣泛地使用。客戶還開始採用標準化模組化拓撲和標準配置的最佳實踐，以降低未經測試的代碼暴露量，並提高整體軟體可靠性。某些高可用性網路具有嚴格的標準配置准則、模組化拓撲標準以及軟體版本控制，可幫助降低未經測試的代碼暴露風險。

可靠性與已部署版本數

軟體可靠性的另一個因素是不同版本之間的互操作性，以及在多個版本中執行的代碼量之大。隨著軟體版本數量的增加，執行代碼的數量也隨之增加，從而增加了軟體缺陷的風險。由於使用多個版本的附加代碼，可靠性風險幾乎呈指數級增長。現在人們認識到，組織確實需要在網路中運行至少幾個版本，以滿足特定功能和平台要求。然而，在一個基本上同構的網路環境中運行超過50個版本通常表明存在軟體問題，因為無法正確分析或驗證這麼多版本。

為了提高軟體可靠性，思科開發部門會執行軟體回歸測試，以確保不同的軟體版本相容。此外，軟體代碼更加模組化，核心模組在不同版本之間隨時間變化不大可能發生顯著變化。思科版本操作還改變了客戶可用的軟體數量，因為發現缺陷後，具有已知缺陷或互操作性問題的版本會迅速從CCO中刪除。

相關資訊

• 思科網際網路作業系統(IOS)
• 技術支援與文件 - Cisco Systems