QoS për çdo tunel nuk kufizon uplink-un total të hub-it tuaj

Ky besim tingëllon si aritmetikë: pesë spoke, secili i formësuar në 5 Mbit/s, pra hub-i mbart më së shumti 25 Mbit/s. Gjysma e parë është e vërtetë dhe përfundimi jo. Një politikë për çdo tunel zbatohet një herë për tunel, jo një herë për hub, dhe uplink-u i përbashkët nëpër të cilin kalojnë të pesë tunelët nuk shfaqet kurrë në atë llogaritje. Mbingarkesa në uplink mbetet saktësisht siç ishte.

Nga vjen ky besim

Konfuzioni është i kuptueshëm, sepse informacioni i grupit NHRP lejon që një përkufizim i vetëm politikë të zbatohet për një grup të tërë spoke-ësh. Kjo lexohet si një buxhet i përbashkët në një skedar konfigurimi. Ajo që nënkupton në të vërtetë është se çdo spoke merr shembullin e vet të atij përkufizimi.

Pra 5 Mbit/s për spoke është një tavan për tunel, dhe ka aq tavane sa ka tunelë.

Çfarë kontrollon një shembull politike

Udhëzuesi i Cisco për QoS për çdo tunel në DMVPN në IOS XE përshkruan një politikë dalëse nga hub-i që zgjidhet përmes informacionit të grupit NHRP dhe zbatohet veçmas për çdo spoke. Nga ajo fjali rrjedhin dy kufizime, dhe të dyja injorohen. Shpejtësia i përket një spoke-i të vetëm dhe jo një kove të përbashkët, dhe veçoria drejton trafikun nga hub-i drejt spoke-it, jo anasjelltas.

Planifikoni drejtimin e dërgimit të spoke-it në mënyrë të pavarur. Asgjë në një politikë dalëse nga hub-i nuk kufizon atë që ngarkon një degë.

Vendosni kufirin e përgjithshëm në grykën e përbashkët

Tërësia duhet të formësohet atje ku konkurron vërtet: në ndërfaqen fizike që ndajnë të gjithë tunelët. Cisco dokumenton një shaper class-default në ndërfaqen fizike si politikën fizike të njëkohshme të mbështetur për këtë veçori, që është një pohim më i ngushtë se çdo hierarki që mund të shtypni. Supozoni se politika e dytë fizike arbitrare që shpikët nuk mbështetet derisa dikush të provojë të kundërtën.

Pastaj vendosni çfarë ndodh kur të gjithë spoke-ët janë të zënë njëkohësisht. Cili trafik pranohet, cila klasë merr përparësi dhe cila radhë zotëron garën. Një tavan për spoke nuk u përgjigjet asnjë prej këtyre pyetjeve, sepse çdo spoke konsiderohet veçmas.

Përputhni njësitë e formësimit dhe kontabilitetin e shpenzimeve shtesë me dorëzimin aktual. Shpenzimet shtesë të kapsulimit që lini jashtë llogaritjes së shpejtësisë shfaqen si një lidhje që ngopet para numrit të konfiguruar.

Numëruesit gënjejnë në një mënyrë të caktuar

Lexoni numëruesit në shtresën që po formësoni. I njëjti udhëzues i Cisco paralajmëron se numëruesit e politikës së ndërfaqes kryesore mund të jenë të pasaktë në këtë rregullim. Ky është një kusht për numëruesin, jo provë që një klasë përputhet ose hedh. Mbani atë veçmas nga rezultati i aplikacionit, që është e vetmja gjë që përjeton përdoruesi.

Kopjimi i një shembulli të vjetër traffic-shape pranë një harte politike të palidhur nuk provon se dy shpejtësitë kontrollojnë të njëjtat paketa.

Testoni tërësinë, jo vetëm tavanin

Filloni me një spoke të zënë dhe konfirmoni se arrin tavanin e tij. Më pas ofroni trafik nga të gjithë njëkohësisht sipas një plani të miratuar, dhe vëzhgoni ndërfaqen fizike pranë numrave për çdo tunel. Nëse çdo spoke qëndron në tavanin e tij ndërsa uplink-u është i bllokuar dhe vonesa rritet, politika për spoke funksionon saktësisht siç është projektuar dhe buxheti është ende i gabuar.

Rregullimi në atë pikë është një vendim kapaciteti ose pranimi. Rregullimi i numrave për spoke ndryshon vetëm cila degë ankohet e para.