弈心：從事計算機網絡工作十年（新加坡7年，沙特3年），2013年考取CCIE，在新加坡先後任職于AT&T，新加坡交通部，蘋果，Equinix，蘇格蘭皇家銀行等大型企業、銀行和政府部門。 目前供職于“世界第一土豪大學“沙特阿蔔杜拉國王科技大學（KAUST），擔任Senior Network Engineer，為KAUST校史上第一位也是唯一一位華人IT部門高級職員。2019年6月在知乎發布了華語圈第一本專門為編程零基礎的網絡工程師量身打造的Python教程《網絡工程師的Python之路》。

今天聊下不少網工學了就忘，忘了又學，幹了一輩子網絡幾乎都沒一個完整的概念，甚至在工作中都沒太多機會接觸的一個技術話題：服務質量 (Quality of Serivce)。開篇前先講講為什麼我要在标題裡加入一個“網絡很難學”的副标。

很多人在知乎上或私信或付費咨詢向我詢問如何學習計算機網絡，如何在短時間内迅速在這行裡積累拿到高薪。這些朋友當中既有為高考後選擇大學專業感到困惑的大學新生，也有工作了若幹年對目前自己所在行業不甚滿意想要改行跳槽的職場人士。而我無一例外對他們的建議是：網絡知識很抽象、很枯燥、很難學，要想在這行走得遠，爬的高，你必須耐得住寂寞。

學網絡不像學編程，我可以10秒鐘教會你如何用python 3來print ("Hello World!")，5分鐘教會你什麼是列表，10分鐘教會你如何寫一個最簡單的for循環來遍曆列表裡的元素。但我沒辦法在同樣那麼短的時間内向你解釋清楚什麼是IP地址，什麼是子網掩碼（以及反掩碼），什麼是默認網關，更不用說跟你解釋清楚它們之間的關系（如果你沒有學過二進制就更難跟你講明白了），你就算把這類網絡最基礎的東西學會後也沒有像用編程語言打印出”Hello World”那種所見即所得的成就感可言，因為你身邊沒有一個現成的網絡給你練習和試手；别人學編程一台筆記本就夠了，你學網絡考證還得租機架在真機上練習。就算有模拟器這個東西，真實的網絡和模拟器也是天差地遠，還得重頭向你解釋怎麼使用模拟器，怎麼搭建環境，在哪裡下模拟器裡要用到的IOS鏡像文件；别人編程2,3個月能夠開發一個網站，寫個小程序，你學兩三個月還在啃CCNA的書，還在背題庫準備迎接考試。。。總之一言以蔽之：網絡很難學，真的很難學，這個行業沒有捷徑可走，沒有短期拿高薪的可能，如果你耐不住及寂寞，那麼請謹慎入坑。

說完副标來說正題：

筆者從業10年來面試過不少人，發現很多網工對各種常用的VLAN，STP, NAT, 各種動态路由協議，網絡抓包排錯，甚至MPLS等等技術都掌握的很不錯，但是一向他們問到QoS，這個相對前面提到的那些二、三層來說并不是那麼常用的技術的相關問題時，他們的表現就不那麼理想了。雖然不少人能正确回答EF的DSCP值是什麼，能說出思科的MLS和MQC的區别及分别對應什麼型号的交換機，知道語音網絡對延遲，抖動，丢包能承受的範圍是多少，能給我講明白AF11和AF13在網絡阻塞時哪個更有可能被丢棄，也能畫圖給我解釋清楚流量整形(shaping)和流量整治(policng)的區别，因為這些都是書本上能找到答案，能夠背下來的知識點。

但是當我拿出實際工作中遇到的和QoS相關的問題，并向他們詢問排錯思路、解法以及相應的原理是什麼時，很少有人能完美的講個清楚，所以今天這篇文章就來聊聊兩個網絡中常見的和QoS相關的問題及其解法。首先來看問題一：

問題一

背景：

網工A最近剛剛入職一家新公司，該公司的網絡配置采用的是End-to-end QoS(端到端的QoS)的設計, 所有接入層交換機（思科3750）和彙聚層交換機（思科4509）都開啟了QoS，接入層交換機下接網絡電話的端口以及彙聚層交換機連接接入層的交換機的端口都配置了mls qos trust dscp，劃分好了信任邊界。 剛入職的網工A為了盡快了解現有網絡的規劃和部署，便将每台交換機的配置拿出來學習研究，他發現所有交換機中唯獨有一台接入層交換機沒有開啟QoS：

