Wie Sie die Netzwerk-Infrastruktur unter Ihre Kontrolle bringen. Kapitel zwei. Aufräumen und Dokumentieren

Dieser Artikel ist der zweite in einer Serie von Artikeln mit dem Titel „Wie man die Netzwerkstruktur unter Kontrolle bekommt“. Den Inhalt aller Artikel dieser Reihe und die Links finden Sie hier.

Unser Ziel in dieser Phase ist es, Ordnung in die Dokumentation und die Konfiguration zu bringen.
Am Ende dieses Prozesses sollten Sie das notwendige Dokumentenpaket und ein Netzwerk haben, das entsprechend konfiguriert ist.

Jetzt werden wir nicht über die Sicherheitsüberprüfung sprechen – dies wird im dritten Teil behandelt.

Der Schwierigkeitsgrad der Aufgabe, die in dieser Phase gestellt wird, variiert natürlich stark von Unternehmen zu Unternehmen.

Die ideale Situation ist, wenn

• Ihr Netzwerk gemäß dem Projekt eingerichtet wurde und Sie ein vollständiges Dokumentationspaket haben
• in Ihrem Unternehmen ein Änderungsmanagementprozess implementiert wurde für das Netzwerk
• gemäß diesem Prozess verfügen Sie über Dokumente (einschließlich aller notwendigen Diagramme), die vollständige Informationen über die aktuelle Situation bieten

In diesem Fall ist Ihre Aufgabe ziemlich einfach. Sie müssen die Dokumente studieren und alle Änderungen überprüfen, die vorgenommen wurden.

Im schlechtesten Fall werden Sie ein

• Netzwerk haben, das ohne Projekt, ohne Plan, ohne Genehmigung von Ingenieuren, die nicht über ausreichende Qualifikationen verfügen, erstellt wurde,
• mit chaotischen, undokumentierten Änderungen, einer Menge „Schrott“ und suboptimalen Lösungen.

Es ist klar, dass sich Ihre Situation irgendwo dazwischen befindet, aber leider werden Sie mit großer Wahrscheinlichkeit näher am schlimmsten Ende dieser Skala liegen.

In diesem Fall werden von Ihnen unter anderem Fähigkeiten im Gedankenlesen verlangt, da Sie lernen müssen zu verstehen, was die „Designer“ beabsichtigt haben, ihre Logik zu rekonstruieren, das zu vervollständigen, was nicht abgeschlossen wurde, und den „Schrott“ zu entfernen.
Und natürlich müssen Sie ihre Fehler korrigieren, das Design (in dieser Phase nach Möglichkeit minimal) ändern und Diagramme ändern oder neu erstellen.

Dieser Artikel erhebt keinesfalls Anspruch auf Vollständigkeit. Ich werde hier lediglich allgemeine Prinzipien beschreiben und auf einige häufige Probleme eingehen, die gelöst werden müssen.

Dokumentensatz

Lassen Sie uns mit einem Beispiel beginnen.

Im Folgenden sind einige Dokumente aufgeführt, die bei der Planung in der Firma Cisco Systems üblich sind.

CR – Customer Requirements, Anforderungen des Kunden (technische Spezifikation).
Wird gemeinsam mit dem Kunden erstellt und definiert die Anforderungen an das Netzwerk.

HLD – High Level Design, das auf den Netzwerkanforderungen (CR) basiert. Das Dokument erklärt und begründet die getroffenen architektonischen Entscheidungen (Topologie, Protokolle, Auswahl der Hardware,…). HLD enthält keine Details zum Design, wie z.B. verwendete Schnittstellen und IP-Adressen. Ebenso wird keine spezifische Hardwarekonfiguration besprochen. Dieses Dokument soll eher dem technischen Management des Kunden die Schlüsselkonzepte des Designs erläutern.

LLD – Low Level Design, das auf dem High Level Design (HLD) basiert.
Es sollte alle Details enthalten, die zur Umsetzung des Projekts erforderlich sind, wie Informationen zum Anschluss und zur Konfiguration der Hardware. Dies ist ein umfassendes Implementierungshandbuch für das Design. Dieses Dokument muss genügend Informationen bereitstellen, damit auch weniger qualifiziertes Personal es umsetzen kann.

