【HCIE面试】QOS拥塞管理机制，来看看你是不是这样想的？

01

拥塞管理有哪些类型？默认一个接口有几个软件队列？不同优先级的报文怎么 映射进不同队列的？依据什么规则？

接收到报文后，如果信任此优先级则根据报文优先级映射为本地优先级，然 后按照本地优先级进入不同的队列，默认的队列有 0-7 八个队列。映射的时候如果 是 802.1p、exp 则默认按报文中的数值映射，如果是 DSCP 则每八个数值映射为一个 优先级，如 0-7 映射为 0，8-15 映射为 1，以此类推。

02

PHB 什么意思？定义了哪些数值？

PHB 叫逐跳转发行为，即 QOS 域内每台设备在转发报文时都需要进行 QOS 行 为，而为了方便设备做 QOS 转发行为判断，为此定义了标记值的特殊含义，Default PHB 缺省 PHB，Best- Effort，DSCP=000000；Class- Selector PHB(类选择器)定义了 7 个数值，CS1-CS7;Expedited Forwarding PHB (EF 快速转发)数值为 46 (101110)

03

DSCP 中的 AF11 与 AF12 有什么不同？第一个数值表示什么意思？第二个数值又是什么意思？

Assured ForwardingPHB (承诺转发) 12 个值保证数据能被转发，但不保证 快。AF11、 AF12、 AF13、 一直到 AF43，第一个数据表示优先级，对应 CS；即 AF1X 则得 到 CS1 的服务，AF2X 则对应 CS2；后一个数值表示丢弃概率，数值越大，丢弃概率越大。

04

队列的调度机制有哪些？每种调度机制分别有什么优缺点？WRR 与 DRR 有什么区别？WFQ 分配的是带宽还是流量大小？基于什么规则来分配？默认不同队列的带宽一致吗？基于队列的拥塞管理用什么配置？WRR 和 DRR 能组合起来配置吗？PQ 队列可以 配置在低优先级的队列上吗？

拥塞管理即收到数据包在转发出去的时候进行的动作，总的可以分为两大类， 基于队列的拥塞管理和基于类的拥塞管理，基于队列的即按照队列的方式转发，基 于类的即按照分类的方式转发。

1）基于队列的拥塞管理 收到报文，会根据标记字段把报文映射进不同的队列，分别是 0-7 号队列，之 后再把报文转发（调度）出去的这个过程叫拥塞管理，调度方法有以下几种：FIFO（先进先出）（尽力而为服务模型使用）

优点：默认，配置简单；

缺点：发生拥塞情况下，高优先级得不到优先转发；

PQ（Priority Queuing 优先级队列） 高优先级先转发，低优先级后转发；

优点：高优先级可得到优先转发；

缺点：低优先级流量饿死；

RR（Round Robin 轮询 ） 每个周期内，每个队列都调度一个数据包；

优点：不会出现低优先级流量饿死；

缺点：高优先级得不到高带宽；

WRR（Weighted Round Robin 加权轮询队列） 加权循环调度在 RR（Round Robin）调度的基础上演变而来，根据每个队列的 权重来轮流调度各队列中的报文流

优点：避免了 PQ 调度的“饿死”现象。

缺点：基于报文个数来调度，容易出现包长尺寸不同的报文出现不平等调度；低时延业务得不到及时调度。

WFQ(Weighted Fair Queuing 加权公平队列) 默认队列的 WFQ 权重相同，流量平均分配接口带宽。用户可以通过配置修改权 重，高优先权和低优先权按权重比例分配带宽。

优点：可完全按照权重分配带宽；自动分类，配置简单。

缺点：低时延业务仍得不到及时调度；无法实现用户自定义分类规则。

组合队列 PQ+WFQ/WRR/RR 可保证低延时业务得到优先转发，其余业务再用其余调度机制 配置方法：LAN 口：PQ、DRR、WRR、PQ+DRR、PQ+WRR WAN 口：PQ、WFQ、PQ+WFQ

1、用 queue-profile 创建队列模板；

2、各个队列指定用何种调度机制；

3、在接口调用；

2）基于类的拥塞管理 CBQ（Class-based Queueing 基于类的队列）

05

基于类的拥塞管理怎么配置？基于类的队列有几种？BE、AF、EF、LLQ 分别什么意思？每种队列采用什么调度机制？EF 队列和 LLQ 配置的时候注意什么？

CBQ 提供三类队列：

EF 队列（Expedited Forwarding）：满足低时延业务。

EF 队列拥有绝对优先级，采用 PQ 调度机制，仅当 EF 队列中的报文调度完毕后，才会调度其他队列中 的报文。所以配置其带宽为最大带宽。

还有一个特殊的 EF 队列 LLQ 队列（Low delay queue）、AF 队列（Assured Forwarding）：满足需要带宽保证的关键数据业务。使用 WRR 的调度机制，每个 AF 队列分别对应一类报文，用户可以设定每类报文占用的带宽。当系统调度报文出队的时候，会按用户为各类报文设定的带宽将报文进行出队发送， 可实现各个类的队列的公平调度。配置其带宽为最小带宽。

