El QoS per túnel no limita l’uplink total del vostre hub

La creença sona com aritmètica: cinc spokes conformats a 5 Mbit/s cadascun, així que el hub transporta 25 Mbit/s com a màxim. La primera meitat és certa i la conclusió no. Una política per túnel s’aplica un cop per túnel, no un cop per hub, i l’uplink compartit que travessen tots cinc túnels no apareix mai en aquest càlcul. La congestió a l’uplink sobreviu exactament tal com era.

D’on ve la creença

La confusió és comprensible, perquè la informació de grup NHRP permet que una definició de política s’apliqui a tot un conjunt de spokes. Això es llegeix com un pressupost compartit en un fitxer de configuració. El que significa realment és que cada spoke obté la seva pròpia instància d’aquesta definició.

Així, 5 Mbit/s per spoke és un sostre per túnel, i hi ha tants sostres com túnels.

Què controla una instància de política

La guia de Cisco de QoS per túnel de DMVPN a IOS XE descriu una política de sortida del hub seleccionada mitjançant informació de grup NHRP i aplicada per separat a cada spoke. D’aquesta frase se’n deriven dos límits, i tots dos s’ignoren. La taxa pertany a un spoke i no a un receptacle compartit, i la funció governa el trànsit del hub cap al spoke, no al revés.

Planifiqueu la direcció d’enviament del spoke de manera independent. Res en una política de sortida del hub no limita el que una branca puja.

Poseu el límit agregat al coll d’ampolla compartit

L’agregat s’ha de conformar on realment competeix: a la interfície física que comparteixen tots els túnels. Cisco documenta un shaper class-default a la interfície física com la política física concurrent suportada per a aquesta funció, que és una afirmació més estreta que qualsevol jerarquia que pugueu escriure. Assumiu que la segona política física arbitrària que heu inventat no és suportada fins que algú demostri el contrari.

Després decidiu què passa quan tots els spokes estan ocupats alhora. Quin trànsit s’admet, quina classe té prioritat i quina cua posseeix la contenció. Un sostre per spoke no respon cap d’aquestes preguntes, perquè cada spoke es considera sol.

Feu coincidir les unitats de conformació i la comptabilitat de sobrecàrrega amb el lliurament real. La sobrecàrrega d’encapsulació que deixeu fora del càlcul de la taxa es manifesta com un enllaç que se satura abans del número configurat.

Els comptadors menteixen d’una manera concreta

Llegiu els comptadors a la capa que esteu conformant. La mateixa guia de Cisco adverteix que els comptadors de política de la interfície principal poden ser inexactes en aquesta disposició. Això és una advertència sobre el comptador, no una prova que una classe coincideixi o descarti. Manteniu-ho separat del resultat de l’aplicació, que és l’única cosa que l’usuari experimenta.

Copiar un exemple antic de traffic-shape al costat d’un mapa de política no relacionat no demostra que les dues taxes controlin els mateixos paquets.

Proveu l’agregat, no només el sostre

Comenceu amb un spoke ocupat i confirmeu que arriba al seu sostre. Després oferiu trànsit de tots alhora sota un pla aprovat, i observeu la interfície física al costat dels números per túnel. Si cada spoke se situa al seu sostre mentre l’uplink està fixat i el retard puja, la política per spoke funciona exactament com es va dissenyar i el pressupost encara és incorrecte.

La solució en aquest punt és una decisió de capacitat o d’admissió. Reajustar els números per spoke només canvia quina branca es queixa primer.