Cosa deve allinearsi prima che un MX possa terminare IPsec
Un commit che accetta la configurazione dimostra il parser, non il percorso. Cinque parti della tupla di piattaforma decidono se il servizio gira davvero.
La configurazione esegue il commit senza errori, le interfacce salgono e il tunnel continua a rifiutarsi di stabilirsi. Nulla nel registro dice che la piattaforma non è in grado di farlo; semplicemente non lo fa. Su Junos, IPsec è un servizio che una combinazione precisa di chassis, hardware dei servizi o percorso software, e versione può erogare, e una pagina di funzionalità descrive la capacità del software, non il vostro apparato. La tupla va verificata parte per parte, perché il risultato di un commit dimostra solo il parser.
Dove va davvero il pacchetto
Il traffico selezionato per IPsec deve raggiungere il componente che lo cifra. Sulle piattaforme con un modulo dei servizi, il flusso selezionato viene indirizzato a quel modulo e poi torna al percorso di inoltro. Se il modulo manca, è sottodimensionato o non è associato all’interfaccia, la configurazione esiste e nessun pacchetto viene mai elaborato. Nulla nell’output del commit distingue quel caso da uno sano.
Le implementazioni ospitate nel software mantengono il lavoro sull’engine di routing o in hardware inline, con limiti di risorse molto diversi. Un tunnel visibile nella configurazione non vi dice quale di questi percorsi lo stia davvero trasportando.
Le cinque parti della tupla
Scrivete la combinazione prima di leggere qualsiasi raccomandazione, perché una parte può invalidare le altre. Un codice di parte che supportava un servizio tre anni fa non dice nulla sulla scheda e sulla versione in questo chassis. Leggete le righe seguenti come lista di controllo, poi compilate i valori che la configurazione non può mostrarvi.
| 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 |
Le famiglie di indirizzi e il carico di lavoro sono le due righe che la gente salta, ed entrambe costano poco da verificare e molto da scoprire tardi. Leggete la tupla dall’apparato invece che da un foglio di calcolo, perché una configurazione riporta ciò che avete chiesto, non ciò che è installato. Due comandi ne coprono gran parte: show chassis hardware indica la scheda realmente inserita e show version dà la versione esatta. Nessuno dei due dipende dal fatto che la configurazione sia corretta, ed è proprio questo il punto.
show chassis hardware
show versionLe soglie di versione sono soglie reali
Il dettaglio della versione non è una formalità. La panoramica di IPsec di Juniper data il supporto AES-GCM per le schede multiservizio a Junos 17.3R1, con la modalità FIPS a partire da 17.4R1. La stessa funzione ha quindi due soglie a seconda di come viene gestita la piattaforma, e la modalità in cui operate decide quale si applica. Verificate la modalità prima di verificare l’elenco delle funzioni.
Leggete le note di rilascio della versione esatta installata, non della più recente documentata. Una capacità arrivata in una build successiva non si può presumere presente in una precedente, e un’affermazione scritta per una scheda non si trasferisce a un’altra. Copiate la riga delle note di rilascio nel registro di progetto, così che l’affermazione porti con sé la propria fonte, perché una dichiarazione di supporto scritta per una famiglia di piattaforme non è una dichiarazione sulla modalità che operate né sulla scheda che avete.
La capacità è un carico di lavoro, non un titolo
Una cifra di throughput da titolo senza le sue condizioni di misura è un numero di marketing. I pacchetti piccoli costano molto più per bit di quelli grandi, le associazioni simultanee consumano memoria, e ogni altro servizio che condivide la scheda riduce ciò che resta.
Stimate dal traffico che vi aspettate: dimensioni dei pacchetti tipiche e nel caso peggiore, numero di peer e se quella scheda termina anche NAT o un altro servizio. Poi lasciate margine per il giorno in cui un percorso porterà più carico di quanto il progetto abbia ipotizzato. Un piano di capacità che presuppone hardware inattivo è un desiderio, non un piano. Se la cifra conta per il caso di business, misuratela una volta sull’apparato sotto un carico rappresentativo e conservate quella misura insieme al progetto.
Scrivete il registro prima del progetto
Per ogni capacità di cui il progetto ha bisogno, tenete il riferimento di piattaforma, la documentazione allineata alla versione e ogni restrizione irrisolta in un unico posto. Dove una riga della tupla non regge, confrontate un gateway separato già approvato invece di ricostruire il progetto intorno a una lista della spesa obsoleta. Il registro dovrebbe dire quale sistema esatto svolge il lavoro e entro quali limiti.
Solo dopo verificate il peer, perché la compatibilità di protocollo con l’estremità remota è la domanda successiva e non sostituisce mai il supporto locale. Un peer che concorda sulle proposte non può comunque aiutare uno chassis che non cifra mai un pacchetto.