OSPF-Konfigurationsmanagement mit SNMP

Download-Optionen

  • PDF     (178.2 KB)
    Mit Adobe Reader auf verschiedenen Geräten anzeigen
  • ePub     (103.0 KB)
    In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
Aktualisiert:15. September 2008
Dokument-ID:15408

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

Einführung

Das OSPF-Routing-Protokoll (Open Shortest Path First) ist in RFC 2328 OSPF Version 2 leavingcisco.com definiert. Ziel dieses Whitepapers ist die Bereitstellung eines prozeduralen Frameworks, das es Organisationen ermöglicht, Konfigurationsmanagementverfahren zu implementieren, um OSPF-Bereitstellungen anhand von OSPF-Designplänen zu überprüfen und die OSPF-Bereitstellung regelmäßig zu überprüfen, um die langfristige Konsistenz mit dem beabsichtigten Design sicherzustellen.

Dieses Whitepaper konzentriert sich auf die Konfigurationsmanagement-Funktionen des ITU-T definierten FCAPS-Modells (Fehler, Konfiguration, Abrechnung/Inventar, Leistung, Sicherheit). Das Konfigurationsmanagement wird von ITU-T M.3400 als Funktion definiert, die die Kontrolle über NEs (Netzwerkelemente), die Identifizierung, das Erfassen und die Bereitstellung von Daten übernimmt.

Die Informationen in diesem Whitepaper werden in mehreren der unten beschriebenen Hauptabschnitte vorgestellt.

Der Abschnitt OSPF-Hintergrund bietet einen technologischen Überblick über OSPF, einschließlich Hintergrundinformationen zu wichtigen Aspekten einer OSPF-Bereitstellung.

Der Abschnitt "Prozessdefinitionen" bietet eine Übersicht über die Prozessdefinitionen, die für das OSPF-Konfigurationsmanagement verwendet werden. Die Prozessdetails werden in Form von Zielen, Leistungsindikatoren, Inputs, Outputs und Einzelaufgaben beschrieben.

Der Abschnitt Aufgabendefinitionen enthält detaillierte Definitionen von Prozessaufgaben. Jede Aufgabe wird anhand der Ziele, Aufgabeneingaben, Aufgabenausgaben, der für die Ausführung der Aufgabe erforderlichen Ressourcen und der für die Aufgabenimplementierung erforderlichen beruflichen Qualifikationen beschrieben.

Der Abschnitt zur Datenidentifizierung beschreibt die Datenidentifizierung für OSPF. Bei der Datenidentifizierung wird die Quelle oder der Standort der Informationen berücksichtigt. Beispielsweise sind Informationen im System in der Simple Network Management Protocol (SNMP) Management Information Base (MIB), von Syslog generierten Protokolldateien oder in internen Datenstrukturen enthalten, auf die nur über die Befehlszeilenschnittstelle (CLI) zugegriffen werden kann.

Im Abschnitt Datenerfassung dieses Dokuments wird die Erfassung der OSPF-Daten beschrieben. Die Erfassung der Daten steht in engem Zusammenhang mit dem Speicherort der Daten. Beispielsweise werden SNMP MIB-Daten von mehreren Mechanismen erfasst, z. B. Traps, RMON-Alarme und -Ereignisse (Remote Monitoring) oder Polling. Die Daten, die von internen Datenstrukturen verwaltet werden, werden mithilfe von automatischen Skripts oder von einem Benutzer erfasst, der sich manuell beim System anmeldet, um den CLI-Befehl auszugeben und dann die Ausgabe aufzuzeichnen.

Der Abschnitt Datenpräsentation enthält Beispiele für die Darstellung der Daten in Berichtsformaten. Nachdem die Daten identifiziert und erfasst wurden, werden sie analysiert. Dieses Dokument enthält Beispielberichte, die zum Aufzeichnen und Vergleichen von OSPF-Konfigurationsdaten verwendet werden können.

Die Abschnitte Commercial and Public Internet Monitoring Tools, SNMP Polling Data und Example Data Collection Algorithms enthalten Informationen zur Entwicklung von Tools zur Implementierung des OSPF-Konfigurationsmanagementverfahrens.

OSPF-Hintergrund

OSPF ist ein internes Gateway-Protokoll, das zur Verwendung in einem einzigen autonomen System entwickelt wurde. OSPF nutzt eine auf Link-State- oder Shortest-Path First (SPF)-Technologie basierende Technologie im Vergleich zur Distanzvektor- oder Bellman-Ford-Technologie, die in Routing-Protokollen wie Routing Information Protocol (RIP) verwendet wird. Einzelne LSAs (Link-State Advertisements) beschreiben Teile der OSPF-Routing-Domäne, z. B. das gesamte autonome System. Diese LSAs werden durch eine Routing-Domäne geflutet und bilden die Link-State-Datenbank. Jeder Router in einer Domäne verfügt über eine identische Link-State-Datenbank. Die Synchronisierung von Link-State-Datenbanken wird mit einem zuverlässigen Flooding-Algorithmus aufrechterhalten. Aus der Link-State-Datenbank erstellt jeder Router eine Routing-Tabelle, indem er einen Shortest-Path-Tree berechnet, wobei der Root des Tree der berechnete Router selbst ist. Diese Berechnung wird allgemein als Dijkstra-Algorithmus bezeichnet.

LSAs sind klein, und jedes LSAs beschreibt einen kleinen Teil der OSPF-Routing-Domäne, und zwar die Nachbarschaft eines einzelnen Routers, die Nachbarschaft eines einzelnen Transit-Netzwerks, einer einzelnen Inter-Area-Route oder einer einzelnen externen Route.

In dieser Tabelle werden die wichtigsten Funktionen von OSPF definiert:

