Ce trebuie să se alinieze înainte ca un MX să poată termina IPsec
Un commit care acceptă configurația dovedește doar parserul, nu calea. Cinci părți ale tuplului de platformă decid dacă serviciul chiar rulează.
Configurația se comitează curat, interfețele urcă, iar tunelul tot refuză să se stabilească. Nimic din jurnal nu spune că platforma nu poate face asta; pur și simplu nu o face. Pe Junos, IPsec este un serviciu pe care doar o anumită combinație de șasiu, hardware de servicii sau cale software și versiune îl poate executa, iar o pagină de funcționalitate descrie capacitatea software-ului, nu aparatul dumneavoastră. Tuplul trebuie verificat parte cu parte, pentru că rezultatul unui commit dovedește doar parserul.
Unde ajunge de fapt pachetul
Traficul selectat pentru IPsec trebuie să ajungă la componenta care îl criptează. Pe platformele cu un modul de servicii, fluxul selectat este direcționat către acel modul și apoi revine pe calea de forwarding. Dacă modulul lipsește, este subdimensionat sau nu este legat de interfață, configurația există și niciun pachet nu este procesat vreodată. Nimic din ieșirea commit-ului nu distinge acest caz de unul sănătos.
Implementările găzduite în software păstrează munca pe motorul de rutare sau în hardware inline, cu limite de resurse foarte diferite. Un tunel vizibil în configurație nu vă spune care dintre aceste căi îl transportă de fapt.
Cele cinci părți ale tuplului
Scrieți combinația înainte de a citi orice recomandare, pentru că o parte le poate invalida pe celelalte. Un număr de piesă care susținea un serviciu acum trei ani nu spune nimic despre placa și versiunea din acest șasiu. Citiți rândurile de mai jos ca pe o listă de verificare, apoi completați valorile pe care configurația nu vi le poate arăta.
| 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 |
Familiile de adrese și sarcina de lucru sunt cele două rânduri pe care oamenii le sar, iar ambele sunt ieftin de verificat și scump de descoperit mai târziu. Citiți tuplul din echipament, nu dintr-un tabel de calcul, pentru că o configurație raportează ce ați cerut, nu ce este instalat. Două comenzi poartă cea mai mare parte: show chassis hardware numește placa instalată efectiv, iar show version dă versiunea exactă. Niciuna nu depinde de faptul că configurația este corectă, și exact acesta este punctul.
show chassis hardware
show versionPragurile de versiune sunt praguri reale
Detaliul versiunii nu este o formalitate. Prezentarea generală IPsec de la Juniper datează suportul AES-GCM pentru plăcile multiserviciu la Junos 17.3R1, cu modul FIPS începând de la 17.4R1. Aceeași funcționalitate are deci două praguri în funcție de modul în care este operată platforma, iar modul în care rulați decide care se aplică. Verificați modul înainte de a verifica lista de funcții.
Citiți notele de versiune pentru versiunea exact instalată, nu pentru cea mai recentă documentată. O capacitate apărută într-un build ulterior nu poate fi presupusă prezentă într-unul anterior, iar o afirmație scrisă pentru o placă nu se transferă la alta. Copiați rândul din notele de versiune în registrul de proiectare, astfel încât afirmația să-și poarte propria sursă, pentru că o declarație de suport scrisă pentru o familie de platforme nu este o declarație despre modul în care rulați sau placa pe care o aveți.
Capacitatea este o sarcină de lucru, nu un titlu
O cifră de debit din titlu fără condițiile ei de măsurare este un număr de marketing. Pachetele mici costă mult mai mult pe bit decât cele mari, asocierile simultane consumă memorie, iar orice alt serviciu care împarte placa reduce ce rămâne.
Estimați din traficul pe care îl așteptați: dimensiuni tipice și în cel mai rău caz ale pachetelor, numărul de peer-i și dacă placa termină și NAT sau alt serviciu. Apoi lăsați marjă pentru ziua în care o cale va duce mai multă încărcare decât a presupus proiectarea. Un plan de capacitate care presupune hardware inactiv este o dorință, nu un plan. Dacă cifra contează pentru cazul de business, măsurați-o o dată pe echipament sub o încărcare reprezentativă și păstrați măsurătoarea împreună cu proiectarea.
Scrieți registrul înainte de proiectare
Pentru fiecare capacitate de care are nevoie proiectarea, păstrați referința platformei, documentația potrivită versiunii și orice restricție nerezolvată într-un singur loc. Unde un rând al tuplului nu se susține, comparați un gateway separat aprobat în loc să reconstruiți proiectarea în jurul unei liste de cumpărături depășite. Registrul ar trebui să spună care sistem exact face treaba și în ce limite.
Abia apoi verificați peer-ul, pentru că compatibilitatea protocolului cu capătul îndepărtat este următoarea întrebare și nu înlocuiește niciodată suportul local. Un peer care este de acord cu propunerile tot nu poate ajuta un șasiu care nu criptează niciodată un pachet.