QoS por unuopo ne limigas la tutan suprenligon de via hubo
Kvin spokes po 5 Mbit ne estas suprenligo de 10 Mbit, kaj la politiko por unuopo neniam vidis la diferencon. Buĝetu la komunan botelon aparte.
La kredo sonas kiel aritmetiko: kvin spokes, ĉiu formita al 5 Mbit/s, do la hubo portas maksimume 25 Mbit/s. La unua duono veras kaj la konkludo ne. Politiko por unuopo aplikiĝas unufoje por unuopo, ne unufoje por hubo, kaj la komuna suprenligo, kiun ĉiuj kvin unuopoj transiras, neniam aperas en tiu kalkulo. La kongesto sur la suprenligo pluvivas ĝuste tiel, kiel ĝi estis.
De kie venas la kredo
La konfuzo estas komprenebla, ĉar grupaj informoj NHRP lasas unu politikan difinon validi por tuta aro de spokes. Tio legiĝas kiel komuna buĝeto en agorda dosiero. Kion ĝi fakte signifas estas, ke ĉiu spoke ricevas sian propran okazon de tiu difino.
Do 5 Mbit/s por spoke estas plafono por unuopo, kaj estas tiom da plafonoj kiom da unuopoj.
Kion regas unu politika okazo
La gvidilo de Cisco pri QoS por unuopo en DMVPN ĉe IOS XE priskribas elirpolitikon de la hubo elektitan per grupaj informoj NHRP kaj aplikatan aparte al ĉiu spoke. Du limoj sekvas el tiu frazo, kaj ambaŭ estas ignorataj. La rapideco apartenas al unu spoke, ne al komuna sitelo, kaj la funkcio regas trafikon de la hubo al la spoke, ne inverse.
Planu la sendodirekton de la spoke sendepende. Nenio en elirpolitiko de la hubo limigas tion, kion filio alŝutas.
Metu la suman limon ĉe la komuna botelo
La sumo devas esti formita tie, kie la sumo efektive konkuras: sur la fizika interfaco, kiun ĉiuj unuopoj dividas. Cisco dokumentas class-default-formilon sur la fizika interfaco kiel la subtenatan samtempan fizikan politikon por ĉi tiu funkcio, kio estas pli mallarĝa aserto ol ĉiu hierarkio, kiun vi povas entajpi. Supozu, ke la arbitra dua fizika politiko, kiun vi elpensis, ne estas subtenata, ĝis iu pruvos la malon.
Poste decidu, kio okazas, kiam ĉiuj spokes estas samtempe okupataj. Kiu trafiko estas akceptata, kiu klaso ricevas prioritaton kaj kiu vico posedas la konkuradon. Plafono por spoke respondas neniun el tiuj demandoj, ĉar ĉiu spoke estas konsiderata sola.
Akomodu la formajn unuojn kaj la superkapan kalkuladon al la efektiva transdono. Superkapa kaŝado, kiun vi lasas ekster la rapideca kalkulo, montriĝas kiel ligilo, kiu satureciĝas antaŭ la agordita nombro.
Nombriloj mensogas en unu specifa maniero
Legu nombrilojn sur la tavolo, kiun vi formas. La sama gvidilo de Cisco avertas, ke politikaj nombriloj de la ĉefa interfaco povas esti malprecizaj en ĉi tiu aranĝo. Tio estas averto pri la nombrilo, ne pruvo, ke klaso kongruas aŭ forĵetas. Tenu ĝin aparte de la aplikaĵa rezulto, kiu estas la sola afero, kiun la uzanto spertas.
Kopii malnovan ekzemplon de traffic-shape apud nerilatan politikan mapon ne pruvas, ke la du rapidecoj regas la samajn pakaĵojn.
Testu la sumon, ne nur la plafonon
Komencu per unu okupata spoke kaj konfirmu, ke ĝi atingas sian plafonon. Poste proponu trafikon de ĉiuj samtempe laŭ aprobita plano, kaj observu la fizikan interfacon apud la nombroj por unuopo. Se ĉiu spoke sidas ĉe sia plafono dum la suprenligo estas fiksita kaj la prokrasto kreskas, la politiko por spoke funkcias ĝuste kiel projektite kaj la buĝeto ankoraŭ malĝustas.
La korekto tiupunkte estas decido pri kapacito aŭ akcepto. Reagordi la nombrojn por spoke nur ŝanĝas, kiu filio plendas unue.