Funktion Beschreibung
Adjazenz Wenn Paare von OSPF-Routern an die Grenze stoßen, synchronisieren die beiden Router ihre Link-State-Datenbanken, indem sie Datenbankübersichten in Form von OSPF-Datenbankaustauschpaketen austauschen. Angrenzende Router synchronisieren dann ihre Link-State-Datenbanken mithilfe des zuverlässigen Flooding-Algorithmus. Router, die über serielle Leitungen angeschlossen sind, werden immer benachbarter. In Multi-Access-Netzwerken (Ethernets) werden alle Router, die mit dem Netzwerk verbunden sind, sowohl an den designierten Router (DR) als auch an den Backup-designierten Router (BDR) angeschlossen.
Festgelegter Router Wenn eine Notfallwiederherstellung in allen Multi-Access-Netzwerken gewählt wird, wird ein Netzwerk-LSA erstellt, das die lokale Umgebung des Netzwerks beschreibt. Sie spielt auch eine besondere Rolle im Flooding-Algorithmus, da alle Router im Netzwerk ihre Link-State-Datenbanken synchronisieren, indem sie während des Flooding-Prozesses LSAs an den und vom DR senden und empfangen.
designierter Backup-Router Wenn der aktuelle DR verschwindet, wird ein BDR in Multi-Access-Netzwerken gewählt, um den Übergang von DRs zu beschleunigen. Wenn der BDR die Rolle übernimmt, muss er nicht den Adjacency-Prozess im lokalen Netzwerk (LAN) durchlaufen. Der BDR ermöglicht es dem zuverlässigen Flooding-Algorithmus auch, in Abwesenheit des DR fortzufahren, bevor das Verschwinden des DR bemerkt wird.
Unterstützung für Multizugriffsnetzwerke ohne Broadcast-Funktion OSPF behandelt Netzwerke wie Frame Relay Public Data Networks (PDNs) wie LANs. Es sind jedoch zusätzliche Konfigurationsinformationen erforderlich, damit die Router, die mit diesen Netzwerken verbunden sind, einander zunächst finden können.
OSPF-Konfigurationsmanagementbereiche Mit OSPF können die autonomen Systeme in Bereiche aufgeteilt werden. Dies bietet einen zusätzlichen Routing-Schutz, sodass das Routing innerhalb eines Bereichs vor allen außerhalb des Bereichs liegenden Informationen geschützt ist. Durch die Aufteilung eines autonomen Systems in Bereiche werden die Kosten des Dijkstra-Verfahrens in Bezug auf CPU-Zyklen reduziert.
Virtuelle Links OSPF ermöglicht die Konfiguration virtueller Verbindungen und beseitigt dadurch topologische Einschränkungen bei Area Layouts in einem autonomen System.
Authentifizierung des Routing-Protokoll-Austauschs Jedes Mal, wenn ein OSPF-Router ein Routing-Protokoll-Paket empfängt, kann er das Paket optional authentifizieren, bevor er es weiter verarbeitet.
Flexible Routing-Metrik In OSPF werden ausgehende Router-Schnittstellen Kennzahlen zugewiesen. Die Kosten eines Pfads sind die Summe der Komponentenschnittstellen des Pfads. Die Routing-Metrik wird standardmäßig von der Bandbreite der Verbindung abgeleitet. Er kann vom Systemadministrator zugewiesen werden, um eine beliebige Kombination von Netzwerkmerkmalen wie Verzögerung, Bandbreite und Kosten anzugeben.
Mehrpfad-Gleiche-Kosten Wenn mehrere kostengünstigste Routen zu einem Ziel vorhanden sind, findet OSPF diese und lädt sie zum Laden des Datenverkehrs zum Ziel ein.
Subnetzunterstützung variabler Länge Unterstützt Subnetzmasken variabler Länge, indem eine Netzmaske mit jedem angegebenen Ziel mitgeführt wird.
Stufenbereichsunterstützung Um Router mit unzureichendem Speicher zu unterstützen, können Bereiche als Stubs konfiguriert werden. Externe LSAs werden nicht in Stub- und Stub-Bereiche überflutet. Das Routing zu externen Zielen in Stub-Bereichen basiert ausschließlich auf der Standardeinstellung.

Prozessdefinitionen

Eine Prozessdefinition ist eine zusammenhängende Reihe von Aktionen, Aktivitäten und Änderungen, die von Agenten ausgeführt werden, um einen Zweck zu erfüllen oder ein Ziel zu erreichen.

Prozesskontrolle ist der Planungs- und Regelungsprozess mit dem Ziel, einen Prozess effektiv und effizient durchzuführen.

Dies wird grafisch in der Abbildung unten gezeigt.

ospf_a.gif

Die Ergebnisse des Prozesses müssen betriebliche Normen erfüllen, die von einem Unternehmen definiert werden und auf Geschäftszielen basieren. Wenn der Prozess den Normen entspricht, wird der Prozess als effektiv angesehen, da er wiederholt, gemessen, verwaltet und zu den Geschäftszielen beiträgt. Werden die Aktivitäten mit einem minimalen Aufwand durchgeführt, gilt der Prozess ebenfalls als effizient.

Prozessbesitzer

Prozesse erstrecken sich über verschiedene organisatorische Grenzen. Daher ist es wichtig, einen einzigen Prozessverantwortlichen zu haben, der für die Definition des Prozesses verantwortlich ist. Der Eigentümer ist die zentrale Stelle für die Bestimmung und Berichterstattung, wenn der Prozess effektiv und effizient ist. Wenn der Prozess nicht effektiv oder effizient ist, steuert der Prozessinhaber die Änderung des Prozesses. Die Änderung des Prozesses unterliegt der Änderungskontrolle und den Überprüfungsprozessen.

Prozessziele

Anhand von Prozesszielen werden Richtung und Umfang für die Prozessdefinition festgelegt. Anhand von Zielen werden außerdem Kennzahlen definiert, anhand derer die Effektivität eines Prozesses gemessen wird.

Ziel dieses Prozesses ist es, ein Framework bereitzustellen, das die bereitgestellte Konfiguration einer OSPF-Implementierung anhand eines beabsichtigten Designs verifiziert und einen Mechanismus für die regelmäßige Überprüfung der OSPF-Bereitstellung bereitstellt, um die Konsistenz hinsichtlich des beabsichtigten Designs im Laufe der Zeit sicherzustellen.

Prozessleistungsindikatoren

Anhand von Prozessleistungsindikatoren wird die Effektivität der Prozessdefinition gemessen. Die Leistungsindikatoren sollten messbar und quantifizierbar sein. Die unten aufgeführten Leistungsindikatoren sind numerisch oder zeitlich gemessen. Leistungsindikatoren für den OSPF-Konfigurationsmanagementprozess werden wie folgt definiert:

  • Die Zeitdauer, die erforderlich ist, um den gesamten Prozess zu durchlaufen.

  • Die Häufigkeit der Ausführung, die erforderlich ist, um OSPF-Probleme proaktiv zu erkennen, bevor sie sich auf Benutzer auswirken.

  • Die mit der Ausführung des Prozesses verbundene Netzwerkauslastung.

  • Die Anzahl der vom Prozess empfohlenen Korrekturmaßnahmen.

  • Die Anzahl der infolge des Prozesses durchgeführten Korrekturmaßnahmen.

  • Die Dauer, die erforderlich ist, um Korrekturmaßnahmen durchzuführen.

  • Die Dauer, die erforderlich ist, um Korrekturmaßnahmen durchzuführen.

  • Der Rückstand bei den Korrekturmaßnahmen.

  • Die Ausfallzeiten, die auf OSPF-bezogene Probleme zurückzuführen sind.

  • Die Anzahl der Elemente, die in der Seed-Datei hinzugefügt, entfernt oder geändert wurden. Dies ist ein Zeichen für Genauigkeit und Stabilität.

Prozesseingaben

Anhand von Prozesseingaben werden Kriterien und Voraussetzungen für einen Prozess definiert. Häufig liefert die Identifizierung von Prozesseingaben Informationen zu externen Abhängigkeiten. Nachfolgend finden Sie eine Liste der Eingaben im Zusammenhang mit dem OSPF-Konfigurationsmanagement.

  • OSPF-Design-Dokumentation

  • Durch SNMP Polling erfasste OSPF-MIB-Daten

  • Syslog-Informationen

