QOS-基本擁塞管理機制（PQ CQ WFQ RTPQ）

QOS-基本擁塞管理機制（PQ CQ WFQ RTPQ）

2018年7月7日    20:29

 

擁塞：是指當前供給資源相對於正常轉發處理需要資源的不足，從而導致服務質量下降的一種現象

 

擁塞管理概述：

 

• • 需要發送的數據流量大於設備發送接口的發送能力時，會產生擁塞。
  • 擁塞管理是指在網絡發生擁塞時，進行管理和控制，合理分配資源。通常采用隊列技術實現
  • 報文按一定的策略緩存到隊列中，然后按一定的調度策略把報文從隊列中取出，在接口上發送出去

          

路由器擁塞管理：

 

 

• • 接口不擁塞，報文直接入發送隊列
  • 接口擁塞，報文按規則入軟件隊列
  • 路由器軟件隊列包括：系統隊列和 用戶隊列
  • 系統隊列包括：緊急隊列（PPP協議等）和協議隊列（OSPF  hello報文等），不會修改
  • 系統隊列優先於用戶隊列調度

 

交換機擁塞管理：

 

• • 報文在入端口，根據映射表入本地隊列
  • 報文在出端口，進行隊列調度后發送
  • 常用的隊列：SPQ、WRR

 

 

FIFO隊列 原理：（IP網絡中默認的隊列）

 

 

• • 所有報文按轉發到達出接口的先后順序入隊
  • 隊列滿后，進行尾丟棄
  • 按進入 隊列的先后順序出隊列，先入先出

 

 

FIFO隊列配置命令：

 

 

增加FIFO隊列的長度可以減少丟包，但同時也可以增加延遲

 

PQ隊列原理：（優先隊列）是針對關鍵業務設計的，Top（高優先隊列）、Middle（中優先隊列）、Normal（正常優先隊列）和boottom（低優先隊列）

• • 按類別入隊，隊列滿后尾丟棄
  • 優先級高的隊列先調度
  • 加入top隊列一直是滿的，會導致優先級低的隊列，一直得不到調度（Normal為默認隊列）

 

 

 

PQ隊列調度：

 

 

• • 高優先級業務的帶寬和時延得到最大限度的保證
  • 如果高優先級業務持續占據帶寬，會導致低優先級業務一直得不到調度

 

PQ隊列配置任務：

• • 配置PQL（優先隊列列表）
    • 配置默認情況下，流量進入的隊列
    • 配置PQ隊列的分類規則（acl）
    • 配置PQL各隊列的長度
    • 默認隊列配置
  • 將PQL應用到接口

 

配置無對應規則的報文所入的缺省隊列：（默認隊列為PQ的4個隊列之一，是普通隊列）

 

 

 

配置PQ隊列長度：

 

配置基於接口的分類規則：

 

配置基於協議的分類規則：

 

同一個PQL內可以配置多個分類規則，各規則可以使用不同的分類方式。報文入隊的時候，按規則的配置順序進行匹配，如果發現報文與某個規則匹配，則入該規則對應的隊列。

 

 

在接口上應用PQL：

 

 

dis qos pql 5                //顯示PQL配置信息

 

dis  qos pq int e9/0                   //顯示PQ統計信息

 

 

CQ隊列原理：（定制隊列）提供了16個 隊列

CQ允許根據 報文的特征建立匹配規則，將報文分為16類，沒類報文對應CQ中的一個隊列。接口擁塞時，報文按匹配規則被送入對應隊列；如果報文不匹配任何規則，則被送入默認隊列。默認隊列默認為CQ的隊列1，可以修改。

• • 按類別入隊，隊列滿后尾丟棄
  • 各隊列輪詢調度
  • 其實有17個隊列，0是給系統隊列使用的，用戶不能修改。
  • 默認每個隊列傳1500個隊列（閾值）

 

 

CQ隊列調度：

 

 

由於CQ不能對數據包進行分片，之前有個數據包1499Byte，不到1500，當有個1500個字節的數據包過來，它還會傳這1500Byte，所以有可能一次最多轉發1500+1499個字節，所以每個隊列傳數據包可能為1500---2999Byte。大於1500Byte才會發。

 

CQ隊列配置任務：

• • 配置CQL（定制隊列 列表）。系統預定義了16個CQL，用戶可以選擇其中的一個來配置自己需要的定制隊列。
    • CQ中各隊列的匹配規則
    • CQ中各隊列的長度與發送額度
    • 默認隊列
  • CQ隊列應用到接口。應用配置好的CQL，在接口應用CQ隊列。

 

 

