Hindi nililimitahan ng QoS bawat tunnel ang kabuuang uplink ng iyong hub
Limang spoke na 5 Mbit bawat isa ay hindi 10 Mbit na uplink, at hindi nakita ng patakaran bawat tunnel ang pagkakaibang iyon. Ibudget nang hiwalay ang pinagsasaluhang bottleneck.
Tunog aritmetika ang paniniwalang ito: limang spoke, bawat isa ay hinubog sa 5 Mbit/s, kaya nagdadala ang hub ng 25 Mbit/s sa pinakamarami. Tama ang unang kalahati at hindi ang konklusyon. Ang patakaran bawat tunnel ay inilalapat isang beses bawat tunnel, hindi isang beses bawat hub, at ang pinagsasaluhang uplink na dinaraanan ng lahat ng limang tunnel ay hindi kailanman lumilitaw sa kalkulasyong iyon. Nananatili ang pagsisikip sa uplink nang eksakto tulad ng dati.
Saan nagmumula ang paniniwala
Naiintindihan ang kalituhan, dahil ang impormasyon ng NHRP group ay nagpapahintulot sa isang depinisyon ng patakaran na mailapat sa isang buong set ng spoke. Parang pinagsasaluhang badyet iyon sa isang configuration file. Ang tunay na ibig sabihin nito ay nakakakuha ang bawat spoke ng sarili nitong instance ng depinisyong iyon.
Kaya ang 5 Mbit/s bawat spoke ay isang kisame bawat tunnel, at kasing dami ng tunnel ang mga kisame.
Ano ang kinokontrol ng isang instance ng patakaran
Inilalarawan ng gabay ng Cisco sa QoS bawat tunnel sa DMVPN sa IOS XE ang isang patakaran sa paglabas ng hub na pinipili sa pamamagitan ng impormasyon ng NHRP group at inilalapat nang hiwalay sa bawat spoke. May dalawang limitasyon na sumusunod sa pangungusap na iyon, at pareho silang binabalewala. Ang rate ay pag-aari ng isang spoke at hindi ng pinagsasaluhang balde, at pinamamahalaan ng feature na ito ang trapiko mula sa hub patungo sa spoke, hindi ang kabaliktaran.
Planuhin nang nakapag-iisa ang direksyon ng pagpapadala ng spoke. Wala sa isang patakaran sa paglabas ng hub ang naglilimita sa ina-upload ng isang sangay.
Ilagay ang pinagsama-samang limitasyon sa pinagsasaluhang bottleneck
Ang kabuuan ay dapat hubugin sa lugar kung saan talaga ito nakikipagkumpitensya: sa pisikal na interface na pinagsasaluhan ng lahat ng tunnel. Itinatala ng Cisco ang isang class-default shaper sa pisikal na interface bilang sinusuportahang kasabay na pisikal na patakaran para sa feature na ito, na isang mas makitid na pahayag kaysa sa anumang hierarchy na maaari mong i-type. Ipagpalagay na ang di-makatwirang pangalawang pisikal na patakaran na inimbento mo ay hindi sinusuportahan hanggang may makapagpatunay ng kabaliktaran.
Pagkatapos ay magpasiya kung ano ang mangyayari kapag abala ang lahat ng spoke nang sabay-sabay. Aling trapiko ang tinatanggap, aling klase ang binibigyan ng priyoridad, at aling pila ang may hawak ng pagtatalo. Hindi sinasagot ng kisame bawat spoke ang alinman sa mga tanong na iyon, dahil isinasaalang-alang ang bawat spoke nang mag-isa.
Itugma ang mga yunit ng paghubog at accounting ng overhead sa aktwal na paghahatid. Ang overhead ng encapsulation na iniiwan mo sa labas ng kalkulasyon ng rate ay lumilitaw bilang isang link na nagsasaturate bago ang naka-configure na numero.
Nagsisinungaling ang mga counter sa isang partikular na paraan
Basahin ang mga counter sa layer na hinuhubog mo. Nagbabala rin ang parehong gabay ng Cisco na maaaring hindi tumpak ang mga counter ng patakaran ng pangunahing interface sa kaayusang ito. Iyon ay isang paalala tungkol sa counter, hindi patunay na tumutugma o nagtatapon ang isang klase. Ihiwalay ito sa resulta ng aplikasyon, na siyang tanging bagay na nararanasan ng gumagamit.
Ang pagkopya ng lumang halimbawa ng traffic-shape sa tabi ng isang walang kaugnayang mapa ng patakaran ay hindi nagpapatunay na kinokontrol ng dalawang rate ang parehong mga packet.
Subukan ang kabuuan, hindi lamang ang kisame
Magsimula sa isang abalang spoke at tiyakin na naaabot nito ang kisame nito. Pagkatapos ay mag-alok ng trapiko mula sa lahat nang sabay-sabay sa ilalim ng isang aprubadong plano, at panoorin ang pisikal na interface sa tabi ng mga numero bawat tunnel. Kung nakaupo ang bawat spoke sa kisame nito habang siksik ang uplink at tumataas ang pagkaantala, gumagana ang patakaran bawat spoke nang eksakto tulad ng dinisenyo at mali pa rin ang badyet.
Ang pagwawasto sa puntong iyon ay isang desisyon sa kapasidad o pagtanggap. Ang muling pagsasaayos ng mga numero bawat spoke ay nagbabago lamang kung aling sangay ang unang magrereklamo.