Einige Dinge, wie z.B. IP-Adressen, AS-Nummern, das Schema der physikalischen Verkabelung, können in separate Dokumente ausgegliedert werden, wie z.B. NIP (Network Implementation Plan).

Der Aufbau des Netzwerks beginnt nach der Erstellung dieser Dokumente und erfolgt strikt entsprechend ihnen, und wird dann vom Kunden (Tests) auf Übereinstimmung mit dem Design überprüft.

Natürlich können die Anforderungen an die Projektdokumentation je nach Integratoren, Kunden und Ländern unterschiedlich sein. Aber wir möchten Formalitäten vermeiden und die Dinge beim Namen nennen. Dieser Schritt geht nicht um das Design, sondern darum, Ordnung zu schaffen, und wir benötigen einen ausreichenden Dokumentensatz (Schemata, Tabellen, Beschreibungen …), um unsere Aufgaben zu erfüllen.

Und meiner Meinung nach gibt es ein gewisses absolutes Minimum, ohne das eine effektive Kontrolle des Netzwerks nicht möglich ist.

Das sind die folgenden Dokumente:

• Schema (Protokoll) der physikalischen Verkabelung
• Schema oder Schemata des Netzwerks mit wesentlichen L2/L3 Informationen

Schaltplan der physischen Verkabelung

In einigen kleinen Unternehmen liegen die Arbeiten, die mit der Installation von Hardware und physikalischer Verkabelung verbunden sind, im Verantwortungsbereich von Netzwerkingenieuren.

In diesem Fall wird die Aufgabe teilweise mit dem folgenden Ansatz gelöst.

• Verwenden Sie die Beschreibung an der Schnittstelle, um zu beschreiben, was daran angeschlossen ist.
• Schalten Sie administrativ alle nicht angeschlossenen Ports des Netzwerkgeräts aus.

Dies ermöglicht Ihnen, auch im Falle eines Problems mit dem Link (wenn cdp oder lldp auf diesem Interface nicht funktioniert), schnell zu erkennen, was an diesen Port angeschlossen ist.
Sie können auch leicht sehen, welche Ports belegt sind und welche frei sind, was notwendig ist, um neue Netzwerkgeräte, Server oder Arbeitsstationen zu planen.

Es ist jedoch klar, dass Sie, wenn Sie den Zugang zu der Ausrüstung verlieren, auch den Zugang zu diesen Informationen verlieren. Außerdem können Sie auf diese Weise solche wichtigen Informationen wie das verwendete Gerät, die Leistungsaufnahme, die Anzahl der Ports, in welchem Rack es sich befindet, welche Patch-Panels vorhanden sind und wo (in welches Rack/Patch-Panel) sie verkabelt sind, nicht protokollieren. Daher ist es immer noch sehr nützlich, zusätzliche Dokumentationen (nicht nur Beschreibungen an den Geräten) zu haben.

Die ideale Lösung besteht darin, Anwendungen zu nutzen, die für die Arbeit mit solchen Informationen entwickelt wurden. Aber es kann auch mit einfachen Tabellen (zum Beispiel in Excel) auskommen oder die Informationen, die Sie für notwendig erachten, in L1/L2-Schemen darstellen.

Wichtig!

Ein Netzwerkingenieur kann natürlich die Feinheiten und Standards von TK-Systemen, Rack-Typen, Arten von unterbrechungsfreien Stromversorgungen, was kalte und warme Gänge sind, die richtige Erdung usw. gut kennen, genauso gut wie er im Prinzip die Physik elementarer Teilchen oder C++ kennen kann. Aber man muss verstehen, dass das alles nicht sein Fachgebiet ist.

Deshalb ist es eine gute Praxis, für Aufgaben im Zusammenhang mit der Installation, Verbindung, Aufrechterhaltung der Funktionsfähigkeit von Geräten sowie der physischen Verkabelung entweder spezialisierte Abteilungen oder spezialisierte Personen zu haben. Normalerweise sind dies Ingenieure für Rechenzentren, und für Büros gibt es Helpdesk.

