Dimensionner un grand VPN en étoile : comptez avant de choisir BGP

Trois mille sites ressemblent à un problème de routage mais se comportent comme un problème de comptabilité. Le total des préfixes se calcule en dix minutes, et c'est rarement le nombre qui fait mal. Ce qui fait mal, c'est le travail par session, la rafale de mises à jour quand un composant partagé tombe, et le temps qui passe avant que le transfert ne corresponde à nouveau à la nouvelle topologie.

Parcourez donc l'arithmétique dans le bon ordre. Comptez les relations, comptez les préfixes et les alternatives, puis comptez ce qui se passe pendant une mauvaise heure, et seulement ensuite comparez protocoles et plateformes. Dans l'autre ordre, l'exercice devient une discussion sur les limites de routes que personne ne peut trancher avec les informations sur la table.

Quatre budgets, pas un

Chaque budget répond à une question différente, et chacun peut être la contrainte limitante sur une plateforme différente. Les écrire séparément évite qu'un seul grand nombre de préfixes tienne lieu de toute la conception.

Les deux derniers sont ceux qu'on saute lors d'une revue de conception. Un réseau qui tient confortablement en mémoire à l'état stable peut encore mal se comporter quand quatre cents sites se reconnectent en deux minutes, parce que le travail arrive plus vite que le plan de contrôle ne le vide. Notez la taille de la rafale sous forme de nombre, avec la durée pendant laquelle le service peut rester dégradé. Cela transforme une inquiétude vague en un test que quelqu'un peut réellement exécuter.

Une question de plateforme se cache aussi dans les quatre : le chiffrement, le transfert et le routage partagent-ils un même CPU ou ont-ils des chemins séparés. Deux équipements dotés d'une capacité de routes identique peuvent se comporter très différemment sous la rafale, et la fiche technique dit rarement lequel vous achetez.

Faites l'arithmétique avec vos propres chiffres

Prenez une conception fictive : 3,000 sites, trois préfixes chacun avant agrégation, et deux concentrateurs par site pour la redondance. La paire de concentrateurs doit tenir environ 9,000 préfixes de site avant résumé, et la conception implique 6,000 sessions site-concentrateur si chaque site s'appaire aux deux.

Ajoutez maintenant les parties qui ne sont pas des préfixes. Chaque session porte un état et des messages périodiques même quand rien ne change. Chaque concentrateur peut conserver plus d'un chemin par préfixe s'il doit basculer rapidement, si bien que le nombre d'alternatives peut dépasser le nombre de sélectionnées. Et la vue de chaque branche est une décision de politique distincte : donner à chaque site les routes de tous les autres multiplie le travail d'une manière que le décompte côté concentrateur ne révèle pas.

Ce sont des chiffres de planification pour une conversation de conception, pas la mesure d'un produit. Le résultat utile de l'exercice est la forme de la courbe, pas une affirmation sur l'endroit où un routeur précis cède.

Ce que BGP vous apporte, et ce qu'un IGP vous apporte

BGP sépare ce qu'un routeur a reçu, ce qu'il a sélectionné et ce qu'il annonce, et chacune de ces choses est contrôlée par la politique. C'est exactement ce dont un réseau de sites a besoin, car une branche doit généralement voir une route par défaut, les services centraux et très peu d'autre chose. Compter seulement la table finale cache les alternatives et les annonces, qui sont précisément les parties qui grossissent quand on ajoute de la redondance.

Un IGP n'est pas automatiquement faux. Quand la topologie, la structure des zones et le modèle d'adjacence correspondent au service, un protocole à état de liens converge vite et demande moins d'échafaudage de politique. Le piège est de supposer qu'il peut exprimer le même contrôle d'export par voisin que BGP : une zone OSPF est une frontière d'inondation, pas un filtre qu'on accroche à un site.

Dans tous les cas, décidez d'abord le modèle de visibilité. Routes par défaut, résumés pour les services centraux ou détails complets des sites sont trois produits différents, et un résumé qui masque une panne plus spécifique est une décision de conception qui doit être écrite, pas découverte pendant un incident.

Testez la rafale, pas l'état stable

Construisez la comparaison autour de la panne que vous attendez vraiment : un concentrateur à terre, un événement WAN régional ou une fenêtre de maintenance qui met la moitié des sites hors ligne d'un coup. Mesurez la reprise du point de vue du site, application comprise, car un plan de contrôle qui converge en secondes compte peu si la session met des minutes à se rétablir.

show bgp vpnv4 unicast summary
show ip route vrf BRANCH summary
show processes cpu sorted | include BGP|OSPF

Enregistrez ce que fait la plateforme au pic de la rafale plutôt qu'au repos, et répétez-le avec les fonctions de sécurité activées. Une preuve de concept qui ne montre qu'une table tranquille est un test de mémoire, et la mémoire n'a jamais été le nombre intéressant.