“Het ligt niet aan het netwerk!” Als je net als ik bent, is dat wat je beweert bij het oplossen van een applicatieprobleem. Het enige probleem: na een zorgvuldige netwerkdiagnose ligt het soms echt aan het netwerk.
Een grap onder netwerkingenieurs is dat wanneer er iets mis is met iets dat met een computer te maken heeft, iedereen de firewall de schuld geeft. Ja, dit is misschien grappig, maar het is ook een van de meest frustrerende dingen voor een netwerktechnicus om een netwerkdiagnose uit te voeren. We zijn goed in het laten werken van pings over een netwerk, maar het oplossen van problemen met een toepassing kan aanvoelen als het maken van foto's in het donker.
Nog maar een paar maanden geleden werd ik getagd in een e-mailketen die was gestart door een van onze ontwikkelaars om te helpen bij het oplossen van problemen met een verouderde applicatie die wordt gebruikt voor het monitoren van wetenschappelijke instrumenten. De applicatie werkte prima op de hoofdlocatie, maar dit was een nieuwe site en er klopte iets niet.
Ik was verrast om te horen dat ze al tijd hadden besteed aan het oplossen van problemen met de applicatie voordat ze mij binnenhaalden. Dat was leuk, maar het suggereerde ook dat het probleem echt het netwerk zou kunnen zijn.
Ik controleerde de basisprincipes, zoals toegangslijsten en MTU-instellingen, maar omdat de symptomen die ze ervoeren niet optraden op de hoofdsite, wist ik niet waar ik op moest letten. Beide sites waren identiek geconfigureerd, dus naar mijn mening had dit moeten werken. De logbestanden van de applicatie zelf onthulden niets nuttigs, dus ik kon heel weinig netwerkdiagnose doen, behalve wachten tot het opnieuw gebeurde en in realtime inloggen op apparaten.
Het vastleggen van relevante informatie op het moment van een incident kan buitengewoon moeilijk zijn, vooral met een netwerk van honderden switches en tientallen routers en firewalls. Het volgen van het pad van laag 2 dat een toepassing neemt, is bijvoorbeeld bijna onmogelijk omdat de traceroute alleen naar laag 3 kijkt. En zelfs als we naar de laag 3-informatie voor een stroom kijken, is het maar in één richting tegelijk.
Belangrijk bij het in realtime oplossen van problemen is ook informatie over netwerkapparaten onderweg, zoals interfacefouten, duplex-mismatches en CRC-fouten. We kunnen een deel hiervan verkrijgen door handmatig apparaat voor apparaat te gaan, maar dat betekent dat we aan de slag moeten zijn CLI gereed op het moment dat een gebruiker een probleem meldt.
We gebruikten alleen de ad-hoc netwerkdiagnosemethoden die we hadden en gingen door met het oplossen van problemen door de apparaten uit productie te nemen om tests uit te voeren terwijl ze rechtstreeks waren aangesloten. De applicatie werkte perfect. Nadat alles weer in productie was genomen, ging het mis. Zeggen dat ik gefrustreerd was, zou een grof understatement zijn.
Deze keer zat ik er echter bovenop, en net toen de wetenschappers de applicatie weer begonnen te gebruiken, bracht een pakketopname het probleem meteen aan het licht. Het probleem was zo eenvoudig, maar het kwam niet bij me op om dit te controleren tijdens de netwerkdiagnose.
Ik wist niet hoe de applicatie moest werken, en door al onze telefonische vergaderingen kwam ik erachter dat de ontwikkelaars gewoon hun best deden om een oud programma te onderhouden dat ze niet hadden geschreven.
Het gebruikte multicast en niemand wist het.
Dit is waar geautomatiseerde, op intentie gebaseerde netwerkdiagnose een redder in nood kan zijn voor netwerkingenieurs die problemen uit de echte wereld oplossen. Ik had netwerkmonitors, maar ik had een mechanisme nodig dat de netwerkkenmerken continu kon monitoren en deze kon vergelijken met basisconfiguraties en dat kon worden geactiveerd door ITSM en monitoringtools om automatisch kritische informatie op het moment van het incident in het ticket vast te leggen, inclusief de netwerkdiagnose . Gelukkig kan ik een intentie gebruiken, een uitvoerbare automatiseringseenheid zonder code, die stappen bevat om automatisch gegevens te leveren over routeringstabellen, interfacestatistieken, kortstondige netwerkinformatie en zelfs het pad dat een applicatie aflegt op het moment dat zich een incident voordoet. Ik kan dit zelfs interactief alleen doen of via een selfservicebot!
De hoofdsite was de enige plaats waar de applicatie werd gebruikt, dus dit was nooit een gedachte. Maar nu het werd gebruikt over de grenzen van laag 3 naar een andere locatie, moesten het netwerk en de applicatie multicast correct hebben geconfigureerd om de communicatie te laten werken.
Het herstel was relatief eenvoudig vergeleken met de netwerkdiagnose, en het management was blij dat we deze eeuwenoude applicatie op de nieuwe locatie werkend konden krijgen. Niemand vroeg zich af waarom het zo lang duurde, maar ik denk dat dat alleen maar komt omdat men al begreep dat dit een oude applicatie was.
Hoewel ik de buitensporig lange tijd tot oplossing van me afschudde, wenste ik ook dat er een gemakkelijkere manier was om de gegevens vast te leggen die ik nodig had op het moment dat het probleem zich voordeed. In feite zou zo'n tool van onschatbare waarde zijn voor het oplossen van dagelijkse problemen met netwerkactiviteiten.
NetBrainMet zijn platform kunnen netwerkingenieurs eenvoudig de paden visualiseren die applicaties door onze netwerken volgen. Bovendien kan het automatisch de juiste intenties bieden om de ongelooflijk waardevolle netwerkdiagnose te verzamelen die we nodig hebben om de vage probleemtickets in onze wachtrijen aan te pakken die met weinig tot geen informatie rechtstreeks op een kaart staan met behulp van Auto Intent.
Uiteindelijk was het oplossen van mijn applicatieprobleem geen rocket science. Ik heb geleerd dat veel problemen waarmee we worden geconfronteerd, vaak het gevolg zijn van veelvoorkomende problemen. Het vinden van het probleem, ook al is het eenvoudig, kan echter erg moeilijk zijn zonder de juiste hulpmiddelen.
Intent-Based Network Automation geef ons, als netwerkingenieurs, de mogelijkheid om te creëren dynamische netwerkmapping en overlay-intenties voor real-time diagnose en probleemoplossing van het netwerk, connectiviteit en applicatieprestaties die ons uiteindelijk helpen om voor eens en voor altijd te bewijzen dat het niet het netwerk is, behalve natuurlijk wanneer het dat wel is.