Wie Sie Ihre Netzwerk-Infrastruktur in den Griff bekommen. Zweites Kapitel. Aufräumen und Dokumentation

Dieser Artikel ist der zweite Teil einer Reihe von Artikeln über "Wie Sie Ihre Netzwerk-Infrastruktur in den Griff bekommen". Das Inhaltsverzeichnis aller Artikel der 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 über das notwendige Dokumentenpaket verfügen und ein Netzwerk, das entsprechend konfiguriert ist.

Jetzt werden wir nicht über die Sicherheitsüberprüfung sprechen – diesem Thema wird der dritte Teil gewidmet sein.

Die Schwierigkeit der Aufgabe, die in dieser Phase zu bewältigen ist, variiert natürlich stark von Unternehmen zu Unternehmen.

Die ideale Situation ist, wenn

• Ihr Netzwerk entsprechend dem Projekt erstellt wurde und Sie ein vollständiges Dokumentationspaket haben
• in Ihrem Unternehmen ein Änderungsmanagement- und Kontrollprozess implementiert wurde für das Netzwerk
• und Sie gemäß diesem Prozess über Dokumente (einschließlich aller notwendigen Diagramme) verfügen, die vollständige Informationen über den aktuellen Stand der Dinge bereitstellen.

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

Im schlimmsten Fall haben Sie es mit

• einem Netzwerk zu tun, das ohne Planung, ohne Konzept und von Ingenieuren ohne ausreichende Qualifikationen erstellt wurde,
• mit chaotischen, undocumented Änderungen, einer Vielzahl von „Müll“ und suboptimalen Lösungen.

Es ist klar, dass Sie sich irgendwo dazwischen befinden, aber leider werden Sie mit hoher Wahrscheinlichkeit näher am schlechtesten Ende dieser Skala sein.

In diesem Fall werden Sie auch die Fähigkeit benötigen, Gedanken zu lesen, da Sie lernen müssen, zu verstehen, was die „Designer“ erreichen wollten, ihre Logik zu rekonstruieren, Unvollendetes fertigzustellen und „Müll“ zu entfernen.
Und natürlich müssen Sie deren Fehler beheben, das Design (in diesem Stadium möglichst minimal) ändern und die Pläne anpassen oder neu erstellen.

Dieser Artikel erhebt keineswegs den Anspruch auf Vollständigkeit. Ich werde hier nur die allgemeinen Prinzipien skizzieren und einige verbreitete Probleme ansprechen, die gelöst werden müssen.

Dokumentenset

Lassen Sie uns mit einem Beispiel beginnen.

Nachfolgend sind einige Dokumente aufgeführt, die bei der Planung in der Firma Cisco Systems erstellt werden.

CR – Customer Requirements, Kundenanforderungen (Lastenheft).
Wird gemeinsam mit dem Auftraggeber erstellt und definiert die Anforderungen an das Netzwerk.

HLD – High Level Design, hoher Entwurf auf der Grundlage der Netzwerk-Requirements (CR). Dieses Dokument erläutert und begründet die getroffenen Architekturentscheidungen (Topologie, Protokolle, Geräteauswahl, …). HLD enthält keine Details zum Design, wie etwa zu verwendeten Schnittstellen oder IP-Adressen. Auch die spezifische Konfiguration der Hardware wird hier nicht behandelt. Dieses Dokument dient eher dazu, dem technischen Management des Kunden die wesentlichen Designkonzepte zu erklären.

LLD – Low Level Design, detaillierter Entwurf basierend auf dem High-Level Design (HLD).
Es sollte alle notwendigen Details für die Umsetzung des Projekts enthalten, wie Informationen zum Anschließen und Konfigurieren der Hardware. Dies ist eine vollständige Anleitung zur Umsetzung des Designs. Dieses Dokument sollte ausreichende Informationen bieten, damit auch weniger qualifiziertes Personal es umsetzen kann.

Bestimmte Aspekte, wie IP-Adressen, AS-Nummern und das physische Verkabelungsschema, können in separate Dokumente, wie NIP (Network Implementation Plan), ausgelagert werden.

Der Netzwerkaufbau beginnt nach der Erstellung dieser Dokumente und erfolgt in strikter Übereinstimmung mit ihnen, gefolgt von Tests durch den Kunden zur Überprüfung der Übereinstimmung mit dem Entwurf.

Natürlich können die Anforderungen an die Projektdokumentation je nach Integrator, Kunde und Land unterschiedlich sein. Dennoch sollte es um die Sache selbst gehen, nicht um formale Aspekte. Diese Phase dient nicht dem Design, sondern der Ordnung, und wir benötigen ein ausreichendes Set an Dokumenten (Schemata, Tabellen, Beschreibungen…), um unsere Aufgaben zu erfüllen.

Meiner Meinung nach gibt es ein gewisses absolutes Minimum, ohne das eine effektive Netzüberwachung nicht möglich ist.

Folgende Dokumente sind notwendig:

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

Schema der physischen Verkabelung

