"De configuratie staat toch op het apparaat zelf." Dat klopt, tot het apparaat stuk is. Of tot niemand meer weet waarom die ene ACL-regel er staat, wie dat VLAN heeft toegevoegd en of de situatie op de switch nog overeenkomt met wat er in de documentatie staat. De configuratie van een router of switch is code: regels tekst die bepalen wat je netwerk doet. Maar waar software allang in versiebeheer leeft, hangt netwerkconfiguratie vaak nog ergens tussen het apparaat zelf, een verouderde tekstdump en het geheugen van een beheerder.
Wat er misgaat zonder
- Vervangen wordt nabouwen — gaat een switch kapot, dan moet zijn configuratie ergens vandaan komen. Zonder actueel archief wordt dat reconstrueren uit oude dumps, screenshots en geheugen, midden in een storing.
- "Wie heeft dit aangepast, en waarom?" — de vraag die bij elk vreemd gedrag als eerste komt, en zonder geschiedenis onbeantwoordbaar is.
- Documentatie en werkelijkheid lopen uiteen — wat je dénkt dat er draait en wat er draait zijn twee verschillende dingen, en het verschil zie je pas als het pijn doet.
Elke wijziging een commit
Wij lossen dit op door de configuratie van al onze netwerkapparatuur automatisch in git vast te leggen; de open-sourcetool Oxidized logt daarvoor periodiek op elk apparaat in en haalt de actuele configuratie op. Het wezenlijke zit in wat er daarna gebeurt: alleen als de configuratie is veranderd, ontstaat er een commit. De geschiedenis is daardoor geen stapel nachtelijke kopieën, maar een logboek van echte wijzigingen, elk met een tijdstip.
- Diffs in plaats van dumps — je ziet niet dát er iets veranderd is, maar wát: die twee regels in de ACL, dat ene VLAN erbij. Twee volledige configuraties naast elkaar leggen hoeft nooit meer.
- Herstel in minuten — een vervangend apparaat krijgt de laatst bekende configuratie, geen reconstructie.
- Wijzigingen die opvallen — een commit die niet bij een aangekondigde wijziging hoort, is meteen zichtbaar. Dat vangt de vergeten handmatige aanpassing, en in het ergste geval een aanpassing die niemand van ons gedaan heeft.
Waarom git, en niet een back-upmap
Een map met gedateerde tekstdumps bewaart hetzelfde en beantwoordt toch niets: welke van de veertig bestanden verschilt van gisteren, en waarin? Versiebeheer is gebouwd voor precies die vragen; geschiedenis, verschillen en herkomst zijn er de kernfuncties, niet iets wat je er zelf omheen scriptet. Het sluit ook aan op hoe wij de rest inrichten: ons beleid en ISMS leven al in git, met dezelfde audittrail. Configuratie, software en beleid krijgen zo één antwoord op de vraag "wat is er wanneer veranderd".
De eerste vraag bij elke storing
"Wat is er veranderd?" is de openingsvraag van elk storingsonderzoek. Zonder versiebeheer is het antwoord een gok; met versiebeheer is het een logboekregel, binnen een minuut gevonden. En voor wie moet aantonen dat wijzigingsbeheer op orde is, voor een auditor of onder de zorgplicht van NIS2, is het archief zelf het bewijs: elke wijziging aan het netwerk, vastgelegd op het moment dat hij plaatsvond.
Zo beheren wij ons netwerk
Dit is geen dienst die we verkopen, maar de manier waarop we werken: het netwerk achter onze colocatie en IP-transit wordt zo beheerd, net als de beheertoegang ernaartoe. Wil je weten wat dat betekent voor de infrastructuur waar jouw apparatuur of verkeer op draait: neem contact op.