本節書摘來自異步社群《端到端qos網絡設計（第2版）》一書中的第2章，第2.3節，作者【美】tim szigeti , 【加】robert barton , 【美】christina hattingh , 【美】kenneth briley，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視
端到端qos網絡設計（第2版）
mqc這種結構化的指令行旨在為操作人員提供一種統一的、獨立于裝置平台的、靈活的配置方式，以簡化在cisco ios平台上配置qos特性的工作。為此，mqc對qos行為的模式進行了簡化和概括，讓管理者無需了解裝置平台的具體資訊，就可以操作裝置來完成qos的配置工作。
mqc為實施下一列每一步qos的配置定義了一個文法架構。
1．定義流量類型，并定義不同流量分别屬于什麼類型。
2．定義各個流量應該應用的動作或政策（例如，應用标記，或者為流量配置設定帶寬）。
3．将政策關聯到某個特定的邏輯或實體接口。
上述三個配置步驟可以通過三個基本的指令集來實作，它們是class map、policy map和service policy。
class map：這個指令集的作用是指定各類資料包的比對标準。
policy map：這個指令集的作用是為各個流量類型定義動作。其中每種類型的流量都可以指定一條或多條政策。政策的内容包括為流量限制一個最大的帶寬，或者為隊列中的某一類流量指定一個更高的優先級别等。
service policy：這條指令的作用是将policy map（以及相應的政策和管理者定義的流量類型）綁定到一個邏輯或實體接口，并指定在哪個方向（入站還是出站）上應用這條政策。
例2-1所示為mqc文法的通用結構。
例2-1 通用的mqc文法結構
例2-2為使用mqc結構配置qos的一個案例。在這個案例中，管理者定義了4種類型的流量，并對其中的三種進行了命名（realtime、control、critical-data），還有一種“預設”的理性。在這個案例中，裝置會根據此前在資料包上應用的标記對其進行分類（match語句）。而在此前的圖2-2中，qos特性先對資料包進行了分類（方塊8），然後才根據分類結果對其進行了标記（方塊9）。在實際應用中，這兩種順序都很常見；邊緣節點往往會根據對流量所進行的分析來分類流量，然後再對資料包進行打标（如圖2-2所示），而其後的節點則會使用資料包上現有的标記對資料包進行分類，然後再對其應用政策（如例2-2所示）。
要注意，class map和policy map的名稱都是區分大小寫的。是以，class map type1、class-map type1和class-map type1定義的是三個不同的class map。在policy map中調用class map時，名稱和大小寫一定要和相應的class map完全一緻。
例2-2 mqc文法結構示例
注釋：
本書中對class map、policy map和通路清單采用全大寫的命名方式，以便于将mqc指令與傳統的ios指令集區分開。
未分類流量會被歸入隐式預設類别中，根據相應的方式進行處理。預設類會自動成為mqc配置中的一部分。
如例2-2所示，預設類不能在class map那一部分中進行配置。因為根據定義，預設類包含所有在class map的配置中無法歸類的流量。但管理者可以通過例2-2所示的cli指令，為class-default指定policy map，以此來為預設類型的流量指定qos特性（列隊、整形、配置設定帶寬等）。這是可選的，如果沒有為預設類配置設定policy map，那麼也就相當于管理者沒有為預設類型的流量配置設定qos特性，是以裝置會對這類流量提供盡力而為的傳輸，也就是使用所有沒有通過配置明确指定給任何類别的帶寬。
在沒有為未分類流量配置qos特性時，處理這類流量的預設做法是先進先出（fifo）尾部丢棄的政策，這種政策會按照平等的方式處理所有流量，在輸出隊列滿載時，裝置就會開始丢棄資料包。
下面是三種最為常見的流量分類方式。
标記：檢查第2層（服務類型[cos]）或第3層（ip優先級[ipp]或差分服務代碼點[dscp]）的設定。
位址：檢查接口的源/目的，或第2層目的位址，或者第3層源/目的位址，或者第4層源/目的端口。使用ip位址可以分類由不同裝置發送過來的流量，而使用端口号的方式則往往适用于将流量按照類型進行分類的場合。
應用簽名：檢查資料包負載中的應用内容，也稱為深度資料資料包監控。
使用标記和位址進行分類的方法，會使用到資料標頭部/資料幀頭部/标記頭部的資訊，而使用應用進行分類的方法，則需要檢查資料包應用層（l7）的負載。
class map是一種cli架構，它适用于全部上述三種機制（基于标記/位址/應用的分類）。在一個class map中，可以包含一條或多條match語句，以定義屬于某一種分類的流量；一個class map可以采用上述三種機制之一（或者将這三種機制結合起來）來分類流量，而match語句後面的關鍵字決定了這個class map使用的是哪（幾）種機制。可以比對的内容包括cos或dscp标記、源或目的位址、協定或應用協定等，如例2-3所示。
例2-3 class map示例
管理者可以通過class map這條cli指令指定如何組合各個比對标準，來定義一個流量。有三種方式可以定義一種流量分類。
比對所有的标準（match-all）。
不比對任何一種标準（match not）。
至少比對其中的某一項标準（match-any）。
（在沒有指定的情況下）預設的邏輯操作方式為match-all。
管理者可以在policy map中為通過class map指定的各個流量類型，定義一個或多個動作（或qos處理方式）。在例2-2中，包含了一個名為wan-edge-4-class的policy map，它為4種類型的流量指定了相關的qos政策。在該示例中顯示的處理方式包含了配置設定帶寬（關鍵字為priority和bandwidth）、隊列算法（關鍵字為priority和fair-queue）、棄門限值（關鍵字為random-detect）。
在定義政策時可以包含以下幾種類型的處理方式：
配置設定帶寬；
隊列檢測（優先級隊列、公平隊列、隊列長度限制）；
流量整形（通過隊列的方式限速或延遲發送資料包）；
資料包丢棄（通過丢棄資料包進行限速，如随機丢棄、尾部丢棄或無條件丢棄）；
标記資料包（将頭部字段設定為某個數值）；
對資料包計數；
壓縮資料標頭部；
準入控制。
盡管在配置中定義class map的順序并不重要，但在policy map中類的次序卻很關鍵。與acl（通路控制清單）的處理方式相同，policy map也會采用“優先比對”的規則，也就是說，資料包會按照policy map中各個類的順序進行校驗，直到找到比對條目為止。一旦找到比對條目，檢查的過程就會中止，裝置不會再嘗試比對後面的類。如果沒有找到比對條目，資料包就會被歸入預設的類别。
為了說清楚policy map中各個類别排序的重要性，不妨參考例2-4。在這個示例中，包含了兩個流量類，其中voice歸類語音流量，而fax-relay歸類傳真流量。這兩個類在全局配置中的順序無關緊要。但我們的目的是按照不同的方式處理語音流量和傳真流量（為了嚴格控制各類流量可以使用的最大帶寬），雖然這兩類流量是以同樣的方式進行标記的——所有資料包都在各自的源标記了dscp ef。
例2-4 policy map排序示例
在例2-4中，管理者對于policy map voice-and-fax中各個類别的順序進行了精心的規劃。其中類voice的次序在前，執行nbar（基于網絡的應用識别）分類來區分某種流量是否為實時傳輸協定（rtp）的音頻流量（也就是語音流量）。隻有不符合這一類别的流量才會由policy map中第2個類别（fax-relay）進行校驗。
類fax-relay會檢驗資料包的dscp值是否為ef。因為隻有兩類流量的dscp值為ef（語音流量和傳真中繼流量），而語音已經被過濾掉了，是以其他滿足這一标準的流量隻能是傳真中繼流量。接下來，管理者為傳真中繼流量配置設定了相同的隊列政策，但為它們配置設定了不同的帶寬。如果policy map中的兩條class語句調換順序，這個政策的工作方式就會全然不同：不會有政策屬于voice這個類别，因為語音和傳真中繼流量都比對dscp ef的條件，是以語音流量也會被歸入fax-relay這個類别中。圖2-3顯示了policy map voice-and-fax校驗各個資料包時的邏輯。
policy map需要與一個邏輯接口或實體接口進行關聯，這些接口包括：
主接口；
子接口；
多鍊路點到點協定（mlppp）束；
虛拟模闆；
虛拟區域網路（vlan）；
異步傳輸模式（atm）或幀中繼（fr）虛鍊路（vc）。
指令service policy同時也會指定相關政策應該應用到這個接口的哪個方向（入站方向還是出站方向）上，如例2-5所示。在不同平台上，這條指令的作用可能會略有差別，因為該指令也會應用于無線空間ssid（服務集标記）的設定當中。
例2-5 入站政策與出站政策
長期以來，mqc架構和文法結構始終支援層級式的結構，這可以讓管理者以子接口為機關來部署一部分政策（例如，讓穿越該子接口的某一類流量不高于某個速率），同時還能夠以接口為機關對所有流量應用全部政策（比如讓整形後的總速率符合服務提供商合同中的規定）。
圖2-4所示為管理者在主接口（gigabit ethernet 1）下的兩個子接口1.1和1.2上部署的分層政策。在這個示例中，這兩個子接口一共可以放行22kbit/s的流量進入主接口，通過整形，這個吞吐量被限制在20kbit/s以内。是以，如果這兩個子接口同時占用了全部配置設定給它們的帶寬，主接口就會額外實施流量整形政策，以保障穿越接口的流量之和不會超過20kbit/s。
在實施層級式的政策時，需要在policy map中（而不是接口配置模式下）應用service policy，如例2-6所示。這個案例顯示了在接口下，總流量都會整形為20kbit/s（policy-map aggregate），但在這個速率範圍内，語音流量可以獲得最小3kbit/s帶寬的保障。
在2006年，為了增強層級式的政策，以支援層級式隊列，出現了qos hqf（層級式隊列架構）的理念。這意味着隊列可以以子接口為機關進行應用（或者應用在邏輯接口的層面），同時接口隊列也能夠與這些邏輯級别的隊列共存。接口級的隊列算法可以反向作用于更進階别的隊列，以確定各個層級的資料包都能夠正常地排程和發送。
mqc cli存在于cisco ios系統中的時間已經超過了10年，但有些qos配置指令比mqc的曆史還要悠久。這些傳統的cli指令長期以來一直和mqc文法共存，是以導緻很多人在使用mqc配置的qos特性，與不使用mqc配置的qos特性之間如何互動這一方面，産生了很多誤解。是以，從2011年7月開始，一些比mqc古老的傳統qos cli指令就開始陸續從系統中删除；15.2m和15.2t版的系統釋出了警告，指出這些指令有可能會被取消。如果讀者有一些較老的平台正在使用這些指令，讀者應該盡早将它們轉換成對應的mqc指令。
總之，讀者務必将使用非mqc的cli指令行配置的qos特性轉換為表2-1中所示的相應mqc指令。如需進一步了解mqc指令的具體資訊，可以檢視cisco産品公告（pb）之legacy qos cli commands deprecation，pb580832，april 2012。
表2-1 将傳統qos cli修改為mqc cli的彙總資訊