Tunnelipõhine QoS ei piira sinu hubi kogu üleslinki

Usk kõlab nagu aritmeetika: viis spoke'i, igaüks vormitud 5 Mbit/s peale, seega kannab hubi ülimalt 25 Mbit/s. Esimene pool on tõsi ja järeldus mitte. Tunnelipõhist poliitikat rakendatakse üks kord tunneli kohta, mitte üks kord hubi kohta, ja jagatud üleslink, mida kõik viis tunnelit läbivad, ei esine selles arvutuses kunagi. Üleslingi ummik püsib täpselt sellisena, nagu see oli.

Kust usk tuleb

Segadus on mõistetav, sest NHRP grupi teave lubab ühel poliitikadefinitsioonil kehtida terve spoke'ide komplekti jaoks. See loeb nagu jagatud eelarve konfiguratsioonifailis. Tegelikult tähendab see, et iga spoke saab selle definitsiooni oma eksemplari.

Seega on 5 Mbit/s spoke'i kohta tunnelipõhine ülempiir ja ülempiire on nii palju, kui on tunneleid.

Mida üks poliitika eksemplar juhib

Cisco juhend QoS-i kohta tunnelipõhiselt DMVPN-is IOS XE-s kirjeldab hubi väljundpoliitikat, mis valitakse NHRP grupi teabe kaudu ja mida rakendatakse eraldi igale spoke'ile. Sellest lausest tuleneb kaks piirangut ja mõlemat eiratakse. Kiirus kuulub ühele spoke'ile, mitte jagatud ämbrile, ja funktsioon juhib liiklust hubist spoke'i, mitte vastupidi.

Planeeri spoke'i saatmissuund iseseisvalt. Miski hubi väljundpoliitikas ei piira seda, mida haru üles laadib.

Aseta koondpiirang jagatud kitsaskohta

Koond tuleb vormida seal, kus koond tegelikult konkureerib: füüsilisel liidesel, mida kõik tunnelid jagavad. Cisco dokumenteerib class-default kujundaja füüsilisel liidesel selle funktsiooni toetatud samaaegse füüsilise poliitikana, mis on kitsam väide kui ükskõik milline hierarhia, mida saad kirjutada. Eelda, et suvaline teine füüsiline poliitika, mille välja mõtlesid, ei ole toetatud, kuni keegi tõestab vastupidist.

Seejärel otsusta, mis juhtub, kui kõik spoke'id on korraga hõivatud. Milline liiklus lubatakse, millist klassi eelistatakse ja milline järjekord omab konkurentsi. Spoke'ipõhine ülempiir ei vasta ühelegi neist küsimustest, sest iga spoke'i vaadeldakse eraldi.

Sovita kujundusühikud ja üldkulude arvestus tegeliku üleandmisega. Inkapsuleerimise üldkulu, mille jätad kiirusearvutusest välja, ilmub lingina, mis küllastub enne seadistatud arvu.

Loendurid valetavad ühel konkreetsel viisil

Loe loendureid kihil, mida kujundad. Sama Cisco juhend hoiatab, et põhiliidese poliitika loendurid võivad selles paigutuses olla ebatäpsed. See on loenduri kohta käiv hoiatus, mitte tõestus, et klass sobib või loobub. Hoia see rakenduse tulemusest lahus, sest see on ainus, mida kasutaja kogeb.

Vana traffic-shape näite kopeerimine mitteseotud poliitikakaardi kõrvale ei tõesta, et kaks kiirust juhivad samu pakette.

Testi koondit, mitte ainult ülempiiri

Alusta ühe hõivatud spoke'iga ja kinnita, et see jõuab oma ülempiirini. Seejärel paku liiklust kõigist korraga heakskiidetud plaani alusel ja jälgi füüsilist liidest tunnelipõhiste numbrite kõrval. Kui iga spoke istub oma ülempiiril, samal ajal kui üleslink on kinni ja viivitus kasvab, töötab spoke'ipõhine poliitika täpselt nii, nagu projekteeritud, ja eelarve on ikka vale.

Parandus on selles punktis võimsuse või lubamise otsus. Spoke'ipõhiste numbrite ümberhäälestamine muudab ainult seda, milline haru esimesena kurdab.