• • 配置無對應分類報文所入的缺省隊列

 

• • 配置CQ隊列長度：

 

• • 配置CQ隊列份額（修改隊列緩存的大小）連續發送字節數（默認1500）

 

• • 配置基於接口的分類

 

• • 配置基於協議的分類規則

 

• • 接口上應用CQL

 

 dis  qos cql  1                            //顯示CQL配置信息

dis   qos  cq  int   e9/0            //顯示CQ統計信息

 

 

 

WFQ隊列原理：（加權公平隊列）對報文按流特征進行分類。

在IP報文中，根據源IP地址、目的IP地址、源端口號，目的端口號、協議號、優先級等特征，采用Hash算法，盡量將不同特征的流分入不同的隊列類別中，這個過程稱為散列。

• • 流量五元組散列入隊，加權公平出隊，丟棄策略為尾丟棄或WRED丟棄
  • 出隊時，WFQ按隊列優先級的比例來分配各個隊列應占有的出口帶寬

 

WFQ入隊機制：

• • 先按五元組哈希成組，組內優先級（IP或DSCP）相同的報文被分配到相同的隊列
  • 受資源限制，五元組不同的報文可以哈希到相同的組

 

WFQ隊列調度：

 

 

• • WFQ隊列調度時，系統隊列優先調度；當系統隊列空時，才調度WFQ隊列
  • WFA隊列間的調度方式也是輪詢調度，同一個隊列內部出隊方式時FIFO隊列

 

WFQ隊列特點：

• • 優點：
    • 配置簡單，各個流都可以獲得公平的服務
    • 有利於小包轉發，降低交互式操作的響應時間
    • 可以與WRED丟棄策略組合應用
  • 缺陷
    • 不能對流的分類進行手工干預
    • 不適合時延敏感的應用

 

WFQ配置：

WFQ隊列長度的配置范圍為1~1024,默認為64，最大隊列數為16~4096，默認為256.

 

• • 配置WFQ的權重類型、隊列長度、隊列總數

 

 

權重類型：對於使用IP precedence的IP報文，當配置WFQ隊列數為16時，WFQ對報文根據五元組特征Hash時最大能分成2個組，每個組里包含8個隊列。如果使用DSCP優先級作為權重，則WFQ隊列數最小要配置成64，此時所有報文都屬於一個組。

 

dis  qos  wfq  int  e0/0            //wfq隊列顯示

 

RTPQ隊列原理：即RTP（實時傳輸協議）優先對列，是一種保證實時業務（包括語音與視頻業務）服務質量的隊列急速。（應用層）UDP

• • 原理：將承載語音或視頻的RTP報文送入高優先級隊列，使其得到優先發送，保證延遲和抖動降為最低限度
  • 匹配的實時業務入RTPQ隊列，其他業務入其他數據隊列處理
  • 實時業務入隊前按配置的帶寬進行限速處理
  • RTPQ隊列滿后進行丟棄
  • RTPQ將RTP報文定義為端口在一定范圍內並且為偶數的UDP報文，並以此歸類依據。
  • RTP隊列可以通FIFO、PQ、CQ和WFQ結合使用，而它的優先級最高

 

 

• • 為了防止RTPQ隊列報文占據全部帶寬，導致其他隊列“餓死”，RTPQ在報文入隊前先進行流量監管處理，超過RTPQ預留帶寬的流量直接丟棄，在預留帶寬以內的流量才能入隊。

 

RTPQ隊列調度：

 

 

RTPQ隊列的優先級僅次於緊急隊列，等同於協議隊列，高於其他的數據隊列。隊列調度時，先檢查緊急隊列是否為空，如果不空，調度緊急隊列報文發送，否則輪詢調度RTPQ和協議隊列。RTPQ隊列內部采用FIFO的出隊方式。RTPQ隊列每一個報文出隊轉發后，將調度全交給緊急隊列，如果緊急隊列不空，發送緊急隊列報文，否則發送協議隊列的調度。協議隊列調度完成后，開始下一輪的調度。如果RTPQ和協議隊列都為空，開始調度其他數據隊列，其他數據隊列為空，或者一次調度完成后，開始下一輪的隊列調度。

 

RTPQ的配置與顯示：

• • 配置RTPQ隊列：

 

• • RTPQ隊列顯示：

 

可以與CQ、PQ、WFQ共用，但是不能與CBQ共用，因為CBQ里面有EF隊列