Étiquette par VRF ou par préfixe ? La vraie facture de capacité

Deux conceptions annoncent le même préfixe client dans le même cœur de réseau du fournisseur. L’une alloue une étiquette par préfixe, l’autre alloue une seule étiquette pour tout le VRF, et la seconde paraît moins chère sur toutes les diapositives. Le nombre d’étiquettes est réel, mais ce n’est pas le budget qui s’épuise habituellement en premier. Choisir entre les deux revient à compter quatre ressources, pas une, et les étiquettes sont la plus petite d’entre elles.

Le choix dépend aussi de ce que le routeur de sortie doit faire du paquet après avoir retiré l’étiquette. C’est cette différence fonctionnelle, et non l’arithmétique des étiquettes, qui doit guider la décision.

Ce que chaque allocation permet réellement d’économiser

Une allocation par préfixe transporte l’information de transfert dans l’étiquette. Le routeur de sortie peut envoyer le paquet directement vers la bonne adjacence sans recherche de destination, ce qui explique sa bonne mise à l’échelle pour les grands ensembles de routes VRF et pourquoi elle consomme une étiquette pour chaque préfixe annoncé dans chaque VRF. Une allocation par VRF, comme Junos vrf-table-label, annonce une étiquette par instance de routage et utilise cette étiquette pour sélectionner la table VRF ; le routeur effectue ensuite une recherche IP dans la table.

Il s’agit d’une véritable différence d’architecture, et non d’un réglage. L’étiquetage par VRF offre un espace d’étiquettes plus petit et une annonce d’étiquettes plus simple, au prix d’une recherche et d’une étiquette qui ne dit rien de la destination. L’étiquetage par préfixe donne à la carte de ligne de sortie davantage d’informations en amont et coûte des étiquettes proportionnellement aux routes transportées.

Le registre des étiquettes est le petit

Les étiquettes MPLS sont finies, mais l’espace d’étiquettes est assez grand pour que les fournisseurs de services ordinaires ne l’épuisent pas avec quelques milliers de préfixes. L’étiquetage par VRF aide réellement sur les plateformes dotées de petites tables d’étiquettes matérielles, ou dans les conceptions où un seul VRF transporte un flux Internet complet et où les étiquettes par préfixe multiplieraient la demande d’étiquettes par le nombre de routes. Ce sont de vraies contraintes, et c’est la raison d’être de la fonction. Aucune d’elles ne concerne le nombre de préfixes dans la table.

Comptez les étiquettes pour le service et pour le transport avant de choisir. Une conception par VRF a toujours besoin d’étiquettes de transport pour les loopbacks et pour chaque saut du chemin, et elle a toujours besoin d’état d’adjacence. Si le cahier des charges ne compte que les étiquettes de service, l’économie est mesurée sur le mauvais registre.

Les flux de routes coûtent de la mémoire avant les étiquettes

Chaque chemin reçu consomme de la mémoire du plan de contrôle, du traitement de mises à jour et du temps de convergence, que le VRF utilise une étiquette ou dix mille. Un flux Internet complet dans un VRF coûte cher à cause des chemins BGP, de la RIB, des entrées FIB et du remue-ménage derrière eux, et non à cause de l’étiquette qui précède la table. Le même flux augmente aussi le rayon d’impact d’une fuite de routes ou d’une erreur de politique dans ce locataire.

Demandez donc ce dont le client a réellement besoin. Si le contrat prévoit des sites privés plus une sortie par défaut, une table complète ajoute du coût sans ajouter d’exigence. C’est une question commerciale, et elle mérite une réponse écrite plutôt qu’une hypothèse héritée de la conception précédente. Si le service a vraiment besoin du flux pour la politique ou pour la sélection de sortie locale, faites-en une ligne explicite avec sa propre réservation de capacité et son propre comportement en cas de panne.

Quand l’étiquetage par VRF est le bon choix par défaut

C’est un bon choix par défaut lorsque la plateforme le documente comme pris en charge, lorsque le nombre de routes du VRF est élevé et lorsque le coût de recherche à la sortie est acceptable pour le profil de trafic. C’est aussi le choix naturel lorsque la simplicité opérationnelle compte plus que gagner la dernière microseconde sur le transfert, car une étiquette par locataire est plus facile à expliquer et à auditer qu’une étiquette par préfixe.

C’est un mauvais choix par défaut lorsque la documentation de la plateforme lie la fonction à des contraintes matérielles ou de version précises, ou lorsque la conception dépend de décisions de transfert par préfixe à la sortie. Lisez la référence de statement de la plateforme avant de supposer le comportement ; la commande Junos est documentée, mais ce sont les limites matérielles et de version qui l’entourent qui décident réellement du déploiement.

Un budget que vous pouvez défendre

Bâtissez le dossier de capacité en cinq nombres distincts : chemins reçus, routes sélectionnées, entrées de transfert installées, étiquettes de service et étiquettes de transport. Ajoutez l’état de next-hop et d’adjacence, le nombre de locataires et le modèle de redondance. L’instantané du chemin nominal d’un seul VRF n’est pas un chiffre d’échelle, et une taille nominale d’espace d’étiquettes n’est pas une table matérielle disponible.

Convenez ensuite du mode de défaillance autant que du régime permanent. Que se passe-t-il lorsque le flux augmente de moitié, lorsqu’un locataire ajoute un second VRF ou lorsque la plateforme doit redémarrer pour redimensionner une table ? Un budget qui résiste à ces questions vaut plus qu’un nombre d’étiquettes qui ne tient que sur le papier.

Choisissez l’allocation d’après l’action à la sortie et les limites de la plateforme, puis faites du flux de routes une décision de service explicite. L’étiquette est la partie visible de la conception ; les routes sont la partie qu’il faut payer chaque jour.