企业官网建设流程全解析

1. 一次逃不掉的深夜重启：配置“人间蒸发”的现场

我先讲一个自己带新人时碰到的真实案例。

有次客户核心交换机需要协调窗口重启，白天刚做完一批 VLAN、路由和 ACL 配置，小兄弟拍着胸脯说“配置肯定保存了，放心重启”。结果设备起来以后，业务网段全部 ping 不通，登录设备一看，running-config 空空如也，连管理 VLAN 都没有了，整个人当场傻眼。后来查下来，他确实是敲了配置，也确实“以为”自己保存了，但现场的情况远比一句“没保存”复杂得多。

这个事在网工新手群里太常见了。配完设备重启丢配置，前前后后我见过的相关求助没有几百也有几十次，而且绝大多数情况都可以归结到两个关键配置上：一是配置根本没写入启动配置文件，二是设备启动时压根没打算加载你保存的那份配置。后者尤其隐蔽，因为操作者明明执行了保存命令，show 的时候也看到配置文件里有一段内容，可一重启照样回到解放前。

这篇文章就是冲着这两个坑来的。全程不讲虚的，把运行配置、启动配置、启动加载指向这几个概念掰开揉碎，再给一套可以照着做的排查方法和防呆习惯。适合刚入行的网络工程师，也适合那些在 H3C、华为、思科、锐捷设备之间来回切换、被各家命令差异搞晕的运维朋友。

2. 先搞懂设备配置的“草稿纸”和“印刷成品”

想搞清楚为什么重启会丢配置，先得明白设备到底把配置存在什么地方。新手最容易犯的认知错误，是把“配置生效”和“配置保存”画等号，其实这是两个完全不同的动作，底层对应的是两份完全不同的文件。

2.1 running-config：你以为搞定的一切，其实只是草稿

你敲入的每一条命令，生效之后会进入设备的运行配置，也就是 running-config。思科系里叫 running-config，华为/华三里叫 current-configuration。这份配置放在设备的内存（RAM）里，CPU 直接读取它来决定转发行为、接口状态、路由表等等。

问题就出在这：RAM 是易失性存储，一断电、一重启，里面所有东西全部清空。你可以把 running-config 理解成你在 Word 里打了半天文档，但一直没点“另存为”。看着屏幕上全是字，其实那些内容只存在于当前进程里，关掉程序就没了。设备重启等于强制关闭这个进程。

很多新手在工程现场改了配置，看到命令回显正常、业务也通了，就认为万事大吉。这种状态下设备的“草稿纸”上确实写得满满当当，但那只是临时的。只要没执行保存命令，任何一次意外断电、计划重启、甚至双主控设备的主备倒换，都能让这份草稿直接作废。

2.2 startup-config：设备开机时真正会去读的东西

真正能扛住重启的，是启动配置文件，也就是 startup-config，华为/华三叫 saved-configuration。这份文件存放在非易失性介质里，思科传统交换机大多放 NVRAM，华为/H3C/锐捷一般放 flash 或者 CF 卡上。设备上电启动时，引导程序会在指定路径找启动配置文件，把它读入内存，加载成新的 running-config。

所以正常流程是：你敲配置 → 配置进入 running-config → 执行保存命令 → running-config 被复制成 startup-config。这两份配置在保存完成的那一刻是一致的，之后你如果再改任何命令，它们又会产生差异，直到你再次保存。

这里有一个天然的设计意图容易被忽略：running-config 和 startup-config 不一致，在某种意义上是正常状态。设备的运行配置就是可以在内存里随便改，改完先观察效果，稳定之后再决定要不要保存。很多老网工就是利用这个差异做变更的，改坏了直接 reboot 就能回到变更前状态。但对新手来说，这个灵活性也带来一个副作用——忘了保存，重启就丢。

2.3 主流厂商保存命令对照表

不同厂商的保存命令不一样，但思路完全一致。我在这里列一份常用对照，建议直接截图存手机里。

注意，这里只是通用版本。不同型号、不同软件版本，命令细节可能有出入，但是“查看运行配置、查看启动配置、保存、查看启动加载指向”这四个动作是每一台真机上都存在的，只是名字有差异。你只要把这四个动作在设备上找到，就不会被厂商命令带走节奏。

