理解流量監管中的CAR工具、單雙桶及欠償機制、CAR配置及經驗
流量監管同樣使用令牌桶（單桶或者雙桶）算法，現在來介紹一個典型的流量監管工具CAR（committed access rate）承諾訪問速率，CAR的工作目標是判斷數據流量是否匹配或者超過認購流量（合同流量也叫CIR），能對匹配認購流量的數據包或者超過認購流量的數據包執行轉發、丟棄、或重標記（一般是降低優先級）。需要注意的是CAR填充令牌桶中的令牌，一個令牌代表可以接收或者發送一個字節（byte）的數據或不是位（bit）。
注意：通過前面對令牌桶的描述，大家應該清晰這個算法了，下面的描述將基於CAR在單桶（只有Bc）和雙桶（Bc和Be同時存）在的情況進行討論。
CAR使用單桶算法（只有Bc）
CAR會在一個時間間隔Tc往桶1（Bc）中填充令牌，注意這裏一個令牌代表一個字節，所以Bc的單位是字節，這和流量×××中Bc使用比特爲單位不同，可以通過公式Bc=監管速率*Tc，一般監管速率都被配置成CIR，Tc默認爲125ms。由於使用目前不存在Be所示CAR的判斷非常簡單，只有兩種情況：
如果數據包的字節數小於或者等於（<=）桶1（Bc）的容量，也就是<=桶1的字節數那麼該數據包被視爲能匹配認購流量的數據包。CAR會移除和該數據包大小相同的令牌數，這個行爲叫做conform 。
如果數據包的字節數大於（>）桶1（Bc）的容量，那麼該數據包被視爲超過認購流量的數據包，CAR不會移除令牌，這個行爲叫做exceed。
必須注意的一件事情：在理解令牌桶算法的時候（無論是單桶或者雙桶），實際上這都是一種形象的比喻，並不是路由器內部真正存在兩個桶。筆者將單桶和雙桶分開描述是爲了讓讀者能使用漸進式的方法來理解。所以在這裏爲了給後面配置CAR的時候打下基礎，需要特別的說明，CAR是必須去明確的逐項申明監管速率（一般爲CIR）、持續突發Bc、最大突發（Bc+Be）分別是多少，不能只配置CIR然後，讓系統自行計算Bc和Be，這與流量×××不同，而且配置是否使用第2個桶（Be）的方式和流量×××不同，這將在12.7.4部署CAR行爲時作更多的描述。
CAR使用雙桶算法（同時有Bc和Be）
CAR使用雙桶算法時，將使用一個更復雜的算法來決定數據包是匹配還是超過認購流量，CAR將在耗盡Be（事實上此時Bc肯定耗盡了）之前來確認，那些超過的包，哪些屬於conform，哪些屬於exceed。但是這個決定沒有像單桶那麼簡單，它關係到一個“debt（欠償）”機制和欠償變量（compounded debt Dc）的計算。這切的原因都來自於CAR使用了雙桶，它的過程是這樣的：
當CAR同時使用Bc和Be時：
1如果數據包的字節數小於或者等於（<=）桶1（Bc）的容量，也就是<=桶1的字節數那麼該數據包被視爲能匹配認購流量的數據包。CAR會移除和該數據包大小相同的令牌數，這個行爲叫做conform 。
2 如果數據包的字節數大於（>）桶1（Bc）的容量，但是小於桶2（Be），那麼該數據包將被CAR使用debt（欠償）機制來決定，該數據包是conform或者exceed，因爲你現在使用了兩個桶，所以這一切將和桶2（Be）有關，那麼什麼是debt（欠償）機制（很多也叫欠償算法）
理解debt（欠償）機制
因爲使用雙桶算法，所謂debt（欠償）的意思就是，如果一個新到來的數據包尺寸（事實上就是字節）大於了桶1（Bc）中的令牌數，這個時候CAR將向桶2（Be）借令牌，然後一個Tc時間間隔後，如果桶1中的令牌不被徹底用完，比如用戶低於監管速率發送數據，或者有一段間沒有發送數據，那麼桶1的令牌將被充滿，然後此時桶1用溢出的令牌來償還先前向桶2（Be）借的令牌。
假設此時，桶1(Bc)的令牌已經耗完，等於0，而桶2（Be）還有8000個字節的令牌，此時剛好有一個1000字節的數據包到達，CAR發現桶1沒有可用令牌了，它就去向桶2借，因爲目前桶2有8000個令牌，所以它可以借出1000字節的令牌，此時這個1000字節的數據包將被認爲是一個conform的數據包，因爲它雖然大於Bc但是它小於Be，然後桶2的令牌就會從8000減少到7000，這個向桶2(Be)借的1000個字節的令牌數量叫做“實際欠償”（actual debt Da)，如果此時還有數據繼續被髮送，當然假設此時的Bc還是等於0，這個時候就牽涉到一個“欠償變量”（compounded debt Dc）也叫累計欠償的關鍵組件，而這個累計欠償Dc將關係到如何決定當前數據是是conform或者exceed，在說明決定原則前必須前理解累計欠償的計算公式，具體如下表所示：
注意：欠償變量Dc的計算只會在桶1（Bc）被耗盡之後纔會開始，此時纔會向桶2借令牌。
累計Dc的增長會比Da更快，可以通過下表的一個到達的數據包、Da和累計Dc的關聯來看出它的計算方式。現在假設是爲CAR的Be配置爲8000字節。當累計的Dc超出Be時，CAR將這個包確定爲超過認購流量的數據包，也就是exceed，然後將當前的Dc值減至0.這時候CAR將做出如下原則：
如果Dc的累計增長超過了Be，當前的數據包就超出了認購流量，CAR將無法再從Be借到令牌，事實上這個時候Bc是肯定在耗盡Be之前就沒有了可用的令牌，CAR將這個包確定爲超過認購流量的數據包，也就是exceed，然後可以針對這個的數據包執行相應的exceed-action監控行爲，可以是丟棄，也可以是降級標記後轉發。
但是，如果借償算法中的累計Dc小於Be，也就是Be還有可用的令牌借出，那麼這個數據包被視爲conforms，就能匹配到認購流量，然後桶2（Be）將移除與數據包字節數相同的令牌，然後執行一個conforms的行爲，一般而言就是轉發。
注意：在流量監管的雙桶算法中，引入這個複雜的欠償算法其實只有一個簡單的目標就是在能監管的範圍內緩解包的丟棄，這與流量監管的初衷並不矛盾。請永遠不要認爲丟棄數據包只是一個很小的事情，甚至會認爲有TCP來確定可靠性，有重傳機制的存在，可以調整滑動窗口來解決，關於這些問題將會在擁塞避免時做解釋。
部署CAR行爲
現在假設需對進入路由器E2/0接口的用戶流量執行監管，將其監管到64K，然後通過公式Bc=監管速率*Tc來確認Bc的大小，及配置最大突發（Bc+Be）的示例如下：
配置CAR：
指令解析：
rate-limit：指示在某個接口下啓動CAR限速機制也就監管功能
input[output]:指示確定CAR的限速方向，入和出方向都可以，但是建議在入向上做限速。
監管速率:指示CAR對用戶流量的監管速率，一般建議監管到與認購流量或者叫CIR相同的速率，該實例中是64K，監管速率的單位是每秒多少比特（bits）。
可持續的突發Bc：配置可持續的突發量也就是桶1的容量，注意單位是字節(byte)，可以通過公式Bc=監管速率*Tc來確定，在該實例中就是64000*0.125(默認的Tc爲125ms)等於8000位,在配置時需要將這個8000bit換算成字節，一個字節等於8個位，所以8000除以8等1000byts（字節）這就是Bc的大小。或者使用12.7.6如果存在多種方案來確定Bc和Be大小，應該選擇哪一種最合適部分中的方案二或者方案三來確定。
Maximum burst（最大突發=Bc+Be）：注意該選項並不僅僅指示桶2（Be）的大小，不能僅將該選項當作Be的配置處理，事實上最大突發是指Be+Bc，如該實例所示的配置最大突發爲2000字節，此時真實的Be只有1000字節，因爲其中有1000字節是屬於Bc。
Conform-action(匹配行爲)：在現在這個Conform-action就必須先理解前面所描述的令牌桶算法，如果是單桶（只有Bc）,那麼只要小於或者等於Bc大小的數據都將會是Conform；如果是雙桶，這將根據雙桶的借償算法來決定，如果借償算法中的累計Dc大於Bc但是小於Be，那麼當前的數據包還是屬於Conform，此時對Conform的數據包，執行一個action（行爲），可以是轉發、重標記、丟棄等，一般對匹配的數據包都執行transmit（轉發或叫傳輸）。
exceed-action（超額行爲）：該行爲仍然是根據令牌桶算法來做出決定：如果是單桶（只有Bc）那麼只要大於Bc的數據都會被視爲exceed，如果是雙桶（有Bc同時也有Be）這將根據雙桶的借償算法來決定，如果借償算法中的累計Dc大於Be，那麼當前的數據包就被視爲exceed，此時需要對exceed的數據包執行一個action（行爲），可以是轉發、重標記、丟棄棄等，在該實例配置中執行的是drop（丟棄）。但是請注意，並不是絕對的說：對exceed的數據包執行的動作就一定是丟棄，也可能是降級標記後再轉發，因爲過多的丟包對網絡並沒有任何好處。關於這一點在12.7.8在一些情況下爲什麼CAR將不能匹配認購流量（CIR）的數據包還要做轉發，會作更詳細的說明。
在配置Maximum burst（最大突發）的注意事項：
在配置CAR的Maximum burst（最大突發）需要注意，如果如圖所示，將正常的突發Bc和最大突發配置成相同的值，比如：Bc=2000字節，最大突發（Bc+Be）=2000字節，那麼此時，相當於沒有配置Be值，更直白的講此時的CAR將使用單桶算法。這和配置GTS（通用流量×××時是有差異的，在配置GTS時如果需要申明不使用Be，那麼會明確的將Be值配置爲０，關於這一點請參看流量×××部分的描述，而CAR則是將最大突發配置爲等於正常突發。
關於CAR使用Bc=監管速率*Tc來確認Bc時的小故障
在很多情況下，當用戶在某個網絡設備的接口上配置：rate-limit input64000 1000 2000 conform-action transmit exceed-action drop後，系統報告如下信息,根據Bc=監管速率*Tc的公式，目前監管速率是64K，而Tc默認是125ms，所以Bc應該就是64000*0.125=8000(bits)然後再換算成字節就是8000/8=1000字節，Bc就應該是1000字節，而如圖所示，該實例中通過公式計算出來的Bc=1000字節，也是Bc有效範圍內的值，那麼在配置時系統爲什麼會報告錯誤？
執行上述指令後系統會報錯：
Illegalnormal burst size * 違返規則的持續突發值（Bc）
Increasingnormal burst size to 1500 * 請增加Bc值到1500
上述通過公式計算出來Bc=1000字節是沒有錯誤的，只是通常在做CAR時會忽略一件事情，爲了考慮更好傳輸性能，CAR的Bc值（也就是令牌桶1）的大小，是不應該低於物理接口的MTU值的大小的，比如：該實例中通過公式計算出來的Be爲1000字節，而如圖所示，這是一個以太網接口(E2/0)，MTU=1500，所以系統才提示“Increasing normal burst size to 1500”請增加Bc值到1500。
當然，在該實例中如果用戶不想調整CAR的Bc值到1500，那麼可以通過更改網絡設備的MTU在大小去吻合Bc值的大小，比如使用如下指令把MTU改爲1000。但是筆者強烈建議不要修改設備默認的MTU值，因爲這可能會引發其它更多問題，而且這種通過更改MTU的方式來適應Bc值只能在非以太網接口，比如串口上執行，在以太網接口上是不支持更改MTU值的。
改變MTU去適應CAR的最小Bc值
R1(config)#intes1/0
R1(config-if)#mtu1000 * 將接口MTU調整爲1000字節
如果存在多種方案來確定Bc和Be大小，應該選擇哪一種最合適
首先說明一下，因爲CAR必須要逐項申明監管速率、Bc、最大突發值（實際上是Bc+Be）分別是多少，用戶不能像基於流量×××和類別的監管那樣僅配置監管速率，後面的Bc和Be都交給系統自己去計算出一個默認值，這是不可以的，所以Bc和Be值的確定和配置將不被“迴避”，那麼將如何來確定Bc和Be，在衆多文檔中一般會出現3種確定Bc和Be的方案：
第一種方案：Bc=監管速率*Tc
假設監管速率爲64Kbit/s，而通過思科推薦的Tc都是125ms，64000*0.125=8000bits，然後再將8000bits換算成字節即1000byts，所以Bc爲1000byts，如果再將Be也配置成1000字節，那麼執行的指令如圖所示：
爲什麼Be是1000字節，在配置時輸入的卻是2000字節？原因很簡單，因爲CAR的Maximum burst bytes（最大突發字節），並不僅是Be的值，而是Bc+Be的值，所以應該將最大突量配置爲2000（1000字節的Bc+1000字節的Be）。
注意這裏需要說明的是：這是一個實驗室計劃的公式，或者是爲了幫助大家理解流量控制（包括×××和監管）去發現速率、持續突發、時間間隔三者之間的關係，事實上Tc值是不可以被管理員手工配置的，它只能被速率和持續突發（Bc）去決定，而大家常用的Tc=125ms，它也只不過是一個推薦的最合適的假定值，因爲本身這個假定值的範圍就是在10-125ms之間，只是取用了最高上線的假定值，所以基於這個默認Tc=125ms，使用Bc=監管速率*Tc的公式去計算得到Bc值也是一個“Ideal value”也就是理想值。這意味着如果在實戰的工程項目中使用這個默認的125ms算出來的Bc值，如果過低，會造成用戶實際的數據到達速率，低於甚至於有時候是遠低於監管所配置的速率。所以一般使用第一種方案確定的Bc都是用在理解和分析相關知識點和技術問題上，並不是一個最佳的實踐行爲，但是這種計算公式是正確的，是正確的，不代表它是最推薦的實踐方案，一般在理解了流量×××和監管後，自己在實驗室要需要搭建並做出流量監管和×××的效果時，通常會使用上述公式去計算Bc值，而且通常算出的這個值都比較小，所以容易看到過載和丟棄的現象，再同時使用該公式的Tc(默認125ms)去計算流量×××，就可以看到×××的實際效果，具體的在本章的演示： GTS流量×××和CAR流量監管的效果部分會有詳細描述。
第二種方案：將1秒鐘可傳輸的監管值轉換爲字節作爲Bc，然後附加0.5秒的值作爲Be，假設現在的監管速率是每秒64Kbit／s,現在根據上述原則來確主Bc和Be，那麼就將64000*1字節然後再除以8等於8000字節來作爲Bc，然後以0.5秒的4000字節來作爲Be，但是請注意在配置時用戶應該使用如圖輸寫方式：在Bc後面的那個12000個字節，叫Maximumburst，它是由Bc+Be得到，所以真實的Be值只有4000個字節。
第三種方案：只要知道被監管的目標速率是多少，就將依據如下所示的公式來得到Bc及最大突發值是多少，通過和第二種方案的對比，不難看出其實方案三和方案二的實質是一樣的，只是方案上中方案三中多配置了0.5秒的Bc字節量，在方案二是以每秒而得到的Bc量，方案三中是以1.5秒所得到的Bc量，然後整個最大突發建議的是2倍Bc。這裏的這個1.5秒可以被理解成是一個數據的平均往返時間。所謂平均往返時間就是來準確體現路由的途徑時間，最理想的就是以1秒爲單位來考慮，但是考慮到各種阻尼效應，所以多加了0.5秒，如果往返時間少於1.5秒，就必須更改該值來確保更準確的往返時間，那用戶怎麼才能知道最合理的往返時間，一種很科學的方案就是通過SLA來測量，當然這以超出本章的描述範圍。
normal burst（BC）= configuredrate * (1 byte)/(8 bits) * 1.5 seconds
最大突發（Bc+Be）= 2 * normal burst
注意：在確定Bc和最大突發值時上述的方案2和3是具備良好實戰意義的，正如思科官方文檔所提示的這兩個方案是“extensivetest results”（廣泛測量的結果）。至於方案2和3在往返時間上的差異（哪0.5秒），可以針對具體工程項目中鏈路的情況來做調整。