Wenn solche Abteilungen in Ihrem Unternehmen vorgesehen sind, dann ist die Faltung des physischen Verkabelungsprotokolls nicht Ihre Aufgabe, und Sie können sich auf die Beschreibung an der Schnittstelle und das administrative Abschalten ungenutzter Ports beschränken.

Netzwerkschemas

Es gibt keinen universellen Ansatz zum Zeichnen von Schemen.

Das Wichtigste ist, dass die Schemen ein Verständnis dafür vermitteln sollten, wie der Verkehr fließt, durch welche logischen und physischen Elemente Ihres Netzwerks.

Unter physischen Elementen verstehen wir

• aktives Equipment
• Schnittstellen/Ports der aktiven Geräte

Unter logischen —

• logische Geräte (N7K VDC, Palo Alto VSYS, …)
• VRF
• VLANs
• Subnetzschnittstellen
• Tunnel
• Zonen
• …

Wenn Ihr Netzwerk nicht ganz elementar ist, wird es aus verschiedenen Segmenten bestehen.
Zum Beispiel

• Rechenzentrum
• Internet
• WAN
• Fernzugriff
• Büro LAN
• DMZ
• …

Es ist sinnvoll, mehrere Diagramme zu haben, die sowohl eine Gesamtübersicht (wie der Verkehr zwischen all diesen Segmenten fließt) als auch detaillierte Beschreibungen jedes einzelnen Segments bieten.

Da es in modernen Netzwerken viele logische Ebenen geben kann, könnte ein guter (aber nicht notwendiger) Ansatz darin bestehen, verschiedene Diagramme für verschiedene Ebenen zu erstellen. Beispielsweise könnten im Fall eines Overlay-Ansatzes die folgenden Diagramme erstellt werden:

• ein Overlay
• L1/L2 Unterlage
• L3 Unterlage

Natürlich ist das wichtigste Diagramm, ohne das das Verständnis Ihres Designs nicht möglich wäre, das Routing-Diagramm.

Routing-Schema

Mindestens in diesem Diagramm sollte Folgendes dargestellt werden:

• welche Routing-Protokolle verwendet werden und wo
• grundlegende Informationen zu den Einstellungen des Routing-Protokolls (Bereich/AS-Nummer/Router-ID/…)
• auf welchen Geräten die Neuzuweisung erfolgt
• wo die Filterung und Aggregation von Routen stattfindet
• Informationen zur Standardroute

Oft ist auch das L2-Diagramm (OSI) nützlich.

L2-Schema (OSI)

In diesem Diagramm könnte folgende Informationen dargestellt werden:

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

Charakteristische Fehler bei der Planung

Beispiel für einen schlechten Ansatz beim Netzwerkaufbau.

Lassen Sie uns ein einfaches Beispiel für den Aufbau eines einfachen Büro-LANs betrachten.

Mit Erfahrung im Unterrichten von Telekommunikation an Studenten kann ich sagen, dass praktisch jeder Student bis zur Mitte des zweiten Semesters das notwendige Wissen hat (im Rahmen des Kurses, den ich gelehrt habe), um ein einfaches Büro-LAN einzurichten.

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

Alles wird funktionieren.

Doch bleiben dabei Fragen offen, die mit

• Sicherheit.
• Redundanz
• Netzwerkskalierung
• Leistung
• Bandbreite
• Zuverlässigkeit.
• …

Manchmal höre ich die Behauptung, dass ein Büro-LAN etwas ganz Einfaches ist, und das höre ich oft von Ingenieuren (und Managern), die sich mit allem Möglichen beschäftigen, aber nicht mit Netzwerken. Sie sprechen so überzeugt darüber, dass es nicht überraschend ist, wenn ein LAN von Personen erstellt wird, die nicht genügend Praxis und Kenntnisse haben und dabei grobe Fehler machen, die ich gleich näher beschreiben werde.

Typische Fehler im Design der L1 (OSI)

• Wenn Sie auch für die strukturierte Verkabelung verantwortlich sind, dann ist eines der unangenehmsten Erben, die Sie erhalten können, eine sorglose und schlecht durchdachte Verkabelung.

Zu der L1-Kategorie würde ich auch Fehler zählen, die mit den Ressourcen der verwendeten Geräte zu tun haben, zum Beispiel:

• unzureichende Bandbreite
• unzureichlicher TCAM auf der Hardware (oder ineffiziente Nutzung)
• unzureichende Leistung (betrifft häufig Firewalls)

Typische Fehler im Design der L2 (OSI)

Oft werden, wenn es kein gutes Verständnis dafür gibt, wie STP funktioniert und welche potenziellen Probleme es mit sich bringt, Switches chaotisch, mit den Standardeinstellungen, ohne zusätzliche STP-Tuning verbunden.

Infolgedessen haben wir oft Folgendes:

• einen großen STP-Durchmesser im Netzwerk, was zu Broadcast-Stürmen führen kann.
• Der STP-Root wird zufällig (basierend auf der MAC-Adresse) bestimmt und der Datenverkehrsweg wird suboptimal sein.
• Ports, die mit Hosts verbunden sind, werden nicht als Edge (portfast) konfiguriert, was zu einer Neuberechnung des STP beim Ein- und Ausschalten der Endstationen führt.
• Das Netzwerk wird nicht auf L1/L2-Ebene segmentiert, sodass Probleme mit einem Switch (z.B. Überlastung der Stromversorgung) zu einer Neuberechnung der STP-Topologie und zum Stillstand des Datenverkehrs in allen VLANs auf allen Switches führen, auch im kritischen Segment für die Servicekontinuität.

Beispiele für Designfehler in L3 (OSI)

Einige typische Fehler von angehenden Netzwerkern:

• häufige (oder ausschließliche) Nutzung von statischem Routing
• Verwendung von für das Design suboptimalen Routing-Protokollen
• suboptimale logische Segmentierung des Netzwerks
• suboptimale Nutzung des Adressraums, die Aggregation von Routen nicht ermöglicht
• Fehlen von Backup-Routen
• Fehlen von Redundanz für das Default Gateway
• asymmetrisches Routing bei der Umstrukturierung von Routen (kann kritisch sein im Falle von NAT/PAT, stateful Firewalls)
• Probleme mit der MTU
• Bei der Umstrukturierung von Routen geht der Datenverkehr durch andere Sicherheitszonen oder sogar durch andere Firewalls, was dazu führt, dass dieser Verkehr abgelehnt wird.
• schlechte Skalierbarkeit der Topologie

Bewertungskriterien für Designqualität

Wenn wir über Optimalität/Nicht-Optimalität sprechen, müssen wir verstehen, aus der Perspektive welcher Kriterien wir dies bewerten können. Meiner Meinung nach sind die bedeutendsten (aber nicht alle) Kriterien (und ihre Entschlüsselung im Zusammenhang mit Routing-Protokollen):

• Skalierbarkeit (scalability)
  Zum Beispiel haben Sie beschlossen, ein weiteres Rechenzentrum hinzuzufügen. Wie einfach können Sie das tun?
• Verwaltungsfreundlichkeit (managability)
  Wie einfach und sicher werden operationale Änderungen vorgenommen, z. B. die Ankündigung eines neuen Netzes oder das Filtern von Routen?
• Verfügbarkeit (availability)
  Wie viel Prozent der Zeit bietet Ihr System das erforderliche Serviceniveau?
• Sicherheit (security)
  Wie sicher sind die übertragenen Daten?
• der Preis

Änderungen

Das Hauptprinzip in dieser Phase kann durch die Formel "nicht schaden" ausgedrückt werden.
Daher, selbst wenn Sie mit dem Design und der gewählten Implementierung (Konfiguration) nicht ganz einverstanden sind, ist es nicht immer sinnvoll, Änderungen vorzunehmen. Ein vernünftiger Ansatz besteht darin, alle identifizierten Probleme nach zwei Kriterien zu priorisieren:

• Wie leicht kann dieses Problem behoben werden?
• Wie groß ist das Risiko, das es mit sich bringt?

Zuerst sollten Sie das beseitigen, was derzeit das Serviceniveau unter das akzeptable Niveau senkt, z. B. Probleme, die zu Paketverlusten führen. Beseitigen Sie dann das, was am einfachsten und sichersten behoben werden kann, in absteigender Reihenfolge der Risikogefährdung (von Problemen im Design oder in der Konfiguration, die große Risiken bergen, zu geringeren).

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

Quelle: habr.com