Nexus TCAM : pourquoi une région de suppression ARP a besoin de deux tranches

Vous dimensionnez une région de suppression ARP, vous comptez les entrées dont le design a besoin, vous trouvez une région avec plus de capacité libre que cela, et le changement ne rentre toujours pas. Rien n'a été mal compté. Le budget que vous lisiez se mesure en tranches, et une fonction découpée en double largeur en a besoin de deux avant qu'aucune entrée ne soit prise en compte.

Traitez l'allocation comme un problème de disposition avec un nombre fixe d'unités, et l'arithmétique commence à se comporter correctement.

Une région possède des tranches, pas des entrées

Le TCAM sur ces plateformes est divisé en tranches, et chaque tranche appartient à exactement une région. Les régions sont dimensionnées en tranches, et la largeur de la fonction détermine combien de tranches elle consomme au minimum. Une fonction de largeur simple peut vivre dans une seule tranche ; une fonction de double largeur a besoin d'une paire contiguë.

Une tranche libre n'est donc pas automatiquement une capacité utilisable. Deux régions de largeur simple sur des tranches séparées ne se combinent pas en la paire qu'exige une nouvelle région de double largeur, et le tableau qui montre beaucoup d'espace inutilisé au total vous parle d'un pool que vous ne pouvez pas dépenser.

Enregistrez la référence avant de découper

Rassemblez le modèle matériel exact, la version de NX-OS, les largeurs et tailles actuelles des régions et les fonctions qui consomment chaque région. Faites-le avant tout changement, car après un rechargement l'état précédent est un souvenir et non un fait.

show version
show hardware capacity
show running-config | include hardware profile

Les noms de commandes varient selon la plateforme et la version, et le guide de découpage nomme celles qui s'appliquent à son propre matériel. Lisez la sortie que vous obtenez réellement au lieu de supposer qu'une commande d'un autre modèle produit le même tableau.

Notez ensuite à quoi sert chaque région. Une région VACL est une capacité de filtrage pour une raison, et une région QoS existe parce que quelqu'un l'a dimensionnée pour une politique toujours en vigueur. Un plan qui traite ces espaces comme de l'espace récupérable sans vérification est un plan pour retirer des fonctions discrètement. Nommez un propriétaire pour chaque région que vous comptez réduire, et donnez à ce propriétaire la nouvelle taille avant la fenêtre.

Tenez compte aussi de la direction. Là où la plateforme couple l'allocation entrante et sortante, un changement d'un côté peut consommer du budget de l'autre, et un plan qui ne compte que la table entrante semblera correct et échouera au rechargement.

Ce que libérer une grande tranche ne fait pas

Réduire une grande région de largeur simple libère une tranche. Si votre région cible a besoin d'une paire, cette tranche unique peut être inutile à moins qu'elle soit adjacente à une autre tranche libre, et l'adjacence est une propriété de la disposition, non du total.

C'est le point où les gens concluent que la plateforme est cassée ou que la documentation est fausse. Ni l'un ni l'autre n'est vrai. Le modèle d'allocation fait exactement ce qu'il dit, et l'erreur était de compter l'espace libre au lieu de compter les tranches libres aux bons endroits. Une fois la disposition dessinée sur papier, la paire disponible existe ou n'existe pas, et c'est une conversation bien plus facile avec le propriétaire de la plateforme qu'une dispute sur des totaux.

Il y a aussi un piège de version qu'il vaut la peine de nommer. Le guide de découpage de Cisco décrit une génération matérielle précise et indique clairement que son modèle n'est ni Cloud Scale ni Silicon One. Les noms de régions, les tailles par défaut et même les fonctions de double largeur diffèrent ailleurs, donc un avertissement sur une région précise sur une plateforme est une preuve concernant cette plateforme et cette version, pas une recette universelle.

Changer une région est un changement de fonction

Chaque découpage est un échange de capacité. Réduire une région pour faire de la place à la suppression ARP réduit ce que cette région protégeait, et la conséquence peut n'apparaître qu'une fois la politique qui a besoin de l'espace réappliquée.

Obtenez l'accord écrit du propriétaire de chaque fonction affectée avant la fenêtre. Ce n'est pas de la bureaucratie : la personne qui a dimensionné la région VACL à l'origine sait ce qu'elle filtre, et celle qui fait de la place ne le sait généralement pas.

Attendez-vous à un rechargement pour les changements qui modifient la disposition matérielle. Certaines plateformes l'exigent et d'autres non, mais planifier sans fenêtre de maintenance quand un rechargement est possible, c'est ainsi qu'un changement de routage devient une panne. Planifiez la fenêtre autour du rechargement plutôt qu'autour de la commande, et conservez le texte du profil précédent quelque part où vous pouvez le lire depuis une console qui a perdu sa session de gestion.

Appliquez et vérifiez par rapport à la référence

Appliquez le plan via le processus pris en charge de la plateforme, puis vérifiez les fonctions que vous avez préservées, pas seulement celle que vous avez ajoutée. Une région nouvellement découpée qui fonctionne alors que le filtrage a silencieusement cessé de correspondre est un résultat pire que la défaillance initiale.

Relisez la sortie de capacité et comparez-la à la référence que vous avez enregistrée, puis testez la fonction qui a motivé le changement. Le guide de découpage Nexus TCAM est la référence pour le modèle de largeur et de tranches décrit ici, y compris la génération matérielle qu'il couvre.