企业官网建设流程全解析

如果有人找你排查交换机丢包，你登上去一看，CPU不高、链路带宽也不拥塞，但业务就是卡顿，最后在端口计数里发现rx_pause或者pause_frame在疯涨——十有八九，又是 PAUSE 帧流控在捣乱。PAUSE 帧这东西，搞网络的对它又爱又恨：它是 IEEE 802.3x 标准定义的链路层流控手段，在以太网交换机里用来解决缓冲区溢出丢包，但用不好就是故障源。这篇就把它讲透：它到底解决什么问题、帧长什么样、怎么配、踩过哪些坑，以及怎么排查。

适合谁看？做数据中心运维、园区网维护的工程师，以及刚接触交换机原理、想搞懂"流控"这个词背后机制的学习者。看完你能明白什么时候该开流控、什么时候千万别开，也能在下次看到pause frame计数飙升时知道从哪里下手。

1. 为什么需要流控：缓冲区溢出才是丢包的根因

1.1 从一次"神秘丢包"说起

先讲个我实际接过的案例。一台服务器 A 向另一台服务器 B 持续同步数据，中间过两台交换机。从 A 的网卡看，发送速率平稳；从 B 的网卡看，接收速率却有周期性掉坑，业务侧 TCP 重传不断。两端链路都不打满，端口 error 计数也没问题。最后我是在中间那台交换机上发现了一个细节：入方向端口没有任何丢包，但出方向端口间歇性出现discard。

为什么出方向会丢包？因为交换机的每一个端口都有自己的缓冲区（buffer），这个缓冲区不是无限的。当 A 向 B 发数据的瞬时速率超过了 B 端口能转发的速率，多余的报文就得先存在出端口的缓冲区里。缓冲区满了怎么办？没地方放，只能丢。

链路带宽明明有剩余，出端口速率也没到线速，为什么会瞬时慢？这就牵扯到另一个问题：网络设备对报文的处理不是匀速的，一个突发流量可能在极短时间内挤爆缓冲区。比如某个时刻 A 的网卡一口气把多个大包发出来，中间交换机查转发表、做 ACL 匹配、修改 VLAN Tag，这些动作需要时间，出端口排队一长，缓冲就撑爆了。类似开车进收费站，通道口处理速度跟不上，车流瞬间在闸机前排长队，队伍排到马路上就堵死了。

1.2 TCP 的拥塞控制为什么"远水救不了近火"？

很多人的第一反应是：TCP 不是有拥塞控制吗？丢包了会自动降速重传啊。这句话没错，但 TCP 是端到端的协议，它的反馈链路非常长。从 B 发现丢包，到 B 反馈 ACK，再到 A 降低发送速度，中间至少经过一个 RTT（往返时延），在数据中心里哪怕只有几百微秒，也已经足够让交换机缓冲区溢出好几轮了。

更重要的是，TCP 的拥塞控制是基于"丢包"或者"时延增加"来判断拥塞的，它根本看不到交换机内部缓冲区的水位。你不可能让 TCP 每毫秒都去查询一下交换机端口的队列长度，这个机制在协议栈上就不存在。所以数据链路层必须有一个更本地、更快速的保护机制，在缓冲区将要溢出时直接对上游设备喊停。

PAUSE 帧就是干这个的：当一台交换机的某个出端口缓冲区快要满了，它会向对端设备发送一个"暂停"信号，让对端在指定的时间内不要继续往这边发数据。等于在高速路口设了一个红绿灯，而不是等"终点站"发现堵车了再打电话让起点不要发车。

1.3 流控可以分为几类：别和 QoS 限速搞混

这里必须把概念理清楚，因为实际工作中很多人把"流控"说得很泛。广义上的流量控制有三类：

• 端到端流控：TCP 滑动窗口、拥塞控制，负责的是"从源端到目的端"的流量节奏。
• 链路层流控：PAUSE 帧机制，负责的是"两个直接相连设备之间"的流量节奏。
• 网络层/设备级 QoS 限速：在交换机上用令牌桶、队列调度实现限速和整形，本质上是"主动丢包/缓存"来平滑流量。