In einigen kleinen Unternehmen liegen die Aufgaben in Bezug auf die Installation von Geräten und die physische Verkabelung in der Verantwortung von Netzwerkingenieuren.

In diesem Fall kann das Problem teilweise mit folgendem Ansatz gelöst werden.

• verwendet Sie die Beschreibung im Interface, um zu erläutern, was angeschlossen ist.
• deaktivieren Sie administrativ (shutdown) alle nicht angeschlossenen Ports des Netzwerkgeräts.

Dies ermöglicht Ihnen, auch bei Problemen mit der Verbindung (wenn auf diesem Interface cdp oder lldp nicht funktioniert), schnell zu erkennen, was an diesem Port angeschlossen ist.
Außerdem können Sie leicht sehen, welche Ports belegt sind und welche frei sind, was für die Planung der Anschlüsse neuer Netzwerkgeräte, Server oder Arbeitsstationen nötig ist.

Es ist jedoch klar, dass Sie, wenn Sie den Zugriff auf die Geräte verlieren, auch den Zugriff auf diese Informationen verlieren. Zudem können Sie auf diese Weise wichtige Informationen wie welches Gerät, mit welchem Stromverbrauch, mit wie vielen Ports, in welchem Rack es sich befindet, welche Patch-Panels vorhanden sind und wohin sie (in welches Rack/Patch-Panel) verkabelt sind, nicht protokollieren. Daher ist eine zusätzliche Dokumentation (nicht nur Beschreibungen auf den Geräten) äußerst hilfreich.

Die ideale Lösung ist die Verwendung von Anwendungen, die speziell für die Bearbeitung dieser Art von Informationen entwickelt wurden. Alternativ können auch einfache Tabellen (zum Beispiel in Excel) verwendet oder die Informationen, die Sie für notwendig erachten, in L1/L2-Schemata dargestellt werden.

Wichtig!

Ein Netzwerkingenieur kann natürlich die Feinheiten und Standards der strukturierten Verkabelung, die verschiedenen Racktypen, die Arten von unterbrechungsfreien Stromversorgungen, sowie die Konzepte von kalten und warmen Gängen ziemlich gut verstehen und auch wissen, wie man eine ordnungsgemäße Erdung durchführt. Genauso könnte er grundsätzlich die Physik der Elementarteilchen oder C++ kennen. Es ist jedoch wichtig zu verstehen, dass dies nicht sein Fachgebiet ist.

Daher ist es eine gute Praxis, für die Aufgaben, die mit der Installation, dem Anschluss und der Wartung von Geräten sowie mit der physischen Verkabelung verbunden sind, spezielle Abteilungen oder ausgewiesene Personen zu haben. In der Regel sind dies im Rechenzentrum die Rechenzentrumsingenieure und im Büro der Helpdesk.

Wenn solche Abteilungen in Ihrem Unternehmen vorhanden sind, liegt die Aufgabenstellung zur Protokollierung des physischen Switchings nicht bei Ihnen. Sie können sich auf die Beschreibung im Interface und das administrative Deaktivieren nicht genutzter Ports beschränken.

Netzwerkschemata

Es gibt keinen universellen Ansatz zum Zeichnen von Schemen.

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

Unter physischen Elementen verstehen wir

• aktive Geräte
• Schnittstellen/Ports aktiver Geräte

Unter logischen —

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

Wenn Ihr Netzwerk nicht völlig einfach 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 das Gesamtbild (wie der Verkehr zwischen all diesen Segmenten fließt) als auch eine detaillierte Erklärung jedes einzelnen Segments geben.

Da es in modernen Netzwerken viele logische Ebenen geben kann, ist es möglicherweise ratsam (aber nicht verpflichtend), verschiedene Diagramme für verschiedene Ebenen zu erstellen. Zum Beispiel könnten im Fall eines Overlay-Ansatzes folgende Diagramme verwendet werden:

• Overlay
• L1/L2 Unterlage
• L3 Unterlage

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

Routing-Diagramm

Mindestens sollte in diesem Diagramm dargestellt sein

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

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

L2-Diagramm (OSI)

In diesem Diagramm könnten folgende Informationen dargestellt werden:

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

Typische Fehler bei der Planung

Ein 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 meiner Erfahrung in der Vermittlung von Telekommunikation an Studierende kann ich sagen, dass nahezu jeder Studierende bis zur Mitte des zweiten Semesters über das notwendige Wissen (im Rahmen meines Kurses) verfügt, um ein einfaches Büro-LAN einzurichten.

Was ist so schwierig daran, Switches miteinander zu verbinden, VLANs zu konfigurieren, SVI-Interfaces (bei Layer-3-Switches) einzurichten und statisches Routing zu definieren?

Alles wird funktionieren.

Aber dabei bleiben Fragen wie

• Sicherheit
• Redundanz
• Netzwerkskalierung
• Leistung
• Durchsatz
• Zuverlässigkeit
• …

