2960X 上的 QoS 似乎没有影响

网络工程 思科 服务质量 思科-2960
2021-07-27 00:25:50

我们对延迟要求非常高的 Dect 站存在一些问题。2 个设备之间的通信不应超过 500 微秒 (0.5ms)。我们决定使用 ping 统计信息测试一些不同的配置。所以我们的设置是这样的：

DeviceA - - - - SwitchA - - - - SwitchB - - - - SwitchC - - - - SwitchD - - - - DeviceB

我们从 DeviceA（ESXi 上的 Windows 2016 服务器）到 DeviceB（仅是 Windows 10 PC）执行了 1 小时的 ping 操作。首先，我们在没有任何 QoS 活动的情况下进行了测试，作为参考。然后，我们将 ICMP 流量放入 DSCP18，因此它有自己的空闲队列可供使用。这是 SwitchA 和 SwitchD 上的策略配置：

ip access-list extended QOS_ICMP_COLORING
 permit icmp host 172.16.144.35 any
 permit icmp any host 172.16.144.35

class-map match-any QOS_ICMP_COLORING
 match access-group name QOS_ICMP_COLORING

policy-map QOS
 class QOS_ICMP_COLORING
  set dscp af21

SwitchA
interface GigabitEthernet1/0/37
 description DeviceA with IP 172.16.144.35
 switchport trunk native vlan 10
 switchport mode trunk
 power inline port 2x-mode
 mls qos trust dscp
 mls qos dscp-mutation HIDE
 spanning-tree portfast trunk
 service-policy input QOS
end

SwitchD
interface GigabitEthernet1/0/5
 description DeviceB with IP 172.16.144.243
 switchport access vlan 10
 switchport mode access
 power inline port 2x-mode
 mls qos trust dscp
 mls qos dscp-mutation HIDE
 spanning-tree portfast
 service-policy input QOS
end

Example uplink interface (same on all switches)
interface GigabitEthernet1/0/47
 description uplink
 switchport trunk native vlan 10
 switchport mode trunk
 power inline port 2x-mode
 mls qos trust dscp
 mls qos dscp-mutation HIDE
end

由于在 2960X 上有固定的 DSCP 到队列映射，我们使用 dscp-mutation 映射来覆盖网络中所有不需要的标记，只允许需要的标记：

SwitchA#show mls qos maps dscp-mutation HIDE
Dscp-dscp mutation map:
HIDE:
 d1 :  d2 0  1  2  3  4  5  6  7  8  
 ---------------------------------------
  0 :    00 00 00 00 00 00 00 00 00 00 
  1 :    00 00 00 00 00 00 00 00 18 00 
  2 :    00 00 00 00 24 00 00 00 00 00 
  3 :    00 00 32 00 00 00 00 00 00 00 
  4 :    00 00 00 00 00 00 46 00 00 00 
  5 :    00 00 00 00 00 00 00 00 00 00 
  6 :    00 00 00 00

我们没有将任何 DSCP 更改为队列映射，因此这仍然是所有端口上的默认值，即：

 queue 0:  DSCP 40–47         Voice RTP
 queue 1:  DSCP 00–15         Class-default
 queue 2:  DSCP 16–31         Voice Signaling
 queue 3:  DSCP 32–39,48–63   Citrix

由于我们在此位置不使用语音信令 (DSCP24)，ICMP 流量 (DSCP18) 可以使用其他未使用的 queue2。在 show mls qos 统计信息中，我们可以看到 DSCP18 标记。我验证了整个路径，到目前为止一切看起来都很好。我们使用默认的队列集设置。

SwitchA#show mls qos interface gigabitEthernet 1/0/37 statistics
GigabitEthernet1/0/37 (All statistics are in packets)

  dscp: incoming  
-------------------------------

  0 -  4 :     1066030            0            0            0            0  
  5 -  9 :           0            0            0            0            0  
 10 - 14 :           0            0            0            0            0  
 15 - 19 :           0            0            0            0            0  
 20 - 24 :           0            0            0            0            0  
 25 - 29 :           0            0            0            0            0  
 30 - 34 :           0            0            0            0            0  
 35 - 39 :           0            0            0            0            0  
 40 - 44 :           0            0            0            0            0  
 45 - 49 :           0            0            0            0            0  
 50 - 54 :           0            0            0            0            0  
 55 - 59 :           0            0            0            0            0  
 60 - 64 :           0            0            0            0  
  dscp: outgoing 
-------------------------------

  0 -  4 :     2038575            0            0            0            0  
  5 -  9 :           0            0            0            0            0  
 10 - 14 :           0            0            0            0            0  
 15 - 19 :           0            0            0        68618            0  
 20 - 24 :           0            0            0            0            0  
 25 - 29 :           0            0            0            0            0  
 30 - 34 :           0            0       679380            0            0  
 35 - 39 :           0            0            0            0            0  
 40 - 44 :           0            0            0            0            0  
 45 - 49 :           0       974219            0            0            0  
 50 - 54 :           0            0            0            0            0  
 55 - 59 :           0            0            0            0            0  
 60 - 64 :           0            0            0            0

output queues enqueued: 
 queue: threshold1 threshold2 threshold3
-----------------------------------------------
queue 0:    974219          0          0 
queue 1:   6166478       1226     544798 
queue 2:     72375          0          0 
queue 3:    679900          0          0

output queues dropped: 
queue: threshold1 threshold2 threshold3
-----------------------------------------------
queue 0:        0          0          0 
queue 1:        8          0          0 
queue 2:        0          0          0 
queue 3:        0          0          0 