Prozessausgabe

Die Prozessausgaben werden wie folgt definiert:

  • OSPF-Konfigurationsberichte, die im Abschnitt Datenpräsentation definiert sind

  • OSPF-Konfigurationsempfehlungen für durchzuführende Korrekturmaßnahmen

Aufgabendefinitionen

In den folgenden Abschnitten werden die Initialisierungs- und iterativen Aufgaben im Zusammenhang mit dem OSPF-Konfigurationsmanagement definiert.

Initialisierungsaufgaben

Initialisierungsaufgaben werden einmal während der Implementierung des Prozesses ausgeführt und sollten nicht bei jeder Iteration des Prozesses ausgeführt werden.

Überprüfen der erforderlichen Aufgaben

Wenn bei der Überprüfung der erforderlichen Aufgaben festgestellt wird, dass eine der Aufgaben nicht implementiert ist oder nicht über ausreichende Informationen verfügt, um den Anforderungen dieses Verfahrens wirksam gerecht zu werden, sollte diese Tatsache vom Prozessinhaber dokumentiert und dem Management vorgelegt werden. In der folgenden Tabelle werden die erforderlichen Initialisierungsaufgaben beschrieben.

Erforderliche Aufgabe Beschreibung
Aufgabenziele und Beiträge
  1. Stellen Sie sicher, dass OSPF-Designdokumente vorhanden sind und dass die folgenden Informationen in der Netzwerkdesigndokumentation sofort verfügbar sind:
    1. Bereichsdefinitionen - Namen, Adressbereiche und Bereichstyp
    2. Identifikationen des Area Border Routers/Autonomous System Border Router (ABR/ASBR)
    3. DR/BDR-Identifizierungen
    4. Den Bereichen zugewiesene Internet Registry (IR)-Knoten und Schnittstellen
  2. Verwenden Sie eine SNMP-Standardkonfigurationsvorlage, um zu überprüfen, ob SNMP im Netzwerk konfiguriert wird.

    Hinweis: Dies wird später als Eingabe zum Erstellen der Seed-Datei verwendet.

  3. Verwenden Sie eine Syslog-Standardkonfigurationsvorlage, um zu überprüfen, ob Syslog im Netzwerk bereitgestellt wird.
Task-Ausgabe Die Aufgabenausgabe ist ein Statusbericht über den Zustand der erforderlichen Aufgaben. Wenn eine der unterstützenden Aufgaben als ineffektiv angesehen wird, sollte der Prozessinhaber eine Anfrage zur Aktualisierung der unterstützenden Prozesse stellen. Wenn die unterstützenden Prozesse nicht aktualisiert werden können, führen Sie eine Bewertung der Auswirkungen auf diesen Prozess durch.
Aufgabenrolle Kenntnisse der Netzwerktechniker

Seed-Datei erstellen

Beim OSPF-Konfigurationsmanagement-Prozess muss eine Seed-Datei verwendet werden, um eine Netzwerkerkennungsfunktion zu entfernen. Die Seed-Datei zeichnet den Satz von Routern auf, die vom OSPF-Prozess gesteuert werden, und wird auch als Koordinierungsstelle für die Change-Management-Prozesse in einer Organisation verwendet. Wenn beispielsweise neue Knoten in das Netzwerk eingegeben werden, müssen sie der OSPF-Seed-Datei hinzugefügt werden. Wenn die SNMP-Community-Namen aufgrund von Sicherheitsanforderungen geändert werden, müssen diese Änderungen in der Seed-Datei übernommen werden. In der folgenden Tabelle werden die Prozesse zum Erstellen einer Seed-Datei beschrieben.

Prozess Beschreibung
Aufgabenziele Erstellen Sie eine Seed-Datei, die zum Initialisieren der OSPF-Konfigurationsverwaltungssoftware verwendet wird. Die Formatierung der Seed-Datei hängt von den Ressourcen ab, die zur Implementierung des OSPF-Konfigurationsmanagementprozesses verwendet werden. Wenn benutzerdefinierte Skripts entwickelt werden, wird das Format der Seed-Datei durch das Softwaredesign definiert. Wenn ein Netzwerkmanagementsystem (NMS) verwendet wird, wird das Format der Seed-Datei in der NMS-Dokumentation definiert.
Task-Eingaben
  1. Formatieren Sie die Seed-Datei.
  2. Verwenden Sie die OSPF-Designdokumentation, um die folgenden Daten zu identifizieren:
    • IP-Adressen aller Knoten
    • SNMP Community-Strings
    • Telnet- und CLI-Anmeldekonten und Kennwörter
  3. Planen und/oder Kontaktnamen für den Netzwerkänderungs-Managementprozess.
Task-Ausgaben Eine Seed-Datei für den OSPF-Konfigurationsmanagementprozess.
Task-Ressourcen
  • Kommerzielles NMS-System
  • Maßgeschneidertes Software-System
  • Manueller Prozess - Melden Sie sich bei jedem Netzwerkelement an, geben Sie Befehlszeilen aus, und zeichnen Sie die Ausgabe auf.
Aufgabenrolle
  • NMS - Netzwerktechniker, NMS-Administrator und NMS-Skriptfähigkeiten
  • Benutzerdefinierte Skripte - Kenntnisse von Netzwerktechnikern und NMS-Skripts
  • Manuelle Prozesse - Netzwerktechniker.

Iterative Aufgaben

Iterative Aufgaben werden mit jeder Iteration des Prozesses ausgeführt, und ihre Häufigkeit wird bestimmt und geändert, um die Leistungsindikatoren zu verbessern.

Verwalten der Seed-Datei

Die Seed-Datei ist für die effektive Implementierung des OSPF-Konfigurationsmanagementprozesses unerlässlich. Daher muss der aktuelle Zustand der Seed-Datei aktiv verwaltet werden. Netzwerkänderungen, die sich auf den Inhalt der Seed-Datei auswirken, müssen vom OSPF-Verantwortlichen für den Konfigurationsmanagementprozess nachverfolgt werden.

Prozess Beschreibung
Aufgabenziele
  1. Beibehaltung der Währung der Seed-Datei durch die Nachverfolgung und Interaktion mit organisatorischen Funktionen, die das Verschieben, Hinzufügen, Ändern und/oder Ändern der Netzwerkkonfiguration steuern.
  2. Behalten Sie die Versionskontrolle und die Sicherungskontrolle für die Seed-Datei bei.
Task-Eingaben
  1. Informationen aus dem Änderungsmanagement, z. B. Verschiebungen, Hinzufügungen und Änderungen, die sich auf den Inhalt der Seed-Datei auswirken.
  2. Informationen aus Technik/Design, die sich auf den Inhalt der Seed-Datei auswirken.
Task-Ausgaben
  1. Wöchentlicher Bericht über den Status der Währung der Seed-Datei.
  2. Definition und Dokumentation, in der der Speicherort und die Wiederherstellungsverfahren für Sicherungen von Seed-Dateien beschrieben werden.