PAUSE 帧属于第二类，它和 QoS 限速有本质区别：QoS 是在设备内部实现了"限速、标记、调度"，报文最终还是会被尽力转发；而 PAUSE 帧是设备向对端设备发出"喘息"命令，直接由对方配合暂停发送。打个比方，QoS 限速像洒水车给道路洒水，车流还继续走，只是速度受控制；PAUSE 帧则直接拉起闸门，让对向车流停下来等。

实际配置中，很多人会把交换机的flow-control命令和端口的rate-limit搞混。前者是 802.3x 链路层流控，后者是端口限速，两者可以同时存在，但作用机制完全不同。后面说配置的时候我会再强调。

1.4 缓冲区阈值：PAUSE 帧从什么时候开始触发？

PAUSE 帧不是"发现缓冲区满了"才发，那样已经晚了，报文早就丢了。真正的机制是交换机内部为每个端口设置了两个水位线：

• 高水位（high watermark）：当缓冲区占用超过这个值，端口就向对端发送 PAUSE 帧，要求暂停一段时间。
• 低水位（low watermark）：当缓冲区占用降到低水位以下，端口再发一个 PAUSE time 为 0 的帧，表示"恢复发送"。

这种设计实际上是一个带滞回特性的开关，防止缓冲区在临界点附近反复触发流控，导致链路在"暂停-恢复-暂停"之间震荡。就好比家里的空调设定 26 度启动、25 度停止，中间留了一个温差缓冲区，不会让压缩机频繁启停。

需要特别提醒的是：不同厂商、不同芯片的交换机对这两个水位线的默认值差异很大。有些芯片只要缓冲区占用超过 1/8 就开始发 PAUSE，有些则要到 3/4 才触发。所以同样两台交换机，一个丢包一个不丢包，可能不是配置差异，而是芯片的水位线算法不同。

2. PAUSE 帧长什么样？拆开协议看细节

2.1 以太网帧结构

PAUSE 帧是一种MAC 控制帧，不是普通的 IP 数据包。它的目的 MAC 地址是一个固定的组播地址，在 IEEE 802.3x 标准中定义为01:80:C2:00:00:01。这个地址有个特点：它不会跨交换机转发，任何一台标准交换机收到目的地址是它的帧，都只会交给本地的 MAC 控制子层处理，而不会查转发表转发出去。

帧格式大致如下：

• 目的 MAC：01:80:C2:00:00:01
• 源 MAC：发送端口的 MAC 地址
• EtherType：0x8808，表示这是一个 MAC 控制帧
• MAC Control Opcode：0x0001，表示这是一个 PAUSE 操作
• MAC Control Parameters：2 字节的pause time字段，取值范围 0~65535

这里出现了两个值得记住的十六进制数：0x8808和0x0001。后面用 Wireshark 抓包时，过滤条件写eth.type == 0x8808就能把 PAUSE 帧全部筛出来，然后看 opcode 是否是 1。

2.2 一个关键的概念：pause quanta（暂停量子）

PAUSE 帧里那个 2 字节的pause time，单位不是"微秒"，也不是"毫秒"，而是一个叫quanta的量。IEEE 标准定义：1 quanta 等于 512 bit time 的发送时间。什么叫 bit time？就是发送 1 bit 数据所需的时间，直接由链路速率决定。

这样设计的初衷，是因为 PAUSE 帧需要兼容不同速率的以太网。标准化"512 bit time"而不是固定时间，是为了让流控的暂停时长和链路速率对应起来。

每类速率下的实际时间可以先算出来。以千兆端口为例，1 bit time = 1 / 1Gbps = 1ns，那么 1 quanta = 512ns。如果 pause time 字段取最大值 65535，则最大暂停时长约为 65535 × 512ns，大概 33.5ms。在万兆端口上，1 bit time = 0.1ns，1 quanta = 51.2ns，最大暂停时长约为 3.35ms。

有意思的是，在万兆链路上，PAUSE 帧本身的传输时间、对端反应时间已经占掉了不少比例，所以如果频繁触发，链路有效带宽会显著下降。这也是后面要讲的"PAUSE 帧不要乱开"的原因之一。