3. 第一个配置错误：配完根本没执行“保存”动作

文章标题说的第一个配置错误，就是这个。90% 的重启丢配置事故，本质上是保存动作没做。这句话说出来挺扎心的，但真相往往就是那么简单。

3.1 为什么新手总把“配置生效”等同于“配置保存”

“我明明配了，命令也执行成功了，怎么重启就没了？”这话我听了不下二十遍。

根源在于很多新手对设备的工作方式没有建立模型。配置命令敲下去，设备立刻按新配置工作，这个即时反馈会给人造成一种“事情已经完成”的心理暗示。尤其当你在配置模式下敲完最后一条命令，看到接口状态变成 up，看到路由出现在路由表里，那种满足感很容易让人脑补出“配置已经牢牢焊死在设备里”的错觉。

但实际上，你敲完命令只是改动了内存里的运行配置，设备没有任何机制告诉你“嘿兄弟，你还没保存”。有些设备在退出配置模式的时候会给一条警示，比如某些思科交换机会提示配置未被保存，但大部分设备在重启前什么都不说。结果到了重启那一刻，一切归零。

我在带人的时候常说一句话：配置生效是给设备看的，配置保存是给设备下一次开机看的，两件事之间差着一个“write”。

3.2 保存前必看的三个状态

在动手敲保存命令之前，先花十秒钟做三件事，成本极低，收益极高。

第一，退出配置模式。不要在配置模式下直接敲保存命令，虽然有些设备允许这么做，但容易造成上下文混乱，而且部分平台的保存命令在普通用户模式下执行更稳妥。按 Ctrl+Z 或者输入 end，回到特权模式或用户视图。

第二，确认运行配置是你想要的最终版本。在保存前快速浏览一遍 running-config 或者 current-configuration，重点看有没有临时的调试配置、多余的测试 ACL、错误的接口 shutdown 等。很多人改完配置直接保存，结果把调试期的一堆临时命令也一起存进去了，后面出问题都不知道是哪条命令惹的祸。

第三，确认设备时钟。听起来无关紧要，但配置文件的保存时间戳在后期排障时非常有用。我见过某台设备上出了问题，查 startup-config 才发现保存时间是半年前的，说明这半年所有改动都没落盘。团队协作时，配置文件里能看到最近一次保存时间，能少吵很多架。

3.3 保存后如何确认不是白干一场

保存命令敲下去，回显出现“OK”或者“successfully”，大部分人就觉得完事了。严格来说还不够，应该再反向验证一次。

验证动作很简单，就是查看启动配置文件的内容或大小。在思科/锐捷上执行 show startup-config，和 running-config 对比一下关键配置是否一致；在华为/华三上执行 display saved-configuration，或者用 display startup 看启动配置文件的文件大小和最后修改时间。如果启动配置文件是 0 字节，或者内容缺了一大截，说明保存有问题，得查文件系统空间是不是满了、flash 是不是只读、文件名是不是没写对。

还有一个我踩过无数次的坑：多台设备轮着配置的时候，配置保存漏了一台。有时候是五六台设备批量改配置，每台都敲了相同的命令，结果最后保存的时候只保存了当前连接的那一台，其他几台全被漏掉。所以批量操作时，每台设备保存完，立刻把这台设备的名字、特权模式提示符、保存时间记录到一个文本里，形成闭环。

4. 第二个配置错误：设备启动时根本没打算加载你的配置

如果你已经确认配置保存成功了，startup-config 里也能看到内容，但重新启动后 running-config 依然恢复出厂，那就进入第二个配置错误的排查范畴了。这个坑比第一个隐蔽得多，因为它不再是“没保存”，而是“设备启动时加载的行为被改掉了”。

4.1 “保存到正确位置”和“加载正确位置”是两回事

设备开机的过程有自己的逻辑链，大体上是：硬件初始化 → 引导程序启动 → 加载系统软件 → 读取启动配置 → 形成 running-config。其中“读取启动配置”这一步，设备不是盲目的，它需要知道自己应该从哪个文件、以什么方式去读。