Task-Ressourcen
  • Kommerzielles NMS-System
  • Maßgeschneidertes Software-System
  • Manueller Prozess - Melden Sie sich bei jedem Netzwerkelement an, geben Sie Befehlszeilen aus, und zeichnen Sie die Ausgabe auf.
Aufgabenrolle
  • NMS - Netzwerktechniker, NMS-Administrator und NMS-Skriptfähigkeiten
  • Benutzerdefinierte Skripte - Kenntnisse von Netzwerktechnikern und NMS-Skripts
  • Manuelle Prozesse - Netzwerktechniker.

Führen Sie den OSPF-Scan aus.

Die beiden Schritte zum Ausführen der OSPF-Prüfung sind:

  1. Erfassen der Daten.

  2. Analysieren der Daten.

Je nachdem, wie der Prozess verwendet wird, variiert die Häufigkeit dieser beiden Schritte. Dieser Prozess kann beispielsweise verwendet werden, um Installationsänderungen zu überprüfen. In diesem Fall wird die Datenerfassung vor und nach der Änderung durchgeführt, und die Datenanalyse wird nach der Änderung durchgeführt, um den Erfolg der Änderung zu bestimmen.

Wenn dieser Prozess zum Überprüfen von Protokollen zum OSPF-Konfigurationsmanagement verwendet wird, hängt die Häufigkeit der Datenerfassung und -analyse von der Geschwindigkeit der Änderungen im Netzwerk ab. Wenn beispielsweise das Netzwerk stark verändert wird, werden die Designüberprüfungen einmal pro Woche durchgeführt. Wenn sich das Netzwerk nur geringfügig ändert, werden die Designüberprüfungen höchstens einmal im Monat durchgeführt.

Überprüfen Sie die OSPF-Berichte.

Das Format der OSPF-Konfigurationsmanagement-Berichte hängt von den Ressourcen ab, die zur Implementierung des OSPF-Konfigurationsmanagementprozesses verwendet werden. Die folgende Tabelle enthält Vorschläge für benutzerdefinierte Berichtsformate.

Bericht Format
Task-Eingaben Berichte zum OSPF-Konfigurationsmanagement finden Sie im Abschnitt Datenpräsentation in diesem Dokument.
Task-Ausgaben Wenn Probleme zwischen den Scan-Berichten und den logischen Entwurfsdatensätzen auftreten, muss entschieden werden, welches Element richtig und welches falsch ist. Der falsche Artikel sollte korrigiert werden. Dies kann eine Änderung der Entwurfsdatensätze oder eine Änderung der Reihenfolge des Netzwerks umfassen.
Task-Ressourcen
  • Kommerzielles NMS-System
  • Maßgeschneidertes Software-System
  • Manual (Manuell): Melden Sie sich bei jedem Netzwerkelement an, geben Sie Befehlszeilen aus, und zeichnen Sie die Ausgabe auf.
Aufgabenrolle
  • NMS - Netzwerktechniker, NMS-Administrator und NMS-Skriptfähigkeiten
  • Benutzerdefinierte Skripte - Kenntnisse von Netzwerktechnikern und NMS-Skripts
  • Manuelle Prozesse - Netzwerktechniker.

Datenidentifizierung

Allgemeine Datenmerkmale

Die folgende Tabelle beschreibt Daten, die auf das OSPF-Konfigurationsmanagement angewendet werden können.

Daten Beschreibung
OSPF-Bereiche Die folgenden Informationen beschreiben die angeschlossenen Bereiche des Routers:
  • Area-ID
  • Bereichsauthentifizierung
  • SPF-Ausführen
  • Anzahl der ABRs in einem Bereich
  • Anzahl der ASBRs in einem Bereich
  • Area LSA Count - Konsistenz zwischen Routern in einem Bereich
  • Area LSA Checksum - Konsistenz zwischen Routern im Bereich
  • Häufigkeit der Paketverluste aufgrund der Fehlerbehebung pro Bereich
  • Häufigkeit der Protokollpaketrückwürfe nach Routing-Prozess pro Bereich
  • Häufigkeit der Routing-Paketverwerfen aufgrund der Bedingung, dass keine Route gefunden wurde pro Bereich
OSPF-Schnittstellen Beschreibt eine Schnittstelle aus Sicht von OSPF, z. B.:
  • IP-Adresse
  • Area-ID
  • Verwaltungsstatus
  • OSPF-Metriken für die Schnittstelle
  • OSPF-Timer für die Schnittstelle
  • OSPF-Status
OSPF-Nachbarstatus Beschreibt einen OSPF-Nachbarn.
  • Nachbarrouter-ID
  • Nachbarstaat
  • Neighbor events (Nachbarereignisse): Die Anzahl der Statusänderungen der Nachbarbeziehung oder eines Fehlers.
  • Neighbor Reübertragung Queue (Warteschlange für erneute Übertragung): Die aktuelle Länge der Warteschlange für die erneute Übertragung.

SNMP-Datenidentifizierung

Cisco unterstützt derzeit die RFC 1253 OSPF Version 2 MIB leavingcisco.com . RFC 1253 enthält keine SNMP-Trap-Definitionen für OSPF. Die neueste Version der OSPF MIB ist RFC 1850 OSPF Version 2 leavingcisco.com . SNMP-Traps werden für OSPF in RFC 1850 definiert. RFC 1850 wird bei der Implementierung der OSPF-MIB durch Cisco nicht unterstützt.

Weitere Informationen finden Sie im Abschnitt SNMP Polling Data (SNMP-Polling-Daten) dieses Dokuments.

Auf der Seite Cisco Network Management Software finden Sie eine endgültige Liste der MIBs, die von welcher Plattform und Codeversion unterstützt werden.

RMON-Datenidentifizierung

Für dieses Verfahren sind keine RMON-spezifischen Daten erforderlich.

Syslog-Datenerkennung

Im Allgemeinen generiert Syslog dienstspezifische Meldungen für verschiedene Technologien. Die Syslog-Informationen eignen sich zwar besser für das Fehler- und Leistungsverwaltungsmanagement, die hier bereitgestellten Informationen dienen jedoch als Referenz. Ein Beispiel für OSPF-Syslog-Informationen, die von Cisco Geräten generiert wurden, finden Sie unter OSPF-Fehlermeldungen.

Eine vollständige Liste der Systemmeldungen nach Einrichtung finden Sie unter Nachrichten und Wiederherstellungsverfahren.

Cisco IOS CLI-Datenidentifizierung

In dieser Version des OSPF-Konfigurationsmanagementverfahrens sind keine CLI-Daten erforderlich.

Datensammlung

SNMP-Datenerfassung

In der Tabelle unten werden die verschiedenen Komponenten der SNMP-Datenerfassung definiert.

