本文目录1. 记录已安装的配置2. 确定替换类型3. 区分证据类别4. 准备具有代表性的恢复测试5. 定义变更和回滚边界6. 更新已安装和备件库存配套工程示意图

在已安装的 Catalyst 环境中进行有界替换时,请使用此检查清单。这不是建议在新项目中部署所有传统平台。目标是通过有记录的组件匹配和已知的运行期限来恢复定义的服务。

1. 记录已安装的配置

捕获精确的交换机或机箱标识符、主控引擎、线卡、电源、风扇、堆叠附件和软件。记录受影响服务使用的接口和功能。不要假设当前的库存标签反映了模块化系统内的每个组件。

Catalyst 3750-X、6500 和 6800 是不同的系统系列。特定主控引擎或机箱组合的文档必须在其声明的范围内阅读。R26

2. 确定替换类型

请求 需要的验证
相同标识符备件 状况、相关修订版和已安装系统匹配
替代部件 制造商替换证据和任何新依赖关系
具有类似端口的不同模块 完整的兼容性和服务能力审查
完整交换机替换 接口、配置、功能和迁移审查
堆叠或电源附件 精确的主机和附件系统支持

如果替换件改变了支持的介质、电源或软件行为,那么即使端口更多也不一定等效。

3. 区分证据类别

分别记录物理状况、卖家测试、制造商兼容性和支持资格。“翻新”并不自动确立特定的测试流程或权益。“停止销售”和其他生命周期里程碑也需要针对具体产品进行解读。

使用确切产品的生命周期通知来确定日期。通用 Cisco 政策解释了流程,但并未确定未识别部件的剩余支持期。R19

4. 准备具有代表性的恢复测试

确认候选部件能够启动、被识别,并支持服务实际使用的接口和功能。在可行的情况下,在合适的暂存系统上测试配置恢复。通过授权流程保留经过测试的软件映像和相关先决条件。

一个说明性的备件验证应说明该部件在记录的配置下恢复了指定角色。卖家通用的通电声明回答的是一个狭窄得多的问题。

5. 定义变更和回滚边界

保留管理访问和现有配置。确定哪些服务所有者必须批准维护窗口。避免将紧急部件更换与无关的固件、拓扑和策略变更相结合,除非它们是必要的并经过单独验证。

定义如果替换件未被识别、接口无法建立所需模式或关键功能表现不同时会发生什么。记录无法立即恢复先前状态的时间点。

6. 更新已安装和备件库存

验收后,记录新组件的序列号或标识符、配置基线和测试结果。从可服务库存中移除故障项,并保留退货或维修记录。

最终决定应标记为已批准、有条件批准并附明确要求,或未解决。该状态比无条件的兼容性标签更有用,并使传统维护操作与受控的替换策略保持关联。

配套工程示意图

以下配图用于说明本篇设计思路,图中英文术语可结合文末释义阅读;不代表实测结果、认证配置或随货清单。

工程示意图 1 — 传统 Catalyst 替换检查清单:匹配组件并保持服务

工程示意图 2 — 传统 Catalyst 替换检查清单:匹配组件并保持服务

专业术语说明

管理引擎supervisor
模块化交换机中负责控制平面、管理及部分转发的核心引擎模块。在 Catalyst 6500/6800 等机箱中,管理引擎型号决定功能与兼容性,替换时必须精确匹配。
线卡line card
插入模块化交换机机箱、提供网络接口与转发功能的板卡。替换时需确认其与管理引擎、机箱及软件版本的兼容性,不能仅凭端口数量判断等效。
堆叠附件stack accessory
用于将多台交换机通过堆叠端口连接成单一逻辑设备的线缆或模块。替换时需验证与主机及堆叠系统的精确支持关系,避免堆叠失效。
生命周期里程碑lifecycle milestone
产品从发布到停止销售、停止支持等阶段的关键时间点。每个产品的日期需查阅其专属通知,通用政策不能确定未识别部件的剩余支持期。
暂存系统staging system
用于在正式部署前测试配置恢复、软件兼容性和功能行为的非生产环境。在替换验证中,可在此类系统上模拟服务恢复,降低生产风险。
配置基线configuration baseline
经过验证并记录在案的配置状态,作为后续变更和恢复的参考点。替换验收后记录基线,有助于保持服务一致性和可追溯性。

延伸阅读

资料来源

资料核对:

参数、兼容性与操作步骤应结合文中引用资料、完整型号及实际软件版本核对。配图为工程示意。