Blind op uw netwerken vertrouwen
Netwerk: optimalisatie, inzicht en controle
Strategisch & operationeel support
Waarin maakt iunxi het verschil?
We gaan er samen voor!
Techniek staat voorop
Zakelijk netwerk service provider
Wederzijds vertrouwen en respect
We dragen graag ons steentje bij
Klaar voor technologische zorgontwikkelingen
Bakeplus zet haar service prominent online in
Wereldwijd de smaak van kwaliteit garanderen
iunxi beheert het netwerk voor de projecten van Change=
Zorgverleners moeten 24x7 over gegevens beschikken
Iedereen, overal en altijd een mobiele pizzeria op zak
Enabling growth in international business
Geen risico’s meer op het gebied van continuïteit
Sharing = caring
Download informatie
We’ll keep you posted!
Ontdek jouw kansen bij iunxi
De start van jouw carrière!
Why fit in when you can stand out
Werken bij iunxi
Carrière, ambitie en solliciteren
Relax! we've got you covered
Het is vast geen onbekende situatie: volgens de systeembeheerder is de server oké, de applicatiebeheerder zegt dat de applicatie goed werkt en de netwerkbeheerder zegt dat het netwerk prima functioneert. Toch klaagt de gebruiker over problemen met de applicatie. Hoe ga je als netwerkbeheerder met zo’n request aan de slag? Ik start altijd met de volgende stappen:
Op basis van deze vragen weet ik dan alvast welke route het verkeer aflegt en welke rule er moet worden toegevoegd aan de firewall. Dit zijn de basics en dit is precies wat een netwerkspecialist nodig heeft om de firewall toegankelijk te maken voor de betreffende gebruiker. Maar het is echt niet voor het eerst als het daarna nog steeds allemaal niet werkt. Er zijn nu eenmaal legio redenen overgebleven waarom bepaalde applicaties niet meer werken. En dan start de zoektocht.
Het gaat niet helpen als de drie eerder genoemde beheerders naar elkaar gaan wijzen, daar is de gebruiker of de klant niet mee geholpen. Koppen bij elkaar steken en troubleshooten maar. En dat doen we het liefst door het inzetten van captures. Met een capture van het verkeer krijgen we inzichtelijk welke pakketjes er op een bepaald moment op een bepaalde plek voorbij kwamen. Dus zet tcpdump aan, zet Wireshark aan, maak een mirroring-poort op de switch aan en capture het verkeer. Je moet wel goed nadenken waar je die capture gaat maken. Als je een capture op de server kan maken en op de firewall dan heeft het niet veel zin om op alle tussenliggende switches ook captures te gaan maken. Tenzij je een latency probleem wilt troubleshooten. Een overdaad aan captures kan er voor zorgen dat je tijdens de analyse ervan niet meer weet waar je moet kijken.
Bedenk dus wat je gaat troubleshooten? Is het een trage verbinding? Is het een one-way traffic? Werkt de applicatie soms helemaal niet? Er komt een heleboel informatie mee in een capture file. De kunst is om er uit te filteren wat je nodig hebt en je niet te laten afleiden door overtollige informatie die je meekrijgt.
Onlangs zat ik in een troubleshooting sessie met applicatiebeheerders, systeembeheerders en netwerkbeheerders van verschillende partijen. Volgens de klant kon een bepaalde applicatie soms geen verbinding maken. De eerste test was een succesvolle sessie dus die capture hebben we opgeslagen voor latere referentie. Bij de tweede test trad de foutmelding inderdaad op. Na het bekijken van de capture vroeg ik me af of het wel klopte, want ik zag; “0 packet(s) captured”. Nog maar ‘ns een test. Weer de foutmelding en weer “0 packet(s) captured”. Dan weten we bijna zeker dat er op de client dingen mis gaan, dus voordat het verkeer het netwerk opgestuurd wordt. Dan zullen we een capture op de client zelf inzetten en kijken wat de client dan gaat uitsturen. Dat kan bijvoorbeeld een issue zijn met betrekking tot authenticatieservers, nog voordat hij besluit dat er een connectieprobleem is. En zo testen we laag voor laag waar een probleem daadwerkelijk vandaag komt, alleen dan kun je uiteindelijk de juiste oplossing realiseren.
Neem contact op voor een eerste kennismaking en een vrijblijvend advies
Radioweg 3 1324 KW Almere Nederland