2.3 暂停和恢复的完整握手

完整流程大致如下：

1. 交换机端口 A 的缓冲区占用超过高水位。
2. 端口 A 向对端口发送 PAUSE 帧，携带pause time = T（T 是当前计算出的 quantum 数，最多 65535）。
3. 对端收到后，在这个端口上停止发送新报文，但已经在发送队列里、正在发送的报文会继续发完。
4. 缓冲区占用回落到低水位以下后，端口 A 再送一个 PAUSE 帧，其中pause time = 0。
5. 对端收到pause time = 0的帧，立即恢复正常发送。

这个过程里有一个容易忽略的细节：标准规定，pause time = 0是一个显式的"恢复"信号，而不是"继续暂停 0 时间"。如果 A 不主动发这个恢复帧，对端会一直暂停到pause time递减到 0 后自动恢复。也就是说，PAUSE 帧的生效时间是"内核里的一个计时器"，只要计时器没到 0，发送行为一直暂停。

所以实际调试中，如果怀疑某个端口的 PAUSE 机制异常，除了看有没有收到 PAUSE 帧，还要看这个暂停计时器有没有反复被刷新。有些交换机接口统计里会单独显示 pause 帧的收发计数，但不会显示"当前暂停了多少毫秒"，这时候就要上抓包工具看相邻 PAUSE 帧之间的间隔。

2.4 半双工背压：PAUSE 帧的"爷爷辈"

严格来说，PAUSE 帧只用于全双工链路。在半双工以太网时代，设备不能同时收和发，所以当接收端缓冲区满了，它没法"发送"任何数据，只能通过制造冲突来阻止对端发送，这种机制叫背压（backpressure）。实现方式通常是持续发送一个拥塞信号（比如延长载波侦听时间或发送冲突信号），让对方认为链路忙，从而退避。

现在半双工已经很少见，除了少数低速链路和某些特殊场景，基本上所有交换机、服务器网卡都是全双工。但很多交换机的端口配置里仍然能看到flow-control同时支持半双工背压和全双工 PAUSE，命令行里常常用backpressure表示半双工模式。实际配置中，如果端口是强制全双工，半双工背压配置是无效的，这点要注意。

3. 实操配置：华为、H3C 交换机的流控命令与验证

3.1 华为交换机配置命令

华为交换机（以常见如 S5700/S6700 系列为例）端口下开启流控的命令非常简单：

system-view interface GigabitEthernet 0/0/1 flow-control enable

关闭流控：

interface GigabitEthernet 0/0/1 undo flow-control enable

这里有一个比较隐蔽的坑：不同版本的华为 VRP 平台，对"流控"的命令命名有差异。早期版本用flow-control，部分版本支持flow-control auto，让端口自动协商流控能力；一些新平台则用undo flow-control直接关闭。如果你敲flow-control enable提示错误，用?看看这个命令下有哪些参数，别死磕。

华为交换机上查看端口流控状态：

display interface GigabitEthernet 0/0/1

在回显信息里重点找这一行，类似：

Pause frame: RX: 12345 TX: 0

RX表示这个端口收到了多少 PAUSE 帧，TX表示从本端口发出了多少 PAUSE 帧。如果RX计数快速增长，说明对端设备在要求你暂停发送；如果TX快速增长，说明本端在要求对端暂停。这个计数是最直接的判断依据。

如果你想确认某个口到底有没有在发 PAUSE 帧，还可以用命令：

display flow-control

它会列出各端口流控开关状态，但注意，它未必显示每个端口的收发 PAUSE 帧计数，所以更准确的做法还是用display interface查看。

3.2 H3C 交换机配置命令

H3C 交换机（Comware 平台）的配置思路类似，只是命令风格略有差异：

system-view interface GigabitEthernet 1/0/1 flow-control enable

Comware 平台里，这个命令同时控制收发两个方向。H3C 还支持更精细的配置：

flow-control rx-remind

