Goede netwerkdocumentatie: je netwerk moet begrijpelijk zijn zonder de architect

Een netwerk kan jarenlang probleemloos werken zonder dat iemand precies heeft vastgelegd waarom het zo is opgebouwd.

De problemen beginnen meestal zodra er iets moet veranderen.

Een firewall moet worden vervangen. Er komt een nieuw VLAN bij. Een server verhuist. Een IP-range moet worden aangepast. Een nieuwe locatie wordt gekoppeld. Of de persoon die het netwerk jarenlang beheerde, is tijdelijk of permanent niet beschikbaar.

Dan ontstaan vragen zoals:

• Welke apparaten zijn met elkaar verbonden?
• Welke poort gebruikt deze server?
• Welke VLAN’s bestaan er?
• Welke IP-ranges zijn actief?
• Waarom bestaat deze firewallregel?
• Welke systemen zijn afhankelijk van deze configuratie?
• Wat werd er tijdens de vorige wijziging aangepast?

Zonder actuele netwerkdocumentatie wordt een infrastructuurwijziging al snel een onderzoek naar hoe het netwerk toevallig is opgebouwd.

Goede netwerkdocumentatie geeft een organisatie een actueel en begrijpelijk vertrekpunt voor troubleshooting, wijzigingen, uitbreidingen en herstel.

Voor mij is de belangrijkste test daarom eenvoudig:

Kan een andere gekwalificeerde IT-professional het netwerk begrijpen en veilig wijzigen zonder eerst de oorspronkelijke architect te moeten bellen?

Als het antwoord nee is, ontbreekt er een deel van de infrastructuurkennis.

Documentatie is onderdeel van je infrastructuur

Netwerkdocumentatie wordt vaak behandeld als administratie.

Na een installatie wordt ergens een Visio-bestand opgeslagen. Een Excelbestand bevat een lijst met IP-adressen. Een technicus heeft enkele configuraties op zijn laptop staan. De firewallconfiguratie staat op het toestel zelf.

Daarmee is informatie verzameld. Dat betekent nog niet dat de infrastructuur goed gedocumenteerd is.

Goede documentatie moet iemand in staat stellen om de infrastructuur te begrijpen voordat die persoon eraan begint te werken.

Een netwerkdiagram kan bijvoorbeeld tonen dat een firewall verbonden is met een core switch. Op die core switch bevinden zich verschillende VLAN’s. Een andere switch bedient access points, servers en werkstations.

Dat diagram geeft een overzicht van de architectuur. Het verklaart nog niet:

• waarvoor de VLAN’s worden gebruikt;
• welke subnetten actief zijn;
• welke DHCP-ranges bestaan;
• welke statische IP-adressen zijn toegewezen;
• welke switchpoorten trunk- of accesspoorten zijn;
• welke firewallregels verkeer tussen segmenten toestaan;
• welke systemen afhankelijk zijn van specifieke netwerkdiensten.

Een bruikbare documentatieset gaat daarom verder dan een mooie tekening.

Welke netwerkgegevens moet je documenteren?

Een praktische netwerkdocumentatie bestaat uit verschillende lagen. Elke laag beantwoordt andere vragen tijdens beheer, troubleshooting of een wijziging.

1. Fysieke en logische topologie

Begin met een overzicht van de infrastructuur.

Documenteer minimaal:

• firewalls;
• routers;
• core switches;
• access switches;
• Wi-Fi access points;
• servers;
• belangrijke netwerkapparaten;
• internetverbindingen;
• WAN- en VPN-verbindingen;
• relevante cloudverbindingen.

Leg vervolgens vast hoe deze componenten met elkaar verbonden zijn.

Bij een switch is bijvoorbeeld nuttige informatie:

Poort	Verbinding	Type	VLAN
1	Firewall	Trunk	10,20,30,40
2	Server 01	Access	30
3	Access Point 01	Trunk	20,40
4	Printer 01	Access	50

Tijdens een storing kan zo’n overzicht sneller bruikbaar zijn dan een configuratiebestand van enkele honderden regels.

2. VLAN’s en IP-adressering

Een netwerk moet ook logisch beschreven worden.

Bijvoorbeeld:

VLAN	Functie	Subnet	Gateway
10	Management	10.10.10.0/24	10.10.10.1
20	Users	10.10.20.0/24	10.10.20.1
30	Servers	10.10.30.0/24	10.10.30.1
40	VoIP	10.10.40.0/24	10.10.40.1
50	Guest	10.10.50.0/24	10.10.50.1

Zo wordt duidelijk welke adressen beschikbaar zijn en waar nieuwe apparatuur thuishoort.

Dit wordt belangrijker naarmate een organisatie groeit.

Een nieuwe server toevoegen wordt dan een geplande infrastructuurwijziging. Je hoeft eerst niet te onderzoeken welke adressen toevallig nog vrij zijn.

