El QoS por túnel no limita el uplink total de tu hub

La creencia suena a aritmética: cinco spokes conformados a 5 Mbit/s cada uno, así que el hub transporta 25 Mbit/s como máximo. La primera mitad es cierta y la conclusión no. Una política por túnel se aplica una vez por túnel, no una vez por hub, y el uplink compartido que atraviesan los cinco túneles nunca aparece en ese cálculo. La congestión en el uplink sobrevive exactamente como estaba.

De dónde viene la creencia

La confusión es comprensible, porque la información de grupo NHRP permite que una definición de política se aplique a todo un conjunto de spokes. Eso se lee como un presupuesto compartido en un archivo de configuración. Lo que significa en realidad es que cada spoke recibe su propia instancia de esa definición.

Así que 5 Mbit/s por spoke es un techo por túnel, y hay tantos techos como túneles.

Qué controla una instancia de política

La guía de Cisco de QoS por túnel de DMVPN en IOS XE describe una política de salida del hub seleccionada mediante información de grupo NHRP y aplicada por separado a cada spoke. De esa frase se derivan dos límites, y ambos se ignoran. La tasa pertenece a un solo spoke y no a un depósito compartido, y la función gobierna el tráfico del hub hacia el spoke, no al revés.

Planifica la dirección de envío del spoke de forma independiente. Nada en una política de salida del hub limita lo que una sucursal sube.

Pon el límite agregado en el cuello de botella compartido

El agregado debe conformarse donde realmente compite: en la interfaz física que comparten todos los túneles. Cisco documenta un shaper class-default en la interfaz física como la política física concurrente admitida para esta función, lo que es una afirmación más estrecha que cualquier jerarquía que puedas escribir. Asume que la segunda política física arbitraria que inventaste no está admitida hasta que alguien demuestre lo contrario.

Luego decide qué ocurre cuando todos los spokes están ocupados a la vez. Qué tráfico se admite, qué clase tiene prioridad y qué cola posee la contención. Un techo por spoke no responde a ninguna de esas preguntas, porque cada spoke se considera por separado.

Ajusta las unidades de conformado y la contabilidad de sobrecarga a la entrega real. La sobrecarga de encapsulación que dejas fuera del cálculo de la tasa se manifiesta como un enlace que se satura antes del número configurado.

Los contadores mienten de una manera concreta

Lee los contadores en la capa que estás conformando. La misma guía de Cisco advierte que los contadores de política de la interfaz principal pueden ser inexactos en esta disposición. Es una advertencia sobre el contador, no una prueba de que una clase coincida o descarte. Mantenlo separado del resultado de la aplicación, que es lo único que el usuario experimenta.

Copiar un ejemplo antiguo de traffic-shape junto a un mapa de políticas no relacionado no demuestra que las dos tasas controlen los mismos paquetes.

Prueba el agregado, no solo el techo

Empieza con un spoke ocupado y confirma que alcanza su techo. Luego ofrece tráfico de todos a la vez bajo un plan aprobado y observa la interfaz física junto a los números por túnel. Si cada spoke se queda en su techo mientras el uplink está saturado y la latencia sube, la política por spoke funciona exactamente como se diseñó y el presupuesto sigue estando mal.

La solución en ese punto es una decisión de capacidad o de admisión. Reajustar los números por spoke solo cambia qué sucursal se queja primero.