📚 课程目录第4章性能瓶颈定位方法论

4. 性能瓶颈定位方法论

当业务方反馈“网络慢”时，最忌讳的做法是直接登录设备敲一堆 show 命令，然后凭经验猜。Arista 云网络的可观测性很强，但前提是排查者必须有一套稳定的方法论。本节介绍的分层排查法，核心思想是：把“网络慢”这个模糊现象，沿着数据包真实经过的路径，拆解为物理层、链路层、网络层、应用层四个可独立验证的层次，逐层缩小嫌疑范围，最后用 Arista 内置工具（show 命令、bash、tcpdump）把结论钉死。

为什么必须分层，而不是“一把梭”

一个典型的云网络故障可能同时涉及多个层次。例如：某台 Leaf 交换机上联端口光模块老化导致 CRC 错误（物理层），引发链路层重传；重传又让 TCP 拥塞窗口收缩（传输层），最终表现为应用层 HTTP 请求超时。如果只盯着应用层看，永远找不到根因；如果只查物理层，又可能漏掉配置错误。分层排查的价值在于：每一层都有明确的“健康判据”，只有当前层判据全部通过，才把注意力上移一层。这样既不会漏，也不会乱。

需要特别说明的是，分层排查不是“从下往上死板地走一遍”。实际排障中，如果现象已经明确指向某一层（例如只有某个 VLAN 不通），可以直接从该层切入，但必须回头确认下层没有隐藏问题。分层是检查清单，不是执行顺序的枷锁。

物理层：先确认“电和光”是干净的

物理层排查的目标只有一个：确认端口、光模块、线缆、供电没有产生误码。Arista 交换机上最直接的入口是 show interfaces 和 show interfaces counters errors。

Leaf1# show interfaces Ethernet1
Ethernet1 is up, line protocol is up (connected)
  Hardware is Ethernet, address is 001c.73a1.2b40
  Internet address is 10.0.1.1/31
  MTU 9214 bytes, BW 100000000 kbit/s
  5 minute input rate 2.31 Gbps, 5 minute output rate 1.87 Gbps
  ...
  Input errors: 0, Output errors: 0
  CRC: 1247, Frame: 0, Runts: 0, Giants: 0

Leaf1# show interfaces counters errors
Port       FCS    Align   Runts   Giants  TX Pause  RX Pause
Et1        1247   0       0       0       0         0
Et2        0      0       0       0       0         0
Et3        0      0       0       0       0         0

判据很明确：FCS/CRC 计数持续增长，说明链路存在误码，优先检查光模块收发光功率（show interfaces transceiver）、光纤跳线、端口协商速率。如果 RX Pause 或 TX Pause 持续增长，说明对端或本端出现了拥塞反压，这属于链路层与网络层交界的问题，需要结合队列统计进一步判断。物理层干净的标准是：错误计数在观察窗口内不增长，光功率在模块规格范围内。

链路层：确认“帧能完整到达对端”

链路层排查关注的是 MAC 地址学习、VLAN 标签、STP 状态、LACP 聚合状态。云网络中大量使用 MLAG 和 EVPN，链路层问题往往表现为“部分流量丢包”而非全断。

常用命令包括 show mac address-table、show vlan、show spanning-tree、show lacp neighbor。例如，当发现某台服务器流量时通时断，可以检查其接入端口的 MAC 是否在预期 VLAN 中稳定学习到，以及 MLAG 双活端口是否出现单边转发。

Leaf1# show lacp neighbor
Flags: S - Device is sending Slow LACPDUs, F - Device is sending fast LACPDUs
Port       Flags  State   LACPDUs  LACP Neighbor
Et5        SA     bndl    32768    001c.73a1.2b41
Et6        SA     bndl    32768    001c.73a1.2b41

如果 LACP 邻居状态不是 bndl，或者只有单端口处于转发状态，说明聚合链路没有真正形成，带宽和冗余都会受影响。链路层还有一个容易被忽略的点：MTU。Arista 默认 MTU 为 9214，如果中间某段链路 MTU 被改小，大包会被丢弃，表现为“小包通、大包不通”。可以用 show interfaces | include MTU 快速核对全路径 MTU 一致性。

网络层：确认“路由和转发路径正确”

网络层是云网络排障的主战场。排查目标包括：路由表是否有预期前缀、下一跳是否可达、ECMP 是否均衡、ACL 是否误杀、ARP/ND 是否正常。

第一步看路由：show ip route 10.20.30.0/24，确认前缀存在且下一跳正确。第二步看转发：show ip route summary 和 show ip hardware fib，确认软件路由已下发到硬件。第三步看流量实际走哪条路：Arista 支持 show ip route 10.20.30.5 detail 查看具体下一跳，也可以用 traceroute 或 show ip interface brief 辅助判断。

