Le QoS par tunnel ne plafonne pas l’uplink total de votre hub

La croyance ressemble à de l’arithmétique : cinq spokes bridés à 5 Mbit/s chacun, donc le hub transporte 25 Mbit/s au maximum. La première moitié est vraie et la conclusion ne l’est pas. Une politique par tunnel s’applique une fois par tunnel, pas une fois par hub, et l’uplink partagé que traversent les cinq tunnels n’apparaît jamais dans ce calcul. La congestion sur l’uplink survit exactement comme avant.

D’où vient la croyance

La confusion est compréhensible, car les informations de groupe NHRP permettent à une seule définition de politique de s’appliquer à tout un ensemble de spokes. Cela se lit comme un budget partagé dans un fichier de configuration. Ce que cela signifie réellement, c’est que chaque spoke reçoit sa propre instance de cette définition.

Ainsi, 5 Mbit/s par spoke est un plafond par tunnel, et il y a autant de plafonds que de tunnels.

Ce que contrôle une instance de politique

Le guide Cisco du QoS par tunnel dans DMVPN sous IOS XE décrit une politique de sortie du hub sélectionnée via les informations de groupe NHRP et appliquée séparément à chaque spoke. Deux limites découlent de cette phrase, et toutes deux sont ignorées. Le débit appartient à un seul spoke et non à un seau partagé, et la fonction gouverne le trafic du hub vers le spoke, pas l’inverse.

Planifiez le sens d’envoi du spoke indépendamment. Rien dans une politique de sortie du hub ne plafonne ce qu’une agence téléverse.

Placez la limite agrégée au goulot d’étranglement partagé

L’agrégat doit être façonné là où il entre réellement en concurrence : sur l’interface physique que tous les tunnels partagent. Cisco documente un shaper class-default sur l’interface physique comme la politique physique concurrente prise en charge pour cette fonction, ce qui est une affirmation plus étroite que toute hiérarchie que vous pouvez saisir. Supposez que la seconde politique physique arbitraire que vous avez inventée n’est pas prise en charge jusqu’à ce que quelqu’un prouve le contraire.

Décidez ensuite de ce qui se passe quand tous les spokes sont occupés en même temps. Quel trafic est admis, quelle classe est priorisée et quelle file détient la contention. Un plafond par spoke ne répond à aucune de ces questions, car chaque spoke est considéré isolément.

Alignez les unités de façonnage et la comptabilité de l’overhead sur la remise réelle. L’overhead d’encapsulation que vous laissez hors du calcul de débit se manifeste comme un lien qui sature avant le nombre configuré.

Les compteurs mentent d’une manière précise

Lisez les compteurs à la couche que vous façonnez. Le même guide Cisco avertit que les compteurs de politique de l’interface principale peuvent être inexacts dans cette configuration. C’est une réserve sur le compteur, pas la preuve qu’une classe correspond ou rejette. Gardez cela séparé du résultat applicatif, qui est la seule chose que l’utilisateur ressent.

Copier un ancien exemple de traffic-shape à côté d’une policy-map sans rapport ne prouve pas que les deux débits contrôlent les mêmes paquets.

Testez l’agrégat, pas seulement le plafond

Commencez par un spoke occupé et confirmez qu’il atteint son plafond. Proposez ensuite du trafic de tous à la fois selon un plan approuvé, et observez l’interface physique à côté des chiffres par tunnel. Si chaque spoke reste à son plafond tandis que l’uplink est saturé et que le délai grimpe, la politique par spoke fonctionne exactement comme prévu et le budget est toujours faux.

Le correctif à ce stade est une décision de capacité ou d’admission. Réajuster les chiffres par spoke ne change que l’agence qui se plaint en premier.