Was stimmen muss, bevor ein MX IPsec terminieren kann
Ein Commit, der die Konfiguration annimmt, beweist den Parser, nicht den Pfad. Fünf Teile des Plattform-Tupels entscheiden, ob der Dienst wirklich läuft.
Die Konfiguration wird sauber committet, die Schnittstellen kommen hoch, und der Tunnel weigert sich weiterhin aufzubauen. Nichts im Protokoll sagt, dass die Plattform das nicht kann; sie tut es einfach nicht. Auf Junos ist IPsec ein Dienst, den eine bestimmte Kombination aus Chassis, Service-Hardware oder Softwarepfad und Release leisten kann, und eine Feature-Seite beschreibt die Fähigkeit der Software, nicht Ihre Box. Das Tupel muss Teil für Teil geprüft werden, denn ein Commit-Ergebnis beweist nur den Parser.
Wohin das Paket tatsächlich geht
Für IPsec ausgewählter Verkehr muss die Komponente erreichen, die ihn verschlüsselt. Auf Plattformen mit einem Services-Modul wird der ausgewählte Flow zu diesem Modul gelenkt und kehrt danach in den Weiterleitungspfad zurück. Fehlt das Modul, ist es zu klein dimensioniert oder nicht an die Schnittstelle gebunden, existiert die Konfiguration und kein einziges Paket wird verarbeitet. Nichts in der Commit-Ausgabe unterscheidet diesen Fall von einem gesunden.
Softwarebasierte Implementierungen behalten die Arbeit auf der Routing Engine oder in Inline-Hardware, mit sehr unterschiedlichen Ressourcengrenzen. Ein in der Konfiguration sichtbarer Tunnel sagt Ihnen nicht, welcher dieser Pfade ihn tatsächlich trägt.
Die fünf Teile des Tupels
Schreiben Sie die Kombination auf, bevor Sie irgendeine Empfehlung lesen, denn ein Teil kann die anderen entwerten. Eine Teilenummer, die vor drei Jahren einen Dienst unterstützte, sagt nichts über die Karte und das Release in diesem Chassis. Lesen Sie die folgenden Zeilen als Checkliste und tragen Sie dann die Werte ein, die die Konfiguration Ihnen nicht zeigen kann.
| 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 |
Die Adressfamilien und die Arbeitslast sind die beiden Zeilen, die man überspringt, und beide sind billig zu prüfen und teuer, wenn man sie später entdeckt. Lesen Sie das Tupel vom Gerät statt aus einer Tabelle, denn eine Konfiguration meldet, was Sie angefordert haben, nicht was installiert ist. Zwei Befehle tragen das meiste davon: show chassis hardware nennt die tatsächlich gesteckte Karte, und show version gibt das genaue Release. Beide hängen nicht davon ab, ob die Konfiguration richtig ist, und genau das ist der Punkt.
show chassis hardware
show versionRelease-Gates sind echte Gates
Das Release-Detail ist keine Formalität. Die IPsec-Übersicht von Juniper datiert die AES-GCM-Unterstützung für Multiservices-Karten auf Junos 17.3R1, wobei der FIPS-Modus ab 17.4R1 beginnt. Dieselbe Funktion hat also zwei Schwellen, je nachdem wie die Plattform betrieben wird, und der Modus, in dem Sie laufen, entscheidet, welche gilt. Prüfen Sie den Modus, bevor Sie die Funktionsliste prüfen.
Lesen Sie die Release Notes für die exakt installierte Version, nicht für die neueste dokumentierte. Eine Fähigkeit, die in einem späteren Build kam, kann in einem früheren nicht als vorhanden vorausgesetzt werden, und eine für eine Karte geschriebene Aussage überträgt sich nicht auf eine andere. Kopieren Sie die Zeile aus den Release Notes in das Design-Record, damit die Aussage ihre eigene Quelle trägt, denn eine für eine Plattformfamilie geschriebene Support-Aussage ist keine Aussage über den Modus, den Sie betreiben, oder über die Karte, die Sie haben.
Kapazität ist eine Arbeitslast, keine Schlagzeile
Eine Schlagzeilen-Durchsatzzahl ohne ihre Messbedingungen ist eine Marketingzahl. Kleine Pakete kosten pro Bit weit mehr als große, gleichzeitige Assoziationen verbrauchen Speicher, und jeder weitere Dienst, der sich die Karte teilt, verringert den Rest.
Schätzen Sie aus dem Verkehr, den Sie erwarten: typische und ungünstigste Paketgrößen, die Anzahl der Peers und ob diese Karte auch NAT oder einen anderen Dienst terminiert. Lassen Sie dann Luft für den Tag, an dem ein Pfad mehr Last trägt, als das Design angenommen hat. Ein Kapazitätsplan, der ruhende Hardware voraussetzt, ist ein Wunsch und kein Plan. Wenn die Zahl für den Business Case zählt, messen Sie sie einmal auf der Box unter einer repräsentativen Last und bewahren Sie diese Messung beim Design auf.
Erst das Record, dann das Design
Halten Sie für jede Fähigkeit, die das Design braucht, die Plattformreferenz, die release-passende Dokumentation und jede ungelöste Einschränkung an einer Stelle. Wo eine Zeile des Tupels scheitert, vergleichen Sie ein separates genehmigtes Gateway, statt das Design um eine veraltete Einkaufsliste herum neu zu bauen. Das Record sollte sagen, welches exakte System die Aufgabe erledigt und unter welchen Grenzen.
Erst danach prüfen Sie den Peer, denn die Protokollkompatibilität mit der Gegenseite ist die nächste Frage und niemals ein Ersatz für lokale Unterstützung. Ein Peer, der den Vorschlägen zustimmt, kann einem Chassis, das nie ein Paket verschlüsselt, trotzdem nicht helfen.