了解IOS软件平台上的队列限制和输出丢弃

简介

本文档介绍Cisco IOS®软件平台和传统接入路由器上的队列限制和输出丢弃。

先决条件

要求

Cisco 建议您了解以下主题：

• Cisco IOS®服务质量解决方案配置指南

• QoS — 分层排队框架(HQF)

使用的组件

本文档中的信息基于以下软件版本：

• 对于Pre-HQF：运行Cisco IOS软件版本12.3(26)的Cisco路由器

• 对于HQF：运行Cisco IOS软件版本12.4(22)T的思科路由器

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

规则

有关文档规则的详细信息，请参阅 Cisco 技术提示规则。

背景信息

本文档仅适用于Cisco IOS®软件平台，通常包括Cisco 7200VXR和Cisco ISR 3800、2800、1800系列路由器，以及包括3700、3600、2600和1700系列路由器的传统Cisco接入路由器。

Class-Based Weighted Fair Queueing 入门

在HQF之前的Cisco IOS映像中，任何具有 bandwidth 通常可以根据类的权重，根据没有带宽或优先级的类确定命令的优先级。要了解 Class-Based Weighted Fair Queueing (CBWFQ) 调度算法，您必须首先了解权重的概念：对于基于流的公平队列，它特定于流；对于基于类的加权公平队列中的单个基于类的队列，它特定于类。

计算基于流的公平队列的权重的公式为：

32384 / (IP Prec + 1)

基于类的加权公平队列中的用户定义类作为的函数导出其各自的权重 bandwidth 命令在类中配置为基于类的队列中所有带宽类的SUM的比例。具体公式是专有的。

在 HQF 映像中，可在用户定义的类和默认使用 fair-queue 的类中配置的基于流的 fair-queue 将平等地进行调度（而不是按权重进行调度）。此外，在 HQF 中，基于类的队列的调度优先级将根据 HQF 调度程序而非类的传统权重公式来确定。

注意：本节不旨在对基于类的排队操作进行全面的行为分析。目的是解释CBWFQ如何应用队列限制和输出丢弃。

了解队列限制和输出丢弃

用“priority”命令配置的用户定义的类

对于使用任何变体配置的MQC用户定义的类 priority 命令，使用  priority , priority  ,和 priority percent  包括。

Pre-HQF 行为

从技术上来说，会有一个供所有优先级数据共享的“隐藏”系统队列存在，即使不存在可查看它的 CLI，且不可对其进行配置。在优先级数据分类之后，在拥塞感知策略器允许优先级数据后，它充当优先级数据的临时存储库。如果在接收中断期间，无法将LLQ数据包直接放置在出口接口传输环上，则将其放入此“隐藏”系统队列中，否则称为功能拥塞。在这种情况下，由于存在功能性拥塞，在接收中断期间，当数据包仍然由接收接口驱动程序拥有时，将根据LLQ条件监察器评估数据包。如果LLQ条件监察器未丢弃数据包，则将其置于此“隐藏”LLQ系统队列中，并释放接收中断。因此，置于此“隐藏”系统队列中的所有数据包都符合LLQ拥塞感知监察器，并且可以立即由LLQ/CBWFQ调度程序将数据包出队到出口接口传输环路。

尽管存在此队列，但此行为与为非LLQ数据（例如公平队列和带宽队列）创建的Cisco IOS队列不同，因为此队列中的数据包可以立即由LLQ/CBWFQ调度程序排入传输环路，所以不会产生额外的排队延迟（高于传输环延迟）。如果在接收中断期间，条件监察器未丢弃优先级类数据包，则此LLQ数据包可以在此“隐藏”系统队列中短暂存在，然后再将数据包出队到出口接口的传输环路。在这种情况下，LLQ/CBWFQ调度程序可以立即将数据包呈现给出口接口传输环。条件监察器在向LLQ/CBWFQ允许数据包之前运行，因此，它将LLQ限制为配置的优先级速率。

总之，建议在拥塞时丢弃超过优先级速率的LLQ数据，而不是产生额外的排队延迟，这是LLQ的基本组成部分。此条件管制机制允许严格的优先级队列，并且不允许优先级队列独占整个接口PLIM，这是对Cisco IOS传统优先级队列功能的改进。

• Pre-HQF队列限制：不适用

• Pre-HQF“priority”+“random-detect”行为:LLQ中不允许使用NA、WRED。

• Pre-HQF“priority”+“fair-queue”行为：NA，LLQ中不允许使用fair-queue。

• Pre-HQF“priority”+“random-detect”+“fair-queue”行为：NA，在LLQ中不支持公平队列或随机检测。

