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

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

在大型网络中，接口与链路层是性能问题最先暴露的地方。很多时候，业务侧反馈“丢包、时延抖动、吞吐上不去”，根因并不在路由协议或防火墙策略，而在接口 MTU 不一致、流控配置不当、LAG 哈希极化或链路误码。本章围绕 GE、10GE、40GE、100GE、400GE 这几类常见接口，讨论如何从链路层把性能调优做到位。

一、MTU：先统一，再谈性能

MTU 决定单个帧能承载的最大有效载荷。Juniper 设备默认接口 MTU 通常为 1514 字节（含二层头），而 MPLS、VXLAN、GRE 等封装会额外增加开销。如果核心链路 MTU 小于封装后报文长度，就会出现“小包能通、大包被丢”的典型现象。调优的第一步不是盲目加大 MTU，而是先确认整条路径的 MTU 一致性。

以 100GE 骨干链路承载 VXLAN 为例，VXLAN 封装增加 50 字节（外层 IP 20 + UDP 8 + VXLAN 8 + 内层以太网 14），若内层业务报文为 1500 字节，则外层需要至少 1550 字节。此时应把物理接口和 LAG 接口的 MTU 统一设置为 1600 或 9000（Jumbo），并确保沿途所有设备一致。配置示例如下：

set interfaces et-0/0/0 mtu 9216
set interfaces ae0 mtu 9216
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 unit 0 family inet mtu 9000

注意：物理接口 MTU 与逻辑单元 MTU 是两个层次。物理接口 MTU 影响二层帧长，unit 下的 family inet mtu 影响三层报文长度。两者需要匹配，否则会出现“接口 up、协议 up、大包不通”的隐蔽故障。建议在变更前用 show interfaces extensive 查看当前 MTU，并用 ping 指定大小做端到端验证：

ping 10.0.0.2 size 9000 do-not-fragment count 10

如果 9000 字节不通而 1500 字节通，说明路径中某段 MTU 不足，应逐跳排查，而不是只在两端调大。

二、流控：谨慎开启，避免“拥塞扩散”

流控（Flow Control）通过 PAUSE 帧让对端暂停发送，防止接收缓冲区溢出。但在大型网络中，流控是一把双刃剑：它可能把局部拥塞扩散到整条链路，甚至引发 Head-of-Line 阻塞。对于 10GE 及以下接口，若服务器或存储设备确实需要，可谨慎开启；对于 40GE/100GE/400GE 骨干链路，通常建议关闭流控，依靠上层拥塞控制（如 TCP）和 QoS 调度来管理。

Juniper 接口流控配置如下：

set interfaces et-0/0/0 ether-options flow-control
set interfaces et-0/0/0 ether-options no-flow-control

判断是否需要流控，可以观察接口统计中的 pause 帧计数：

show interfaces et-0/0/0 extensive | match "PAUSE"

如果 pause 帧持续增长，说明链路存在瞬时拥塞。此时应优先检查 LAG 成员带宽是否均衡、QoS 队列是否合理，而不是简单依赖流控“压住”发送端。

三、LAG/LACP 哈希：让流量真正分散

链路聚合（LAG）把多条物理链路捆绑成一条逻辑链路，但聚合后的带宽能否被充分利用，取决于哈希算法是否把流量均匀分散到各成员链路。Juniper 默认哈希通常基于源/目的 MAC、IP 和端口。如果网络中大量流量是“单源单目的”的大象流，哈希结果可能只落在一条成员链路上，形成极化。

优化方向有两个：一是调整哈希字段，二是调整哈希算法。对于 IP 骨干，建议启用基于 L3/L4 的哈希：

set forwarding-options hash-key family inet layer-3
set forwarding-options hash-key family inet layer-4
set forwarding-options hash-key family inet ipv6 layer-3
set forwarding-options hash-key family inet ipv6 layer-4

对于 100GE/400GE 高带宽场景，还可以启用弹性哈希（resilient hashing），在成员链路增减时减少流量重分布：

set chassis fpc 0 pic 0 adaptive-services service-package extension-provider
set forwarding-options enhanced-hash-key resilient-hash

验证哈希是否均衡，最直接的方法是查看各成员链路的流量计数：

show interfaces ae0 extensive | match "Input bytes"
show interfaces et-0/0/0 extensive | match "Input bytes"
show interfaces et-0/0/1 extensive | match "Input bytes"

如果各成员链路流量差异超过 20%，说明哈希极化明显，应调整哈希字段或检查是否存在单一巨流。

四、误码排查：从统计到物理层

高速接口对误码非常敏感。400GE 在单纤上使用 PAM4 调制，信噪比余量更小，一旦光模块老化、光纤脏污或连接器松动，就会产生 CRC 错误、FCS 错误甚至链路震荡。排查误码应遵循“先看统计、再查光层、后换硬件”的顺序。

第一步，查看接口错误计数：

show interfaces et-0/0/0 extensive | match "CRC|FCS|Align|Symbol"

如果 CRC 或 FCS 持续增长，说明物理层存在误码。第二步，检查光模块收发光功率和温度：

show interfaces diagnostics optics et-0/0/0

重点关注 Rx Power 是否低于灵敏度门限、Tx Power 是否正常、Temperature 是否过高。第三步，通过更换光纤、清洁连接器、更换端口或光模块进行交叉验证。若更换后误码消失，即可定位为物理层故障。

对于 100GE/400GE，还可以启用 FEC（前向纠错）统计来观察纠错前后的误码率：

show interfaces et-0/0/0 extensive | match "FEC"

如果 FEC 纠正的码字数量持续上升，说明链路已处于“亚健康”状态，即使业务暂时未丢包，也应提前安排维护。

五、调优检查清单

综合以上内容，接口与链路层调优可按以下清单执行：

MTU：确认物理接口与逻辑单元 MTU 一致，端到端 ping 大包验证。
流控：骨干链路建议关闭，接入服务器按需开启，观察 PAUSE 帧计数。
LAG/LACP：启用 L3/L4 哈希，高带宽场景启用弹性哈希，定期检查成员流量均衡度。
误码：定期采集 CRC/FCS/FEC 统计，结合光功率和温度判断链路健康度。

建议把上述检查项纳入日常巡检脚本，对 100GE/400GE 链路每周采集一次误码和光功率数据，提前发现劣化趋势。

接口与链路层调优没有“一招鲜”，关键在于把 MTU、流控、哈希和误码四条线同时管住。只有链路层稳定、均衡、无隐性丢包，上层的路由收敛、QoS 调度和容量规划才有可靠的基础。