📚 课程目录第4章 Arista EOS基础与DCI配置框架

4. Arista EOS基础与DCI配置框架

在DCI互联工程中，设备初始化并不是“上电后随手敲几条命令”这么简单。Arista EOS作为数据中心与DCI场景中广泛使用的网络操作系统，其CLI、配置管理、ZTP、eAPI与CloudVision共同构成了一套从“裸机上线”到“配置可控、状态可视、变更可审计”的完整框架。理解这套框架，是后续DCI互联参数落地、策略下发和故障排查的前提。

EOS CLI：DCI设备的本地操作入口

EOS CLI采用分层视图结构，默认进入用户模式，输入 enable 进入特权模式，再输入 configure terminal 进入全局配置模式。DCI设备初始化时，通常先确认版本与硬件信息，再进入配置模式。例如：

show version
show interfaces status
configure terminal
hostname dci-leaf-01
interface Ethernet1
   description To-DCI-Spine-01
   no switchport
   ip address 10.10.1.1/30

上述示例中，no switchport 将二层口转为三层路由口，这是DCI互联中常见的做法；ip address 10.10.1.1/30 表示该接口与对端设备处于同一/30互联网段。配置完成后，可用 show ip interface brief 查看接口IP与状态，用 show lldp neighbors 确认对端邻居是否识别正确。CLI的价值在于“即时可验证”：每敲一条命令，都能通过show命令观察结果，适合初始化阶段的逐项确认。

配置管理：从running-config到启动配置

EOS的配置管理核心是running-config与startup-config的关系。running-config是当前内存中生效的配置，startup-config是设备重启后加载的配置。DCI设备初始化时，常见操作包括：

copy running-config startup-config
show running-config
show startup-config
write memory

其中 write memory 等价于保存配置。若只修改running-config而未保存，设备重启后配置会丢失。DCI工程中建议在每次变更后执行保存，并记录变更前后的配置差异。EOS还支持配置会话（configure session），可在提交前预览差异：

configure session DCI-CHANGE
interface Ethernet1
   mtu 9214
show session-config named DCI-CHANGE diffs
commit

这种方式适合DCI互联中MTU、BGP邻居、路由策略等关键参数的批量变更，能有效降低误操作风险。

ZTP：零接触开局与DCI批量初始化

ZTP（Zero Touch Provisioning）用于设备首次上电或恢复出厂后自动获取并加载配置。其基本流程是：设备通过DHCP获取管理IP和ZTP服务器地址，然后从HTTP/TFTP/FTP服务器下载启动脚本或配置文件，自动执行并完成初始化。DCI场景中，若有多台Leaf或Spine需要上线，ZTP可显著减少逐台手工配置的工作量。

一个典型的ZTP脚本会先判断设备型号和序列号，再决定加载哪份配置。例如：

#!/usr/bin/env python
import json
import urllib.request

model = "DCS-7050X3"
config_url = "http://ztp-server/dci/" + model + ".cfg"
urllib.request.urlretrieve(config_url, "/mnt/flash/startup-config")

实际工程中，ZTP脚本通常还会校验配置文件完整性、记录日志、在加载后触发eAPI或CloudVision注册。需要注意的是，ZTP依赖DHCP、DNS、HTTP等基础服务，若这些服务未就绪，设备可能停留在ZTP等待状态。此时可通过 show ztp status 查看当前阶段，判断是DHCP未响应、脚本下载失败还是配置加载异常。

eAPI：面向自动化的可编程接口

eAPI是EOS内置的HTTP/HTTPS接口，允许通过JSON-RPC方式执行CLI命令、获取结构化数据。与SSH逐条敲命令相比，eAPI更适合DCI控制器或自动化平台调用。启用方式如下：

management api http-commands
   protocol https
   no shutdown

启用后，可用curl或Python请求执行命令。例如获取接口状态：

curl -k -u admin:password https://10.10.1.1/command-api \
  -d '{"jsonrpc":"2.0","method":"runCmds","params":{"version":1,"cmds":["show interfaces status"],"format":"json"},"id":1}'

返回结果为JSON结构，便于程序解析。DCI初始化中，eAPI常用于批量采集设备信息、下发接口描述、校验BGP邻居状态。与CLI相比，eAPI的优势是“结构化输出”和“可编程调用”，但前提是管理网络可达且认证配置正确。

CloudVision集成：从单机配置到集中管理

CloudVision是Arista的集中管理平台，可对多台EOS设备进行配置下发、状态监控和变更审计。DCI设备初始化时，通常将设备注册到CloudVision，由CloudVision统一管理配置模板和合规性检查。设备侧需要配置管理接口和CloudVision服务器地址，并确保eAPI可用。注册后，CloudVision可读取设备的running-config，生成配置偏差报告，并支持基于容器或配置let的批量下发。

在DCI工程中，CloudVision的价值在于“跨站点一致性”：当多个数据中心通过DCI互联时，各站点的Leaf/Spine配置需要保持相似的基线，CloudVision可以集中定义模板，减少人工逐台配置带来的差异。但需注意，CloudVision本身不替代底层网络连通性，设备必须先具备管理IP和到CloudVision的IP可达性，才能完成注册。

初始化顺序与验证要点

综合来看，DCI设备初始化可以按以下顺序推进：先确保管理接口IP可达，再通过ZTP或手工CLI完成基础配置，随后保存startup-config，接着启用eAPI并验证JSON调用，最后将设备注册到CloudVision。每一步都有对应的验证命令：管理IP用 show management api http-commands 确认eAPI状态，用 show ztp status 判断ZTP阶段，用 show running-config 与 show startup-config 对比配置是否已保存。

实践提示：在DCI工程中，建议将ZTP脚本、eAPI调用脚本和CloudVision注册流程纳入版本管理。设备初始化完成后，先不要急于配置BGP或VXLAN，而是确认管理面、配置面和自动化面均已稳定，再进入互联参数配置阶段。

注意：ZTP和eAPI都依赖管理网络。若管理网络尚未打通，ZTP会停留在DHCP阶段，eAPI也无法访问。此时应优先排查管理接口VLAN、DHCP中继和路由可达性，而不是反复修改ZTP脚本。

掌握EOS CLI、配置管理、ZTP、eAPI与CloudVision的协同关系后，DCI设备初始化就不再是零散命令的堆叠，而是一条可验证、可自动化、可审计的工程路径。后续的DCI互联配置，正是建立在这条路径稳定运行的基础之上。