示範： 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)#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)#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
在配置流量×××後，首先來觀察沒有大量資料發送時的各項狀态，可以看到如圖所示的各個流量×××選項，×××的目标速率為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機制後，再去購買更高的認購速率将會使企業的資源使用更充分，過渡更平穩，通常管這種行為叫做可持續的增長。