Automatisera ASA-tunnelreset: tre portar innan du tillåter det

Betrakta en automatisk tunnelreset som en återställningsåtgärd med sprängradie, inte som ett schemalagt humörsving. Beslutet framför dig är smalare än verktygen antyder: vilket fel som motiverar den, vilken peer den får röra och vad som får den att stoppa. Har du fel på dessa tre har du byggt en maskin för att radera bevis. Jag har sett en av dessa avfyras var femtonde minut mot en frisk peer under större delen av en vecka, och ingen märkte det eftersom tunneln kom tillbaka varje gång.

Port ett: bevisa att felet finns inne i tunneln

Korrelera färskt tillstånd innan du godkänner något. show crypto ikev2 sa detailed berättar om IKEv2-associationen finns och hur långt förhandlingen kom, och show vpn-sessiondb detail l2l ger sessionsvyn som matchar samma peer. Sedan visar show crypto ipsec sa peer 203.0.113.10 barn-SA:na, encaps- och decaps-räknarna och de selektorer som används. En stigande encaps-räknare med en platt decaps-räknare är ett helt annat problem än ingen association alls.

Kontrollera sedan vad en återuppbyggnad inte kan reparera: en saknad returväg, en MTU som slukar stora paket, en policy som nekar porten efter dekryptering, eller asymmetrisk routning som skickar svaren runt enheten. Att rensa SA:er mot något av detta ger en kort grön blinkning och samma ärende i morgon. Var och en ser ut som en död tunnel från applikationssidan, därför betyder räknarna mer än larmet.

Ta en ögonblicksbild före åtgärden. Anteckna peeren, associationsidentifierarna, räknarna i utlösningsögonblicket och bevisen som utlöste den. En reset som springer före ögonblicksbilden förstör de mest användbara data incidenten hade.

Port två: begränsa omfånget till peeren, aldrig till världen

I ASA-CLI:t är clear crypto ikev2 sa peer 203.0.113.10 och clear crypto ipsec sa peer 203.0.113.10 riktade operationer. Samma kommandon utan peer-argument rensar varje association i kontexten, vilket gör dem till en stavningsvariant och i effekt ett avbrott. Ciscos referens för rensningskommandon skiljer dessa former från statistikvarianten, som nollställer räknare och inte reparerar något. I flerkontextläge verkar kommandot bara på den aktuella kontexten, så automatiseringen måste också veta vilken kontext den är i.

Validera peeren innan kommandot byggs. En tom eller olöst variabel måste fälla jobbet högljutt i stället för att kollapsa till en clear-all, och den kontrollen hör hemma i kod en granskare kan läsa.

Kartlägg sprängradien ärligt. En peer kan bära flera skyddade nätverk, tusentals sessioner och en andra tunnel för hantering, så en peer-begränsad rensning är fortfarande en händelse för flera kunder på en hubb. Kör åtgärden från en hanteringsväg som inte beror på tunneln som återställs. Annars kan automatiseringen inte verifiera sitt eget resultat, och nästa steg är en människa som kör till platsen.

Port tre: nya försök, nedkylning, definierad framgång

Ge jobbet ett lås per peer, en nedkylningsperiod och en hård försöksgräns som räknas från färska observationer. Utan låset rensar två monitorer som utlöses i samma ögonblick samma peer medan omförhandlingen pågår, och var och en drar slutsatsen att den andra misslyckades.

Framgång betyder att associationen är tillbaka och den tillåtna arbetslasten passerar, inte att kommandot återvände utan fel. Prova med samma kontroll som upptäckte felet och bekräfta sedan att barn-SA-räknarna rör sig i båda riktningarna. Ett kommando som avslutas med noll medan tunneln ligger nere är ett övervakningsfel klätt som återställning.

Håll okänt åtskilt från misslyckat. Om telemetrin är inaktuell eller hanteringsvägen oåtkomlig är det ärliga tillståndet okänt, och en försöksbudget bör inte läsa det som tillstånd att avfyra igen.

När den första godkända återställningen inte återställer tjänsten, eskalera med ögonblicksbilden i stället för att loopa. Schemalagda resets är den sämsta versionen av mönstret, eftersom de döljer ett fel i nyckelbyte, rutt eller policy samtidigt som de skär av friska sessioner på en timer.

Ägarskap, en avstängningsknapp och en övning

Namnge en ägare, dokumentera hur appletten eller schemat inaktiveras i ett steg och sätt ett granskningsdatum. En automatisering utan avstängningsväg blir permanent infrastruktur den dag dess författare byter team.

Öva den i laboratorium eller underhållsfönster med peer-valet avsiktligt trasigt, så att du får veta om jobbet misslyckas säkert. Öva sedan framgångsvägen, eftersom ett jobb som bara körs när något är fel inte lär dig något om dess normala beteende.