Een storing welke lijkt te zijn veroorzaakt door een foute config? Wat nu?

Het komt regelmatig voor dat lijkt alsof iets "ineens" niet meer werkt. Er is echter vrijwel altijd een oorzaak aan te wijzen welke verantwoordelijk is voor het feit dat het netwerk of systeem niet meer werkt. In sommige gevallen is dit makkelijk te doen: Een storing bij een internet provider, een server welke kortsluiting heeft gehad of een kabel welke los zit. In veel gevallen ligt de problematiek echter minder voor de hand en is een configuratie fout het issue. In dit document beschrijven we hoe je te werk kunt gaan om hierachter te komen. Belangrijk is hierbij om in gedachten te houden dat een storing een afwijking is op een situatie welke wel heeft gewerkt.

Het stappenplan:
1 Reproduceer/ Bevestig
2 Veilig stellen data/configuratie (s)
3 Verifieer en vergelijk configuraties
4 Logging controleren
5 Geavanceerde traces uitvoeren
6 Onderbouwde change voorstellen
7 Herstel / Correctie
8 En nu voorkomen in de toekomst

1- Reproduceer/ Bevestig
Bevestig / Reproduceer het incident en log informatie omtrent de bevindingen. Kortom: probeer hetgeen dat word gemeld door de eindgebruiker of (interne) klant zelf ook te zien/ervaren en leg de bevindingen vast (feitelijkheden).

2- Veilig stellen data / configuratie(s)
Maak een backup van het apparaat en de configuraties. Door voordat incident herstel plaats vind een backup te maken is het altijd mogelijk naar deze situatie terug te keren maar ook om op enig later moment onderzoek te doen naar de oorzaak.

Veelgebruikte tools:
Cisco  > ASDM Launcher
Mikrotik  > WinBox
Fortinet  > Fortigate UI

3- Verifieer en vergelijk de configuraties

  • Controleer de time stamps, written by, software version en cryptohashes.
  • Vergelijk de configuraties van running config en startup in Notepadd++ met de Compare addonn.
  • Vergelijk de configuraties van de huidige running config met de runnig config van de laatst werkende situatie.
  • Vergelijken betekend dat je de verschillen identificeerd én verklaard. Onverklaarbare verschillen zijn reden tot escalatie. Vaak is dit de stap waarin duidelijk word welke wijzigingen zijn gedaan en een verklaring geven voor de verstoring.

4- Logging controleren

  • Controleer de logging van gebruikers toegang;
  • Controleer de logging van changes;
  • Controleer tickets in het ticketing/change management systeem. Mogelijk dat één van je collega’s is bezig geweest.

Allen met name gericht op activiteiten rond de periode dat het incident is ontstaan.

5- Geavanceerde traces
Voer geavanceerde traces uit met IP, TCP, UDP of over verschillende poorten om het probleem verder te specificeren of te herleiden. Sla de resultaten op. Maak geen aannames maar test het en leg het vast.

6- Onderbouwde change voorstellen

7- Herstel / Correctie

  1. Communicatie start werkzaamheden
  2. Backup van de huidige configuratie
  3. Toevoegen / Correctie config
  4. Backup van de gewijzigde configuratie
  5. Communicatie werkzaamheden uitgevoerd

8- En nu voorkomen in de toekomst

Opgelost? Helemaal top! Maar nu wel direct vooruit denken en kijken/overleggen of het mogelijk is dit probleem/verstoring in de toekomst te voorkomen.

Terug naar overzicht

Deel via:

Blijf op de hoogte!

Meld u aan voor onze maandelijkse business update.