📚 课程目录第4章端口与链路层性能调优

4. 端口与链路层性能调优

端口与链路层是交换系统性能的物理基础。上层再精细的队列调度和拥塞控制，如果底层链路本身协商不当、FEC 模式错配或 LAG 哈希失衡，都会在源头形成瓶颈。本章围绕端口速率协商、FEC 模式选择、LAG 哈希算法配置、链路故障切换时间优化四个关键点展开，并给出一个可复现的调优案例。

一、端口速率协商：先确认"两端一致"

现代数据中心交换机端口普遍支持 10G/25G/40G/50G/100G/200G/400G 多速率，速率协商的本质是两端 PHY 通过自协商或强制配置达成一致的编码与速率。实践中常见两类问题：一是两端速率不匹配导致链路 down 或降速运行；二是自协商成功但实际协商到低于预期的速率，例如 25G 端口协商成 10G。

排查时先看端口状态与协商结果。以 Broadcom 平台常见的诊断命令为例：

# 查看端口速率与协商状态
show interfaces status
# 查看 PHY 层协商细节
show interfaces phy Ethernet0
# 强制指定速率（两端必须一致）
configure interface Ethernet0 speed 25000

判断依据很直接：show interfaces status 中显示的 Speed 应与规划一致，且两端一致；若出现 Speed: 10000 而规划为 25G，需检查对端是否强制 10G、光模块是否支持 25G、DAC 线缆是否匹配。速率协商是"两端共同决定"的过程，单侧强制、对侧自协商往往能成功，但单侧强制 25G、对侧强制 10G 必然失败。

二、FEC 模式选择：在误码与延迟之间取舍

FEC（前向纠错）通过在发送端加入冗余校验、接收端纠错，降低高速链路的误码率。25G/50G/100G 及以上链路通常必须启用 FEC，否则 BER 无法满足要求。常见模式包括：

RS-FEC (528,514)：用于 25G/100G 的 Clause 108，纠错能力强，引入约 100ns 级延迟。
RS-FEC (544,514)：用于 50G/200G/400G 的 Clause 91，纠错能力更强。
FC-FEC / BASE-R FEC：用于 25G 的 Clause 74，延迟较低但纠错能力弱。
无 FEC：仅适用于短距、低误码场景，如机柜内 DAC。

选择原则是"链路越高速、距离越长、误码风险越高，越需要强 FEC"。但 FEC 会引入额外延迟，对延迟敏感的存储或 HPC 流量，可在短距 DAC 场景下评估关闭 FEC 或使用低延迟 FEC。两端 FEC 模式必须匹配，否则链路无法 up 或出现大量 CRC 错误。配置示例：

# 设置端口 FEC 模式
configure interface Ethernet0 fec rs
# 查看 FEC 统计与纠错情况
show interfaces counters fec Ethernet0

观察 show interfaces counters fec 中的 corrected/uncorrected 计数：corrected 持续增长说明链路误码在 FEC 纠错范围内，尚可接受；uncorrected 增长则说明误码超出纠错能力，需检查光功率、连接器或更换模块。

三、LAG 哈希算法配置：让流量真正分散

链路聚合（LAG）把多条物理链路捆绑成一条逻辑链路，提升带宽并提供冗余。但 LAG 的带宽能否被充分利用，取决于哈希算法能否把流量均匀分散到各成员链路。哈希通常基于报文的五元组（源/目的 IP、源/目的端口、协议）或二层字段（源/目的 MAC、VLAN）。

关键认知：同一条流只能走一条成员链路。如果流量中大量是"同一对 IP、同一对端口"的大象流，哈希再均匀也无法分散，因为每条流被固定映射到一条链路。此时需要调整哈希字段，例如引入源端口或使用更细粒度的哈希。配置示例：

# 配置 LAG 哈希算法（示例：基于 L3/L4 五元组）
configure port-channel hash-algorithm layer3 layer4
# 查看各成员链路的流量分布
show port-channel load-balance Ethernet0

判断 LAG 是否均衡，最直接的方法是查看各成员链路的收发字节数。若某条成员链路流量明显高于其他，说明哈希分布不均，可尝试切换哈希字段或调整流量结构。需要强调的是，哈希均衡是"统计意义上"的，单条大象流无法被拆分，这是 LAG 的固有局限。

四、链路故障切换时间优化

LAG 的冗余价值体现在成员链路故障时能快速切换。切换时间由故障检测时间和重新哈希时间决定。传统方案依赖链路状态变化触发切换，检测时间受 PHY 层影响；优化手段包括：

启用 BFD（双向转发检测）实现毫秒级故障检测，而非依赖路由协议慢收敛。
缩短 LACP 超时时间，从 long（90s）改为 short（3s），加快成员链路状态感知。
确保硬件支持快速重哈希，故障后剩余链路立即承接流量。

# 配置 LACP short timeout
configure interface Ethernet0 lacp timeout short
# 启用 BFD 检测
configure interface Ethernet0 bfd interval 300 min-rx 300 multiplier 3

BFD 的 interval 300 表示每 300ms 发送一次检测报文，multiplier 3 表示连续 3 次未收到即判定故障，理论检测时间约 900ms。实际切换时间还需加上重哈希和转发表更新耗时，通常可控制在 1s 以内。

五、实际调优案例

某数据中心两台交换机之间使用 4×25G LAG 互联，规划总带宽 100G。运维发现业务高峰期实际吞吐仅约 40G，且成员链路流量分布为 25G/10G/3G/2G，严重不均。

排查过程：先确认端口速率与 FEC 均正常，排除物理层问题；再查看 LAG 哈希配置，发现默认基于二层 MAC 哈希，而该场景流量以 IP 存储流量为主，源/目的 MAC 集中在少数几对，导致哈希集中。调整为基于 L3/L4 五元组哈希后，流量分布改善为 25G/25G/24G/23G，总吞吐提升至约 95G。

随后进行故障切换测试：手动 down 掉一条成员链路，观察业务中断时间。初始配置下切换耗时约 2.5s，业务出现明显丢包。启用 LACP short timeout 并配置 BFD 后，切换时间降至约 800ms，丢包显著减少。最终该链路在高峰期稳定运行，带宽利用率超过 90%。

调优顺序建议：先确保速率与 FEC 两端一致，再优化 LAG 哈希分布，最后压缩故障切换时间。物理层不一致时，上层任何优化都无意义。

总结来看，端口与链路层调优的核心是"一致性"与"均衡性"：速率和 FEC 必须两端一致，LAG 哈希要尽可能让流量均衡，故障切换要尽可能快。三者共同决定了链路层能否为上层提供稳定、高吞吐、低中断的传输基础。