2. Catalyst配置体系与运行机制

在 Catalyst 交换机上，“配置”并不是一个单一文件，而是由运行态、启动态和文件系统共同构成的一套体系。理解这套体系，是后续做配置基线、变更审计和回滚设计的前提。很多现场问题——例如“改了配置重启后丢失”“copy run start 报错”“flash 空间不足导致镜像无法升级”——本质上都是对配置存储结构和加载流程理解不清造成的。

一、IOS 与 IOS-XE 的配置存储结构

传统 Catalyst（如 2960、3560、3750 系列）运行的是经典 IOS，其配置存储相对简单：运行配置保存在内存（RAM）中，启动配置保存在 NVRAM 中，系统镜像和部分文件保存在 flash 中。IOS-XE 则不同，它本质上是基于 Linux 的模块化系统，配置管理由 IOSd 进程承担，运行配置同样在内存中，但启动配置的落盘位置、文件系统命名和持久化机制更接近“文件系统 + 数据库”的混合模型。Catalyst 9000 系列（如 C9200、C9300）运行 IOS-XE，常见文件系统包括 flash:、bootflash:、nvram:（部分平台仍保留）以及 usbflash0:。

需要特别注意的是：在 IOS-XE 平台上，startup-config 通常位于 bootflash:/nvram/startup-config 或类似路径，而不是传统 IOS 的 NVRAM 芯片。执行 show file systems 可以看到各文件系统的类型、总容量、可用空间和权限标志。理解“哪个文件系统是可写的、哪个是只读的、哪个用于启动”，对配置备份和镜像管理至关重要。

二、running-config 与 startup-config 的关系

running-config 是设备当前生效的配置，存在于内存中，任何 configure terminal 下的修改都立即作用于 running-config，并即时影响转发行为。startup-config 是设备下次启动时加载的配置，存在于非易失存储中。两者之间不是自动同步关系：修改 running-config 不会自动写入 startup-config，必须显式执行保存动作。

这种“运行态与启动态分离”的设计带来两个直接后果：第一，未保存的变更在断电或重启后会丢失；第二，可以在不改变启动配置的前提下做临时调试，重启即恢复。对于变更治理而言，这意味着每一次变更都必须明确回答两个问题：当前 running-config 与 startup-config 的差异是什么？这次变更是否需要持久化？

Switch# show running-config | include hostname
hostname C9300-LAB
Switch# show startup-config | include hostname
hostname C9300-LAB

Switch# configure terminal
Switch(config)# hostname C9300-TEMP
Switch(config)# end
Switch# show running-config | include hostname
hostname C9300-TEMP
Switch# show startup-config | include hostname
hostname C9300-LAB

上面的示例说明：修改主机名后，running-config 立即变为 C9300-TEMP，但 startup-config 仍是 C9300-LAB。此时若重启，设备会回到 C9300-LAB。只有执行 write memory 或 copy running-config startup-config 后，两者才一致。

三、配置加载与保存流程

设备上电后的配置加载顺序大致为：Bootloader 加载系统镜像 → IOS/IOS-XE 初始化 → 查找 startup-config → 逐行解析并应用到 running-config → 进入用户执行模式。如果 startup-config 不存在或损坏，设备会进入 Setup 模式或使用出厂默认配置。IOS-XE 平台还可能涉及 bootflash:/nvram/ 下的配置文件校验和版本管理。

保存流程则是反向的：running-config 被序列化为文本 → 写入目标文件系统 → 更新 startup-config 指针。保存时如果 flash 或 bootflash 空间不足，会直接报错，配置不会写入。因此在大规模变更前，建议先检查文件系统可用空间，并保留一份带时间戳的备份。

四、NVRAM 与 flash 文件系统的分工

在经典 IOS 中，NVRAM 专门用于保存 startup-config 和部分启动参数，容量很小（通常几十到几百 KB），读写次数有限。flash 用于保存系统镜像、部分配置文件、许可证和日志。在 IOS-XE 中，NVRAM 的角色被弱化，startup-config 更多以文件形式存放在 bootflash 的 nvram 目录中，flash/bootflash 成为配置持久化的主要载体。

这种变化带来的实践影响是：备份配置时不能只盯着 NVRAM，而应把 bootflash 中的 startup-config 文件、镜像文件和许可证文件一起纳入备份范围。对于 Catalyst 9000，推荐使用 copy startup-config bootflash:backup-YYYYMMDD.cfg 或通过 TFTP/SCP 外传，形成可追溯的配置基线。

五、变更治理中的关键检查点

把上述机制落到变更治理上，可以形成几个必须固化的检查点。第一，变更前记录基线：执行 show running-config 并外传备份，同时记录 show version 中的镜像版本和 show file systems 的可用空间。第二，变更中控制范围：明确本次修改涉及哪些配置段，避免误改管理面或 AAA 相关配置导致失联。第三，变更后验证并持久化：先确认 running-config 行为符合预期，再执行保存，最后对比 startup-config 与 running-config 是否一致。

对于 IOS-XE 平台，还可以利用 archive 功能实现配置自动归档和回滚。配置 archive path bootflash:archive 并设置 time-period 后，系统会按周期或按 write memory 触发归档，保留多个历史版本。这在出现配置错误时，可以通过 configure replace bootflash:archive/xxx.cfg 快速回退，而不必逐行手工撤销。

六、一个可复用的配置基线检查清单