O QoS por túnel non limita o uplink total do teu hub

A crenza soa a aritmética: cinco spokes conformados a 5 Mbit/s cada un, así que o hub transporta 25 Mbit/s como máximo. A primeira metade é certa e a conclusión non. Unha política por túnel aplícase unha vez por túnel, non unha vez por hub, e o uplink compartido que atravesan os cinco túneles nunca aparece nese cálculo. A conxestión no uplink sobrevive exactamente como estaba.

De onde vén a crenza

A confusión é comprensible, porque a información de grupo NHRP permite que unha definición de política se aplique a todo un conxunto de spokes. Iso lese como un orzamento compartido nun ficheiro de configuración. O que significa en realidade é que cada spoke recibe a súa propia instancia desa definición.

Así que 5 Mbit/s por spoke é un teito por túnel, e hai tantos teitos como túneles.

Que controla unha instancia de política

A guía de Cisco de QoS por túnel de DMVPN en IOS XE describe unha política de saída do hub seleccionada mediante información de grupo NHRP e aplicada por separado a cada spoke. Desa frase derivan dous límites, e ambos se ignoran. A taxa pertence a un só spoke e non a un recipiente compartido, e a función goberna o tráfico do hub cara ao spoke, non ao revés.

Planifica a dirección de envío do spoke de forma independente. Nada nunha política de saída do hub limita o que unha sucursal sube.

Pon o límite agregado no pescozo de botella compartido

O agregado debe conformarse onde realmente compite: na interface física que comparten todos os túneles. Cisco documenta un shaper class-default na interface física como a política física concurrente admitida para esta función, o que é unha afirmación máis estreita que calquera xerarquía que poidas escribir. Asume que a segunda política física arbitraria que inventaches non está admitida ata que alguén demostre o contrario.

Despois decide que ocorre cando todos os spokes están ocupados á vez. Que tráfico se admite, que clase ten prioridade e que cola posúe a contención. Un teito por spoke non responde a ningunha desas preguntas, porque cada spoke se considera por separado.

Axusta as unidades de conformado e a contabilidade de sobrecarga á entrega real. A sobrecarga de encapsulación que deixas fóra do cálculo da taxa maniféstase como unha ligazón que se satura antes do número configurado.

Os contadores menten dunha maneira concreta

Le os contadores na capa que estás conformando. A mesma guía de Cisco advirte que os contadores de política da interface principal poden ser inexactos nesta disposición. É unha advertencia sobre o contador, non unha proba de que unha clase coincida ou descarte. Mantén isto separado do resultado da aplicación, que é o único que o usuario experimenta.

Copiar un exemplo antigo de traffic-shape xunto a un mapa de políticas non relacionado non demostra que as dúas taxas controlen os mesmos paquetes.

Proba o agregado, non só o teito

Comeza cun spoke ocupado e confirma que chega ao seu teito. Despois ofrece tráfico de todos á vez baixo un plan aprobado, e observa a interface física xunto aos números por túnel. Se cada spoke queda no seu teito mentres o uplink está saturado e a latencia sobe, a política por spoke funciona exactamente como se deseñou e o orzamento segue mal.

A solución nese punto é unha decisión de capacidade ou de admisión. Reaxustar os números por spoke só cambia que sucursal se queixa primeiro.