比較流量管制和流量調節以限制頻寬

簡介

本文說明流量調節和流量管制之間的功能差異，兩者都會限制輸出速率。

必要條件

需求

本文件沒有特定需求。

採用元件

本文件所述內容不限於特定軟體和硬體版本。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

背景資訊

本文件釐清流量調節與管制的功能性差異。兩種功能都能限制流量輸出率。兩種機制都將權杖貯體當作測量封包速率的流量計測工具。如需詳細瞭解權杖貯體，請參閱什麼是權杖貯體

本檔案中的概念仍與瞭解Cisco QoS設計相關。流量調節和流量策略繼續用於實施最大流量速率和管理擁塞。對於新部署，思科建議在該平台支援時使用模組化QoS命令列(MQC)基於類的整形和基於類的策略。包括通用流量調節(GTS)、訊框中繼流量調節(FRTS)、承諾存取速率(CAR)和速率限制指令等舊式機制，以用於歷史背景或支援平台特定討論。

管制與調節

流量管制會傳播峰值。當流量速率達到設定的上限時，過多的流量會遭到捨棄（或加上備註）。 於是產生的結果會是包含波峰的輸出率，狀似鋸齒。相比管制，流量調節則是將過多的封包保留在佇列中，然後將它們排程在累積一段間後再傳輸。流量調節會產生曲線順暢的封包輸出率。

下一張圖表所示為兩種流量選項的主要差異。

管制與調節

調節就表示存在佇列，且有充足的記憶體可以緩衝延遲的封包，管制則否。佇列是一種傳出的概念；封包在離開介面時排入佇列，且可加以調節。管制則只能套用在介面的傳入流量。啟用調節時，請確認您有充足的記憶體。此外，如要啟用調節，您需要有功能可以為任何延遲封包排程之後的傳輸。上述排程功能可讓您將調節佇列分門別類到不同佇列。類別式加權公平佇列 (CBWFQ) 和低延遲佇列 (LLQ) 都是這類功能的範例。Queuing Queuing

選擇條件

下表列出調節與管制的差別，協助您選擇適合的流量解決方案。

	流量調節	流量管制
主要行為	按照認可的速率緩衝過多的封包並排入佇列。	丟棄（或註釋）超過承諾速率的超額資料包。不會緩衝。*
權杖更新率	在每個Tc間隔週期性地補充令牌。在每個間隔開始時，整形器會將Bc令牌新增到已配置的桶限制。Tc受平台特定限制的約束。	令牌根據到達資料包之間的經過時間進行補充。監察器計算要與((t - t1)* policer_rate_bps)/ 8一起新增的令牌數，其中t - t1是自上一個資料包以來的時間。
權杖值	配置單位為每秒位數(bps)。	以位元組設定。
設定選項	MQC中的Shape命令用於實現基於類的整形。 用於實現FRTS的frame-relay traffic-shape命令。 Traffic-shape命令來實施GTS。	MQC 中的 Police 命令會實作類別型管制。 實現CAR的Rate-limit命令。
典型方向	出站	入站或出站，依賴於平台
峰值	可控制峰值，且至少可在八次時間間隔得到順暢的輸出率。它使用令牌桶計量並排隊多餘的資料包。排隊的資料包會隨著時間推移釋放，從而產生類似於漏桶的平滑效果。	允許突發在配置的突發限制內。它不會緩衝資料包來平滑傳輸速率。
優點	由於過多的封包可得到緩衝，因此不會捨棄過多的封包。（封包的緩衝範圍只達佇列的長度。如果過多流量維持在高速率，還是可能發生捨棄情況。） 由於會捨棄封包，通常可避免重複傳輸。	可透過封包的捨棄控制輸出率。由於 ，可避免延遲。queuing
缺點	由於 ，可能造成延遲，尤其佇列過長時。queuing	會捨棄過多封包（如有設定）、經過節流的 TCP 視窗大小，並使受影響的流量串流降低整體輸出率。過度激進的峰值規模可能造成大量封包捨棄並與整體輸出率節流，尤其是 TCP 式的流量。
選用的封包備註	否	是，它可以選擇性地傳輸、丟棄或標籤資料包，包括IP優先順序或DSCP操作，具體取決於配置的MQC管制器操作和平台支援。

權杖更新率

調節與管制的主要差異在於權杖重新補足的速率。調節與管制都使用權杖貯體隱喻法。權杖貯體本身沒有捨棄或優先權原則。

權杖貯體的功能運作時： 

• 權杖會以特定速率置入貯體。

• 每個權杖都會提供權限，讓來源將特定數量的位元傳送到網路中。

• 為了傳送封包，流量調整器必須有能力從貯體移除一組能夠等同於代表封包大小的權杖數量。

• 如果貯體中的權杖不足以傳送封包，則在選擇調節時，封包會等候貯體置入足夠的權杖；在選擇管制時，封包則會遭到捨棄或經過備註。

