部署和维护可靠的Cisco IOS®软件是当今业务关键型网络环境中的优先任务,这需要思科和客户重新关注,以实现无间断的可用性。虽然思科必须专注于对软件质量的承诺,但网络设计和支持团队还必须专注于Cisco IOS软件管理的最佳实践。目标是提高可用性和软件管理效率。此方法是共享、学习和实施软件管理最佳实践的组合合作伙伴。
本文档为企业和服务提供商客户提供了Cisco IOS管理实践的有效操作框架,有助于提高软件可靠性、降低网络复杂性和提高网络可用性。此框架还通过确定在思科版本运营和思科客户群之间进行软件管理测试和验证方面的责任和重叠,帮助提高软件管理效率。
下表概述了Cisco IOS最佳实践。这些表可用作已定义最佳实践的管理概述、查看当前Cisco IOS管理实践的差距分析核对表,或用作创建Cisco IOS管理流程的框架。
这些表定义了Cisco IOS管理的四个生命周期组件。每个表都以确定的生命周期区域的策略和工具摘要开头。策略和工具摘要后面是仅适用于定义的生命周期区域的特定最佳实践。
规划 — 构建Cisco IOS管理框架 — 规划是帮助组织确定何时升级软件、何时升级以及将使用什么流程测试和验证潜在映像所需的Cisco IOS管理的初始阶段。
最佳实践 | 详细信息 |
---|---|
思科IOS规划的策略和工具 | 开始使用Cisco IOS管理规划时,首先要对当前实践、可实现目标的制定和项目规划进行诚实的评估。 |
软件版本跟踪定义 | 确定可在何处维护软件一致性。软件路径可以定义为独特的软件版本分组,根据独特的地理位置、平台、模块或功能要求与其他区域不同。 |
升级周期和定义 | 升级周期定义可定义为软件和变更管理中的基本质量步骤,用于确定何时应启动软件升级周期。 |
认证流程 | 认证流程步骤应包括跟踪识别、升级周期定义、候选管理、测试/验证,以及至少一些试生产用途。 |
设计 — IOS版本的选择和验证 — 拥有一个定义明确的选择和验证Cisco IOS版本的流程,可帮助组织减少由于升级尝试失败和计划外软件缺陷而导致的计划外停机时间。
最佳实践 | 详细信息 |
---|---|
思科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目标和流程改进项目。初始会议的目标应是确定总体目标、角色和职责、分配措施项和定义初始项目计划。此外,定义关键成功因素和指标,以确定软件管理优势。潜在指标包括:
可用性(由于软件问题)
软件升级成本
升级所需时间
生产中运行的软件版本数
软件升级更改成功率/失败率
除了整体Cisco IOS管理框架规划外,一些组织还定义了每月或每季度召开的持续软件规划会议。这些会议的目标是审查当前软件部署并开始规划任何新的软件要求。规划可能包括重新访问或修改当前软件管理流程,或只是定义不同软件管理阶段的角色和职责。
规划阶段的工具仅包括软件库存管理工具。CiscoWorks 2000 Resource Manager Essentials(RME)Inventory Manager是此区域使用的主要工具。CiscoWorks2000 RME Inventory Manager通过基于Web的报告工具,根据软件版本、设备平台、内存大小和设备名称报告和排序Cisco IOS设备,极大地简化了Cisco路由器和交换机的版本管理。
第一个Cisco IOS软件管理规划最佳实践确定可在何处维护软件一致性。软件路径被定义为独特的软件版本分组,根据独特的地理位置、平台、模块或功能要求与其他领域不同。最好,网络应只运行一个软件版本。这大大降低了软件管理相关成本,并提供了一致且易于管理的环境。但是,现实情况是,由于特定区域内的功能、平台、迁移和可用性问题,大多数组织必须在网络中运行多个版本。在许多情况下,同一版本在异类平台上不起作用。在其他情况下,组织无法等待一个版本支持其所有要求。目标是确定网络的软件路径最少,同时考虑测试/验证、认证和升级要求。在许多情况下,组织可能会稍微多一些路径,以降低整体测试/验证、认证和升级成本。
第一个与众不同的事实是平台支持。通常,LAN交换机、WAN交换机、核心路由器和边缘路由器都有单独的软件路径。对于特定功能或服务(如数据链路交换(DLSw)、服务质量(QoS)或IP电话),可能需要其他软件路径,尤其是当此要求可在网络内本地化时。
另一个标准是可靠性。许多组织尝试向网络核心和数据中心运行最可靠的软件,同时向边缘提供更新的高级功能或硬件支持。另一方面,在核心或数据中心环境中,通常最需要可扩展性或带宽功能。特定平台可能需要其他路径,例如具有不同WAN路由器平台的较大分布站点。下表是大型企业组织的软件跟踪定义示例。
跟踪 | 区域 | 硬件平台 | 功能 | Cisco IOS version(Cisco IOS 版本) | 认证状态 |
---|---|---|---|---|---|
1 | LAN核心交换 | 6500 | QoS | 12.1E(A8) | 测试 |
2 | LAN接入交换机 | 2924XL 2948XL | 单向链路检测协议(UDLD)、生成树协议(STP) | 12.0(5.2)XU | 认证3/1/01 |
3 | LAN分布/访问 | 5500 6509 | 管理引擎3 | 5.4(4) | 认证7/1/01 |
4 | 分布层交换机路由交换模块(RSM) | RSM | 开放最短路径优先(OSPF)路由 | 12.0(11) | 认证3/4/02 |
5 | WAN头端分布 | 7505 7507 7204 7206 | OSPF帧中继 | 12.0(11) | 认证11/1/01 |
6 | WAN 接入 | 2600 | OSPF帧中继 | 12.1(8) | 认证6/1/01 |
7 | IBM连接 | 3600 | 同步数据链路控制(SDLC)头端 | 11.3(8)T1 | 认证11/1/00 |
跟踪作业也可随时间变化。在许多情况下,功能或硬件支持可能会集成到更多主线软件版本中,从而允许不同的路径最终一起迁移。定义跟踪定义后,组织可以使用其他定义的流程迁移到新版本的一致性和验证。跟踪定义也是一项持续的工作。只要确定新功能、服务、硬件或模块要求,就应考虑新路径。
希望启动跟踪流程的组织应从新定义的跟踪要求开始,在某些情况下,应从现有网络的稳定项目开始。组织可能还与现有软件版本有一些可识别的共同点,这些共同点可使当前跟踪定义成为可能。在大多数情况下,如果客户具有足够的网络稳定性,则不需要快速迁移到已确定的版本。网络架构或工程组通常拥有跟踪定义流程。在某些情况下,可能由一个人负责跟踪定义。在其他情况下,项目主管负责根据个别项目开发软件要求和新的跟踪定义。最好每季度审核跟踪定义,以确定是否需要新跟踪,或旧跟踪是否需要整合或升级。
通过严格版本控制来识别和维护软件跟踪的组织在生产网络中软件版本数量的减少中取得了最高的成功。这通常会提高软件稳定性和整体网络可靠性。
升级周期定义定义为软件和变更管理中的基本质量步骤,用于确定何时应启动软件升级周期。升级周期定义允许组织正确规划软件升级周期并分配所需资源。如果没有升级周期定义,由于当前稳定版本中的功能要求,组织通常会遇到软件可靠性问题增加的情况。另一个风险可能是组织在需要使用生产之前没有机会正确测试和验证新版本。
此实践的一个重要方面是确定软件规划流程应何时启动以及启动到何种程度。这是因为导致软件问题的主要原因是在生产中启用功能、服务或硬件功能而不进行尽职调查,或者升级到新的Cisco IOS版本而不考虑软件管理。另一个问题是不升级。由于忽略了正常的软件周期和要求,许多客户面临着通过许多不同的主要版本升级软件的艰巨任务。困难是由于映像大小、默认行为更改、命令级解释器(CLI)更改和协议更改。
思科建议根据本白皮书中定义的最佳实践,在需要新的主要功能、服务或硬件支持时启动定义明确的升级周期。应分析认证和测试/验证的程度(基于风险),以确定精确的测试/验证要求。风险分析可以按地理位置、逻辑位置(核心层、分布层或接入层)或受影响人员/客户的估计数量进行。如果当前版本中包含主要功能或硬件功能,还应启动一些简化的升级周期流程。如果功能相对较小,请考虑风险,然后决定应启动哪些进程。此外,软件应在两年或更短时间内升级,以帮助确保您的组织保持相对最新,并且升级过程不会太繁琐。
客户还应考虑这样一个事实,即不会对已通过寿命终止(EOL)状态的软件系列执行错误修复。还应考虑业务需求,因为许多环境可以容忍甚至欢迎更多功能添加,而很少或不需要测试/验证过程,并且会导致一些停机。客户在考虑其测试要求时,还应考虑思科版本操作中收集的更新数据。对Bug和根本原因的分析显示,绝大多数Bug根本原因是开发人员在受影响的软件区域内编码的结果。这意味着,如果组织在现有版本中向其网络添加特定功能或模块,则出现与该功能或模块相关的Bug的可能性会大大降低,但新功能、硬件或模块将影响其他区域的可能性会小得多。当添加现有版本中支持的新功能或模块时,此数据应允许组织通过仅测试新服务或功能以及其他启用的服务来降低测试要求。在根据网络中发现的几个关键错误升级软件时,还应考虑数据。
下表显示了对主要高可用性企业组织的建议升级要求:
软件管理触发器 | 软件生命周期要求 |
---|---|
新网络服务。例如,新的ATM主干或新的VPN服务。 | 完整的软件生命周期验证,包括新功能测试(与其他启用的服务一起)、折叠拓扑测试、假设性能分析和应用配置文件测试。 |
当前软件版本不支持新的网络功能。示例包括QoS和多协议标签交换(MPLS)。 | 完成软件生命周期验证,包括新功能测试、折叠拓扑测试、假设性能分析和应用配置文件测试。 |
当前版本中存在的新主要功能或硬件模块。例如,添加新的GigE模块、组播支持或DLSW。 | 候选管理流程。可能根据版本要求进行完整验证。如果候选管理将当前版本确定为可能可接受,则可能有限的测试/验证。 |
次要功能添加。例如,用于访问控制的TACACS设备。 | 根据功能的风险考虑候选管理。考虑根据风险测试或试用新功能。 |
软件生产两年或每季度进行软件审查。 | 与完整生命周期管理相关的候选管理和业务决策,以确定当前可支持的版本。 |
紧急升级
在某些情况下,组织由于灾难性错误而面临升级软件的需求。如果组织没有紧急升级方法,这可能会导致问题。软件问题可能包括非托管软件升级(即软件升级时无需软件生命周期管理),网络设备持续崩溃,但组织未进行升级,因为尚未完成对下一个候选版本的认证/测试。思科建议在网络中业务关键性较低的区域执行有限的测试和试用时,执行紧急升级流程。
如果发生灾难性错误,且没有明显的解决方法,并且问题与软件缺陷相关,思科建议全面参与思科支持,以隔离该缺陷,并确定修复是否可用或何时可用。当修复可用时,思科建议执行紧急升级周期,以快速确定问题是否可以在有限的停机时间内修复。在大多数情况下,组织运行的代码是受支持的版本,而问题修复在现有的较新版本的软件中可用。
组织还可以为潜在的紧急升级做好准备。准备工作包括迁移到受支持的Cisco IOS版本,以及在与认证版本相同的Cisco IOS系列中识别/开发候选替换版本。受支持的软件非常重要,因为它意味着思科开发仍在向确定的软件系列添加漏洞修复。通过在网络中维护受支持的软件,组织由于更熟悉、更稳定的代码库而缩短了验证时间。通常,候选替换是同一Cisco IOS系列中新的临时软件映像,不增加任何功能或硬件支持。如果组织处于特定软件系列的早期采用阶段,则候选替换策略尤为重要。
认证流程有助于确保在组织的生产环境中一致部署经过验证的软件。认证流程步骤应包括跟踪识别、升级周期定义、候选管理、测试/验证以及一些试生产用途。但是,简单的认证流程仍然有助于确保在确定的路径中部署一致的软件版本。
通过从架构、工程/部署和运营中确定人员来拟定和管理认证流程,启动认证流程。该团队应首先考虑业务目标和资源能力,以确保认证过程能够持续取得成功。接下来,指定个人或团队对认证流程中的关键步骤承担总体责任,包括跟踪管理、生命周期升级定义、测试/验证和试用。在组织内,应定义、批准和正式传达这些领域。
还包括认证流程每个阶段的质量或审批指南。这有时称为质量门流程,因为必须满足某些质量标准,该流程才能进入下一步。这有助于确保认证流程有效且值得分配资源。通常,当在一个区域发现质量问题时,该流程会将工作推回一步。
由于软件质量或意外行为,软件候选者可能不符合定义的认证标准。当发现影响环境的问题时,组织应该有一个更简化的流程来验证稍后的临时版本。这有助于减少资源需求,并且通常有效,前提是组织能够了解发生了哪些变化以及哪些缺陷已得到解决。组织遇到初始候选人问题并认证以后的临时Cisco IOS版本并不罕见。如果存在某些问题,组织也可能进行有限的认证或提供警告,并在验证新的临时版本后升级到更高的完全认证版本。下面的流程图是基本的认证流程,包括质量门(每个模块后都有一个审核):
拥有定义明确的方法来选择和验证Cisco IOS版本,可帮助组织减少由于升级尝试失败和计划外软件缺陷而导致的计划外停机时间。
设计阶段包括候选管理和测试/验证。候选管理是用于识别已定义软件路径的特定版本的过程。测试/验证是认证流程的一部分,可确保所识别的软件版本在所需路径内成功。测试/验证应在与生产环境非常相似的折叠拓扑和配置的实验室环境中完成。
每个组织都应具有为网络选择和验证标准Cisco IOS版本的流程,从选择Cisco IOS版本的流程开始。架构、工程和运营部门的跨职能团队应定义并记录候选管理流程。审批后,流程应移交给相应的交付组。还建议创建标准候选管理模板,该模板在识别时可用候选信息进行更新。
并非所有组织都拥有能够轻松模仿生产环境的复杂实验室环境。一些组织跳过实验室测试,因为测试费用高昂,而且能够在网络中试用新版本,而不会对业务产生重大影响。但是,我们鼓励高可用性组织构建模拟生产网络的实验室,并开发测试/验证流程,以确保新Cisco IOS版本的高测试覆盖。组织应该允许大约6个月的时间来构建实验室。在此期间,组织应制定特定的测试计划和流程,以确保实验能发挥全部优势。对于Cisco IOS,这意味着为每个所需软件路径创建特定Cisco IOS测试计划。由于许多实验室因新产品和软件的引入而未使用,因此这些流程在大型组织中非常关键。
以下各节简要介绍用于Cisco IOS选择和验证的候选管理和测试/验证工具。
候选管理工具
注:要使用下面提供的大多数工具,您必须是注册用户且必须登录。
版本说明 — 提供有关版本的硬件、模块和功能支持的信息。应在候选管理期间审核版本说明,以确保潜在版本中存在所有必需的硬件和软件支持,并了解任何迁移问题,包括不同的默认行为或升级要求。
测试和验证工具
测试和验证工具用于测试和验证网络解决方案,包括新硬件、软件和应用。
流量生成器 — 生成多协议流量流和原始数据包速率,用于使用特定协议对任何特定链路上的速率进行建模。用户可以指定源、目标MAC和套接字编号。这些值可以按指定步骤递增,也可以配置为静态/固定或随机递增。流量生成器可以为以下协议生成数据包:
IP
互联网分组交换 (IPX)
DECnet
苹果
Xerox网络系统(XNS)
Internet Control Message Protocol (ICMP)
互联网组管理协议(IGMP)
无连接网络服务(CLNS)
用户数据报协议 (UDP)
虚拟集成网络服务(VINES)
数据链路数据包
数据包计数器/捕获/解码器(嗅探器) — 允许客户选择性地捕获和解码所有数据包和数据链路层的数据包。该工具允许用户指定过滤器,从而仅允许捕获指定的协议数据。过滤器还允许用户指定捕获与特定IP地址、端口号或MAC地址匹配的数据包。Sniffer Technologies提供工具 。
Network Simulator/Emulator — 允许客户根据生产网络要求填充特定路由器的路由表。支持生成IP路由信息协议(RIP)、OSPF、中间系统到中间系统(IS-IS)、内部网关路由协议(IGRP)、增强型IGRP(EIGRP)和边界网关协议(BGP)路由器。PacketStorm Communications和Spirent Communications提供了工具。
会话仿真器 — 生成滑动窗口多协议流量流,并能够通过测试网络向接收设备发送多协议流量流。接收设备将数据包回传到源设备。源设备验证发送、接收、顺序错误数据包和错误数据包的数量。该工具还可以灵活地定义传输控制协议(TCP)中的窗口参数,从而密切模拟实验网络中的客户端/服务器流量会话。工具可从Empirix获得 。
大规模网络仿真器 — 帮助测试大型环境的可扩展性。这些工具能够创建并轻松地将控制类型的流量注入实验室拓扑中,以便更接近地模拟生产环境。功能包括路由注入器、协议邻居和第2层协议邻居。Agilent和Spirent Communications提供的 工具可用 。
WAN模拟器 — 非常适合测试带宽和延迟可能存在问题的企业应用流量。这些工具允许组织在本地测试具有估计延迟和带宽的应用,以查看应用如何通过广域网运行。这些工具通常用于企业组织内的应用程序开发和应用程序分析测试类型。Adtech是Spirent Communications和Shunra的一个部门 ,提供广 域网模拟工具。
候选管理是确定特定硬件和已启用功能集的软件版本要求和潜在风险的过程。建议组织在试运行版本之前花费四至八个小时来适当研究软件要求、版本说明、软件缺陷和潜在风险。以下概述了候选人管理的基础:
通过思科在线连接(CCO)工具确定软件候选者。
风险分析软件成熟度、新功能或代码支持。
在整个生命周期中识别并跟踪已知软件错误、问题和要求。
确定所选映像的默认配置行为。
为潜在候选人变更保留后退和前推候选人。
擦虫。
思科高级服务支持。
随着思科产品和软件系列的不断增多,确定软件候选者变得更加复杂。CCO现在有多种工具,包括Cisco IOS升级规划器、软件搜索工具、软件 — 硬件兼容性矩阵和产品升级工具,可帮助组织确定潜在的版本候选者。这些工具可在http://www.cisco.com/cisco/software/navigator.html找到。
然后,分析潜在候选软件的风险。这是了解软件当前驻留在成熟度曲线上的位置,然后将部署要求与发布候选产品的潜在风险进行权衡的过程。例如,如果组织希望将早期部署(ED)软件置于关键的高可用性环境中,则应考虑成功认证的相关风险和资源要求。组织应至少为高风险情况添加软件管理资源,以确保成功。另一方面,如果提供满足组织需求的通用部署(GD)版本,则需要的软件管理资源会更少。
当发现潜在版本和风险时,请执行漏洞清理,以确定是否存在任何已发现的可能阻止认证的灾难性漏洞。思科的Bug Watcher、Bug Navigator和Bug Watcher代理可帮助识别潜在问题,并应在整个软件生命周期中用于识别潜在的安全或缺陷问题。
还应检查新软件候选者是否存在潜在的默认配置行为。这可以通过查看新软件映像的版本说明以及查看与指定平台上加载的潜在映像的配置差异来实现。如果所选版本在流程的某个阶段不符合认证标准,则候选管理还可包括对退出版本或转到版本的标识。通过查看与指定路径的功能相关的漏洞,组织可以维护潜在的认证候选者。
思科高级服务也是候选管理的绝佳工具。此团队可以进一步了解开发流程以及许多行业专家在许多不同垂直市场环境中的协作。通常,思科支持中存在最佳的漏洞清除或候选管理功能,这是因为具备其他组织运行的生产软件版本所需的专业知识和可视性。
总体而言,测试和验证是管理最佳实践和高可用性网络的关键方面。正确的实验室测试可以显着减少生产停机时间,帮助培训网络支持人员,并帮助简化网络实施流程。但是,为了有效运行,组织必须分配必要的资源来构建和维护适当的实验室环境,应用必要的资源来执行正确的测试,并使用建议的测试方法(包括测量收集)。如果没有这些方面,测试和验证流程可能无法满足组织的期望。
大多数企业组织没有推荐的测试实验室环境。因此,许多组织部署的解决方案不正确,遇到过网络更改故障,或遇到过可能在实验室环境中隔离的软件问题。在某些环境中,这是可以接受的,因为停机成本无法抵消复杂实验环境的成本。但是,在许多组织中,不能容忍停机。强烈要求这些组织开发推荐的测试实验室、测试类型和测试方法,以提高生产网络质量。
测试实验和环境
实验室应是一个隔离区,有足够的空间容纳桌子、工作台、测试设备以及设备柜或机架。大多数大型组织需要四至十机架的设备来模拟生产环境。建议使用一些物理安全功能来帮助在测试过程中维护测试环境。这有助于防止因硬件借用、培训或实施演练等其他实验优先事项而中断实验测试。还建议使用逻辑安全来防止伪造路由进入生产网络或不需要的流量从实验室流出。这可以通过实验网关路由器上的路由过滤器和扩展访问列表来完成。连接到生产网络有助于软件下载和从生产环境访问实验室网络。
实验拓扑应能模拟生产环境中任何特定测试计划。建议重现硬件、网络拓扑和功能配置。当然,复制实际拓扑几乎是不可能的,但可以做的是复制网络层次结构以及生产设备之间的交互。这对于多个设备之间的协议或功能交互非常重要。根据软件测试要求,某些测试拓扑会有所不同。例如,广域网边缘Cisco IOS测试不应要求LAN类型的设备或测试,并且可能只需要广域网边缘路由器和广域网分布路由器。关键是模仿软件功能,而不复制生产。在某些情况下,工具甚至可用于模拟大规模行为,如协议邻居计数和路由表。
还需要工具来通过提高模拟生产环境和收集测试数据的能力来帮助处理某些测试类型。帮助模拟生产的工具包括流量收集器、流量生成器和广域网模拟设备。Smartbits是收集和重放网络流量或生成大量流量的设备的一个很好的示例。组织还可以从有助于收集数据的设备(如协议分析器)中获益。
本实验还需要一些管理。许多大型组织都有专职实验室经理,负责管理实验室网络。其他组织利用现有架构和工程团队进行实验室验证。实验室管理职责包括订购实验室设备和资产跟踪、布线、物理空间管理、定义实验规则和方向、实验安排、实验文档、设置实验拓扑、编写测试计划、执行实验室测试以及管理已发现的潜在问题。
测试类型
总的来说,可以执行多种不同类型的测试。在构建可以测试多种配置的所有测试的完整测试实验室和测试计划之前,组织应了解不同类型的测试、测试意图,以及思科工程、技术营销或客户宣传是否应该或可能负责某些测试。客户测试计划通常涵盖暴露性更强的测试类型。下表有助于了解不同的测试类型、应何时执行测试以及相关方。
在以下测试中,正确测试组织的特定功能集、拓扑和应用组合通常是最有价值的。了解思科执行完整功能和回归测试非常重要,但思科无法通过您的特定拓扑、硬件和配置功能组合来测试您组织的应用配置文件。事实上,测试全部功能、硬件、模块和拓扑排列是不可行的。此外,思科无法测试与第三方设备的互操作性。思科建议组织测试其环境中硬件、模块、功能和拓扑的精确组合。此测试应在实验室中进行,其折叠的拓扑表示您组织的生产环境,并包含其他支持测试类型,如性能、互操作性、中断和老化。
测试 | 测试概述 | 测试责任 |
---|---|---|
功能 | 确定基本Cisco IOS功能和Cisco硬件模块是否如通告那样运行。应测试功能或模块功能以及功能配置选项。应测试配置删除和添加。包括基本故障测试和老化测试。 | 思科设备测试 |
回归 | 确定功能或模块是否与其他模块和功能一起运行,以及Cisco IOS版本是否与其他Cisco IOS版本一起运行,与定义的功能有关。包括一些老化和故障测试。 | 思科回归测试 |
基本设备性能 | 确定功能或模块的基本性能,以确定Cisco IOS功能或硬件模块是否满足负载下的最低要求。 | 思科设备测试 |
拓扑/功能/硬件组合 | 确定特定拓扑和模块/功能/硬件组合中的功能和模块是否按预期运行。此测试应包括协议验证、功能验证、show命令验证、老化测试和故障测试。 | 思科在实验(如企业解决方案工程(ESE)和网络解决方案集成测试工程(NSITE))中测试标准通告拓扑。 高可用性客户应根据需要测试功能/模块/拓扑组合,尤其是使用早期采用的软件和非标准拓扑。 |
故障(假设) | 包括特定功能/模块/拓扑环境中可能发生的常见故障类型或行为以及潜在的功能影响。故障测试包括卡交换、链路抖动、设备故障、链路故障和卡故障。 | 思科负责基本故障测试。客户最终要对与其单个环境的可扩展性相关的停机性能问题负责。如果可能,应在客户实验室环境中进行故障测试。 |
网络性能(假设) | 调查与特定功能/硬件/拓扑组合相关的设备负载。重点关注设备容量和性能,如CPU、内存、缓冲区利用率和链路利用率,它们与所设置的流量类型和协议、邻居、路由数和其他功能的资源要求有关。该测试有助于确保在更大环境中的可扩展性。 | 客户最终要负责设备负载和可扩展性。负载和可扩展性问题通常由思科销售或高级服务提出,并且通常通过客户概念验证实验室(CPOC)等思科实验室进行测试。 |
错误修复 | 确保漏洞修复修复已识别的缺陷。 | 思科测试Bug修复以确保Bug已修复。客户还应进行测试,以确保他们遇到的Bug已得到修复,并且Bug不会中断模块或功能的任何其他方面。维护版本经过回归测试,但过渡版本通常不会。 |
网络管理 | 调查简单网络管理协议(SNMP)管理功能、SNMP MIB变量准确性、陷阱支持和系统日志支持。 | 思科负责测试基本SNMP功能和MIB变量准确性。客户应验证网络管理结果,并最终负责新技术部署的管理策略和方法。 |
大规模网络仿真 | 大规模网络仿真使用Agilent的路由器模拟器和Spirent的测试工具套件等工具来模拟更大的环境。这可能包括协议邻居、帧中继永久虚电路(PVC)计数、路由表大小、缓存条目以及生产中通常需要的其他资源(默认情况下不在实验室)。 | 思科客户通常负责复制其网络环境的网络模拟测试方面,其中可能包括路由协议邻居/邻接关系的数量以及相关路由表大小和生产中的其他资源。 |
互操作性 | 测试与第三方网络设备连接的所有方面,尤其是在需要协议或信令互操作性时。 | 思科客户通常负责互操作性测试的所有方面。 |
烧入 | 随着时间的推移调查路由器资源。老化测试通常要求设备在一段时间内承受一定负载,并对资源利用率(包括内存、CPU和缓冲区)进行调查。 | 思科执行基本的老化测试。建议对独特的拓扑、设备和功能组合进行客户测试。 |
测试方法
一旦组织知道他们在测试什么,就应制定测试流程的方法。最佳实践测试方法的目的是帮助确保商定的测试是全面的、记录详实的、易于复制的,并且在发现潜在生产问题方面很有价值。记录和重新创建实验场景对于测试更高版本或测试实验室环境中发现的漏洞修复尤为重要。测试方法的步骤如下所示。也可以同时执行一些测试步骤。
创建模拟所测试生产环境的测试拓扑。WAN边缘测试环境可能只包括几个核心路由器和一个边缘路由器,而LAN测试可能包括更多最能代表环境的设备。
配置模拟生产环境的功能。实验设备的配置应与预期的生产设备硬件和软件配置紧密匹配。
编写测试计划、定义测试和目标、记录拓扑并定义功能测试。测试包括基本协议验证、show命令验证、中断测试和老化测试。下表列出了测试计划中特定测试的示例。
验证路由和协议功能。记录或基线预期的show命令结果。协议应包括第2层协议(如ATM、帧中继、思科发现协议(CDP)、以太网和生成树)以及第3层协议(如IP、IPX和组播)。
验证功能。记录或基线预期的show命令结果。功能可能包括全局配置命令和任何关键功能,如身份验证、授权和记帐(AAA)。
模拟负载,在生产环境中是预期的。负载模拟可以使用流量收集器/发电器完成。通过调查任何丢包情况,验证预期网络设备利用率变量,包括CPU、内存、缓冲区利用率和接口统计信息。记录或基线预期的show命令结果。
在设备和软件预计会处理或防止负载不足时执行故障测试。例如,卡删除、链路抖动、路由抖动和广播风暴。确保根据网络中使用的功能生成正确的SNMP陷阱。
记录测试结果和设备测量,因为测试应可重复。
测试名称 | 热备份路由器协议(HSRP)故障转移 |
---|---|
测试配置要求 | 将负载应用于主网关接口。从用户站角度来看,流量大约应为通往网关的20%,而从用户站角度来看应为传入流量的60%。此外,将流量增加到更高的负载。 |
测试步骤 | 通过show命令监控STP和HSRP。主网关接口连接失败,然后在收集信息后恢复连接。 |
预期测量 | 故障切换期间的CPU。显示主网关和辅助网关的接口在前、中和后。显示HSRP的前、中和后。 |
预期结果 | 主网关在两秒内故障切换到另一路由器网关。show命令正确反映更改。恢复连接时,会故障切换到主网关。 |
实际结果 | |
通过或失败 | |
通过所需修改 |
设备测量
在测试阶段,执行并记录以下测量,以确保设备正常运行:
内存使用情况
CPU负载
缓冲区使用
接口统计资料
路由表
特定调试
测量信息根据所实施的特定测试而不同。此外,还可能有其他信息,根据正在解决的具体问题进行衡量。
对于每个正在测试的应用程序,测量参数以确保对给定的应用程序没有不利的性能影响。通过使用可用于比较部署前后性能的性能基线来完成此操作。应用测量测试的示例包括:
登录网络所需的平均时间。
网络文件系统(NFS)复制一组文件所花的平均时间。
启动应用并在第一个屏幕提示时所用的平均时间。
其他特定于应用的参数。
定义明确的实施过程使组织能够高效地部署新的Cisco IOS版本。
实施阶段包括试点过程和实施过程。试运行过程可确保Cisco IOS版本在环境中成功,实施过程允许快速成功地进行大规模Cisco IOS部署。
Cisco IOS部署的策略是通过试用流程和使用升级工具和明确定义的实施流程快速部署来执行最终认证。
在启动网络试运行过程之前,许多组织会制定一般的试运行指南。试点指南应包括对所有试点的期望,如成功标准、可接受的试点位置、试点文档、试点所有者期望、用户通知要求和预期试点持续时间。来自工程、实施和运营的跨职能团队通常参与构建整体试点指南和试点流程。试运行流程创建后,各个实施小组通常可以使用确定的最佳实践方法进行成功的试运行。
一旦新软件版本获批用于部署和最终认证,组织需要开始规划Cisco IOS升级。规划从确定新映像要求开始,包括平台、内存、闪存和配置。架构和工程组通常在Cisco IOS管理生命周期的候选管理阶段定义新的软件映像要求。确定需求后,必须由实施组验证并可能升级每台设备。CiscoWorks2000软件映像管理器(SWIM)模块还可以通过根据设备资产验证Cisco IOS要求来执行验证步骤。当所有设备都经过验证或升级到正确的新映像标准后,实施组可以开始使用CiscoWorks2000 SWIM模块作为软件部署工具的缓慢启动实施过程。
新映像成功部署多次后,组织可以使用CiscoWorks SWIM开始快速部署。
思科IOS资产管理
CiscoWorks2000 Resource Manager Essentials(RME)Inventory管理器通过基于Web的报告工具,根据软件版本、设备平台和设备名称报告和排序Cisco IOS设备,大大简化了思科路由器和交换机的版本管理。
思科IOS SWIM
CiscoWorks2000 SWIM可帮助降低升级过程中容易出错的复杂性。CCO的内置链接将思科在线软件补丁信息与网络中部署的思科IOS和Catalyst软件相关联,并突出显示相关技术说明。新的规划工具可查找系统要求,并在需要硬件升级(Boot ROM、Flash RAM)以支持建议的软件映像更新时发送通知。
在启动更新之前,将根据目标交换机或路由器的资产数据验证新映像的必备条件,以帮助确保成功升级。当更新多个设备时,SWIM会同步下载任务并允许用户监控作业进度。计划的作业通过签名流程进行控制,使经理能够在启动每个升级任务之前授权技术人员的活动。RME 3.3能够分析Cisco IGX、BPX和MGX平台的软件升级,从而大大简化并减少确定软件升级影响所需的时间。
为了最大限度地减少潜在风险并更安全地捕获任何剩余的生产问题,建议进行软件试运行。试用通常对新技术部署更为重要,但许多新软件部署将与新服务、功能或硬件相关联,其中试用更为关键。个人试点计划应当考虑试点选择、试点持续时间和测量。试运行选择是确定何时何地应进行试运行的过程。试点测量是收集所需数据以识别成功和失败或潜在问题的过程。
试点选择可确定试点的完成位置和完成方式。导频可以从低冲击区中的一个设备开始,并扩展到高冲击区中的多个设备。试点选择的一些考虑因素(可以减少影响)包括:
安装在网络区域,因冗余而对单台设备产生影响。
在网络区域中,所选设备后面的用户数量最少,能够处理某些可能的生产影响。
请考虑沿架构线分隔试点。例如,在网络的接入层、分布层和/或核心层进行试用。
此试运行的持续时间应基于充分测试和评估所有设备功能所需的时间。这应包括老化和正常流量负载下的网络。持续时间还取决于代码升级步骤和Cisco IOS运行的网络区域。如果Cisco IOS是新的主版本,则首选更长的试运行期。但是,如果升级是维护版本,新功能很少,则缩短试运行期就足够了。
在试运行阶段,监控和记录结果的方式与初始测试类似,这一点非常重要。这包括用户调查、试点数据收集、问题收集和成功/失败标准。个人应直接负责跟踪和监控试点进度,以确保发现所有问题,并确保试点涉及的用户和服务对试点结果感到满意。如果某个版本在试运行或生产环境中成功,大多数组织将对其进行认证。此步骤是某些环境中的关键失败,因为在未确定或记录任何衡量或成功标准时,您会感到成功。
在生产网络中完成试运行阶段后,开始Cisco IOS实施阶段。实施阶段包括确保软件升级成功和实施效率的几个步骤,包括实施缓慢启动、最终认证、升级准备、升级自动化和最终验证。
实施缓慢启动是缓慢实施新测试版本以确保映像在最终认证和完全规模转换之前完全暴露在生产环境中的过程。有些组织可能从一台设备开始并在一天内进行暴露,然后在第二天升级到两台设备,可能在第二天再升级几台。当大约10台设备投入生产时,组织可能需要等待一至两周时间才能最终认证特定Cisco IOS版本。最终认证后,组织可以更快速地部署已确定的版本,并获得更高的置信度。
启动缓慢后,应使用设备清单和引导程序、DRAM和闪存的最低Cisco IOS标准矩阵来检查和验证确定要升级的所有设备,以确保满足要求。数据可通过内部工具、第三方SNMP工具或CiscoWorks2000 RME获取。CiscoWorks2000 SWIM在实施前会检查或检查这些变量。但是,了解实施尝试期间的预期始终是一个好主意。
如果计划升级的类似设备超过一百台,强烈建议使用自动化方法。已经证明,自动化可提高升级效率,并提高在大型部署中设备升级成功的百分比,其基础是对1000台设备进行内部升级,无论SWIM是否有SWIM。由于升级期间执行的验证程度,思科建议将CiscoWorks 2000 SWIM用于大型部署。如果检测到问题,SWIM甚至会从Cisco IOS版本中恢复。SWIM通过创建和安排升级作业来运行,其中作业配置了设备、所需的升级映像和作业的运行时间。每个作业应包含12个或更少的设备升级,并且最多可以同时运行12个作业。SWIM还验证计划的Cisco IOS升级版本在升级后是否成功运行。建议每次设备升级(包括验证)大约需要20分钟。 使用此公式,组织每小时可以升级36台设备。思科还建议每晚最多升级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输出解释程序是帮助快速诊断Cisco IOS软件崩溃的工具。
第三种策略是持续改进。主要流程是改进基于质量的可用性改进计划。通过对所有问题(包括Cisco IOS相关问题)执行根本原因分析,组织可以改善测试覆盖、缩短问题解决时间,并改进消除或减少中断影响的流程。组织还可以查看常见问题并构建流程以更快地解决这些问题。
用于Cisco IOS操作的工具包括软件版本控制(CiscoWorks2000 RME)的库存管理、用于管理系统日志消息的系统日志管理,以及用于管理设备配置一致性的设备配置管理器。
系统日志管理
系统日志消息是设备发送到收集服务器的消息。这些消息可能是错误(例如,链路断开),也可能是信息性消息,例如当有人进入设备配置终端时。
系统日志管理工具记录并跟踪路由器和交换机接收的系统日志消息。某些工具具有过滤器,可以删除可能会删除重要邮件的有害邮件。系统日志工具还应允许根据收到的消息创建报告。报告可按时间段、设备、消息类型或消息优先级显示。
Cisco IOS管理中最常用的系统日志工具是CiscoWorks2000 RME系统日志管理器。还提供其他工具,包括SL4NT、Netal的共享软件程序和 OpenSystems的Private I。
CiscoWorks设备配置管理器
CiscoWorks2000设备配置管理器维护活动存档,并提供更新多个思科路由器和交换机配置更改的简单方法。配置管理器监控网络的配置更改,在检测到更改时更新存档,并将更改信息记录到更改审核服务。通过基于Web的用户界面,您可以搜索归档文件以查找特定配置属性,并比较两个配置文件的内容,以便于识别差异。
思科输出解释程序
思科输出解释程序是用于诊断软件强制崩溃的工具。该工具可帮助识别软件缺陷,而无需致电思科技术支持中心(TAC),也可在软件强制崩溃后将其用作TAC的主要信息。这些信息通常有助于加快问题的解决,至少在所需信息收集方面是如此。
软件版本控制是仅实施标准化软件版本并监控网络以验证或可能更改软件的过程,因为软件版本不合规。一般来说,软件版本控制是使用认证过程和标准控制完成的。许多组织在中央Web服务器上发布版本标准。此外,实施人员还接受过培训,以检查运行的版本,并在版本不符合标准时更新版本。有些组织有质量门流程,通过审核完成二级验证,以确保在实施过程中遵循标准。
在运行期间,在网络中看到非标准版本的情况并不罕见,尤其是当网络和操作人员庞大时。这可能是由于未接受培训的新员工、配置错误的引导命令或未经检查的实施。使用CiscoWorks 2000 RME等工具定期验证软件版本标准始终是一个好主意,这些工具可以按Cisco IOS版本对所有设备进行排序。当确定非标准时,应立即标记它们,并启动故障单或更改单,以将版本提交到已确定的标准。
系统日志收集、监控和分析是建议的故障管理流程,用于解决更多Cisco IOS特定网络问题,这些问题很难或无法通过其他方式识别。系统日志收集、监控和分析有助于在出现或用户报告更严重的网络问题之前,主动识别并解决许多故障,从而缩短问题解决时间。与针对大量MIB变量的一致SNMP轮询相比,Syslog还提供了收集各种问题的更有效方法。系统日志收集、监控和分析通过使用正确的Cisco IOS配置、系统日志关联工具(如CiscoWorks2000 RME)和/或系统日志事件管理来完成。系统日志事件管理通过解析收集的系统日志数据以识别关键消息,然后将警报或陷阱转发到事件管理器以进行实时通知和解决来完成。
系统日志监控需要NMS工具支持或脚本来帮助分析和报告系统日志数据。这包括按日期或时间段、设备、系统日志消息类型或消息频率对系统日志消息进行排序的功能。在大型网络中,可以实施工具或脚本来解析系统日志数据并向事件管理系统或操作和工程人员发送警报或通知。如果不使用各种系统日志数据的警报,组织应至少每天查看优先级更高的系统日志数据,并为潜在问题创建故障单。为了主动检测可能无法通过正常监控发现的网络问题,应定期检查和分析历史系统日志数据,以检测可能不表示立即问题,但可能在问题变为服务影响之前提供问题指示的情况。
许多客户因缺乏问题管理流程而经历额外的停机时间。如果网络管理员尝试使用影响服务的命令或配置更改的组合来快速解决问题,而不是花时间识别问题、收集信息和分析得当的解决方案路径,则可能会出现额外的停机时间。在此区域观察到的行为包括重新加载设备,或在调查问题及其根本原因之前清除IP路由表。在某些情况下,这是由于第一级支持问题解决目标。所有软件相关问题的目标应是在恢复连接或服务之前快速收集根本原因分析所需的必要信息。
建议在较大的环境中使用问题管理流程。在升级到第二层之前,此过程应包含一定程度的默认问题描述和相应的show命令集合。第一层支持不应清除路由或重新加载设备。最好,第一级组织应快速收集信息并上报到第二级。最初只需花几分钟时间在问题识别或问题描述上,就更有可能发现根本原因,从而提供解决方法、实验室识别和漏洞报告。二级支持应深入了解思科诊断问题或提交Bug报告时可能需要的信息类型。这包括内存转储、路由信息输出和设备show命令输出。
全局设备配置标准代表在类似设备和服务中维护标准全局配置参数,从而实现企业范围全局配置一致性的实践。全局配置命令是适用于整个设备的命令,而不适用于单个端口、协议或接口。全局配置命令通常会影响设备访问、一般设备行为和设备安全。在Cisco IOS中,这包括服务命令、IP命令、vty命令、控制台端口命令、日志记录命令、AAA/TACACS+命令、SNMP命令和标语命令。在全局设备配置标准中,同样重要的是适当的设备命名约定,允许管理员根据设备的域名系统(DNS)名称识别设备、设备类型和设备位置。全局配置一致性对于网络环境的整体支持性和可靠性非常重要,因为它有助于降低网络复杂性并增强网络支持性。由于设备行为不正确或不一致、SNMP访问和一般设备安全,在未进行配置标准化时,通常会遇到支持困难。
维护全局设备配置标准通常由为类似网络设备创建和维护全局配置参数的内部工程或运营组完成。在TFTP目录中提供全局配置文件的副本也是一种良好的做法,这样可以将全局配置文件初始下载到所有新调配的设备。此外,还有一个可通过Web访问的文件,该文件为标准配置文件提供了每个配置参数的说明。有些组织甚至定期全局配置类似设备,以帮助确保全局配置一致性或定期检查设备是否符合正确的全局配置标准。协议和接口配置标准代表维护接口和协议配置标准的实践。
协议和接口配置一致性通过降低网络复杂性、提供预期的设备和协议行为以及提高网络支持性来提高网络可用性。协议或接口配置不一致可能导致意外的设备行为、流量路由问题、连接问题增加以及反应式支持时间增加。接口配置标准应包括CDP接口描述符、缓存配置和其他协议特定标准。协议特定配置标准可能包括:
IP路由配置
DLSW配置
访问列表配置
ATM配置
帧中继配置
生成树配置
VLAN分配和配置
虚拟中继协议(VTP)
HSRP
注意:根据网络中配置的内容,可能有其他协议特定配置标准。
IP标准的示例可能包括:
子网大小
使用的IP地址空间
使用的路由协议
路由协议配置
维护协议和接口配置标准通常是网络工程和实施组的责任。工程组应负责标准的识别、测试、验证和记录。然后,实施组负责使用工程文档或配置模板来调配新服务。工程组应创建有关所需标准所有方面的文档,以确保一致性。还应创建配置模板,以帮助实施配置标准。运营团队还应接受标准培训,并能够识别非标准配置问题。配置一致性在测试、验证和认证阶段非常有帮助。事实上,如果没有标准化的配置模板,对于中等规模的网络,要充分测试、验证或验证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是整合技术版本的示例。
特定技术早期部署(STED)版本— STED版本具有与CTED版本类似的功能承诺特征,只是它们针对特定技术或市场大区。它们始终在特定平台上发布,并仅在思科业务部的监督下发布。STED版本使用附加到主版本的两个字母进行标识。STED版本的示例包括Cisco IOS 11.3NA、11.3MA、11.3WA和12.0DA。
特定市场早期部署(SMED)版本 - Cisco IOS SMED与STED不同,原因在于它们针对的是特定垂直市场细分(ISP、企业、金融机构、Telcom公司等)。SMED仅包括特定技术功能要求,适用于目标垂直市场所利用的特定相关平台。它们与反恐执行局的区别在于它们只针对与垂直市场相关的特定平台而构建,而反恐执行局将根据更广泛的技术要求为更多平台而构建。Cisco IOS SMED版本由附加到主版本(与CTED一样)的字母字符标识。 SMED的示例包括Cisco IOS 12.0S和12.1E。
短期早期部署版本,也称为X版本(XED)- Cisco IOS XED版本向市场引入新硬件和技术。它们不提供软件维护修订,也不提供定期软件临时修订。如果在XED与CTED收敛之前在XED中发现缺陷,则启动软件重建并在名称后附加一个数字。例如,Cisco IOS版本12.0(2)XB1和12.0(2)XB2是12.0(2)XB重建的示例。
主要版本
主要版本是Cisco IOS软件产品的主要部署工具。它们由思科IOS技术部管理,并整合了以前ED版本中的特性、平台、功能、技术和主机激增。Cisco IOS主要版本希望获得更高的稳定性和质量。因此,主要版本不接受添加功能或平台。每个维护修订版仅提供漏洞修复。例如,Cisco IOS软件版本12.1和12.2是主要版本。
主要版本已安排维护更新,称为维护版本,经过完全回归测试,包含最新的漏洞修复,并且不支持新平台或功能。主版本的版本号标识主版本及其维护级别。在思科IOS软件版本12.0(7)中,12.0是主版本的编号,7是其维护级别。完整版本号为12.0(7)。 同样,12.1是主要版本,12.1(3)是主要Cisco 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版本仍可从Cisco Connection Online(CCO)下载,用于维护升级。
工程结束(EOE) - EOE版本是GD版本的最后一个维护版本,通常在EOS版本后三个月左右。客户可以继续从思科TAC获得技术支持,并从CCO下载EOE版本。宣布EOS和EOE版本及日期的产品公告在计划EOS日期前一年发布。此时,客户应开始调查升级其Cisco IOS软件以利用最新的网络技术。
寿命终止(EOL) — 在版本生命周期结束时,Cisco IOS软件版本的所有支持将终止,在EOL日期不再可供下载。通常,EOL日期为EOE日期后五年。EOL产品公告在实际EOL日期前大约一年发布。
Cisco IOS映像命名约定提供所有已发布映像的完整配置文件。名称始终包括主版本标识符和维护版本标识符。该名称还可以包括列车指示符、重建指示符(用于维护版本)、业务单元(BU)特定功能指示符和BU特定功能指示符重建标识符。格式可按如下方式细分:
命名约定部分 | 解释 |
---|---|
x.y | 由“。”分隔的两个单独(一个或两个)数字标识符的组合 标识主版本值。此值由Cisco IOS营销决定。示例:12.1 |
z | 1到3位,用于标识x.y的维护版本。每八周发生一次。测试版为0,FCS为1,第一个维护版本为2。示例:12.1(2) |
p | 一个字母字符,用于标识x.y(z)的重建。 值以小写“a”开头,对于第一次重建,然后是“b”,依此类推。示例:12.1(2a) |
A | 1至3个字母是版本系列的标志符,对于CTED、STED和X版本是必填字母。它还标识了一系列产品或平台。技术ED版本使用两个字母。第一个字母代表技术,第二个字母用于区分。例如: 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)版本名称第一位置的“X”根据CTED“T”系列标识一次性版本。例如,XA、XB、XC等。版本名称第二个位置的“X”或“Y”根据STED版本或与其关联标识短期ED版本。例如,11.3NX(基于11.3NA)、11.3WX(基于11.3WA)等。 |
o | 可选的一位或两位数字指示符,用于标识特定版本值的重建。如果不表示重建,请留空。从1开始,然后是2,依此类推。示例:12.1(2)T1、12.1(2)XE2 |
u | 标识BU特定版本功能的一位或两位数字指示符。价值由业务部营销团队确定。示例:11.3(6)WA4、12.0(1)W5 |
v | 标识BU特定代码维护版本的一至两位数字指示符。测试版为0,FCS为1,第一个维护版本为2。示例:11.3(6)WA4(9)、12.0(1)W5(6) |
p | 一个字母字符标志,用于标识特定技术版本的重建。值以小写“a”开头,首次重建时使用小写“a”,然后使用“b”,依此类推。示例:11.3(6)WA4(9a)是11.3(6)WA4(9)的重建。 |
下图标记了Cisco IOS命名约定的不同部分:
Cisco IOS可靠性是思科不断努力改进的领域。在讨论以客户为导向的最佳实践之前,需要对思科内部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软件版本都有执行和跨职能的承诺。
在思科内,软件可靠性质量工作的一个重要部分是测试的质量、范围和覆盖范围。总的来说,思科有以下IOS质量目标:
减少发现的思科内部回归缺陷。这包括在静态/动态分析中开发和识别更多问题的质量。
减少客户发现的缺陷
减少未解决的全部缺陷
提高软件版本清晰度和功能一致性
提供功能和维护版本,提供计划和质量
思科内部测试可视为在测试的不同阶段识别不同缺陷的过程。总体目标是在正确的实验室中找到正确的缺陷类型。这很重要,原因有几。第一个也是最重要的一点是,在后续测试阶段可能不存在足够的测试覆盖。测试成本也从各个阶段大幅增加,因为能够在早期阶段实现自动化,并且以后需要的复杂性和专业知识不断增加。下图描述了Cisco IOS的测试频谱。
第一阶段是软件开发。思科在此领域做了多项努力,以帮助提高初始软件质量。开发组还执行代码审核甚至多个代码审核,以确保其他开发人员批准软件更改或新功能代码。
下一阶段是单元测试。单元测试使用的工具可检查软件交互,无需使用实验室。DevTest是实验室测试,包括特性/功能测试和回归测试。功能/功能测试旨在检查给定功能的功能。这包括配置、取消配置和测试功能规范中定义的所有功能排列。回归测试是在自动测试设施中完成的,该测试设施旨在持续验证功能和行为。测试主要侧重于使用ping和有限流量生成的多种不同网络拓扑中的路由、交换和功能。由于可能的排列数量极多,回归测试只能在功能、平台、软件版本和拓扑的有限组合上完成,但目前使用了4000多个回归测试脚本。集成测试旨在扩展实验室测试功能,以获得更全面的产品套件和互操作性。集成测试还通过扩展测试来增加测试代码的覆盖范围,包括互操作性测试、压力和性能测试、系统测试和负面测试(测试意外事件)。
下一实验阶段为常见客户环境提供端到端测试。上图显示为财务测试实验室(FTL)和NSITE、客户场景测试。FTL旨在为任务关键型金融社区提供测试。NSITE是一组为不同Cisco IOS技术提供更深入测试的组。NSITE和FTL实验室专注于可扩展性和性能测试、可升级性、可用性和恢复能力、互操作性和可维护性等领域。可维护性侧重于批量调配问题、事件管理/关联和负载下的故障排除。思科内部针对不同垂直市场提供其他实验室,以帮助测试这些领域。
上图所示的最终实验确定为客户实验。客户测试是质量工作的延伸,建议用于高可用性环境,以确保功能、配置、平台、模块和拓扑的准确组合已经过全面测试。测试覆盖范围应包括已识别拓扑中的网络可扩展性和性能、特定应用测试、已识别配置中的负测试、非思科设备的互操作性测试以及老化测试。
整体可靠性最常见的指标之一是平均无故障时间(MTBF)。软件可靠性的MTBF之所以有用,是因为使用MTBF为硬件可靠性开发了分析功能。使用一些现有标准可以更准确地确定硬件可靠性。思科使用基于Telcordia Technologies标准MTBF数据的部件计数方法。但是,MTBF软件没有相应的分析方法,必须依靠现场测量来进行MTBF分析。
过去三年,思科对思科内部IT网络执行了软件可靠性现场测量,此工作在思科内部进行记录。此工作基于Cisco IOS设备的软件强制崩溃,可使用网络管理SNMP陷阱信息和正常运行时间信息来衡量。该研究使用统计对数正态分布模型识别所识别的软件版本的软件可靠性。软件故障的平均修复时间(MTTR)基于平均路由器重启和恢复时间。企业环境使用6分钟的恢复时间,大型互联网服务提供商(ISP)使用15分钟的恢复时间。 本持续研究的结果是,软件发布时或在几个维护版本之后通常满足良好的90%可用性,并且随着时间的推移会更高,使用软件强制崩溃作为唯一的停机时间来源进行测量。该研究确定,早期部署软件的潜在MTBF值在5,000小时到一般部署软件的50,000小时之间。
对此工作最常见的反驳是,软件强制崩溃并不包括由于软件可靠性问题而导致的所有停机时间。如果在质量改进工作中使用此指标,则可能有助于提高软件强制崩溃的速率,但可能忽略软件可靠性的其他关键领域。此评论在很大程度上仍未得到答复,因为很难用统计方法准确预测软件可靠性。思科软件质量统计人员得出结论,使用范围更广的故障类型可靠地预测软件MTBF需要更大的样本集准确数据。此外,由于网络复杂性、员工解决软件相关问题的专业知识、网络设计、启用的功能和软件管理流程等变量,理论统计分析将很困难。
目前,由于难以准确采集此类敏感数据,尚未完成行业工作,以现场测量更准确地预测软件可靠性。此外,由于可用性数据的专有性质,大多数客户不希望思科直接从其网络收集可用性信息。但是,有些组织确实会收集软件可靠性数据,思科鼓励组织收集有关软件故障导致的可用性的指标,并对这些故障执行根本原因分析。软件可靠性较高的组织已利用这种主动姿态通过他们可以控制的许多实践来提高软件可靠性。
由于客户反馈、Cisco IOS技术组进行的主动研究和Cisco高级服务团队执行的根本原因分析,已形成一些有助于提高软件可靠性的较新的假设和最佳实践。这些假设的核心是测试责任、软件成熟度或年龄、启用的功能和部署的软件版本数。
测试责任
第一个新假设涉及测试责任。思科始终负责测试/验证新特性和功能,以确保它们能够在新产品中运行。思科还负责回归测试,以确保新软件版本向后兼容。但是,思科无法根据客户环境可能引起的每个潜在警告(设计特性、负载和流量量变曲线)验证每个功能、拓扑和平台。 客户的高可用性最佳实践包括在折叠的实验室拓扑中进行测试,该拓扑使用客户定义的功能、设计、服务和应用流量模拟生产网络。
可靠性与软件成熟度
软件可靠性主要是软件成熟度的一个因素。软件在收到暴露(使用)并纠正已识别的错误时会逐渐成熟。思科版本操作已进入系列版本架构,以确保软件在不添加新功能的情况下成熟。需要高可用性的客户正在寻找具有他们现在所需功能的更成熟软件。然后,在软件成熟度、可用性要求和新特性或功能的业务驱动因素之间进行权衡。许多组织都有标准或准则,以便达到可接受的成熟度。一些人只会接受第五次临时放车。对于其他人,可以是第九个或GD认证。最终,组织需要根据软件成熟度确定其可接受的风险级别。
可靠性与功能和标准的数量
软件可靠性也是在生产环境中测试和执行代码数量的一个因素。随着不同硬件平台和模块数量的增加,代码执行量也随之增加,这通常会增加软件缺陷的暴露。对于所配置的协议数量、配置的多样性,甚至实施的拓扑或设计的多样性,也是如此。设计、配置、协议和硬件模块因素可能导致代码的使用量和软件缺陷的风险或风险增加。
软件版本操作现在有特殊用途软件,通常限制代码在一个特定区域可用。业务部门具有推荐的设计和配置,这些设计和配置在思科内经过更彻底的测试,并且被客户更广泛地利用。客户还开始采用标准化模块化拓扑和标准配置的最佳实践,以降低未经测试的代码暴露量,并提高整体软件可靠性。一些高可用性网络具有严格的标准配置指南、模块化拓扑标准和软件版本控制,以帮助降低未经测试的代码暴露风险。
可靠性与已部署版本数
软件可靠性的另一个因素是版本之间的互操作性以及与多个版本一起使用的大量代码。随着软件版本数量的增加,执行的代码数量也会增加,从而增加软件缺陷的暴露。由于使用多个版本执行了额外代码,可靠性风险几乎呈指数级增长。现在,人们认识到组织确实需要在网络中运行至少几个版本,以满足特定功能和平台要求。但是,在大多数同构网络环境中运行超过50个版本通常表示由于无法正确分析或验证这许多版本而导致软件问题。
为提高软件可靠性,思科开发部门执行软件回归测试,以确保不同软件版本兼容。此外,软件代码更加模块化,而且核心模块在不同版本之间随时间推移发生显着变化的可能性更小。思科版本操作还改变了客户可用软件的数量,因为在发现缺陷时,具有已知缺陷或互操作性问题的版本会快速从CCO中删除。