Toto presvedčenie znie ako aritmetika: päť spokov, každý obmedzený na 5 Mbit/s, takže hub prenáša nanajvýš 25 Mbit/s. Prvá polovica je pravdivá a záver nie. Politika na jednotlivé tunely sa uplatňuje raz na tunel, nie raz na hub, a zdieľaný uplink, ktorým prechádza všetkých päť tunelov, sa v tom výpočte nikdy neobjaví. Preťaženie na uplinku pretrváva presne tak, ako bolo.

Odkiaľ presvedčenie pochádza

Zmatek je pochopiteľný, pretože informácie o skupine NHRP umožňujú jednej definícii politiky platiť pre celú sadu spokov. To sa číta ako zdieľaný rozpočet v konfiguračnom súbore. V skutočnosti to znamená, že každý spok dostane svoju vlastnú inštanciu tejto definície.

Takže 5 Mbit/s na spok je strop na tunel a stropov je toľko, koľko je tunelov.

Čo riadi jedna inštancia politiky

Príručka Cisco o QoS na jednotlivé tunely v DMVPN v IOS XE opisuje výstupnú politiku hubu vyberanú pomocou informácií o skupine NHRP a uplatňovanú samostatne na každý spok. Z tejto vety vyplývajú dve obmedzenia a obe sa ignorujú. Rýchlosť patrí jednému spoku, nie zdieľanému vedru, a funkcia riadi prevádzku z hubu na spok, nie naopak.

Plánujte smer odosielania spoku nezávisle. Nič vo výstupnej politike hubu neobmedzuje to, čo pobočka nahrá.

Umiestnite súhrnný limit na zdieľané hrdlo

Súhrn musí byť tvarovaný tam, kde skutočne súťaží: na fyzickom rozhraní, ktoré všetky tunely zdieľajú. Cisco dokumentuje class-default shaper na fyzickom rozhraní ako podporovanú súbežnú fyzickú politiku pre túto funkciu, čo je užšie tvrdenie než akákoľvek hierarchia, ktorú môžete napísať. Predpokladajte, že ľubovoľná druhá fyzická politika, ktorú ste vymysleli, nie je podporovaná, kým niekto nepreukáže opak.

Potom rozhodnite, čo sa stane, keď sú všetky spoky zaneprázdnené naraz. Ktorá prevádzka sa pripustí, ktorá trieda má prioritu a ktorý front vlastní súperenie. Strop na spok neodpovedá na žiadnu z týchto otázok, pretože každý spok sa posudzuje samostatne.

Zosúlaďte jednotky tvarovania a účtovanie réžie so skutočným odovzdaním. Réžia zapuzdrenia, ktorú necháte mimo výpočtu rýchlosti, sa prejaví ako linka, ktorá sa nasýti skôr než nastavené číslo.

Počítadlá klamú jedným konkrétnym spôsobom

Čítajte počítadlá na vrstve, ktorú tvarujete. Tá istá príručka Cisco upozorňuje, že počítadlá politiky hlavného rozhrania môžu byť v tomto usporiadaní nepresné. Je to výhrada k počítadlu, nie dôkaz, že trieda sa zhoduje alebo zahadzuje. Držte to oddelene od výsledku aplikácie, ktorý je jediné, čo používateľ zažíva.

Kopírovanie starého príkladu traffic-shape vedľa nesúvisiacej mapy politiky nepreukazuje, že obe rýchlosti riadia tie isté pakety.

Testujte súhrn, nielen strop

Začnite jedným zaneprázdneným spokom a overte, že dosiahne svoj strop. Potom ponúknite prevádzku zo všetkých naraz podľa schváleného plánu a sledujte fyzické rozhranie vedľa čísel na jednotlivé tunely. Ak každý spok sedí na svojom strope, kým je uplink na doraz a oneskorenie rastie, politika na spok funguje presne tak, ako bola navrhnutá, a rozpočet je stále nesprávny.

Oprava v tom bode je rozhodnutie o kapacite alebo o prijatí. Doladenie čísel na spok mení len to, ktorá pobočka sa sťažuje prvá.

Súvisiace články