📚 课程目录第3章 NX-OS命令行与配置管理基础

3. NX-OS命令行与配置管理基础

NX-OS 的配置管理能力并不只是“敲命令、保存配置”这么简单。它把配置的修改、验证、提交、对比、回退和长期归档组织成一条可追溯的链路。理解这条链路，是后续用 NX-API、Ansible、Python 做自动化配置的前提——因为自动化工具最终调用的，仍然是这些底层机制。

配置会话：先改后提交，而不是边改边生效

NX-OS 默认的配置模式是“即时生效”：在 configure terminal 下输入的命令会立刻作用于运行配置（running-config）。这在手工排障时很方便，但在批量变更时风险很高——一旦某条命令写错，设备可能已经进入不可预期的状态。

配置会话（Configuration Session）解决的就是这个问题。它创建一个独立的候选配置（candidate config），所有修改先写入候选区，只有执行 commit 才真正合并到运行配置。典型流程如下：

switch# configure session VLAN_ADD
switch(config-s)# vlan 120
switch(config-s-vlan)# name PROD_APP
switch(config-s-vlan)# exit
switch(config-s)# interface Ethernet1/1
switch(config-s-if)# switchport mode trunk
switch(config-s-if)# switchport trunk allowed vlan add 120
switch(config-s)# verify
switch(config-s)# commit
switch(config-s)# end
switch# show configuration session VLAN_ADD

关键点有三个：verify 会在提交前做语法与部分语义校验，能提前发现接口不存在、VLAN 未创建等问题；commit 是原子性的，要么整体生效，要么整体不生效；会话可以命名并保留，便于多人协作时区分变更意图。若中途放弃，用 abort 丢弃候选配置即可，运行配置不受影响。

配置会话适合“一次变更涉及多个接口、多个 VLAN、多条 ACL”的场景。单条命令的修改用会话反而增加步骤，不必强求。

检查点与回滚：给配置拍快照

检查点（Checkpoint）是 NX-OS 的配置快照机制。执行 checkpoint 会把当前运行配置完整保存为一个命名快照，之后无论配置被改成什么样，都可以用 rollback 回到该快照。

switch# checkpoint create BEFORE_UPGRADE
switch# show checkpoint summary
switch# rollback running-config checkpoint BEFORE_UPGRADE

检查点与配置会话的区别在于：会话是“变更前先隔离”，检查点是“变更前先留底”。两者可以配合使用——先建检查点，再用会话做变更，提交后如果发现业务异常，直接回滚到检查点。回滚会覆盖运行配置，因此执行前应确认当前是否有其他未保存的变更，避免误伤。

配置差异对比：看清改了什么

变更前后到底差在哪，是配置管理中最容易被忽略、却最影响判断的一环。NX-OS 提供 show diff 系列命令，用于比较运行配置与检查点、启动配置或另一个检查点之间的差异。

switch# show diff rollback-patch checkpoint BEFORE_UPGRADE running-config
switch# show diff rollback-patch running-config startup-config

输出以 + 表示新增行、- 表示删除行，按配置层级展开。实际使用中，建议在提交会话前先看一次 diff，确认没有多余命令被带入；回滚前也看一次 diff，确认回滚范围符合预期。对于自动化流水线，diff 输出可以作为变更审批的附件，让审批人看到“这次到底改了什么”，而不是只看一句“已提交”。

归档与恢复：把配置放到设备之外

检查点保存在设备本地，设备故障或误删时无法自救。配置归档（Configuration Archive）把运行配置或启动配置复制到远程服务器，形成带时间戳的历史版本。常用方式是 FTP、TFTP、SCP 或 SFTP。

switch# copy running-config scp://admin@10.10.10.20/archive/leaf01_20240612.cfg
switch# show archive status
switch# show archive log config all

恢复时把归档文件复制回设备并合并：

switch# copy scp://admin@10.10.10.20/archive/leaf01_20240612.cfg running-config

需要注意，copy ... running-config 是合并而非替换，归档中已删除的命令不会自动从当前配置中移除。若要做“完全还原”，应结合检查点回滚，或先清空相关配置段再合并。

定时备份策略：让归档自动发生

手工备份迟早会漏。NX-OS 支持用调度器（Scheduler）定时执行配置归档，把“备份”变成设备自身的例行任务。

switch# feature scheduler
switch# scheduler job BACKUP_CFG
switch(config-job)# copy running-config scp://admin@10.10.10.20/archive/leaf01_$(TIMESTAMP).cfg
switch(config-job)# end
switch# scheduler schedule DAILY_BACKUP
switch(config-schedule)# job name BACKUP_CFG
switch(config-schedule)# time start now repeat 24:00
switch(config-schedule)# end

策略设计上建议区分三个层次：变更前手动建检查点，保证可快速回滚；每日定时归档到远程服务器，保证有历史版本；重大变更（如版本升级、大规模 VLAN 调整）前额外做一次带标签的归档。归档文件命名带设备名与时间戳，便于在服务器侧按设备、按日期检索。

把机制串成可执行的变更习惯

这五项能力不是并列的功能清单，而是一条有先后顺序的操作链。一次规范的配置变更，通常按下面的顺序展开：

变更前执行 checkpoint create <标签>，标签写明变更内容与日期，例如 CHG20240612_VLAN120。
进入配置会话，完成所有修改，执行 verify 检查语法与依赖。
用 show configuration session <名称> 或 diff 确认候选配置内容符合预期。
执行 commit 提交，随后用 show diff rollback-patch checkpoint <标签> running-config 复核实际生效的差异。
业务验证通过后，触发一次归档；若验证失败，执行 rollback running-config checkpoint <标签> 回到变更前状态。

定时备份则作为兜底：即使某次变更没有手工归档，每日调度任务也会把运行配置推到远程服务器。归档服务器上建议按 设备名/日期/文件名 组织目录，文件名包含设备名与时间戳，例如 leaf01_20240612_0200.cfg，这样在需要恢复时能快速定位到某个时间点的版本。

回滚和恢复都会改写运行配置。执行前先确认当前配置是否已被他人修改、是否有未提交的会话，避免把别人的变更一起覆盖掉。生产环境中，回滚操作同样应记录变更单。

掌握这些机制后，再看 NX-API 或 Ansible 的 nxos_config 模块，会发现它们本质上是在程序化地调用同一套能力：候选配置对应会话，backup: yes 对应归档，diff_against 对应差异对比。命令行阶段把这些机制用熟，自动化阶段才不会只是“把命令搬到脚本里”。