HQF 行为

和 Pre-HQF 一样，只是隐藏队列不再能够隐藏，队列限制现在可以进行配置，默认值为 64 个数据包。

• HQF队列限制:64个数据包

• HQF“priority”+“random-detect”行为:LLQ中不允许使用NA、WRED。

• HQF“priority”+“fair-queue”行为:NA，LLQ中不允许使用fair-queue。

• HQF“priority”+“random-detect”+“fair-queue”行为：NA，在LLQ中不支持公平队列或随机检测。

用“bandwidth”命令配置的用户定义类

对于使用任何变体配置的MQC用户定义的类 bandwidth 命令，使用  bandwidth  ,  bandwidth percent ,和  bandwidth remaining percen t  包括。

Pre-HQF 行为

默认队列限制为 64 个数据包，可调整。在接收中断期间，如果需要将某个数据包排入队列中，从而导致队列中的数据包超出 64 个，则会对该数据包执行尾部丢弃。

• Pre-HQF queue-limit:64个数据包，可通过queue-limit进行调整。

• Pre-HQF“bandwidth”+“random-detect”行为：

示例：

policy-map PRE_HQF_BANDWIDTH_WRED
 class 1
   bandwidth 32
   random-detect

如果将 bandwidth 的任意变体与 random-detect 的任意变体一起进行配置，请忽略任何 queue-limit CLI，即可有效去除类中的任何缓冲限制。也就是说，随机检测和队列限制在pre-HQF图像上是相互排斥的，使用随机检测作为丢弃策略，当前队列大小不受限制，理论上可以占用分配给基于类的公平队列的每个缓冲区，其中分配给基于类的公平队列的缓冲区数量是根据服务策略连接点得出的：

• 物理接口：1000个数据包，可通过接口CLI保持队列退出进行调整

• ATM PVC:500个数据包，可使用PVC CLI vc-hold-queue进行调整

• Frame-Relay map-class:600个数据包，可使用frame-relay map-class CLI frame-relay hold-queue进行调整

• 应用于（子）接口(pre-HQF)的基于类的整形策略：1000个数据包，可使用MQC类CLI shape max-buffers进行调整。

注意：所有帧中继和基于类的整形示例都假设整形器的总和不超过接口时钟速率。

注意：在HQF之前的映像中，将基于类的整形策略应用到（子）接口时，请注意底层物理接口的速度，因为接口<2Mbps可以默认为加权公平队列，而接口>2Mbps可以默认为FIFO。在pre-HQF中，无论整形策略是在子接口级别还是在物理接口级别连接，整形队列都可以馈送接口保持队列。

在接收中断期间，每当数据包成为接口输出队列的候选者时，WRED平均队列大小使用以下公式计算：

Average Queue Size = (old_average * (1-1/2^n)) + (current_queue_size * 1/2^n)

如果得到的平均队列大小：

• 小于 WRED 最小阈值，则会将数据包排入队列并释放接收中断。
• 处于 WRED 最小阈值和 WRED 最大阈值之间，则平均队列大小越接近 WRED 最大阈值，丢弃数据包的可能性越大。如果Average Queue Size完全等于WRED max-threshold，则根据标记概率分母丢弃数据包。标记概率分母还用作基线，以确定当平均队列限制不完全等于WRED最大阈值但高于WRED最小阈值时，可以丢弃的数据包百分比。以下为图形示例：

平均队列限制不等于WRED最大阈值但高于WRED最小阈值

• • 如果数据包已丢弃，则释放接收中断，并增加一次“随机丢弃”。如果数据包未丢弃，则将数据包排入队列，并释放接收中断。

  • 大于 WRED 最大阈值，则丢弃数据包，释放接收中断，并增加一次“尾部丢弃”。

注意：基于IP优先级（默认）和基于DSCP的WRED允许针对不同值以不同方式定义最小阈值、最大阈值和标记概率分母。这是随机早期检测的加权组件最突出的特点。在调整其相对阈值和标记概率分母时，可以相对于其他值保护某些ToS值。

随机检测和带宽在一起配置时，任何时候，当前队列大小均可大于 WRED 最大阈值。这是因为WRED最小和最大阈值仅基于平均（而非当前）队列大小而运行。这提供了终止分配给基于类的队列的所有缓冲区的机会，这些缓冲区可能导致基于类的公平队列中的任何位置发生无缓冲区丢弃(请参阅Cisco Bug ID CSCsm94757)。

• Pre-HQF“bandwidth”+“fair-queue”行为：NA，带宽类中不允许使用fair-queue。