access-sw#sh mls qos QoS is disabled

于是便自作主張在該交換機上開啟了QoS，但是随即網工A就收到了其他組同事開來的ticket，他們有一台服務器直連在該交換機下，在該服務器上跑的程序一直因為高延遲的問題而報錯。

問題：

網工A并沒有改變該交換機下任何端口的配置，僅僅隻是在這台3750上開啟了QoS，請問為什麼會導緻終端用戶應用延遲的問題發生？講下原理和解法。

問題二

背景：

某土豪大學為所有師生和職員提供别墅作為住房，每棟别墅都配置了一台思科2960交換機，該2960交換機的級聯端口（光纖）和用戶端的端口（RJ45）均為100兆的Fastethernet，最近學校升級住家網絡，将級聯端口的SFP transceiver從100兆的GLC-FE-100BX-U換成了1G的GLC-BX-U，所有住家用戶的2960交換機均開啟了QoS(mls qos)，級聯端口的配置如下（網速升級後沒有對交換機的配置做任何更改）：

interface GigabitEthernet0/2 switchport trunk allowed vlan 2232-2235,3208,3999 switchport mode trunk switchport nonegotiate load-interval 30 media-type sfp srr-queue bandwidth share 1 40 30 30 priority-queue out mls qos trust dscp spanning-tree bpdufilter enable ip dhcp snooping trust

問題：

将級聯端口從100M升級到1G後，不久就收到用戶的投訴，說他們家裡的網速明顯變慢了很多，你在排錯時做了speedtest，将級聯端口為100M時的測速結果和1G時的測速結果做了對比，結果如下：

級聯端口為100M時，下行速度達到了93.9Mbps。

級聯端口為1G時，下行速度隻有8.31Mbps。

請問為什麼？不用給出具體配置方案，講講排錯思路，以及涉及到的知識點即可。

答案：

這兩道題都是筆者在工作中親自碰到過的實戰問題，具有極強的實用性，計算機網絡那麼多知識點裡面就數QoS最抽象，最難學，很多網工能背下書本上的各種理論，但是一旦碰到和QoS相關的實戰問題就會顯得手足無措，不知從何下手。也有小部分網工能解決問題，但是無法系統的說出該問題涉及到了QoS的哪個知識點及其原理。筆者當年也是查閱了很多資料才做到了“知其然還要知其所以然“，希望下面的解答能給大家一點啟發。

問題一解答

在回答"為什麼網工A開啟QoS後，用戶端程序出現了延遲問題"之前，先來看下"為什麼QoS在沒有被開啟的時候一切正常"。答案其實很簡單：在QoS被關閉的時候，交換機對其吞吐的流量不做任何事情，從QOS的角度來講，這時沒有信任(Trust)和不信任(Untrust)之分，交換機不管這些流量自帶的是什麼DSCP, COS還是IPP值，統統放行。換句話說，這時給該程序流量做QoS标記(marking)的恰恰就是程序本身，并且該标記沒有受到任何行為約束，自然該流量一切正常，沒有延遲發生。

當網工A開啟了QOS之後，交換機馬上做了兩件重要的事情：

1. 所有端口默認為不信任任何DSCP值，也就是說該交換機所有端口的配置裡現在多了一條"no mls qos trust dscp"。

2. 所有不信任DSCP值的端口會對流經該端口下的程序流量進行DSCP重寫(ip packet dscp rewrite)，默認狀态下，所有程序自帶的DSCP值将被交換機重設為0。

