2. Arista EOS与数据中心架构基线
在讨论任何升级迁移动作之前，必须先建立一张清晰的“架构基线图”。Arista 数据中心网络的核心不是某一台交换机，而是由 EOS 操作系统、MLAG 接入冗余、VXLAN 数据面封装、EVPN 控制面、Underlay/Overlay 分层以及 Spine-Leaf 拓扑共同构成的整体。升级迁移之所以复杂，正是因为这些组件彼此耦合：改动 Underlay 路由可能影响 EVPN 邻居，调整 MLAG 可能牵动接入侧双活，变更 VXLAN 参数则可能波及跨 Leaf 的二层扩展。理解它们之间的关联，是后续制定迁移窗口、回退方案和验证清单的前提。
EOS：统一的操作系统底座
Arista EOS（Extensible Operating System）是运行在所有 Arista 交换机上的单一镜像操作系统，其最大特点是“单一镜像、多平台通用”。无论是 1RU 的 Leaf 交换机还是高密度 Spine 框式设备，都运行同一套 EOS 软件，差异通过平台驱动和特性授权体现。这带来两个直接好处：一是升级时可以使用统一的 EOS 版本基线，减少因平台差异导致的版本碎片；二是配置语法、CLI 结构和可编程接口（eAPI、gNMI、OpenConfig）保持一致，便于自动化批量下发。
EOS 的进程化架构（SysDB + 各 Agent）使路由、接口、MLAG 等模块相对独立，单个进程重启通常不会导致整机转发中断。在升级迁移中，这意味着可以通过 reload 或 install 方式滚动升级，并借助 MLAG 或 EVPN 多路径实现业务不中断。需要特别关注的是 EOS 版本与硬件平台、特性集（如 VXLAN、EVPN、MLAG）的兼容矩阵，升级前必须核对目标版本是否支持当前所有已启用特性。
MLAG：接入侧的双活冗余
MLAG（Multi-Chassis Link Aggregation）让两台物理交换机在接入服务器看来像一台逻辑交换机。服务器使用标准 LACP 双上联到两台 Leaf，形成跨设备的 Port-Channel。MLAG 通过 Peer-Link 同步 MAC 表、ARP 表和 STP 状态，并使用 Peer-Link 上的心跳与一致性检查判断对端是否存活。
在升级迁移中，MLAG 是“逐台升级、业务不中断”的关键机制。典型做法是：先升级 MLAG 备侧（Secondary），此时主侧继续转发；备侧重启完成后重新加入 MLAG，再升级原主侧。整个过程服务器侧 LACP 成员端口始终至少有一个处于转发状态。但要注意，MLAG 的 Peer-Link 必须是高带宽直连链路，且升级期间不能同时重启两台设备，否则会形成双主（dual-primary）导致 MAC 漂移和流量黑洞。
VXLAN 与 EVPN：Overlay 的数据面与控制面
VXLAN 解决的是“二层网络如何在三层 IP 网络上延伸”的问题。它把原始以太网帧封装进 UDP 报文，外层使用 VTEP（VXLAN Tunnel Endpoint）的 IP 地址进行路由转发。每个 VXLAN 网络用 VNI（VXLAN Network Identifier）标识，理论上支持 1600 万个租户网络，远超传统 VLAN 的 4094 个。
但 VXLAN 本身只定义了数据面封装格式，不负责 VTEP 之间的地址学习和隧道建立。如果靠 Flood-and-Learn，会产生大量未知单播泛洪，扩展性差。EVPN（Ethernet VPN）作为 BGP 的地址族扩展，承担了 Overlay 的控制面：通过 MP-BGP 在 VTEP 之间交换 MAC/IP 可达性信息（Type-2 路由）、IMET 组播隧道信息（Type-3 路由）和前缀路由（Type-5 路由）。这样 VTEP 之间可以建立精确的隧道映射，避免泛洪。
在升级迁移中，EVPN 的价值在于：新增或替换 Leaf 时，只要 BGP EVPN 邻居建立、路由收敛，新 Leaf 就能自动学习到远端 VTEP 的 MAC/IP 信息，无需手工配置静态隧道。但前提是 Underlay 路由必须先把 VTEP 的 Loopback 地址打通。
Underlay 与 Overlay 的分层关系
Underlay 是物理承载网，通常采用 eBGP 或 OSPF 在 Spine 和 Leaf 之间交换 Loopback 和互联地址，目标是提供无环、等价多路径（ECMP）的 IP 可达性。Overlay 是建立在 Underlay 之上的逻辑网络，VTEP 之间的 VXLAN 隧道报文依靠 Underlay 路由到达对端。两者关系可以概括为：Underlay 负责“把包送到对端 VTEP”，Overlay 负责“包到了之后属于哪个租户、哪个二层域”。
升级迁移时，Underlay 的变更（如修改 BGP AS 号、调整链路开销、更换 Spine）会直接影响 Overlay 隧道的可达性。因此通常建议先稳定 Underlay，再验证 EVPN 邻居和 VXLAN 隧道状态，最后才动 Overlay 业务参数。
Spine-Leaf 拓扑与升级迁移的关联
Spine-Leaf 是 Clos 架构的两种角色：Spine 只负责高速转发，不连接服务器；Leaf 连接服务器和存储，并作为 VTEP。任意 Leaf 到任意 Leaf 的流量最多经过一台 Spine，跳数固定、时延可预测。这种拓扑天然适合滚动升级：升级一台 Spine 时，Leaf 到其他 Spine 的 ECMP 路径仍然可用；升级一台 Leaf 时，该 Leaf 下的服务器可通过 MLAG 切换到对端 Leaf。
下面这张图把 EOS、MLAG、VXLAN、EVPN、Underlay/Overlay 和 Spine-Leaf 的关联放在同一张架构基线上，便于在升级前快速定位“改哪一层、影响哪些对象”。
升级迁移中的关联判断
把上述组件串起来看，升级迁移的决策可以按“影响半径”排序。影响半径最大的是 Underlay 路由协议变更，因为它会同时影响所有 VTEP 的可达性；其次是 Spine 设备升级，影响所有 Leaf 的 ECMP 路径；再次是 Leaf 升级，影响该 Leaf 下挂的服务器和 MLAG 对端；最小的是单台服务器的接入参数调整。
一个可参考的升级前检查顺序是：先确认 EOS 目标版本与当前硬件、特性集的兼容性；再确认 Underlay 的 BGP/OSPF 邻居和 Loopback 路由表完整；然后确认 EVPN 邻居状态为 Established、Type-2/Type-3 路由数量与预期一致；接着确认 MLAG 状态为 primary/secondary 且 Peer-Link 正常；最后确认 VXLAN 隧道 Up、VNI 映射正确。只有这些基线全部健康，滚动升级才有可预期的收敛行为。
需要强调的是，Spine-Leaf 拓扑本身并不自动保证升级不中断，真正提供保护的是 MLAG 的双活接入和 EVPN 的多路径收敛。如果 MLAG 配置错误或 EVPN 路由未收敛，即使拓扑正确，单台 Leaf 重启仍可能导致服务器失联。因此，架构基线的价值在于：让每一次升级动作都能对应到明确的保护机制和验证点，而不是依赖“应该没问题”的经验判断。