为基于类的策略选择突发数据量和超额突发数据量
生活随笔
收集整理的這篇文章主要介紹了
为基于类的策略选择突发数据量和超额突发数据量
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
??什么是令牌桶
在我們討論突發數據量之前,我們首先要理解令牌桶的概念。令牌桶本身沒有丟棄和優先級策略,
令牌桶是這樣工作的:
1. 令牌以一定的速率放入桶中。
2. 每個令牌允許源發送一定數量的比特。
3. 發送一個包,流量調節器就要從桶中刪除與包大小相等的令牌數。
4. 如果沒有足夠的令牌發送包,這個包就會等待直到有足夠的令牌(在×××器的情況下)或者包被丟棄,也有可能被標記更低的DSCP(在策略者的情況下)。
5. 桶有特定的容量,如果桶已經滿了,新加入的令牌就會被丟棄。因此,在任何時候,源發送到網絡上的最大突發數據量與桶的大小成比例。令牌桶允許突發,但是不能超過限制。
Cisco IOS 流量策略(Traffic Policers)
IOS支持兩種流量策略:
1. 傳統的Cisco流量策略:CAR承諾接入速率,使用命令Router(config-if)#rate-limit {input | output} CIR (bps)
Bc(burst-normal) Be(burst-max) conform-action action exceed-action action
2. 新型的Cisco流量策略:基于類的策略(Class-based policer),使用模塊化Qos CLI(MQC)語法。可以使用MQC命令建立流量策略并把策略應用到接口。一個流量策略包括一個流量類(traffic class)和一個或多個Qos特性。Policy命令用來執行流量策略特性,它指定了一個流量類所需要的最大速率,超過這個速率Qos系統會立刻執行一個操作,標準的操作是丟棄或重置包頭的DSCP字段。Policy命令的語法是:
police cir Bc Be conform exceed violate
理解Bc和Be
對于超額的數據包,流量策略并不會把它們緩存稍候轉發,只有×××器(shaper)會這樣做。流量策略只執行一個發送或不發送的策略。因為不能緩存數據包,所以在發生擁塞時,所能做的最好的方法就是通過配置適當的超額突發數據量Be來不那么過分的丟棄數據包。這一點對理解流量策略使用Bc和Be來保證達到CIR是非常重要的。
超額參數模仿路由器的通用緩存規則。The rule recommends configuring buffering equal to the round-trip time bitrate to accommodate the outstanding TCP windows of all connections in times of congestion.
突發參數 目的 推薦公式
普通突發 · 執行標準的令牌桶 · 設置最大數量的令牌(盡管如果Be>Bc的話可以借到令牌). · 決定令牌桶有多大,因為如果桶已經滿了那么令牌將被丟棄而不會再加入到桶中。 CIR [bps] * (1 byte)/(8 bits) * 1.5 seconds Note: 1.5 seconds is the typical round trip time.
超額突發 · 為令牌桶提供超額突發能力 · 如果Bc = Be那么不支持超額突發 · 當Bc = Be,流量調節器就不能借令牌,當令牌不夠時只能丟棄數據包 兩倍的Bc
對TCP流量的測試表明,Bc和Be的數值應該近似等于配置的平均速率在兩秒鐘內的流量。如果你想限制流量在1Mb,應該把Bc設置在1-2Mb,Be在2-4Mb。
舉個例子,如果我們想把輸出速率限制在1.5Mbps,我們可以做一下步驟:
1. 把承諾速率從比特轉換成字節,因為突發數據量的單位為字節。
1500000 bits / 8 bits = 187500 bytes
2. 使用標準的1.5秒往返時間(round-trip time)計算Bc
187500 bytes * 1.5秒 = 281250 bytes
3. 兩倍的Bc為Be
281250 bytes * 2 = 562500 bytes
使用命令
rate-limit input 1500000 281250 562500 conform-action {action} exceed-action {action}
超額突發數據量
當數據包到達時可用的令牌數目小于包的大小,就可以使用超額突發數據量。包會請求借用令牌。可以通過配置大于Bc的Be的數值來為令牌桶提供超額突發能力。
可以通過下面兩個例子來理解Be。
第一個例子說明怎樣配置CAR策略來允許所有的IP流量。管理員在T3線路上提供了便宜的20Mbps的子速率服務。用戶只花費子速率帶寬的金額,也可以按需要增加帶寬。CAR限制了用戶可用的流量速率,用戶只能使用規定的速率加上承諾的突發數據量。可以適當的設置Be=32000。
interface hssi 0/0/0
rate-limit output 20000000 24000 32000 conform-action transmit exceed-action drop
下一個例子,用戶只能發送24000字節的突發數據量,所有超過限制的數據包都要被丟棄,因為設置Bc=Be,數據包流不能通過超額突發能力來借用令牌。
interface Hssi0/0/0
rate-limit output 20000000 24000 24000 conform-action transmit exceed-action drop
正確設置突發數據量的重要性
策略以字節為單位指定了突發數據量,基于類的策略(class-based policer)支持最小的突發數據量為1000字節,包括第二層包頭。
突發數據量的目的是逐漸的丟棄數據包,就像RED那樣,并且避免尾丟棄。設置足夠高的突發數據量對保證良好的吞吐量是非常重要的。
設置突發數據量時,考慮一下內容:
1. 如果突發數據量設置的過低,數據到達的速率將遠遠低于配置的速率。
2. 懲罰暫時突發對TCP流的吞吐量來說是相當不利的,具體情況請察看RFC 2001 and Random Early Detection (RED) gateways for Congestion Avoidance。設置突發數據量來允許路由器容納暫時突發。
3. 對離開接口的數據包的處理基于包的大小和桶中剩余的令牌數。
4. 在基于類的策略中,流量測量器不論接口是否擁塞都是激活的。每個包都會經過令牌桶測量系統來決定是否符合配置的參數。
5. 如果數據突發量非常大而且非常突然,那么配置較高的超額突發數據量可以保證超額令牌桶中存放較多的令牌。而且可以調整接口的MTU等于或大于突發數據量大小。
允許的突發數據量數值
最初,包括IOS12.0,rate-limit命令支持承諾和超額的突發數據量的范圍是:
Router1(config-if)#rate-limit input 18000000 ?
<8000-2000000> Normal burst bytes
Router1(config-if)#rate-limit input 18000000 2000000 ?
<8000-8000000> Maximum burst bytes
Router1(config-if)#rate-limit input 18000000 2000000
IOS12.1增加了突發數據量的最大值:
7500-107(config)#interface atm 1/0/0
7500-107(config-if)#rate-limit output ?
<8000-2000000000> Bits per second
access-group Match access list
qos-group Match qos-group ID
7500-107(config-if)#rate-limit output 18000000 ?
<1000-512000000> Normal burst bytes
7500-107(config-if)#rate-limit output 18000000 2250000 ?
<2000-1024000000> Maximum burst bytes
step-by-step流量策略指南
在12.0(5)XE流量策略特性模塊中提供了數據包如何進入一個配置了策略的接口的step-by-step的總結。總結需要理解堆積債務和復合債務。對于債務的概念,請察看IOS配置指南Policing and Shaping Overview。
下面這個例子中,離開接口F0/0的流量平均速率被設置為1bps,Bc為2btyes,Be為4bytes。
7200-uut(config)# class-map larry
7200-uut(config-cmap)# match access-group 2
7200-uut(config-cmap)# exit
7200-uut(config)# policy-map bird
7200-uut(config-pmap)# class larry
7200-uut(config-pmap-c)# police 1 2 4 conform-action transmit exceed-action set-qos-transmit 4
7200-uut(config-pmap-c)# exit
7200-uut(config-pmap)# exit
7200-uut(config)# interface fastethernet 0/0
7200-uut(config-if)# service-policy input bird
這個例子中所有的進入數據包都要制定的匹配標準相符合,并且在一個時間單位T內只有一個數據單元進入令牌桶。
1. 配置了Bc=2bytes,令牌桶中有兩個令牌,一個令牌等于1bytes。
2. 配置了1bps的平均速率,每個1byte的包需要一個令牌來獲得承諾操作(conform action)
3. 傳輸第一個包需要一個令牌,因為桶中能夠提供傳輸第一個包所需的令牌數,所以第一個包符合限制條件,被傳輸。桶中還剩下一個令牌。
4. 第二個包需要剩下的一個令牌,桶中也能夠提供傳輸第二個包所需的令牌數,所以第二個包也被傳輸。這時桶中就沒有剩余的令牌。
5. 第三個包還需要令牌,但是桶中已經沒有令牌了,超額突發被激活。
超額突發能力分析兩個數字:超額突發的大小和復合債務(compound debt)。超額突發大小通過CLI指定(本例中是4),復合債務等于上一次包被丟棄以來所有實際債務的和。
實際債務等于當前流所借的令牌數。實際債務的值可以由當前從桶中取出的令牌數(本例中借了一個令牌)乘以令牌被取出的次數(本例中是一次),這樣,傳輸完第三個包之后的實際債務就是1。
這個例子中復合債務與實際債務相等都是1,注意上一個包的復合債務加上當前包的實際債務也等于當前復合債務。
因為復合債務是1,小于超額突發數據量的4,所以第三個包也被傳輸。
6. 第四個包還需要令牌。
超額突發能力仍然在激活狀態。第四個包需要借用一個令牌,這是第二次借用令牌,因此實際債務變成2。復合債務等于傳輸上一個包的復合債務加上當前的實際債務,所以當前的復合債務是3(1+2)。3仍然小于配置的超額突發數據量4,所以數據包4也被承諾傳輸。
7. 第五個包也需要令牌。
超額突發能力仍然在激活狀態。實際債務是3,復合債務是6(3+3),超過了超額突發數據量,所以第五個包被超額操作(exceed-action)指定了Qos組4。超額操作發生之后復合債務歸零,而實際債務不受丟包影響,仍然是2。
8. 第六個包也需要令牌。
超額突發能力仍然在激活狀態。當然實際債務是3,注意在計算一共從桶中借了多少次令牌的時候要加上上次為包3和4所借的令牌。復合債務是3(0+3),小于超額突發,所以第六個包被承諾傳輸。
9. 第七個包也需要令牌。
超額突發能力仍然在激活狀態。實際債務是4,復合債務是7(3+4),超過了超額突發,所以第六個包執行超額操作。超額操作發生之后復合債務歸零,而實際債務不受丟包影響,仍然是3。
·
數據包順序 使用的令牌數 剩余令牌 實際債務 復合債務 對包的操作及原因
Before Packet 1 X 2 0 0
Packet 1 1 1 0 0 Transmit. No actual or compound debt.
Packet 2 1 0 0 0 Transmit. No actual or compound debt.
Packet 3 1 0 1 1 Transmit. Tokens are borrowed and counted against actual and compound debt, but the compound debt is still less than the excess burst size
Packet 4 1 0 2 3 Transmit. Tokens are borrowed and counted against actual and compound debt, but the compound debt is still less than the excess burst size.
Packet 5 1 0 3 6 Assign a QoS transmit value of 4. Because the compound debt exceeds the excess burst size, the exceed action is taken.
Packet 6 1 0 3 3 Transmit. After packet 5 is dropped, the compound debt resets to 0. However, the actual debt of 2 remains. Therefore, the new compound debt of 3 is lower than the excess burst size, so the packet conforms.
Packet 7 1 0 4 7 Assign a QoS transmit value of 4. Because the compound debt exceeds the excess burst size, the exceed action is taken.
實現Qos
簡介
本文介紹了在為諸如帶寬敏感(bandwidth-intensive)和延遲敏感(delay-sensitive)的應用提供傳輸服務的網絡中實現Qos所需的基礎知識。這些應用需要增強的處理和擴展的網絡資源。Qos可以通過管理網絡中的延遲、延遲抖動(jitter)、帶寬和丟包率為這些應用提供高安全、可預見的、可擴展的和有保證的服務。
什么樣的應用需要Qos
首先,找出關鍵性和需要保護的應用,應該察看所有的應用對網絡資源的使用情況,可以使用Netflow Accounting, Network-based Application Recognition (NBAR), or QoS Device Manager (QDM)對網絡流量進行分析。
Netflow Accounting可以根據每個流相應的優先級或級別來捕捉流從而分析網絡流量的細節。
NBAR是可以在應用層識別流的分級工具。他可以對通過一個接口的任一流進行基于每個端口的、每個協議的雙向(bi-directional)統計。也可以對子接口分類。
QDM是非常簡單的基于Web的管理工具,使用GUI界面,可以配置和監視高級的基于IP的Qos。
理解應用的特性
理解需要保護的應用是非常重要的,有些應用對延遲和丟包率非常敏感,而有些應用則被認為很有侵略性,因為他們對帶寬非常貪婪并經常有突發數據量。如果應用有突發,要考慮是小突發還是持續突發,應用程序的數據包大小怎樣,使用的是TCP還是UDP。
特性 方針
帶寬和延遲敏感的應用(Voice and Real Time Video) 不要使用weighted random early detection (WRED), traffic shaping, fragmentation (FRF-12)或policing。對這樣的延遲敏感應用應該執行 Low Latency Queuing (LLQ)并使用priority queue。
對帶寬貪婪并經常有突發(FTP and HTTP) 使用WRED, policing, traffic shaping或class-based weighted fair queueing (CBWFQ)來保證帶寬。
基于TCP的應用 若因為丟包而引起重傳則應使用WRED。如果是基于UDP的而且沒有重傳則不是用WRED。需要對應用進行限速(rate-limit),使用Policing。其他的使用tail-drop。
了解網絡拓撲
有些設備需要升級IOS才支持Qos,評估網絡拓撲圖、路由器配置和軟件版本會幫助了解有多少設備需要升級IOS。
1. 在網絡使用高峰時段察看路由器的CPU使用率對決定如何在多設備間分布Qos特性從而實現負載均衡有所幫助。
2. 區分關鍵流量和他要通過的接口,決定建立哪個優先級組來達到Qos目的。
3. 通過流量調節器(traffic shapers or policers)決定關鍵應用的最大延遲和突發參數。
4. 找出每個接口支持的速率:PVCs或子接口。
5. 找出低速連接接口,來幫助在適當的接口上實行Link Efficiency mechanisms。
6. 為每種將傳輸關鍵應用的媒體計算Layer 2和Layer 3的負載,這對計算每一級別流量的正確帶寬有所幫助。
7. 另一個關鍵是,希望基于應用,還是希望基于源目的IP來保護流量。
包頭尺寸
媒體類型 包頭長度
Ethernet 14 Bytes
PPP 6 Bytes
Frame Relay 4 Bytes
ATM 5 Bytes/Cell
建立基于標準的分類
一旦你決定哪個應用需要Qos以及使用哪個級別(基于應用的特性),就可以使用這些信息來建立分類。
創建策略來標記每一個類
創建策略使用適當的優先級值(使用不同的DSCP和IP優先級值)來標記流量的每一個類。流量在進入路由器的接口被標記,流量流出路由器時根據這個標記區分服務。
從邊緣向核心工作
從最接近流量源的路由器開始朝著網絡核心部署Qos。在路由器的輸入接口應用標記。在下面的拓撲圖中,Router A顯然是從網絡A到達網絡B的流量的標記點和策略應用點。流量在進入Router A的E0口時打上標記,在離開Router A的S1口時應用Qos策略。如果雙向流量被應用了相同的策略(網絡B到網絡A的流量有相通的待遇),那么從網絡B發往網絡A的流量過程相通。
一旦流量在路由器的進入接口被標記了,經過多跳仍然使用相同的標記(除非被再標記)。因此只需要標記一次。基于這些標記其他的路由器也支持Qos。你只需要把非信任域中的流量再標記即可。
建立流量轉發策略
標記過流量之后,你可以根據標記實行策略在網絡中實行流量分類。為了簡單起見我們推薦不要把流量分類超過4類。如果可能在實驗室里測試一下Qos的工作,有了滿意的結果在實行到使用網絡中。
應用策略
在適當的方向上應用策略,決定是單向還是雙向應用策略,在離流量源最近的地方標記流量。推薦雙向應用策略,這就意味著在Router A和Router B的S口上應用相同的策略。唯一的缺點就是分級始終激活而不管是否應用了Qos。
使用Qos策略管理器(QPM)監控策略效果
使用QPM作為自動的、可靠的、集中的策略管理管理系統。
推薦的Qos一般用途
下面的列表說明了Qos的種類和每個種類更廣泛的特性。
種類 相關的Qos特性
QoS Service Model Use provisioned (Diffserv) QoS rather than signaled (RSVP) when possible.
Classification/Marking Use Diffserv Code Points or qos-group ID.
Congestion Management Use LLQ or CBWFQ.
Congestion Avoidance Use Diffserv-compliant WRED.
Link Efficiency MLPPP, LFI, FRF.11, FRF.12, CRTP
Signaling RSVP, QPPB
Traffic Conditioners/Policing Use Class Based Policer and Generic Traffic Shaping (GTS) or Frame-Relay Traffic Shaping (FRTS).
Configuration/Monitoring QPM, Modular QoS Command Line Interface (CLI), QDM
轉載于:https://blog.51cto.com/kwsnh/472382
總結
以上是生活随笔為你收集整理的为基于类的策略选择突发数据量和超额突发数据量的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Extjs 动态改变列名
- 下一篇: QOS笔记分享