Documenteer daarom ook:

• DHCP-ranges;
• statische adressen;
• DNS-servers;
• gateways;
• publieke IP-adressen;
• gereserveerde adressen;
• relevante routing.

Een configuratiebackup vertelt niet waarom een instelling bestaat

Een backup van een firewallconfiguratie is waardevol. Je hebt die nodig wanneer een apparaat moet worden hersteld of vervangen.

Een configuratiebackup geeft echter niet noodzakelijk de reden achter een instelling.

Stel dat je deze firewallregel aantreft:

VLAN 20 → Server VLAN → TCP 443

Technisch weet je wat de regel doet.

Je weet nog niet waarom die regel bestaat.

Goede documentatie voegt daarom context toe:

Toegang van gebruikers naar de interne applicatieserver voor de bedrijfsapplicatie. Nodig voor alle medewerkers. Beheer door het applicatieteam.

Die context kan jaren later het verschil maken tussen een veilige wijziging en een fout.

Een firewallregel zonder context kan blijven bestaan omdat niemand weet waarvoor ze dient. Een beheerder kan dezelfde reden hebben om de regel niet te verwijderen als om ze niet aan te passen.

Documenteer ook afhankelijkheden

Een netwerkapparaat staat zelden volledig op zichzelf.

Een firewall kan afhankelijk zijn van:

• een internetprovider;
• een publiek IP-adres;
• DNS;
• DHCP;
• certificaten;
• VPN-configuraties;
• authenticatiesystemen;
• specifieke firewallregels.

Een VoIP-platform kan bijvoorbeeld afhankelijk zijn van DNS-records, SIP-connectiviteit, NAT-regels en firewallinstellingen.

In mijn eigen ervaring met 3CX zie je hoe externe toegang, firewallregels en beveiligingsinstellingen met elkaar samenhangen. Een IP-PBX krijgt op publieke poorten te maken met ongewenste SIP- en authenticatiepogingen. Firewallregels en applicatiebeveiliging moeten daarom binnen dezelfde architectuur worden bekeken.

Die afhankelijkheden moeten ergens zichtbaar zijn.

Anders kan iemand een ogenschijnlijk eenvoudige wijziging uitvoeren en pas daarna ontdekken dat een andere dienst ervan afhankelijk is.

Houd een wijzigingshistoriek bij

Een netwerk verandert.

Dat kan een firmware-update zijn, een nieuw VLAN, een aangepaste firewallregel, een nieuwe VPN-verbinding of de verhuis van een server.

Documenteer daarom niet alleen wat vandaag bestaat, maar ook relevante wijzigingen.

Bijvoorbeeld:

Datum	Wijziging	Reden	Uitgevoerd door
12/06/2026	VLAN 40 toegevoegd	Nieuwe VoIP-omgeving	IT
18/06/2026	Firewallregel aangepast	Nieuwe applicatieserver	IT
03/07/2026	Switch 02 vervangen	Hardwaredefect	IT

Bij een incident kan die geschiedenis waardevolle context geven.

Wanneer een probleem op 3 juli begint, is het bijvoorbeeld relevant om te weten welke netwerk- of routingwijzigingen kort daarvoor werden uitgevoerd.

Change history helpt bovendien om later te begrijpen waarom een configuratie werd aangepast.

Test je documentatie tijdens een storing

Een goede test is eenvoudig:

Geef de documentatie aan iemand die het netwerk niet heeft gebouwd.

Vraag:

De server op poort 12 van switch 03 is niet bereikbaar. Waar begin je?

De documentatie moet minstens voldoende informatie geven om de eerste stappen te bepalen.

Een technicus zou bijvoorbeeld moeten kunnen zien:

1. waar switch 03 zich bevindt;
2. waarmee de switch verbonden is;
3. welk VLAN op poort 12 staat;
4. welk apparaat daar verwacht wordt;
5. welk IP-adres dat apparaat gebruikt;
6. via welke gateway het verkeer loopt;
7. welke firewallregels relevant zijn.

Zo ontstaat een logisch startpunt voor troubleshooting.

De documentatie vervangt technische analyse niet. Ze voorkomt wel dat de analyse begint met het reconstrueren van de infrastructuur.

Goede documentatie vermindert afhankelijkheid van één persoon

Voor veel Belgische kmo’s is dit een onderschat risico.

De infrastructuur kan technisch perfect werken terwijl vrijwel alle kennis bij één persoon zit.

Die persoon weet bijvoorbeeld:

“Die firewallregel mag je niet verwijderen.”

Maar nergens staat waarom.

Of:

“Die switchpoort moet trunk blijven.”

Ook zonder documentatie.

Zolang alles werkt, valt die afhankelijkheid nauwelijks op.

Bij een afwezige medewerker, een vertrekkende IT-specialist of een wissel van IT-partner wordt ze plots een operationeel probleem.

