Sur cette page
À retenir
- Documenter les deux sensLivraison filtrée et retour doivent respecter le modèle de routage et de protection choisi.
- Utiliser le MTU livréL’encapsulation et les chemins de secours peuvent nécessiter des valeurs différentes.
- Prouver le transfert et la repriseUne session de routage établie ne prouve pas à elle seule que le trafic utile atteint le service.
Écrire le contrat d’interface avant l’activation
La livraison est la frontière où une équipe remet le trafic à une autre qui en prend la responsabilité. Notez les extrémités publiques des tunnels ou l’interface physique, l’adressage interne, le VLAN éventuel, les familles d’adresses, les voisins de routage, les préfixes autorisés et le MTU. Placez chemins normal, protégé et retour sur le même schéma pour éviter que chaque équipe attribue une étape manquante à l’autre.
Identifiez les responsables de l’interface, de la politique BGP, des règles de filtrage et du service final. Convenez de la fenêtre de changement, des preuves disponibles de chaque côté et d’un contact de reprise. La fiche de livraison doit permettre de distinguer un problème de chemin externe du tunnel, une route interne incorrecte et une application qui ne répond pas.
| Élément | À consigner explicitement | À vérifier à la recette |
|---|---|---|
| Encapsulation ou accès physique | Extrémité réelle, protocole, interface ou VLAN et famille d’adresses. | Le chemin choisi existe et reste joignable par le réseau sous-jacent prévu. |
| Routage interne | Adresses locale et distante, ASN, annonces autorisées et routes reçues. | Les préfixes et routes de retour attendus sont utilisables, pas seulement configurés. |
| Taille des paquets | MTU livré pour chaque chemin et comportement attendu de sa découverte. | Les échanges légitimes petits et plus grands aboutissent. |
| Reprise | Chemin préféré, règles de secours, critères de convergence et responsable de l’annulation. | Le trafic emprunte un chemin fonctionnel après la panne convenue et revient comme prévu. |
Considérer le MTU sur le chemin complet
L’encapsulation consomme une partie de la taille disponible sur le chemin externe. Dans un exemple simple, un chemin IPv4 de 1 500 octets avec un en-tête IPv4 externe de 20 octets et un en-tête GRE de base de 4 octets laisse 1 476 octets au paquet interne. Options GRE, encapsulation supplémentaire ou MTU inférieur du réseau sous-jacent peuvent modifier le résultat. Ce calcul n’est pas une valeur universelle à recopier sur toutes les interfaces GRE.
Utilisez le MTU indiqué dans la fiche de livraison de chaque tunnel. Chemins principal et de secours peuvent exiger des valeurs différentes ; une valeur livrée de 1 452 sur un chemin ne doit pas être remplacée par 1 476 parce qu’un autre chemin l’utilise. Vérifiez à quelle couche correspond la taille rapportée par l’interface ou la capture avant de l’interpréter.
La découverte du MTU et le transport comptent aussi. Un petit ping réussi ne prouve pas que de plus grands échanges TCP ou UDP fonctionneront. De même, l’ajustement du MSS TCP ne concerne que la taille des segments TCP ; il ne corrige pas tous les problèmes UDP ou d’encapsulation. Préservez les messages de contrôle nécessaires au mécanisme de découverte choisi dans la politique de sécurité convenue.
Tester de vrais échanges petits et grands
Choisissez des tests correspondant au service. Vérifiez l’établissement d’une connexion et une opération applicative utile, puis un transfert plus important ou un échange de datagrammes représentatif. Répétez dans les sens et familles d’adresses couverts. Consignez tailles, points de mesure, délais d’attente et compteurs plutôt que de vous limiter à un résultat « joignable ».
Le débit TCP dépend notamment du temps aller-retour, des pertes, des limites du récepteur et du comportement du transport, en plus du débit disponible. L’objectif est d’identifier un problème, pas d’attribuer toute lenteur au filtrage. Croisez la référence applicative et les mesures de transport, et gardez les tests saturant les ressources dans un environnement isolé autorisé.
Distinguer état BGP et transfert utilisable
Une session BGP peut être établie alors que les routes nécessaires sont absentes, refusées par la politique ou moins préférées qu’une autre route. Vérifiez les annonces envoyées et reçues, les préfixes acceptés, les prochains sauts sélectionnés et les entrées de transfert qui en résultent. Si le client a besoin d’une route par défaut, précisez si elle est livrée en BGP ou configurée par une autre méthode convenue.
Testez aussi le retour. Une route statique obsolète ou un chemin incompatible avec un filtre avec état peut donner l’impression que le secours échoue alors que sa session BGP est saine. Vérifiez également la longueur des préfixes : un secours moins spécifique ne remplace pas le trafic toujours attiré par une route plus spécifique encore installée ailleurs. Étudiez la sélection réelle avant de changer les préférences.
Définir la panne que doit couvrir le secours
Gardez le tunnel de secours et sa session de routage activés lorsque l’architecture les prévoit pour une reprise automatique. La préférence du trafic normal et l’éligibilité du secours sont deux questions distinctes. Les politiques des deux extrémités doivent être compatibles, et l’existence d’une session de secours ne documente pas à elle seule la préférence appliquée aux routes reçues.
Exercez le scénario de panne convenu avec les équipes responsables de la production : perte de session, de chemin de tunnel ou de routeur ne sont pas identiques. Deux tunnels sur le même routeur ne démontrent pas une redondance de routeur. Relevez pertes de transfert, comportement applicatif, sélection des routes et restauration ; ne promettez pas une bascule sans perte à partir d’un simple test de joignabilité.
Corréler les deux extrémités et la période de reprise
Utilisez une période commune et indiquez le sens de chaque compteur. Comparez émetteur, interface de tunnel ou de livraison, interface réceptrice, filtre et application finale. Notez l’heure du changement de routage et celle du retour du service utile. Un paquet vu à la sortie d’un composant ne prouve pas son arrivée au suivant : gardez assez de traces pour localiser la rupture.
Après restauration du chemin préféré, vérifiez que la route prévue est sélectionnée, que le secours reste disponible et que les applications établies se comportent comme attendu. Vérifiez aussi les mesures : le collecteur peut avoir repris à un autre moment que le transfert. Conservez configuration finale et résultats de recette avec la fiche de livraison.
Une fiche compacte de livraison et de recette
Ces étapes constituent une recette, pas une autorisation d’interrompre un service actif sans coordination. Séparez tests intrusifs et contrôles courants, et définissez les conditions d’arrêt à l’avance. Le résultat utile est un constat reproductible de la livraison réelle, pas une affirmation générale de validation complète du réseau.
Identifier le service
Consignez interfaces, responsables, préfixes autorisés et configuration versionnée.
Vérifier le transfert normal
Contrôlez routes reçues, prochains sauts choisis, deux sens de trafic et réussite applicative.
Vérifier la taille des paquets
Utilisez le MTU livré de chaque chemin et des échanges petits et grands représentatifs.
Consigner la panne et la restauration
Documentez la panne convenue, la convergence observée, les limites restantes et le résultat de l’annulation.
Questions de livraison
Peut-on utiliser un seul MTU GRE pour tous les tunnels ?
Non. Utilisez la valeur livrée pour chaque chemin complet. Une encapsulation supplémentaire ou un autre réseau sous-jacent peut réduire le MTU interne disponible.
Une session BGP établie prouve-t-elle que le secours fonctionne ?
Non. Vérifiez routes acceptées et sélectionnées, transfert, sens retour et comportement applicatif dans le scénario de panne convenu.
Que doit contenir le rapport final de recette ?
Configuration réelle et responsables, résultats en fonctionnement normal, contrôles de taille des paquets, observations de panne et de reprise, et conditions non testées explicites.