SNMP-Datenkomponente Definition
Allgemeine SNMP-Konfiguration Unter SNMP konfigurieren finden Sie allgemeine Informationen zu Best Practices für die SNMP-Konfiguration.
Servicespezifische SNMP-Konfiguration Für dieses Verfahren sind keine servicespezifischen SNMP-Konfigurationen erforderlich.
SNMP MIB-Anforderungen Weitere Informationen finden Sie im Abschnitt zur Datenidentifizierung.
SNMP MIB Polling Collection SNMP-Polling-Daten werden von einem kommerziellen System wie HP OpenView leavingcisco.com oder benutzerdefinierten Skripts gesammelt. Weitere Informationen zu Auflistungsalgorithmen finden Sie im Abschnitt Beispieldatenerfassungsalgorithmen dieses Dokuments.
SNMP MIB Trap-Erfassung Die aktuelle Version von OSPF MIB, die von Cisco Geräten unterstützt wird, unterstützt keine SNMP-Traps. Für dieses Verfahren sind keine SNMP-Traps erforderlich.

RMON-Datensammlung

In dieser Version des Verfahrens sind keine RMON-Konfigurationen und -Daten erforderlich.

Syslog-Datenerfassung

Allgemeine Richtlinien für die Syslog-Konfiguration werden in diesem Dokument nicht behandelt. Weitere Informationen finden Sie unter Konfiguration und Fehlerbehebung für die Cisco Secure PIX Firewall mit einem zentralen internen Netzwerk.

OSPF-spezifische Anforderungen werden erfüllt, indem der OSPF-Router so konfiguriert wird, dass Nachbar-Änderungen mithilfe einer Syslog-Meldung mit dem folgenden Befehl protokolliert werden:

OSPF_ROUTER(config)# ospf log-adj-changes

Cisco IOS CLI-Datenerfassung

Im Allgemeinen bietet die Cisco IOS CLI den direktesten Zugriff auf die Rohdaten des NE. Der CLI-Zugriff eignet sich jedoch besser für Fehlerbehebungsverfahren und Change-Management-Aktivitäten als für das globale Konfigurationsmanagement gemäß diesem Verfahren. Der Zugriff über die CLI kann nicht für die Verwaltung eines großen Netzwerks skaliert werden. In diesen Fällen ist ein automatisierter Zugriff auf Informationen erforderlich.

In dieser Version des OSPF-Konfigurationsmanagementverfahrens sind keine CLI-Konfigurationen und -Daten erforderlich.

Datenpräsentation

OSPF Area Report

Im Folgenden sehen Sie ein Beispielformat für den OSPF-Bereichsbericht. Das Format des Berichts wird durch die Funktionen eines kommerziellen NMS (falls verwendet) oder die entworfene Ausgabe der benutzerdefinierten Scripts bestimmt.

Bereich Datenfelder Letzte Ausführung Dieser Vorgang
Area-ID 1 Authentifizierung    
SPF-Ausführen    
ABR-Anzahl    
ASBR-Anzahl    
LSA-Anzahl    
LSA-Prüfsumme    
Adressfehler    
Routing-Rückwürfe    
Keine Route gefunden    
Area-ID Nr. Authentifizierung    
SPF-Ausführen    
ABR-Anzahl    
ASBR-Anzahl    
LSA-Anzahl    
LSA-Prüfsumme    
Adressfehler    
Routing-Rückwürfe    
Keine Route gefunden    

OSPF-Schnittstellenbericht

Im Folgenden sehen Sie ein Beispielformat für den OSPF-Schnittstellenbericht. In der Praxis wird das Format des Berichts durch die Funktionen eines kommerziellen NMS bestimmt, wenn eines verwendet wird, oder durch die entworfene Ausgabe der benutzerdefinierten Scripts.

Bereich Gerät Schnittstelle Datenfelder Letzte Ausführung Dieser Vorgang
Area-ID 1 Knoten-ID 1 Schnittstellennummer 1 IP-Adresse    
Area-ID    
Verwaltungsstatus    
OSPF-Status    
Metriken/Kosten/Timer    
Interface ID #n IP-Adresse    
Area-ID    
Verwaltungsstatus    
OSPF-Status    
Metriken/Kosten/Timer    
Knoten-ID #n Schnittstellennummer 1 IP-Adresse    
Area-ID    
Verwaltungsstatus    
OSPF-Status    
Metriken/Kosten/Timer    
Interface ID #n IP-Adresse    
Area-ID    
Verwaltungsstatus    
OSPF-Status    
Metriken/Kosten/Timer    
Area-ID Nr. Knoten-ID 1 Schnittstellennummer 1 IP-Adresse    
Area-ID    
Verwaltungsstatus    
OSPF-Status    
Metriken/Kosten/Timer    
Interface ID #n IP-Adresse    
Area-ID    
Verwaltungsstatus    
OSPF-Status    
Metriken/Kosten/Timer    
Knoten-ID #n Schnittstellennummer 1 IP-Adresse    
Area-ID    
Verwaltungsstatus    
OSPF-Status    
Metriken/Kosten/Timer    
Interface ID #n IP-Adresse    
Area-ID    
Verwaltungsstatus    
OSPF-Status    
Metriken/Kosten/Timer    

OSPF Neighbor Report

Im Folgenden finden Sie ein Beispielformat für den OSPF-Nachbarbericht. In der Praxis wird das Format des Berichts durch die Funktionen eines kommerziellen NMS bestimmt, wenn eines verwendet wird, oder durch die entworfene Ausgabe der benutzerdefinierten Scripts.

Bereich Gerät Nachbarn Datenfelder Letzte Ausführung Dieser Vorgang
Area-ID 1 Knoten-ID 1 Nachbarn-ID 1 Router-ID    
Router-IP-Adresse    
Staat    
Veranstaltungen    
Retrans-Menge    
Neighbor-ID Nr. Router-ID    
Router-IP-Adresse    
Staat    
Veranstaltungen    
Retrans-Menge    
Knoten-ID #n Nachbarn-ID 1 Router-ID    
Router-IP-Adresse    
Staat    
Veranstaltungen    
Retrans-Menge    
Neighbor-ID Nr. Router-ID    
Router-IP-Adresse    
Staat    
Veranstaltungen    
Retrans-Menge    
Area-ID Nr. Knoten-ID 1 Nachbarn-ID 1 Router-ID    
Router-IP-Adresse    
Staat    
Veranstaltungen    
Retrans-Menge    
Neighbor-ID Nr. Router-ID    
Router-IP-Adresse    
Staat    
Veranstaltungen    
Retrans-Menge    
Knoten-ID #n Nachbarn-ID 1 Router-ID    
Router-IP-Adresse    
Staat    
Veranstaltungen    
Retrans-Menge    
Neighbor-ID Nr. Router-ID    
Router-IP-Adresse    
Staat    
Veranstaltungen    
Retrans-Menge    

Überwachungstools für das Commercial- und Public-Internet

Kommerzielle Tools unterstützen die Erfassung und Verarbeitung von Syslog-Informationen und das Polling allgemeiner SNMP MIB-Variablen.