In mijn visie is kennisoverdracht daarom onderdeel van infrastructuurarchitectuur.

Een Infrastructure Architect moet volgens mij niet alleen technische kennis hebben. Hij moet die kennis ook kunnen vastleggen en de relatie met de bedrijfscontext begrijpen.

De infrastructuurkennis moet binnen de organisatie beschikbaar blijven.

Als een IT-medewerker of externe leverancier morgen wegvalt, moet een andere gekwalificeerde partij kunnen begrijpen hoe de omgeving werkt en welke wijzigingen veilig kunnen worden uitgevoerd.

Documentatie moet onderdeel zijn van change management

Hier gaat het vaak mis.

Een document dat drie jaar geleden correct was, kan vandaag onvolledig of misleidend zijn.

Een netwerk verandert voortdurend.

Daarom hoort documentatie bij het wijzigingsproces.

Wijziging uitgevoerd? Documentatie aanpassen.

Bij voorkeur gebeurt dat als onderdeel van dezelfde change.

Een change voor een nieuwe VLAN bevat dan niet alleen de configuratie op de firewall en switches. De VLAN-documentatie, het IP-adresplan, het netwerkdiagram en de relevante afhankelijkheden worden eveneens bijgewerkt.

Automatisatie kan hierbij helpen.

Configuratiebackups, versiebeheer en monitoring kunnen wijzigingen in netwerkapparaten detecteren. De exacte tooling hangt af van de omvang en complexiteit van de omgeving.

Een netwerk met tien apparaten heeft andere documentatiebehoeften dan een omgeving met honderden switches, firewalls en access points.

Wat moet een kmo minimaal documenteren?

Voor een typische kmo zou ik minstens de volgende informatie willen kunnen terugvinden.

Architectuur

• netwerkdiagram;
• internetverbindingen;
• firewall;
• switches;
• access points;
• VPN’s;
• belangrijke servers en diensten.

Adresplan

• VLAN’s;
• subnetten;
• gateways;
• DHCP-ranges;
• statische IP-adressen;
• DNS;
• publieke IP-adressen.

Configuratie

• switchpoorten;
• trunk- en accesspoorten;
• routing;
• firewallregels;
• NAT;
• VPN-configuratie;
• Wi-Fi-configuratie;
• belangrijke netwerkservices.

Afhankelijkheden

• internetproviders;
• DNS-provider;
• cloudservices;
• VoIP;
• authenticatie;
• certificaten;
• externe leveranciers.

Historiek

• belangrijke wijzigingen;
• firmware-updates;
• vervangen hardware;
• gewijzigde IP-ranges;
• aangepaste firewallregels;
• relevante incidenten.

Herstel

• configuratiebackups;
• locatie van backups;
• herstelprocedure;
• toegang tot beheeraccounts;
• verantwoordelijke personen.

Wachtwoorden, API-sleutels, private keys en andere geheime gegevens horen niet thuis in een netwerkdiagram of gewone documentatie. Die moeten worden beheerd met een geschikt secrets- of password-managementsysteem.

Documentatie moet bruikbaar zijn voor herstel

Documentatie is ook relevant wanneer infrastructuur moet worden hersteld.

Bij een defecte firewall moet bijvoorbeeld duidelijk zijn:

• welke internetverbindingen aanwezig zijn;
• welke publieke IP-adressen worden gebruikt;
• welke VLAN’s bestaan;
• welke routing actief is;
• welke VPN’s bestaan;
• welke NAT-regels relevant zijn;
• welke diensten afhankelijk zijn van de firewall.

Een configuratiebackup kan een deel van deze informatie bevatten. De architectuurdocumentatie geeft de context waarin die configuratie moet functioneren.

Dat verschil wordt belangrijk wanneer hardware vervangen wordt of een omgeving opnieuw moet worden opgebouwd.

De echte waarde van netwerkdocumentatie

Een netwerkdiagram op zichzelf levert weinig bedrijfswaarde.

De waarde ontstaat wanneer iemand met die informatie een beslissing kan nemen, een storing kan onderzoeken of een wijziging gecontroleerd kan uitvoeren.

Goede netwerkdocumentatie ondersteunt:

• troubleshooting;
• gecontroleerde wijzigingen;
• uitbreiding van de infrastructuur;
• herstel na een incident;
• kennisoverdracht;
• samenwerking met externe IT-partners;
• overdracht bij personeelswijzigingen.

Voor mij is daarom de belangrijkste test heel eenvoudig:

Als je belangrijkste IT-contactpersoon morgen niet beschikbaar is, kan iemand anders dan veilig een wijziging uitvoeren aan je netwerk?

Als het antwoord nee is, ontbreekt er waarschijnlijk meer dan een netwerkdiagram.

Er ontbreekt een deel van de architectuurkennis van je organisatie.

Die kennis hoort niet uitsluitend in het hoofd van één persoon te zitten.