Ce qui doit être aligné avant qu’un MX puisse terminer IPsec
Un commit qui accepte la configuration prouve le parseur, pas le chemin. Cinq éléments du tuple de plateforme décident si le service tourne réellement.
La configuration se commit proprement, les interfaces montent, et le tunnel refuse toujours de s’établir. Rien dans le journal ne dit que la plateforme ne sait pas le faire ; simplement, elle ne le fait pas. Sur Junos, IPsec est un service qu’une combinaison précise de châssis, de matériel de services ou de chemin logiciel, et de version, peut assurer, et une page de fonctionnalité décrit la capacité logicielle, non votre équipement. Le tuple doit être vérifié élément par élément, car un résultat de commit ne prouve que le parseur.
Où va réellement le paquet
Le trafic sélectionné pour IPsec doit atteindre le composant qui le chiffre. Sur les plateformes dotées d’un module de services, le flux sélectionné est dirigé vers ce module puis revient au chemin de transfert. Si le module est absent, sous-dimensionné ou non rattaché à l’interface, la configuration existe et aucun paquet n’est jamais traité. Rien dans la sortie du commit ne distingue ce cas d’un état sain.
Les implémentations hébergées en logiciel gardent le travail sur le moteur de routage ou dans du matériel en ligne, avec des limites de ressources très différentes. Un tunnel visible dans la configuration ne vous dit pas lequel de ces chemins le transporte réellement.
Les cinq éléments du tuple
Écrivez la combinaison avant de lire quelque recommandation que ce soit, car un élément peut invalider les autres. Un numéro de pièce qui prenait en charge un service il y a trois ans ne dit rien de la carte et de la version présentes dans ce châssis. Lisez les lignes ci-dessous comme une liste de contrôle, puis renseignez les valeurs que la configuration ne peut pas vous montrer.
| Part | What to record | Where it fails quietly |
|---|---|---|
| Chassis and service hardware | Model plus the installed PIC, MPC or MIC | Card absent or not bound to the interface |
| Implementation | Services card, inline or software path | Configuration accepted, no processing |
| Release | Exact Junos version | The feature arrives in a later build |
| Address families and mode | Outer and inner family, tunnel mode, peer authentication | Half the traffic silently unprotected |
| Entitlement and capacity | Licence state and the workload profile | Ceiling reached only under load |
Les familles d’adresses et la charge de travail sont les deux lignes que l’on saute, et toutes deux sont peu coûteuses à vérifier et coûteuses à découvrir plus tard. Lisez le tuple depuis l’équipement plutôt que depuis un tableur, car une configuration rapporte ce que vous avez demandé et non ce qui est installé. Deux commandes en portent l’essentiel : show chassis hardware nomme la carte réellement installée, et show version donne la version exacte. Ni l’une ni l’autre ne dépend de l’exactitude de la configuration, et c’est tout l’intérêt.
show chassis hardware
show versionLes verrous de version sont de vrais verrous
Le détail de la version n’est pas une formalité. La présentation d’IPsec de Juniper date la prise en charge d’AES-GCM pour les cartes multiservices à Junos 17.3R1, le mode FIPS commençant à 17.4R1. La même fonctionnalité a donc deux seuils selon la façon dont la plateforme est exploitée, et le mode que vous utilisez décide lequel s’applique. Vérifiez le mode avant de vérifier la liste des fonctionnalités.
Lisez les notes de version de la version exacte installée, pas la plus récente documentée. Une capacité apparue dans une build ultérieure ne peut pas être présumée présente dans une antérieure, et une affirmation écrite pour une carte ne se transpose pas à une autre. Copiez la ligne des notes de version dans le dossier de conception pour que l’affirmation porte sa propre source, car une déclaration de prise en charge écrite pour une famille de plateformes n’est pas une déclaration sur le mode que vous exploitez ni sur la carte que vous possédez.
La capacité est une charge de travail, pas un chiffre d’affiche
Un chiffre de débit d’affiche sans ses conditions de mesure n’est qu’un nombre marketing. Les petits paquets coûtent bien plus cher par bit que les gros, les associations simultanées consomment de la mémoire, et tout autre service partageant la carte réduit ce qui reste.
Estimez à partir du trafic que vous attendez : tailles de paquets typiques et dans le pire cas, nombre de pairs, et si cette carte termine aussi du NAT ou un autre service. Laissez ensuite de la marge pour le jour où un chemin porte plus de charge que la conception ne l’avait supposé. Un plan de capacité qui suppose du matériel au repos est un souhait, pas un plan. Si le chiffre compte pour le dossier de décision, mesurez-le une fois sur l’équipement sous une charge représentative et conservez cette mesure avec la conception.
Écrivez la fiche avant la conception
Pour chaque capacité dont la conception a besoin, gardez la référence de plateforme, la documentation correspondant à la version et toute restriction non résolue au même endroit. Lorsqu’une ligne du tuple fait défaut, comparez une autre passerelle déjà approuvée au lieu de reconstruire la conception autour d’une liste d’achats obsolète. La fiche doit indiquer quel système exact exécute la tâche et sous quelles limites.
Ensuite seulement, vérifiez le pair, car la compatibilité de protocole avec l’extrémité distante est la question suivante et ne remplace jamais la prise en charge locale. Un pair qui s’accorde sur les propositions ne peut toujours pas aider un châssis qui ne chiffre jamais un paquet.