Es sind keine kommerziellen oder öffentlichen Internet-Überwachungstools bekannt, die das OSPF-Konfigurationsmanagement gemäß diesem Verfahren unterstützen. Daher sind lokale benutzerdefinierte Skripts und Prozeduren erforderlich.

SNMP Polling-Daten

Routentabelle RFC 1213 leavingcisco.com

Objektname Objektbeschreibung
ipRouteDest Die Ziel-IP-Adresse der Route. Ein Eintrag mit dem Wert 0.0.0.0 gilt als Standardroute. In der Tabelle können mehrere Routen zu einem einzelnen Ziel angezeigt werden. Der Zugriff auf diese mehreren Einträge hängt jedoch von den vom verwendeten Netzwerkverwaltungsprotokoll definierten Mechanismen für den Tabellenzugriff ab. ::= { ipRouteEntry 1 } object identifier = 1.3.6.1.2.1.4.21.1.1
ipRouteMask Gibt die Maske an, die mit der Zieladresse logisch sein muss, bevor sie mit dem Wert im Feld ipRouteDest verglichen wird. Bei Systemen, die keine beliebigen Subnetzmasken unterstützen, erstellt ein Agent den Wert der ipRouteMask, indem er mithilfe eines der folgenden Maskennetzwerke feststellt, ob der Wert des entsprechenden ipRouteDest-Felds zu einem Netzwerk der Klasse A, B oder C gehört:
  • Klasse A = 255.0.0.0
  • Klasse B = 255.255.0.0
  • Klasse C = 255.255.255.0
Wenn der Wert von ipRouteDest 0.0.0.0 ist, die Standardroute, ist der Maskenwert auch 0.0.0.0.

Hinweis: Dieser Mechanismus wird implizit von allen IP-Routing-Subsystemen verwendet.

::= { ipRouteEntry 11 } object identifier = 1.3.6.1.2.1.4.21.1.11
ipRouteNextHop Die IP-Adresse des nächsten Hop dieser Route. Bei einer Route, die an eine Schnittstelle gebunden ist, die mit einem Broadcast-Medium realisiert wird, ist der Wert in diesem Feld die IP-Adresse des Agenten auf der Schnittstelle. ::= { ipRouteEntry 7 } object identifier = 1.3.6.1.2.1.4.21.1.7
ipRouteIfIndex Der Indexwert, der eindeutig die lokale Schnittstelle identifiziert, über die der nächste Hop der Route erreicht wird. Diese Schnittstelle ist die gleiche Schnittstelle, die durch den IfIndex-Wert identifiziert wird. ::= { ipRouteEntry 2 } object identifier = 1.3.6.1.2.1.4.21.1.2

RFC 1213 Verschiedene Objekte

Objektname Objektbeschreibung
ipAdEntIfIndex Der Indexwert, der die für den Eintrag zutreffende Schnittstelle eindeutig identifiziert. Diese Schnittstelle ist die gleiche Schnittstelle, die durch den IfIndex-Wert identifiziert wird. ::= { ipAddrEntry 2 } object identifier = 1.3.6.1.2.1.4.20.1.2
ipInAddrErrors Die Anzahl der verworfenen Eingabedatagramme, da die IP-Adresse in ihrem IP-Header ein ungültiges Zielfeld für die Entität war. Diese Zahl enthält ungültige Adressen (0.0.0.0) und nicht unterstützte Klassenadressen (Klasse E). Bei Entitäten, die keine IP-Gateways sind und keine Datagramme weiterleiten, enthält der Zähler verworfene Datagramme, da die Zieladresse keine lokale Adresse war. { ip 5 } object identifier = 1.3.6.1.2.1.4.5
ipRoutingDiscards Die Anzahl der verworfenen gültigen Routingeinträge. Ein möglicher Grund dafür, einen solchen Eintrag zu verwerfen, besteht darin, Speicherplatz für andere Routingeinträge freizugeben. { ip 23 } object identifier = 1.3.6.1.2.1.4.23
ipOutNoRoutes Die Anzahl der IP-Datagramme, die verworfen wurden, da keine Route gefunden wurde, um sie an ihr Ziel zu übertragen. { ip 12 } object identifier = 1.3.6.1.2.1.4.12

RFC 1253 leavingcisco.com - OSPF-Bereichstabelle

Objektname Objektbeschreibung
ospfAreaID Eine 32-Bit-Ganzzahl, die einen Bereich eindeutig identifiziert. Für den OSPF-Backbone wird die Area-ID 0.0.0.0 verwendet. ::= { ospfAreaEntry 1 } object identifier = 1.3.6.1.2.1.14.2.1.1
ospfAuthType Der für diesen Bereich angegebene Authentifizierungstyp. Zusätzliche Authentifizierungstypen können lokal pro Bereich zugewiesen werden. Der Standardwert ist 0. ::= { ospfAreaEntry 2 } object identifier = 1.3.6.1.2.1.14.2.1.2
OSPFspfAusführen Die Anzahl der Berechnungen der Intra-Area-Routing-Tabelle wurde mithilfe der Link-State-Datenbank dieses Bereichs vorgenommen. object identifier = 1.3.6.1.2.1.14.2.1.4
ospfAreaBdrRtrCount Die Gesamtzahl der ABRs, die in diesem Bereich erreichbar sind. Dies ist zunächst 0, der Standardwert, und wird bei jedem SPF-Durchlauf berechnet. ::= { ospfAreaEntry 5 } object identifier = 1.3.6.1.2.1.14.2.1.5
ospfASBdrRtrCount Die Gesamtzahl der ABSRs, die in diesem Bereich erreichbar sind. Dies ist zunächst 0 (der Standardwert) und wird bei jedem SPF-Durchlauf berechnet. ::= { ospfAreaEntry 6 } object identifier = 1.3.6.1.2.1.14.2.1.6
ospfAreaLSACount Die Gesamtzahl der LSAs in der Link-State-Datenbank einer Area, ausgenommen externe LSAs. Der Standardwert ist 0. ::= { ospfAreaEntry 7 } object identifier = 1.3.6.1.2.1.14.2.1.7
ospfAreaLSACksumSum Die unsignierte 32-Bit-Summe der LS-Prüfsummen des LSA in der Link-State-Datenbank des Bereichs. Diese Summe beinhaltet keine externen LSAs (LS-Typ 5). Die Summe kann verwendet werden, um festzustellen, ob sich die Link-State-Datenbank eines Routers geändert hat, und um die Link-State-Datenbank von zwei Routern zu vergleichen. Der Standardwert ist 0. ::= { ospfAreaEntry 8 } object identifier = 1.3.6.1.2.1.14.2.1.8

RFC 1253 OSPF-Schnittstellentabelle

Objektname Objektbeschreibung
OSPFIfIPAddress Die IP-Adresse der OSPF-Schnittstelle. object identifier = 1.3.6.1.2.1.14.7.1.1
OspfIfEvents Die Anzahl der Änderungen, die die OSPF-Schnittstelle an ihrem Status vorgenommen hat, oder es ist ein Fehler aufgetreten. object identifier = 1.3.6.1.2.1.14.7.1.15
OspfIfState Der OSPF-Schnittstellenstatus. object identifier = 1.3.6.1.2.1.14.7.1.12

