So übernehmen Sie die Kontrolle über Ihre Netzwerkinfrastruktur. Kapitel Zwei. Reinigung und Dokumentation

Dieser Artikel ist der zweite in der Artikelreihe „So übernehmen Sie die Kontrolle über Ihre Netzwerkinfrastruktur“. Den Inhalt aller Artikel der Reihe und Links finden Sie hier hier.

Unser Ziel in dieser Phase ist es, Ordnung in die Dokumentation und Konfiguration zu bringen.
Am Ende dieses Prozesses sollten Sie über die erforderlichen Dokumente und ein entsprechend konfiguriertes Netzwerk verfügen.

Jetzt werden wir nicht über Sicherheitsüberprüfungen sprechen – dies wird Gegenstand des dritten Teils sein.

Die Schwierigkeit, die in dieser Phase gestellte Aufgabe zu erfüllen, ist natürlich von Unternehmen zu Unternehmen sehr unterschiedlich.

Die ideale Situation ist, wenn

• Ihr Netzwerk wurde projektgerecht erstellt und Sie verfügen über vollständige Unterlagen
• wurde in Ihrem Unternehmen umgesetzt Änderungskontroll- und Managementprozess für Netzwerk
• Im Rahmen dieses Prozesses verfügen Sie über Dokumente (einschließlich aller erforderlichen Diagramme), die vollständige Informationen über den aktuellen Stand der Dinge liefern

In diesem Fall ist Ihre Aufgabe ganz einfach. Sie sollten die Dokumente studieren und alle vorgenommenen Änderungen überprüfen.

Im schlimmsten Fall werden Sie es haben

• ein Netzwerk, das ohne Projekt, ohne Plan, ohne Genehmigung von Ingenieuren ohne ausreichende Qualifikation erstellt wurde,
• mit chaotischen, undokumentierten Änderungen, mit viel „Müll“ und suboptimalen Lösungen

Es ist klar, dass Ihre Situation irgendwo dazwischen liegt, aber leider besteht auf dieser Skala von besser bis schlechter eine hohe Wahrscheinlichkeit, dass Sie dem schlechtesten Ende näher kommen.

In diesem Fall benötigen Sie auch die Fähigkeit, Gedanken zu lesen, denn Sie müssen lernen, zu verstehen, was die „Designer“ tun wollten, ihre Logik wiederherzustellen, zu Ende zu bringen, was nicht fertig war, und „Müll“ zu entfernen.
Und natürlich müssen Sie ihre Fehler korrigieren, das Design (zu diesem Zeitpunkt so minimal wie möglich) ändern und die Schemata ändern oder neu erstellen.

Dieser Artikel erhebt keinen Anspruch auf Vollständigkeit. Hier werde ich nur die allgemeinen Prinzipien beschreiben und mich auf einige häufige Probleme konzentrieren, die gelöst werden müssen.

Satz Dokumente

Beginnen wir mit einem Beispiel.

Nachfolgend finden Sie einige Dokumente, die bei Cisco Systems üblicherweise während des Designs erstellt werden.

CR – Kundenanforderungen, Kundenanforderungen (technische Spezifikationen).
Es wird gemeinsam mit dem Kunden erstellt und ermittelt die Netzwerkanforderungen.

HLD – High-Level-Design, High-Level-Design basierend auf Netzwerkanforderungen (CR). Das Dokument erläutert und begründet die getroffenen Architekturentscheidungen (Topologie, Protokolle, Hardwareauswahl,...). HLD enthält keine Designdetails, wie z. B. die verwendeten Schnittstellen und IP-Adressen. Auch auf die konkrete Hardwarekonfiguration wird hier nicht eingegangen. Vielmehr soll dieses Dokument der technischen Leitung des Kunden wichtige Designkonzepte erläutern.

LLD – Low-Level-Design, Low-Level-Design basierend auf High-Level-Design (HLD).
Es sollte alle für die Umsetzung des Projekts notwendigen Details enthalten, beispielsweise Informationen zum Anschluss und zur Konfiguration der Geräte. Dies ist eine vollständige Anleitung zur Umsetzung des Designs. Dieses Dokument soll ausreichende Informationen für die Umsetzung auch durch weniger qualifiziertes Personal bieten.

Etwas, zum Beispiel IP-Adressen, AS-Nummern, physikalisches Vermittlungsschema (Verkabelung), kann in separaten Dokumenten „herausgegeben“ werden, z NIP (Netzwerkimplementierungsplan).