SwitchA#show mls qos queue-set 1
Queueset: 1
Queue :        1     2     3     4
----------------------------------------------
buffers :     25    25    25    25
threshold1:  100   200   100   100
threshold2:  100   200   100   100
reserved :    50    50    50    50
maximum :    400   400   400   400

对我来说似乎很奇怪的是，DSCP18 对 mls qos 统计 DSCP 传出的计数与队列 2 排队的输出队列不匹配。但这也许是正常的。萨尔迪，我们的 ping 统计数据没有改善。所以我们改变了策略映射来设置 DSCP46 并激活优先级队列：

policy-map QOS
 class QOS_ICMP_COLORING
  set dscp ef

interface GigabitEthernet1/0/5
 description DeviceB with IP 172.16.144.243
 switchport access vlan 10
 switchport mode access
 power inline port 2x-mode
 priority-queue out
 mls qos trust dscp
 mls qos dscp-mutation HIDE
 service-policy input QOS
end

服务策略仅应用于连接终端设备的接口。优先级队列已在路径上的所有接口（包括上行链路）上启用。但这并不影响ping统计。这是一个具有 21 个交换机的网络，其中大部分为星型配置。我们在同一台服务器上同时对 3 台 PC 进行了测试，以获得更可靠的数据。但我们到处都有同样的画面。结果如下：

TC0686CQ swDAI15 no QoS     TC0686CQ swDAI15 QoS (18)   TC0686CQ swDAI15 QoS (46) Priority  
More then 1ms   2872        More then 1ms   4872        More then 1ms   1870
More then 2ms   1012        More then 2ms   2080        More then 2ms   735
More then 3ms   123         More then 3ms   160         More then 3ms   449
More then 4ms   75          More then 4ms   246         More then 4ms   39
More then 5ms   64          More then 5ms   59          More then 5ms   29
Average (ms)    0.768       Average (ms)    0.935       Average (ms)    0.873
Maximum (ms)    26.5        Maximum (ms)    23          Maximum (ms)    26.3
Timeouts    0               Timeouts    0               Timeouts    0

TC0686JZ swDAI12 no QoS     TC0686JZ swDAI12 QoS (18)   TC0686JZ swDAI12 QoS (46) Priority
More then 1ms   2507        More then 1ms   2891        More then 1ms   746
More then 2ms   865         More then 2ms   1012        More then 2ms   385
More then 3ms   150         More then 3ms   894         More then 3ms   41
More then 4ms   106         More then 4ms   64          More then 4ms   19
More then 5ms   87          More then 5ms   73          More then 5ms   34
Average (ms)    0.866       Average (ms)    0.736       Average (ms)    0.679
Maximum (ms)    48.5        Maximum (ms)    59.3        Maximum (ms)    27.9
Timeouts    1               Timeouts    0               Timeouts    1

TC0868KD swDAI08 no QoS     TC0868KD swDAI08 QoS (18)   TC0868KD swDAI08 QoS (46) Priority
More then 1ms   3145        More then 1ms   1010        More then 1ms   406
More then 2ms   1095        More then 2ms   171         More then 2ms   154
More then 3ms   145         More then 3ms   134         More then 3ms   27
More then 4ms   63          More then 4ms   62          More then 4ms   11
More then 5ms   70          More then 5ms   43          More then 5ms   27
Average (ms)    0.737       Average (ms)    0.717       Average (ms)    0.703
Maximum (ms)    43.7        Maximum (ms)    40.3        Maximum (ms)    55.7
Timeouts    1               Timeouts    1               Timeouts    2

我们总是每 50 毫秒进行 1 小时的 ping 测试，即 20 ping/秒，即 72'000 ping/小时。平均水平对我们来说很好，也许这不能再提高了。但是让我感到困扰的是我们无法摆脱的最大值，即使激活了优先级队列。我们的配置中是否遗漏了什么？对我来说唯一的解释是，延迟来自终端设备。我们交叉引用了这些值，以查看服务器是否有一些负载，导致所有 ping 同时延迟，但事实并非如此。我们在所有交换机上使用 IOS 版本 15.2(2)E7。感谢您查看这篇长文。

1个回答

正如已经评论过的，QoS 只能在拥塞的情况下调整您的流量- 它可以优先处理某些流量，但不能使您的网络更快。减少空闲延迟的唯一方法是在硬件中 - 使用更快的设备或更少/更短的链接。

换句话说，即使存在拥塞，QoS 也使您能够以（理想情况下）空闲延迟转发高优先级流量。有了充足的带宽，QoS 就没有什么意义了。

但是，跨四个交换机的 500 μs 应该不是问题——一个不错的交换机跨千兆链路的范围为 2 到 5 μs。再加上每 100 m 布线 0.5 μs（铜和光纤无关紧要）。为 10GBASE-T 链路增加 1-1.5 μs。

在您的场景中，最有可能导致延迟的原因是虚拟主机。我发现 ESXi 上的 Windows 虚拟机在物理网卡、vSwitch 和 vNIC 上至少有 50 微秒的额外延迟。您可以通过使用半虚拟化 vNIC (VMXNET) 而不是虚拟 E1000 等来稍微降低它。（不过我们已经跑题了。）

但是，您应该注意，您无法使用 测量延迟ping。这是一个常见的误解，但 ICMP 处理通常具有如此低的优先级，以ping显示比您实际拥有的数字高得多的数字。因此，这些ping值（或多或少）显示了延迟的上限——这通常没有多大帮助。

相反，您应该监视 TCP 或类似参数中的 RTT 值。对于真正精确的值，您需要使用昂贵的设备（或非常复杂的实验室设置）。

其它你可能感兴趣的问题
上一篇仅 RST 段是否合法？ 下一篇TCP - ACK 和接收窗口之间的相关性