2. Nexus QoS架构与硬件基础

在 Nexus 平台上做 QoS，不能只停留在“配一条 policy-map”的层面。真正决定报文在拥塞时被如何对待的，是转发芯片内部的队列结构、缓冲区分配方式以及各平台 ASIC 的差异。NX-OS 的 QoS 模型本质上是一套“策略下发 + 硬件映射”的体系：管理员在 CLI 中定义分类、标记、队列和调度策略，系统再把这些策略翻译成芯片可执行的表项。理解这条映射链，才能解释为什么同样的配置在不同型号上表现不同。

NX-OS QoS 模型的三层结构

NX-OS 的 QoS 配置可以归纳为三个层次。第一层是分类与标记，通过 class-map 匹配流量，再用 policy-map 设置 CoS、DSCP 或 IP 优先级。第二层是队列映射，把不同优先级映射到出接口的硬件队列，并决定哪些队列参与调度。第三层是调度与拥塞控制，包括严格优先级、加权轮询、带宽保证、WRED 以及尾丢弃等。这三层最终都要落到具体 ASIC 的队列资源和缓冲区上。

以 Nexus 9000 系列为例，常见的配置顺序是：先定义 class-map 匹配关键业务，再在 policy-map 中为每个类指定 set cos 或 set dscp，最后通过 service-policy 应用到接口。需要注意的是，NX-OS 中入方向通常负责标记和分类，出方向负责队列调度和拥塞管理。如果只在入方向做标记而没有在出方向配置队列策略，拥塞时仍然可能所有流量进入同一个默认队列。

转发芯片队列结构

Nexus 交换机的转发芯片通常为每个出端口维护多组队列。以典型的 8 队列模型为例，队列编号 0 到 7 对应不同的优先级，其中队列 7 常被保留给网络控制协议，队列 6 用于严格优先级业务，其余队列参与加权调度。每个队列并不是无限缓冲的，芯片会为每个队列分配一定的缓冲区单元，并在队列深度超过阈值时触发丢弃或标记。

队列的调度方式决定了出口带宽的分配。严格优先级队列会优先发送，直到队列为空；加权轮询则按权重比例分配剩余带宽。实际配置中，常把语音和存储流量放入严格优先级队列，把普通业务放入加权队列，把尽力而为流量放入低权重队列。这样在拥塞发生时，高优先级流量仍能获得低延迟，而低优先级流量按比例分享剩余带宽。

缓冲区分配机制

缓冲区是队列能够吸收突发流量的关键资源。Nexus 芯片通常采用共享缓冲区池加每队列动态阈值的方式。共享池意味着所有队列可以按需借用缓冲区，但每个队列有一个动态上限，防止某个队列占满全部缓冲。动态阈值会根据当前空闲缓冲区的多少自动调整：空闲多时阈值放宽，空闲少时阈值收紧。这种机制在突发流量场景下比固定阈值更高效。

当队列深度超过阈值时，芯片有两种处理方式：尾丢弃和 WRED。尾丢弃简单直接，但容易造成全局同步，多个 TCP 流同时降速再同时提速，导致链路利用率波动。WRED 则在队列达到下限阈值后开始随机丢弃部分报文，让 TCP 发送端提前降速，从而平滑拥塞。配置 WRED 时需要关注三个参数：最小阈值、最大阈值和标记概率。最小阈值决定何时开始丢弃，最大阈值决定丢弃概率达到上限的队列深度，标记概率决定最大丢弃比例。

平台差异与选型注意

不同 Nexus 平台的 QoS 能力差异明显。Nexus 9000 系列中，固定式交换机与模块化交换机使用的 ASIC 不同，队列数量和缓冲区大小也不同。例如部分 1RU 固定式 N9K 每端口支持 8 个队列，而高密度模块化平台可能支持更多队列和更大的共享缓冲区。Nexus 7000 系列使用不同的转发引擎，队列结构和调度算法与 N9K 有区别。Nexus 3000 系列面向低成本场景，队列资源相对有限，配置时需要更谨慎地规划优先级数量。

实际项目中，建议先确认平台型号和 ASIC 类型，再决定 QoS 策略的复杂度。如果平台只支持 4 个队列，就不要设计 8 个优先级；如果缓冲区较小，WRED 阈值需要设置得更保守。可以通过 show hardware profile status 或 show platform fwm 等命令查看硬件资源概况。对于跨平台部署，尽量把 QoS 策略抽象为“关键业务、普通业务、尽力而为”三档，再根据各平台能力映射到具体队列，这样既能保证策略一致性，又能适配硬件差异。

配置示例与结果判断

下面是一段典型的 N9K 出方向队列策略示例，用于把语音流量放入严格优先级队列，把普通业务放入加权队列：

class-map type qos match-any VOICE
  match dscp ef
class-map type qos match-any BUSINESS
  match dscp af31

policy-map type qos MARK
  class VOICE
    set qos-group 6
  class BUSINESS
    set qos-group 4

policy-map type queuing QUEUE-OUT
  class type queuing c-out-8q-q7
    priority level 1
  class type queuing c-out-8q-q6
    priority level 2
  class type queuing c-out-8q-q5
    bandwidth percent 40
  class type queuing c-out-8q-q4
    bandwidth percent 30
  class type queuing c-out-8q-q3
    bandwidth percent 20
  class type queuing c-out-8q-q2
    bandwidth percent 10

interface Ethernet1/1
  service-policy type qos input MARK
  service-policy type queuing output QUEUE-OUT

配置完成后，用 show policy-map interface ethernet 1/1 output 查看各队列的发送速率和丢弃计数。如果 Q6 的发送速率稳定且丢弃为零，说明严格优先级队列工作正常；如果 Q4 的丢弃计数持续增长，说明普通业务队列缓冲区不足，可以考虑调整 WRED 阈值或增加该队列的带宽权重。判断 QoS 是否生效，不能只看配置是否存在，而要看拥塞场景下各队列的实际转发比例和丢弃分布是否符合设计预期。

总结来说，Nexus QoS 的硬件基础决定了策略的上限。理解 NX-OS 的三层模型、芯片队列结构、缓冲区动态阈值和平台差异，才能在配置时做出合理取舍，并在结果不符合预期时快速定位是策略问题还是硬件资源限制。