问题就出在这个“知道”上。很多设备允许管理员指定启动配置文件的路径和文件名，也可以设置一些特殊的启动标志。一旦这些参数被改动，或者保存的文件名和启动参数指向的文件名不一致，设备就会进入“找不到配置文件”或“忽略配置文件”的状态，直接以出厂默认配置启动。

这就像你明明把行李放在了 A 寄存柜，但出发时系统告诉司机去 B 寄存柜取。行李好好的，取货单指向错了，结果还是两手空空。

4.2 华为/H3C 的 startup-config 指向问题

在华为和 H3C 设备上，最典型的坑是启动配置文件参数为空，或者保存文件名与启动文件名不匹配。

先看启动配置指向，在设备上执行：

<Huawei> display startup MainBoard: Startup saved-configuration file: cfcard:/vrpcfg.zip Next startup saved-configuration file: cfcard:/vrpcfg.zip

注意看 Noise字段是否为 NULL。如果显示 NULL，说明这台设备当前没有指定启动配置文件。就算你刚才执行了 save，只要保存的文件名没有被正确设置成启动配置文件，重启照样不加载。正常情况下 save 会自动把当前保存的文件设置为下一次启动配置文件，但如果你之前手动用 startup saved-configuration 改过路径，或者初装设备从来没有配置过启动文件，就会出现保存了却不加载的诡异现象。

H3C 也类似：

<H3C> display startup Current startup saved-configuration file: flash:/startup.cfg Next main startup saved-configuration file: flash:/startup.cfg

如果两边显示的是 NULL 或者路径里的文件名和实际保存的文件不一致，就用 startup saved-configuration 命令手动指回去，比如：

<H3C> startup saved-configuration flash:/startup.cfg

修完之后再执行一遍 display startup 确认。

4.3 思科的 config-register 与 boot 参数

思科设备上也有一个同样性质但很多人不熟的启动配置开关，叫 config-register。这个参数控制了很多开机行为，其中包括“是否读取 startup-config”。

正常情况下，思科 IOS 设备的 config-register 应该是 0x2102，代表正常加载 NVRAM 中的 startup-config 启动。但有的设备被改成 0x2142，这个值的意思是“忽略 NVRAM 配置启动”，本来是官方用来做密码恢复和排障的。如果设备上一个维护人员调过这个值又没改回来，重启之后设备就会跳过 startup-config，直接以空配置启动。从操作者的角度看，就像配置丢了一样。

用 show version 查看：

Switch# show version <省略> Configuration register is 0x2142

看到 0x2142 就要警惕，如果这不是你有意设置的特殊状态，应该改回 0x2102：

Switch# configure terminal Switch(config)# config-register 0x2102 Switch(config)# end Switch# write memory

注意，config-register 修改之后通常需要重启才能完全生效，所以改完现场验证要留出第二次重启的窗口。另外，思科个别平台的 boot 命令里也能指定启动配置文件路径，比如 boot startup-config 之类的参数，如果 show running-config 里能看到这类命令并且指向异常，同样会导致加载问题。这类情况虽然少见，但排障时要想得到。

4.4 锐捷交换机的启动配置机制

锐捷设备整体命令风格偏思科，很多型号上执行 write 保存之后，重启默认就会加载。但框式设备、支持双主控的机型、以及不同软件版本的启动管理命令不太一样，我见过最坑的案例是保存到了 flash 里的一个自定义文件名，但启动引导参数仍然指向默认的 config.text 或者其他文件，结果重启后配置既不报错也不加载，看起来就像完全没保存。

遇到锐捷设备重启丢配置，先做两个检查。

一是看启动配置文件名和启动参数是否一致。执行 show boot 或者 show version，找到配置文件路径，再和实际保存的文件名对比。发现不一致，就用对应命令把启动配置文件重新指定回来。

二是确认平台是否有类似 config-register 的位开关。有些锐捷机型支持 register 参数，同样的道理，如果被改成 0x2142 或其他忽略配置的值，重启必丢。这种场景常出现在二手设备、实验室设备上，前一任使用者调了特殊参数，下一任接手时完全不知情，设备一重启就“变脸”。