这个命令用于设置某个端口接收 PAUSE 帧时是否上送 CPU 处理，默认情况下端口直接处理 PAUSE 帧，不上送 CPU。如果你在排查风暴时发现 CPU 很高，可以尝试把部分端口的 PAUSE 帧不上送 CPU，减少对控制面的冲击。这一点在应对"交换机死机"问题时非常有用。

查看 H3C 交换机端口 PAUSE 计数：

display interface GigabitEthernet 1/0/1

回显中通常会有Input部分下面的Pause frame计数，以及Output部分下面的Pause frame计数。H3C 还有一条命令可以看某个端口收到和发出的流控帧总数：

display packet-filter statistics interface GigabitEthernet 1/0/1

不过这条命令和 ACL 过滤关联，不是专门看 PAUSE 帧的，日常用得不多，大家知道即可。

3.3 验证流控有没有生效：一个可操作的小实验

在实验室里要验证流控是否生效，可以搭一个简单拓扑：PC 直连交换机端口 1，交换机端口 1 再连一个上行端口。然后从 PC 灌流量，同时人为制造一个瓶颈，比如把上行端口限速到低于 PC 发包速率。用 iPerf3 打 UDP 流，观察交换机的 PAUSE 帧计数：

iperf3 -c 192.0.2.10 -u -b 1G -t 30

如果测试机和对端都是千兆口，但中间有个百兆瓶颈，理论上交换机出端口会缓冲积压，一旦超过高水位就会向 PC 发 PAUSE 帧。这时的表现是：交换机端口上TX的 PAUSE 计数开始增长，PC 的网卡上能看到tx_pause或者pause计数增长，但 PC 侧 iPerf 统计的发送速率仍然可能是 1Gbps，因为它已经发出了很多报文，实际的"暂停"表现在交换机不会继续从 PC 口取报文，PC 发送缓冲区会逐渐占满。

如果你的 PC 网卡是 Linux，还可以用ethtool -S eth0 | grep -i pause查看：

tx_pause: 1523 rx_pause: 0

rx_pause为 0 而tx_pause增长，说明本机的网卡在配合对端暂停。如果rx_pause一直增长，说明网卡在要求交换机少发数据。这两个计数是非常关键的证据，比交换机上的计数器更贴近实际链路。

3.4 配置要点：两端必须同时支持

PAUSE 流控能否生效，关键前提是链路两端设备都支持 802.3x 并且都开启的。如果交换机开了流控，但服务器网卡没有开启相应的流控协商，效果会很尴尬：交换机发出的 PAUSE 帧对方根本不理，缓冲区该溢出还是溢出，丢包依旧。

实际环境中，服务器网卡的流控默认经常是关闭的，尤其是一些数据中心服务器，操作系统里会专门设置disable flow control。所以不要以为交换机上flow-control enable就万事大吉了，一定要检查对端。可以通过ethtool -p eth0确认物理链路，或者用ethtool -a eth0查看网卡流控参数：

Advertised pause frame use: No Received pause frame use: No

这说明网卡不支持或者没有开启流量控制。需要开启时，用ethtool -A eth0 rx on tx on让网卡启用 PAUSE 帧收发，但要评估是否真的需要，后面说坑的时候会展开。

光模块场景下也要特别注意。很多光模块对 PAUSE 帧的透传和响应表现不同，一些廉价模块可能根本不转发 PAUSE 帧，交换机发出去了，光模块直接丢弃。所以遇到跨光模块链路时，如果怀疑流控异常，可以先换一对短网线直连验证，排除光模块因素。

4. 实战中的坑：PAUSE 风暴、交换机死机和 PFC 的区别

4.1 PAUSE 风暴：当一切流量都停了

PAUSE 帧设计的初衷是"局部暂停"，但它有个副作用：如果某个端口频繁发送 PAUSE 帧，对端的暂停计时器会被不断刷新，暂停时间会被无限拉长，最终表现为"链路看起来是 link up 的，但流量完全不动"。这种状态我通常叫它PAUSE 风暴。

