1. 课程导入与故障诊断全景
在复杂数据中心里，Arista 交换机往往不是孤立设备，而是承载 Spine-Leaf 架构、VXLAN 叠加网络、EVPN 控制平面以及多租户隔离的关键节点。一次业务中断，可能源于光模块收光功率不足，也可能源于 BGP EVPN 路由未收敛，甚至只是某条 ACL 误拦了 VXLAN 内层流量。如果诊断时只盯着一个层面，很容易在错误的方向上消耗大量时间。本课程的第一节，先建立一张“从物理层到应用层”的诊断全景图，并明确 EOS、CloudVision、Telemetry 三类核心工具各自在故障定位中的位置。
为什么需要分层诊断思维
数据中心网络的故障具有明显的“层间传导”特征。物理层链路抖动会导致上层协议邻居反复重建；Underlay 路由不可达会让 VXLAN 隧道无法建立；EVPN 路由类型 2 缺失则表现为虚拟机无法跨 Leaf 通信。若把网络简化为“通”与“不通”，就会丢失定位精度。分层诊断的核心，是把故障现象映射到 OSI 或 TCP/IP 的某一层，再在该层内使用对应工具和判据逐级收敛。
以一次典型故障为例：某租户报告两台虚拟机之间时延突增且偶发丢包。按照分层思路，先确认物理层——检查两端 Leaf 上联端口的光功率、CRC 错误计数和接口 flap 记录；再确认链路层——查看 VLAN、MTU 与端口 channel 状态；接着确认网络层——验证 Underlay 的 OSPF/BGP 邻居与路由表；然后进入叠加层——检查 VXLAN VNI 映射、EVPN 邻居与 MAC/IP 路由；最后才到应用层——确认负载均衡、防火墙或安全策略是否引入额外时延。这个顺序不是死板流程，而是“由下至上、逐层排除”的收敛策略。
EOS、CloudVision、Telemetry 的定位
Arista EOS 是设备本地的操作系统，提供最细粒度的实时状态。它的价值在于“单点深挖”：通过 show interfaces、show bgp evpn、show vxlan vni 等命令，可以直接观察接口计数器、协议状态和转发表项。EOS 还支持 Linux 底层工具，例如在 bash 中查看 /proc/net 或使用 tcpdump 抓取特定 VNI 的报文，这对定位叠加网络中的封装问题非常关键。
CloudVision 则是“全局视角”的管理与分析平台。它通过 gNMI/gRPC 从多台设备采集配置与状态，形成网络范围的拓扑、合规性和变更审计视图。当故障涉及多台设备或配置漂移时，CloudVision 能快速回答“哪台设备、哪个时间点、哪条配置发生了变化”。它不替代 EOS 的实时诊断，而是把分散在各设备上的信息聚合为可关联的数据集。
Telemetry 解决的是“高频、连续、可观测”的问题。传统 SNMP 轮询周期通常为分钟级，难以捕捉微突发或瞬态丢包。Arista 支持基于 gNMI 的流式 Telemetry，可将接口队列深度、丢包计数、CPU 利用率等指标以秒级甚至亚秒级推送至采集器。在诊断时，Telemetry 提供的是时间序列证据，用于判断故障是持续性的还是突发性的，以及是否与某次配置变更或流量峰值相关。
从现象到层级的映射方法
实际诊断中，第一步不是敲命令，而是把用户描述转化为可观测的层级线索。例如“跨机架虚拟机不通”至少涉及三个可能层级：Underlay 路由是否可达、EVPN 是否学到对端 MAC/IP、VXLAN 隧道是否正常封装。可以先用 show bgp evpn route-type mac-ip 确认 EVPN 路由是否存在；若缺失，再回到 Underlay 检查 BGP 邻居与路由表；若 EVPN 路由存在但流量不通，则用 show vxlan vni 和 tcpdump 检查封装与解封装。
再看一个时延类故障。若 Telemetry 显示某 Leaf 上联口队列深度周期性飙升，而其他端口正常，则问题很可能集中在特定链路或 ECMP 哈希结果上。此时用 EOS 的 show interfaces counters 查看该口丢包与 pause 帧，再用 CloudVision 检查该链路两端配置是否对称。这种“Telemetry 发现异常 → EOS 确认细节 → CloudVision 关联配置”的三角验证，比单一工具更可靠。
工具协同的典型判据
为了便于快速判断，可以把三类工具的输出归纳为不同证据类型：EOS 提供“点证据”，如接口计数器、协议状态机、转发表项；CloudVision 提供“面证据”，如拓扑变化、配置差异、变更审计；Telemetry 提供“线证据”，如时间序列上的突变、趋势和相关性。诊断时，点证据用于确认现象，面证据用于定位范围，线证据用于判断时序。三者结合，才能从“某台设备有问题”推进到“某条链路在某个时间点因某次变更出现了特定异常”。