2. Arista EOS与云网络基础

在云网络里谈性能与容量，不能只盯着端口速率和芯片型号，必须先把“软件控制面—硬件转发面—可观测面”这条链路看清楚。Arista 的体系可以概括为三层：EOS 作为统一网络操作系统，CloudVision 作为集中管理与遥测平台，vEOS 作为可离线验证的虚拟化实例；而真正决定吞吐、时延与表项规模的，是底层 Jericho、Trident、Tomahawk 三类转发芯片的架构差异。理解这四者的分工与耦合关系，是后续做容量规划与性能调优的前提。

EOS：单镜像、多进程、可编程的转发底座

EOS（Extensible Operating System）最核心的设计是“单一镜像 + 多进程 + 无状态重启”。它基于 Linux 内核，把路由协议、接口管理、转发状态等拆成独立进程（如 Bgp、Fib、Stp、Lag），进程之间通过 SysDB 共享状态。这样做的好处是：某个协议进程异常重启时，转发面（数据平面）不受影响，已下发的硬件表项继续生效，业务流量不中断。

对性能与容量而言，EOS 有两个关键点需要记住。第一，控制面与转发面解耦：路由收敛速度取决于协议进程与 CPU，而实际转发能力取决于 ASIC 表项与缓存，两者不能混为一谈。第二，EOS 提供 show platform、show hardware、show interfaces counters 等命令，可直接读取芯片级资源占用，这是容量评估的第一手数据来源。例如查看转发表项余量：

show platform trident forwarding-table usage
show platform jericho resources
show interfaces counters rates

这些输出中的 used/free、high-watermark 字段，就是判断“还能加多少租户、多少路由”的直接依据。

CloudVision：把分散的遥测变成容量视图

CloudVision（CVP）不是简单的配置下发工具，它的价值在于把全网 EOS 的状态、计数器、流表、告警统一采集并做趋势分析。在容量规划中，CVP 主要承担三件事：一是通过 Streaming Telemetry 以秒级粒度采集接口速率、队列丢包、Buffer 占用；二是用 Change Control 记录每次配置变更，便于把性能波动与变更事件对齐；三是通过拓扑与合规视图，快速定位哪些交换机已接近表项或带宽阈值。

实操中，建议在 CVP 中为关键指标建立基线：例如核心层每端口 95 百分位利用率、每台 Leaf 的 MAC/IP 表项使用率、ECMP 组数量。当某台设备连续 5 分钟超过基线 80% 时触发告警，而不是等到丢包才处理。这样容量规划就从“事后救火”变成“趋势预判”。

vEOS：上线前的性能与配置验证环境

vEOS 是运行在虚拟机或容器中的 EOS 实例，转发面由软件模拟（如 vEOS-lab 使用 Linux 内核转发）。它不能用来测真实吞吐和时延，但非常适合做三件事：验证 BGP/EVPN 配置语法、验证 CloudVision 注册与 Telemetry 采集、验证自动化脚本（如 eAPI、Ansible）的正确性。换句话说，vEOS 负责“逻辑正确性”，真实硬件负责“性能与容量”。把两者混用，是初学者常见的误区。

三类转发芯片：决定性能与容量的物理边界

Arista 交换机的能力上限由 ASIC 决定，主流分为三条产品线：

• Trident：面向 1/10/25/100G 接入与汇聚，表项规模适中，支持较丰富的 ACL 与 VXLAN，适合 Leaf 层与中小规模云网络。它的 Buffer 相对有限，突发流量下容易在拥塞端口丢包。
• Tomahawk：面向 100/400G 高密度骨干与 Spine，强调高带宽、低时延、大 ECMP 组，但表项深度和 Buffer 通常小于 Jericho，适合“转发路径简单、流量大”的场景。
• Jericho：面向核心与边界，具备大容量外部 TCAM/DRAM、深 Buffer 和分段路由能力，能承载百万级路由与大规模租户表项，适合需要深度表项和复杂策略的云骨干。

三者的差异可以用一张“能力—场景”关系图来理解：横轴是表项深度与 Buffer，纵轴是端口带宽密度。Trident 居中，Tomahawk 偏右上（高带宽、中等表项），Jericho 偏左上（高表项、高 Buffer、带宽密度略低）。选型时先问“我需要多少路由/租户表项”和“我需要多少 400G 端口”，两个答案基本就能锁定芯片家族。

从架构到容量：一条可执行的评估路径

把上述知识落到实际工作中，可以按以下顺序推进。第一步，明确业务需求：租户数量、VXLAN 隧道数、BGP 路由条数、东西向带宽峰值。第二步，对照芯片能力表，估算所需表项与端口。例如一个中型云区有 2000 个租户、每租户 4 条 VXLAN 隧道，则 Leaf 需要约 8000 条隧道表项，Trident 通常可满足；若租户数升到 2 万，则应考虑 Jericho 或分层设计。第三步，在 vEOS 上验证 EVPN 配置与 CVP 注册流程，确保逻辑无误。第四步，上线后用 CVP 采集真实基线，观察表项使用率与端口利用率是否在预期范围内。