4.5 堆叠/IRF/CSS 里容易被忽略的成员配置同步

第二个配置错误的另一个高发场景，是堆叠、IRF、CSS 这类多设备虚拟化组网里。

很多新手以为堆叠系统是一台设备，保存配置一次就够了，其实没这么简单。堆叠建立后，配置确实主要落在主设备上，但成员设备、备用主控也有自己的配置文件。如果只在主设备上执行了 save，备设备或成员设备上的启动配置可能是旧的、空的，甚至残缺的。一旦发生主备倒换，或者某台成员设备独立重启、脱离堆叠，它就会按自己那份老旧配置启动，表现出来就是“配置全没了”或者“部分配置没生效”。

我见过一个挺典型的事故：两台设备做了堆叠，配置一直很稳，后来为了割接需要把其中一台先关掉，结果那台设备关掉再起来之后，发现上面没有同步最新的配置，业务流量路径全部乱套。查来查去，问题是主设备保存配置时只保存了自己的本地文件，没有同步到备设备，备设备重启后加载的是一周前的旧配置。

所以堆叠环境下，保存动作要贯彻到所有成员设备。不同厂商的命令和同步机制不一样，有的平台执行 save 时会自动同步，有的需要手动登录到每台成员设备上依次保存，还有的依赖堆叠配置同步命令，比如部分 H3C 场景里的 irf configuration sync 之类。通用的做法是：在主设备上保存后，登上备用主控和所有成员设备，逐一执行 display startup 或 show startup-config，确认每台设备上的启动配置文件信息一致。别嫌麻烦，堆叠故障往往比单机故障影响面大得多。

5. 真实排查链路：十分钟按图索骥

前面把这些原理和坑都过了一遍，现在给你一套亲测有效的排查链路，如果哪天真的遇到“配置重启后消失”，按这个顺序操作，十分钟内大概率能定位问题。

5.1 重启前要留下的恢复抓手

避免事故的第一步是在重启前留下足够的信息。不是每次重启都能从容做完备份，但至少要执行下面三个命令并保存输出，三个命令三十秒就够：

• show running-config 或 display current-configuration，导出当前运行配置；
• show startup-config 或 display saved-configuration，确认已保存的配置内容；
• show version / show boot / display startup，记录设备的启动参数、配置寄存器、启动配置文件路径。

把这三份输出存到本地，哪怕重启后设备真的全丢，你手里还有一份完整的期望配置可以手工恢复，不至于抓瞎。

5.2 重启后确认配置丢在哪一层

设备起来之后，不要慌，按下面的逻辑一层层排除。

第一，看 running-config 或 current-configuration。如果运行配置正常，只是个别业务没有恢复，那是服务没起来、接口状态问题、或者路由协议收敛没完成，和“配置丢失”是两回事。

第二，如果 running-config 是出厂默认状态，接着看 startup-config 或 saved-configuration。这里会分出两条路：startup-config 里是空的，说明问题出在保存环节，也就是第一个配置错误；startup-config 里有完整配置但 running-config 却是空的，说明问题出在启动加载环节，也就是第二个配置错误。

第三，如果 startup-config 有内容、running-config 也有内容，但不完整，那要重点检查启动时有没有报错，比如某个配置文件缺失、接口配置加载失败、堆叠成员没有同步等。

这个分层逻辑适用于所有厂商设备，因为它基于的是设备工作的通用机制，而不是某家的具体命令。

5.3 常见现象与根因对照表

这张表不是万能的，但它覆盖了绝大概率的重启丢配置场景。如果你的现象不在表里，恭喜你，又碰到一个能发技术帖的冷门 bug 了。

6. 把“重启不丢配置”变成本能

排障只是事后补救，我更希望你在日常操作中把“不丢配置”变成一个不需要思考的习惯。这套习惯不复杂，核心就四个字：闭环验证。

6.1 一套稳到没朋友的保存配置动作

我自己的保存固定套路，每次操作都严格执行，不凭感觉跳步：

