华为CE交换机配置误删或错误后如何快速回滚

在华为CE交换机的日常割接或业务配置过程中，操作方案不完善或现场人员经验不足很容易造成配置误删、配置错误，直接影响现网业务。如果此时没有清晰可执行的回退方案，现场临场恢复往往越忙越乱。CE交换机内置的配置回滚机制可以把运行配置快速恢复到指定时间节点，是运维人员必须掌握的保命技能。本文基于华为官方案例库，演示如何用 commit-id 机制把配置一键回退到操作前的状态，并补充回滚失败的常见原因、按时间点回滚与割接前后标准动作清单。

CE 交换机配置提交与回滚原理

CE 系列交换机采用类似 Junos 的配置提交（commit）模型：每次 commit 都会生成一个递增的 Commit ID，系统保留历史提交记录。只要确认了出问题前的 Commit ID，就可以把运行配置整体回退到该节点，无需手动一条条撤销命令。

理解这套机制需要抓住四个要点。第一，只有在系统视图下执行过 commit 的配置才会进入回滚历史，未提交的候选配置（candidate configuration）不会产生 Commit ID。第二，回滚动作本身也是一次提交，它不会"删除历史"，而是在历史链条尾部追加一个新的提交节点，因此回滚之后 Commit ID 继续向前递增。第三，回滚是全局行为，影响的是整个运行配置，而不是单条命令或单个接口。第四，设备保存的提交历史条数受版本与规格限制，超出后最早的记录会被覆盖，所以不能把回滚当成长期配置归档来用。

<HUAWEI> display configuration commit list
------------------------------------------------------------------
Seq  CommitId            Label       User       TimeStamp
------------------------------------------------------------------
1    1000000104                      huawei     2024-01-11 09:12:33
2    1000000106          baseline    huawei     2024-01-11 14:05:10
3    1000000108          ospf-add    huawei     2024-01-11 15:22:41

为什么需要回滚：三类典型误操作场景

现场绝大多数配置事故都可以归入以下三类，而这三类场景恰恰都能用回滚机制快速兜底。

• 误删配置：执行 undo 时打错命令或选错接口范围，例如本想删除某个临时 VLAN，结果整段 interface 配置被清空，随后 commit 生效，业务立即中断。
• 旧配置覆盖新配置：把几周前导出的离线配置脚本整段粘贴到设备上，旧参数覆盖了期间的优化项，表现是部分业务"悄悄"回退，但设备不报任何告警。
• 脚本批量下发错误：自动化平台或 Python 脚本一次性下发上百条命令，其中一条参数错误（例如 ACL 方向写反），整批配置一起提交，问题范围极难手工定位。

三类场景的共同点是：错误配置已经 commit 生效，手工逐条纠正既慢又容易漏。此时最快的路径就是先回滚、再重新规划变更。

回滚机制关键命令速查

把下面这组命令记进巡检卡片，出现问题时可以按顺序执行，不必现场翻文档。

display configuration commit list                 // 查看历史提交列表与 Commit ID
display configuration commit changes              // 查看全部提交的变更明细
display configuration commit changes last 3       // 只看最近 3 次提交改了什么
display configuration commit changes commit-id 1000000106
rollback configuration to commit-id 1000000106    // 回滚到指定提交
rollback configuration to time 2024-01-11 14:05:10  // 按时间点回滚
rollback configuration last 1                     // 回滚最近一次提交

第一步：确认错误配置的 Commit ID

执行 display configuration commit changes 查看各次提交的变更内容，找到"最后一次正确配置"对应的提交节点：

<ShenZhen-DC1-Core-CE12816> display configuration commit changes
Commit changes of commitId 1000000108
#  + ospf 100 router-id 1.1.1.1
   + area 0.0.0.0
   + network 114.172.12.2 0.0.0.0
#
Commit changes of commitId 1000000106  //假设从本次commit后的操作都是要恢复的
#
- sysname HUAWEI
+ sysname ShenZhen-DC1-Core-CE12816

回溯时抓住一个简单规则：正向看每一段差异，找到"错误命令第一次出现"的那次提交，回滚目标就是它前一次的 Commit ID。如果变更内容很多，可以配合 display configuration commit changes last N 逐段比对，避免看错行。

第二步：回滚到指定 Commit ID

<ShenZhen-DC1-Core-CE12816> rollback configuration to commit-id 1000000106
Warning: This operation will revert configuration changes to the previous status. Continue? [Y/N]:y
Loading rollback changes
Committing
Check rollback result
Configuration rollback succeeded.

选择 y 之后设备会进入 Loading / Committing / Check 三个阶段，正常情况下终端会打印 Configuration rollback succeeded.。如果卡在 Committing 阶段超过一分钟，不要直接断电，先观察控制台是否有板卡上电或配置锁相关提示。

第三步：验证回滚结果

用 display configuration commit changes last 1 检查本次恢复删除了哪些命令，确认配置已回到操作前状态：