Der Aufbau des Netzwerkes beginnt nach der Erstellung dieser Unterlagen und erfolgt in strikter Übereinstimmung mit diesen und wird anschließend vom Kunden auf Übereinstimmung mit dem Entwurf überprüft (Versuche).

Natürlich können unterschiedliche Integratoren, unterschiedliche Kunden und unterschiedliche Länder unterschiedliche Anforderungen an die Projektdokumentation haben. Aber ich möchte auf Formalitäten verzichten und die Angelegenheit nach ihrem Sachverhalt betrachten. In dieser Phase geht es nicht um Design, sondern darum, die Dinge zu ordnen, und wir benötigen einen ausreichenden Satz an Dokumenten (Diagramme, Tabellen, Beschreibungen ...), um unsere Aufgaben zu erledigen.

Und meiner Meinung nach gibt es ein gewisses absolutes Minimum, ohne das es unmöglich ist, das Netzwerk effektiv zu kontrollieren.

Dabei handelt es sich um folgende Dokumente:

• Diagramm (Protokoll) der physikalischen Schaltung (Verkabelung)
• Netzwerkdiagramm oder Diagramme mit wesentlichen L2/L3-Informationen

Physikalisches Schaltdiagramm

In einigen kleinen Unternehmen liegen Netzwerktechniker für Arbeiten im Zusammenhang mit der Geräteinstallation und der physischen Umschaltung (Verkabelung).

In diesem Fall wird das Problem teilweise durch den folgenden Ansatz gelöst.

• Verwenden Sie eine Beschreibung auf der Schnittstelle, um zu beschreiben, was mit ihr verbunden ist
• Schalten Sie alle nicht verbundenen Netzwerkgeräteports administrativ ab

Dies gibt Ihnen die Möglichkeit, auch im Falle eines Verbindungsproblems (wenn cdp oder lldp auf dieser Schnittstelle nicht funktioniert) schnell festzustellen, was an diesem Port angeschlossen ist.
Außerdem können Sie leicht erkennen, welche Ports belegt und welche frei sind, was für die Planung der Anbindung neuer Netzwerkgeräte, Server oder Workstations notwendig ist.

Aber es ist klar: Wenn Sie den Zugriff auf die Ausrüstung verlieren, verlieren Sie auch den Zugriff auf diese Informationen. Darüber hinaus können Sie auf diese Weise nicht so wichtige Informationen erfassen, wie z. B. welche Art von Gerät, welcher Stromverbrauch, wie viele Ports, in welchem ​​Rack es sich befindet, welche Patchpanels sich dort befinden und wo (in welchem ​​Rack/Patchpanel). ) sie sind verbunden . Daher sind zusätzliche Dokumentationen (nicht nur Beschreibungen der Geräte) immer noch sehr nützlich.

Die ideale Option besteht darin, Anwendungen zu verwenden, die für die Arbeit mit dieser Art von Informationen entwickelt wurden. Sie können sich aber auf einfache Tabellen beschränken (z. B. in Excel) oder die Informationen, die Sie für notwendig halten, in L1/L2-Diagrammen darstellen.

Wichtig!

Ein Netzwerktechniker kann natürlich die Feinheiten und Standards von SCS, die Arten von Racks, die Arten von unterbrechungsfreien Stromversorgungen, was ein Kalt- und Warmgang ist, wie man eine ordnungsgemäße Erdung durchführt, recht gut kennen ... genau wie er es im Prinzip auch kann kennen die Physik der Elementarteilchen oder C++. Aber man muss trotzdem verstehen, dass das alles nicht sein Fachgebiet ist.

Daher empfiehlt es sich, entweder eigene Abteilungen oder engagierte Leute zu haben, die Probleme im Zusammenhang mit der Installation, dem Anschluss, der Wartung von Geräten sowie dem physischen Schalten lösen. Normalerweise handelt es sich bei Rechenzentren um Rechenzentrumsingenieure und bei Büros um einen Helpdesk.

Wenn in Ihrem Unternehmen solche Abteilungen vorhanden sind, ist die Protokollierung des physischen Switchings nicht Ihre Aufgabe und Sie können sich nur auf die Beschreibung der Schnittstelle und die administrative Abschaltung nicht verwendeter Ports beschränken.

Netzwerkdiagramme

Es gibt keinen universellen Ansatz zum Zeichnen von Diagrammen.

