Marquage DSCP ou promesse QoS de l'opérateur ? Ni l'un ni l'autre n'est un contrat

Quelque chose est marqué, une file est configurée, puis quelqu'un demande quelle qualité la conception garantit réellement. La réponse honnête est que vous avez décrit deux moitiés d'un contrat qui se rencontrent à une frontière. Tant que vous ne pouvez pas nommer la classe que l'opérateur accepte et le traitement qu'il applique, la configuration locale est une intention, pas une promesse. Les deux moitiés comptent, et aucune ne peut être déduite de l'autre.

local match → queue and marking → provider classifier
  → provider treatment → destination

Où un marquage correct peut mourir en silence

Commencez par noter, pour chaque charge de travail, la condition de correspondance locale, tout marquage qui se produit dans un tunnel, la valeur que l'opérateur accepte et la classe de service que cette valeur sélectionne. Quatre colonnes, et les défaillances vivent généralement entre la deuxième et la troisième.

Le comportement de marquage d'interne vers externe est le problème classique. Un paquet dans un chemin chiffré ou tunnelisé porte un en-tête interne que votre classificateur peut voir et un en-tête externe que l'équipement de l'opérateur peut voir, et copier l'un dans l'autre est une décision de configuration, pas une propriété automatique. Marquez uniquement l'en-tête interne et l'opérateur classifie l'externe, généralement par défaut, ce qui explique qu'un flux correctement marqué puisse arriver dans la mauvaise classe sans une seule ligne mal configurée de votre côté.

Une classe nommée localement peut aussi rester vide parce que sa condition de correspondance ne se déclenche jamais sur de vrais paquets. Les ports bougent, les applications utilisent plusieurs flux, et une correspondance sur un port bien connu que le fournisseur a cessé d'utiliser deux versions plus tôt produit une file dont les compteurs sont à zéro et une politique qui, dans la configuration en cours, semble parfaite.

Décidez explicitement où les marquages sont dignes de confiance. Promouvoir tout ce qui partage un tunnel promeut les transferts en masse en même temps que les appels, et un opérateur qui accepte votre marquage sans validation vous offre un moyen de vous faire du mal. Si le contrat permet à la passerelle de remarquer à la remise, dites-le par écrit, car c'est précisément le point où les hypothèses de deux équipes divergent généralement.

Ce que le planificateur partage réellement

La politique locale a sa propre sémantique, et celle qui cause le plus de malentendus est le mot “remaining”. Sur les plateformes que décrit le guide de planification IOS XE, bandwidth remaining percent définit un poids excédentaire, et non une étape d'une séquence où chaque classe prend une part de ce que la classe précédente a laissé. Les pourcentages non attribués sont répartis entre les files éligibles non configurées au lieu d'être réservés à la dernière classe du fichier.

Cette distinction compte parce que le modèle mental séquentiel produit des prédictions qui ne correspondent jamais aux compteurs. Les ingénieurs réordonnent les classes pour changer un résultat, ne voient aucune différence et concluent que la plateforme est cassée, alors que la configuration n'a jamais voulu dire ce qu'ils supposaient.

Le régulateur parent est l'autre surprise courante. Réguler une file contrôlée jusqu'au débit de service utilisable est souvent délibéré, car cela déplace le point de congestion vers un équipement que vous administrez plutôt que vers une file amont que vous n'administrez pas. Supprimer le régulateur parce que la régulation ajoute du délai peut déplacer la perte au lieu de l'éliminer, et la comptabilisation des surcoûts ou un policer de l'opérateur peuvent rendre le débit effectif inférieur à ce que suggère l'interface.

Les compteurs disent quelle moitié a échoué

Comparez quatre nombres dans la direction affectée : ce qui a été offert, ce que la classe a intercepté, ce qui a été mis en file ou abandonné, et ce que le service a réellement livré. Gardez la description de la charge de travail et la version de la politique à côté de l'observation, car une capture d'écran des compteurs sans elles ne peut pas être reproduite.

Les branches sont des problèmes différents avec des propriétaires différents. Une classe locale qui ne correspond à rien est un défaut de classification de votre côté. Une classe qui correspond, se met en file et abandonne tandis que l'opérateur signale une livraison propre pointe vers votre propre planificateur ou régulateur. Une classe qui semble correcte localement tandis que la perte apparaît au-delà de la remise pointe vers le mapping de l'opérateur et la frontière mesurée dans le contrat. Aucune des trois ne se corrige en modifiant les autres, c'est pourquoi les nombres doivent être collectés ensemble.

RFC 2475 encadre la classification et le conditionnement comme un travail effectué à l'intérieur de domaines administratifs, et c'est précisément pourquoi un marquage ne peut pas réserver des files de bout en bout. Le guide de planification IOS XE est la référence pour le comportement de poids excédentaire décrit ci-dessus, et ses comparaisons de plateformes valent la peine d'être lues avant de déplacer un débit calculé entre modèles.

Écrivez le contrat en un seul endroit

Placez la correspondance locale, la frontière de confiance, la classe de l'opérateur et le niveau de service mesuré dans un seul document que les deux parties signent. Alors un changement de pourcentage a un contexte, et une plainte de qualité a un propriétaire.

Changer un pourcentage local ne peut pas réparer la garantie d'une autre file, et aucun schéma de marquage ne survit à un mapping que l'opérateur n'honore pas. Comparez les moitiés, nommez la frontière, et seulement alors citez un chiffre.