Jak rozumiem, Cisco IOS CAR (Committed Access Rate) opiera się na algorytmie nieszczelnego wiadra (pomysł jest dokładnie taki sam jak algorytm wiadra tokena ), a ilość bitów, którą konfiguruję jako średnią szybkość, to ilość „wody stale wyciekającej z wiadra „. Na przykład tutaj średnia szybkość limitu wejściowego wynosi 5 Mb / s:
interface FastEthernet0/0
ip address 10.10.10.2 255.255.255.0
rate-limit input 5000000 937500 1875000 conform-action transmit exceed-action drop
Teraz, jeśli natężenie ruchu jest niższe niż średnia, to zawsze jest zgodne. Czy mam rację, że „normalny wybuch” określa, jak duże mogą być wybuchy ruchu, zanim zastosowane zostanie przekroczenie? Tak więc w przypadku powyższego przykładu, jeśli ruch był stały o prędkości 5 Mb / s (625000 bajtów w segmencie), to mógłbym wysłać na sekundę 7,5 Mb / s (dodaje dodatkowe 312500 bajtów do segmentu) ruchu i ani jeden bit nie jest upuszczany ? A jeśli bajty w segmencie znajdują się między normalną serią a maksymalną serią, to bajty są usuwane na podstawie algorytmu RED-podobnego, dopóki wszystkie nowe pakiety nie zostaną usunięte, jeśli maksymalna seria również jest pełna?
Odpowiedzi:
Obliczmy, z czym mamy tutaj do czynienia. CAR jest w zasadzie starszą wersją policji IOS, więc wszystkie te koncepcje dotyczą obu.
Szybkość, do której chcemy ograniczyć przepływy, wynosi 5 Mb / s. Wiadro zatwierdzania ma 937,500 bajtów. Wiadro rozerwania ma 1 875 000 bajtów. I wiadra są napełniane co 187,5 ms.
Jak wspomniałeś, IOS używa mechanizmu kubełkowego, aby ograniczyć natężenie ruchu. Nie wygładza on ruchu do X% przepustowości interfejsu w dowolnym czasie! Zamiast tego umożliwia pełny dostęp do przepustowości interfejsu, o ile masz za to tokeny.
Ponadto, ponieważ jest to kontrola, RED / WRED nie są w grze. RED występuje tylko wtedy, gdy istnieje kolejka do zarządzania. Nie ma buforowania / kolejkowania w policji, a tylko w kształtowaniu.
Najpierw porozmawiajmy o Commit Bucket (Bc). Załóżmy, że na razie nie ma nadmiaru łyżki (Be).
* Commit Bucket Only (Polerka dwukolorowa) *
Jest to bardzo surowy policjant, który pozwoli ci tylko wysłać dokładnie w ramach CIR; bez pękania powyżej. Jest tylko jedno wiadro, Bc. Istnieją dwa „kolory” dla ruchu, zgodne i przekraczające .
Czas = 0 ms - Wiadro zaczyna się od pełna z tokenami o wartości 937,500 bajtów. Załóżmy, że wysyłasz 7500 bajtów przez interfejs. Teraz IOS zmniejsza koszyk o 7500 bajtów, a koszyk zawiera teraz tokeny o wartości 930 000 bajtów. Wysłany ruch jest uważany za „zgodny” i ma do niego zastosowane „działanie zgodne”.
Czas = 187,5 ms - Uderzamy teraz w Tc i napełniamy wiadro Bc. Dodano tokeny o wartości 937,500 bajtów. Wszelkie dodatkowe tokeny rozlewają się i są tracone.
Czas = 190 ms - W koszyku zatwierdzeń znajduje się 937,500 tokenów. Otrzymujemy 2 000 000 bajtów ruchu. Pierwsze 937,500 bajtów jest przesyłanych w porządku, ponieważ wiadro ma dla nich tokeny. Pozostały ruch jest uważany za „przekraczający” i jest traktowany zgodnie z „przekroczeniem”. Pamiętaj, nie ma buforowania w policji (to się nazywa kształtowanie) - albo transmitujesz, zaznaczasz i transmitujesz, albo upuszczasz.
Czas = 375 ms - Znów trafiliśmy Tc, a wiadro Bc zostało napełnione 937,500 tokenów.
* Commit Bucket z nadmiarem Bucket (trójkolorowa polerka) *
Możesz opcjonalnie dodać nadmiar łyżki (Be). Dzięki temu ruch może tymczasowo przekroczyć segment Bc. Ogólny CIR powinien pozostać taki sam. To trzykolorowy policjant: dostosowujący się, przekraczający i naruszający .
Czas = 0 ms - oba segmenty (Bc i Be) zaczynają się pełne. Bc ma 937,500 tokenów, Be ma 1 875 000 tokenów.
Czas = 50 ms - przybywa 2 000 000 bajtów. Router najpierw zmniejsza tokeny segmentu Bc. Zmniejsza wiadro Bc do zera. 937,500 bajtów ruchu objętego Bc jest uważane za „zgodne” i ma do niego zastosowanie „działanie zgodne”.
To pozostawia 1 062,500 bajtów ruchu, który nie ma jeszcze tokenów. Teraz router zanurza się w wiadrze Be i odejmuje 1,062,500 tokenów, aby pokryć resztę ruchu. Bajty te są uważane za „przekraczające” i będą miały do niego zastosowanie „przekroczenie”. W twoim przykładzie ruch zostałby zmniejszony, ale możesz potencjalnie zauważyć lub po prostu go przesłać.
Jeśli trzymasz wynik w domu, Bc ma teraz zero tokenów, Be ma 812,500 tokenów.
Czas = 75 ms - Teraz router otrzymuje kolejne 120000 bajtów ruchu. Wiadro Bc jest puste, więc nie ma tam żadnej pomocy. Wiadro Be może pomóc, więc obejmuje pierwsze 812 500 bajtów ruchu swoimi tokenami i jest teraz puste. Ten ruch jest uważany za „przekraczający” i będzie miał do niego zastosowanie „przekroczenie”.
Teraz wiadra są suche, ale wciąż pozostaje do zrobienia 387,500 bajtów. Ten ruch jest uważany za „naruszający” i zawsze jest usuwany za pomocą CAR (możesz robić z nim inne rzeczy za pomocą MQC i komendy policji za pomocą „naruszenia”).
Czas = 187,5 ms - Teraz dochodzimy do pierwszego przedziału czasu Tc, czas na wypełnienie naszych wiader. Kluczową kwestią jest to, że tylkotokeny o wartości Bc są uzupełniane! Wiadro Bc jest napełnione najpierw do 937,500. Wiadro Be POZOSTAJE PUSTE.
Czas = 375 ms - Było cicho i doszliśmy do następnego przedziału Tc. Żetony o wartości Bc są dodawane do wiadra Bc. Ponieważ wiadro Bc jest już pełne, żetony nadmiaru nie są tracone - zamiast tego są „rozlewane” do wiadra Be. Teraz wiadro Bc jest pełne z 937,500 tokenów, a wiadro Be jest częściowo pełne z 937,500 tokenów.
Czas = 562,5 ms - Cicho, i jesteśmy przy następnej Tc. Żetony o wartości Bc są dodawane do wiadra Bc, które jest już pełne. Wszystko to przelewa się do wiadra Be (który ma już 937,500 tokenów). Be wypełnia do 1 875 000 żetonów.
* Uwagi końcowe *
Twoja konfiguracja nie korzysta z wiadra Be. Ograniczasz / policja używasz tylko segmentu Bc, co może mieć niezamierzone skutki uboczne, jeśli policjant / shaper wysyłający dane do ciebie nie jest skonfigurowany identycznie i nie jest zsynchronizowany Tc.
Limit CAR / stawki jest bardzo stary i przestarzały. Zastanów się nad przejściem na MQC i nowoczesną QoS, aby to zaimplementować, ponieważ zapewni to więcej informacji i opcji.
Całkowicie ignoruję opóźnienie serializacji (czas potrzebny na przesłanie danych przez linię) powyżej i jestem całkiem pewien, że matematyka nie zadziała w prawdziwym scenariuszu. Ale koncepcje są solidne, niezależnie od dokładnych liczb w użyciu.
* Przykład MQC *
* Źródła *
http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-policing/19645-policevsshape.html
Materiały szkoleniowe INE CCIE
CCIE # 38955
źródło