RFC 1253 - OSPF-Nachbartabelle

Objektname Objektbeschreibung
OSPFnbrIPadr Die IP-Adresse dieses Nachbarn. ::= { ospfNbrEntry 1 } object identifier = 1.3.6.1.2.1.14.10.1.1
ospfNbrAddressLessIndex Der entsprechende Wert von IfIndex in der Internet-Standard-MIB auf einem Index, der über keine IP-Adresse verfügt. Bei der Zeilenerstellung kann dies von der Instanz abgeleitet werden. ::= { ospfNbrEntry 2 } object identifier = 1.3.6.1.2.1.14.10.1.2
OSPFnbrRtrID Eine 32-Bit-Ganzzahl, dargestellt als IPAddress, die den benachbarten Router im autonomen System eindeutig identifiziert. Der Standardwert ist 0.0.0.0. ::= { ospfNbrEntry 3 } object identifier = 1.3.6.1.2.1.14.10.1.3
ospfNbrState Der Zustand der Beziehung zum Nachbarn. Die Staaten sind:
  • nach unten (1)
  • Versuch (2)
  • Init (3)
  • TwoWay (4)
  • exchangeStart (5)
  • Austausch (6)
  • Laden (7)
  • voll (8)
::= { ospfNbrEntry 6 } object identifier = 1.3.6.1.2.1.14.10.1.6
ospfNbrEvents Die Anzahl der Statusänderungen der Nachbarbeziehung oder eines Fehlers. Der Standardwert ist 0. ::= { ospfNbrEntry 7 } object identifier = 1.3.6.1.2.1.14.10.1.7
OspfNbrLSRetransQLen Die aktuelle Länge der Warteschlange für die erneute Übertragung. Der Standardwert ist 0. ::= { ospfNbrEntry 8 } object identifier = 1.3.6.1.2.1.14.10.1.8

Beispielalgorithmen für die Datenerfassung

Während der Untersuchung dieses Papiers wurde ein Prototyp "C"-Programm entwickelt. Das Programm mit dem Namen oscan wurde mit Microsoft Developer Studio 97 mit Visual C++ Version 5.0 geschrieben. Es gibt zwei spezifische Bibliotheken, die die API für die SNMP-Funktion bereitstellen. Diese Bibliotheken sind snmpapi.lib und mgmtapi.lib

Die Funktionen der Microsoft API sind in drei Hauptkategorien eingeteilt und in der nachfolgenden Tabelle aufgeführt.

Agentenfunktionen Manager-Funktionen Dienstprogrammfunktionen
SNMPExtensionInit SNMPExtensionInitEx SNMPExtensionQuery snmpExtensionTrap SNMPmgrClose SNMPMgrGetTrap SNMPmgrOidToStr SNMPMgrOpen SNMPMgrMgrRequest SNMPMgrStrToOid SNMPMgrTrapListen SnmpUtilMemAlloc SnmpUtilMemFree SNMPUtilMemReAlloc SnmpUtilOidAppend SnmpUtilOidCmp SnmpUtilOidCpy SnmpUtilOidFree SnmpUtilOidNCSNMPSNMPUtilPrint AsnAny snmpUtilVarBindCpy snmpUtilVarBindListCpy snmpUtilVarBindFree snmpUtilVarBindListFree

Der oscan-Prototyp-Code kapselte die Microsoft API mit einer Reihe zusätzlicher Funktionen, die unten aufgeführt sind.

  • snmpWalkStrOid

  • snmpWalkAsnOid

  • snmpWalkVarBind

  • snmpWalkVarBindList

Diese Funktionen stellen eine generische API bereit, die den Zugriff auf die verschiedenen SNMP MIB-Tabellen ermöglicht, die zum Verwalten der OSPF-Konfigurationsdaten verwendet werden. Die Objekt-ID (OID) für die Tabelle, auf die zugegriffen werden soll, wird zusammen mit einer tabellenspezifischen Rückruffunktion an die oscan-API übergeben. Die Rückruffunktion verfügt über die Intelligenz, um auf die Daten zu reagieren, die aus den Tabellen zurückgegeben werden.

Haupt-Routine

Die erste Aufgabe besteht darin, eine Liste von Knoten zu erstellen, die das Ziel des oscan-Programms sind. Um das "Geräteerkennungsproblem" zu vermeiden, ist eine Seed-Datei erforderlich, um die zu scannenden Knoten zu identifizieren. Die Seed-Datei stellt Informationen wie die IP-Adresse und die schreibgeschützten SNMP-Community-Strings bereit.

Das oscan-Programm muss mehrere interne Datenstrukturen unterhalten, um die SNMP-Informationen zu speichern, die von den Routern gesammelt werden. Im Allgemeinen gibt es eine interne Datenstruktur für jede SNMP-MIB-Tabelle, die erfasst wird.

Main
	load node array based on information in the seed file.
	while more entries in the node array
		start SNMP session for this node
		collect IP route table for this node
		collect OSPF area table for this node
		collect OSPF Neighbor table for this node
		collect  sysName for this node
		collect OSPF Interface table for this node
		end SNMP session for this node
	end while

IP-Routentabelle

Beim Zugriff auf die IP-Routing-Tabelle mit SNMP ist Vorsicht geboten, da bei diesem Vorgang die CPU eines Routers einfach überlastet werden kann. Daher verwendet das oscan-Programm einen vom Benutzer konfigurierbaren Verzögerungsparameter. Der Parameter stellt eine Verzögerung zwischen jeder SNMP-Anforderung bereit. Für große Umgebungen bedeutet dies, dass die Gesamtzeit für die Erfassung der Informationen sehr erheblich sein kann.

Die Routing-Tabelle enthält vier Informationen, die für Sie interessant sind:

  • ipRouteDest

  • ipRouteMask

  • ipRouteNextHop

  • ipRouteIfIndex

Die Routing-Tabelle wird durch ipRouteDest indiziert. Daher ist für jedes von der SNMP-Get-Anfrage zurückgegebene Objekt das an die OID angehängte ipRouteDest angefügt.

Das Objekt ipRouteIfIndex ist eine ganze Zahl, die in die IP-Adresstabelle (ipAddrTable) indiziert wird. Die ipAddrTable wird mithilfe des ipAdEntAddr-Objekts (der IP-Adresse der Schnittstelle) indiziert. Um die IP-Adresse der Schnittstelle abzurufen, ist ein vierstufiger Prozess erforderlich:

  1. Erfassen Sie den ipRouteIfIndex aus der Routing-Tabelle.

  2. Greifen Sie mithilfe des ipRouteIfIndex für die Musterzuordnung auf die ipAddrTable zu.

  3. Wenn ein Muster gefunden wird, konvertieren Sie die OID in eine Zeichenfolge und sammeln Sie die letzten vier Dezimalfelder mit einem Punkt, die die IP-Adresse der Schnittstelle darstellen.

  4. Speichern Sie die IP-Adresse der Schnittstelle wieder in der IP-Routing-Tabelle.

