QoS na tunel nie ogranicza całkowitego uplinku Twojego huba

To przekonanie brzmi jak arytmetyka: pięć spoke'ów, każdy ukształtowany do 5 Mbit/s, więc hub przenosi najwyżej 25 Mbit/s. Pierwsza połowa jest prawdziwa, a wniosek nie. Polityka na tunel jest stosowana raz na tunel, nie raz na hub, a wspólny uplink, przez który przechodzi wszystkie pięć tuneli, nigdy nie pojawia się w tym obliczeniu. Przeciążenie uplinku pozostaje dokładnie takie, jakie było.

Skąd bierze się to przekonanie

Zamieszanie jest zrozumiałe, bo informacje o grupie NHRP pozwalają jednej definicji polityki obowiązywać dla całego zestawu spoke'ów. To czyta się jak wspólny budżet w pliku konfiguracyjnym. W rzeczywistości oznacza to, że każdy spoke otrzymuje własną instancję tej definicji.

Zatem 5 Mbit/s na spoke to pułap dla tunelu, a pułapów jest tyle, ile tuneli.

Czym steruje jedna instancja polityki

Przewodnik Cisco po QoS na tunel w DMVPN w IOS XE opisuje politykę wyjścia z huba wybieraną przez informacje o grupie NHRP i stosowaną osobno do każdego spoke'a. Z tego zdania wynikają dwa ograniczenia i oba są ignorowane. Szybkość należy do jednego spoke'a, a nie do wspólnego wiadra, a funkcja steruje ruchem z huba do spoke'a, nie odwrotnie.

Planuj kierunek wysyłania spoke'a niezależnie. Nic w polityce wyjścia z huba nie ogranicza tego, co oddział wysyła.

Umieść limit zbiorczy we wspólnym wąskim gardle

Całość musi być kształtowana tam, gdzie naprawdę konkuruje: na interfejsie fizycznym, który dzielą wszystkie tunele. Cisco dokumentuje shaper class-default na interfejsie fizycznym jako obsługiwaną równoczesną politykę fizyczną dla tej funkcji, co jest węższym stwierdzeniem niż każda hierarchia, którą możesz wpisać. Zakładaj, że wymyślona przez Ciebie dowolna druga polityka fizyczna nie jest obsługiwana, dopóki ktoś nie udowodni inaczej.

Potem zdecyduj, co się dzieje, gdy wszystkie spoke'i są zajęte jednocześnie. Który ruch jest dopuszczany, która klasa ma priorytet i która kolejka posiada rywalizację. Pułap na spoke nie odpowiada na żadne z tych pytań, bo każdy spoke jest rozpatrywany osobno.

Dopasuj jednostki kształtowania i rozliczanie narzutu do rzeczywistego przekazania. Narzut enkapsulacji, który pominiesz w obliczeniu szybkości, objawia się jako łącze, które nasyca się przed skonfigurowaną liczbą.

Liczniki kłamią w jeden konkretny sposób

Czytaj liczniki na warstwie, którą kształtujesz. Ten sam przewodnik Cisco ostrzega, że liczniki polityki interfejsu głównego mogą być w tym układzie niedokładne. To zastrzeżenie dotyczące licznika, nie dowód, że klasa pasuje lub odrzuca. Trzymaj to osobno od wyniku aplikacji, który jest jedyną rzeczą, jakiej doświadcza użytkownik.

Skopiowanie starego przykładu traffic-shape obok niepowiązanej mapy polityki nie dowodzi, że obie szybkości sterują tymi samymi pakietami.

Testuj całość, nie tylko pułap

Zacznij od jednego zajętego spoke'a i potwierdź, że osiąga swój pułap. Potem zaproponuj ruch od wszystkich naraz według zatwierdzonego planu i obserwuj interfejs fizyczny obok liczb na tunel. Jeśli każdy spoke siedzi na swoim pułapie, a uplink jest zapchany i opóźnienie rośnie, polityka na spoke działa dokładnie tak, jak zaprojektowano, a budżet wciąż jest błędny.

Poprawka w tym miejscu jest decyzją o przepustowości lub dopuszczeniu. Dostrajanie liczb na spoke zmienia tylko to, który oddział skarży się pierwszy.