• 貯體本身的容量經過指定。如果貯體的容量已滿，新的權杖抵達時就會遭到捨棄，且無法傳送之後的封包。如此一來，任何時候只要來源傳送極大量的峰值進入網路，比例上就幾乎等同於貯體的大小了。權杖貯體可允許峰值，但會對它設限。

調節在增加權杖貯體的時間間隔使用的值是每秒位元數 (bps)。調節器會使用以下公式：

Tc = Bc/CIR (in seconds)

在此等式中：

• Bc：承諾突發量。在一個時間間隔內允許傳送的流量數量。

• CIR:承諾資訊速率。整形器或監察器執行的平均通訊速率。

• Tc：提交的時間間隔。整形器傳送承諾突發同時保持配置的CIR所用的時間間隔。

Tc 的範圍介於 10 ms 到 125 ms。在某些採用分散式流量調節(DTS)的舊式平台中，最低Tc為4毫秒。路由器會根據 CIR 和 Bc 值在內部計算該值。如果 Bc/CIR 小於 125 ms，它就會使用上述等式計算的 Tc。如果Bc/CIR大於或等於125毫秒，如果Cisco IOS確定流量可以在更小的間隔內更穩定，則會使用內部Tc值。使用 show traffic-shape 命令可判斷您的路由器使用內部 Tc 值，或在命令列設定的值。

顯示流量輸出

如果過量峰值 (Be) 的設定值不是 0，調節器就會讓權杖存放在貯體中，數量最多為 Bc + Be。權杖貯體可達到的最大值為 Bc + Be，而溢位的權杖則會遭捨棄。想讓貯體中的權杖大於 Bc，唯一的方法是在一或多次 Tc 期間內不要用盡全部 Bc。由於權杖貯體會在每次 Tc 重新補充 Bc 個權杖，您最多可以累積 Bc + Be 個未使用的權杖供稍後使用。

相反，基於類的策略和速率限制會根據到達資料包之間的經過時間來補充令牌。當資料包到達時，策略器計算自上一個資料包以來要新增的令牌數和已配置的策略器速率。具體而言，權杖的送達速率是以如下方法計算：

Tokens added = ((t - t1) * policer_rate_bps) / 8 bytes

換句話說，如果封包上一次是於 t1 送達，而目前的時間是 t，貯體就會根據權杖送達速率得出的位元組，以等值的 t-t1 來更新。 

以下範例使用 8000 bps 的 CIR（或管制器速率）和 1000 位元組的正常峰值：

Router(config)#policy-map police-setting 
Router(config-pmap)#class access-match 
Router(config-pmap-c)#police 8000 1000 conform-action transmit exceed-action drop 

權杖貯體一開始即充滿 1000 個位元組。如有 450 位元組的封包送達，由於權杖貯體有足夠位元組可用，所以此封包符合規範。封包會接受合規動作（傳輸），而權杖貯體會移除 450 個位元組（留下 550 個位元組）。 如果下個封包在 0.25 秒後送達，根據以下公式，權杖貯體會新增 250 個位元組：

(0.25 * 8000)/8

1. 儲存段開始已滿：

   • 正常突發= 1000位元組
   • 初始令牌= 1000位元組

2. 第一個封包到達：

   • 資料包大小= 450位元組
   • 資料包符合，因為儲存桶有足夠的令牌。
   • 監察器從容段中刪除了價值450位元組的標籤。

   計算：1000 - 450 =剩餘550位元組

3. 0.25秒後下一個資料包到達：

   • 管制器速率= 8000 bps
   • 在0.25秒內新增的令牌：

   (0.25 × 8000)/ 8 = 250位元組

4. 刷新後的儲存段：

   • 剩餘的現有令牌=550位元組
   • 新增的新令牌= 250位元組

   計算：550 + 250 = 800位元組

計算在令牌桶中保留800位元組(策略器桶中剩餘的令牌)。 如果下個封包為 900 個位元組，則封包過多，必須接受超出動作（捨棄）。於是權杖貯體不會接受任何位元組。

流量調節

Cisco IOS®支援以下流量整形方法：

• 通用流量調節

• 訊框中繼流量調節

• 類別型調節和分散式類別型調節

所有流量調節方法在實作上都類似，透過各自稍有不同的命令列介面 (CLI) 操作，並使用不同類型的佇列來維持與調節延遲的流量。思科建議您採用類別型調節和分散式調節，這些方法是以模組化 QoS CLI 來設定。

以下圖表說明 QoS 原則如何將流量分門別類，並將超出設定調節速率的封包排入佇列。

流量管制

Cisco IOS 支援以下流量管制方法：

• 認可存取速率 (CAR)

• 類別型管制

這兩個機制具有重要的功能差異，如如何配置基於類的策略中所述。思科建議您在 QoS 原則適用時採用類別型管制及模組化 QoS CLI 的其他功能。

使用 police 命令可指定對某類流量必須施加速率上限，如果超出上限，系統就必須立即採取行動。換句話說，使用 police 命令時，您不能選擇緩衝封包並於稍後再傳送，這種情況僅適用於 shape 命令。

