QoS 常見問題
目錄
簡介
本文件說明關於服務品質 (QoS) 最常見的問題 (FAQ)。
一般
問：什麼是服務品質(QoS)?
A. QoS指網路通過各種底層技術(包括幀中繼、非同步傳輸模式(ATM)、乙太網和802.1網路、SONET和IP路由網路)為所選網路流量提供更好服務的能力。
QoS是一組技術，允許應用請求和接收可預知的服務級別，具體體現在資料吞吐量（頻寬）、延遲變化（抖動）和延遲方面。特別是，QoS功能通過以下方法提供更好、更可預測的網路服務：
支援專用頻寬。
改善損失特性。
避免和管理網路擁塞。
調節網路流量。
設定整個網路的流量優先順序。
Internet工程任務組(IETF)定義了以下兩個QoS體系結構：
整合式服務(IntServ)
差異化服務(DiffServ)
IntServ使用資源保留協定(RSVP)明確發出訊號，表示在端到端路徑中通過網路沿裝置傳輸應用流量的QoS需求。如果路徑上的每個網路裝置都可以預留必要的頻寬，則發起應用即可開始傳輸。要求建議(RFC)2205定義RSVP，RFC 1633定義IntServ。
DiffServ專注於聚合和調配的QoS。DiffServ不向應用的QoS要求發訊號，而是使用IP報頭中的DiffServ代碼點(DSCP)來指示所需的QoS級別。Cisco IOS®軟體版本12.1(5)T在Cisco路由器上引入了DiffServ合規性。如需詳細資訊，請參閱以下檔案：
什麼是擁塞、延遲和抖動？
A.接口遇到流量超出其可處理能力時，就會發生擁塞。網路擁塞點是服務品質(QoS)機制的強大候選者。以下是典型擁塞點的示例：
網路擁塞會導致延遲。網路及其裝置會引入多種延遲，如瞭解資料包語音網路中的延遲中所述。延遲的變化稱為抖動，如瞭解資料包語音網路（Cisco IOS平台）中的抖動中所述。需要控制和最小化延遲和抖動，以支援即時和互動流量。
MQC是什麼？
A. MQC代表模組化服務品質(QoS)命令列介面(CLI)。它旨在通過定義通用的命令語法和由此產生的一組跨平台的QoS行為，簡化Cisco路由器和交換機上的QoS配置。此模型取代了以前為每個QoS功能和每個平台定義唯一語法的模型。
MQC包含以下三個步驟：
發出class-map命令定義流量類。
通過發出policy-map命令，將流量類與一項或多項服務品質功能相關聯，從而建立流量策略。
發出service-policy命令，將流量策略連線到介面、子介面或虛擬電路(VC)。
注意：您可以使用MQC語法實施DiffServ的流量調節功能，例如標籤和整形。
如需詳細資訊，請參閱模組化服務品質指令行介面。
問：僅在啟用了DCEF的VIP介面上支援service-policy表示什麼意思？
A.在Cisco 7500系列中的多功能介面處理器(VIP)上，自Cisco IOS 12.1(5)T、12.1(5)E和12.0(14)S起，僅支援分散式服務品質(QoS)功能。啟用分散式Cisco Express Forwarding(dCEF)將自動啟用分散式QoS。
非VIP介面(稱為傳統介面處理器(IP))支援路由交換處理器(RSP)上啟用的中央QoS功能。如需詳細資訊，請參閱以下檔案：
問：服務品質(QoS)策略支援多少類？
答：在Cisco IOS 12.2之前的版本中，您最多只能定義256個類，並且如果相同的類被重新用於不同的策略，則可以在每個策略中定義最多256個類。如果您有兩個策略，則兩個策略中的類總數不應超過256。如果策略包括基於類的加權公平隊列(CBWFQ)（意味著它包含任何類中的bandwidth [or priority]語句），則支援的類總數為64。
在Cisco IOS版本12.2(12)、12.2(12)T和12.2(12)S中，對256個全域性類對映的這一限制被更改，現在可以在同一策略對映內配置最多1024個全域性類對映並使用256個類對映。
問：應用服務策略時，如何處理路由更新和點對點協定(PPP)/高級資料鏈路控制(HDLC)保持連線？
A. Cisco IOS路由器使用以下兩種機制來確定控制資料包的優先順序：
IP優先順序
pak_priority
這兩種機制都旨在確保在出站介面擁塞時，路由器和排隊系統最後不會丟棄或丟棄關鍵控制資料包。有關詳細資訊，請參閱瞭解路由更新和控制資料包如何使用QoS服務策略在介面上排隊。
問：配置了整合路由和橋接(IRB)的介面是否支援服務品質(QoS)?
答：不。當介面配置為IRB時，您無法配置QoS功能。
分類和標籤
問：什麼是服務品質(QoS)預分類？
A. QoS預分類使您能夠匹配經歷隧道封裝和/或加密的資料包的原始IP報頭內容並對其分類。此功能不說明將Type of Service(ToS)位元組的原始值從原始封包標頭複製到通道標頭的過程。如需詳細資訊，請參閱以下檔案：
問：哪些資料包報頭欄位可以重新標籤？哪些值可用？
A.基於類的標籤功能允許您設定或標籤資料包的第2層、第3層或多協定標籤交換(MPLS)報頭。如需詳細資訊，請參閱以下檔案：
問：我是否可以根據URL確定流量的優先順序？
A.是。網路型應用程式辨識(NBAR)允許您根據應用層上的欄位比對封包進行分類。在引入NBAR之前，最精細的分類是第4層傳輸控制協定(TCP)和使用者資料包協定(UDP)埠號。如需詳細資訊，請參閱以下檔案：
問：哪些平台和Cisco IOS軟體版本支援基於網路的應用識別(NBAR)?
A.以下版本的Cisco IOS軟體引入了對NBAR的支援：
平台 最低Cisco IOS軟體版本 7200 12.1(5)公噸 7100 12.1(5)公噸 3660 12.1(5)公噸 3640 12.1(5)公噸 3620 12.1(5)公噸 2600 12.1(5)公噸 1700 12.2(2)公噸 注意：您需要啟用Cisco Express Forwarding(CEF)才能使用NBAR。
以下平台提供分散式NBAR(DNBAR):
平台 最低Cisco IOS軟體版本 7500 12.2(4)T、12.1(6)E FlexWAN 12.1(6)E 註：Catalyst 6000多層次交換功能卡(MSFC)VLAN介面、Cisco 12000系列或Catalyst 5000系列的路由交換器模組(RSM)不支援NBAR。如果您沒有看到上面列出的特定平台，請聯絡您的思科技術代表。
佇列和擁塞管理
排隊的作用是什麼？
A.佇列設計為將多餘的封包儲存在緩衝區中，直到頻寬可用為止，藉此適應網路裝置介面上的暫時擁塞。Cisco IOS路由器支援多種排隊方法，以滿足不同應用的各種頻寬、抖動和延遲要求。
大多數介面上的預設機制是先進先出(FIFO)。某些流量型別對延遲/抖動的要求更為苛刻。因此，預設情況下應配置或啟用以下備用隊列機制之一：
加權公平佇列(WFQ)
類別式加權公平佇列(CBWFQ)
低延遲佇列(LLQ)(實際上是具有優先順序佇列(PQ)的CBWFQ)（稱為PQCBWFQ）
優先順序佇列(PQ)
自訂佇列(CQ)
排隊通常僅在出站介面上發生。路由器對從介面傳出的資料包進行排隊。您可以管制傳入流量，但通常不能排入隊列(例外情況是使用分散式Cisco Express Forwarding(dCEF)在Cisco 7500系列路由器上使用接收端緩衝將封包從輸入轉送到輸出介面；如需詳細資訊，請參閱瞭解99%運行的VIP CPU和Rx-Side Buffering。在Cisco 7500和12000 Series等高端分散式平台上，入站介面可以使用自己的資料包緩衝區來儲存根據入站介面的交換決策交換到擁塞出站介面的過多流量。在極少數情況下，通常當入站介面向較慢的出站介面提供資料時，入站介面在資料包記憶體用盡時可能會遇到越來越多的被忽略錯誤。過度擁塞會導致輸出隊列丟棄。在大多數情況下，輸入隊列丟棄具有不同的根本原因。有關疑難排解捨棄的詳細資訊，請參閱以下檔案：
如需詳細資訊，請參閱以下檔案：
問：加權公平佇列(WFQ)和類別型加權公平佇列(CBWFQ)是怎樣運作的？
A.公平排隊試圖在活動會話或IP流之間分配介面頻寬的公平份額。它使用基於IP報頭的多個欄位和資料包長度的雜湊演算法將資料包分類到子隊列中，子隊列由會話標識號標識。以下是計算重量的方式：
W=K/（優先順序+1）
K= 4096與Cisco IOS 12.0(4)T及更低版本相容，32384與12.0(5)T及更高版本相容。
權重越低，優先順序和頻寬份額越高。除了權重，資料包的長度也被考慮在內。
CBWFQ允許您定義流量類別並為其分配最小頻寬保證。此機制背後的演算法是WFQ，它解釋了名稱。要配置CBWFQ，可在map-class語句中定義特定類。然後，將策略分配給策略對映中的每個類。然後，此策略對映將被附加到介面的出站位置。如需詳細資訊，請參閱以下檔案：
問：如果基於類的加權公平隊列(CBWFQ)中的某個類未使用其頻寬，其他類是否可以使用頻寬？
A.是。雖然發出bandwidth和priority命令提供的頻寬保證已用「保留」和「要保留的頻寬」等詞來描述，但這兩個命令都沒有實現真正的保留。這意味著，如果流量類未使用其配置的頻寬，則任何未使用的頻寬都會在其他類之間共用。
排隊系統對具有優先順序類的此規則實施一個重要的例外。如上所述，優先順序類的已提供負載由流量管制器計量。在擁塞情況中，優先順序類不能使用任何多餘的頻寬。有關詳細資訊，請參閱比較QoS服務策略的頻寬和優先順序命令。
問：子介面是否支援類別型加權公平佇列(CBWFQ)?
答：Cisco IOS邏輯介面本身不支援擁塞狀態，也不支援直接應用應用排隊方法的服務策略。相反，您首先需要使用通用流量調節(GTS)或類別行調節，將調節應用到子介面。有關詳細資訊，請參閱將QoS功能應用於乙太網子介面。
問：策略對映中priority和bandwidth語句有何區別？
A.priority和bandwidth命令在功能上以及它們通常支援的應用程式上有所不同。下表彙總了這些差異：
功能 bandwidth命令 priority命令 最小頻寬保證 是 是 最大頻寬保證 否 是 內建監察器 否 是 提供低延遲 否 是 如需詳細資訊，請參閱比較QoS服務原則的bandwidth和priority命令。
問：如何在FlexWAN和通用介面處理器(VIP)上計算隊列限制？
A.假設VIP或FlexWAN上有足夠的SRAM，則隊列限制會根據最大延遲500ms（平均資料包大小為250位元組）來計算。以下是具有1 Mbps頻寬的類的示例：
隊列限制= 1000000 /(250 x 8 x 2)= 250
隨著可用資料包記憶體量的減少以及虛擬電路(VCS)數量的增加，分配更小的隊列限制。
在以下示例中，PA-A3安裝在Cisco 7600系列的FlexWAN卡中，並且支援具有2 MB永久虛擬電路(PVC)的多個子介面。服務策略應用於每條VC。
class-map match-any XETRA-CLASS match access-group 104 class-map match-any SNA-CLASS match access-group 101 match access-group 102 match access-group 103 policy-map POLICY-2048Kbps class XETRA-CLASS bandwidth 320 class SNA-CLASS bandwidth 512 interface ATM6/0/0 no ip address no atm sonet ilmi-keepalive no ATM ilmi-keepalive ! interface ATM6/0/0.11 point-to-point mtu 1578 bandwidth 2048 ip address 22.161.104.101 255.255.255.252 pvc ABCD class-vc 2048Kbps-PVC service-policy out POLICY-2048Kbps非同步傳輸模式(ATM)介面會取得整個介面的佇列限制。此限制是可用緩衝區總數、FlexWAN上的物理介面數以及介面上允許的最大排隊延遲的函式。每個PVC根據PVC的持續信元速率(SCR)或最小信元速率(MCR)獲得一部分介面限制，而每個類根據它們的頻寬分配獲得PVC限制的一部分。
show policy-map interface命令的以下輸出示例來自具有3687全域性緩衝區的FlexWAN。發出show buffer命令來檢視此值。每個2 Mbps PVC分配了50個資料包，基於兩個Mbps的PVC頻寬(2047/149760 x 3687 = 50)。然後每個類被分配到50的一部分，如以下輸出所示：
service-policy output: POLICY-2048Kbps class-map: XETRA-CLASS (match-any) 687569 packets, 835743045 bytes 5 minute offered rate 48000 bps, drop rate 6000 BPS match: access-group 104 687569 packets, 835743045 bytes 5 minute rate 48000 BPS queue size 0, queue limit 7 packets output 687668, packet drops 22 tail/random drops 22, no buffer drops 0, other drops 0 bandwidth: kbps 320, weight 15 class-map: SNA-CLASS (match-any) 2719163 packets, 469699994 bytes 5 minute offered rate 14000 BPS, drop rate 0 BPS match: access-group 101 1572388 packets, 229528571 bytes 5 minute rate 14000 BPS match: access-group 102 1146056 packets, 239926212 bytes 5 minute rate 0 BPS match: access-group 103 718 packets, 245211 bytes 5 minute rate 0 BPS queue size 0, queue limit 12 packets output 2719227, packet drops 0 tail/random drops 0, no buffer drops 0, other drops 0 bandwidth: kbps 512, weight 25 queue-limit 100 class-map: class-default (match-any) 6526152 packets, 1302263701 bytes 5 minute offered rate 44000 BPS, drop rate 0 BPS match: any 6526152 packets, 1302263701 bytes 5 minute rate 44000 BPS queue size 0, queue limit 29 packets output 6526840, packet drops 259 tail/random drops 259, no buffer drops 0, other drops 0如果您的流量流使用較大的資料包大小，show policy-map interface命令輸出可能會報告no buffer drops欄位的遞增值，因為在達到隊列限制之前您可能已用盡緩衝區。在這種情況下，請嘗試手動最佳化非優先順序類中的隊列限制。如需詳細資訊，請參閱瞭解IP到ATM CoS的傳輸佇列限制。
問：如何驗證隊列限制值？
A.在非分散式平台上，預設情況下隊列限製為64個資料包。在Cisco 3600系列路由器上捕獲了以下示例輸出：
november# show policy-map interface s0 Serial0 Service-policy output: policy1 Class-map: class1 (match-all) 0 packets, 0 bytes 5 minute offered rate 0 BPS, drop rate 0 BPS Match: ip precedence 5 Weighted Fair Queueing Output Queue: Conversation 265 Bandwidth 30 (kbps) Max Threshold 64 (packets) !--- Max Threshold is the queue-limit. (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0 Class-map: class2 (match-all) 0 packets, 0 bytes 5 minute offered rate 0 BPS, drop rate 0 BPS Match: ip precedence 2 Match: ip precedence 3 Weighted Fair Queueing Output Queue: Conversation 266 Bandwidth 24 (kbps) Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0 Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0 BPS, drop rate 0 BPS Match: any
我能在類內啟用公平排隊嗎？
A.具有分散式服務品質(QoS)的Cisco 7500系列支援每個類別的公平佇列。其他平台（包括Cisco 7200系列和Cisco 2600/3600系列）支援類別預設類別中的加權公平佇列(WFQ)；所有頻寬類別都使用先進先出(FIFO)。
問：可以使用哪些命令來監控佇列？
A.使用以下命令監控佇列：
show queue {interface}{interface number} — 在Cisco 7500系列以外的Cisco IOS平台上，此命令顯示活動隊列或會話。如果介面或虛擬電路(VC)未擁塞，則不會列出任何隊列。在Cisco 7500系列上，不支援show queue命令。
show queueing interface interface-number [vc [[vpi/] vci] — 顯示介面或VC的隊列統計資訊。即使沒有擁塞，您仍然可以看到一些點選內容。這是因為無論是否存在擁塞，都會對進程交換資料包進行計數。除非出現擁塞，否則不會對Cisco快速轉送(CEF)和快速交換封包進行計數。優先順序佇列(PQ)、自訂佇列(CQ)和加權公平佇列(WFQ)等舊版佇列機制不會提供分類統計資料。在12.0(5)T之前的映像中，只有基於模組化服務品質命令列介面(MQC)的功能可提供這些統計資訊。
show policy interface {interface}{interface number} - packets計數器計算與類的條件相匹配的資料包數。無論介面是否擁塞，此計數器都會遞增。packets matched計數器表示介面擁塞時與類標準匹配的資料包數。有關資料包計數器的詳細資訊，請參閱以下文檔：
Cisco Class-Based QoS Configuration and Statistics MIB — 提供簡單網路管理協定(SNMP)監控功能。
Q. RSVP可以和基於類的加權公平佇列(CBWFQ)結合使用。當為介面配置資源預留協定(RSVP)和CBWFQ時，RSVP和CBWFQ是否獨立運行，表現出與各自單獨運行時相同的行為？RSVP的行為似乎與未配置頻寬可用性、評估和分配的CBWFQ類似。
A.在Cisco IOS軟體版本12.1(5)T和更新版本中使用RSVP和CB-WFQ時，路由器可以正常運作，使RSVP流和CBWFQ類共用介面或PVC上的可用頻寬，且沒有過度訂閱。
IOS軟體版本12.2(1)T和更新版本允許RSVP使用其自己的「ip rsvp bandwidth」池進行許可控制，而CBWFQ則對RSVP封包進行分類、原則制訂和排程。這假設傳送者已預先標籤封包，且非RSVP封包的標籤不同。
擁塞迴避加權隨機早期偵測(WRED)
問：我是否可同時啟用加權隨機早期偵測(WRED)和低延遲佇列(LLQ)或類別型加權公平佇列(CBWFQ)?
A.是。隊列定義資料包離開隊列的順序。這表示它定義了一個封包排程機制。它還可以用於提供公平的頻寬分配和最小頻寬保證。相反，要求建議(RFC)2475將丟棄定義為「根據指定規則丟棄資料包的過程」。 預設丟棄機制是尾部丟棄，即當隊列已滿時，介面丟棄資料包。另一種丟棄機制是隨機早期檢測(RED)和思科的WRED，它會在隊列已滿之前隨機丟棄資料包，並尋求保持一致的平均隊列深度。WRED使用封包的IP優先順序值做出區分捨棄決定。如需詳細資訊，請參閱加權隨機早期偵測(WRED)。
問：如何監控加權隨機早期檢測(WRED)並確保其生效？
A. WRED監控平均隊列深度，並在計算值超過最小閾值時開始丟棄資料包。發出show policy-map interface命令並監控平均隊列深度值，如下例所示：
Router# show policy interface s2/1 Serial2/1 output : p1 Class c1 Weighted Fair Queueing Output Queue: Conversation 265 Bandwidth 20 (%) (pkts matched/bytes matched) 168174/41370804 (pkts discards/bytes discards/tail drops) 20438/5027748/0 mean queue depth: 39 Dscp Random drop Tail drop Minimum Maximum Mark (Prec) pkts/bytes pkts/bytes threshold threshold probability 0(0) 2362/581052 1996/491016 20 40 1/10 1 0/0 0/0 22 40 1/10 2 0/0 0/0 24 40 1/10 [output omitted]
管制和調節
維持治安和塑造治安有什麼不同？
A.以下圖說明了主要區別。流量整形在隊列中保留多餘的資料包，然後排程多餘的資料包以便以後在時間增量內傳輸。流量整形的結果是平滑的資料包輸出速率。相反，流量策略會傳播突發流量。當流量速率達到設定的最大速率時，會捨棄或重標多餘流量。結果輸出速率顯示為具有頂部和槽的鋸齒形。
有關詳細資訊，請參閱策略和整形概述。
什麼是令牌桶，演算法如何工作？
A.令牌儲存桶本身沒有丟棄策略或優先順序策略。以下是令牌桶隱喻的運作示例：
令牌以一定的速率放入桶中。
每個令牌都允許源傳送一定數量的位元。
要傳送資料包，流量調節器必須能夠從儲存桶中移除表示資料包大小的數個令牌。
如果儲存桶中沒有足夠的令牌來傳送資料包，資料包將一直等待，直到儲存桶中有足夠的令牌（對於整形器）或者資料包被丟棄或被降級（對於整形器）。
桶本身具有指定的容量。如果儲存桶已滿容量，新到達的令牌將被丟棄，並且不能用於未來的資料包。因此，在任何時間，源可以傳送到網路的最大突發量與儲存桶的大小大致成正比。令牌桶允許突發情況，但會限制突發情況。
問：使用基於類的策略等流量策略時，承諾突發量(BC)和超額突發量(Be)意味著什麼？我應如何選擇這些值？
A.流量管制器不會緩衝過多的封包並在稍後傳輸，整形器的情況就是這樣。相反，監察器會執行簡單的傳送，或者不傳送沒有緩衝的策略。在擁塞期間，由於您無法進行緩衝，因此您的最佳做法是通過正確配置擴展突發來降低丟棄資料包的攻擊性。因此，瞭解管制器使用正常突發和擴展突發值來確保達到配置的承諾資訊速率(CIR)是非常重要的。
突發引數以路由器的通用緩衝規則鬆散地建模。規則建議配置與往返時間位元率相等的緩衝，以便在擁塞時容納所有連線的未決傳輸控制協定(TCP)視窗。
下表說明了正常和擴展突發值的用途和推薦公式：
突發引數 目的 推薦的公式 正常突發
實現標準令牌桶。
設定令牌桶的最大大小（雖然如果Be大於BC則可以借用令牌）。
確定令牌桶的大小，因為新到達的令牌被丟棄，並且如果令牌桶已滿容量，則無法用於未來的資料包。
註：1.5秒是典型的往返時間。
擴展突發量
實施具有擴展突發功能的令牌桶。
通過設定BC = Be禁用。
當BC等於Be時，流量調節器無法借用令牌，當可用令牌不足時只會丟棄資料包。
對於監察器，並非所有平台都使用或支援相同的值範圍。請參閱以下文檔，瞭解您的特定平台支援的值：
問：承諾訪問速率(CAR)或基於類的策略如何決定資料包是否符合或超過承諾資訊速率(CIR)?即使確認速率小於配置的CIR，路由器也會丟棄資料包並報告超出速率。
A.流量管制器使用正常突發和擴展突發值來確保達到配置的CIR。設定足夠高的突發值對於確保良好的吞吐量非常重要。如果突發值配置得太低，則達到的速率可能遠遠低於配置的速率。懲罰臨時突發可能會對傳輸控制協定(TCP)流量的吞吐量產生嚴重的不利影響。使用CAR時，發出show interface rate-limit命令以監控當前突發，並確定顯示的值是否始終接近於限制(BC)和擴展限制(Be)值。
rate-limit 256000 7500 7500 conform-action continue exceed-action drop rate-limit 512000 7500 7500 conform-action continue exceed-action drop router# show interfaces virtual-access 26 rate-limit Virtual-Access26 Cable Customers Input matches: all traffic params: 256000 BPS, 7500 limit, 7500 extended limit conformed 2248 packets, 257557 bytes; action: continue exceeded 35 packets, 22392 bytes; action: drop last packet: 156ms ago, current burst: 0 bytes last cleared 00:02:49 ago, conformed 12000 BPS, exceeded 1000 BPS Output matches: all traffic params: 512000 BPS, 7500 limit, 7500 extended limit conformed 3338 packets, 4115194 bytes; action: continue exceeded 565 packets, 797648 bytes; action: drop last packet: 188ms ago, current burst: 7392 bytes last cleared 00:02:49 ago, conformed 194000 BPS, exceeded 37000 BPS如需詳細資訊，請參閱以下檔案：
突發和隊列限制是否相互獨立？
A.是，策略器突發和隊列限制是相互獨立且獨立的。可以將監察器視為允許一定數量的資料包（或位元組）的門，將隊列視為大小為隊列限制的桶，用於在網路上傳輸之前保留已允許的資料包。理想情況下，您希望儲存桶足夠大，以容納入口（管制器）允許的位元組/資料包的突發。
服務品質(QoS)訊框中繼
問：應為承諾資訊速率(CIR)、承諾突發量(BC)、超額突發量(Be)和最小突發量(MinCIR)選擇哪些值？
A.您通過發出frame-relay traffic-shaping命令啟用的幀中繼流量整形支援多個可配置的引數。這些引數包括frame-relay cir、frame-relay mincir和frame-relay BC。有關選擇這些值和瞭解相關show命令的詳細資訊，請參閱以下文檔：
問：在Cisco IOS 12.1中，幀中繼主介面上的優先順序隊列是否有效？
A.幀中繼介面同時支援介面排隊機制和每虛電路(VC)排隊機制。自Cisco IOS 12.0(4)T起，只有在設定訊框中繼流量調節(FRTS)時，介面佇列才支援先進先出(FIFO)或每個介面優先順序佇列(PIPQ)。因此，如果升級到Cisco IOS 12.1，以下配置將不再有效。
interface Serial0/0 frame-relay traffic-shaping bandwidth 256 no ip address encapsulation frame-relay IETF priority-group 1 ! interface Serial0/0.1 point-to-point bandwidth 128 ip address 136.238.91.214 255.255.255.252 no ip mroute-cache traffic-shape rate 128000 7936 7936 1000 traffic-shape adaptive 32000 frame-relay interface-dlci 200 IETF如果未啟用FRTS，則可以將替代排隊方法(如基於類的加權公平佇列(CBWFQ))應用到主介面，它就像一個單一頻寬管道。此外，從Cisco IOS 12.1.1(T)開始，您還可以在幀中繼主介面上啟用幀中繼永久虛擬電路(PVC)優先順序介面隊列(PIPQ)。您可以定義高優先順序、中優先順序、普通優先順序或低優先順序PVC，並在主介面上發出frame-relay interface-queue priority命令，如以下示例所示：
interface Serial3/0 description framerelay main interface no ip address encapsulation frame-relay no ip mroute-cache frame-relay traffic-shaping frame-relay interface-queue priority interface Serial3/0.103 point-to-point description frame-relay subinterface ip address 1.1.1.1 255.255.255.252 frame-relay interface-dlci 103 class frameclass map-class frame-relay frameclass frame-relay adaptive-shaping becn frame-relay cir 60800 frame-relay BC 7600 frame-relay be 22800 frame-relay mincir 8000 service-policy output queueingpolicy frame-relay interface-queue priority low
問：訊框中繼流量調節(FRTS)是否與分散式思科快速轉送(dCEF)和分散式類別型加權公平佇列(dCBWFQ)搭配使用？
答：自Cisco IOS 12.1(5)T起，Cisco 7500系列中的VIP僅支援分散式版本的QoS功能。要在幀中繼介面上啟用流量調節，請使用分散式流量調節(DTS)。如需詳細資訊，請參閱以下檔案：
使用非同步傳輸模式(ATM)的服務品質(QoS)
問：在非同步傳輸模式(ATM)介面上，在哪裡應用具有基於類的加權公平隊列(CBWFQ)和低延遲隊列(LLQ)的服務策略？
A.從Cisco IOS 12.2開始，ATM介面支援三個級別或邏輯介面的服務策略：主介面、子介面和永久虛擬電路(PVC)。應用策略的位置取決於您正在啟用的服務品質(QoS)功能。因為ATM介面會監控每個VC的擁塞層級，且會維護每個VC多餘封包的佇列，所以應該對每個VC套用佇列原則。如需詳細資訊，請參閱以下檔案：
問：IP到非同步傳輸模式(ATM)服務類別(CO)隊列統計哪些位元組？
A.在服務策略中配置的頻寬和優先順序命令分別啟用基於類的加權公平隊列(CBWFQ)和低延遲隊列(LLQ)，這些命令使用一個Kbps值，該值計數與show interface命令輸出所計數的開銷位元組相同。具體來說，第3層排隊系統計算邏輯鏈路控制/子網訪問協定(LLC/SNAP)的數量。它不計算以下內容：
ATM調適第5層(AAL5)報尾
填充以使最後一個單元格成為48位元組的偶數倍數
五位元組信元信頭
問：有多少虛擬電路(VCS)可以同時支援服務策略？
A.以下檔案提供了可支援的非同步傳輸模式(ATM)VCS數量的有用准則。已安全部署約200到300個VBR-nrt永久虛擬電路(PVC):
還要考慮以下因素：
使用功能強大的處理器。例如，VIP4-80的效能明顯高於VIP2-50。
可用資料包記憶體量。在NPE-400上，為資料包緩衝區預留了高達32 MB（在具有256 MB的系統中）。對於NPE-200，為128 MB的系統上的資料包緩衝區預留了高達16 MB的空間。
在多達200個ATM PVC上同時運行的每個VC加權隨機早期檢測(WRED)的配置已經過廣泛測試。VIP2-50上可用於每個VC隊列的資料包記憶體量是有限的。例如，具有8-MB SRAM的VIP2-50提供1085個資料包緩衝區，可用於WRED在其上運行的IP到ATM CO的每條VC隊列。如果設定了100個ATM PVC，且所有VCS同時遇到過度擁塞（如在將使用非TCP流量控制來源的測試環境中模擬），則每個PVC平均將具有約10個封包值的緩衝，這可能太短，致使WRED無法成功運作。因此，對於具有運行每個VC WRED且可以同時遇到擁塞的大量ATM PVC的設計，強烈建議使用具有大SRAM的VIP2-50裝置。
已配置的活動PVC數量越多，所需的持續信元速率(SCR)就越低，因此WRED在PVC上操作所需的隊列就越短。因此，如同使用IP到ATM服務類別(COs)第1階段功能的預設WRED設定檔一樣，當在大量低速擁塞ATM PVC上啟用每VC WRED時，設定較低的WRED捨棄臨界值會將VIP上緩衝區短缺的風險降至最低。VIP上的緩衝區不足不會導致任何故障。在VIP上的緩衝區不足的情況下，IP到ATM CO第1階段功能在緩衝區不足期間會簡化為先進先出(FIFO)尾部丟棄（也就是說，與此PVC上未啟用IP到ATM CO功能時發生的丟棄策略相同）。
可合理支援的同步VCS的最大數量。
問：哪種非同步傳輸模式(ATM)硬體支援IP到ATM服務類別(CO)功能，包括基於類別的加權公平佇列(CBWFQ)和低延遲佇列(LLQ)?
A. IP到ATM CO是指基於每個虛擬電路(VC)啟用的一組功能。根據此定義，ATM介面處理器(AIP)、PA-A1或4500 ATM網路處理器不支援IP到ATM CO。此ATM硬體不支援依照VC進行佇列，因為PA-A3和大多數網路模組（ATM-25除外）會定義它。如需詳細資訊，請參閱以下檔案：
語音和服務品質(QoS)
問：鏈路分段和交錯(LFI)如何工作？
A.當網路處理大型封包(例如透過廣域網進行檔案傳輸通訊協定(FTP)傳輸)時，例如Telnet和IP語音的互動流量容易增加延遲。當FTP資料包在較慢的WAN鏈路上排隊時，互動式流量的資料包延遲會非常嚴重。設計一種方法，用於對較大封包進行分段，並在較大封包(FTP)的片段之間對較小（語音）封包進行佇列。Cisco IOS路由器支援多個第2層分段機制。如需詳細資訊，請參閱以下檔案：
問：可以使用哪些工具來監控IP語音的效能？
答：思科目前提供多個選項，用於使用思科的IP語音解決方案監控網路中的服務品質(QoS)。這些解決方案不使用感知語音品質測量(PSQM)或某些新的語音品質測量演算法來測量語音品質。Agilent(HP)和NetIQ提供的工具可用於此目的。但是，思科提供的工具可以通過測量延遲、抖動和丟包來瞭解您所體驗的語音品質。如需詳細資訊，請參閱使用Cisco服務保證代理和Internetwork Performance Monitor管理IP語音網路的服務品質。
問題： %SW_MGR-3-CM_ERROR_FEATURE_CLASS：連線管理器功能錯誤：類SSS:(QoS) — 安裝錯誤，忽略。
A.將無效配置應用於模板時，觀察到的功能安裝錯誤是預期行為。它表示由於衝突而未應用服務策略。一般情況下，不應在分層策略對映中的子策略的類預設配置整形，而應在介面的父策略上配置它。因此，會將此消息與回溯一起列印出來。
對於基於會話的策略，類預設整形只能在子介面或PVC級別完成。不支援在物理介面進行整形。如果在物理介面上完成配置，則出現此錯誤消息是預期行為。
在LNS的情況下，另一個原因可能是，啟動會話時可以通過radius伺服器設定服務策略。發出show tech命令以檢視radius伺服器組態，並在作業階段啟動或翻動時，檢視透過radius伺服器安裝的任何非法服務原則。
意見