典型场景是两台存储设备之间通过交换机互连，存储设备的某个端口因为故障或者配置问题，不停地向交换机端口发送 PAUSE 帧。此时交换机的出端口计数器会发现rx_pause在飞速上涨，但output bytes几乎停滞。更坑的是，很多交换机不会自动上报这种状态，你远程登录设备看接口状态还是 up，物理链路也没有任何 error，但业务就是不通。

排查思路如下：

1. 先看所有端口的rx_pause和tx_pause计数，找到增长速度异常的那个口。
2. 用抓包工具抓那个端口，确认 PAUSE 帧的来源速率。如果每秒钟有几百上千个 PAUSE 帧，说明链路已经在持续拥塞。
3. 找到源头后，优先处理源端设备，比如把存储设备的流控关闭，或者把某个故障网卡的流控强制关闭再观察。

经验之谈：正常局域网里端口的 PAUSE 帧计数应该是稳定且极低的，如果明显异常，背后一定有问题，不要只盯着"接口 up"放松警惕。

4.2 交换机死机、SSH 连不上：流控与控制面

和 PAUSE 帧相关的另一个故障是交换机"死机"或者"SSH 连不上"。不少工程师在交换机上开了流控，然后接了一个不停广播的终端设备，结果整机 CPU 飙升，telnet/SSH 都登录不上去。

为什么？因为某些交换机的端口收到大量 PAUSE 帧后，默认会把这些帧交给 CPU 处理，由 CPU 维护暂停状态。如果你的交换机的控制面 CPU 被 PAUSE 帧淹没，它就没有时间去处理 SSH 登录、SNMP 请求、BGP 邻居保活这些正常控制报文。表现出来就是"交换机活着，但管理通道断了"。

这时候你有两个选择：

• 在端口下配置不上送 CPU。不同厂商命令不同，华为可以用undo flow-control或者在端口上配置对控制面的保护，比如car限速。H3C 的flow-control rx-remind就是用来做这件事的。
• 先把连着异常设备的端口手动 shutdown，恢复管理后慢慢排查。

还有一个隐藏很深的问题：如果你用 SSH 连交换机时发现完全无响应，但 console 口还能登录，进去后第一件事就是看display cpu-usage和接口 PAUSE 计数，十有八九能找到答案。

4.3 镜像抓包实战：用交换机镜像抓 PAUSE 帧

排查 PAUSE 帧问题时，抓包是最直观的方式。交换机上配置端口镜像，把疑似出问题的端口流量复制到抓包端口。

华为交换机配置端口镜像：

observe-port 1 interface GigabitEthernet 0/0/2 interface GigabitEthernet 0/0/1 port-mirroring to observe-port 1 inbound

H3C 配置端口镜像：

mirroring-group 1 local interface GigabitEthernet 1/0/1 mirroring-group 1 mirroring-port both interface GigabitEthernet 1/0/2 mirroring-group 1 monitor-port

然后在抓包电脑上用 Wireshark 抓包，过滤器填eth.type == 0x8808。如果看到源 MAC 是某台设备、目的 MAC 是01:80:C2:00:00:01的帧，那就是 PAUSE 帧。注意观察两个字段：

• opcode是 1 表示这是 PAUSE。
• pause_time字段的值，如果大量是 65535，说明对端在拼命要求你暂停；如果交替出现 0 和 65535，说明链路在反复震荡，典型的水位线配置不当。

这里有个小技巧：抓包时最好连交换机管理口也做一个镜像，因为 PAUSE 帧不上送 CPU 时，普通数据端口抓不到完整会话，但管理口流量小，不容易被干扰。不过在实际实验中，直接把业务口镜像到 PC 抓包口是足够的。

4.4 死锁现象：当 PAUSE 帧和广播风暴同时出现

再讲一个让我印象深刻的案例。某企业内网一台服务器网卡故障，不停发出大量广播包。交换机的某个上联口缓冲区被打满，触发了 PAUSE 帧机制，结果整个上联链路上的交换机全部开始"等暂停"，数据转发效率急剧降低。从逻辑上看，广播风暴导致缓冲区满，缓冲区满导致 PAUSE 帧，PAUSE 帧导致暂停，暂停导致有效带宽缩小，有效带宽缩小又加剧广播包的占比，形成了一个正反馈死循环。

