Het is niet het netwerk!

by Philip Gervasi 26 mei 2017

"Het is niet het netwerk!" Als je op mij lijkt, is dat wat je verkondigt bij het oplossen van een toepassingsprobleem. Het enige probleem is echter dat het soms echt aan het netwerk ligt.

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 aangezien de symptomen die ze ervoeren niet voorkwamen 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 logboeken voor de applicatie zelf onthulden niets nuttigs, dus ik kon weinig anders doen dan 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.

Ook belangrijk om in real-time problemen op te lossen is netwerkapparaatinformatie langs het pad, zoals interfacefouten, duplex-mismatches en CRC-fouten. We kunnen een deel hiervan krijgen door handmatig apparaat voor apparaat te gaan, maar dat betekent dat we op de CLI gereed moeten zijn, net als een gebruiker een probleem meldt.
We gebruikten alleen de ad-hocmethoden 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 grove understatement zijn.

Deze keer zat ik er echter bovenop, en net toen de wetenschappers de applicatie weer begonnen te gebruiken, onthulde een pakketopname het probleem meteen. Het probleem was zo simpel, maar niet iets dat bij me opkwam om te controleren.

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 een op intentie gebaseerd geautomatiseerd systeem een ​​redder in nood kan zijn voor netwerktechnici die echte problemen oplossen. Ik had netwerkmonitors, maar ik had een mechanisme nodig dat de netwerkkenmerken continu kon monitoren en vergelijken met basisconfiguraties en geactiveerd door ITSM en monitoringtools om automatisch kritieke informatie op het moment van het incident vast te leggen in het ticket, 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 toepassing aflegt op het moment dat er zich een incident voordoet. Ik kan dit zelfs interactief alleen doen of via een selfservice-bot!

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 en het management was blij dat we deze oude applicatie op de nieuwe locatie aan de praat konden krijgen. Niemand vroeg zich af waarom het zo lang duurde, maar ik denk dat dat alleen 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.

NetBrain's platform stelt netwerkingenieurs in staat om eenvoudig de paden te visualiseren die applicaties door onze netwerken afleggen. Bovendien kan het automatisch de juiste intenties bieden om de ongelooflijk waardevolle netwerkgegevens te verzamelen die we nodig hebben om de vage probleemtickets aan te pakken die onze wachtrijen raken en die met weinig tot geen informatie rechtstreeks op een kaart komen 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.