BE 队列（Best-Effort）：满足不需要严格 QoS 保证的尽力发送业务。当报文不匹配用户设定的所有类别时，报文会被送入系统定义的缺省 BE（Best Effort， 尽力传送）类。BE 队列使用接口剩余带宽和 WFQ 调度方式进行发送。配置方法：使用 MQC 来配置

06

队列占满，进来的报文要怎么处理？尾丢弃带来哪些影响？

队列被装满后的传统处理方式：尾丢弃；尾丢弃带来的危害：

1）不加区分的丢包；

2）TCP 全局同步；

3）TCP 流量饿死；不加区分丢包：尾丢弃会丢弃不能进入队列的全部数据包，无论优先级如何；

07

什么叫 TCP 全局同步？画图解释 TCP 全局同步怎么产生的？TCP 流量饿死又是什么意思？怎么解决？

TCP 全局同步：

（1）TCP 的重传机制 超时重传：TCP 为每一个发送的报文段设置一个超时重传（RTO）计时器，计时 器到时则重传。快重传：接收方接收发现一部分报文丢失，立即连续发送 3 个 ACK（重复）报 文，发送方立即重发丢失的报文段。

（2）TCP 拥塞控制慢启动：建立连接时将拥塞窗口设置为一个 MSS（536B）大小，即开始传输时 速率很慢，但按指数方式增长，达到慢启动阈值（默认 56636B）时停下，进入拥塞避免状态；

拥塞避免：拥塞窗口按加法规律增长，每次发送的所有报文都被确认，拥塞 窗口就增大一个 MSS，此阶段持续增长，直到拥塞被检测到。

拥塞检测：如果检测到拥塞，窗口必须减小 检测到拥塞的方法，发送方发生重传事件，即 RTO 计时器超时或收到 3 个重 复的 ACK 报文，慢启动的阈值下降一半。

①发生超时，出现拥塞可能性较大，阀值减半，拥塞窗口设置为一个 MSS 大小， 开始一个慢启动阶段

②如果收到 3 个 ACK 报文，出现拥塞可能性较小，阀值减半，拥塞窗口设置 为阀值，再开始一个拥塞避免阶段

如图表示 TCP 全局同步过程，一种颜色表示一种流量的发送快慢转换过程。一 条链路上同时有多条 TCP 流量则会呈现此图，多条 TCP 流量同时增大或者同时减小 的过程称之为 TCP 全局同步。

TCP 流量饿死：TCP 有流量发送快慢控制机制，发生拥塞有降低速率，而 UDP 则没有，并且会尽力抢占带宽，所以 TCP 流量一直降低速率，最终导致 TCP 流量很 小。

08

RED 可以缓解尾丢弃的到来吗？RED 可以解决尾丢弃带来的哪些影响？为什么？RED 和 WRED 有什么区别？RED 什么意思？

解决方法：

为避免 TCP 全局同步，可在队列未装满时先随机丢弃一部分报文。通过预 先降低一部分 TCP 连接的传输速率来尽可能延缓 TCP 全局同步的到来。这种预先 随机丢弃报文的行为被称为早期随机检测（RED）。RED 在丢弃报文时是随机丢弃， 所以可以让 TCP 流量在不同时间检测到丢包，从而让不同 TCP 流量在不同时刻增大 或者降低速率，所以可以缓解 TCP 全局同步现象。其画图表示如图，可配置，队列长度在 20%前不丢弃，而队列长度在 20%到 80% 之间丢弃比例最大为 50%，队列长度超过 80%则全部丢弃。

优点：可尽量缓解 TCP 全局同步的到来

缺点：不加区分丢包和 TCP 流量饿死无法缓解；因为 RED 丢弃报文是随机丢弃， 不会对报文加以区分，所以不加区分丢包无法解决；而丢弃过程并不能限制 UDP 流 量大小，所以 TCP 流量饿死现象还存在。

09

WRED 呢？WRED 能缓解尾丢弃的到了吗？能解决尾丢弃带来的所有影响吗？怎么解决的？WRED 是根据什么区分流量的

WRED（Weighted Random Early Detection）技术

如图，可实现每一种优先级都能独立设置报文的丢包的高门限、低门限及丢包率，报文到达低门限时，开始丢包，到达高门限时丢弃所有的报文，随着门限的增 高，丢包率不断增加，最高丢包率不超过设置的最大丢包率，直至到达高门限，报文全部丢弃。这样按照一定的丢弃概率主动丢弃队列中的报文，从一定程度上避免 了尾丢弃带来的所有缺点。

配置方法：

1）基于队列的 WRED;先定义丢弃模板；用 queue-profile 绑定丢弃模板；最 后在接口下调用

2）基于 MQC 实现；先定义丢弃模板；用 MQC 模型，流行为与丢弃模板绑定