Das Wichtigste ist, dass die Diagramme ein Verständnis dafür vermitteln, wie der Datenverkehr durch welche logischen und physischen Elemente Ihres Netzwerks fließen wird.

Mit physikalischen Elementen meinen wir

• aktive Ausrüstung
• Schnittstellen/Ports aktiver Geräte

Unter logisch -

• logische Geräte (N7K VDC, Palo Alto VSYS, ...)
• VRF
• Vilans
• Subschnittstellen
• Tunnel
• Zone
• ...

Auch wenn Ihr Netzwerk nicht völlig elementar ist, besteht es aus verschiedenen Segmenten.
Beispielsweise

• Rechenzentrum
• Internet
• WAN
• Fernzugriff
• Büro-LAN
• DMZ
• ...

Es ist ratsam, mehrere Diagramme zu haben, die sowohl einen Gesamtüberblick (wie der Verkehr zwischen all diesen Segmenten fließt) als auch eine detaillierte Erklärung jedes einzelnen Segments vermitteln.

Da es in modernen Netzwerken viele logische Schichten geben kann, ist es möglicherweise ein guter (aber nicht notwendiger) Ansatz, unterschiedliche Schaltkreise für verschiedene Schichten zu erstellen. Im Falle eines Overlay-Ansatzes könnten dies beispielsweise die folgenden Schaltkreise sein:

• Auflage
• L1/L2-Unterlage
• L3-Unterlage

Das wichtigste Diagramm, ohne das es unmöglich ist, die Idee Ihres Designs zu verstehen, ist das Routing-Diagramm.

Routing-Schema

Zumindest sollte dieses Diagramm widerspiegeln

• Welche Routing-Protokolle werden wo verwendet?
• Grundlegende Informationen zu Routing-Protokolleinstellungen (Bereich/AS-Nummer/Router-ID/…)
• Auf welchen Geräten findet eine Umverteilung statt?
• wo Filterung und Routenaggregation stattfinden
• Standardrouteninformationen

Auch das L2-Schema (OSI) ist oft nützlich.

L2-Schema (OSI)

Dieses Diagramm kann die folgenden Informationen anzeigen:

• welche VLANs
• Welche Ports sind Trunk-Ports?
• Welche Ports werden in Ether-Channel (Port-Channel) und virtuellen Port-Channel zusammengefasst?
• welche STP-Protokolle auf welchen Geräten verwendet werden
• Grundlegende STP-Einstellungen: Root/Root-Backup, STP-Kosten, Portpriorität
• zusätzliche STP-Einstellungen: BPDU Guard/Filter, Root Guard…

Typische Designfehler

Ein Beispiel für einen schlechten Ansatz beim Aufbau eines Netzwerks.

Nehmen wir ein einfaches Beispiel für den Aufbau eines einfachen Büro-LAN.

Aufgrund meiner Erfahrung im Unterrichten von Telekommunikationsstudenten kann ich sagen, dass praktisch jeder Student in der Mitte des zweiten Semesters über die erforderlichen Kenntnisse verfügt (im Rahmen des Kurses, den ich unterrichtet habe), um ein einfaches Büro-LAN einzurichten.

Was ist so schwierig daran, Switches miteinander zu verbinden, VLANs, SVI-Schnittstellen (im Fall von L3-Switches) und statisches Routing einzurichten?

Alles wird funktionieren.

Aber gleichzeitig Fragen im Zusammenhang mit

• Sicherheit
• Reservierung
• Netzwerkskalierung
• Produktivität
• Durchsatz
• Zuverlässigkeit
• ...

Von Zeit zu Zeit höre ich die Aussage, dass ein Büro-LAN etwas sehr Einfaches sei, und das höre ich normalerweise von Ingenieuren (und Managern), die sich mit allem außer Netzwerken befassen, und sie sagen das so selbstbewusst, dass es nicht überrascht ist, wenn das LAN so sein wird von Leuten mit unzureichender Übung und Wissen gemacht und werden mit ungefähr den gleichen Fehlern gemacht, die ich unten beschreiben werde.

Häufige L1 (OSI)-Designfehler

• Wenn Sie dennoch auch für SCS verantwortlich sind, dann ist ein unvorsichtiger und unüberlegter Wechsel eine der unangenehmsten Hinterlassenschaften, die Ihnen entstehen können.

Ich würde auch Fehler vom Typ L1 einstufen, die sich auf die Ressourcen der verwendeten Geräte beziehen, zum Beispiel:

