QoS pe tunel nu limitează uplink-ul total al hubului tău

Această credință sună ca aritmetică: cinci spoke-uri, fiecare modelat la 5 Mbit/s, deci hubul transportă cel mult 25 Mbit/s. Prima jumătate este adevărată, iar concluzia nu. O politică pe tunel se aplică o dată pe tunel, nu o dată pe hub, iar uplink-ul comun prin care trec toate cele cinci tuneluri nu apare niciodată în acel calcul. Congestia de pe uplink rămâne exact cum era.

De unde vine credința

Confuzia este de înțeles, pentru că informațiile de grup NHRP permit unei singure definiții de politică să se aplice unui set întreg de spoke-uri. Asta se citește ca un buget comun într-un fișier de configurare. Ce înseamnă de fapt este că fiecare spoke primește propria instanță a acelei definiții.

Deci 5 Mbit/s pe spoke este un plafon pe tunel, și există atâtea plafoane câte tuneluri sunt.

Ce controlează o instanță de politică

Ghidul Cisco pentru QoS pe tunel în DMVPN pe IOS XE descrie o politică de ieșire din hub selectată prin informații de grup NHRP și aplicată separat fiecărui spoke. Din acea propoziție rezultă două limite, și ambele sunt ignorate. Rata aparține unui singur spoke, nu unei găleți comune, iar funcția guvernează traficul de la hub către spoke, nu invers.

Planifică direcția de trimitere a spoke-ului independent. Nimic dintr-o politică de ieșire din hub nu limitează ce încarcă o sucursală.

Pune limita agregată la gâtul de sticlă comun

Agregatul trebuie modelat acolo unde concurează cu adevărat: pe interfața fizică pe care o împart toate tunelurile. Cisco documentează un shaper class-default pe interfața fizică drept politica fizică simultană acceptată pentru această funcție, ceea ce este o afirmație mai îngustă decât orice ierarhie pe care o poți tasta. Presupune că a doua politică fizică arbitrară pe care ai inventat-o nu este acceptată până când cineva dovedește contrariul.

Apoi decide ce se întâmplă când toate spoke-urile sunt ocupate simultan. Ce trafic este admis, ce clasă are prioritate și ce coadă deține contenția. Un plafon pe spoke nu răspunde la niciuna dintre aceste întrebări, pentru că fiecare spoke este considerat separat.

Aliniază unitățile de modelare și contabilizarea overhead-ului la predarea reală. Overhead-ul de încapsulare pe care îl lași în afara calculului ratei apare ca o legătură care se saturează înainte de numărul configurat.

Contoarele mint într-un mod anume

Citește contoarele la stratul pe care îl modelezi. Același ghid Cisco avertizează că contoarele de politică ale interfeței principale pot fi inexacte în această configurație. Aceasta este o rezervă privind contorul, nu o dovadă că o clasă se potrivește sau aruncă. Ține-o separată de rezultatul aplicației, care este singurul lucru pe care îl experimentează utilizatorul.

Copierea unui exemplu vechi de traffic-shape lângă o hartă de politici fără legătură nu dovedește că cele două rate controlează aceleași pachete.

Testează agregatul, nu doar plafonul

Începe cu un singur spoke ocupat și confirmă că își atinge plafonul. Apoi oferă trafic de la toate simultan conform unui plan aprobat și urmărește interfața fizică lângă cifrele pe tunel. Dacă fiecare spoke stă la plafonul său în timp ce uplink-ul este blocat și întârzierea crește, politica pe spoke funcționează exact cum a fost proiectată, iar bugetul este în continuare greșit.

Remedierea în acel punct este o decizie de capacitate sau de admitere. Reacordarea cifrelor pe spoke schimbă doar care sucursală se plânge prima.