• Pre-HQF“bandwidth”+“random-detect”+“fair-queue”行为：NA，带宽类中不允许公平队列

HQF 行为

其行为与 Pre-HQF 部分描述的行为相同。

• HQF queue-limit:64个数据包，可通过queue-limit进行调整。

这与 Pre-HQF 中的队列限制相同。

• HQF“bandwidth”+“random-detect”行为：

示例：

policy-map HQF_BANDWIDTH_WRED
 class 1
   bandwidth 32
   queue-limit 512
   random-detect

注意：默认队列限制为64个数据包。

行为与等效的pre-HQF部分相同，但有一个重要例外。在HQF映像中，random-detect和queue-limit可以共存于同一个用户定义的类（或class class-default）中，队列限制可以启用并调整为默认配置中的64个数据包。因此，queue-limit可以充当随机检测类中的最大当前队列大小，因此它可以提供一种机制来限制等效的pre-HQF部分中讨论的无缓冲区丢弃。由于此添加，配置的队列限制必须至少与random-detect max-threshold一样大，其中random-detect max-threshold可以默认为40个数据包，否则解析器可以拒绝配置。

这在WRED类中引入了当前队列限制检查，由此即使平均队列深度计算小于最大阈值，如果当前（非平均）队列大小大于队列限制，也可以丢弃数据包，释放接收中断，并记录尾部丢弃。切记，如果将队列限制调整得足够高，耗尽了基于类的队列的聚合排队缓冲区，此时仍可能发生“无缓冲区丢弃”。HQF 的聚集排队缓冲区定义如下：

• 物理接口：1000个数据包，可通过接口CLI保持队列退出进行调整

• ATM PVC:500个数据包，可使用PVC CLI vc-hold-queue进行调整

• Frame-Relay map-class:600个数据包，可使用frame-relay map-class CLI frame-relay hold-queue进行调整

• 应用于HQF代码中物理接口的基于类的整形策略：1000个数据包，可通过接口CLI保持队列输出和子策略队列限制组合进行调整，其中子策略队列限制具有接口保持队列输出的上限。

• 应用于HQF代码中子接口的基于类的整形策略：512个数据包，不可调整（使用NSSTG QoS平台团队进行调查，必须对其进行调整）

注意：所有帧中继和基于类的整形示例都假设整形器的总和不超过接口时钟速率。

以下为实际示例：

policy-map JACKLYN
 class 1
    bandwidth 64
    queue-limit 500 packets
     random-detect
     random-detect precedence 1 22 300

在此输出期间，不会通过接口生成任何流量：

F340.11.25-7200-5_LAC#show policy-map interface | i queue      
      queue limit 500 packets
      (queue depth/total drops/no-buffer drops) 0/387595/0

!--- Current_q_depth is 0

        Mean queue depth: 107 packets

!--- last calculation of Average_queue_depth

这时，流量开始生成。数据流在400PPS时无突发，包含1000字节的帧：

F340.11.25-7200-5_LAC#show policy-map interface | i queue
      queue limit 500 packets
      (queue depth/total drops/no-buffer drops) 461/387641/0

!--- 461 is Current_q_depth > Prec 1 max-thresh of 300 
!--- but < "queue-limit 500 packets".

        Mean queue depth: 274 packets

!--- Avg_q_depth is rising, Mark Prob Denom is being used.  F340.11.25-7200-5_LAC#show policy-map interface | i queue queue limit 500 packets (queue depth/total drops/no-buffer drops) 363/387919/0 !--- 363 is Current_q_depth and it is falling compared to last !--- iteration because WRED is random dropping packets. Mean queue depth: 351 packets !--- Avg_q_depth is now above max_thresh, WRED starts to tail-drop !--- in addition to random-drop.  F340.11.25-7200-5_LAC#show policy-map interface | i queue queue limit 500 packets (queue depth/total drops/no-buffer drops) 199/388263/0 Mean queue depth: 312 packets F340.11.25-7200-5_LAC#show policy-map interface | i queue queue limit 500 packets (queue depth/total drops/no-buffer drops) 303/388339/0 Mean queue depth: 276 packets F340.11.25-7200-5_LAC#show policy-map interface | i queue queue limit 500 packets (queue depth/total drops/no-buffer drops) 325/388498/0 Mean queue depth: 314 packets F340.11.25-7200-5_LAC#show policy-map interface | i queue queue limit 500 packets (queue depth/total drops/no-buffer drops) 298/390075/0 Mean queue depth: 300 packets

请注意，对于非突发数据流，WRED平均队列深度最终如何等于当前队列深度，这是预期行为。