<ShenZhen-DC1-Core-CE12816> display configuration commit changes last 1
- interface LoopBack0        //"-"表示在本次恢复过程中删除的命令
  - ip address 1.1.1.1 255.255.255.255
- ospf 100 router-id 1.1.1.1
  - area 0.0.0.0
  - network 114.172.12.2 0.0.0.0

除了比对差异，还应当从业务侧验证：检查关键接口 display interface brief 是否为 Up、OSPF/BGP 邻居是否重新建立、VLAN 与路由表是否符合预期。配置一致不等于业务恢复，两者都要确认。

快捷方式：回退最近一次提交

如果误操作就是通过最近一次 commit 生效的，可以直接回退一步，不必先查 Commit ID：

<ShenZhen-DC1-Core-CE12816> rollback configuration last 1

last 1 表示回退最近一次提交，last 2 表示连续回退最近两次提交。这个写法在现场最省时间，但前提是你能确信问题只由最近一次提交引入。

按时间点回滚

有时现场记不住 Commit ID，只记得"大概是今天下午两点半左右还是好的"。CE 支持直接按时间戳回滚，设备会自动匹配该时间点之前最近的一次提交：

<ShenZhen-DC1-Core-CE12816> rollback configuration to time 2024-01-11 14:05:10
Warning: This operation will revert configuration changes to the previous status. Continue? [Y/N]:y
Configuration rollback succeeded.

时间格式必须完整到秒，并且要与设备本地时钟一致。如果设备时间不准（例如没配 NTP），按时间点回滚极容易选错节点，所以建议在生产设备上统一开启 NTP 同步。

回滚失败或不生效的常见原因

• 目标提交点之后存在物理配置：回滚只处理配置文件层面的差异，如果期间有板卡插拔、接口模块更换，回滚不会"恢复硬件"，差异仍会存在于运行状态中。
• 选错了 Commit ID：把"错误命令产生的那次提交"当成目标点，结果回滚后问题依旧，此时应回滚到它前一次提交。
• 回滚后又被人为改回：多人在线操作时，另一名工程师在你回滚后又执行了一次编辑与提交，覆盖回了错误状态。回滚前务必确认无人同时操作设备。
• 权限或视图不对：rollback 属于系统级操作，需要在具备管理权限的账号下执行，权限不足时会直接拒绝。
• 双主控同步未完成：主备主控板配置尚未同步时执行回滚，可能出现主备配置短时间不一致，建议确认主备状态正常后再操作。
• 历史已被覆盖：提交记录条数超出规格，目标 Commit ID 已不在历史列表中，此时只能退回配置文件恢复路径。

割接前后标准动作清单

回滚能力只有在"有基线可回"的前提下才有价值，因此割接流程中必须固化以下动作。

变更实施前：

• 执行 display configuration commit list，把当前最新 Commit ID 抄录进割接单，作为回滚目标。
• 执行 save 保存当前配置，并额外导出一份配置文件到本地或 TFTP/FTP 服务器。
• 记录关键业务状态基线：接口 Up/Down 列表、路由/邻居数量、VLAN 与链路聚合状态。

<HUAWEI> display configuration commit list
<HUAWEI> save
The current configuration will be written to the device.
Are you sure to continue? [Y/N]:y
<HUAWEI> display interface brief | include up
<HUAWEI> display ospf peer brief

变更实施后：

• 核对业务验证项是否全部通过，而不是只看设备是否还在线。
• 执行一次 commit 固化配置，让正确状态成为新的回滚基线。
• 再次 save，并记录新的 Commit ID 与本次变更说明。

常见问题 FAQ

Q1：回滚会不会导致接口 up/down 翻转？回滚会按差异重建配置，涉及接口的参数会被删除或重新下发，因此可能出现短暂的接口状态变化。生产窗口内操作，并提前评估影响范围。

Q2：能回滚到昨天的配置吗？只有当昨天的提交记录仍在设备保留的历史中才可行。历史条数有限，长期归档仍然要依赖配置文件备份。

Q3：回滚之后还需要 save 吗？需要。回滚修改的是运行配置，若不保存，设备重启后仍会按启动配置文件引导，回滚结果会丢失。

运维建议

• 割接前先执行 display configuration commit changes 记录当前基线 Commit ID。
• 回滚属于全局操作，执行前务必确认影响面，建议在维护窗口内进行。
• 回滚后立即验证业务，并补一次新的 commit 固化正确配置。
• 为设备配置 NTP 同步，让"按时间点回滚"真正可用。
• 把 Commit ID 抄录进割接单，而不是只写"操作前状态良好"。

更多华为设备运维技巧可参考 华为交换机配置宝典 和 华为路由器交换机常用命令与排障大全，配置文件备份与启动文件管理的完整流程见 华为交换机启动配置文件管理，SNMP 网管不通的排查见 华为CE交换机SNMP排障。

原文链接：https://support.huawei.com/enterprise/zh/knowledge/EKB1000294444