Als netwerkspecialist moet ik al jaren uitleggen wat ik nu precies doe. Mensen komen in hun verbeelding niet verder dan een kabeltje, een stekkertje en een poortje. Maar ook op grotere schaal, in een bedrijfsomgeving, is het netwerk een grote onbekende. Dit heeft tot gevolg dat 'het netwerk' telkens zijn onschuld moet bewijzen of dat 'het netwerk' (te) laat bij een project wordt betrokken.
Het probleem begint al bij de definitie en de invulling van de begrippen 'het netwerk', netwerkbeheer, netwerkspecialist. Omdat men vaak als uitgangspunt de eindgebruiker voor ogen heeft (niet onlogisch overigens) beschouwd men alles dat zich achter de wall-outlet bevindt als 'het netwerk'. It-specialisten kunnen verder kijken en weten dat de wereld achter de wall-outlet bestaat uit een complexiteit van fileservers, webservers, database-servers, san, loadbalancers, firewalls, switches, routers, trafficshapers etc..die allemaal verbonden zijn door koper- en glasbekabeling. De reden dat de onzichtbare centrale IT infrastructuur toch wordt bestempeld als 'het netwerk' heeft te maken met het gegeven dat de eindgebruiker zijn netwerkkabeltje ziet 'verdwijnen' in de muur en voor het gemak vervolgens aanneemt dat het kabeltje vanaf dat punt doorloopt tot aan een onbekend eindpunt. Bekend zijn de typische eindgebruikeruitspraken zoals 'Ik heb al mijn bestanden op het netwerk gezet' of 'het netwerk is heel erg traag vandaag'.
Ernstiger vind ik het wanneer vanuit de (it-)organisatie zelf er slordig wordt omgesprongen met de definitie van 'het netwerk'. Als je als netwerkspecialist op zoek gaat naar een nieuwe baan of een nieuwe opdracht dan is het volslagen zinloos om als zoekterm het woord 'netwerkspecialist' in te voeren op bijvoorbeeld Monsterboard. Je staat versteld van het grote aantal vacatures met de titel 'Netwerkspecialist', waarin uiteindelijk wordt gevraagd om iemand met kennis en ervaring van Microsoft servers, SQL, databases, et cetera..met als laatste opmerking 'CCNA is een pré'. Maar ook onder accountmanagers van it-detacheerders worden de termen 'systeembeheer' en 'netwerkbeheer' door elkaar gegooid; ik heb dit menigmaal moeten uitleggen toen ze weer aan mijn bureau stonden.
Grens trekken
Een duidelijk onderscheid tussen 'netwerk' en 'systeem' is goed te maken als je kijkt naar het OSI-model. Je kan dan de grens trekken tussen laag-4 en laag-5. De onderste vier lagen zijn 'netwerk'; vanaf laag-5 is het 'systeem'. In concreto: bekabeling, switches, routers, firewalls, loadbalancers, vlan's, IP-adressen zijn het domein van de netwerkspecialist; fileservers, database-servers, SAN, authenticatie-servers..et cetera zijn het domein van de systeemmensen (die op hun beurt ook weer hun eigen specialisten hebben: Windows, Unix/Linux, DBA, Citrix, HP-Nonstop, et cetera).
De eerlijkheid gebiedt wel te zeggen dat er grijze gebieden zijn: hoort een SAN-switch bij 'netwerk' of is het dermate specialistisch dat het bij 'storage' hoort ? Verder zijn bijvoorbeeld de huidige loadbalancers in staat om tot op 'laag-7' te schakelen en zijn ze in feite geëvolueerd tot geavanceerde 'proxy servers'. Toch valt een loadbalancer doorgaans nog steeds onder 'netwerk'.
Maar zelfs onder it-specialisten blijft het netwerk een 'black box'. De netwerkspecialisten hebben doorgaans meer kennis en hands-on ervaring van servers en de daarop draaiende besturingssystemen dan dat de systeemspecialisten hun weg kunnen vinden in de configuratie van een router. Ik vermoed dat het onder andere heeft te maken met het gegeven dat een server, oneerbiedig gezegd, een sterk doorontwikkeld werkstation is waar iedereen zich iets bij kan voorstellen; op de spreekwoordelijke verjaardagsfeestjes kan je het begrip server uitleggen als een 'zeer krachtige pc die is gespecialiseerd op de uitvoering van één taak'.
Daarentegen is er onder systeemspecialisten relatief weinig hands-on ervaring met de configuratie van netwerkcomponenten, op een enkeling na die een Cisco CCNA-cursus heeft gevolgd. De kennis van netwerken beperkt zich tot de configuratie van de (Ethernet-)interface(s) van de server en bijbehorende ip-parameters. Meestal is dit ook voldoende om een dienst of een applicatie werkend te maken, maar er zijn situaties dat een gebrek aan enige basiskennis van netwerken tot problemen leidt.
Afwijkend pad
Een veelvoorkomende situatie is dat een systeembeheerder een statische ip-route heeft ingesteld op de server. Gevolg is dan dat het netwerkverkeer een afwijkend pad kan gaan volgen en dat er geen verbinding tot stand komt tussen zender en ontvanger. Uit onwetend wordt er vervolgens een melding gemaakt richting netwerkbeheer dat 'iets wordt tegengehouden' in het netwerk. Een ander voorbeeld is een geavanceerde server omgeving die de mogelijkheid heeft om een interne virtuele switch te kunnen draaien. Hoewel er dan geen gebruik wordt gemaakt van deze functionaliteit, blijven de 'default' instellingen ongewijzigd en zend de server-interface zogenaamde 'BPDU's' uit naar de netwerkswitch waar het op aangesloten zit. De netwerkswitch denkt dat er een andere switch achter het poortje zit (het detecteert BPDU's) en kan dan vanuit beveiligingsoogpunt de poort automatisch dichtzetten. Raad eens wat er gebeurt: de servermensen maken een call aan naar Netwerkbeheer om het op te lossen. Als netwerkspecialist in een netwerkbeheeromgeving heb je veelal te kampen met een 'omgekeerde bewijslast': je moet veel tijd en energie steken om aan te tonen dat het toch echt niet aan het netwerk ligt maar dat er op systeemniveau fouten zitten in de configuratie. Omdat er weinig kennis is en omdat het netwerk wordt gezien als een schimmige wolk, is het makkelijk om de aanname te doen dat er 'iets in het netwerk is dichtgezet'. Op vele tekeningen van it-infrastructueren wordt een netwerk ook echt als een wolkje weergegeven!
De naïeve gedachte dat het netwerk niet meer is dan een switchpoort en een IP adres wordt helemaal pijnlijk bij projecten. Het komt nog te vaak voor dat de netwerkspecialisten pas bij een project worden betrokken op het moment dat de uitrol en implementatiefase begint. Dan pas komen kwesties aan bod zoals: bandbreedtebehoefte, performance, redundantie, segmentering, verkeersstromen, security en Quality-of-Service. Vraagstukken die het vervolgens noodzakelijk maken om het infrastructuurontwerp van het betreffende project grondig te herzien. Het gevolg is dan een onnodige extra doorlooptijd, maar ook dat 'het netwerk' op het kritieke pad komt te liggen en dat de mismatch tussen project en netwerkinfrastructuur moet worden opgelost door alsnog 'specials' te maken aan de netwerkzijde.
De netwerkwereld blijft een aparte tak van sport binnen de it; daar kunnen we weinig aan veranderen. We zullen meer en beter moeten communiceren over de toegenomen complexiteit van een modern netwerk en nieuwe functionaliteiten die in toenemende mate in een netwerkinfrastructuur worden belegd. Andere onderwerpen waarover we meer over moeten vertellen zijn beschikbaarheid, redundantie en security en de hoofdrol die het netwerk daarin speelt. Wellicht is dan de invoering van IPv6 de uitgelezen kans om ons werk zichtbaarder te maken.
Dag Bart, de Computable site is geen Web 2.0. Zelf artikelen aanpassen gaat niet, zien wanneer er op je artikel gereageerd wordt ook niet. En deze reactie tast direct mijn gemiddelde aan, let maar op het aantal sterren.
Van de week was ik bij een klant die ook een spook in zijn netwerk had. Als je een switch maakte van wired naar wireless raakte hij zijn internet verbinding kwijt. Zal het hele verhaal niet opschrijven, maar uiteindelijk bleek het dat de UPC router standaard 100 Mac adressen toestond. Door de switch kwam deze wat boven de 100 uit en werd die verbinding dus niet tot stand gebracht. Hier zijn wat uren in gaan zitten en soms is het best lastig isoleren wat nu de veroorzaker is omdat het gedrag `willekeurig` leek. Overigens had UPC het binnen vijf minuten naar 250 Mac adressen gebracht, maar als zij niet gebeld waren en een onervaren iemand had opgenomen waren er veel duurdere beslissingen gemaakt.
Wat IPv6 betreft. Ik vermoed dat IPv6 helemaal niet doorbreekt of veel later dan je zou verwachten op basis van de feiten. Er zijn namelijk alternatieven die technisch minder goed zijn, maar praktisch gezien wel zijn te realiseren (NAT scenario). Een ander groot nadeel van IPv6 vind ik dat ze zo lastig te onthouden zijn.
Ik ben zelf niet zo thuis in netwerken en hier wringt nu juist de schoen. Een goed werkend netwerk is belangrijk maar als het puntje bij het paaltje komt is het een noodzakelijk kwaad. Heel storend dat de netwerk specialist er dan te laat bij wordt gehaald.
Beste Bart,
Lees regelmatig je artikelen, deze is ook weer treffend! Probeer op de verjaardag maar eens uit te leggen dat je je binnen het vak ‘netwerken’ ook nog kunt specialiseren op routing, switching, hardware, datacenter, bekabeling, enzovoorts enzovoorts!
Nog een klantvoorbeeld: Unix server met twee interfaces in verschillende netwerksegmenten. Statische routingtable op de server bleek niet correct geconfigureerd door Unix-beheerder, wat ik samen met hem opgelost heb. Het management concludeerde: netwerkprobleem.
Laten wij als netwerkspecialisten proberen duidelijk te blijven communiceren!
Is het zo erg wanneer een specialist het netwerk als een black box beschouwt?
Ik zit momenteel in India, en via het netwerk van het hotel (waarvoor ik een userid/password heb) en een VPN verbinding (nog een userid/password) kan ik het gros van mijn werk op mijn omgeving in Nederland doen.
Zet ik nu de pet van applicatiespecialist op, die zijn werk zowel in India als Nederland kan doen, is het netwerk op dit moment voor mij een black box.
Als netwerkbeheerder mag je dit overigens als compliment beschouwen; ik merk nauwelijks verschil of ik op kantoor, thuis of bijna 7000 km van huis zit.
Overigens ken ik ook de andere kant van het verhaal (uit de tijd dat ik zelf nog in de netwerkhoek zat). Als netwerkgroep kregen we de schuld van de slechte performance van een client-server applicatie. Een stevige portie debuggen leverde uiteindelijk op dat de server zoveel bevestigingen vroeg aan de client bij het opbouwen van het scherm (bestaande uit een matrix structuur met honderden cellen) dat de network latency (afstand Engeland-Nederland) maal het aantal cellen inderdaad meer dan 10 seconden bedroeg. Of we dit als netwerkgroep niet op konden lossen….
(het antwoord wat we gegeven hebben is dat we Engeland niet dichterbij wilde hebben, dus de latency niet konden verkleinen)
Tot slot nog even over wat men zoekt aan functies, en wat aangeboden wordt: binnen de ICT sector zien we al langer devaluatie van bepaalde titels/rollen en functies.
Iemand met 2 certificaten van microsoft noemt zich specialist; iemand met 25 jaar ervaring in een hybride omgeving van IBM Mainframe met TCP/IP ook. …. wie is nu de specialist?
Helaas zijn titels in de IT niet beschermd, iedereen mag zich (al dan niet terecht) specialist, consultant en/of architect noemen. Dit maakt het helaas soms lastig het kaf van het koren te scheiden….
so be it.
Ik ben het met je eens dat de netwerkbeheerders meer kennis en bepaalde vaardigheden hebben dan de meeste systeembeheerders. Misschien komt dit doordat het netwerk een abstracte eigenschap heeft (Geen Windows GUI). Maar dit verschil zal langzamerhand verdwijnen of verminderd worden.
Met de ontwikkelingen die ICT heeft meegemaakt (zoals virtualisatie) en de komende tijd nog gaat meemaken is er bijna geen grenzen meer te bekennen tussen verschillende objecten in een ICT landschap. Alles wordt steeds meer in elkaar verweven. Wanneer je servers, desktop, DMZ, load balancer (Citrix Netscaler) etc allemaal virtueel zijn dan zal de grote onbekende wolk niet allen boven je netwerk hangen maar ook andere objecten van je ICT landschap in zich opnemen.
Spijtig dat er in sommige situaties (en indirect) bij het oplossen van een probleem om een omgekeerde bewijslast gevraagd wordt! Maar dat heeft meer te maken met de aanpak om tot een oplossing te komen dan je functie als netwerkspecialist.
De verwevenheid van verschillende objecten vraagt om andere aanpak voor het oplossen van een probleem. Een aanpak met directe samenwerking, structuur, duidelijke communicatie etc tussen verschillende beheerders.
In dit geval moet de oorzaak en de oplossing in de “hele keten” opgezocht worden dan alleen in de losse onderdelen zoals netwerk of switches.
Dit is juist iets wat ik sterk in je artikel gemist heb.
Gentlemen,
Dank voor jullie uitgebreide en inhoudelijke en goed gefundeerde reacties!
Ik ben het in grote lijnen met jullie eens: het geeft niet dat het netwerk een blackbox is maar het onbekende is dan ook vaak de makkelijke zondebok..
Verder zeer eens dat oplossingen in de keten moeten worden gezocht en in de samenwerking. Echter in mijn artikel is het meer een constatering vanuit de jarenlange ervaringen dan dat het een beschrijving is van een oplossing..je kan het zien als de ‘klaagzang’ van de netwerkspecialist. Het is daarbij nog steeds zo dat organisaties klassiek zijn ingericht naar het model van netwerkbeheer, systeembeheer en applicatiebeheer met daartussen administratieve muren van ‘assignment groups’. Er komt een ticket binnen met daarin “iets over IP adressen..”; hup we zetten het door naar het netwerk-oplosteam..Het is dan lastig om niet in een welles-nietes discussie te komen…Ook een veel gehoorde: “ik kan mijn server niet pingen; dus het ligt aan het netwerk”. Er wordt dan niet meer de moeite genomen om ook de eigen instellingen eens na te gaan om die minstens uit te kunnen sluiten…maar goed; dit is geen plek om uitgebreid te klagen…
Nogmaals dank voor jullie feedback !
Houden jullie die black box ook niet zelf in stand? Ben de laatste dagen ook weer druk in de weer met beheerders, architecten en dergelijke, en ook al loop ik 10 jaar mee in de IT….het blijft abracadabra.
Daarnaast denk ik ook dat het te maken heeft, dat in veel organisaties de mensen die bezig zijn met die black box en het netwerk altijd uitgaan van wat er niet mogelijk is? In plaats van dat de gebruiker centraal gesteld wordt. Dit draagt ook in grote mate bij aan hoe er tegen “jullie” werk wordt aangekeken.
Desalniettemin een prima artikel, maar had even het gevoel te moeten reageren!
In het artikel een feest van herkenbare situaties (ja, ik ben er ook zo een)
Dat er naar “het netwerk” wordt gewezen heeft volgens mij een aantal oorzaken.
– de meeste OS en applicaties geven bij veel fouten een melding over een begrip wat vaak met een netwerk wordt geassocieerd.
– helaas zijn er in deze OS en applicaties vaak geen hulpmiddelen aanwezig die wel een correcte foutanalyse kunnen doen.
De eindgebruiker maakt gebruik van een dienst.
vaak is er geen overzicht van de infrastructuurketen die deze dienst ondersteunt. Er zijn geen hulpmiddelen deze keten op fouten, beschikbaarheid, beveiliging etc automatisch kan analyseren.
(er zijn wel een hoop tools die beweren dat ze dit kunnen, maar daar is vaak een aparte extra beheerder voor nodig)
De gebruikers van het netwerk (ook ict-afdelingen) willen graag het netwerk als een NUTSvoorziening afnemen. De interesse wat er dan in zo’n black box gebeurt neemt daardoor af. (behalve als er iets mis is)
Als netwerk beheerders staan we voor de uitdaging om goed te communiceren wat wel onze verantwoordelijkheid is en vooral wat niet.
Zoals ReZa al opmerkte, met virtualisatie (aan de server zijde) zie je al een hoop veranderen. Het netwerk is namelijk niet meer het enige wat ketens verbindt.
Ik vermoed dat de volgende black-box waarvan veel mensen niet weten wat er in gebeurt al naar boven komst (het san)
vVoral bij de ontluikende convergentie van LAN/WAN en SAN zal het onbegrip van de hogere OSI lagen in eerste instantie toenemen.
Het onderkennen dat alle applicaties/diensten in een keten werken, en daarom veel samenwerking van alle specialisten in die keten nodig is, is een begin.
het standaardiseren van automatiseren van die koppelvlakken (op alle processen) is stap 2
Het erkennen van een netwerk als een voorziening die blijvend in ontwikkeling is, is iets wat de beheerders/ontwikkelaars zelf moeten oppakken. Dit is soms iets van de bedrijfscultuur.
Het proactief deelnemen van netwerkmensen in ontwikkeltrajecten kan veel problemen voorkomen.(als de resources beschikbaar zijn)
Zoals ook Robbert waarschijnlijk meemaakt, ook bij netwerkspecialisten is het niet altijd vanzelfsprekend dat ze makkelijk aansluiting vinden bij jouw begrippenkader. Serverbeheerders denken in doosjes, netwerkbeheerders in lijnen.
@Robbert: het probleem van het netwerk vs gebruiker is dat de behoefte van de individuele gebruiker oneindig is: altijd en overal en naar alles kunnen connecteren met een hoge snelheid. Wij, de netwerkmensen, moeten de gebruikers tegen elkaar beschermen en hen ook behoeden voor de gevaren waravan ze niet altijd bewust zijn…In dat geval moeten we vaak de “niet mogelijk” kaart uitspelen en de slechte boodschap berngen. De analogie van de politie-agent is wel op zijn plaats: niet leuk als je ergens niet in mag rijden of dat je je aan de snelheidslimiet moet houden…Maar die agent legt dit ook op aan al die andere (weg)gebruikers dus als individuele gebruiker heb je daar dan weer baat van..Of wat dacht je van “voor eigen bestwil”..Of de ‘ zeurende’ tandarts die zegt dat je beter moet poetsen..of De Belastingdienst “leuker kunnen we het niet maken”.
@Nico: wat een geweldige analyse op een hoger abstractieniveau. Je kan er zo een nieuwe artikel van maken dat aansluit op het mijne; jij geeft al veel aanzetten tot de oplossing. Ik ga ook zeker je ‘onliner’ onthouden (“Serverbeheerders denken in doosjes, netwerkbeheerders in lijnen”).
Bedankt voor je bijdrage