這點可以在3750上show mls qos驗證(看到QoS ip packet dscp rewrite is enabled了嗎？）：

access-sw(config)#mls qos
access-sw(config)#end
access-sw#sh mls qos
QoS is enabled
QoS ip packet dscp rewrite is enabled

那麼DSCP被重設為0意味着什麼？意味着現在該程序的流量在該網絡下被分類為了BE(Best Effort，盡力而為)流量，BE流量出現高延遲的情況并不罕見。

解法：

找到問題的原因後就可以對症下藥了，這道題大緻有如下幾種解法：

1. 在連接服務器的端口下開啟mls qos trust dscp，這個是最簡單也是最直接的辦法。

mls qos trust dscp

2. 還有一種很多人不太了解的解法，就是在交換機上開啟DSCP透明模式(DSCP transparency mode)， 讓交換機不要重設不信任端口下收到的流量的DSCP值，(言下之意就是關閉默認開啟的DSCP重寫功能），開啟DSCP透明模式的命令如下：

no mls qos rewrite ip dscp

3. 創建一個ACL來匹配該程序流量，然後手動将它标記為它原有的dscp值（複雜，不推薦）。

問題二解答

給出這道題的解法和原理之前，我們可以把級聯端口和用戶端口看成兩根水管，先來看下級聯端口提速前後的變化：

1. 提速前：用戶端口和級聯端口均為100Mbps, 下行流量從級聯端口到達用戶端口時不會發生擁塞現象，因為兩根一樣粗的水管的容量是一樣的。
2. 提速後：級聯端口變成了1G，管子增大了10倍，而用戶端口依然是100M，你現在将大水管裡的水往隻有它容量10分之1的小水管裡灌水，顯而易見會發生擁塞現象。

既然涉及到了網絡擁塞的現象，那自然而然就涉及到了QoS的隊列(queueing)以及緩沖(buffering)的問題。隊列的知識點又分為入隊列(Ingress Queue)和出隊列(Egress Queue）。這道題出現問題的是下行速度，所以我們要關心的是用戶端口的出隊列。

下面簡要回顧一下出隊列的相關知識點，注意加粗斜線部分為涉及到本題的重點内容， 其他部分了解即可。

• 在思科的IOS交換機裡面（以這裡的2960為例），每個交換機端口有4個出隊列。每個隊列默認分配的緩存空間(buffer size)相等，都為緩存總量的25%（思科2960的硬件緩存總量為2MByte），緩存的作用是在交換機出隊列出現擁塞的時候，額外分配硬件資源給出隊列，換句話說就是分配更多的帶寬給出隊列，也就是把這道題裡我們所比喻的客戶端管子加粗。每個隊列保留自己所得緩存空間的50%作為保留阈值（threshold）。其中隊列1使用shaped模式，其他3個隊列使用shared模式，換句話說隊列1隻能使用總緩存空間的25%，超出這個空間的數據将被丢棄，而其他3個隊列則是共享剩下的75%緩存空間，也就是它們理論上可以“獨享”75%的緩存空間。
• 要了解出隊列還必須了解Queue-set。Queue-set本身是一個列表， 用來設定每個出站隊列的buffer資源如何分配和使用。用戶可以自定義的queue-set有兩個：queue-set 1 和 queue-set 2。每個交換機的端口一次隻能使用一個queue-set， 默認情況下，所有交換機的端口都在queue-set 1下。

我們可以使用show mls qos queue-set命令來查看Queue-set 1 和 2的參數，你可以看到默認狀态下4個隊列分别分配到了25%的buffers.

2960#show mls qos queue-set Queueset: 1 Queue : 1 2 3 4 ---------------------------------------------- buffers : 25 25 25 25 threshold1: 100 200 100 100 threshold2: 100 200 100 100 reserved : 50 50 50 50 maximum : 400 400 400 400 Queueset: 2 Queue : 1 2 3 4 ---------------------------------------------- buffers : 25 25 25 25 threshold1: 100 200 100 100 threshold2: 100 200 100 100 reserved : 50 50 50 50 maximum : 400 400 400 400

• 每個出站隊列的buffer有3個阈值（threshold）：threshold 1, threshold2, threshold3。其中threshold 1和threshold 2可以自定義，threshold 3為固定值（100%），不可修改。 上面的命令Show mls qos queue-set的時候隻能看到threshold 1和2，看不到threshold 3。阈值的意思是，如果一個隊列使用的buffer達到了由阈值定義的百分比，則交換機開始丢包。比如說使用threshold 3（100%），那麼交換機會在buffer的使用率達到100%後開始丢包。阈值1和阈值2最大可以修改到3200。

說了那麼多，也許你有點眉目了，就是因為在擁塞情況下，交換機默認給每個出隊列25%的buffer不夠用，以緻丢包，最終造成下行速度在級聯端口升速後驟降。

如果你有經驗的話，你可以show interface x/x | i output drops以及show mls qos interface x/x stat | b dropped這兩條命令來查看output方向的丢包情況，通常這種級聯端口和用戶端口帶寬不對稱的情況都會造成output drop嚴重的問題(在跑完測速後，測速機器所連的用戶端口fa0/2的Total ouput drops 達到了9346180，這個數字和隊列2阈值1的丢包數據相同！

2960#show int fa0/2 | i output drops Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 9346180 2960#sh mls qos int f0/2 stat | b dropped output queues dropped: queue: threshold1 threshold2 threshold3 ----------------------------------------------- queue 0: 0 0 0 queue 1: 9346180 0 0 queue 2: 0 0 0 queue 3: 0 0 0

** 注意這裡的queue 0對應的是出隊列1， queue 1對應的是出隊列2, 以此類推。

解法：

要解決這個問題，還要了解DSCP值和4個出隊列的映射關系。

我們可以通過show mls qos maps dscp-output-q這個命令來查看DSCP值與出隊列即阈值的映射關系：

2960#show mls qos maps dscp-output-q Dscp-outputq-threshold map: d1 :d2 0 1 2 3 4 5 6 7 8 9 ------------------------------------------------------------ 0 : 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 1 : 02-01 02-01 02-01 02-01 02-01 02-01 03-01 03-01 02-01 03-01 2 : 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01 3 : 03-01 03-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 4 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 04-01 5 : 04-01 04-01 04-01 04-01 04-01 04-01 01-01 04-01 04-01 04-01 6 : 04-01 04-01 04-01 04-01

• 這個表的d1表示DSCP值的十位數，d2表示個位數。
• 02-01表示出隊列2，阈值1。 04-01表示出隊列4，阈值1， 依次類推。

回到這道題來看，我們做測速的時候是在某測速網站做的，互聯網流量的DSCP值為0，也就是BE盡力而為。通過上面的映射表可以看出，DSCP 00對應的是02-01，也就是出隊列2，阈值1。

知道了流量對應的出隊列和阈值後，我們就可以手動修改交換機對每個出隊列的緩沖空間的分配了，既然默認的25%不夠，那麼我們可以多分點，比如分60%給出隊列2，再把阈值1調高到3200。兩條命令分别如下：

2960(config)# mls qos queue-set output 1 buffers 10 60 15 15 2960(config)# mls qos queue-set output 1 threshold 2 3200 3200 50 3200

首先講下這條命令mls qos queue-set output 1 buffers 10 60 15 15， 這裡的1表示queue-set 1，前面提到了IOS交換機有兩個queue set，默認使用的是Qset 1，所以這裡我們就直接改Qset 1的配置。 後面的10,60,15,15的意思也許你也猜到了，就是分别給出隊列1分配10%的buffer, 給出隊列2分配60%的buffer, 給出隊列3分配15%的buffer, 給出隊列4分配15%的buffer。

第二條命令mls qos queue-set output 1 threshold 2 3200 3200 50 3200， 這裡output後面的1表示的依然是Qset 1， threshold後面的2表示的是出隊列2，第一個和第二個3200分别表示阈值1和阈值2，50表示默認的保留阈值（前面有提到），最後的3200表示最大阈值。

配置好這兩條命令後，問題完美解決。關于思科IOS交換機的完整出隊列機制可以用下圖概括起來。

結語：

如果從難度來評價這兩道題的話，第一道題姑且算中級，第二道題則是真正的專家級難度，我在技術面試環節問到QOS時通常會用這兩道題來考應聘者。

就如我在上篇文章裡提到的一樣：

當我在面試的時候向應聘者問到QoS相關的問題時，雖然不少人能正确回答EF的DSCP值是什麼，能說出思科的MLS和MQC的區别及分别對應什麼型号的交換機，知道語音網絡對延遲，抖動，丢包能承受的範圍是多少，能給我講明白AF11和AF13在網絡阻塞時哪個更有可能被丢棄，也能畫圖給我解釋清楚流量整形(shaping)和流量整治(policng)的區别，因為這些都是書本上能找到答案，能夠背下來的知識點。
但是當我拿出實際工作中遇到的和QoS相關的問題，并向他們詢問排錯思路、解法以及相應的原理是什麼時，很少有人能完美的講清楚。

QoS很難，真的很難，要想在這行混得好，成為真正的技術大神，那就絕對不能抱有“不求甚解”的态度。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部