Tunnelikohtainen QoS ei rajoita keskittimesi kokonaisuplinkia

Uskomus kuulostaa aritmetiikalta: viisi spokea, kukin muotoiltu 5 Mbit/s:iin, joten keskitin kuljettaa enintään 25 Mbit/s. Ensimmäinen puoli on totta, johtopäätös ei. Tunnelikohtaista käytäntöä sovelletaan kerran tunnelia kohden, ei kerran keskittimen kohden, eikä jaettu uplink, jonka kaikki viisi tunnelia ylittävät, koskaan esiinny siinä laskelmassa. Uplinkin ruuhka säilyy täsmälleen sellaisena kuin se oli.

Mistä uskomus tulee

Sekaannus on ymmärrettävä, koska NHRP-ryhmätieto sallii yhden käytäntömääritelmän soveltua koko spokejoukolle. Se luetaan kuin jaettu budjetti asetustiedostossa. Mitä se todella tarkoittaa, on että jokainen spoke saa oman instanssinsa siitä määritelmästä.

Joten 5 Mbit/s spokea kohden on tunnelikohtainen yläraja, ja ylärajoja on yhtä monta kuin tunneleita.

Mitä yksi käytäntöinstanssi ohjaa

Ciscon opas tunnelikohtaiseen QoS:ään DMVPN:ssä IOS XE:llä kuvaa keskitimen lähtökäytännön, joka valitaan NHRP-ryhmätiedon kautta ja sovelletaan erikseen jokaiseen spokeen. Tuosta lauseesta seuraa kaksi rajaa, ja molemmat jätetään huomiotta. Nopeus kuuluu yhdelle spokelle eikä jaetulle ämpärille, ja ominaisuus ohjaa liikennettä keskitimestä spokeen, ei päinvastoin.

Suunnittele spoken lähetyssuunta itsenäisesti. Mikään keskitimen lähtökäytännössä ei rajaa sitä, mitä haara lataa ylös.

Aseta kokonaisraja jaettuun pullonkaulaan

Kokonaisuus on muotoiltava siellä, missä se todella kilpailee: fyysisellä liitännällä, jonka kaikki tunnelit jakavat. Cisco dokumentoi class-default-muotoilijan fyysisellä liitännällä tämän ominaisuuden tuetuksi samanaikaiseksi fyysiseksi käytännöksi, mikä on kapeampi väite kuin mikään kirjoitettavissa oleva hierarkia. Oleta, että keksimäsi mielivaltainen toinen fyysinen käytäntö ei ole tuettu, kunnes joku todistaa toisin.

Päätä sitten, mitä tapahtuu, kun kaikki spoket ovat yhtä aikaa varattuja. Mikä liikenne päästetään sisään, mikä luokka saa prioriteetin ja mikä jono omistaa kilpailun. Spoke-kohtainen yläraja ei vastaa yhteenkään noista kysymyksistä, koska jokaista spokea tarkastellaan erikseen.

Sovita muotoiluyksiköt ja ylikuormituksen kirjanpito todelliseen luovutukseen. Kapselointiylikuormitus, jonka jätät nopeuslaskelman ulkopuolelle, näkyy linkkinä, joka kyllästyy ennen asetettua lukua.

Laskurit valehtelevat yhdellä tietyllä tavalla

Lue laskureita sillä tasolla, jota muotoilet. Sama Ciscon opas varoittaa, että pääliitännän käytäntölaskurit voivat olla epätarkkoja tässä järjestelyssä. Se on varauma laskurista, ei todiste siitä, että luokka täsmää tai pudottaa. Pidä se erillään sovellustuloksesta, joka on ainoa asia, jonka käyttäjä kokee.

Vanhan traffic-shape-esimerkin kopioiminen irrallisen käytäntökartan viereen ei osoita, että kaksi nopeutta ohjaa samoja paketteja.

Testaa kokonaisuus, älä vain ylärajaa

Aloita yhdellä varatulla spokella ja varmista, että se saavuttaa ylärajansa. Tarjoa sitten liikennettä kaikilta yhtä aikaa hyväksytyn suunnitelman mukaisesti ja seuraa fyysistä liitäntää tunnelikohtaisten lukujen rinnalla. Jos jokainen spoke istuu ylärajallaan samalla kun uplink on kiinni ja viive kasvaa, spoke-kohtainen käytäntö toimii täsmälleen suunnitellusti ja budjetti on edelleen väärä.

Korjaus on siinä kohdassa kapasiteetti- tai hyväksyntäpäätös. Spoke-kohtaisten lukujen uudelleensäätö muuttaa vain sitä, mikä haara valittaa ensimmäisenä.