Tunelurile cad, recuperarea durează nouăzeci de secunde, iar timerul pentru peer mort este setat la zece, așa că timerul este învinovățit. Acest raționament omite trei etape care au loc după detectare și care consumă de obicei cea mai mare parte a timpului. Detectarea vitalității observă liniștea; apoi selecția peerului, autentificarea, instalarea rutei și reconectarea aplicației își iau fiecare rândul. Scurtarea primei etape nu poate scurta celelalte și poate adăuga agitație unui sistem care deja se lupta.

Patru etape, dintre care una poate fi cronometrată

Scrieți recuperarea ca patru evenimente cu marcaje temporale. Defectul devine observabil: ultimul trafic protejat util și prima cerere eșuată. Mecanismul responsabil reacționează: detectarea vitalității, un monitor de rută sau un alt declanșator documentat. Alternativa devine utilizabilă: selecția peerului, autentificarea, o asociație nouă și o rută care transportă efectiv traficul dorit. Aplicația se recuperează: o operație nouă reușește, iar ceea ce era în curs are un rezultat definit.

Regulile de vitalitate ale IKEv2 descriu dovezi despre peer și schimburile sale și nu spun nimic despre o bază de date sau un serviciu de fișiere din spatele acelui peer. A citi un timeout de vitalitate ca pe o verificare de sănătate a întregii căi este greșeala care începe vânătoarea de timere.

De ce timerul este cel mai puțin interesant număr

Valorile configurate nu sunt unități interschimbabile. Unele sunt intervale de reîncercare, altele sunt limite superioare ale unei încercări, iar altele rulează simultan cu celelalte. Adunarea lor produce un număr care pare o predicție și se comportă ca un zvon. Citiți documentația câmpului pe care urmează să îl atingeți și notați care dintre cele trei tipuri este.

Alte etape nu sunt deloc timere. O întârziere de reconectare, o solicitare de autentificare interactivă sau un client care își reevaluează configurația doar la repornire pot fiecare domina întreruperea în timp ce fiecare timer de protocol stă confortabil jos.

Măsurați etapa care este într-adevăr lentă

Capturați defectul o dată, cu marcaje temporale pe ambele părți, apoi comparați cele patru evenimente în locul contoarelor protocolului însuși. O fereastră de observare făcută corect valorează mai mult decât o lună de reglaje.

ip -4 route get 203.0.113.10
tcpdump -ni any -c 20 "esp or icmp"

Dacă punctul final alternativ nu răspunde niciodată, nicio schimbare a timerului nu ajută, pentru că inaccesibilitatea nu este o problemă de detectare. Dacă noua stare de securitate se formează rapid, dar ruta indică în continuare calea moartă, problema este instalarea rutei, iar o altă ajustare a vitalității adaugă doar agitație.

Alternativa trebuie să fie deja utilizabilă

O copie de rezervă definită într-o configurație nu este o copie de rezervă care funcționează. Trebuie să fie accesibilă din rețeaua actuală a clientului, să poată autentifica aceeași identitate și să fie permisă să transporte același trafic în aceeași politică. Dacă descoperiți oricare dintre aceste trei lacune în timpul unei întreruperi, discuția despre timer devine irelevantă. Testați alternativa cât timp primarul este sănătos, pentru că este singurul moment în care puteți citi ambele jurnale unul lângă altul.

Furnizați alternativa în avans, testați-o deliberat cât timp primarul este sănătos și notați care dintre cele patru etape consumă timpul. Acea înregistrare este ceea ce face următoarea schimbare o măsurătoare în loc de o presupunere.

Agitația la revenire și calea de administrare

Restabilirea primarului este o decizie separată. O revenire agresivă poate întrerupe munca ce se recuperase deja pe copia de rezervă, iar o cale care oscilează poate părea un tunel instabil atunci când defectul real este o rută care continuă să oscileze între două opțiuni egale.

Două căi cu cost egal și fără preferință sunt sursa obișnuită a oscilației vizibile, pentru că fiecare monitor reacționează la alegerea celuilalt. Decideți care cale este preferată în condiții normale și faceți acea preferință explicită în configurație în loc să o lăsați în seama ordinii rutelor. Definiți dinainte comportamentul de revenire dorit și cine îl deține. Păstrați setările anterioare și o cale de administrare independentă, pentru că o schimbare care vă elimină propriul acces în timpul unei întreruperi transformă un incident de rețea într-o vizită la fața locului.

Apoi repetați aceeași încărcare de lucru și comparați aceleași patru marcaje temporale. O recuperare mai scurtă care lasă în continuare aplicația să aștepte aceeași rută sau autentificare lipsă nu este progres, este un alt număr pe același grafic.

Articole similare