Manchmal höre ich die Behauptung, dass ein Büro-LAN etwas sehr Einfaches ist, und ich höre das normalerweise von Ingenieuren (und Managern), die mit allem Möglichen, aber nicht mit Netzwerken zu tun haben. Sie sprechen so selbstbewusst darüber, dass man sich nicht wundern sollte, wenn das LAN von Menschen erstellt wird, die über unzureichende Praxis und Kenntnisse verfügen und dabei typischerweise die Fehler machen, die ich gleich beschreiben werde.

Typische Designfehler auf L1-Ebene (OSI)

• Sollten Sie auch für die strukturierten Verkabelungssysteme verantwortlich sein, ist eines der unangenehmsten Erben, das Ihnen überlassen werden kann, die schlampige und undurchdachte Verkabelung.

Fehler der Kategorie L1 sind auch solche, die mit den Ressourcen der verwendeten Hardware verbunden sind, zum Beispiel:

• unzureichende Bandbreite
• unzureichender TCAM-Speicher auf der Hardware (oder ineffiziente Nutzung davon)
• unzureichende Leistung (betrifft oft Firewalls)

Typische Designfehler auf L2-Ebene (OSI)

Häufig, wenn kein gutes Verständnis darüber besteht, wie STP funktioniert und welche potenziellen Probleme es mit sich bringt, werden Switches chaotisch mit Standardkonfigurationen verbunden, ohne zusätzliche STP-Tuning.

Das Ergebnis ist oft Folgendes:

• ein großer STP-Durchmesser im Netzwerk, was zu Broadcast-Stürmen führen kann
• Das STP-Root wird zufällig bestimmt (basierend auf der MAC-Adresse), und der Verkehrspfad wird suboptimal sein
• Ports, die an Hosts angeschlossen sind, werden nicht als Edge (Portfast) konfiguriert, was zu einer STP-Neuberechnung beim Ein- und Ausschalten der Endgeräte führt.
• Das Netzwerk wird nicht auf L1/L2-Ebene segmentiert, was dazu führt, dass Probleme mit jedem Switch (z.B. Überlastung des Netzteils) die STP-Topologie neu berechnen und den Datenverkehr in allen VLANs auf allen Switches (einschließlich der kritischen Segmente für die Servicekontinuität) zum Stillstand bringen.

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

Einige typische Fehler von Anfängern in der Netzwerktechnik:

• Häufige Verwendung (oder ausschließliche Verwendung) von statischem Routing.
• Verwendung von für dieses Design suboptimalen Routing-Protokollen.
• Suboptimale logische Segmentierung des Netzwerks.
• Suboptimale Nutzung des Adressraums, die das Aggregieren von Routen verhindert.
• Fehlende Backup-Routen.
• Fehlende Redundanz für das Default Gateway.
• Asymmetrisches Routing beim Neuanordnen von Routen (kann kritisch sein bei NAT/PAT, stateful Firewalls).
• Probleme mit MTU.
• Beim Neuanordnen von Routen fließt der Datenverkehr durch andere Sicherheitszonen oder sogar andere Firewalls, was dazu führt, dass dieser Datenverkehr verworfen wird.
• Schlechte Skalierbarkeit der Topologie.

Kriterien zur Bewertung der Designqualität.

Wenn wir über Optimalität oder Nicht-Optimalität sprechen, müssen wir verstehen, nach welchen Kriterien wir dies bewerten können. Aus meiner Sicht sind die relevantesten (aber nicht alle) Kriterien (und ihre Erklärung im Hinblick auf Routing-Protokolle):

• Skalierbarkeit (scalability)
  Zum Beispiel haben Sie entschieden, ein weiteres Rechenzentrum hinzuzufügen. Wie einfach können Sie das umsetzen?
• Bedienbarkeit (managability)
  Wie einfach und sicher werden operationale Änderungen durchgeführt, zum Beispiel die Ankündigung eines neuen Netzwerks oder die Filterung von Routen?
• Verfügbarkeit (availability)
  Welcher Prozentsatz der Zeit bietet Ihr System das erforderliche Service-Level?
• Sicherheit (security)
  Wie sicher sind die übertragenen Daten?
• Preis

Änderungen

Das grundlegende Prinzip in diesem Zusammenhang lässt sich mit der Formel "do no harm" ausdrücken.
Deshalb ist es, selbst wenn Sie mit dem Design und der gewählten Implementierung (Konfiguration) nicht vollständig einverstanden sind, nicht immer sinnvoll, Änderungen vorzunehmen. Ein vernünftiger Ansatz ist, alle identifizierten Probleme nach zwei Kriterien zu bewerten:

• wie einfach dieses Problem behoben werden kann
• wie hoch das Risiko ist, das es mit sich bringt

Zunächst gilt es, die Faktoren zu beseitigen, die den aktuellen Servicelevel unter ein akzeptables Niveau reduzieren, beispielsweise Probleme, die zu Paketverlusten führen. Anschließend sollten die am leichtesten und sichersten zu lösenden Probleme in der Reihenfolge ihrer Risikoschwere angegangen werden (von gravierenden Design- oder Konfigurationsproblemen zu weniger kritischen).

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

Quelle: habr.com