Das OSPF-Routing-Protokoll (Open Shortest Path First) ist in RFC 2328 OSPF Version 2 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 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. |
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.
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.
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.
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.
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.
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
Die Prozessausgaben werden wie folgt definiert:
OSPF-Konfigurationsberichte, die im Abschnitt Datenpräsentation definiert sind
OSPF-Konfigurationsempfehlungen für durchzuführende Korrekturmaßnahmen
In den folgenden Abschnitten werden die Initialisierungs- und iterativen Aufgaben im Zusammenhang mit dem OSPF-Konfigurationsmanagement definiert.
Initialisierungsaufgaben werden einmal während der Implementierung des Prozesses ausgeführt und sollten nicht bei jeder Iteration des Prozesses ausgeführt werden.
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 |
|
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 |
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 |
|
Task-Ausgaben | Eine Seed-Datei für den OSPF-Konfigurationsmanagementprozess. |
Task-Ressourcen |
|
Aufgabenrolle |
|
Iterative Aufgaben werden mit jeder Iteration des Prozesses ausgeführt, und ihre Häufigkeit wird bestimmt und geändert, um die Leistungsindikatoren zu verbessern.
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 |
|
Task-Eingaben |
|
Task-Ausgaben |
|
Task-Ressourcen |
|
Aufgabenrolle |
|
Die beiden Schritte zum Ausführen der OSPF-Prüfung sind:
Erfassen der Daten.
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.
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 |
|
Aufgabenrolle |
|
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:
|
OSPF-Schnittstellen | Beschreibt eine Schnittstelle aus Sicht von OSPF, z. B.:
|
OSPF-Nachbarstatus | Beschreibt einen OSPF-Nachbarn.
|
Cisco unterstützt derzeit die RFC 1253 OSPF Version 2 MIB . RFC 1253 enthält keine SNMP-Trap-Definitionen für OSPF. Die neueste Version der OSPF MIB ist RFC 1850 OSPF Version 2 . 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.
Für dieses Verfahren sind keine RMON-spezifischen Daten erforderlich.
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.
In dieser Version des OSPF-Konfigurationsmanagementverfahrens sind keine CLI-Daten erforderlich.
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 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. |
In dieser Version des Verfahrens sind keine RMON-Konfigurationen und -Daten erforderlich.
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
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.
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 |
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 |
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 |
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.
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:
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 |
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 |
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 |
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 |
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:
|
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 |
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.
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
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:
Erfassen Sie den ipRouteIfIndex aus der Routing-Tabelle.
Greifen Sie mithilfe des ipRouteIfIndex für die Musterzuordnung auf die ipAddrTable zu.
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.
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
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
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