暂停帧对网络连接的潜在影响是什么?
适用场景
- ONTAP 9
- 以太网
问题解答
以太网流量控制的用途:
以太网流量控制机制允许遇到性能瓶颈的网络设备请求相邻设备停止传输。
- 以太网流量控制定义了一种通常称为"暂停"帧的以太网数据包。
- 它们只能在直接连接的设备之间交换、并且只能在以太网(DataLink)层定义。
- 因此、以太网暂停帧不会与IP、TCP、NFS、CIFS或任何其他 更高级别的协议相关联、也不能与这些协议相关联。
如果没有以太网流量控制、则如果接收设备无法像发送设备发送信息那样快速处理信息、则最终必须开始处理传入数据。
- 这迫使传输客户端必须重新传输、并会由于多种原因导致发生原因出现令人痛苦的延迟。
通过以太网流量控制、接收方可以请求传输设备暂停一小段时间、以尝试避免这些丢弃。
- 在某些情况下、这可以提高网络传输的效率。
- 但是、以太网流量控制并不总是能够有效地防止出现性能问题。
- 在某些情况下(通常很少见)、以太网流量控制发生原因对性能的影响比其设计所防止的重新传输所造成的影响更大。
注: 以太网流量控制将在1 Gbps或更快的设备上通用。在更现代的100 Mbps设备上也可能会发现此问题、即使此处不支持以太网流量控制规范。
示例:
- 假设我们拥有一个包含存储控制器、交换机和客户端计算机的基本网络。
- 此外、假设存储控制器配置为发送以太网流量控制数据包、而交换机配置为 在存储控制器插入的接口上接收(侦听)以太网流量控制数据包。
- 最后、假设客户端未配置为完全支持以太网流量控制。
- 请注意、交换机的每个接口都有一个以太网流量控制设置 (一个设置用于存储控制器所插入的接口、对于客户端所插入的接口来说、这可能是一个不同的设置)。
停止/暂停流量:
- 在这种情况下、存储控制器现在可以 向交换机发送暂停帧。
- 如果存储控制器达到无法像交换机发送信息那样快速处理信息的程度、现在允许存储控制器向交换机发送暂停帧(Xoff)。
- 交换机在收到该暂停帧时应停止传输。此时、交换机应开始将需要发送到存储控制器的流量暂挂(排队)一小段时间。存储控制器现在可以处理以前收到的数据。
恢复流量:
- 每个暂停/Xoff帧都包含一个值(称为"Quanta (定量)")、用于请求相邻设备在特定时间段内停止传输。
- 当此时间到期或从接收器(在本示例中为存储控制器)接收到不同的以太网流量控制数据包时、发射器(在本例中为交换机)应恢复传输。
- 根据IEEE标准、交换机应评估Quanta值、并根据Quanta值和接口速度的组合保持"暂停"状态。
- 但是、接口应保持"暂停"状态的时间量取决于传输设备的固件、可能不会遵循此规则。
计算接口应保持暂停状态的时间量:
- 暂停帧或Xoff帧会显示在
ifstat -a -v
命令的输出中。 - 在10Gbps中、
ifstat –a
命令可能会列出"暂停"帧;在1Gbps中、通常会列为Xoff和Xon。
- 暂停帧包括所请求的暂停时间、其形式为一个两字节无符号整数(0到65535)、称为"quanta (昆塔)"。
- 这 两字节无符号整数是请求的暂停持续时间。
- 每个"quanta "等于512位的次数。
- "位时间"是指发送一些数据所需的秒数。由于接口的额定单位是"位/秒"、因此"位时间"与接口线路速度相反。
对于 1 Gbps (1、000、000、000 bps) 接口 | "位时间"为每位1/1、000、000、000秒 |
1Gbps 链路、接口预期停止传输的最长时间计算 | 最大量子值* 512 /(10^9) = 65535 * 512/1000000000 = 0.03355392秒= 33.55毫秒 |
对于 10Gbps、 接口预期停止传输计算的最长时间 |
65535 * 510/10^10 = 3.3555毫秒 |
适用于 支持该协议的100Mbps接口 | 100Mbps接口的暂停 时间应最多为335.5毫秒 |
可以将设备或网络元素配置为发送和接收暂停帧。
- 在1 Gbps接口上、如果存储控制器在"传输"统计信息中列出Xoff (或暂停):
- 存储控制器正在指示交换机端口暂停
- 然后、存储控制器应停止接收数据包长达33.5毫秒。
如果存储控制器在"接收"统计信息中列出Xoff (或暂停)
- 交换机正在指示存储控制器停止发送数据包
- 然后、 存储控制器应停止在此接口上传输最长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秒的时间间隔内、多达31%的时间内、客户端可能无法从存储系统上的此端口接收响应。
- ‘,每一个‘Xoff’(Xoff)都有可能在其后面立即出现一个 Xon’(Xon),
- 在这种情况下、传输流量只会在很短的时间内停止。
- 这很可能不会引起注意。
因此,就这些统计数据而言,1326暂停帧的影响范围介于‘无’和44.4秒之间。由于流量控制暂停帧针对各个端口并由其操作、因此暂停帧不会传递到协议的上层。PKTT不包含暂停帧。来自交换机的大多数端口镜像跟踪也不包含任何暂停帧。只有‘线上'的数据包捕获才能肯定地揭示真正的影响。
暂停帧表示发送暂停帧的设备遇到问题。如果计算结果确认端口可能已暂停的最长时间是捕获数据的时间的很大一部分、请考虑调查发送暂停帧的设备遇到困难的原因。
如果暂停帧可能已停止流量的最长时间只是捕获数据的时间的一小部分、则暂停帧的存在不应引起过多关注。但是、暂停帧的存在仍会表明、发送暂停帧的设备会遇到一定程度的困难。
该协议的最初目的是、允许接口在其邻居(缆线另一端的接口)的传输速度可能足以超过接口时暂停其邻居。如果先暂停相邻接口、则可以防止接收接口不堪重负。虽然这有时会对这种情况有所帮助、但也可能意味着接收接口(及其所在节点)不会注册除暂停帧以外的任何问题描述证据。因此、如果需要了解为什么要发送暂停帧、则可能必须禁用以太网 流量控制。然后、如果问题描述继续运行、您可能会看到其他计数器或行为、这些计数器或行为会告诉您负载过重的组件是位于NIC、PCI总线还是操作系统中。
追加信息