部署QoS的一點心得

還是那個網絡，有VPN，還要上網，部署QoS。

 

原來的QoS策略寫的已經不適合現在的情況了，最主要的是VPN內部的流量沒有分類，直接在WAN口上給了VPN流量一個LLQ。

原來VPN主要是給語音建的，所以還可以。不過現在VPN中的應用越來越多，這樣就不符合實際了。

 

好吧，你們肯定聽說過Pre-classify，那我們就說說這個東西。

 

我們的VPN比較特殊，GRE隧道受IPSec保護。GRE隧道的源是路由器上的一個loopback接口，目的是另一台路由器上的Loopback接口。

有人可能就問了，你這兩頭的loopback都是在內網的，你怎麼路由呢？

解決這個問題很簡單，因為有IPSec啊。用acl把兩頭的loopback的ip地址一劃，這數據包不就過去了嘛。

主要是IPSec設置Peer可以使用DNS解析名稱，GRE就不行，我這麼弄一下，也純粹是因為我們的peer都是動態IP+DDNS的。

別質疑，除了ISP每96小時給強制斷線，我們的Tunnel會掉個2分鐘，之後網絡自動恢復，無需干預。

我們已經這麼跑了半年了，非常穩定。

 

我們知道呀，GRE隧道的pre-classify是根物理接口有關係的。像我這樣的情況，在GRE上直接用Pre-Classify肯定是沒有作用的。

怎麼辦？想想企業級的QoS規劃應該怎樣做嘛～

 

我們應該在盡可能靠近end-users的地方進行流量分類，然後在網絡中根據分類的結果進行差別服務。

可惜我這裡現在的交換機是，好吧，它是非網管的。我只好把給流量分類的QoS策略應用在路由器的F0/0接口上了。（此口接內網）

如果你有可網管的交換機，你可以在交換機上進行協議分析，並將流量分類，打標（設置DSCP）。

 

好了，現在進入路由器的數據包，都被識別，並且有了獨特的DSCP值。

WAN接口我們就不用說了，直接設置一個策略，按照DSCP識別協議，並設置相應的排隊策略。

 

GRE和IPSec都可以把原IP頭的TOS字段複製到新的IP頭上，所以在已經對流量分類打標完畢之後，只需在WAN口按DSCP執行操作即可。

 

『IPSec協議標準中一開始就提供了保留原始IP頭部ToS字節信息的功能，方法是將其複製到由隧道和加密過程添加的IP頭部中。』——《端到端QoS設計》