Sur cette page
À retenir
- Attribuer un rôle précisTerminer un tunnel, gérer les routes et transférer les paquets demandent des ressources et des preuves différentes.
- Dimensionner le chemin completLe débit affiché par un port virtuel ne mesure pas ce que la VM, l’hôte et le lien physique peuvent soutenir.
- Tester un service réelUne seconde session BGP n’est utile que si les routes sélectionnées et le chemin applicatif se rétablissent comme prévu.
Définir les fonctions de la VM avant de choisir sa taille
Un routeur VM peut terminer une livraison GRE validée, maintenir des sessions BGP ou router entre plusieurs réseaux. Précisez les fonctions attendues. Le contrôle des routes et le transfert des paquets sont liés, mais distincts : une VM qui échange des routes sans transporter les applications ne se dimensionne pas comme une passerelle placée sur leur chemin.
Dessinez le chemin réel : entrée publique, terminaison du tunnel, réseaux applicatifs, retour du trafic et accès d’administration. Identifiez le responsable de chaque frontière. Traitez séparément IPv4 et IPv6 lorsqu’ils sont utilisés. Ce relevé permet de distinguer un problème de configuration de la VM d’un problème d’hôte, de fournisseur ou d’extrémité distante.
Un serveur dédié existant assure peut-être déjà certaines fonctions. L’ajout d’une VM doit répondre à un besoin défini, comme isoler le rôle de routage ou préparer une autre livraison validée. Répartir les mêmes dépendances dans deux processus ne crée pas, à lui seul, une redondance indépendante.
Intégrer la politique de routage aux paramètres de livraison
Pour chaque voisin BGP, convenez des ASN local et distant, de la famille d’adresses, des adresses source et du voisin, des annonces autorisées et des routes attendues. Une route par défaut, un ensemble limité et une table Internet complète n’ont pas les mêmes exigences. Le support BGP ne signifie pas qu’une table complète est incluse.
Listez les imports et exports autorisés, les limites de préfixes et le comportement prévu en cas de dépassement. Conservez les éléments de propriété et d’autorisation des préfixes annoncés. La sécurité opérationnelle BGP comprend la politique de routes et la protection de la session ; les recommandations du RFC 7454 constituent une référence utile pour cette revue.
Une fois la session établie, inspectez les routes acceptées et celles installées pour les destinations concernées. Vérifiez le prochain saut et le chemin depuis les applications. L’état de la session ne prouve ni la réception d’une route par défaut, ni l’acceptation de vos préfixes, ni le retour du trafic vers l’application.
Mesurer le chemin de transfert virtualisé
La vitesse d’interface affichée dans la VM n’est pas un engagement de débit soutenu. Relevez CPU, mémoire, pilote invité, modèle de carte virtuelle et files, puis identifiez les ressources de l’hôte réellement disponibles. La contention de l’hôte et le lien physique font toujours partie du chemin.
Mesurez le volume et le nombre de paquets dans le sens utile. Un flux de gros paquets et beaucoup de petits paquets peuvent occuper une bande passante voisine tout en exigeant un nombre très différent d’opérations. Incluez NAT, filtrage, traitement des tunnels et autres fonctions qui seront actives en production.
Examinez les pertes et l’utilisation côté VM et côté hôte lorsque ces mesures sont disponibles. Une faible moyenne CPU peut cacher la saturation d’une file ou d’un cœur. La documentation réseau Linux décrit RSS, RPS et les mécanismes associés ; leur réglage demande une analyse du déploiement plutôt qu’une recette universelle sur le nombre de files.
Valider séparément l’encapsulation et le MTU
Conservez pour chaque tunnel l’extrémité externe livrée, l’adressage interne, l’encapsulation et le MTU. Un GRE simple sur IPv4 utilise 24 octets avant les champs optionnels ou une autre encapsulation. Ce calcul ne détermine pas le MTU réel du chemin. Les tunnels principal et de secours peuvent avoir des contraintes différentes.
Vérifiez des échanges applicatifs représentatifs avec de plus grandes charges utiles, en complément des petits tests de connectivité. Un petit ping ou une session BGP établie ne valide pas tous les services TCP et UDP. Examinez le retour et la découverte du MTU avec l’équipe réseau ; modifier la MSS TCP ne résout pas tous les échanges UDP trop grands.
Définir la panne que le secours doit pouvoir supporter
Une seconde VM sur le même hôte peut survivre à un problème propre à la première tout en partageant alimentation, hyperviseur, carte physique et amonts. Recensez ces éléments communs avant de parler de redondance. Deux sessions établies ne prouvent pas l’existence de deux chemins de données indépendants.
Convenez de la sélection des routes principales et de secours dans les deux sens. Quel événement retire ou dépriorise la route principale ? Une alternative est-elle éligible ? Que se passe-t-il au retour du principal ? Vérifiez aussi les routes statiques persistantes : une route statique indépendante peut continuer à sélectionner un chemin défaillant.
Réalisez un test de maintenance autorisé, avec une application de référence fonctionnelle et un responsable du retour arrière. Comparez la route choisie, les compteurs et le résultat applicatif pendant la panne précisément testée. Relevez le temps de reprise et l’effet sur les sessions existantes. Un redémarrage de VM ne valide pas une panne d’hôte ou d’amont.
Recetter le déploiement à partir de résultats observables
Avant de faire porter à la VM une dépendance importante de production, convenez d’un relevé de recette court. Réservez les tests de surcharge à un environnement isolé, sans propagation possible vers les clients. Le RFC 6815 explique pourquoi les tests de capacité RFC 2544 ne conviennent pas aux réseaux de production.
| Contrôle | Preuve à conserver | Portée du résultat |
|---|---|---|
| Routage | Imports, exports, routes installées et prochains sauts attendus | BGP établi décrit seulement l’état de session |
| Chemin applicatif | Échange abouti par l’entrée et le retour prévus | Une application ne valide pas tous les protocoles |
| MTU | Paramètres livrés et échanges plus grands sur chaque chemin | Un calcul d’octets ne mesure pas un chemin |
| Transfert | Compteurs bidirectionnels, tailles de paquets, fonctions actives et pertes | Le débit du port virtuel n’est pas une capacité de transfert mesurée |
| Reprise | Routes sélectionnées, impact utilisateur, temps de reprise et retour au nominal | Seuls la panne et les dépendances testées sont couverts |
Questions avant de commander un routeur VM
Un routeur VM remplace-t-il la protection DDoS en amont ?
Pas à lui seul. Il peut assurer le routage ou la livraison, mais le trafic doit encore lui parvenir par un chemin utilisable. Distinguez capacité amont, filtrage, ressources virtuelles et périmètre du service.
Le support BGP implique-t-il une table complète incluse ?
Non. Confirmez les familles d’adresses, routes reçues, limites de préfixes et conditions réelles. La mémoire des tables et le traitement des mises à jour doivent correspondre à la politique convenue.
Quelles informations permettent de qualifier le déploiement ?
Décrivez le rôle de routage, l’ASN et les préfixes autorisés le cas échéant, la livraison des tunnels, le trafic attendu en Gbit/s et paquets/s, les fonctions actives et les besoins de reprise. Ne transmettez pas d’identifiants secrets ni de clés privées.
