Tunnlar faller, återställningen tar nittio sekunder och timern för död peer är satt till tio, så timern får skulden. Det resonemanget hoppar över tre faser som inträffar efter detekteringen och vanligtvis tar större delen av tiden. Detektering av livstecken märker tystnaden; därefter tar peerval, autentisering, ruteinstallation och applikationens återanslutning var sin tur. Att korta den första fasen kan inte korta de andra, och det kan tillföra oro till ett system som redan kämpade.

Fyra faser, varav du kan ta tid på en

Skriv återställningen som fyra händelser med tidsstämplar. Felet blir observerbart: den sista användbara skyddade trafiken och den första misslyckade begäran. Den ansvariga mekanismen reagerar: detektering av livstecken, en rutmonitor eller en annan dokumenterad utlösare. Alternativet blir användbart: peerval, autentisering, en ny association och en rutt som faktiskt bär den avsedda trafiken. Applikationen återhämtar sig: en ny operation lyckas och det som pågick har ett definierat utfall.

IKEv2:s regler för livstecken beskriver bevis om peeren och dess utbyten och säger ingenting om en databas eller filtjänst bakom den peeren. Att läsa en livstecken-timeout som en hälsokontroll för hela vägen är felet som startar timerjakten.

Varför timern är det minst intressanta talet

Konfigurerade värden är inte utbytbara enheter. Vissa är återförsöksintervall, vissa är övre gränser för ett försök och vissa körs samtidigt med andra. Att addera dem ger ett tal som ser ut som en prognos och beter sig som ett rykte. Läs dokumentationen för fältet du är på väg att röra och notera vilken av de tre typerna det är.

Andra faser är inte alls timers. En återanslutnings-backoff, en interaktiv autentiseringsprompt eller en klient som bara omvärderar sin konfiguration vid omstart kan var och en dominera avbrottet medan varje protokolltimer sitter bekvämt lågt.

Mät fasen som faktiskt är långsam

Fånga felet en gång, med tidsstämplar på båda sidor, och jämför sedan de fyra händelserna i stället för protokollets egna räknare. Ett ordentligt utfört observationsfönster slår en månads trimning.

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

Om den alternativa slutpunkten aldrig svarar hjälper ingen timerändring, eftersom onåbarhet inte är ett detekteringsproblem. Om ny säkerhetstillstånd bildas snabbt men rutten fortfarande pekar på den döda vägen är problemet ruteinstallation, och ännu en livsteckenjustering tillför bara oro.

Alternativet måste redan vara användbart

En säkerhetskopia som definieras i en konfiguration är inte en säkerhetskopia som fungerar. Den måste vara nåbar från klientens nuvarande nätverk, kunna autentisera samma identitet och vara tillåten att bära samma trafik under samma policy. Upptäcker du någon av dessa tre luckor under ett avbrott blir timerdiskussionen irrelevant. Testa alternativet medan den primära är frisk, för det är den enda gången du kan läsa båda loggarna sida vid sida.

Förbered alternativet i förväg, testa det medvetet medan den primära är frisk och notera vilken av de fyra faserna som tar tiden. Det är den registreringen som gör nästa ändring till en mätning i stället för en gissning.

Oro vid återgång och administrationsvägen

Att återställa den primära är ett separat beslut. En aggressiv återgång kan avbryta arbete som redan hade återhämtat sig på säkerhetskopian, och en fladdrande rutt kan se ut som en instabil tunnel när det verkliga felet är en rutt som ständigt svänger mellan två likvärdiga alternativ.

Två rutter med lika kostnad utan preferens är den vanliga källan till synligt fladder, eftersom varje monitor reagerar på den andras val. Bestäm vilken rutt som föredras under normala förhållanden och gör den preferensen explicit i konfigurationen i stället för att lämna den till rutordningen. Definiera önskat återgångsbeteende och vem som äger det, i förväg. Behåll de tidigare inställningarna och en oberoende administrationsväg, eftersom en ändring som tar bort din egen åtkomst under ett avbrott förvandlar en nätverksincident till ett besök på plats.

Upprepa sedan samma arbetsbelastning och jämför samma fyra tidsstämplar. En kortare återställning som fortfarande låter applikationen vänta på samma saknade rutt eller inloggning är inte framsteg, det är en annan siffra på samma graf.

Relaterade artiklar