Leaf1# show ip route 10.20.30.0/24
Codes: C - connected, S - static, B - BGP
B E      10.20.30.0/24 [200/0] via 10.0.1.3, Ethernet3, 2d03h
                              via 10.0.1.5, Ethernet4, 2d03h

Leaf1# show ip hardware fib 10.20.30.0/24
Prefix              Next Hop        Interface
10.20.30.0/24       10.0.1.3        Ethernet3
10.20.30.0/24       10.0.1.5        Ethernet4

如果软件路由表有两条 ECMP，但硬件 FIB 只有一条，说明硬件资源或哈希配置有问题，流量会全部压到单条链路，造成局部拥塞。此时应检查 show platform fap 或 show hardware capacity 确认表项资源。网络层还有一个高频问题：ACL 或 QoS 策略误匹配。可以用 show ip access-lists 查看命中计数，确认是否有非预期流量被丢弃。

应用层：确认“协议交互和业务逻辑正常”

应用层排查不是去查服务器代码，而是确认网络设备对应用协议的处理是否正确。典型对象包括：TCP 握手是否完成、DNS 解析是否超时、HTTP 响应是否被中间设备改写、TLS 握手是否因 MTU 或时间同步失败。

这时 tcpdump 是最有力的工具。Arista 支持在交换机上直接抓包，并可通过 CPU 或镜像端口捕获。例如，怀疑某台服务器 TCP 重传严重，可以在 Leaf 上抓取该服务器所在 VLAN 的流量：

Leaf1# tcpdump -i Ethernet5 -nn -c 100 'host 10.20.30.5 and tcp port 443'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on Ethernet5, link-type EN10MB (Ethernet), capture size 262144 bytes
14:22:01.123456 IP 10.20.30.5.443 > 10.20.30.100.51234: Flags [.], ack 1, win 29200
14:22:01.123789 IP 10.20.30.100.51234 > 10.20.30.5.443: Flags [.], ack 1, win 65535
14:22:01.124012 IP 10.20.30.5.443 > 10.20.30.100.51234: Flags [P.], seq 1:1461, ack 1

如果看到大量 [TCP Retransmission] 或 [TCP ZeroWindow]，说明问题可能不在网络转发，而在服务器处理能力或接收窗口。如果看到 ICMP fragmentation needed，则回到网络层检查 MTU。应用层排查的关键是：用抓包结果区分“网络丢包”和“端系统处理慢”，避免把服务器问题误判为网络问题。

用 bash 把各层证据串起来

Arista EOS 底层是 Linux，bash 命令可以进入 Linux shell，使用 ip、ethtool、ss、cat /proc/net/dev 等工具做交叉验证。例如，ethtool -S et1 可以看到比 show 命令更细的驱动级计数，ip -s link show et1 可以快速查看收发丢包。这些信息与 show 命令互为补充，尤其在怀疑硬件或驱动问题时非常有用。

分层排查的实用口诀：物理看误码，链路看聚合，网络看路由，应用看抓包。每一层都要有“通过/不通过”的明确判据，不要凭感觉跳层。

分层排查路径示意

下图把四层排查的对象、工具和判据组织成一条从现象到根因的收敛路径。左侧是用户可见的“慢”，右侧是最终定位到的具体层次和证据。实际排障时，可以沿着箭头逐层验证，也可以根据现象直接切入某一层，但必须回头确认下层无隐患。

把方法落到一张排查记录表上

为了让分层排查可复现、可交接，建议每次排障都留下结构化记录。下表是一个可直接使用的示例模板，字段只保留与本节四层判据直接相关的内容。

层次	检查对象	关键命令	通过判据	本次结果
物理层	端口误码、光功率	show interfaces counters errors	FCS/CRC 在 5 分钟内不增长	Et1 FCS=1247 且持续增长 → 不通过
链路层	LACP、MAC、MTU	show lacp neighbor	所有成员口状态为 bndl	Et5/Et6 均为 bndl → 通过
网络层	路由、FIB、ACL	show ip route / hardware fib	软件路由与硬件 FIB 一致	ECMP 两条均在 FIB → 通过
应用层	TCP 重传、分片	tcpdump -i Et5 -nn	无 Retransmission / Frag needed	存在少量重传，与物理层误码吻合

这张表的价值在于：它把“我觉得是网络问题”变成了“物理层判据不通过，且应用层重传与误码计数在时间上吻合”。结论一旦落到具体层次和具体计数上，后续更换光模块、复测 FCS、再次抓包验证，就形成了一个完整的闭环。分层排查法不是让你多敲命令，而是让你每一次敲命令都有明确的验证目标。