• HQF“bandwidth”+“fair-queue”行为：

将带宽和公平队列一起应用于 HQF 用户定义的类时，将会为每个基于流的队列分配一个队列限制（等于 .25 * 队列限制）。由于默认队列限制为64个数据包，因此公平队列中每个基于流量的队列可分配16个数据包。如果四个流经过此类，默认情况下，每个流队列将有16个数据包，因此您永远也不会看到排队的数据包总数超过64(4 *16)。来自单个流队列的所有尾部丢弃都记录为flow-drops。如果流队列的数量远大于队列限制的数量，则这时也可能会发生“无缓冲区丢弃”。例如，如果您假设策略连接点是一个物理接口，其中分配了1000个聚合缓冲区：

policy-map TEST
 class 1
  bandwidth 32
  fair-queue 1024
  queue-limit 128

在此配置中，所有流队列中的可感知流量可能会耗尽聚合接口缓冲区，并导致其他用户定义类发生无缓冲区丢弃(请参阅Cisco Bug ID CSCsw98427)。这是因为，1024 个流队列（每个流队列的队列限制为 32 个数据包）能够轻易使基于类的排队缓冲区（具有 1000 个聚集接口）发生分配超载。

• HQF“bandwidth”+“random-detect”+“fair-queue”行为：

示例：

policy-map TEST
 class 1
  bandwidth 32
  fair-queue 1024
  queue-limit 128
  random-detect

与section中的带宽和公平队列相同，不同之处在于，每当数据包到达时，都会计算WRED平均队列大小，以确定数据包必须随机丢弃还是尾部丢弃。与pre-HQF一样，所有流队列可以共享一个WRED阈值实例，这意味着所有流队列中排队的数据包都用于计算WRED平均队列深度，然后丢弃决策会针对所有流队列中的聚合数据包应用WRED最小和最大阈值。但是，另一个与该部分的 bandwidth 和 fair-queue 不同的地方在于，由于已将 WRED 阈值的一个实例应用于所有基于流的队列，因此不会采用各个流队列的队列限制（.25 * 队列限制），而是采用当前队列限制检查的类聚集队列限制。

类的默认行为

Pre-HQF 行为

在 Pre-HQF 中，Class Default 默认为 fair-queue，所有流队列具有相同的类队列限制（默认为 64），并且没有带宽预留。换句话说，所有流队列中排队的数据包总数永远不能超过队列限制。每个流队列中排队的数据包数量可取决于流队列的计算权重。相反，如果在class-default中同时使用fair-queue和random-detect，则可以忽略队列限制，并且所有流队列可以共享相同的WRED阈值。因此，所有流队列中当前排队的所有数据包都可用于计算WRED平均队列大小。由于当前队列大小在此配置中没有上限，因此无缓冲区丢弃的可能性很高(请参阅Cisco Bug ID CSCsm94757)。

• 如果将带宽添加到class-default，则会导致Pre-HQF Behavior - User Defined Classes Configured with the "bandwidth"部分中概述的行为。

• 如果将bandwidth和random-detect添加到class class-default，则会导致Pre-HQF Behavior - User Defined Classes的Pre-HQF "bandwidth" + "random-detect"行为部分中概述的行为。

注：在pre-HQF中，带宽不能与class-default中的fair-queue共存。

HQF 行为

在 HQF 中，Class Default 的默认值为 FIFO 队列，并已根据用户定义的类中的残余分配分配了伪带宽预留。同样地，关于 HQF class class-default 的默认行为，请参阅 HQF 行为 - 用“bandwidth”命令配置的用户定义的类部分。在任何时候，无论配置如何，HQF映像中的class class-default始终可以具有相当于未使用的接口带宽（用户定义类不消耗该带宽）的隐式带宽预留。默认情况下，class-default 类的带宽至少为接口或父整形带宽的 1%。此外，还可以在 class default 中显式配置带宽 CLI。

• 如果在 class class-default 中配置了 fair-queue，则行为与 HQF 行为 - 用“bandwidth”命令配置的用户定义的类中 HQF“bandwidth”+“fair-queue”行为部分所述相符。

• 如果在Class-Default中同时配置了fair-queue和random-detect，则行为与HQF Behavior - User Defined Classes Configured with the "bandwidth"命令的HQF "bandwidth" + "random-detect" + "fair-queue"行为部分匹配。

相关信息

• Cisco IOS服务质量解决方案配置指南，版本12.2SR
• QoS — 分层排队框架(HQF)[不支持]
• 路由器支持
• 思科技术支持和下载