Problemen met het gevreesde intermitterende netwerkprobleem oplossen

by Paul Campbell 14-2019-XNUMX

Hoeveel van jullie hebben een probleem opgelost, een ondersteuningszaak behandeld of een klantoproep gehad in verband met een intermitterend netwerkprobleem? Ik zou me veel voorstellen. De meeste mensen in een of andere vorm van een IT-gerelateerd veld zijn meer analytisch ingesteld. Met een analytische geest denken we vaak dat als het blijft gebeuren, we het moeten kunnen herhalen. In de meeste gevallen heb je gelijk. Maar aangezien ik al bijna twintig jaar verschillende vormen van IT-werk doe, kan ik je verzekeren dat dit niet altijd het geval is.

Intermitterende netwerkproblemen zijn gebeurtenissen die niet zo gemakkelijk kunnen worden gerepliceerd. Ze komen ook niet op hetzelfde tijdstip van de dag of hebben altijd dezelfde gebruikers. Als iemand die dit soort problemen op verschillende posities heeft aangepakt, kan ik je vertellen dat ze vreselijk zijn om tegen te komen. Je voelt je hulpeloos en je twijfelt soms aan je gezond verstand!

NetBrain stelde ons in staat om het probleem te lokaliseren en ergens te beginnen. Om elk probleem op te lossen, moet je het probleem begrijpen, en zonder NetBrain, Ik weet niet zeker of we zo snel zouden hebben begrepen waar we moesten beginnen.

Waargebeurd verhaal: Af en toe een storing zes weken na een upgrade
Ik had ooit een klant die aan het upgraden was van een verouderde Cisco-omgeving naar een nieuwere Cisco Nexus-omgeving, toen de 7K/5K/2K-architectuur uitkwam en de markt stormenderhand veroverde. Een deel van onze adviesopdracht omvatte een netwerkbeoordeling voordat we begonnen. Waarom? We wilden zorgen voor een naadloze overgang naar de nieuwe architectuur en controleren of elke basis was gedekt. We streven naar geen uitval, downtime of enige vorm van impact. Er gebeuren echter dingen waar we soms geen controle over hebben. (Voorafschaduwing, misschien?)

Na voltooiing van de omschakeling waren alle tests geslaagd en waren alle teams tevreden. Het was geen week, twee weken of drie weken later dat we werden teruggebeld. Het was ongeveer zes weken in hun standaardactiviteiten toen de klant belde, bezorgd dat ze periodieke storingen hadden en onze hulp nodig hadden om te begrijpen wat er mis was. Het was een probleem dat schijnbaar willekeurige applicaties en willekeurige gebruikers trof. Zoals de meeste mensen dachten we niet meteen dat de nieuwe datacenterkern hun probleem was. Waarom? Het waren zes weken! De ervaring leerde ons dat de meeste problemen binnen 24 uur of hooguit een week zouden zijn opgetreden en opgemerkt, als die er al waren.

Waarom pakken NMS Solutions het probleem niet op?
Wat is het eerste dat we deden? Ontstoken NetBrain en voerde een bijgewerkte ontdekking van het netwerk opnieuw uit en vergeleek het met onze post-installatiekaart. Een exact duplicaat, zelfs niet één CLI-opdracht verschilde tussen de twee scans. We begonnen te bespreken dat er niets was veranderd sinds we vertrokken, waardoor de IT-directeur en VP zich op hun gemak voelden dat hun team het niet had verknoeid. (Het gaf ons ook een goed gevoel.) Maar het hielp niemand om zich goed te voelen bij het oplossen van het probleem - een intermitterende gremlin die verbroken verbindingen en zwarte gaten in het verkeer leek te veroorzaken.

NetBrain kan met slechts één klik vrijwel alle netwerkgegevens vergelijken tussen live-status en historische snapshots.

We spraken af ​​om in de buurt te blijven en een grootschalige kaart van de campus, het datacenter en een paar afgelegen locaties 's nachts in monitormodus achter te laten, in totaal zo'n 16 uur. Toen we de volgende dag terugkwamen, merkten we dat sommige van de doorlopende gemiddelden sterk bleven fluctueren voor de tweede Nexus 7K. Eindelijk hadden we een plek om te beginnen! We zijn begonnen met hun oplossingen voor netwerkbeheer, waarbij Splunk, SolarWinds en een handvol andere tools betrokken waren. Ze zagen de vorige nacht geen problemen. Hebben ze die gemist of waren de drempels te laag?

Teruggaan naar NetBrain, merkten we dat het verkeer in en uit de tweede Nexus 7K leek te fluctueren, wat niet overeenkwam met het normale inkomende/uitgaande verkeerspatroon dat te zien was op de eerste Nexus 7K. In een paar draaien, met evenveel vPC-links als we hadden, was dit vreemd.

Je kunt niet repareren wat je niet kunt zien
Wat hebben we gevonden? Nou, we hebben een bug gevonden, een intermitterende bug die het verkeer zou blokkeren. Bugs zijn onvermijdelijk; ze gebeuren op elk product, elke software of oplossing die er is. We kwamen toevallig in dit geval een bepaalde tegen die ervoor zou zorgen dat de backplane fabric-modules het verkeer zouden blokkeren terwijl het probeerde gegevens door te geven van bijvoorbeeld slot 3 naar slot 2. De backplane-modules faalden niet, dus geen waarschuwingen. De blackholing van het verkeer zou plaatsvinden bij een bufferoverloop vanwege andere factoren: de klant pompte niet genoeg gegevens om de limiet van de gegevensverwerking te naderen. Een code-release loste het probleem op. Tevreden klant.

NetBrain gaf waardevol inzicht in een situatie waarin alle andere redelijke manieren om 'wat normaal is' faalden. De andere tools hadden zo kunnen worden afgesteld dat ze opvangen wat we nodig hadden, maar het zou ook waarschuwen voor veel te veel niet-ernstige problemen. NetBrain stelde ons in staat om het probleem te lokaliseren en ergens te beginnen. Om elk probleem op te lossen, moet je het probleem begrijpen, en zonder NetBrain, Ik weet niet zeker of we zo snel zouden hebben begrepen waar we moesten beginnen.

---

Historische vergelijkende analyse met één klik is slechts één manier NetBrain helpt frustrerende periodieke problemen aan te pakken. Het kan ook een geautomatiseerde analyse activeren vanuit uw 24×7-bewakingsoplossing, ticketingsysteem, IDS/SIEM op het moment dat er een probleem wordt gedetecteerd.

We noemen dit "just in time"-automatisering - bekijk het in actie door hier een demo te plannen: laat me just-in-time automatisering zien