Tunel bakoitzeko QoSak ez du zure hubaren uplink osoa mugatzen

Sinesmena aritmetika bezala entzuten da: bost spoke, bakoitza 5 Mbit/s-ra moldatuta, beraz hubak gehienez 25 Mbit/s eramaten ditu. Lehen erdia egia da eta ondorioa ez. Tunel bakoitzeko politika tunel bakoitzeko behin aplikatzen da, ez hub bakoitzeko behin, eta bost tunelek zeharkatzen duten uplink partekatua ez da inoiz agertzen kalkulu horretan. Uplinkeko kongestioak bere horretan jarraitzen du.

Nondik dator sinesmena

Nahasmendua ulergarria da, NHRP talde-informazioak politika-definizio bat spoke multzo osoari aplikatzeko aukera ematen duelako. Hori konfigurazio-fitxategi bateko aurrekontu partekatu gisa irakurtzen da. Benetan esan nahi duena da spoke bakoitzak definizio horren bere instantzia lortzen duela.

Beraz, spokeko 5 Mbit/s tunel bakoitzeko sabaia da, eta sabaiak tunelak adina dira.

Zer kontrolatzen du politika-instantzia batek

Ciscoren IOS XEko DMVPN-eko tunel bakoitzeko QoS gida hubaren irteera-politika bat deskribatzen du, NHRP talde-informazioaren bidez hautatzen dena eta spoke bakoitzari bereizita aplikatzen zaiona. Esaldi horretatik bi muga datoz, eta biak ez dira kontuan hartzen. Abiadura spoke bakarrari dagokio, ez ontzi partekatu bati, eta funtzioak hubatik spokera doan trafikoa gobernatzen du, alderantzizkoa ez.

Planifikatu spokearen bidaltze-norabidea modu independentean. Hubaren irteera-politika batean ezerk ez du mugatzen adar batek igotzen duena.

Jarri muga agregatua lepo-puntu partekatuan

Agregatuak benetan lehiatzen den tokian moldatu behar du: tunel guztiek partekatzen duten interfaze fisikoan. Ciscok class-default shaper bat dokumentatzen du interfaze fisikoan funtzio honetarako onartutako politika fisiko konkurrentetzat, eta hori idatz dezakezun edozein hierarkia baino adierazpen estuagoa da. Eman ezazu asmatu duzun bigarren politika fisiko arbitrarioa ez dela onartzen norbaitek kontrakoa frogatu arte.

Ondoren erabaki zer gertatzen den spoke guztiak aldi berean okupatuta daudenean. Zein trafiko onartzen den, zein klasek duen lehentasuna eta zein ilarak duen lehia. Spokeko sabaiak ez dio galdera horietako bati ere erantzuten, spoke bakoitza bereizita aztertzen delako.

Egokitu moldeatze-unitateak eta gainkostuaren kontabilitatea benetako entrega. Abiaduraren kalkulutik kanpo uzten duzun kapsulatze-gainkostua konfiguratutako zenbakia baino lehen saturatzen den esteka gisa agertzen da.

Kontagailuek modu zehatz batean gezurra esaten dute

Irakurri kontagailuak moldeatzen ari zaren geruzan. Cisco gida berak ohartarazten du interfaze nagusiko politika-kontagailuak zehaztugabeak izan daitezkeela antolamendu honetan. Hori kontagailuari buruzko oharra da, ez klase batek bat egiten edo uzten duen froga. Mantendu aplikazioaren emaitzatik bereizita, erabiltzaileak esperimentatzen duen gauza bakarra baita.

Traffic-shape adibide zahar bat politikarekin zerikusirik ez duen mapa baten ondoan kopiatzeak ez du frogatzen bi abiadurek pakete berak kontrolatzen dituztenik.

Probatu agregatua, ez sabaia soilik

Hasi spoke okupatu batekin eta egiaztatu bere sabaira iristen dela. Ondoren eskaini trafikoa denetatik aldi berean onartutako plan baten arabera, eta begiratu interfaze fisikoa tunel bakoitzeko zenbakien ondoan. Spoke bakoitza bere sabaian badago uplinka estua dagoen bitartean eta atzerapena igotzen bada, spokeko politikak diseinatu zen bezala funtzionatzen du eta aurrekontua oraindik oker dago.

Une horretako konponketa edukiera edo onarpen-erabakia da. Spokeko zenbakiak berdoitzea soilik aldatzen du zein adar kexatzen den lehenengo.