Der allgemeine Algorithmus für den Zugriff auf die IP-Routing-Tabelle ist unten dargestellt. An diesem Punkt wird nur der ganzzahlige Wert des ipRouteIfIndex gespeichert. Später wird beim Erfassen der Schnittstelleninformationen auf die ipAddrTable zugegriffen, und die übrigen Informationen werden erfasst und in die interne IP-Routing-Tabelle eingefügt.

OID List =
	ipRouteDestOID,
	ipRouteMaskOID,
	ipRouteNextHopOID,
	ipRouteIfIndexOID;

For each object returned by  SNMP route table walk
	Sleep // user configurable polling delay.
	check varbind oid against OID list
	if OID is ipRouteDestOID
		add new entry in the internal route table array
	if OID is one of the others
		search internal route array for matching index value
		store information in array

Die gesammelten Informationen werden in einer Tabelle dargestellt, die der vertrauten Ausgabe aus der Router-CLI unten ähnelt.

ROUTE TABLE
**********************************************************
Destination     Mask                GW              Interface       
10.10.10.4      255.255.255.252     10.10.10.5      10.10.10.5      
10.10.10.16     255.255.255.252     10.10.10.6      10.10.10.5      
10.10.10.24     255.255.255.252     10.10.10.25     10.10.10.25     
10.10.10.28     255.255.255.252     10.10.11.2      10.10.11.1      
10.10.10.36     255.255.255.252     10.10.10.6      10.10.10.5      
10.10.11.0      255.255.255.0       10.10.11.1      10.10.11.1      
10.10.13.0      255.255.255.0       10.10.11.2      10.10.11.1

OSPF-Area-Tabelle

Die Sammlung von Informationen aus der OSPF-Bereichstabelle wird durch Scannen der OSPF-Bereichstabelle (ospfAreaTable) und Verarbeiten der Daten während der Rückgabe durchgeführt. Der Index der ospfAreaTable ist die osfpAreaId. Die OspfAreaId wird im Dezimalpunktformat gespeichert, das mit einer IP-Adresse identisch ist. Daher können hier dieselben Unterroutinen, die für die Verarbeitung und Suche nach der IProuteTable und dem ipRouteIfIndex verwendet wurden, wiederverwendet werden.

In diesem Abschnitt sind mehrere Datenelemente enthalten, die sich nicht in der OSPF-Bereichstabelle befinden. Die Objekte ipInAddrErrors, IPRoutingDiscards und ipOutNoRoute befinden sich beispielsweise in der MIB-2-Definition, sind jedoch keinem OSPF-Bereich zugeordnet. Diese Objekte sind einem Router zugeordnet. Daher werden diese Zähler als Bereichsmetrik verwendet, indem die Werte für jeden Knoten in einem Bereich einem Bereichszähler hinzugefügt werden. Im OSPF-Area-Report ist beispielsweise die Anzahl der Pakete, die verworfen wurden, weil keine Route gefunden wurde, die Summe der Pakete, die von allen Routern in diesem Bereich verworfen wurden. Dies ist eine High-Level-Metrik, die einen allgemeinen Überblick über den Routing-Status des Bereichs bietet.

OID List =
	ipInAddrErrorsOID,
	ipRoutingDiscardsOID,
	ipOutNoRouteOID,
	areaIdOID,
	authTypeOID,
	spfRunsOID,
	abrCountOID,
	asbrCountOID,
	lsaCountOID,
	lsaCksumSumOID;

	For object returned from the SNMP walk of  the Area Table
		Sleep // user configurable polling delay.
		check varbind oid against OID list.
		if OID is ospfAreaId
			add new entry in the internal route table array
		if OID one of the others
			search internal array for matching index value
			store information in array
	end of for loop
	get ipInAddrErrors, ipRoutingDiscards, ipOutNoRoute
	add values to overall Area counters

Die gesammelten Informationen sind in der unten stehenden ASCII-Tabelle dargestellt.

AREAS
**********************************************************
AREA = 0.0.0.0			AREA = 0.0.0.2
authType = 0			authType = 0
spfRuns = 38			spfRuns = 18
abrCount = 2			abrCount = 1
asbrCount = 0			asbrCount = 0
lsaCount = 11			lsaCount = 7
lsaCksumSum = 340985		lsaCksumSum = 319204
ipInAddrErrors = 0		   ipInAddrErrors = 0
ipRoutingDiscards = 0		ipRoutingDiscards = 0
ipOutNoRoutes = 0		ipOutNoRoutes = 0

OSPF Neighbor-Tabelle

Der Index für die Nachbartabelle ist zwei Werte:

  • ospfNbrIpAddr: Der ospfNbrIpAddr ist die IP-Adresse des Nachbarn.

  • ospfNbrAddressLessIndex: Der ospfNbrAddressLessIndex kann einer von zwei Werten sein:

    • Bei einer Schnittstelle, der eine IP-Adresse zugewiesen ist, ist sie Null.

    • Für eine Schnittstelle, der keine IP-Adresse zugewiesen ist, wird sie als IfIndex aus der Internet-Standard-MIB interpretiert.

Da es zwei Werte für den Index gibt, müssen Sie die zuvor verwendeten Algorithmen für die zusätzlichen Informationen anpassen, die an die zurückgegebenen OIDs angefügt werden. Nach dieser Anpassung können hier die gleichen Subroutinen, die zum Verarbeiten und Suchen der ipRouteTable und des ipRouteIfIndex verwendet wurden, wiederverwendet werden.

OID List =
	ospfNbrIpAddrOID,
	ospfNbrAddressLessIndexOID,
	ospfNbrRtrIdOID,
	ospfNbrStateOID,
	ospfNbrEventsOID,
	ospfNbrLSRetransQLenOID,

	For object returned from the SNMP walk of the Neighbor Table
		Sleep // user configurable polling delay.
		check varbind OID against OID list.
		if OID matches ospfNbrIpAddr
			add new entry in the internal neighbor table array
		if OID matches one of the others
			search array for matching index value
			store information in array

Die gesammelten Informationen sind in der unten stehenden ASCII-Tabelle dargestellt.

NEIGHBORS
************************************************************
NEIGHBOR #0				NEIGHBOR #1
Nbr Ip Addr = 10.10.10.6		Nbr Ip Addr = 10.10.11.2
Nbr Rtr Id = 10.10.10.17		Nbr Rtr Id = 10.10.10.29
Nbr State = 8				Nbr State = 8
Nbr Events = 6				Nbr Events = 30
Nbr Retrans = 0				Nbr Retrans = 0

Zugehörige Informationen

War dieses Dokument hilfreich?

FeedbackFeedback

Cisco kontaktieren

Dieses Dokument gilt für folgende Produkte.