1. 退出配置模式，回到特权模式或用户视图；
2. 用 show running-config 或 display current-configuration 最后确认一遍运行配置；
3. 执行保存命令，华为/华三用 save，思科/锐捷用 write，需要确认时敲 y；
4. 保存完成后，立即执行 show startup-config 或 display saved-configuration，确认关键配置已在启动配置文件里；
5. 对于华为/华三，再补一步 display startup，确认启动配置文件路径不是 NULL；
6. 对于思科设备，顺手看一眼 show version 的 config-register，确认是 0x2102 而不是 0x2142。

这套动作看起来啰嗦，但每一步都有对应的“为什么会丢”的场景。比如第五步解决的就是启动指向问题，第六步解决的是思科特有的忽略配置启动问题。

6.2 用定时保存兜底

再注意的人也有忙中出错的时候，所以很多设备支持定时自动保存配置。

华为和 H3C 设备上可以配置定时保存：

<Huawei> system-view [Huawei] set save-configuration delay 300 [Huawei] set save-configuration interval 60

大意是每隔一段时间或延迟一定时间自动执行保存。这个功能尤其适合那些长期有人调试、配置频繁变动的设备，哪怕有人调完忘了保存，定时任务也能兜底。

思科平台没有完全对等的内置定时保存，但可以利用 archive 功能做配置归档，或者依靠运维平台的定时任务定期 ssh 上去执行 write memory。如果公司有网络管理平台，给核心设备配置一个每日自动保存的定期任务，是性价比很高的操作。

6.3 变更窗口的自检命令串

变更窗口收尾时，我习惯按以下顺序快速过一遍，当作默认动作：

• 登录设备确认设备名和型号，别在对端设备上操作；
• 执行保存命令；
• 执行 display startup / show startup-config，确认配置文件存在且时间戳是刚才；
• 如果是双主控或堆叠，登录备主控/成员设备再确认一次；
• 把所有执行结果和关键输出粘贴到变更记录里，留痕。

这样做的好处是，将来设备出了任何配置相关的问题，可以通过变更记录反推是什么时候、哪台设备、哪个环节出了问题，而不是靠记忆去猜。

6.4 模拟器环境的差异

最后必须提醒一句，在 eNSP、GNS3、EVE-NG 这类模拟器环境里，很多人会遇到“明明在设备上保存了配置，关掉工程再打开，配置还是没了”的情况。

模拟器里的设备虽然能执行 save 命令，但它的非易失存储本质上是模拟出来的，依赖模拟器工程文件的保存状态。如果你只关了设备没保存工程，或者在模拟器里点了“清空终端配置”，那点设备上的 startup-config 也会跟着丢。所以模拟器环境操作时，设备内保存和模拟器工程保存要一起做，缺一个都白搭。

另一个模拟器特有的坑是，某些模拟器在设备启动时默认不加载任何配置文件，即使你在设备里执行过 write memory，重开工程后也会回到初始状态。这种情况不是配置错误，而是模拟器的行为特性，处理方式是保存工程后重新启动设备前，提前确认一下设备里 display startup 的指向。

7. 写在最后：这些年我踩过的“保存”坑

带新人的时候，我经常说一句话：不要相信任何人说“配置已经保存了”，只相信设备自己说出来的启动配置文件信息。口头汇报会出错，记忆会模糊，只有 show startup-config 这种命令的回显是诚实的。

我自己早年也栽过跟头，最尴尬的一次是在客户现场改完配置，信誓旦旦跟客户说保存好了，结果设备一重启，业务直接中断。后来回查发现不仅 save 没敲，连配置导出备份都没留，只能一个人蹲在机房里一条一条重新敲，从凌晨两点敲到早上六点。那次之后，我才真正把“保存配置 + 验证启动配置 + 导出配置备份”这三步焊死在流程里。

现在每一次改完配置，我最后一步一定是看一眼设备的 startup-config 文件信息和时间戳，再顺手把配置导出一份到本地。这个动作多花不到一分钟，但能让我在每一个睡到一半被电话叫醒的凌晨，都多一分底气。

如果你看到这里，建议现在就去登录手头正在维护的设备，执行一遍保存命令，再用验证命令确认一下启动配置文件和启动指向。也许就是这几秒钟，帮你躲过下一次设备重启带来的大麻烦。