Wat er moet kloppen voordat een MX IPsec kan beëindigen
Een commit die de configuratie accepteert bewijst de parser, niet het pad. Vijf onderdelen van de platformtuple bepalen of de dienst echt draait.
De configuratie commit schoon, de interfaces komen omhoog, en de tunnel weigert nog steeds tot stand te komen. Niets in het log zegt dat het platform dit niet kan; het doet het eenvoudigweg niet. Op Junos is IPsec een dienst die een specifieke combinatie van chassis, servicehardware of softwarepad en release kan uitvoeren, en een functiepagina beschrijft de capaciteit van de software, niet uw apparaat. De tuple moet deel voor deel worden gecontroleerd, want een commitresultaat bewijst alleen de parser.
Waar het pakket werkelijk naartoe gaat
Verkeer dat voor IPsec is geselecteerd, moet het onderdeel bereiken dat het versleutelt. Op platforms met een servicemodule wordt de geselecteerde flow naar die module geleid en keert daarna terug naar het doorstuurpad. Ontbreekt de module, is hij te klein of niet aan de interface gebonden, dan bestaat de configuratie en wordt er geen enkel pakket verwerkt. Niets in de commit-uitvoer onderscheidt dat geval van een gezond geval.
Implementaties in software houden het werk op de routing engine of in inline hardware, met heel verschillende resourcelimieten. Een tunnel die in de configuratie zichtbaar is, vertelt u niet welk van die paden hem werkelijk draagt.
De vijf onderdelen van de tuple
Schrijf de combinatie op voordat u enige aanbeveling leest, want één onderdeel kan de andere ongeldig maken. Een onderdeelnummer dat drie jaar geleden een dienst ondersteunde, zegt niets over de kaart en de release in dit chassis. Lees de rijen hieronder als checklist en vul daarna de waarden in die de configuratie u niet kan tonen.
| 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 |
De adresfamilies en de werklast zijn de twee rijen die mensen overslaan, en beide zijn goedkoop te controleren en duur om later te ontdekken. Lees de tuple van het apparaat en niet uit een spreadsheet, want een configuratie rapporteert wat u hebt aangevraagd, niet wat er is geïnstalleerd. Twee commando's leveren het meeste: show chassis hardware noemt de kaart die werkelijk is geplaatst, en show version geeft de exacte release. Geen van beide hangt af van of de configuratie juist is, en dat is precies het punt.
show chassis hardware
show versionRelease-drempels zijn echte drempels
Het release-detail is geen formaliteit. Het IPsec-overzicht van Juniper dateert AES-GCM-ondersteuning voor multiservicekaarten op Junos 17.3R1, waarbij de FIPS-modus begint bij 17.4R1. Dezelfde functie heeft dus twee drempels, afhankelijk van hoe het platform wordt bedreven, en de modus waarin u draait bepaalt welke geldt. Controleer de modus voordat u de functielijst controleert.
Lees de release notes voor de exact geïnstalleerde versie, niet de nieuwste gedocumenteerde. Een capaciteit die in een latere build kwam, mag niet als aanwezig worden verondersteld in een eerdere, en een uitspraak die voor de ene kaart is geschreven, gaat niet over op een andere. Kopieer de regel uit de release notes naar het ontwerpverslag, zodat de bewering haar eigen bron meedraagt, want een supportverklaring die voor een platformfamilie is geschreven, is geen verklaring over de modus die u draait of de kaart die u hebt.
Capaciteit is een werklast, geen kopregel
Een doorvoercijfer in de kop zonder de meetomstandigheden is een marketinggetal. Kleine pakketten kosten per bit veel meer dan grote, gelijktijdige associaties kosten geheugen, en elke andere dienst die de kaart deelt, vermindert wat overblijft.
Schat op basis van het verkeer dat u verwacht: typische en slechtste pakketgroottes, het aantal peers en of die kaart ook NAT of een andere dienst beëindigt. Laat daarna ruimte voor de dag waarop één pad meer belasting draagt dan het ontwerp aannam. Een capaciteitsplan dat uitgaat van stille hardware is een wens, geen plan. Als het cijfer ertoe doet voor de businesscase, meet het dan één keer op het apparaat onder een representatieve belasting en bewaar die meting bij het ontwerp.
Schrijf het verslag vóór het ontwerp
Houd voor elke capaciteit die het ontwerp nodig heeft de platformreferentie, de bij de release passende documentatie en elke onopgeloste beperking op één plek. Waar een rij van de tuple niet slaagt, vergelijk dan een apart goedgekeurd gateway in plaats van het ontwerp opnieuw op te bouwen rond een verouderde boodschappenlijst. Het verslag moet zeggen welk exact systeem het werk doet en onder welke grenzen.
Controleer pas daarna de peer, want protocolcompatibiliteit met de andere kant is de volgende vraag en nooit een vervanging voor lokale ondersteuning. Een peer die het eens is over de voorstellen kan een chassis dat nooit een pakket versleutelt, nog steeds niet helpen.