還是那個網絡,有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設計》