此外，透過管制，權杖貯體會判斷封包是否超出或符合套用的速率。無論何種情況，管制都會實作可設定的動作，包括 IP 優先權或差異化服務代碼點 (DSCP)。

以下圖表說明流量管制在壅塞點的常見應用情況，這種情況通常會套用 QoS 功能。

頻寬控制上下限比較

shape和police命令將流量限製為已配置的最大速率。在MQC中，除非平台特定語法另有說明，否則shape average和police的配置速率以bps指定。重要的是，兩種機制在壅塞期間都不提供頻寬下限保證。使用 bandwidth 或 priority 命令才能提供這類保證。

階層化原則使用兩種服務原則，一種是對流量彙總套用 QoS 機制的上層原則，一種是對彙總的流向或子集套用 QoS 機制的下層原則。子介面和通道介面這類邏輯介面就需要採用階層化原則，在上層使用流量 功能，在下層執行佇列。limiting流量 功能會降低輸出率並（假設性地）建立壅塞，這種情況在對過量的封包進行 時即可見。limitingqueuing

以下組態並非最佳選擇，列於此處僅為呈現 police 和 shape 命令在將流量彙總（此例使用預設類別） 於速率上限時的差別。limiting在此組態中，police 命令會根據封包大小和相符與超出權杖貯體中剩餘的位元組數量來傳送下層類別的封包。（請參閱流量管制。） 由於管制功能會覆寫優先順序功能設定的保證，因此指定給 IP 語音 (VoIP) 和網際網路通訊協定 (IP) 類別的速率可能無法獲得保證。

不過，若使用 shape 命令，就會獲得階層化的佇列系統，使所有保證皆能實現。換句話說，如果提供的流量超出調節速率，VoIP 和 IP 類別可獲得保證速率，而任何捨棄都會在類別為預設的流量（在下層）產生。

注意：建議不要使用此配置，它顯示了限制流量聚合時police與shape命令之間的區別。

class-map match-all IP 
   match ip precedence 3 
class-map match-all VoIP 
   match ip precedence 5 
!  
policy-map child 
  class VoIP 
     priority 128 
   class IP 
     priority 1000 
! 
 policy-map parent 
   class class-default 
     police 3300000 103000 103000 conform-action transmit exceed-action drop 
     service-policy child

若要讓上述組態能夠合理運作，調節必須取代為管制。舉例來說：

policy-map parent
    class class-default
     shape average 3300000 103000 0
     service-policy child

使用show policy-map interface <interface>驗證配置的策略、類計數器、提供速率、丟棄計數器、整形速率、隊列深度和監察器符合/超出/違反計數器。

Router#show policy-map interface gigabitEthernet 0/0/2
 GigabitEthernet0/0/2 

 Service-policy output: parent 
    Class-map: class-default (match-any)  
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: any 
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 0/0
 shape (average) cir 3300000, bc 103000, be 0 target shape rate 3300000 
 Service-policy : child 
        queue stats for all priority classes:
          Queueing
          queue limit 512 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0

        Class-map: VoIP (match-all)  
          0 packets, 0 bytes
          5 minute offered rate 0000 bps, drop rate 0000 bps
          Match: ip precedence 5 
 Priority: 128 kbps, burst bytes 3200, b/w exceed drops: 0           

        Class-map: IP (match-all)  
          0 packets, 0 bytes
          5 minute offered rate 0000 bps, drop rate 0000 bps
          Match: ip precedence 3 
 Priority: 1000 kbps, burst bytes 25000, b/w exceed drops: 0           

        Class-map: class-default (match-any)  
          0 packets, 0 bytes
          5 minute offered rate 0000 bps, drop rate 0000 bps
          Match: any 
          
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0

附註：要瞭解有關父策略和子策略的更多資訊，請參閱QoS:優先順序類的子服務策略。

上面的示例是有意地處於次優狀態，僅用於說明分層QoS策略中的策略與整形之間的差異。在建議的QoS設計中，priority命令通常保留用於即時延遲敏感型流量（如語音）。要求最小頻寬保證的非即時類通常使用bandwfq命令。

此方法與LLQ和CBWFQ的Cisco QoS設計手冊相一致。LLQ為延遲敏感型流量提供嚴格的優先順序處理，而CBWFQ在擁塞期間為其他流量類別提供頻寬保證。因此，本示例中的IP類更好地用頻寬而不是優先順序來表示，除非該類承載的流量明確要求嚴格的優先順序處理。

policy-map child
 class VoIP
  priority 128
 class IP
  bandwidth 1000

相關資訊

• 服務品質 (QoS) 技術支援
• 技術支援與文件 - Cisco Systems

修訂記錄

修訂	發佈日期	意見
6.0	21-Jul-2026	重新認證。
4.0	07-Sep-2023	更新的品牌要求、SEO、語法和格式。
3.0	26-Sep-2022	重新認證
1.0	15-Feb-2002	初始版本