Es ist wirklich schwer, einen CCIE zu feuern. Und nein, das ist keine versteckte Drohung an meinen Chef. Versetzen wir uns für einen Moment in die Lage des Managements. Das Netzwerk ist eine unheimliche Blackbox, an die man nicht einfach einen VGA-Monitor anschließen kann, um zu sehen, was auf dem Bildschirm zu sehen ist.
Es gibt eine ganze Reihe verschiedener Tools und Überwachungssysteme, von denen keines in 100% der Fälle funktioniert. Wenn das Netzwerk wirklich etwas Ungewöhnliches tut oder sich in irgendeiner Weise falsch verhält, ist die Antwort nie eindeutig. Das Problem lässt sich nur durch einen Blick in die verrückt aussehenden Protokolldateien oder noch schlimmer erkennen. Wenn Sie einWenn Sie sich fragen: "Was könnte schlimmer sein als eine Protokolldatei?", dann haben Sie offensichtlich noch nie einen Paket-Trace lesen müssen.
Für diejenigen, die gerade erst einsteigen, ist dies der zweite Teil von diese Serie. In diesem Beitrag werde ich alle Netzwerkexperten als CCIEs bezeichnen. Wenn Sie ein CCIE, ein JNCIE, eine andere Art von IE oder einfach ein Rockstar-Netzwerkarchitekt/-ingenieur sind, wenn ich von CCIEs spreche, dann meine ich SIE! Es ist ein großes Zelt, komm rein und mach mit...
Kehren wir also zu meiner Aussage vom letzten Mal zurück. Ein CCIE macht im Wesentlichen diese 4 Dinge:
- Bricht das Netzwerk - Mein letzter Beitrag
- Repariert das Netzwerk - Dieser Beitrag
- Umzüge/Ergänzungen/Änderungen
- Projektleitung
Wenn wir wieder in die Rolle unseres Managers schlüpfen, wir betrachten unsere CCIE-Mitarbeiter als sehr wertvolles Gut. Viele Unternehmen haben höchstens einen CCIE, einige wenige haben mehr als einen, und die große Mehrheit der Unternehmen hat gar keinen. Es ist schwierig, CCIEs zu finden, CCIEs einzustellen, CCIEs zu beschäftigen und CCIEs zu halten. Sie können ziemlich teuer sein und manchmal ist der Umgang mit ihnen etwas merkwürdig. Was sind also die Vorteile für einen Manager, der einen CCIE in seinem Unternehmen hat?
CCIEs sind (abgesehen von ihrer eigentlichen Arbeit) so etwas wie eine Versicherung. Sie sind die besten Köpfe in der IT-Organisation, an sie wendet man sich, wenn etwas wirklich kaputt ist. Sie können nicht alle Probleme auf der Anwendungsebene beheben, aber sie können zumindest aufzeigen, welches System nicht das tut, was es tun sollte. So kann Ihr CCIE, möglicherweise durch das Lesen einer Paketaufzeichnung, Ihrer Organisation sagen, wo das Problem liegt. Welcher Server antwortet nicht? Und wenn etwas nicht funktioniert und Sie keinen CCIE haben, welche Möglichkeiten haben Sie dann noch?
- Rufen Sie den Netzwerkanbieter an (z. B. Cisco TAC, Juniper JTAC)
- Rufen Sie Ihren Managed Service Provider an
- Beauftragen Sie einen Berater und hoffen Sie, dass er nicht zu beschäftigt ist, um Ihnen zu helfen
- Gehen Sie zu StackOverflow, ChatGPT, Discord
- Kontaktieren Sie Ihre lokale Gottheit
Keine dieser Optionen ist besonders gut. Jede von ihnen erfordert eine gewisse Zeitverzögerung, möglicherweise den Austausch von Geld (oder, im Falle der Gottheit, Ihres Erstgeborenen), und sie alle erfordern, dass sich jemand anderes mit Ihrer Umgebung vertraut macht. Wenn Ihr Unternehmen schwer angeschlagen ist und Sie darauf warten müssen, dass ein Berater Ihr Problem versteht, Zugang zu Ihren Systemen erhält und die Fehlerbehebung tatsächlich durchführt, werden diese Minuten/Stunden/Tage wie eine Ewigkeit vergehen. Wenn Ihr Unternehmen also so groß und wichtig ist, dass Sie diese Verzögerung nicht tolerieren können, stellen Sie einen CCIE ein. Und diese Person in der Nähe Ihres Büros zu haben, ist Ihre eigene Form der Versicherung. Er ist die Rückendeckung. Die Verantwortung liegt bei ihm.
Was aber, wenn der CCIE das Problem nicht lösen kann? Zunächst einmal würde das den CCIE in den mentalen Brunnen des Hochstaplersyndroms stoßen. Es gibt immer ein Problem, das jeden Experten verwirren kann, auch CCIEs. Glücklicherweise können sie sich immer noch an eine der bereits erwähnten dritten Parteien wenden, und während sie in der Warteschleife sind, können sie die Fehlersuche fortsetzen und Informationen erfassen, die jemand anderem helfen, die Ursache des Problems zu verstehen. Und wenn sie eine Remote-Support-Einheit wie ein Technical Assistance Center (TAC) einschalten, agieren diese als Experten aus der Ferne und führen alle notwendigen physischen Aktionen durch, um Informationen zur Identifizierung des Problems zu erhalten.
Alle CCIEs leiden unter dem Hochstaplersyndrom. Es gibt immer etwas, das wir nicht herausfinden oder reparieren können, und obwohl das manchmal beunruhigend ist, ist es eine Realität, wenn wir Geräte bedienen, die von jemand anderem gebaut wurden.
In meinem letzten Beitrag hatte ich einige mea culpa-Momente (übersetzt: ich habe Mist gebaut). Aber es gab auch einige Momente, in denen ich definitiv NICHT am Hochstaplersyndrom litt. Es gab einige Momente, in denen ich den Tag gerettet habe, oder wie es in meinem Lebenslauf steht: "Manchmal bin ich wirklich der Größte".
Eine kurze Geschichte von Josh, der alles gibt
Ich stürmte um 2 Uhr morgens in die Zentrale eines weltweit tätigen Medien- und Rundfunkunternehmens, als das gesamte Netzwerk ausgefallen war, und verbrachte Stunden damit, Fehler zu suchen und mich wie ein Bandit über den Campus zu schleichen, bis ich einen verstaubten alten Schalter in einem HLK-Büro fand, das vier Stockwerke unter dem Straßenniveau mitten in Manhattan lag. Der Schalter befand sich in einem Raum, in dem ein Facility Manager die Klimaanlage für einen ganzen Firmencampus auf einem kleinen Bildschirm überwachte, und als ich um 4 Uhr morgens unangemeldet in sein Zimmer stürmte, zu dem Schalter rannte und eines der Kabel herauszog, war das eine Szene wie aus Herr der Ringe. Der Kerl (der offensichtlich nie Besuch hatte und aussah, als bekäme er nicht viel Sonne ab) war sicherlich ausgeflippt, weil ich in sein Versteck eindrang und mich an seinem Schmuckstück zu schaffen machte. Wie auch immer. Das Netz erwachte wieder zum Leben, und ich bahnte mir langsam einen Weg aus den Dampftunneln heraus. RIESIGER GEWINN. Lektion: Als Experte sollten Sie sich die Zeit nehmen, jedes noch so abgelegene Gerät zu besichtigen und zu prüfen.
Ich habe einmal eine Fehlersuche an einem hängenden Cisco 7206VXR durchgeführt, als ich im Urlaub war und eine völlig ungeschulte Person im entfernten Rechenzentrum über eine sporadische Telefonverbindung meine Hände im Spiel hatte. Glücklicherweise verfüge ich über ein fotografisches Gedächtnis, so dass ich den genauen Standort des Geräts beschreiben konnte und auch wusste, wo ein Aux-Kabel und ein Dongle zu finden sind und wo sich der Konsolenanschluss inmitten eines Nests alter Kabel befindet. Mein entfernter Kumpel machte seine ersten Erfahrungen mit dem Bau eines Notfallwagens und dem Anschluss an die Konsole (ich habe ihn wahrscheinlich für sein ganzes Leben gezeichnet), und als wir wussten, dass das Gerät hing, starteten wir es neu. Das Netzwerk wurde wiederhergestellt. Auf der Konferenzbrücke saßen mein direkter Vorgesetzter, der Abteilungsleiter und der Leiter eines kürzlich übernommenen Unternehmens, zu dem mehrere Filmstudios gehören. Sie waren überschwänglich in ihrem Lob. Ich legte den Anruf auf und holte mir (noch eine) Pina Colada. Lektion: Lassen Sie überall, wo Sie können, zusätzliche Konsolenkabel liegen. Lektion 2: Genießen Sie Ihre freie Zeit, Sie haben sie verdient.
Einmal beendete ich eine wochenlange Fehlersuche, die jemand an einem Nexus 7k durchgeführt hatte, der wahllos entschied, welche Pakete weitergeleitet werden sollten. Ich fuhr zu dem Standort, um einem jungen Ingenieur zu helfen, und brauchte 2 Minuten, um das Problem zu erkennen. "Warum ist das Gehäuse schief?" Ein paar Stunden später gab er zu, dass er es "nur einmal" fallen ließ, als er es in Position brachte. Die Menge tobt. Lektion: Heruntergefallene Geräte sind wahrscheinlich defekt.
Ich habe im Alleingang ein Problem gelöst, das zu sporadischen Ausfällen zwischen zwei großen Medienunternehmen führte, die fusionierten. Der hochrangige Netzwerkarchitekt des anderen Unternehmens entschied, dass es schlau wäre, die Verwaltungskontrollen zu isolieren, indem zwei SUP4s in einem einzigen 6509 eingesetzt werden, wobei jedes Unternehmen einen kontrolliert. SCHLECHTE IDEE. Lektion: Redundante Supervisors müssen identisch konfiguriert sein.
Während des Stromausfalls an der Ostküste im Jahr 2003 habe ich eine große E-Commerce-Website vor dem Zusammenbruch bewahrt. Ich saß an meinem Schreibtisch, als die Lichter im Gebäude ausgingen. Mein erster Gedanke war: "Oh, Mist, hoffentlich habe ich das nicht getan", und dann rannte ich sofort los und lief drei Stockwerke hoch zu einem Rechenzentrum, um zu sehen, was mit unserem Rechenzentrum passiert war. Glücklicherweise war das Rechenzentrum mit einem Batterie-Backup ausgestattet, so dass alles lief, aber in einem verrückten, vorausschauenden Moment beschloss ich zu überprüfen, ob unsere Kern-Switches alle an das Notstromnetz angeschlossen waren, das in weniger als 5 Minuten die einzige Stromquelle sein würde. Ich stellte fest, dass jemand die redundanten Stromversorgungen mit einem Core-Switch falsch verbunden hatte. Da ich etwas wie der Road Runner aussah, fand ich ein Ersatzkabel und steckte es ein, etwa 3 Sekunden bevor der Strom von der Batterie auf den Notstromgenerator umgeschaltet wurde. Hätte ich das nicht getan, wäre der gesamte Betrieb zusammengebrochen. Lektion: Seien Sie proaktiv bei der Bewertung von Notfallwiederherstellungsszenarien, und testen Sie alles häufig.
Bauen Sie keine Schneeflocken
Aber nicht jeder kann es sich leisten, rund um die Uhr einen Netzwerkexperten zu beschäftigen. Deshalb gibt es eine Vielzahl von Tools zur Netzwerküberwachung, -analyse und -fehlerbehebung. Außerdem hat sich die Branche in den letzten 10 Jahren stark weiterentwickelt. Wir bauen heute Netzwerke mit einigen recht gängigen Designs auf, und viele Produkte implementieren standardmäßig Best Practices für das Design. Tatsächlich können Sie ein Netzwerk online entwerfen und alle Techniken und Optimierungen, die von den großen Cloud-Anbietern verwendet werden, in das Design integrieren lassen. Durch diese Verbesserungen werden nicht nur Probleme von vornherein vermieden, sondern gut konzipierte und deterministische Netzwerktopologien sind auch viel einfacher zu beheben, falls Sie einmal ein Problem erben sollten.
Sind CCIEs jetzt weniger wertvoll? Wenn Ihr Netzwerk ausgefallen ist, lautet die Antwort eindeutig NEIN, denn Sie werden wahrscheinlich jede Menge Geld bezahlen, um es wieder zum Laufen zu bringen. Aber die Welt hat sich in den letzten zwanzig Jahren sehr verändert. Wir verwenden nicht mehr so viele verschiedene Protokolle (RIP: DLSW, Appletalk, IPX/SPX, DECnet, Vines usw.), und bestimmte Netzwerktopologien und -designs haben sich als beste technische Lösung für bestimmte Anwendungsfälle erwiesen (z. B. Leaf-Spine Clos Fabric für die Serverkonnektivität in Rechenzentren). Das bedeutet, dass Architekten wiederholbare (und zuverlässige) Netzwerkeinheiten bauen und nicht etwas, das schwer zu beheben ist. Und das bedeutet, dass Sie mit geringerer Wahrscheinlichkeit einen CCIE benötigen. Lassen Sie uns in Teil 3 weiter darüber sprechen.
Bis zum nächsten Mal!

Josh Saul leistet seit mehr als 25 Jahren Pionierarbeit bei Open-Source-Netzwerklösungen. Als Architekt hat er Kernnetzwerke für GE, Pfizer und NBC Universal aufgebaut. Als Ingenieur bei Cisco beriet Josh Saul Kunden aus dem Fortune-100-Finanzsektor und warb bei Kunden für neue Technologien. In jüngerer Zeit leitete Josh Marketing- und Produktteams bei VMware (übernommen von Broadcom), Cumulus Networks (übernommen von Nvidia) und Apstra (übernommen von Juniper). Josh lebt mit seinen beiden Kindern in New York City und ist ein begeisterter SCUBA-Taucher.