Dieser Artikel ist der zweite in einer Reihe von Artikeln mit dem Titel „So nehmen Sie die Netzwerkinfrastruktur unter Ihre Kontrolle“. Den Inhalt aller Artikel der Reihe und Links finden Sie hier .
Unser Ziel in dieser Phase ist es, die Dokumentation und Konfiguration zu bereinigen.
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 - der dritte Teil wird diesem Thema gewidmet sein.
Die Schwierigkeit, die Aufgabe in dieser Phase zu erledigen, ist natürlich von Unternehmen zu Unternehmen sehr unterschiedlich.
Die ideale Situation ist wann
- Ihr Netzwerk wurde gemäß dem Projekt erstellt und Sie verfügen über einen vollständigen Satz von Dokumenten
- Ihr Unternehmen hat einen Prozess zur Überwachung und Verwaltung von Änderungen für das Netzwerk implementiert
- In Übereinstimmung mit diesem Prozess verfügen Sie über Dokumente (einschließlich aller erforderlichen Schemata), die vollständige Informationen über den aktuellen Stand der Dinge enthalten
In diesem Fall ist Ihre Aufgabe recht einfach. Sie sollten die Dokumente studieren und sich alle vorgenommenen Änderungen ansehen.
Im schlimmsten Fall haben Sie
- ein Netzwerk, das ohne Projekt, ohne Plan, ohne Koordination von Ingenieuren ohne ausreichendes Qualifikationsniveau erstellt wurde,
- mit chaotischen, undokumentierten Veränderungen, mit viel „Müll“ und suboptimalen Lösungen
Es ist klar, dass Ihre Situation irgendwo dazwischen liegt, aber leider ist es in dieser Größenordnung besser - schlimmer mit einer hohen Wahrscheinlichkeit, Sie werden näher am schlimmsten Ende sein.
In diesem Fall benötigen Sie auch die Fähigkeit, Gedanken zu lesen, da Sie lernen müssen, zu verstehen, was die „Designer“ tun wollten, ihre Logik wiederherzustellen, das zu beenden, was nicht fertig war, und den „Müll“ zu entfernen.
Und natürlich müssen Sie ihre Fehler stoppen, das Design (zu diesem Zeitpunkt so wenig wie möglich) ändern und die Schaltung ändern oder neu erstellen.
Dieser Artikel soll in keiner Weise umfassend sein. Hier werde ich nur allgemeine Prinzipien beschreiben und auf einige allgemeine Probleme eingehen, die angegangen werden müssen.
Satz von Dokumenten
Beginnen wir mit einem Beispiel.
Im Folgenden sind einige der Dokumente aufgeführt, die Cisco Systems normalerweise im Design erstellt.
CR - Kundenspezifische Anforderungen, Kundenanforderungen (technische Zuordnung).
Es wird zusammen mit dem Kunden erstellt und definiert die Netzwerkanforderungen.
HLD - High Level Design, ein High Level Design basierend auf Netzwerkanforderungen (CR). Das Dokument erläutert und begründet die getroffenen Architekturentscheidungen (Topologie, Protokolle, Geräteauswahl, ...). HLD enthält keine Designdetails, z. B. zu den verwendeten Schnittstellen und IP-Adressen. Auch die spezifische Gerätekonfiguration wird hier nicht behandelt. Dieses Dokument soll vielmehr die wichtigsten Designkonzepte für das technische Management des Kunden erläutern.
LLD - Low Level Design, Low Level Design basierend auf High Level (HLD).
Es sollte alle Details enthalten, die für die Implementierung des Projekts erforderlich sind, z. B. Informationen zum Anschließen und Konfigurieren der Geräte. Dies ist eine vollständige Anleitung zur Entwurfsimplementierung. Dieses Dokument sollte auch von nicht sehr qualifiziertem Personal ausreichende Informationen für seine Umsetzung enthalten.
Beispielsweise können IP-Adressen, AS-Nummern und Verkabelungen in separaten Dokumenten wie NIP (Network Implementation Plan) „herausgenommen“ werden.
Der Netzwerkaufbau beginnt nach der Erstellung dieser Dokumente und erfolgt in strikter Übereinstimmung mit diesen und wird dann vom Kunden (Tests) auf Übereinstimmung mit dem Design überprüft.
Natürlich können unterschiedliche Integratoren, unterschiedliche Kunden, in unterschiedlichen Ländern die Anforderungen an die Projektdokumentation unterschiedlich sein. Aber ich möchte Formalitäten vermeiden und das Thema in der Sache prüfen. In dieser Phase geht es nicht um Design, sondern darum, die Dinge in Ordnung zu bringen. Wir benötigen eine Reihe von Dokumenten (Schemata, Tabellen, Beschreibungen ...), die ausreichen, um unsere Aufgaben zu erfüllen.
Und meiner Meinung nach gibt es ein bestimmtes absolutes Minimum, ohne das es unmöglich ist, das Netzwerk effektiv zu steuern.
Dies sind die folgenden Dokumente:
- Schema (Protokoll) der physischen Vermittlung (Verkabelung)
- Netzwerkschaltung oder Schaltungen mit signifikanten L2 / L3-Informationen
Physikalisches Schaltschema
In einigen kleinen Unternehmen liegt die Verantwortung für die Installation von Geräten und die physische Verkabelung in der Verantwortung der Netzwerktechniker.
In diesem Fall wird das Problem teilweise durch den folgenden Ansatz gelöst.
- Verwenden Sie die Beschreibung auf der Schnittstelle, um zu beschreiben, was damit verbunden ist
- Fahren Sie alle nicht verbundenen Ports von Netzwerkgeräten administrativ herunter
Dies gibt Ihnen die Möglichkeit, selbst bei einem Problem mit der Verbindung (wenn cdp oder lldp auf dieser Schnittstelle nicht funktioniert) schnell festzustellen, was mit diesem Port verbunden ist.
Sie können auch leicht erkennen, welche Ports belegt und welche frei sind, was für die Planung von Verbindungen für neue Netzwerkgeräte, Server oder Workstations erforderlich ist.
Es ist jedoch klar, dass Sie den Zugriff auf diese Informationen verlieren, wenn Sie den Zugriff auf Geräte verlieren. Darüber hinaus können Sie auf diese Weise keine so wichtigen Informationen wie die Art der Ausrüstung, den Stromverbrauch, die Anzahl der Anschlüsse, das Rack, die Patch-Panels und den Ort (an welches Rack / Patch-Panel) anschließen, an dem sie angeschlossen sind . Daher ist eine zusätzliche Dokumentation (nicht nur Hardwarebeschreibungen) sehr nützlich.
Die ideale Option ist die Verwendung von Anwendungen, die für diese Art von Informationen entwickelt wurden. Sie können sich jedoch auf einfache Tabellen beschränken (z. B. in Excel) oder die Informationen anzeigen, die Sie in L1 / L2-Schemata für erforderlich halten.
Wichtig!
Ein Netzwerktechniker kann natürlich die Feinheiten und Standards von SCS, Arten von Racks, Arten von unterbrechungsfreien Stromversorgungen, was ein kalter und heißer Korridor ist, eine ordnungsgemäße Erdung kennen ... genau wie er im Prinzip Teilchenphysik oder C ++ kennen kann. Man muss jedoch verstehen, dass dies alles nicht sein Wissensgebiet ist.
Daher ist es empfehlenswert, spezielle Abteilungen oder Mitarbeiter zu haben, um Probleme im Zusammenhang mit der Installation, dem Anschluss, der Wartung der Geräteleistung sowie dem physischen Schalten zu lösen. In der Regel handelt es sich bei Rechenzentren um Rechenzentrumsingenieure und im Büro um einen Helpdesk.
Wenn solche Einheiten in Ihrem Unternehmen bereitgestellt werden, sind die Probleme beim Verwalten eines physischen Switching-Protokolls nicht Ihre Aufgabe, und Sie können sich darauf beschränken, nur auf der Schnittstelle zu beschreiben und nicht verwendete Ports administrativ herunterzufahren.
Netzwerkdiagramme
Es gibt keinen universellen Ansatz für Zeichnungsschemata.
Am wichtigsten ist, dass die Schemata ein Verständnis dafür vermitteln, wie der Datenverkehr durch welche logischen und physischen Elemente Ihres Netzwerks geleitet wird.
Mit physikalischen Elementen meinen wir
- aktive Ausrüstung
- Schnittstellen / Ports aktiver Geräte
Unter dem logischen -
- logische Geräte (N7K VDC, Palo Alto VSYS, ...)
- VRF
- Vilanas
- Subschnittstellen
- Tunnel
- Zonen
- ...
Wenn Ihr Netzwerk nicht vollständig elementar ist, besteht es aus verschiedenen Segmenten.
Zum Beispiel
- Rechenzentrum
- das Internet
- Wan
- Fernzugriff
- Büro LAN
- Dmz
- ...
Es wäre sinnvoll, mehrere Schemata zu haben, die sowohl ein allgemeines Bild (wie der Verkehr zwischen all diesen Segmenten verläuft) als auch eine detaillierte Erläuterung jedes einzelnen Segments liefern.
Da moderne Netzwerke viele logische Ebenen haben können, ist es möglich, dass ein guter (aber nicht obligatorischer) Ansatz darin besteht, unterschiedliche Schemata für unterschiedliche Ebenen zu erstellen, beispielsweise im Fall eines Overlay-Ansatzes, dies können die folgenden Schemata sein:
- Overlay
- L1 / L2 Unterlage
- L3 Unterlage
Das wichtigste Schema, ohne das es unmöglich ist, die Idee Ihres Entwurfs zu verstehen, ist natürlich ein Routing-Schema.
Routing-Schema
Dieses Diagramm sollte mindestens reflektieren
- Welche Routing-Protokolle und wo werden verwendet?
- Grundlegende Informationen zu den Einstellungen des Routing-Protokolls (Bereich / AS-Nummer / Router-ID / ...)
- auf welchen Geräten erfolgt eine Umverteilung
- Hier erfolgt die Routenfilterung und -aggregation
- Standardrouteninformationen
Ebenfalls häufig nützlich ist die L2-Schaltung (OSI).
L2-Schaltung (OSI)
Die folgenden Informationen können in diesem Diagramm wiedergegeben werden:
- was für ein vlan
- Welche Ports sind Trunk-Ports?
- Welche Ports werden im Ether-Channel (Port-Channel), dem virtuellen Port-Channel, zusammengefasst?
- Welche STP-Protokolle und auf welchen Geräten werden verwendet?
- STP-Haupteinstellungen: Root / Root-Backup, STP-Kosten, Portpriorität
- erweiterte STP-Einstellungen: BPDU Guard / Filter, Root Guard ...
Typische Konstruktionsfehler
Ein Beispiel für einen schlechten Ansatz beim Aufbau eines Netzwerks.
Nehmen wir ein einfaches Beispiel für den Aufbau eines einfachen Office-LAN.
Ich habe Erfahrung im Unterrichten von Telekommunikationsunterricht für Studenten und kann sagen, dass praktisch jeder Student bis zur Mitte des zweiten Semesters über die erforderlichen Kenntnisse (als Teil des von mir unterrichteten Kurses) verfügt, um ein einfaches Office-LAN zu konfigurieren.
Was ist schwierig, Switches miteinander zu verbinden, VLAN- und SVI-Schnittstellen zu konfigurieren (bei L3-Switches) und statisches Routing einzurichten?
Alles wird funktionieren.
Aber gleichzeitig Probleme im Zusammenhang mit
- Sicherheit
- Reservierung
- Netzwerkskalierung
- Leistung
- Bandbreite
- Zuverlässigkeit
- ...
Manchmal höre ich die Aussage, dass ein Office-LAN etwas sehr Einfaches ist, und ich höre es normalerweise von Ingenieuren (und Managern), die alles tun, aber keine Netzwerke, und sie sagen es so sicher, dass es nicht überrascht, wenn das LAN wird von Menschen mit unzureichender Praxis und unzureichendem Wissen gemacht und wird mit ungefähr den Fehlern gemacht, die ich unten beschreiben werde.
Häufige Design L1 Layer Errors (OSI)
- Wenn Sie dennoch verantwortlich sind, auch für SCS, dann ist eines der unangenehmsten Vermächtnisse, das Sie möglicherweise bekommen, unachtsames und gedankenloses Umschalten.
Um L1 einzugeben, würde ich außerdem Fehler klassifizieren, die sich auf die Ressourcen der verwendeten Geräte beziehen, z.
- unzureichende Bandbreite
- unzureichendes TCAM auf dem Gerät (oder dessen ineffiziente Verwendung)
- unzureichende Leistung (bezieht sich oft auf Firewalls)
Häufige Design L2 Layer Errors (OSI)
Wenn nicht genau bekannt ist, wie STP funktioniert und welche potenziellen Probleme damit verbunden sind, werden die Switches häufig mit Standardeinstellungen zufällig verbunden, ohne dass STP zusätzlich eingestellt werden muss.
Infolgedessen haben wir oft Folgendes
- großer STP-Durchmesser des Netzwerks, der zu Broadcast-Stürmen führen kann
- Der STP-Stamm wird zufällig bestimmt (basierend auf der Mac-Adresse) und der Verkehrspfad ist suboptimal
- Mit Hosts verbundene Ports werden nicht als Edge (Portfast) konfiguriert, was zu einer Neuberechnung von STP führt, wenn Endpunkte ein- oder ausgeschaltet werden
- Das Netzwerk wird nicht auf L1 / L2-Ebene segmentiert, wodurch Probleme mit einem Switch (z. B. Stromüberlastung) zu einer Neuberechnung der STP-Topologie und zum Stoppen des Datenverkehrs in allen VLANs auf allen Switches führen (auch unter dem Gesichtspunkt der Kontinuität kritisch) Dienstleistungssegment)
L3 Design Error Beispiele (OSI)
Einige typische Fehler, die unerfahrene Netzwerker machen:
- häufige Verwendung (oder nur Verwendung) von statischem Routing
- Verwendung von Routing-Protokollen, die für dieses Design nicht optimal sind
- suboptimale logische Netzwerksegmentierung
- Nicht optimale Nutzung des Adressraums, die keine Routenaggregation zulässt
- Mangel an Backup-Routen
- Mangel an Redundanz für Standard-Gateway
- asymmetrisches Routing beim Neuerstellen von Routen (kann bei NAT / PAT, Statefull Firewalls, kritisch sein)
- Probleme mit MTU
- Beim Wiederaufbau von Routen wird der Verkehr durch andere Sicherheitszonen oder sogar andere Firewalls geleitet, was dazu führt, dass dieser Verkehr abnimmt
- schlechte Skalierbarkeit der Topologie
Kriterien für die Bewertung der Entwurfsqualität
Wenn wir über Optimalität / nicht Optimalität sprechen, müssen wir verstehen, nach welchen Kriterien wir dies bewerten können. Hier aus meiner Sicht die wichtigsten (aber nicht alle) Kriterien (und Entschlüsselung in Bezug auf Routing-Protokolle):
- Skalierbarkeit
Sie möchten beispielsweise ein weiteres Rechenzentrum hinzufügen. Wie einfach du das kannst. - Bequemlichkeit im Management (Verwaltbarkeit)
Wie einfach und sicher sind betriebliche Änderungen wie 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.
Selbst wenn Sie mit dem Design und der gewählten Implementierung (Konfiguration) nicht ganz einverstanden sind, ist es daher nicht immer ratsam, Änderungen vorzunehmen. Ein vernünftiger Ansatz besteht darin, alle identifizierten Probleme auf zwei Arten einzustufen:
- wie einfach dieses Problem behoben werden kann
- Wie viel Risiko trägt sie?
Zunächst muss beseitigt werden, was in der gegenwärtigen Zeit das Niveau des bereitgestellten Dienstes unter das zulässige Maß reduziert, beispielsweise Probleme, die zu Paketverlust führen. Beseitigen Sie dann das, was am einfachsten und sichersten zu beseitigen ist, um die Schwere des Risikos zu verringern (von Entwurfs- oder Konfigurationsproblemen, die größere Risiken mit sich bringen, bis hin zu kleineren).
Perfektionismus in diesem Stadium kann schädlich sein. Bringen Sie das Design in einen zufriedenstellenden Zustand und synchronisieren Sie die Netzwerkkonfiguration entsprechend.