📚 课程目录第2章 Arista EOS配置体系解析

2. Arista EOS配置体系解析

Arista EOS 的配置治理能力，很大程度上来自它对“配置到底存在哪里、什么时候生效、如何回退”这件事的清晰分层。理解 running-config、startup-config 与 flash 中配置文件的关系，是后续做合规基线与变更审计的前提。很多变更事故并非命令写错，而是操作者误判了“当前生效的配置”和“重启后仍存在的配置”之间的差异。

一、三层配置对象：内存、启动与持久存储

EOS 的配置体系可以按“生效态—启动态—存储态”来理解：

running-config（运行配置）：驻留在内存中，是设备当前真正生效的配置。所有 show 命令看到的接口状态、路由协议、ACL 行为，都由它决定。它随设备重启而丢失，除非被保存。
startup-config（启动配置）：设备重启时加载的配置，通常位于 flash 的 startup-config 文件中。它决定了“重启后设备长什么样”。
flash 中的配置文件：EOS 允许把配置以命名文件形式保存在 flash 中，例如 flash:baseline-2024.cfg。这些文件不自动生效，但可作为基线快照、回滚源或审计证据。

三者的关系可以用一句话概括：running-config 是“现在”，startup-config 是“下次启动”，flash 中的命名配置是“可追溯的历史与基线”。变更治理的核心，就是让这三者之间的差异始终处于受控状态。

二、commit 与 rollback：变更的“提交—回退”语义

在 EOS 中，配置变更默认是“即时生效”的：进入配置模式敲下命令，running-config 立刻改变。但 EOS 提供了更接近版本控制的机制，让变更可以像代码提交一样被管理。

commit 在 EOS 中通常与“配置会话”或“候选配置”配合使用。当启用 configure session 后，所有变更先进入一个候选配置，只有执行 commit 才会真正合并到 running-config。这带来两个关键好处：一是变更可以分阶段准备，二是提交前可以用 show session-config diffs 查看将要生效的差异。

switch# configure session CHANGE-20240615
switch(config-sess-CHANGE-20240615)# interface Ethernet1
switch(config-sess-CHANGE-20240615-if-Et1)# description Uplink-to-Core
switch(config-sess-CHANGE-20240615-if-Et1)# exit
switch(config-sess-CHANGE-20240615)# show session-config diffs
--- running-config
+++ session-config
@@ interface Ethernet1 @@
+   description Uplink-to-Core
switch(config-sess-CHANGE-20240615)# commit

这段示例展示了“先看差异、再提交”的受控变更流程。差异行以 + 开头表示新增，- 表示删除，与常见 diff 语义一致。提交后，候选配置合并进 running-config，但此时仍未写入 startup-config，重启后依然会丢失。

rollback 则用于把配置恢复到某个已知状态。EOS 支持基于 checkpoint 的回滚，也支持从 flash 中的命名配置文件回滚。回滚的价值在于：当变更导致业务异常时，可以快速回到变更前的稳定状态，而不必逐条反向输入命令。

三、checkpoint：内存中的配置快照

checkpoint 是 EOS 配置治理中非常实用的机制。它在内存中保存一份 running-config 的快照，并赋予一个名称。与 flash 文件不同，checkpoint 不占用持久存储，创建和回滚速度都很快，适合在变更前“随手打一个点”。

switch# checkpoint create BEFORE-ACL-CHANGE
switch# show checkpoint list
BEFORE-ACL-CHANGE   2024-06-15 14:22:03
switch# configure terminal
switch(config)# ip access-list STANDARD
switch(config-std-acl)# deny host 10.1.1.99
switch(config-std-acl)# exit
switch(config)# end
switch# show diff checkpoint BEFORE-ACL-CHANGE
--- checkpoint BEFORE-ACL-CHANGE
+++ running-config
@@ ip access-list STANDARD @@
+   deny host 10.1.1.99
switch# configure replace checkpoint BEFORE-ACL-CHANGE

这里 show diff checkpoint 用于确认变更内容，configure replace checkpoint 用于回退。回退后 running-config 恢复到快照状态，但 startup-config 不会自动同步，仍需显式保存。这一点在审计时经常被忽略：回滚只影响运行态，不等于持久化。

四、变更治理中的关键判断

把上述机制放到合规与变更治理的语境中，可以形成几条明确的判断规则：

变更前：创建 checkpoint 或保存命名配置文件，作为回退锚点；记录变更单号与时间戳。
变更中：使用 configure session 准备候选配置，提交前必须查看 diff，确认影响范围。
变更后：验证业务状态，确认无误后再执行 write memory，使 startup-config 与 running-config 一致。
审计时：对比 running-config 与 startup-config 的差异，识别“已生效但未持久化”的配置漂移。

常见误区：执行 rollback 或 configure replace 后，running-config 已恢复，但 startup-config 仍是变更后的版本。若此时设备重启，会重新加载错误的 startup-config。因此回滚后必须重新评估并保存 startup-config。

五、配置漂移的识别与处理

配置漂移是指 running-config 与预期基线之间出现的非受控差异。在 EOS 上识别漂移，最直接的方式是导出 running-config 并与基线文件做文本比对。例如将 show running-config 输出保存为文件，再与 flash 中的基线配置逐行比较，差异行即为漂移点。

处理漂移时，需要区分两类情况：一类是合理的临时变更（如排障时临时调整），应在变更结束后回退；另一类是无记录的永久变更，应补录变更记录并更新基线。无论哪一类，都应通过 checkpoint 或命名配置文件留下可追溯的操作痕迹。

综合来看，EOS 的配置体系提供了从“即时生效”到“受控提交”再到“快速回退”的完整能力。running-config、startup-config 与 flash 文件分别对应运行态、启动态与历史态，commit、rollback、checkpoint 则构成变更治理的操作闭环。掌握这些对象与机制之间的关系，才能在后续的合规基线与审计工作中做到有据可依、有路可退。