Het gebeurt mij vaak dat ik verstrikt raak in een poel van ssh- of telnetsessies en met meerdere routers, switches of firewalls moet communiceren terwijl ik probeer een aantal variabelen te onhouden. Als ik dan door iemand anders lastig gevallen wordt, zal ik kortaf roepen: “Nee helaas, er is geen andere manier.”
Je zou denken dat in deze tijd van sublieme GUI-interfaces en wizards het gemakkelijker zou zijn om OSPF-tunneling door GRE, EIGRP-distributie of BGP-Peering te configureren. Ik bedoel, ze zijn al jáááren beschikbaar – zou het intussen niet veel makkelijker configureerbaar moeten zijn? Het antwoord van netwerkbeheerders ligt voor de hand: Als ieder netwerk gelijk was, dan zou dat inderdaad prima moeten kunnen. Maar omdat ieder netwerk verschilt, kan het helaas niet anders.
De kracht van bovengenoemde protocollen en bijbehorende tools schuilt in hun mogelijkheden en mate waarin ze toepasbaar zijn. Je kunt met Cisco IOS dingen doen die zelfs Cisco nooit voor mogelijk had gehouden, omdat IOS op configuratieniveau een programmeertaal is en niet enkel een router- of switchplatform. De reden waarom de Linux kernel in C geschreven is en niet in een VPL (visuele programmeertaal), is dezelfde waarom er geen eenvoudige GUI voor ingewikkelde routing- en switching configuraties bestaat.
Tools zijn niet zaligmakend
Uiteraard bestaan er SNMP-gebaseerde tools die het eenvoudiger maken om een VLAN-toewijzing van een switchpoort te veranderen of om de regels van een firewall anders te definiëren, maar dat lukt altijd maar tot op zekere hoogte. Uiteindelijk loop je met zulke tools onherroepelijk tegen een muur op, aangezien ze gebouwd zijn om tot op een bepaald niveau te kunnen beheren. Ze halen nooit het maximale uit de mogelijkheden van het onderliggende besturingssysteem.
Complexe configuraties zijn niet het enige die verder gaan dan dat waar deze tools op gebouwd zijn; het debuggen en probleemoplossen vereisen nog meer kennis en vaardigheden. Er bestaat geen Clippy voor ingewikkelde netwerkproblemen en ook niet voor simpeler zaken als een verkeerd geconfigureerde link in een LACP-bundel. Met andere woorden, er bestaat geen vangnet voor netwerkconfiguraties. Geen IDE in de wereld begrijpt dat je twee nummers in een OSPF netwerkstatement niet kunt verhogen of verlagen zonder dit het routingprotocol voor een andere locatie verstoort.
Netwerkbeheerders vertel ik hiermee niets nieuws, maar voor niet-ingewijden kan dit als een verassing komen. Er zijn genoeg IT-professionals die denken dat de configuratie van een 9-poorts switch of het opzetten van een MLPS-netwerk ongeveer hetzelfde gaat als wanneer ze thuis een router van Netgear of Linksys voor wifi configuren. Ik hoor sommigen weleens zeggen dat netwerkbeheerders hun werk moeilijker doen lijken dan dat het in werkelijkheid is omdat ze bang zijn anders hun baan te verliezen. Dat zal af en toe inderdaad gebeuren, maar ik ben er zeker van dat de meeste netwerkbeheerders die door enorme hoeveelheden packet traces moeten worstelen om na te gaan waarom WAN-verkeer soms tijdelijk wegvalt of die te maken krijgen met ingewikkelde VPN-configuraties niet het probleem verergeren om dat hun status ten goede laten komen.
Netwerkbeheer kunnen begrijpen is een jarenlang proces
Wanneer je verder kijkt dan de configuratie interface en de (onoverkoombare) complexiteit van configuratie-elementen als same-security-traffic permit intra-interface, dan blijft het feit dat je moet weten hoe deze tools functioneren. Dit leer je niet zo snel in een vierdaagse cursus. Daarbij heb je – in tegenstelling tot andere IT-banen – geen knop om iets ongedaan te maken. Als je onverhoopt de verbinding naar een locatie op afstand kwijtraakt, zit er soms niets anders op dan naar die plek te moeten gaan.
Ja echt, netwerkbeheer is ingewikkeld. Het is mogelijk een van de lastigste aspecten in hedendaagse IT. Helaas kun je daar weinig aan doen – tot het moment dat iemand gedachtenlezende netwerkapparatuur ontwikkelt.
-
-
Er zijn nog geen reacties.Reageer
Preview