解决这类问题时，不能只关流控，要先把广播源头找到。通常在交换机上用display l2 multicast或者查看端口广播报文计数，找出广播率最高的端口，把那个端口隔离或 shutdown，问题马上缓解。流控在这个场景里反而起了"帮凶"作用，所以我的建议是：在正常的二层接入交换机上，默认不建议全局开启流控，只有在明确有突发流量场景、且对端设备支持配合时才开。

4.5 和 PFC 的区别：别把 802.3x 和 802.1Qbb 混为一谈

现在数据中心交换机上经常会看到一个叫PFC（Priority-based Flow Control，基于优先级的流控）的协议，很多人会把它当成 PAUSE 帧的升级版。实际上它们不是一回事，但确实有关系。

标准 802.3x 的 PAUSE 帧是无差别暂停：它一发，整个端口上所有队列全部暂停发送。而 PFC 在以太网帧头里增加了 802.1p 优先级字段，可以在一个端口内为不同的优先级队列分别做暂停。比如你把存储流量打上优先级 3，把普通业务流量打上优先级 0，当拥塞发生时，PFC 只会暂停优先级 3 的队列，不影响优先级 0 的普通业务。这让 PFC 在无损以太网和 RoCE（RDMA over Converged Ethernet）场景里成为关键技术。

但在配置上，PFC 通常需要在端口上开启priority-flow-control命令，而不是简单的flow-control enable。两者有时可能同时存在，有时会冲突，要看设备实现。华为交换机的命令大概长这样：

interface GigabitEthernet 0/0/1 priority-flow-control enable priority-flow-control no-drop dot1p 3

H3C 在 Comware 9 平台上的命令也类似：

interface GigabitEthernet 1/0/1 priority-flow-control enable priority-flow-control no-drop dot1p 3

不熟悉的人容易把flow-control和priority-flow-control都开了，结果发现端口行为变得很奇怪：某些业务流量频繁中断，某些完全不受影响。实际上就是两种机制叠加后，暂停信号的处理产生了竞争。我的经验是：在非无损以太网场景里，不要同时开经典 PAUSE 和 PFC，选一个即可，否则坑你到怀疑人生。

5. 常见问题速查表

许多问题其实在配置阶段就能避免。几个实用心得：

• 默认建议关闭流控：在标准以太网环境里，TCP 的重传机制已经足够处理丢包，链路层再叠加 PAUSE 帧反而可能放大故障。你可以在接入交换机关掉流控，只在存储网、RoCE 这类需要无损链路的专用网络中开启。
• 不要用 PAUSE 帧解决"带宽不足"：如果链路长期拥塞，开流控只会把问题转移为"间歇性全停"，真正的解法是升级带宽或做负载分担。
• 光模块与镜像口排查优先：遇到流控相关故障，先用镜像抓包，再用display interface的 PAUSE 计数辅助判断，双管齐下效率最高。

6. 最后再分享一个小技巧：应急时手动制造"暂停"

有一次线上业务抽风，某个视频服务器的发送速率突然飙高，把交换机到存储之间的端口打满，我要临时让它停下来，但厂商不给远程重启的权限。当时紧急操作是在交换机上直接把连接服务器的端口流量镜像到一个空端口，并临时配了一条 ACL 丢弃所有数据，瞬间把故障流量拦住。虽然这个操作和 PAUSE 帧本身无关，但思路是一样的：与其等故障协议自己收敛，不如在网络设备上主动做隔离。

在抓 PAUSE 帧时我还有个习惯：先清零计数器再看增长，这样能快速定位异常源。华为交换机的命令是reset counters interface GigabitEthernet 0/0/1，H3C 是reset counters interface GigabitEthernet 1/0/1。清零后观察 5 分钟，哪个口计数涨得最猛，哪个口就是重点排查对象。这个方法我用了很多年，简单粗暴但极其有效。

PAUSE 帧流控就是这样一把双刃剑。懂了原理，你就能在关键时刻判断它到底是在帮忙还是在添乱。希望这篇实战拆解能帮你在下次遇到类似的"高深问题"时，少走一些弯路。