• unzureichende Bandbreite
• unzureichendes TCAM auf der Ausrüstung (oder ineffiziente Nutzung davon)
• unzureichende Leistung (häufig im Zusammenhang mit Firewalls)

Häufige L2 (OSI)-Designfehler

Wenn kein gutes Verständnis dafür besteht, wie STP funktioniert und welche potenziellen Probleme es mit sich bringt, werden Switches oft chaotisch, mit Standardeinstellungen und ohne zusätzliche STP-Optimierung angeschlossen.

Infolgedessen haben wir oft Folgendes

• großer STP-Netzwerkdurchmesser, der zu Broadcast-Stürmen führen kann
• Der STP-Root wird zufällig bestimmt (basierend auf der MAC-Adresse) und der Verkehrspfad ist nicht optimal
• Mit Hosts verbundene Ports werden nicht als Edge-Ports (Portfast) konfiguriert, was zu einer STP-Neuberechnung beim Ein-/Ausschalten von Endstationen führt
• Das Netzwerk wird nicht auf L1/L2-Ebene segmentiert, was dazu führt, dass Probleme mit einem Switch (z. B. Stromüberlastung) zu einer Neuberechnung der STP-Topologie und einem Stopp des Datenverkehrs in allen VLANs auf allen Switches (einschließlich) führen ein aus Sicht der Kontinuität kritisches Servicesegment)

Beispiele für Fehler im L3 (OSI)-Design

Ein paar typische Fehler unerfahrener Netzwerker:

• Häufige (oder ausschließliche) Verwendung von statischem Routing
• Verwendung suboptimaler Routing-Protokolle für ein bestimmtes Design
• suboptimale logische Netzwerksegmentierung
• suboptimale Nutzung des Adressraums, die keine Routenaggregation ermöglicht
• Keine Backup-Routen
• Keine Reservierung für Standard-Gateway
• asymmetrisches Routing beim Neuaufbau von Routen (kann bei NAT/PAT, Statefull-Firewalls kritisch sein)
• Probleme mit MTU
• Wenn Routen neu erstellt werden, passiert der Datenverkehr andere Sicherheitszonen oder sogar andere Firewalls, was dazu führt, dass dieser Datenverkehr verworfen wird
• schlechte Skalierbarkeit der Topologie

Kriterien zur Beurteilung der Designqualität

Wenn wir über Optimalität/Nicht-Optimalität sprechen, müssen wir verstehen, nach welchen Kriterien wir dies bewerten können. Hier sind aus meiner Sicht die wichtigsten (aber nicht alle) Kriterien (und Erklärungen in Bezug auf Routing-Protokolle):

• Skalierbarkeit
  Sie beschließen beispielsweise, ein weiteres Rechenzentrum hinzuzufügen. Wie einfach können Sie das machen?
• Benutzerfreundlichkeit (Verwaltbarkeit)
  Wie einfach und sicher sind betriebliche Änderungen, etwa die Ankündigung eines neuen Netzes oder das Filtern von Routen?
• Verfügbarkeit
  Wie viel Prozent der Zeit bietet Ihr System das erforderliche Serviceniveau?
• Sicherheit
  Wie sicher sind die übertragenen Daten?
• Preis

Änderungen

Das Grundprinzip in dieser Phase kann durch die Formel „keinen Schaden anrichten“ ausgedrückt werden.
Daher ist es nicht immer ratsam, Änderungen vorzunehmen, auch wenn Sie mit dem Design und der gewählten Implementierung (Konfiguration) nicht vollständig einverstanden sind. Ein sinnvoller Ansatz besteht darin, alle identifizierten Probleme nach zwei Parametern zu ordnen:

• Wie einfach lässt sich dieses Problem beheben?
• Wie viel Risiko trägt sie?

Zunächst gilt es zu beseitigen, was derzeit das Niveau der bereitgestellten Dienste unter das akzeptable Niveau senkt, beispielsweise Probleme, die zu Paketverlusten führen. Beheben Sie dann das, was am einfachsten und sichersten zu beheben ist, in absteigender Reihenfolge der Risikoschwere (von Design- oder Konfigurationsproblemen mit hohem Risiko bis hin zu Problemen mit geringem Risiko).

Perfektionismus kann in dieser Phase schädlich sein. Bringen Sie das Design in einen zufriedenstellenden Zustand und synchronisieren Sie die Netzwerkkonfiguration entsprechend.

Source: habr.com