QoS per tunnel beheint net de totale uplink fan jo hub

It leauwen klinkt as rekkenjen: fiif spokes, elk foarme ta 5 Mbit/s, dus draacht de hub op syn heechst 25 Mbit/s. De earste helte is wier en de konklúzje net. In belied per tunnel wurdt ien kear per tunnel tapast, net ien kear per hub, en de dielde uplink dêr't alle fiif tunnels trochgeane ferskynt nea yn dy berekking. De oerlêst op de uplink oerlibbet krekt sa't er wie.

Wêr't it leauwen wei komt

De betizing is begryplik, want NHRP-groepsynformaasje lit ien beliedsdefinysje jilde foar in hiele set spokes. Dat lêst as in dield budzjet yn in konfiguraasjebestân. Wat it eins betsjut, is dat elke spoke syn eigen eksimplaar fan dy definysje krijt.

Sa is 5 Mbit/s per spoke in plafond per tunnel, en der binne safolle plafonds as tunnels.

Wat ien beliedseksimplaar regelet

De Cisco-gids foar QoS per tunnel yn DMVPN op IOS XE beskriuwt in útgongbelied fan 'e hub dat troch NHRP-groepsynformaasje keazen en apart op elke spoke tapast wurdt. Ut dy sin folgje twa grinzen, en beide wurde negearre. De faasje heart by ien spoke en net by in dielde amer, en de funksje regelet ferkear fan 'e hub nei de spoke, net oarsom.

Plan de stjoerrjochting fan 'e spoke selsstannich. Neat yn in útgongbelied fan 'e hub beheint wat in filiaal oplaadt.

Set de totale grins by it dielde knelpunt

It gehiel moat foarme wurde dêr't it gehiel echt konkurrearret: op 'e fysike ynterface dy't alle tunnels diele. Cisco dokumintearret in class-default-shaper op 'e fysike ynterface as it stipe tagelyk fysike belied foar dizze funksje, wat in nauwere bewearing is as elke hiërargy dy't jo ynfiere kinne. Nim oan dat it willekeurige twadde fysike belied dat jo betocht hawwe net stipe wurdt oant immen it tsjinoerstelde bewyst.

Beslis dan wat der bart as alle spokes tagelyk dwaande binne. Hokker ferkear wurdt talitten, hokker klasse krijt prioriteit en hokker wachtrige hat de striid. In plafond per spoke beantwurdet gjinien fan dy fragen, want elke spoke wurdt op himsels besjoen.

Pas foarmingsienheden en oerheidsboekhâlding oan op 'e eigentlike oerdracht. Inkapselingsoerheid dy't jo bûten de faasjeberekkening litte, docht bliken as in ferbining dy't fersêde rekket foar it konfigurearre getal.

Tellers lige op ien spesifike manier

Lês tellers op 'e laach dy't jo foarmje. Deselde Cisco-gids warskôget dat beliedstellers fan 'e haadynterface yn dizze opstelling ûnkrekt wêze kinne. Dat is in foarbehâld oer de teller, gjin bewiis dat in klasse oerienkomt of weilitten wurdt. Hâld it apart fan it applikaasjeresultaat, dat it iennichste is wat de brûker belibbet.

It kopiearjen fan in âld traffic-shape-foarbyld njonken in net besibbe beliedsmap bewiist net dat de twa faasjes deselde pakketten regele.

Test it gehiel, net allinnich it plafond

Begjin mei ien drokke spoke en befêstigje dat dy syn plafond berikt. Bied dan ferkear fan allegear tagelyk oan ûnder in goedkard plan, en sjoch nei de fysike ynterface njonken de sifers per tunnel. As elke spoke op syn plafond sit wylst de uplink fêstset is en fertraging omheech giet, wurket it belied per spoke krekt sa't it ûntwurpen is en is it budzjet noch hieltyd ferkeard.

De oplossing op dat punt is in kapasiteits- of talittingsbeslissing. It wer ôfstimmen fan de sifers per spoke feroaret allinnich wa't it earst klaget.