暂停帧对网络连接的潜在影响是什么？
适用于
ONTAP 9
解答
以太网流量控制的用途：
以太网流量控制是一种机制，它允许遇到性能瓶颈的网络设备请求相邻设备停止传输。以太网流量控制定义了一种通常称为“暂停”帧的以太网数据包。它们只能在直接连接的设备之间进行交换、并且只能在以太网（ DataLink ）层中定义。因此、以太网暂停帧不与 IP 、 TCP 、 NFS 、 CIFS 或任何其他更高级别的协议相关联、也不能与这些帧相关联。
如果没有以太网流量控制、如果接收设备无法像发送设备一样快速处理信息、最终必须开始丢弃传入数据。这迫使传输客户端必须重新传输，并可能由于一些原因导致痛苦的延迟。
通过以太网流控制、接收方可以请求传输设备“暂停”一段时间、尝试避免这些丢弃。在某些情况下，这可以实现更高效的网络传输。但是，以太网流量控制在防止性能问题方面并不总是有效。在某些情况下（通常很少见）、以太网流量控制比它们为防止重新传输而导致的性能影响更大。
注：以太网流控制在 1 Gbps 或更快的设备上将是常见的。即使不支持以太网流量控制规范、也可以在更现代的 100 Mbps 设备上找到该规范。
示例：
假设我们有一个具有存储控制器、交换机和客户端计算机的基本网络。此外、假设存储控制器配置为发送以太网流量控制数据包、交换机配置为在存储控制器插入的接口上接收（侦听）以太网流量控制数据包。最后，假设客户机根本不配置为支持以太网流量控制。请注意，交换机为每个接口设置了以太网流量控制（存储控制器所插入接口的一个设置、客户端所插入接口的设置可能不同）。
停止 / 暂停流量：
在这种情况下、存储控制器现在可以向交换机发送暂停帧。如果存储控制器到达无法像交换机发送信息那样快速处理信息的位置、则现在允许存储控制器向交换机发送暂停帧 (Xoff) 。当交换机收到暂停帧时，它将停止传输。交换机现在应开始保留（队列）需要短时间发送到存储控制器的流量。存储控制器现在可以处理以前收到的数据。
恢复流量：
每个 PAUSE/XOFF 帧都包含一个值（称为“ Quanta ”）、该值要求相邻设备在特定时间段内停止传输。传输器（本例中为交换机）在该时间到期时、或接收到来自接收器的不同以太网流量控制数据包（本例中为存储控制器）时、预期会恢复传输。根据 IEEE 标准、交换机应根据广达值和接口速度的组合来评估广达值并保持“暂停”状态。但接口应保持“暂停”状态的时间取决于传输设备的固件，因此可能不会遵循此规则。
计算接口预期保持暂停的时间：
命令输出中将显示暂停帧或 XOFF 帧ifstat -a -v。
在 10 Gbps 中，ifstat –a该命令可能会列出“暂停”帧；在 1 Gbps 中，它通常会被列为 XOFF 和 XON 。
暂停帧包括请求的暂停时间，其格式为两字节无符号整数（ 0 到 65535 ）、称为“ Quanta ”。此数字是请求的暂停持续时间。
- 每个“ Quanta ”等于 512 位。
- “位时间”定义为发送比特数据所需的秒数。由于接口的额定值为“每秒位数”，因此“位时间”是接口线路速度的逆函数。
对于 1 Gbps （ 1,000,000,000 bps ）接口、 1
Gbps 链路的“位时间”为 1/1 、每位为 1,000,000,000 秒、接口停止传输的最大时间为：
最大广达值 * 512/(10^9) =65535*512/10000000=0.03355392 秒 =33.55 毫秒。
对于 10 Gbps 、接口停止传输的最长时间应为
： 65535 *512/10^10=3.355 毫秒
对于支持该协议的 100 Mbps 接口、 100 Mbps 接口应暂停最多 335.5 毫秒。
可以将设备或网络元素配置为发送和接收暂停帧。因此，在 1 Gbps 接口上、如果存储控制器在“传输”统计数据中列出 XOFF （或暂停）、存储控制器指示交换机端口暂停、则存储控制器应停止接收数据包，最长可达 33.5 毫秒。
如果存储控制器在“接收”统计信息中列出 XOFF （或 PAUSON ）、则交换机指示存储控制器停止发送数据包、则存储控制器应在该接口上停止传输、最长可达 33.5 毫秒。
如果“暂停”端口在计时器过期之前收到 XON 数据包，则该端口可以立即恢复传输。
计算潜在影响：
示例：
-- interface e0b (0 hours, 2 minutes, 21 seconds) --
RECEIVE
Frames/second: 4655 | Bytes/second: 416k | Errors/minute: 0
Discards/minute: 0 | Total frames: 186k | Total bytes: 31954k
Total errors: 0 | Total discards: 0 | Multi/broadcast: 0
No buffers: 0 | Non-primary u/c: 0 | Tag drop: 0
Vlan tag drop: 0 | Vlan untag drop: 0 | CRC errors: 0
Runt frames: 0 | Fragment: 0 | Long frames: 0
Jabber: 0 | Alignment errors: 0 | Bus overruns: 0
Queue overflows: 0 | Xon: 1326 | Xoff: 1326
Jumbo: 0 | Reset: 0 | Reset1: 0
Reset2: 0 | TBI mode: 0 | Pad odd: 0
Pad even: 0
TRANSMIT
Frames/second: 2993 | Bytes/second: 4009k | Errors/minute: 0
Discards/minute: 0 | Total frames: 224k | Total bytes: 285m
Total errors: 0 | Total discards: 0 | Multi/broadcast: 2
Queue overflows: 0 | No buffers: 0 | Frames queued: 0
Buffer coalesces: 0 | MTUs too big: 0 | Max collisions: 0
Single collision: 0 | Multi collisions: 0 | Late collisions: 0
Timeout: 0 | Xon: 0 | Xoff: 0
Jumbo: 0
LINK_INFO
Current state: up | Up to downs: 0 | Auto: on
Status interrupt: 0 | Speed: 1000m | Duplex: full
Flowcontrol: full
收集的统计信息总共包括 141 秒（ 2 分钟、 21 秒）。
- 收到 1326 个 XOFF 帧。
- 每个 XOFF 帧可能已停止传输多达 33.5 毫秒。
- 每个 XON 都会释放存储系统端口以恢复传输。但是，无法确定 Xon 是在 Xoff 之后接收的 0.1 毫秒、在 Xoff 之后接收的 1 毫秒、还是在 Xoff 之后接收的 33.4 毫秒。
因此，从存储系统到网络的所有传输的最大 * 潜在 * 时间量为
： 1326*33.5 毫秒 =44,421 毫秒 =44.4 秒。
在考虑“数据包的百分比”时，可能会显得微不足道： 1326/224000=0.7%
。但是请注意，收到的暂停帧只会对传输的帧产生影响（暂时停止接收人本来会发送的传输）。端口可以继续从交换机接收数据的速度与交换机选择发送数据的速度相同。更准确的百分比计算应该是 < 数据包已发送 >/< 如果通信未暂停则会发送的数据包 > 。但是，无法确定如果通信未被暂停，本来会发送的数据包数量。
在考虑端口可能无法传输的时间时、视角非常不同、 而且可能更相关：
44.4 秒 /141 秒 =31%
、因此，在这 141 秒间隔内、客户机将无法从存储系统上的此端口接收响应。
当然，每一个 "xoff" 后面都可能会立即出现一个 "xon) " ，在这种情况下，传输流量只会在很短的时间内停止。这种情况很可能不会被注意到。
因此，在这些统计信息中、 1326 个暂停帧的影响范围介于“无”和 44.4 秒之间。由于流控制暂停帧是针对单个端口、并由单个端口操作的，因此暂停帧不会传递到上层协议层。pktt 不包含暂停帧。来自交换机的大多数端口镜像跟踪也不会包含任何暂停帧。只有一个“在线”数据包捕获可以肯定地揭示真正的影响。
暂停帧表示发送暂停帧的设备遇到问题。如果计算结果确认端口可能已暂停的最长时间是捕获数据所经过的相当长的一段时间，请考虑调查发送暂停帧的设备为何遇到困难。
如果暂停帧可能已停止通信流的最长时间是捕获数据的时间的一小部分、则暂停帧的存在不应引起很大的关注。但是，暂停帧的存在仍会表明、发送暂停帧的设备遇到一定程度的困难。
该协议的最初目的是允许接口暂停其邻居（电缆另一端的接口）、因为该邻居可能会以足够快的速度传输接口。如果先暂停相邻的接口、则会阻止接收接口被淹没。虽然这有时会帮助这种情况，但也可能意味着接收接口（以及其中包含的节点）不会注册任何问题证据（暂停帧除外）。因此，如果需要了解发送暂停帧的原因、您可能必须禁用以太网流控制。然后、如果问题仍然存在、您可能会看到其他计数器或行为，这些计数器或行为会告诉您网卡、 PCI 总线或操作系统中是否有被重压的组件。