WFQ/CBWFQ/LLQ
加權公平排隊(Weighted Fair Queuing)縮寫 WFQ。
它是一種擁塞管理算法，該算法識別對話(以數據流的形式)、分開屬於各個對話的分組，並確保傳輸容量被這些獨立的對話公平地分享。WFQ是在發生擁塞時穩定網絡運行的一種自動的方法，它能提高處理性能並減少分組的重發。
WFQ(weighted fair queuing加權公平排隊)
目標：
1爲每個活動流提供公平的帶寬分配機制
2爲少量交互流提供更快的調度機制
3爲高優先級流提供更多的帶寬
WFQ：是一種基於流的排隊算法，到達的數據包被分成多個流，每隔流都被分配給一個FIFO隊列。
可以基於IP和TCP或UDP頭中以下字段標識流：源IP地址 目的IP地址 協議號 TOS 源TCP/UDP端口號 目的TCP/UDP端口號
WFQ插入和丟棄策略
WFQ有一個保持隊列（hold queue）,保持隊列=WFQ系統中數據包占用的所有內存之和，數據包到達時，保持隊列已滿，那就丟棄數據包（WFQ主動丟棄WFQ aggressive dropping）
例外：數據包分配到一個空隊列，不會丟棄
WFQ的優缺點：
主要優點 ：
WFQ配置簡單，無需顯示分類
不會讓任何流得不到處理機會，能夠保證所有流的吞吐量
從最主動的流中丟棄數據包，可以爲非主動流提供更快的服務
是一種標準.簡單的排隊機制，大多數CISCO平臺和IOS版本都支持
缺點
WFQ的分類和調度機制是不可配置和無法修改的
WFQ僅支持低速鏈路（2.048Mbit/s及以下的）
WFQ不能爲流量流提供帶寬和時延保證
WFQ系統中多個流量流可能會被分配到同一個對列中去
WFQ的配置和監控
默認情況下，所有低速（2.048Mbit/s及以下）串行接口都啓用WFQ
接口模式下： fair-queue [cdt] [dynamic-queues] \\ cdt 爲擁塞丟棄門限,dynamic 動態隊列 默認爲256
hold-queue max-limit out \\定義保持隊列
CBWFQ基於類別的加權公平排隊
比WFQ更好，因爲可以創建用戶自定義的類別，併爲所有類別分配專屬隊列，每個隊列都有用戶自定義的（最小）帶寬，而且在有可用帶寬隊列可以使用更多帶寬。
最多可以創建64個用戶自定義類別，每個隊列都是有保證帶寬和最大包門限的FIFO隊列，一旦達到最大，就會產生尾部丟棄。
分類，調度和帶寬保證
帶寬
帶寬百分比
帶寬剩餘百分比
CBWFQ的優點
可以創建用戶自定義的類別，利用MQC的分類映射可以很容易地定義這些流量類別
可以基於用戶策略和用戶意願爲每種流量類別分配/預留帶寬
可以基於現有網絡應用和用戶策略定義最多64個固定類別，從而提供微調手段，而且擴展性更好
缺點：沒有爲實時性應用提供合適地隊列（VOIP 和 視頻）無法保證低時延
配置和監控CBWFQ
LLQ
包含了一個優先級隊列，使其非常適合時延和抖動敏感型應用
優點：
LLQ具有CBWFQ的所有優點，包括自定義流量類別，爲每種類別的流量提供帶寬保證，並確保可以在所有類別的隊列上應用WRED。（嚴格優先級隊列除外）
對於LLQ和CBWFQ來說，任何沒有被顯示分類的流量都被認爲class-default流量，可以將class-default流量類別隊列由FIFO改爲WFQ,需要時也可以用WRED.
LLQ最大優勢 可以爲時延和抖動敏感型應用的流量提供一個或多個有帶寬保證的嚴格優先級隊列
LLQ並不侷限於特定平臺或傳輸介質
配置和監控LLQ
Weight Fair Queuing
配置WFQ:
1)特點:
*基於流的隊列算法 //把同一個流的數據放到同一個隊列中(即WFQ的分類是基於"流"，用戶無法控制)
*將交互式流量(eg.telnet對響應時間要求高) 放在隊列的前面，以減少響應時間;
將剩餘帶寬在不同流之間公平地分配;
防止大數據量的流(eg.FTP) 獨佔出接口
|-----FTP-----|
---------------------------R
|-telnet-|
交互式流量
FIFO：
FTP先到，先發送
WFQ:
在 "最後" 判斷報文到達時間,何時收到完整的數據包，才認爲到達
使得小報文(telnet)優先進行發送，該情況，認爲telnet報文先到達設備
WFQ的思想:
i, 爲每個流創建一個專用的隊列，避免隊列的 飢餓，延遲，抖動 等
ii, 在所有流間公平，正確地分配帶寬
iii, WFQ使用 [IP優先級] 作爲分配帶寬的權重
注:WFQ中的flow亦稱爲conversation(會話)
注:在帶寬小於等於E1(2.048Mbps)的串行接口上 缺省 使用WFQ
注:WFQ不能在配置 Tunneling 和 加密 的接口上使用
---Forwarded Packets|
|
|
Flow 1--------Weight值-------------
| \
| \
Flow 2--------Weight值------------- WFQ Scheduler-----> Hardware Queuing
| /
| /
Flow 4096--------Weight值----------
|
權重高的，一次多放報文;權重低的，一次少放報文即體現公平原則，同時體現權重原則
WFQ uses per-flow FIFO queues
參數:
-------IP-------- --TCP-- Payload Source IP Address
/ \ / \ Destination IP Address
Src. Dst Proto ToS | Src. Dst Source TCP or UDP Port
Addr. Addr Port Port Destination TCP or UDP Port
↓ ↓ ↓ ↓ ↓ ↓ Transport Protocol
ToS Field
Hash Algorithm
|
|-------→Queue Number
隊列256，但網絡中流1000個----→不同流配到同一個隊列中
希望: 一個流對應一個隊列
調度時就無法體現每個流公平調度機制
HASH結果:
flow 1
----→1個隊列 。同一個隊中不同的流是不作區分的
flow 2
解法:將隊列個數調大
在WFQ中，要保證 隊列個數 要大於 網絡中流的個數，這樣調度方式較爲合理
流的多少設備無法控制
用戶不干預 對流的分類，是自動分類的，WFQ的分類是由內部算法自動計算
帶來的缺點:不能人工定義類別
用戶可以定義信息:
WFQ隊列:
8個隊: 保留下來給系統使用Systems packets
0~1000個隊: 保留給RSVP flows (0~1000)
剩下隊列: 動態隊列
一般接口配成256個隊
隊列可以調整，保證隊列個數超過實際網絡流的個數
the number of queues configured has to be significantly larger
than the expected number of flows
2)WFQ的分類方式
* 源IP地址 / 目標IP地址 / 協議號 / ToS字段 / 源TCP或UDP端口號 / 目標TCP或UDP端口號
注:WFQ中利用這些參數作爲 hash算法 的輸入參數，可以計算出對應隊列的 索引號
因此，通常情況下，同一個流的數據將被分類到同一個隊列中
注:WFQ中存在8個隊列用於系統的報文發送,最多可配置1000個隊列用於RSVP流，另外用戶可以配置動態隊列的個數
WFQ缺省使用的動態隊列數取決於接口帶寬，通常爲256個動態隊列,該參數取值範圍是16~4096(必須是2的整數次冪)
注：若網絡中存在較大的併發流，則可能2個不同流間分類到同一個隊列中
因此在配置動態隊列數量時，應該超過網絡中實際併發流的數量
3)WFQ的插入，丟棄策略
WFQ Insertion and Drop Policy
---Forwarded Packets|
|
|
Flow 1--------Weight值-------------
| \
| \
Flow 2--------Weight值------------- WFQ Scheduler-----> Hardware Queuing
| /
| /
Flow 4096--------Weight值----------
|
|
隊列多，但是報文是否能加入其中，要看實際情況：
1)-每個隊列有長度(上限滿了)，報文無法加入，丟棄! ---單獨隊列滿
2)-隊列中報文存在緩存，所有隊列所有報文的數量有上限---所有報文數達到上限
以上二因素，可導致報文無法排到隊列中!報文丟包!
WFQ always drops packets of the most aggressive flow
比較活躍的流，報文量最多的流進行丟棄，懲罰
丟包時特殊情況:
Drop mechanism exceptions:
1)要排到的隊列是空的，不會被丟棄
a packet classified into an empty queue is never dropped
2)IP優先級不影響丟包機制，丟包時不考慮IP優先級
the packet IP precedence has no effect on the dropping scheme
配置WFQ優點和缺點:
Benefits:
1)simple configuration 配置簡單
int s0
fair-queue //表示該接口使用了WFQ
不需要分類，用戶無法配置
no need for classification to be configured
2)保證所有流都可以得到帶寬,不會出現如PQ把低優先級別的數據餓死
Guarantees throughput to all flows
3)丟包時會優先丟棄比較活躍的報文
Drops packets of most aggressive flows
4)在思科大部分平臺上都可以支持WFQ
supported on most platforms / in most Cisco IOS versions
Drawbacks:
1)多個流經過HASH算法後有可能落到同一個隊列中
Possibility of multiple flows ending up in one queue
原因
1)--隊列配得太少
(2)--網絡中流太多，超過隊列個數
2)不能對流進行分類，不能控制
lack of control over classification
3)只能在帶寬小於等於2M的接口上支持
supported only on links less than or equal to 2 Mb
4)對不同流不能保障多少帶寬，完全由WFQ的算法決定
每個不同的流是無法提供固定的帶寬保證,可控性差
cannot provide fixed bandwidth guarantees
配置命令:
route(config-if):fair-queue cdt dynamic-queues reservable-queues
動態隊列個數 保留隊列個數
reservable-queues
保留隊列個數：針對RSVP流,可以保留一定的隊列，缺省是0，範圍0~1000
dynamic-queues
動態隊列個數: 缺省是256,流確實很多，可以調大，最大4096
cdt:
每個隊自己的長度
一個數據排到第一個隊中，cdt=64，如果該隊的報文己達到64,新的報文丟包!
每個隊中排的報文數量是有限的
所有隊列加起來，上限:
hold-queue max-limit out
缺省1000
一個報文是否在WFQ中排到隊列中的二個因素:
1)--本隊列是否己滿
2)--所有隊列是否超出隊列上限 ----超出報文丟棄
驗證:
show interface s1/0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
size: 0 當前隊列的報文數
max total: 1000(總數) 所有隊列中報文累加最多能放報文的數量
threshold: 64 每個隊最多可以放的報文數量
drop: 0 丟包情況
Conversations 0/1/256 (active/max active/max total)
WFQ中conversation(會話)=流
max active: 歷史統計中最多的流數=1
active: 目前流數=0
max total: 256個動態隊列 [若每個隊都放64,超過]
若max active > max total，就要將隊列調得更大
int s1/0
fair-queue 128 4096 1000
cdt 動態隊列個數 所有隊列最多能存多少數據(最多1000)
Output queue: 0/1000/128/0 (size/max total/threshold/drops)
size: 0 當前隊列的報文數
max total: 1000(總數不變) 所有隊列中報文累加最多能放報文的數量
threshold: 128 每個隊最多可以放的報文數量
drop: 0 丟包情況
Conversations 0/1/4096 (active/max active/max total)
max total: 4096個動態隊列,防止不同流配到同一個隊列中
若這樣就無法基於流來調度，沒法區分
缺省：
1)--若帶寬小於等於2.048M ------>WFQ
2)--其他情況------>FIFO
/ CBWFQ
WFQ----改進--->---/
\
\ LLQ
WFQ的hold-queue limit表示所有隊列累計能夠存放的最大報文數量
CDT(擁塞丟棄門限值)表示單個隊列中能存放的最大報文數量
i,WFQ在以下情況時丟棄報文：
*當一個隊列中的報文數量超過CDT,此時就算hold-queue未滿，該報文還是丟棄
注：該丟棄方式可以用於限制最活躍的數據流
* 若所有隊列中的報文總數已經超過hold-queue
ii、例外情況
* 若一個報文被排入空的隊列中，它在任何情況下都不會被丟棄
* IP報文中的IP優先級字段不會影響WFQ的丟棄機制。
4）配置WFQ
Router(config)#int s0
Router(config-if)#fair-queue 128 1024 100
Router(config-if)#hold-queue 1200 out
注：設置s0接口使用WFQ，並設置動態隊列數量爲1024個隊列，爲RSVP流保留100個隊列；
每個隊列能夠存放128個報文（CDT），所有隊列最大的報文數量爲1200（Hold-queue）
查看WFQ的命令
show interface 接口名稱
show queue 接口名稱
注：在WFQ中，weight的計算方式爲4096/(IP優先級+1)或者32384r/(IP優先級+1)
因此在show queue中看到的weight值越大，表示權重越低。
------------------------------------
5、配置CBWFQ和LLQ
WFQ: 用戶無法控制分類，由HASH算法自己決定
CBWFQ:讓用戶對流量自己來分類
WFQ 對正常流量處理沒問題，但是對語音流量顯得"太公平"(語音要求低延遲)
CBWFQ:考慮到公平特性，並沒有考慮到語音的應用
爲了保證語音可以優先傳輸，引入LLQ
Queuing Methods Combined融合網絡應用:
包括:視頻，語音，普通數據
LLQ = CBWFQ + Priority Queue
CBWFQ特點:
1)能夠給不同的類保障一定的帶寬
CBWFQ is a mechanism that is used to guarantee bandwidth to classes
2)對傳統的WFQ作了擴展支持用戶自己定義流量的分類:
3)隊列的個數和類別是一一對應,給每個class 保留帶寬
a queue is reserved for each class
CBWFQ Architecture(構造)
classification由用戶定義
並流量分配到不同class中,針對不同class定義不同帶寬值
|---報文4--> Class 1 \
| Bandwidth = 64 \
| \
|---報文3--> Class 2 \
-4-3-2-1->| Bandwidth = 128----- WFQ----2-1--4--3---->
| / 報文
| /
|---報文2-1-->Class 3 /
| Bandwidth = 32
權重和帶寬 成 正比關係
帶寬值越大，權重值越大,通過帶寬的參數配置，控制權重比例
配置工作
分類:
策略:指定類有多少帶寬Bandwidth avaliability can be defined by specifying:
帶寬指定方式:
(1) ---Bandwidth ( in kbps ) //<8-2000000>
(2) ---Percentage of bandwidth //percent
百分比
(3) ---Percentage of remaining available bandwidth //remaining
剩餘可用帶寬的百分比
計算公式:
Bandwidth(avail) = Bandwidth * MaxReservable - SUM(all fixed guarantees)
剩餘的可用帶寬 = 接口帶寬值*最大的保留百分比 - 己經分配出去的帶寬
1.544M * 75%(缺省值)
並不是把所有帶寬都轉發我們的數據，
一些系統的報文也需要發送，通常會保留25%作爲系統的目的使用
缺省情況下接口保留帶寬值75%(即用戶可以使用75%帶寬)
-----10G帶寬，若使用到7.5G時，就要擴容!
CBWFQ:
Benefits:
1)自己可以分類
Custom-defined classifications
2)對不同類進行帶寬的分配
Minimum bandwidth allocation
3)具有更好的調節能力和擴展性
Finer granularity and scalability
Drawback:
語音無法得到很好的服務質量，對語音來說不合適，語音要求有比較小的延遲
Voice traffic can still suffer unacceptable delay
CBWFQ的缺點-----太公平，輪詢方式調度，沒法保證語音業務得到保障
CBWFQ配置:
定義一個類
定義 策略
在策略policy-map裏配置帶寬:
router(config-pmap-c)#
bandwidth bandwidth
bandwidth percent percent
bandwidth remaining percent percent
隊列滿了如何丟包?
router(config-pmap-c)#
queue-limit queue-limit
--定義每個隊能存放的報文數量(隊列長度)
eg.
queue-limit 128 //報文超過128就丟包，丟包方式:Tail-Drop
隊列滿之後，後繼報文才會丟棄
--丟包方式--
方式一:尾丟棄
policy-map mypolicy
class class01
bandwidth 128
queue-limit 128 //尾丟棄
方式二:random-detect隨機早期檢測
policy-map mypolicy
class class01
bandwidth 128
random-detect //隨機早期檢測“丟棄”
二者衝突!
fair-queue [number-of-dynamic-queues]
配置實例：
HTTP流量保障256Kbps帶寬
FTP流量保證512Kbps帶寬
class-map class_HTTP //定義類
match protocol http
class-map class_FTP
match protocol ftp
class-map class_BT
match protocol bittorrent
policy-map Policy_HTTP_FTP //定義"策略"
class class_HTTP
bandwidth 256
class class_FTP
bandwidth 512
class class_BT
drop
class class-default //網絡中剩下流量(除了http,ftp)使用WFQ自動放到fair-queue
fair-queue
int fa0/0 //最後應用到相應物理接口
service-policy output Policy_HTTP_FTP
//問題:語音無法保障
相對CQ-字節數無法保障帶寬比例,WFQ可以保證
查看命令: show policy-map interface
另
配置實例:
class-map match-all class_office
match access-group name acl_office
class-map mathc-all class_student
match access-group name acl_student
policy-map polic_ald
class class_office
priority 1920 //優先級隊列，保留帶寬1.92M
class class_student
shape average 128000 //整形,最多帶寬128k
class class-default
fair-queue //其它所有流量，加權公平隊列
inter f0/0
service-policy output policy_ald //接口應用
限速，報文過濾 使用QoS MQC方式!
ACL只能過濾第三層，第四層信息，不能過濾應用層
1）CBWFQ
i、特點
* 確保每種類別流量的帶寬
* 擴展WFQ的功能，提供用戶自定義流量類別的功能
* 每一種類對應一個隊列
注：CBWFQ支持多個類，在每個類對應的FIFO隊列中缺省採用Tail Drop方式進行丟包，也可以支持WRED方式。
ii、分類
使用class－map方式對流量進行分類
iii、調度
根據不同類的權重來保證帶寬。（注：思科設備會根據給不同類配置的帶寬值或百分比，計算每個類的權重）
帶寬的配置方式：
a）bandwidth（kbps）
命令：bandwidth 帶寬值
注：配置的帶寬值必須在該接口的保留帶寬內。（缺省情況下一個接口的保留帶寬爲75％，其餘保留給系統用途）
b）帶寬百分比（接口可用帶寬的百分比）
命令：bandwidth percent 百分比
c）剩餘可用帶寬的百分比
命令：bandwidth remaining percent 百分比
注：如何配置接口的保留帶寬？
int s1/0
max-reserved-bandwidth 百分比（缺省爲75％）
配置實例：
HTTP流量保障256Kbps帶寬
FTP流量保證512Kbps帶寬
class-map class_HTTP
match protocol http
class-map class_FTP
match protocol ftp
class-map class_BT
match protocol bittorrent
policy-map Policy_HTTP_FTP
class class_HTTP
bandwidth 256
class class_FTP
bandwidth 512
class class_BT
drop
class class-default
fair-queue
int fa0/0
service-policy output Policy_HTTP_FTP
------------------------------
A priority queue is added to CBWFQ for real-time traffic
新增PQ，目的是爲了實時流量提供服務
CBWFQ:爲每個流量進行分類，對類定義帶寬
LLQ目的:在CBWFQ之上，對實時的流量提供更高優先級的支持
高優先級的流量保證:
High-priority classes are guaranteed:
低延遲保證
-Low-latency propagation of packets
保障一定帶寬
-Bandwidth
在任何情況下，語音數據都優先得到發送
網絡中語音流量過多，是否會佔用更多的帶寬?--NO
高優先級的數據在保證"低延遲傳播"和"帶寬"時，可以管制"policy"
當網絡發生擁塞時，高優先級的分類所佔用的帶寬 不能超過 保障的帶寬值
High-priority classes are also policed when congestion occurs-they
then cannot exceed their guaranteed bandwidth
保留128K帶寬，上限值!發生擁塞時不允許超過128k值
超過該值的數據丟棄!
低優先級的分類 還是 CBWFQ!
Lower-priority classes use CBWFQ
LLQ Architecture架構:
【Forwarded Packets】
↓ 【Priority Queue】上半部分優先級隊列,分類將重要數據排到PQ中
↓
Class ---→Bandwidth ---→
Priority Policing |→Priority Queue----→ |
↓ |→ (FIFO) |
Class ---→Bandwidth ---→ V V V V |
Priority Policing |
↓ |
↓ |----→【Hardware
↓ | Queuing System】
↓ 【 CBWFQ 】剩下流量按CBWFQ分類 | Hardware Queue ----→Interface
Class 1?---->Tail-Drop--->Queue 1 ---→| | V V V
↓ | |
↓ | CBWFQ---→| V=Voice 語音優先轉發，然後纔是其它類別數據
Class 2?---->Tail-Drop--->Queue 2 ---→|Scheduler
↓ |
↓ |
Class 3?---->Tail-Drop--->Queue 3 ---→|
LLQ基本可以滿足企業中融合的網絡應用
支持語音對網絡的低延遲，抖動小，保障帶寬
對其它流量提供公平處理
LLQ Benefits:優點
1)高優先級隊列服務質量很到保證，特別是針對語音業務
High-priority classes are guaranteed:
--Low-latency propagation of packets
--Bandwidth
2)LLQ包含了CBWFQ,所以網絡流量的分類，用戶可以自己定義!
Entrance criteria to a class can be defined by an ACL
CBWFQ配置參數: bandwidth
LLQ的配置:
router(config-pmap-c)#
priority bandwidth [burst] // 表示這個類所處的隊列是優先級隊列
給優先級隊列保證的帶寬
*Traffic exceeding the specified bandwidth is dropped if congestion exists;
otherwise,policing is not used
若優先級較高的數據流量在網絡擁塞時流量超出定義的帶寬值
超出部分將被丟棄!
若網絡沒有擁塞，這個類的流量是可以超過帶寬值
作的策略，網絡沒有擁塞時，不會生效!
網絡擁塞之後，PQ隊列中的數據最大的帶寬不能超過bandwith值
router(config-pmap-c)#
priority percent percentage [burst]
接口帶寬的百分比
配置實例:
class-map voip
match ip precedence 5 (通常IP優先級=5爲語音流量)
class-map mission-critical (關鍵業務流量)
match ip precedence 3 4
class-map transactional (事務型流量)
match ip precedence 1 2
policy-map Policy1
class voip
priority percent 10 //針對VOIP類使用PQ,這路流量在任何情況下都是優先發送
同時最大可以帶寬爲接口帶寬的10%
class mission-critical \
bandwidth percent 30 \
\
class transactional / ----CBWFQ方式進行調度，分別保障30%和20%接口帶寬
bandwidth percent 20 /
class class-default -----剩下其它隊列採用缺省的WFQ調度
fair-queue
2）LLQ（低延遲隊列）
i、特點
在CBWFQ中添加一個優先級隊列用於實時的流量。
* 高優先級隊列得到如下保障：
a）低延遲的報文轉發
b）帶寬
注：在擁塞發生時，高優先級的流量同時受到管制---即它們佔用的帶寬不能超過它們所保障的帶寬。
* 低優先級隊列使用CBWFQ。
ii、配置LLQ
priority 帶寬值----爲一個類分配固定的帶寬值確保快速轉發；若擁塞時，超過該帶寬的流量將被丟棄。（若沒有擁塞，將不會使用管制）
配置實例：
class-map voip
match ip precedence 5
class-map mission-critical
match ip precedence 3 4
class-map transactional
match ip precedence 1 2
policy-map policy1
class voip
priority percent 10
class mission-critical
bandwidth percent 30
class transactional
bandwidth percent 20
class class-default
fair-queue
int s1/0
service-policy output policy1
使用該QoS的結果：
i.若網絡沒有擁塞，所有數據都可以得到調度!
ii,若網絡發生擁塞，voip類的數據優先發送，並且它佔用的帶寬不能超過接口的10%。始終優先發送，流量太大會管制!
mission-critical類的數據可以保證它至少有30%*接口帶寬(CBWFQ保證發生擁塞時的下限，至少有30%的帶寬)
爲什麼voIP中需要使用CAC（呼叫接入控制）來限制併發的voip呼叫數量?
CAC: QoS無法對不同的voip呼叫進行區分，若未使用CAC，則一旦呼叫數量超出一定的數量，
在網絡發生擁塞時，可能導致所有呼叫的報文被丟棄(具體丟哪個呼叫不一定)，使得所有呼叫的質量下降。
使用CAC來限制網絡中併發呼叫數據的原因!
網絡沒有擁塞，說明硬件隊列沒有滿，一個數據要轉發，直接排到硬件隊列!(硬件隊列不能調度)能調度的只是軟件隊列部分
一般情況下，硬件隊列長度不是很長，若做很長，語音就沒法得到合理保證
查看不同平臺硬件隊列長度：
show control int s0/0 -2個硬件隊列
show control int fa0/0 -4個硬件隊列
查看命令:
來觀察接口中使用的隊列情況
show policy-map interface f0/0
Summary:
FIFO
PQ ---機制簡單配置麻煩
CQ ---機制簡單配置麻煩
WFQ
CBWFQ ----適用
LLQ