演示： GTS流量×××和CAR流量监管的效果及相关实践计划
?演示： GTS流量×××和CAR流量監管的效果及相關實踐計劃
演示目標：
1 理解clock rate(時鐘頻率)和bandwidth（帶寬）與接入速率的關系
2 在模擬運營商的接入路由器ISP上配置CAR監管用戶流量到認購速率64K
3 取證模擬的企業網絡以128K的接入速率沖擊64K的認購監管速率，出現數據丟包現象
4 通過在企業邊界R1上作流量×××，將128K×××為64K的速率，看到延遲增大，緩解丟包
5 企業發送同樣大小的包，將接入速率（AR）改變成與認購速率相同，此時會發生什么情況？
演示背景：
R1和R2的10MB以太網部分模擬企業的內部高速網絡，R1和ISP路由器的串口鏈路部分模擬企業到運營商的WAN鏈路接入，將ISP的時間頻率配置為128000，那么此時整個鏈路的接入速率AR就是128K，也就是說R1將以128K的速率發送數據到ISP，但是由于企業只支付了64K認購速率的費用，所以運營商會使用監管工具將用戶的發送速率監管在64K范圍內，如果有超過的數據包，那么這些超過的數據包將被丟棄，為了避免過量的數據包被丟棄，所以在路由器R1上部署流量×××，以犧牲更大的延遲來緩解丟包。
演示環境：如圖所示：
演示步驟：
第一步：配置路由器R1和ISP之間的串口鏈路，讓ISP提供時鐘，并將時鐘配置為128000，帶寬配置為128K，注意在這個環境中，完成這樣的配置，其主要的目標是讓鏈路的接入速率為128K，要將鏈路的接入速率仿真為128K，必須將時鐘頻率配置為128000，因為決定速率的關鍵因素是時鐘頻率，關于這一點后面有詳細描述。注意這樣這樣配置，才能讓整個實驗最大程度接近真實，讀者才能看到監管和×××的不同效果。
?
ISP路由器的配置：
ISP(config)#inte s1/0
ISP(config-if)#ipaddress 192.168.1.2 255.255.255.252
ISP(config-if)#clockrate 128000*配置時鐘頻率為128000
ISP(config-if)#bandwidth 128????? ?*配置帶寬為128K
ISP(config-if)#noshutdown
ISP(config-if)#exit
?
請嚴格區別clock rate和bandwidth的不同意義：
?? ?Clock rate是定義了真實的物理層轉輸的bit（比特率），這被路由器應用到需要提供時鐘頻率的接口上，比如某臺路由器的同步串口上(S1/0)，所以鏈路真正的傳輸速率是由Clock rate來決定，而bandwidth是通過申明帶寬來告之路由器的一些其它應用，當前的帶寬是多少，這種典型的應用包據OSPF或者EIGRP再計算路由度量值的時候使用。在計算度量值是使用的是bandwidth，而不是依據Clock rate，但是bandwidth是不應響真實的發送率的，最后建議將bandwidth與clock rate進行對應配置，比如鏈路的時鐘頻率為128000，那么建議將帶寬配置為128K。
?
ISP(config)#inteloopback 1
ISP(config-if)#ipaddress 192.168.4.1 255.255.255.0
ISP(config-if)#noshutdown
ISP(config-if)#exit
?
ISP(config)#router rip?????????? * 在ISP的網絡設備上公告路由
ISP(config-router)#noauto-summary?
ISP(config-router)#version2
ISP(config-router)#network192.168.4.0
ISP(config-router)#network192.168.1.0
ISP(config-router)#exit
?
路由器R1的基礎配置：
R1(config)#intes1/0
R1(config-if)#ipaddress 192.168.1.1 255.255.255.252
R1(config-if)#bandwidth128??? * 為路由器R1配置物理鏈路的接入帶寬
R1(config-if)#noshutdown
R1(config-if)#exit
?
??? 注意在配置R1的S1/0接口的接入帶寬時，請將其配置為與DCE端（ISP路由器）的時鐘頻率相同，如圖所示，因為時鐘頻率是128000，所以請將R1的帶寬也配置成128K。
R1(config)#intee2/0
R1(config-if)#ipaddress 192.168.2.1 255.255.255.0
R1(config-if)#noshutdown
R1(config-if)#exit
?
R1(config)#routerrip???????????? * 在R1上啟動并公告路由
R1(config-router)#noauto-summary
R1(config-router)#version2
R1(config-router)#network192.168.1.0
R1(config-router)#network192.168.2.0
R1(config-router)#exit
?
路由器R2的基礎配置：
R2(config)#intee2/0
R2(config-if)#ipaddress 192.168.2.2 255.255.255.0
R2(config-if)#noshutdown
R2(config-if)#exit
?
R2(config)#routerrip?????????? * R2上啟動并公告路由
R2(config-router)#version2
R2(config-router)#network192.168.2.0
R2(config-router)#noauto-summary
R2(config-router)#exit
?
第二步：ISP路由器的S1/0接口上，也就是允許企業接入ISP的接入端口配置基于CAR的流量監管，監管的具體內容如下所示：將流量監管到每秒64K，監管到該速率的原因可能是企業用戶只向ISP運營商支付了64K速率的流量費用，然后配置持續突發Bc為1500個字節，而最大突發（Bc+Be）=2000個字節，事實上，真正的Be只有500個字節。如果滿足CAR語句所定義的監管范圍，數據將被轉發，如果超過了監管范圍，那么這些數據包將被丟棄。
?
在ISP上配置基于CAR的流量監管：
ISP(config)#interfaceSerial1/0
ISP(config-if)#rate-limitinput 64000 1500 2000 conform-action transmit exceed-action drop
?
注意這里的Bc=1500個字節，并沒有使用公式Bc=Tc*CIR也就是Bc=0.125*64000=8000bits，再將8000個位除以8得到1000個字節的原因是：因為Bc大小不能低于接口的MTU值，關于這一點在12.7.5關于CAR使用Bc=監管速率*Tc來確認Bc時的小故障中已經作了詳細描述，因為目前ISP的S1/0的接口使用的是1500個字節作為MTU，所以將Bc配置為了1500字節。
?
第三步：在該實驗環境中模擬的企業內部路由器R2上，發起對192.168.4.1的ping，連續發50個ping包，每個ping包的大小為2000字節，以192.168.2.2作為源地址ping192.168.4.1。具體的顯示結果如圖所示：可以看出在帶上如圖所示的各項參數完成ping時，192.168.2.2到192.168.4.1的流量有嚴重的丟包現象。數據的成功率只有66%,50個包通了33個，丟棄了17個包，平均延遲為91ms。然后可以通過show interfaces s1/0rate-limit指令查看到超過CAR定義監管范圍的17個包被丟棄，如圖所示，
分析為什么現在會存在嚴重的丟包現象？
???? 在一個網絡中存在丟包的原因，有很多種，目前這種嚴重丟包的現象，主要是因為用戶網絡以接入速率(AR)128K來發送數據，而ISP路由器的監管器將限制進入的流量為64K，所以就產生了如圖示的“瓶頸效應”，由于沒有使用流量×××，并且配置CAR將超過認購流量的數據包執行丟棄（注意確認超過認購流量的算法是令牌桶算法，而不是簡單的對流速的加減法），所以才會出現嚴重的丟包。那么此時需要對用戶網絡的路由器R1配置流量×××，將接入速率128K×××為認購速率也就是CIR速率64K，然后緩存超額的包，等到下一個周期再發送超額的包，來盡量避免丟棄，這樣做的目標是使用流量×××去匹配ISP運營商的流量監管，所以在實踐的環境中流量×××一般會和流量監管配合使用。
第四步：在R1上配置流量×××，將128K的接入速率×××為64K的認購速率，而在配置流量×××時，流量×××中的Bc和Be參數，讓IOS系統根據配置的×××速率64K去自行計算，無需管理員手工配置，這也是思科的建議的思想，具體配置如下所示：
?
在路由器R1的S1/0接口上執行流量×××的配置：
R1(config)#inte s1/0
R1(config-if)#traffic-shaperate 64000? * 使用GTS配置流量×××的速率為64K
R1(config-if)#exit
?
?? ?在配置流量×××后，首先來觀察沒有大量數據發送時的各項狀態，可以看到如圖所示的各個流量×××選項，×××的目標速率為64000、Bc為8000位（1000字節）、Be為8000位、Tc是125ms、Bc+Be為2000字節，關于各個選項的參數都是根據Bc=CIR*Tc的公式計算而來，而關于這個公式的計算在前面的小節有更詳細的描述。
然后可以通過show traffic-shape statistics指令來查看流量×××的狀態，如圖所示，目前的流量×××為非激活狀態，因為此時暫無任何大量的數據發送，流量×××只在用戶發送的數據超過擬訂的×××速率（根據令牌桶的算法決定）后，才會被激活，如果無數據發送或者發送的數據根據令牌桶的算法后低于×××速率，那么流量×××將永遠不會被激活。
注意：如果用戶發送的流量沒有超過×××條件，那么流量×××將不被激活！
?
??? 現在在路由器R2上使用與先前相同的Ping參數及攜帶數據包的大小來ping192.168.4.1,具體配置如圖所示，可以看到在相同的流量監管條件下，因為用戶配置了流量×××功能，并將128K的接入速率×××為64K的認購速率，也就是去匹配了ISP運營的監管速率，所以此時的流量沒有任何丟包現象，為什么不發生丟包？原為流量×××緩存了數據包，它以犧牲更大的延遲作為代價來換回數據包不被丟棄，所以它的平均延遲將增大，如圖所示，平均延遲為249ms，而在沒有執行流量×××之前的平均延遲是91ms。
? ??在流量持續的發送周期中，可以來到路由器R1上，通過show traffic-shape statistics來查看對流量×××的統計數據，如圖所示，下面顯示了流量×××隊列的深度，沒有被×××的數據包，以及被×××延遲的數據包，以及目前的流量×××狀態為激活狀態。
根據上面的實驗可以得到一個關于流量管理的經驗：
應該盡量讓用戶接入速率（AR）去匹配在ISP運營商處所購買的認購速率（也叫CIR），通過上面的實驗取證了一個道理：接入速率（AR）并不是越高越好，而應該是讓接入速率（AR）越匹配認購速率越好。如果無法更改接入速率（AR）,那么就需要使用流量×××將接入速率（AR）×××為與認購速率相匹配，讓網絡中的數據包平滑過渡，避免過大的抖動和丟棄。注意很多時候把接入速率也叫做用戶的物理速率。同時還可以看出在很多時候流量×××是伴隨流量監管在使用，為什么這樣講呢？很簡單通常管理員對某個用戶正在執行流量監管（或者叫限速），這大抵意味著用戶的接入速率正高于管理員不希望的速率，所以才來限制用戶，而正是因為這種限制可能會導致用戶丟包，從而引發用戶要使用流量×××來放慢和平滑發送速率。
?
在實踐中工程人員可能提出的問題：
?
提問1:前面的描述一直在強調一個問題，就是讓用戶接入速率（AR）去匹配在ISP運營商處所購買的認購速率（也叫CIR），那么在這個實驗環境中，如果現在將用戶的接入鏈路（AR）的時鐘頻率及帶寬都改成64K，這樣就可以與認購速率64K相匹配了，同時不再使用流量×××，會發生丟包嗎？
將接入速率（AR）更改為與認購速率相匹配的64K，而不再使用流量×××，如果仍然是ping50個包，然后每個包帶2000字節的重量，會明顯發現：處于64K的接入速率時丟包沒有先前接入速率處于128K時那么嚴重，會有明顯好轉，但是可能仍然會存在丟包，此時丟包的原因就不是接入速率AR高于認購速率所產生的問題了，因為接入速率AR高于認購速率是造成丟包的一個重要原因，但是不是唯一的原因，比如：雖然接入速率與監管速率匹配了，但是由于產生的高額流量是持續不間斷的發送，超過了鏈路本身能承受的壓力，此時盡管用戶的接入速率與監管速率相匹配，但是它仍然會丟包。而這種高額流量的產生來源取決于應用程序本身，比如該實例中，筆者正使用一個持續的帶大型數據的ping來制造高額流量，在實際的環境中可能是視屏系統，或者其它的軟件。
?
提問2：如果出現了提問1中所描述的雖然接入速率與監管速率匹配了，但是由于產生的高額流量是持續不間斷的發送，超過了鏈路本身能承受的壓力，造成丟包，該怎么辦？
??? 第一步：首先通過統計分析流量并計算后，然后在用戶的邊界設備上執行流量×××，這就是所謂當接入速率與監管速率匹配了，但是為更好的平滑流量作為最大的目標來作的流量×××處理。如果在這種情況下被丟棄的程度得以緩解，那么請感覺上帝啟法您的這個決定。但是此時請謹慎的考慮IP語音流量，如果還是出現丟棄。
第二步：請聯系運營商，并申請運營商在不違反你的認購速率的前提條件下，適當加大對你監管的持續突發和最大突發，當然這種增加是適當的，適當的前提條件不違反你的認購，這樣可以讓用戶的網絡流量性能得到最大的價值，如果用戶以一種更專業的眼光來看認購速率，請您一定記住：在簽訂那一張紙（流量認購合同）時，您有權力要求運營商出了申明認購的承諾速率CIR是多少的同時要求對持續突發和最大突發進行說明或者書面承諾，即便是你會讓他很不開心。通常這種方案能緩解你丟棄的現象。如果這樣做還不能達到用戶的目標。
第三步：如果完成了前面兩個步驟，并確定不是由于用戶內部網絡的某個故障所導致的，那么此時用戶需要做的就是向運營商申明和購買更高的認購速率了。但是用戶所在的企業高層不愿意為購買更高的認購速率而支付更多的費用。
第四步：此時用戶唯一的辦法就是限制內部用戶對一些非重要數據的訪問速率，避免這種不重要的訪問和下載來占用寶貴的WAN帶寬，然后在現有的，已經出現匱乏的帶寬資源條件下，采取本章后面描述的各種隊列調度機制和擁塞避免機制去更合理的執行隊列調度，比如：將非常重要的數據流量放入低延遲隊列或者優先級隊列中執行調度，其實這也是充分使用QOS技術來保證服務質量的核心所在，但是這種做法并不能從根本上解問題，也是一種“割股充腹”的行為，因為隨著用戶企業內部網絡的不斷擴展，對流量的需求不斷提高，最終用戶還是需要通地購買更高的認購速率來緩解流量需求，但是通過在部署QOS機制后，再去購買更高的認購速率將會使企業的資源使用更充分，過渡更平穩，通常管這種行為叫做可持續的增長。
轉載于:https://blog.51cto.com/7658423/1577240
總結
以上是生活随笔為你收集整理的演示： GTS流量×××和CAR流量监管的效果及相关实践计划的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 扫描网络计算机mac地址,局域网MAC地
- 下一篇： Excel闪退