DE60318651T2

DE60318651T2 - Verfahren und Vorrichtung zur dynamischen Konfigurationsverwaltung

Info

Publication number: DE60318651T2
Application number: DE60318651T
Authority: DE
Inventors: Michael Sunnyvale Yip; Yeeping Chen Milpitas Zhong; Qi Diamond Bar Cao; Anna Los Altos Berenberg
Original assignee: Extreme Networks Inc
Current assignee: Extreme Networks Inc
Priority date: 2002-04-26
Filing date: 2003-04-25
Publication date: 2008-12-24
Anticipated expiration: 2023-04-26
Also published as: DE60318651D1; EP1376932B1; JP2004005610A; EP1376932A3; JP4350410B2; EP1376932A2; US7783733B1

Description

TECHNISCHES GEBIET
Die vorliegende Erfindung bezieht sich auf das Gebiet des Netzwerkmanagements. Speziell bezieht sich die vorliegende Erfindung auf dynamische Konfiguration eines Netzwerkgeräts.
URHEBERRECHTSHINWEIS/GENEHMIGUNG
Ein Teil der Offenbarung dieses Patentdokuments enthält Material, welches dem Urheberrechtsschutz unterliegt. Der Urheberrechtsinhaber hat keinen Einwand gegen originalgetreue Vervielfältigung des Patentdokuments oder der Patentoffenbarung, wie sie in der Akte oder den Unterlagen des Patent- und Markenamts erscheinen, durch Jedermann, behält sich jedoch ansonsten sämtliche Urheberrechte vor. Der folgende Hinweis gilt für die Software und Daten, wie unten beschrieben und in den zugehörigen Figuren: Copyright @ 2002, Extreme Networks, Inc., Alle Rechte Vorbehalten.
HINTERGRUND UND ZUGEHÖRIGER STAND DER TECHNIK
Die Architektur hochperformanter Internetrouter ist in den letzten Jahren vorangeschritten, um erhöhte Leistung für das Routen ständig größerer Mengen von Netzwerkverkehr bereitzustellen. Es ist für einen Router nicht ungewöhnlich, zahlreiche Protokolle und mehrere Steueranwendungen für Konfiguration und Wartung von Routingtabellen, Protokollen und Netzwerkrichtlinien zu unterstützen. Diese Fortschritte haben die Komplexität der Router erhöht, so dass das effiziente Management der Routerkonfigurationen entscheidend für zuverlässige Netzwerkperformanz ist.
Die Konfiguration eines Routers wird typischerweise durch eine zentralisierte Systemkonfigurationsdatenbank gemanagt, welche sich auf dem Router befindet. Die Inhalte der Konfigurationsdatenbank steuern den Betrieb des Routers, und Manipulation der Inhalte der Konfigurationsdatenbank wird durch die Nutzung einer Managementschnittstelle wie einer Befehlszeilenschnittstelle (CLI) erreicht. In einer traditionellen Routerarchitektur hat die CLI vollen Zugriff auf die Systemkonfigurationsdatenbank durch einen Konfigurationsmanagerprozess und soll das primäre Zugriffsverfahren für Systemexperten sein. Die CLI kann nicht nur für Konfigurationsbefehle genutzt werden, sondern auch für andere interaktive Befehle, die den Betrieb des Routers steuern, z. B. Befehle zum Hochfahren oder Herunterfahren bestimmter Anwendungen oder Prozesse.
Eine andere häufig gebrauchte Managementschnittstelle für die Konfiguration des Routers ist das Simple Network Management Protocol (SNMP). SNMP ist ein Protokoll, das Netzwerkmanagement und Monitoring von Netzwerkgeräten und deren Funktionen regelt und ist dokumentiert im Request For Comment (RFC) 2570, Introduction to Version 3 of the Internet-Standard Network Management Framework, verfasst von der Network Working Group der Internet Engineering Task Force (IETF), und veröffentlicht von der Internet Society im April 1999. Dokument WO-A1-0175634 offenbart ein System und ein Verfahren für Zugriff auf ein Netzwerkgerät mittels SNMP. Noch eine andere, erst kürzlich entwickelte Managementschnittstelle zur Konfigurationsdatenbank des Routers basiert auf der Extensible Markup Language, oder XML. Eine XML-basierte Netzwerkmanagementschnittstelle nutzt typischerweise XML zur Codierung von Kommunikationsdaten, welche von einem Netzwerkadministrator über eine grafische Benutzeroberfläche (GUI) eingegeben wurden, und stellt einen Mechanismus zum Übertragen der komplexen Daten, die zum Managen von Netzwerkgeräten genutzt werden, an die Konfigurationsdatenbank bereit.
Es ist nicht ungewöhnlich für bestimmte Anwendungen und Protokolle auf einem Router, Zugriff auf ihre zugehörigen Konfigurationsdaten von allen drei der oben beschriebenen Netzwerkmanagementschnittstellen – CLI, SNMP und XML – zu erlauben. Tatsächlich könnte ein Netzwerkadministrator verschiedene CLI- oder SNMP-Befehle eingeben, welche die identische Konfigurationsänderung eines bestimmten Routers erreichen. Den Router dazu bringen, alle der verschiedenen Managementschnittstellenbefehle für alle unterschiedlichen Anwendungen und Protokolle, welcher der Router unterstützt, zu erkennen, kann schwierig sein und viele Aktualisierungen von Daten wie SNMP Management Information Database (MIB)-Definitionen, CLI-Befehlsbäume oder XML-Tags erfordern. Dokument XP-002158233 lehrt, einen durch das Netzwerk reisenden Agenten zu nutzen, wodurch dem Agent erlaubt wird, eine Lösungsstrategie für eine gegebene Umgebung zu definieren, um seine Aufgabe effizient zu erfüllen.
In der bestehenden Routermanagementtechnologie wird die Logik zur Unterstützung von Anwendungen, Protokollen und zusammengehörigen Managementschnittstellen zentral in einem einzigen Masterprogramm gemanagt. Dies kann zu einem einzigen Ausfallpunkt führen, was bedeutet, dass sogar wenn es ein Problem mit nur einem Protokoll oder Anwendung oder Schnittstelle gibt, das gesamte Programm abstürzen und den Router mit hinunter ziehen könnte. Des Weiteren, wenn das Masterprogramm aktualisiert werden muss, angenommen um ein neues Protokoll zu unterstützen, z. B. das Multi-Protocol Label Switching (MPLS)-Protokoll, oder eine neue, schnellere Blade zu unterstützen, welche jeweils einen neuen Satz CLI-Befehle, SNMP-Anfragen oder XML-Zugriffe einführen können, die unterstützt werden müssen, dann muss das Masterprogramm heruntergefahren werden um die Aktualisierungen vorzunehmen, was den Router vorübergehend außer Betrieb setzt.
In einem Versuch, einige der Beschränkungen der bestehenden Routermanagementtechnologie zu überwinden, wurden im Rahmen der SNMP-Managementsysteme separate Bearbeitungsinstanzen, bekannt als Masteragenten und -subagenten, entwickelt. Ein Masteragent sendet und empfangt die SNMP-Anfragen, aber hat wenig oder keinen Zugriff auf die Managementinformationen, z. B. die MIB-Daten in der Konfigurationsdatenbank. Der Subagent hat Zugriff auf die Managementinformationen und -prozesse der SNMP-Anfragen, ist aber abgeschirmt von den SNMP-Anfragen selbst. RFC 2741, Agent Extensibility (AgentX) Protocol, verfasst von der Network Working Group der IETF, und veröffentlicht von der Internet Society im Januar 2000, dokumentiert das Konzept erweiterbarer SNMP-Agenten und ein Protokoll für Kommunikation zwischen dem Masteragent und dem Subagent.
Die SNMP Masteragent/Subagent-Technologie hat neue Möglichkeiten zur Verbesserung des Konfigurationsmanagements gebracht. Jedoch wurde wenig getan, um die Beschränkungen in der bestehenden Routermanagementtechnologie im Rahmen anderer Managementschnittstellen zu überwinden oder eine umfassende Lösung für Konfigurationsmanagement ungeachtet der Managementschnittstelle zu ermöglichen.
ZUSAMMENFASSUNG
Gemäß der Erfindung werden ein Verfahren gemäß Anspruch 1, ein Konfigurationsmanagementsystem gemäß Anspruch 12 und ein Netzwerkgerät gemäß Anspruch 22 bereitgestellt. Eine Anwendung zur Unterstützung eines Protokolls, Netzwerkschnittstelle oder anderer Komponente der Konfiguration arbeitet in Verbindung mit einem Masteragent und Subagent zum Senden und Empfangen von Konfigurationsmanagementinformationen. Die Anwendung arbeitet weiterhin in Verbindung mit einer Konfigurationsmanagerschnittstelle und einem Konfigurationsmanager für das Zugreifen auf die und Aktualisieren der Konfiguration gemäß einer Priorität der Anwendung und ohne das Netzwerkgerät außer Betrieb zu nehmen.
Gemäß eines Aspekts der Erfindung aktiviert die Anwendung die Subagenten, welche sich bei dem entsprechenden Masteragenten wie erforderlich registrieren und abmelden. Der Masteragent und die registrierten Subagenten kommunizieren mittels einer gemeinsamen Nachrichtenschnittstelle zum Austauschen von an einen und von einem Netzwerkadministrator gesendeten Befehlen und Konfigurationsinformationen. Die Anwendung bildet die Befehle und Konfigurationsinformationen auf ein universales Managementobjektformat ab und aktiviert weiterhin eine Konfigurationsmanagerschnittstelle zum Austauschen der formatierten Befehle und Konfigurationsinformationen mit dem Konfigurationsmanager mittels der gemeinsamen Nachrichtenschnittstelle.
Der Masteragent und die Subagenten arbeiten unabhängig voneinander und von der Anwendung, und unabhängig von anderen Masteragenten und zu der Anwendung oder zu anderen Anwendungen gehörenden Subagenten. Der Konfigurationsmanager und die Konfigurationsmanagerschnittstelle arbeiten ebenfalls unabhängig voneinander und von der Anwendung. Unabhängige Aktivierung und Betrieb von Subagent, Masteragent, Anwendung, Konfigurationsmanager und Konfigurationsmanagerschnittstelle ermöglichen einem Netzwerkadministrator, ein Protokoll hinzuzufügen oder zu aktualisieren, eine Blade hinzuzufügen oder auszuwechseln oder andere Aktionen vorzunehmen, ohne das Netzwerkgerät selbst abschalten zu müssen. Zudem führt der Ausfall des Konfigurationsmanagers, einer Anwendung oder einem zugehörigen Subagent, Masteragent oder Konfigurationsmanagerschnittstelle nicht zum Ausfall des gesamten Netzwerkgeräts.
Gemäß dieser und anderer Aspekte der vorliegenden Erfindung werden Vorrichtungen zum Ausführen der oben genannten und anderen Verfahren bereitgestellt.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die vorliegende Erfindung wird ohne Beschränkungen durch beispielhafte Ausführungsformen beschrieben, welche in den beigefügten Zeichnungen dargestellt sind, wobei gleiche Bezugszeichen gleichartige Elemente kennzeichnen, und wobei:
1 ist ein Blockdiagramm, das eine verallgemeinerte Ausführungsform eines Konfigurationsmanagementsystem, welche die Erfindung enthält und die Betriebsumgebung, in welcher bestimmte Aspekte der dargestellten Erfindung genutzt werden können, darstellt;
2 ist ein Blockdiagramm, das ausgewählte Komponenten des Konfigurationsmanagementsystems der 1 entsprechend einer Ausführungsform der vorliegenden Erfindung detaillierter darstellt;
3 ist eine Darstellung eines Datenformats der gemeinsamen Nachrichtenschnittstelle der 1 entsprechend einer Ausführungsform der vorliegenden Erfindung;
4A ist eine Darstellung eines Beispiels der gemeinsamen Nachrichtenschnittstelle der 1 für eine CLI-basierte Managementschnittstelle, entsprechend einer Ausführungsform der vorliegenden Erfindung;
4B ist eine Darstellung eines Beispiels der gemeinsamen Nachrichtenschnittstelle der 1 für eine SNMP-basierte Managementschnittstelle, entsprechend einer Ausführungsform der vorliegenden Erfindung;
4C ist eine Darstellung eines Beispiels der gemeinsamen Nachrichtenschnittstelle der 1 für eine XML-basierte Managementschnittstelle, entsprechend einer Ausführungsform der vorliegenden Erfindung;
5 ist ein Blockdiagramm, das eine geeignete Rechenumgebung darstellt, in welcher bestimmte Aspekte der dargestellten und in 1–4C gezeigten Erfindung genutzt werden können;
6 ist ein Flussdiagramm, das bestimmte Aspekte eines Verfahrens zur Ausführung durch einen Computer darstellt, welches eine Ausführungsform der dargestellten und in 1–5 gezeigten Erfindung ausführt;
7 ist ein Flussdiagramm, das bestimmte andere Aspekte eines Verfahrens zur Ausführung durch einen Computer darstellt, welches eine Ausführungsform der dargestellten und in 1–5 gezeigten Erfindung ausführt;
8 ist ein Flussdiagramm, das bestimmte andere Aspekte eines Verfahrens zur Ausführung durch einen Computer darstellt, welches eine Ausführungsform der dargestellten und in 1–5 gezeigten Erfindung ausführt;
9 ist ein Flussdiagramm, das bestimmte andere Aspekte eines Verfahrens zur Ausführung durch einen Computer darstellt, welches eine Ausführungsform der dargestellten und in 1–5 gezeigten Erfindung ausführt.
DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
In der folgenden Beschreibung werden verschiedene Aspekte der vorliegenden Erfindung, ein Verfahren und eine Vorrichtung für dynamisches Konfigurationsmanagement beschrieben. Besondere Details werden dargelegt, um ein genaues Verständnis der vorliegenden Erfindung zu gewährleisten. Jedoch wird es für die Fachleute offenkundig sein, dass die vorliegende Erfindung mit nur einigen oder allen der beschriebenen Aspekte der vorliegenden Erfindung und mit oder ohne einige oder alle der besonderen Details ausgeführt werden kann. In einigen Instanzen wurden bekannte Architekturen, Schritte und Techniken nicht gezeigt, um die vorliegende Erfindung nicht unnötigerweise zu verdecken. Zum Beispiel wurden besondere Details, ob ein Verfahren oder eine Vorrichtung in einem Switch, Router, Bridge, Server oder Gateway, als eine Softwareroutine, Hardwareschaltkreis, Firmware oder eine Kombination davon implementiert ist, nicht angegeben.
Teile der Beschreibung werden unter Verwendung bekannter, von Fachleuten verwendeter Terminologie dargelegt, um das Wesentliche ihrer Arbeit anderen Fachleuten zu vermitteln, einschließlich Begriffe für von einem Netzwerkbetriebssystem ausgeführte Operationen, und ihre Operanden wie Übertragen, Empfangen, Routen, Pakete, Nachrichten, Tabellen, Befehle, Nachrichteninformationsbasis, Befehlsbäume, Tags und dergleichen. Wie von Fachleuten wohlverstanden wird, nehmen diese Operanden die Form elektrischer, magnetischer oder optischer Signals an, und die Operationen enthalten Speichern, Übertragen, Kombinieren und anderweitiges Manipulieren der Signale durch elektrische, magnetische oder optische Komponenten eines Systems. Der Begriff System beinhaltet Anordnungen dieser Komponenten, welche selbstständig, zusätzlich oder eingebettet sind, zu allgemeinem Zweck und speziellem Zweck.
Verschiedene Operationen werden als mehrfache, diskrete Schritte beschrieben, welche nacheinander so durchgeführt werden, dass es möglichst hilfreich für das Verständnis der Erfindung ist. Jedoch sollte die Reihenfolge der Beschreibung nicht so gedeutet werden, dass sie impliziert, dass diese Operationen notwendigerweise in der dargelegten Reihenfolge oder sogar reihenfolgenabhängig durchgeführt werden. Schließlich bedeutet in der ganzen Beschreibung die Bezugnahme auf "eine Ausführungsform" oder "einen Aspekt", dass das bestimmte beschriebene Merkmal, die Struktur oder Charakteristik in wenigstens einer Ausführungsform der Erfindung, aber nicht notwendigerweise in der gleichen Ausführungsform enthalten ist. Weiterhin können die bestimmten Merkmale, Strukturen oder Charakteristiken in jeder brauchbaren Art in einer oder mehreren Ausführungsformen kombiniert werden.
Es sollte angemerkt werden, dass obwohl die folgende Beschreibung auf das Verfahren und die Vorrichtung auf ein Netzwerkgerät wie einen Router oder einen Layer 3-Switch eingeht, die durchschnittlichen Fachleute verstehen, dass dieses Verfahren grundsätzlich auf jedes paketweiterleitende Gerät inklusive einer Bridge (Layer 2-Switch), Server oder Gateway angewendet werden kann. Es sollte ebenfalls angemerkt werden, dass, obwohl das Verfahren und die Vorrichtung im Rahmen eines Local Area Network (LAN) diskutiert werden, die vorliegende Erfindung ebenfalls im Rahmen anderer Transport Control Protocol/Internet Protocol (TCP/IP)-basierten Netzwerke einschließlich, aber nicht beschränkt auf Internetzwerke, Virtual Local Area Networks (VLANs), Metropolitan Area Networks (MANs) und Wide Area Networks (WANs) sowie in Subnetzen organisierte Netzwerke genutzt werden kann.
1 ist ein Blockdiagramm, das eine verallgemeinerte Ausführungsform eines Konfigurationsmanagementsystem, welche die Erfindung enthält und die Betriebsumgebung, in welcher bestimmte Aspekte der dargestellten Erfindung genutzt werden können, darstellt. Wie dargestellt, arbeitet das Konfigurationsmanagementsystem 100 auf einem Router, der einen Konfigurationsmanager 70 hat.
Der Konfigurationsmanager 70 arbeitet in Verbindung mit einem Transaktionsmonitor 75, einem Dateisystem 80, einem Concurrent Version Server (CVS)-Server 90, und einem oder mehreren entfernten CVS-Servern 85, um die Konfigurationsdaten des Routers zu führen. Die Konfigurationsdaten enthalten die aktuell laufende Konfiguration und die letzte gesicherte Konfiguration. Die aktuell laufende Konfiguration wird im flüchtigen Speicher auf dem Router gespeichert, während die gesicherte Konfiguration im nicht-flüchtigen Speicher oder anderen permanenten Speichermedium mittels des Dateisystems 80 gespeichert wird. Der Konfigurationsmanager 70 führt weiterhin eine bestimmte Version der Konfigurationsdaten im nicht-flüchtigen Speicher unter Verwendung des CVS-Servers 90 und der entfernten CVS-Server 85 zur Gewährleistung von Versionskontrolle. In einer Ausführungsform sichert der Konfigurationsmanager 70 die bestehenden Versionen der Konfigurationsdaten zur Laufzeit in einer ASCII-formatierten Textdatei unter Verwendung des Dateisystems 80. Es sollte angemerkt werden, dass der Konfigurationsmanager 70 die Konfigurationsdaten in anderen als ASCII-Dateiformaten sichern könnte, ohne den Bereich der Erfindung zu verlassen. Zum Beispiel könnten in einer Ausführungsform die Konfigurationsdaten in einer XML-formatierten Datei, wie in der gemeinsam zugewiesenen anhängigen Anmeldung EP-A1-02478 beschrieben, gesichert werden.
Während des Betriebs nutzt der Konfigurationsmanager 70 den Transaktionsmonitor 75 zum Puffer und Steuern mehrerer Aktualisierungen der Konfigurationsdaten, um ihre Integrität zu bewahren. Die letzte gesicherte Version der Konfigurationsdaten (oder andere Backup-Version der Konfigurationsdaten) wird auf einer Standby-Blade repliziert, welche einen Standby-Konfigurationsmanager 79 und ein Standby-Dateisystem 89 sowie einen Standby-CVS-Server 99 hat.
Ein typischer Router unterstützt eine Anzahl von Anwendungen, welche Protokolle, Netzwerkschnittstellen und andere Komponenten unterstützen und deren Operationen gemäß der aktuell laufenden Konfiguration, wie sie vom Konfigurationsmanager 70 geführt wird, gesteuert werden. Zum Beispiel enthält der Router in der dargestellten Ausführungsform Anwendungen, welche das Border Gateway Protocol (BGP) 40, das Open Shortest Path First-Protokoll (OSPF) 50 und eine Ethernet-Schnittstelle 60 unterstützen.
Jede Anwendung könnte auch eine oder mehrere Managementschnittstellen wie CLI, SNMP oder XML-basierte Managementschnittstellen unterstützen. Die Managementschnittstellen bieten Netzwerkadministratoren Zugriff auf die Funktionen des Routers und Routeranwendungen mittels CLI-Befehlen oder SNMP oder XML-Anfragen zum Aktualisieren oder Zugreifen auf die Konfiguration.
In einer Ausführungsform werden die Managementschnittstellen zu den Routerfunktionen, Anwendungen und der resultierenden Konfiguration statt in die Anwendung eingebunden zu sein mittels eines Masteragent/Subagent-Modells ausgeführt. Das Masteragent/Subagent-Modell ist eine Technik, die es einem Nutzer erlaubt, sehr variables Multiplexing in dynamischer Weise durchzuführen. Zum Beispiel erlaubt das Modell einer Anwendung, einen Subagent zum dynamischen Registrieren von Blättern in einem Befehlsbaum des Masteragenten oder zum Registrieren anderer Informationen, welche die Operationen des Masteragenten steuern, zu aktivieren. Der Masteragent ist ein unabhängiger Prozess wie z. B. ein Dämon, der empfangt, sendet und fähig ist, Eingangsdaten der Managementschnittstelle vor ihrer Weitergabe an den Subagenten über einen Kommunikationskanal 15/25/35 mittels einer gemeinsamen Nachrichtenschnittstelle zu validieren. Der Subagent ist ebenfalls ein unabhängiger Prozess wie z. B. ein Thread, der von der Anwendungsschicht 40/50/60 erzeugt wird und direkt an diese angekoppelt ist. Die Anwendungsschicht 40/50/60 hat viele Komponenten einschließlich der Anwendung 44/54/64 selbst, die in Verbindung mit einer universalen Managementobjektschicht (UMOL) 44/54/64 zum Abbilden der Befehle, Anfragen oder über das Masteragent/Subagent-Modell ausgetauschten Nachrichten auf eine gemeinsame interne Struktur arbeitet. In einer Ausführungsform ist die gemeinsame interne Struktur aus Aktionen und Parametern zusammengesetzt.
In einer Ausführungsform arbeitet die Anwendung in Verbindung mit einer Konfigurationsmanagementschnittstelle 47/57/67 zum Weitergeben der gemäß der gemeinsamen internen Struktur der UMOL erzeugen Aktionen und Parameter an den Konfigurationsmanager 70 über einen Kommunikationskanal 71/72/73 mittels der gemeinsamen Nachrichtenschnittstelle. Der Konfigurationsmanager 70 koordiniert das Verarbeiten der Aktualisierung der Konfiguration durch periodisches Anfragen der Konfigurationsdaten – der Aktionen und Parameter – auf die zugegriffen oder die aktualisiert werden müssen, von jeder registrierten Anwendung. Der Konfigurationsmanager 70 führt die Aktionen gemäß den Parametern und gemäß eines Anwendungsreihenfolgeschemas, das zur Registrierzeit erstellt wurde, aus. Der Konfigurationsmanager 70 gibt weiterhin etwaige Antworten auf die Aktionen und Parameter zurück an die Anwendung über die Konfigurationsmanagementschnittstelle 47/57/67 und über den Kommunikationskanal 71/27/73 mittels der gemeinsamen Nachrichtenschnittstelle.
Durch Nutzung des Masteragenten zum Trennen der Komponenten der Anwendungsschicht von der Managementschnittstelle und zum Trennen der Konfigurationsmanagementschnittstelle von den Anwendungsschichtkomponenten kann die Routerkonfiguration leichter gemanagt und dynamisch aktualisiert werden.
In der dargestellten Ausführungsform enthält das Konfigurationsmanagementsystem 100 drei Masteragenten, einen SNMP-Masteragent 10, einen CLI-Masteragent 20 und einen XML-Masteragent. Das Konfigurationsmanagementsystem 100 enthält weiterhin zugehörige SNMP-Subagenten für jede Anwendung: SNMP-Subagent 41 für die BGP-Anwendung 45, SNMP-Subagent 51 für OSPF-Anwendung 55 und SNMP-Subagent 61 für die Ethernetschnittstellenanwendung 65. Gleichermaßen enthält das Konfigurationsmanagementsystem 100 weiterhin zugehörige CLI-Subagenten für jede Anwendung: CLI-Subagent 42 für die BGP-Anwendung, CLI-Subagent 52 für OSPF-Anwendung 55 und CLI-Subagent 62 für die Ethernetschnittstellenanwendung 65, und enthält weiterhin zugehörige XML-Subagenten für jede Anwendung: XML-Subagent 43 für die BGP-Anwendung 45, XML-Subagent 53 für OSPF-Anwendung 55 und XML-Subagent 63 für die Ethernetschnittstellenanwendung 65. Jede Anwendung enthält weiterhin eine Konfigurationsmanagerschnittstelle: Konfigurationsmanagerschnittstelle 47 für die BGP-Anwendung 45, Konfigurationsmanagerschnittstelle 57 für die OSPF-Anwendung 55 und Konfigurationsmanagerschnittstelle 67 für die Ethernetschnittstellenanwendung 65. Es sollte angemerkt werden, dass andere Typen von Managementschnittstellen neben CLI, SNMP oder XML verwendet werden könnten, ohne den Bereich der Erfindung zu verlassen.
2 ist ein Blockdiagramm, welches das Konfigurationsmanagementsystems 100 der 1 detaillierter darstellt. In einer Ausführungsform tauschen die Masteragenten 10/20/30 und Subagenten 41/42/43/41/52/53/61/62/63 Konfigurationsmanagementinformationen mittels einer gemeinsamen Nachrichtenschnittstelle 110 und eines Kommunikationskanals 15/25/35 aus. Eine UMOL 44/54/64 koppelt an die Subagenten 41/42/43/41/52/53/61/62/63 und an die Anwendungen 45/55/65 zum Abbilden der Konfigurationsmanagementinformationen auf die interne Datenstruktur 74 an. Die Anwendungen 45/55/65 arbeiten in Verbindung mit den Konfigurationsmanagementschnittstellen 47/57/67 zum Ausgeben von gemäß der internen Datenstruktur 74 der UMOL erzeugten Aktionen und Parametern 110. Die Konfigurationsmanagementschnittstellen 47/57/67 senden die Aktionen und Parameter 110 an den Konfigurationsmanager 70 mittels der gemeinsamen Nachrichtenschnittstelle 110 und des Kommunikationskanals 71/72/73. In einer Ausführungsform können die Kommunikationskanäle 15/25/35 und 71/72/73 Inter-Prozess-Kommunikationskanäle (IPC) sein. Jedoch können andere Typen von Kommunikationskanälen genutzt werden, wie Transmission Control Protocol(TCP)-Kanäle oder Sockets, ohne den Bereich der Erfindung zu verlassen.

3 stellt ein Nachrichtenformat 130 für die gemeinsame Nachrichtenschnittstelle 110 dar, das zum Austauschen von Konfigurationsinformationen zwischen den Masteragenten und Subagenten und zwischen den Konfigurationsmanagementschnittstellen 47/57/67 und dem Konfigurationsmanager 70 genutzt wird. Wie dargestellt, enthält das Nachrichtenformat einen Nachrichten-TAG 132, eine Nachrichtenlänge 134 und einen Nachrichteninhalt 136. Das Format des Nachrichteninhalts 136 variiert abhängig davon, von welcher Anwendung die Nachricht gesendet oder für welche Anwendung sie bestimmt ist oder welche Managementschnittstelle den Inhalt weitergegeben hat, z. B. CLI, SNMP oder XML. In einer Ausführungsform enthält der Nachrichteninhalt 136 eine Reihe formatierter Befehle, wie sie vom Masteragent oder Subagent empfangen oder verarbeitet wurden. Das erwartete Format des Nachrichteninhalts 136 wird durch den Nachrichten-TAG identifiziert. Tabelle 1 fasst einige Beispiele verschiedener Nachrichten-Tags, welche gemäß einer Ausführungsform der Erfindung genutzt werden können, und eine Beschreibung ihrer Funktion zusammen. Tabelle 1

Nachrichten-TAG	Beschreibung
REGISTER_SNMP	Subagent-Anfrage zum Registrieren beim SNMP-Masteragent
REGISTER_CLI	Subagent-Anfrage zum Registrieren beim CLI-Masteragent
REGISTER_XML	Subagent-Anfrage zum Registrieren beim XML-Masteragent
CLI_CMD	Masteragent/Subagent – CLI-Befehl und Parameter
XML_ELEMENT	Masteragent/Subagent – XML-Element und Werte
SNMP_MIB_OID	Masteragent/Subagent SNMP MIB-OID-Tabellenelemente
REGISTER_CM_APP_NAME	Subagent-Anfrage, eine Anwendung beim Konfigurationsmanager zu registrieren
REGISTER_CM_APP_PRIORITY	Subagent-Anfrage, eine Priorität einer Anwendung beim Konfigurationsmanager zu registrieren
CFG_SAVE_REQUEST	Anfrage des Konfigurationsmanagers an eine Anwendung, Konfigurationsinhalt zum Sichern auf die laufende Konfiguration zu liefern
CFG_SAVE_CONTENT	Antwort einer Anwendung auf das CFG_ SAVE-REQUEST des Konfigurationsmanagers, Konfigurationsinhalt zum Sichern auf die laufenden Konfiguration zu liefern
CFG_REP_CONFIG	Anfrage einer Anwendung an den Konfigurationsmanager, die Konfiguration auf das Slave Backup zu replizieren
ROLLBACK	Anfrage einer Anwendung an den Konfigurationsmanager Rollback-Unterstützung zu gewähren
ROLLBACK_NOT-SUPPORTED	Anfrage einer Anwendung an den Konfigurationsmanager, Rollback-Unterstützung nicht zu gewähren

Wie in Tabelle 1 gesehen werden kann, bezeichnen einige Nachrichten-TAGS Nachrichten, die vom Subagent an den Masteragent erzeugt werden, während andere Nachrichten-TAGS Nachrichten bezeichnen, die von der Anwendung an den Konfigurationsmanager 70 erzeugt werden (oder umgekehrt). Zum Beispiel wird ein Nachrichten-TAG REGISTER_CLI vom Subagent erzeugt, um anzuzeigen, dass die Nachricht selbst eine Anfrage zum Registrieren beim Masteragent ist. Ein Nachrichten-TAG CLI_CMD wird vom Masteragent erzeugt, um dem Subagent anzuzeigen, dass der Nachrichteninhalt 136 der Nachricht ein validiertes CLI_CMD enthält. Andererseits wird ein Nachrichten-TAG CFG_SAVE_REQUEST vom Konfigurationsmanager erzeugt, um der Anwendung anzuzeigen, dass die Nachricht eine Anfrage an die Anwendung zum Senden gleich welcher Konfigurationsdaten, welche auf die letzte gesicherte Konfiguration im flüchtigen Speicher gesichert werden müssen, und der Nachrichten-TAG CFG_SAVE_CONTENT ist die von der Anwendung erzeugte Antwort an den Konfigurationsmanager, die anzeigt, dass der Nachrichteninhalt 136 die gewünschten Konfigurationsdaten, welche vom Konfigurationsmanager 70 gesichert werden müssen, enthält. Andere Nachrichten-TAGS können unter anderem eine Replizierungsanfrage oder eine Rollbackanfrage enthalten, die von der Anwendung an den Konfigurationsmanager 70 erzeugt werden.
4A stellt ein Beispiel einer gemeinsamen Nachrichtenschnittstelle 110 bei Nutzung für eine CLI-Nachricht dar, welche von einem Masteragent zu einem Subagent weitergegeben wird. Das CLI-Nachrichtenformat 140 enthält den Nachrichten-Tag 132 mit Wert "CLI_CMD", der anzeigt, dass die Nachricht ein CLI-Befehl ist. Der Nachrichteninhalt 136 umfasst eine Befehlskennung 142 und einen oder mehrere Parameter 144/146. 4B stellt die gemeinsame Nachrichtenschnittstelle 110 bei Nutzung für eine SNMP-Anfrage dar, welche von einem Masteragent an einen Subagent weitergegeben wird; gleichermaßen stellt 4C die gemeinsame Nachrichtenschnittstelle 110 bei Nutzung für eine XML-Anfrage dar, welche von einem Masteragent an einen Subagent weitergegeben wird. Zahlreiche andere Nachrichten-Tag-Werte 132, Nachrichtenlängen und Formate des Nachrichteninhalts 136 können verwendet werden, ohne den Bereich der Erfindung zu verlassen.
5 stellt eine Ausführungsform einer geeigneten Rechenumgebung dar, in welcher bestimmte Aspekte der dargestellten und in 1–4C gezeigten Erfindung genutzt werden können. In einer Ausführungsform kann ein Verfahren für ein Konfigurationsmanagementsystem 100 auf einem Computersystem 200 mit Komponenten 201–206, einschließlich eines Prozessors 2001, eines Speichers 202, eines Eingabe/Ausgabe-Geräts 203, einer Datenspeicherung 204, einer Netzwerkschnittstelle 205, miteinander verbunden durch einen Bus 208 implementiert werden. Die Komponenten führen ihre üblichen, aus dem Stand der Technik bekannten Funktionen aus und stellen die Mittel für das Implementieren des Konfigurationsmanagementsystems 200 bereit. Gemeinsam stellen diese Komponenten eine breite Kategorie von Hardwaresystemen dar, einschließlich, aber nicht beschränkt auf Mehrzweckcomputersysteme und spezielle Paketweiterleitungsgeräte.
In einer Ausführungsform kann die Speicherkomponente 202 einen oder mehrere Random Access Memory (RAM) und nicht-flüchtige Speichergeräte (z. B. magnetische oder optische Platten) enthalten, auf welchen Befehle und Daten zur Nutzung durch den Prozessor 201 gespeichert werden, einschließlich der Befehle und Daten, welche die Masteragenten 10/20/30, den Konfigurationsmanager 70 und die Konfigurationsmanagerschnittstellen 47/57/67, und Subagenten 41–43, 51–53 und 61–63, und andere Komponenten des Konfigurationsmanagementsystems 200 umfassen.
In einer Ausführungsform kann die Datenspeicherungskomponente 204 das Konfigurationsdateisystem 80, das von dem Konfigurationsmanagementsystem 100 gemanagt wird, und jeden anderen Speicherbereich wie Puffer, etc., der von den Protokollen 45, Anwendungen 55 oder anderen Schnittstellen 65 genutzt wird, darstellen.
Es ist auch einzusehen, dass verschiedene Komponenten des Computersystems 200 neu angeordnet werden können, und dass bestimmte Implementierungen der vorliegenden Erfindung nicht alle oben genannten Komponenten benötigen oder enthalten müssen. Weiterhin können zusätzliche Komponenten einbezogen werden, wie zusätzliche Prozessoren (z. B. ein digitaler Signalprozessor), Speicherungsgeräte, Speicher, Netzwerk/Kommunikationsschnittstellen, etc.
In der dargestellten Ausführungsform von 5 kann das Verfahren und die Vorrichtung für ein Konfigurationsmanagementsystem 100 gemäß einer Ausführungsform der Erfindung als eine Reihe von Softwareroutinen, die von einem Computersystem 200 ausgeführt werden, implementiert werden. Die Softwareroutinen können mehrere oder eine Reihe von Anweisungen, Codesequenzen, Konfigurationsinformationen oder anderen Daten, die von einem Verarbeitungssystem wie einem oder mehreren Prozessoren 201 aufgerufen und/oder ausgeführt werden, enthalten. Zunächst kann die Reihe von Anweisungen, Codesequenzen, Konfigurationsdaten oder anderen Daten auf einer Datenspeicherung 204 gespeichert oder über den Bus 208 zum Speicher 202 übertragen werden. Es ist einzusehen, dass die Reihe von Anweisungen, Codesequenzen, Konfigurationsdaten oder anderen Daten mit einer Datenspeicherung 204 mittels jedem üblichen computerlesbaren oder maschinenzugreifbaren Speichermedium wie einer Diskette, CD-ROM, Magnetband, DVD, ROM, etc. gespeichert werden. Es ist auch einzusehen, dass die Reihe von Anweisungen, Codesequenzen, Konfigurationsinformationen oder anderen Daten nicht lokal gespeichert werden muss und auf einem verbreitetem Datensignal, das von einem entfernten Speicherungsgerät wie einem Server in einem Netzwerk über eine Netzwerk/Kommunikationsschnittstelle empfangen wurde, gespeichert werden könnte. Die Anweisungen, Codesequenzen, Konfigurationsinformationen oder anderen Daten können von der Datenspeicherung 204 wie ein Massenspeicher oder von dem verbreiteten Datensignal in einen Speicher 202 kopiert und vom Prozessor 201 aufgerufen und ausgeführt werden.
In einer alternativen Ausführungsform ist die vorliegende Erfindung in diskreter Hardware oder Firmware implementiert. Zum Beispiel könnten ein oder mehrere Application Specific Integrated Circuits (ASICs) mit einigen oder allen der oben beschriebenen Funktionen der vorliegenden Erfindung programmiert werden.
Nun den 6–9 zuwendend werden bestimmte Verfahren der Erfindung in Form von Computersoftware unter Bezugnahme auf eine Reihe von Flussdiagrammen beschrieben. Die Verfahren zum Ausführen durch einen Prozessor auf einem Router oder Netzwerkgerät bilden Computerprogramme bestehend aus von einem Computer ausführbaren Anweisungen. Das Beschreiben der Verfahren unter Bezugnahme auf ein Flussdiagramm ermöglicht es einem Fachmann, solche Programme einschließlich solcher Anweisungen zum Ausführen der Verfahren auf einem geeignet konfigurierten Computer (der Prozessor des Computers, der die Befehle von einem computer-zugreifbaren Medium ausführt) zu entwickeln. Die von einem Computer ausführbaren Anweisungen können in einer Computerprogrammiersprache geschrieben oder können in Firmwarelogik wie einem Application Specific Integrated Circuit (ASIC) verkörpert sein. Wenn sie in einer mit einem anerkannten Standard konformen Programmiersprache geschrieben sind, können solche Anweisungen auf unterschiedlichen Hardwareplattformen oder als Schnittstelle für unterschiedliche Betriebssysteme ausgeführt werden. Zudem wird die vorliegende Erfindung nicht unter Bezugnahme auf eine bestimmte Programmiersprache beschrieben. Es wird anerkannt werden, dass unterschiedliche Programmiersprachen genutzt werden kann, um die Lehren der Erfindung wie sie hier beschrieben sind zu implementieren. Weiterhin ist es in der Fachwelt üblich, von Software in der einen oder anderen Form des Handelns oder Ergebnis Erzielens zu sprechen (z. B. Programm, Prozedur, Prozess, Anwendung ...). Solche Ausdrücke sind lediglich eine abkürzende Methode zu sagen, dass die Ausführung von Software auf einem Computer den Prozessor des Computers zum Durchführen einer Aktion oder Erzeugen eines Ergebnisses veranlasst.
6 ist ein Flussdiagramm, das bestimmte Aspekte eines Verfahrens zur Ausführung durch einen Computer darstellt, welches eine Ausführungsform der dargestellten und in 1–5 gezeigten Erfindung ausführt. In einer Ausführungsform, während des Registrierungsprozesses 300, bei Ablaufblock 310, startet ein Prozessmanager auf einem Router oder anderem Netzwerkgerät eine Anwendung wie z. B. eine BGP-Anwendung 45, woraufhin die Anwendung bei Ablaufblock 313 eine Konfigurationsmanagerschnittstelle 47 startet und bei Ablaufblock 315 fortfahrt, einen Kommunikationskanal 71 zu dem Konfigurationsmanager 70 aufzubauen. Der Ablauf geht weiter bei Feld 317, wo die Anwendung 45 sich beim Konfigurationsmanager 70 mittels der gemeinsamen Nachrichtenschnittstelle 110 registriert, um den Anwendungsnamen, die Priorität und andere anwendungsspezifische Informationen bereitzustellen. In einer Ausführungsform registriert sich die Anwendung 45 durch Senden zweier Nachrichten, die gemäß der gemeinsamen Nachrichtenschnittstelle 45 formatiert sind, wobei der Nachrichten-Tag 132 bei einer Nachricht REGISTER_CM_APP_NAME und bei der anderen Nachricht REGISTER_APP_PRIORITY ist. Die erste Nachricht enthält in dem Bereich des Nachrichteninhalts 136 den Anwendungsnamen "BGP" oder eine Repräsentation dessen. Die zweite Nachricht enthält in dem Bereich des Nachrichteninhalts 136 einen Wert, der die Priorität der BGP-Anwendung 45 relativ zu anderen Anwendungen auf dem Router anzeigt. In einer Ausführungsform, bei Ablaufblock 319, erfasst der Konfigurationsmanager 70 den Anwendungsnamen und Prioritätswert und weist der Anwendung 45 basierend auf der Priorität eine Sequenznummer zu und verknüpft alle registrierten Anwendungen 45/55/65, um eine Verknüpfungsliste basierend auf der Sequenznummer zu bilden. Auf diese Weise ist der Konfigurationsmanager in der Lage, die Sicherungen der Konfigurationsdaten von mehreren Anwendungen 45/55/65 in einer bevorzugten Anwendungsreihenfolge durchzuführen, d. h. die Konfigurationsdaten so zu aktualisieren, dass die verschiedenen Protokollabhängigkeiten, welche in einem gegebenen Router oder Netzwerkgerät vorliegen können, widergespiegelt werden.
In einer Ausführungsform, bei Ablaufblock 312, startet die Anwendung einen Subagenten, angenommen den CLI-Subagenten 42, woraufhin der Subagent 42 bei Ablaufblock 314 einen Kommunikationskanal 25 zu dem CLI-Masteragent 20 aufbaut und sich bei Ablaufblock 316 bei dem CLI-Masteragent 20 registriert. Bei Ablaufblock 318 erfasst der Masteragent 20 die Registrierinformationen, welche im Falle der CLI-Managementschnittstelle ein CLI-Befehlsbaum ist. Andere Registrierinformationen können geeignet sein, wie eine SNMP MIB-Tabelle/Objekt-OID oder ein XML-Element entsprechend den SNMP- oder XML-Managementschnittstellen. Zum Beispiel, im SNMP-Kontext, registriert der Subagent 41 Blätter im MIB-Baum des SNMP-Masteragenten 10, wohingegen im CLI-Kontext der Subagent 42 Blätter im CLI-Befehlsbaum des CLI-Masteragenten 20 registriert. Es sind diese Registrierinformationen, die es den Masteragenten 10/20/30 ermöglichen, die verschiedenen Konfigurationsbefehle und -daten, die sie empfangen, richtig zu identifizieren und zu validieren. Bei Ablaufblock 320 wird die Registrierung abgeschlossen, wenn der CLI-Masteragent 20 und der Konfigurationsmanager 70 ihre jeweiligen Registrierungen und aufgebauten Verbindungen, d. h. Kommunikationskanäle 15/25/35 bestätigen.
Der Konfigurationsmanager 70 und CLI-Masteragent 20 sind nun fähig, das "Horchen" auf der Konfigurationsmanagerschnittstelle 47 beziehungsweise CLI-Subagenten der BGP-Anwendung zu beginnen und sie zum Verarbeiten von Konfigurationsinformationen, welche der BGP-Anwendung mittels der CLI-Managementschnittstelle übergeben wurde, zu nutzen.
Es sollte angemerkt werden, dass in der obigen Beschreibung der Einfachheit halber nur die BGP-Anwendung 45 und die CLI-Managementschnittstelle im Detail beschrieben wurden – natürlich gilt die selbe Beschreibung für SNMP- und XML-Schnittstellen oder die OSPF- oder Ethernetschnittstellenanwendungen 55/65, oder jede andere Managementschnittstelle oder Anwendung, welche fähig ist, auf einem Router oder Netzwerkgerät zu arbeiten.
7 ist ein Flussdiagramm, welches den Agentenbetrieb 400 zwischen den Masteragenten 10/20/30 und den Subagenten 42/52/62 detaillierter darstellt. Die Masteragenten 10/20/30 fungieren als ein Verkehrscontroller und Vermittler für alle Funktionalitäten einer gegebenen Managementschnittstelle für eine Anwendung oder andere Komponente eines Netzwerkgeräts. Wiederum die CLI-Managementschnittstelle und die BGP-Anwendung 45 als ein Beispiel benutzend, verarbeitet der CLI-Masteragent 20 bei Ablaufblock 410 einen eingehenden CLI-Befehl und zugehörige Konfigurationsdaten einschließlich Validieren des Befehls und der Daten gemäß der Registrierinformationen. Die Registrierdaten enthalten in diesem Fall einen CLI-Befehlsbaum. Jedoch können andere Registrierdaten verwendet werden, ohne den Bereich der Erfindung zu verlassen, abhängig von der Managementschnittstelle wie SNMP Management Information Bases (MIB) und XML-Tags oder unterstützte Elemente, oder jede andere Daten, welche dem Masteragent das Identifizieren und Validieren der eingehenden Managementbefehle und Konfigurationsdaten und deren Richten an die richtige Anwendung ermöglichen.
In einer Ausführungsform, bei Ablaufblock 410, parst der Masteragent 20 den Befehl und die zugehörigen Konfigurationsdaten (z. B. die Parameter zum CLI-Befehl) und validiert die Syntax und gegebenenfalls die Parameternutzung des CLI-Befehls gegen die zuvor zur Registrierzeit vom Subagent 42 an den Masteragent 20 gelieferten Registrierdaten. Bei Ablaufblock 430 übergibt der Masteragent 20 die validierten Befehls- und Konfigurationsdaten an den richtigen Subagenten, in diesem Fall den CLI-Subagenten für die BGP-Anwendung 45. Der Masteragent 20 nutzt die gemeinsame Nachrichtenschnittstelle 100 zum Übergeben der Befehls- und Konfigurationsdaten an den Subagenten 42 über den Kommunikationskanal 25, wobei er die geeigneten Headerinformationen einschließlich Nachrichten-Tag 132 mit Wert "CLI_CMD" zum Identifizieren des Nachrichteninhalts 136 und eine Nachrichtenlänge 134, welche die Länge des Nachrichten-Tags 132, des Nachrichteninhalts 136 und der Nachrichtenlänge 134 selbst einschließt, anfügt.
In einer Ausführungsform, bei Ablaufblock 440, empfängt der CLI-Subagent 42 für die BGP-Anwendung 45 von dem CLI-Masteragent 20 die Befehls- und Konfigurationsdaten in der Nachrichtenschnittstelle 100 und übergibt diese an die BGP-Anwendung 45 zum Verarbeiten bei dem vordefinierten Prozess 500, detaillierter beschrieben in 8. Wenn zutreffend empfängt der CLI-Subagent 42 bei Ablaufblock 450 formatierte Antwortdaten von der Anwendung 45 und übergibt ebenfalls mittels der gemeinsamen Nachrichtenschnittstelle 100 die Antwort an den CLI-Masteragent 20, der die Antwort in den Nachrichteninhalt 136 einfügt und den geeigneten Nachrichten-Tag 132 und Nachrichtenlänge 134 oder welche anderen Header zum Senden der Nachricht über den Kommunikationskanal 25 auch immer benötigt werden zufügt. Bei Ablaufblock 460 schließt der Masteragent die Verarbeitung jeglicher Antwort der Anwendung 45 durch Entfernen der Nachrichtenheader – den Nachrichten-Tag 132 und die Nachrichtenlänge 134 – ab und übergibt die Antwort zurück an die entsprechende Managementschnittstelle, in diesem Fall die CLI-Managementschnittstelle.
8 ist ein Flussdiagramm, das den Anwendung/Konfigurationsmanagerschnittstellenbetrieb zwischen den Anwendungen 45/55/65 und den Konfigurationsmanagerschnittstellen 47/57/67 detaillierter darstellt. Da alle Aktualisierungen der Routerkonfiguration vom Konfigurationsmanager 70 gemanagt werden, fungieren die Konfigurationsmanagerschnittstellen 47/57/67 als ein Verkehrscontroller und Vermittler für alle Funktionalitäten einer gegebenen Anwendung gegenüber der Konfiguration. Mit anderen Worten, alle Aktualisierungen oder Zugriffe auf die Konfiguration, welche eine gegebene Anwendung benötigen könnte, werden durch die Konfigurationsmanagerschnittstellen 47/57/67 jeder Anwendung behandelt. Wiederum die CLI-Managementschnittstelle und die BGP-Anwendung 45 als ein Beispiel benutzend, empfangt die Anwendung für das BGP-Protokoll 45 bei Ablaufblock 510 validierte Befehls- und Konfigurationsdaten vom CLI-Subagent 42 und entfernt die Nachrichtenschnittstellenheader – Nachrichten-Tag und Nachrichtenlänge. Bei Ablaufblock 520 ruft die Anwendung 42 die UMOL 44 auf, um die ausgepackten CLI-Befehle und Konfigurationsinformationen in eine interne Datenstruktur 74 zu formatieren. In einer Ausführungsform nimmt die UMOL-interne Datenstruktur 74 die Form von Aktionen und Parametern an. Bei Ablaufblock 530 übergibt die Anwendung 42 die formatierten Aktionen und Parameter an die Konfigurationsmanagerschnittstelle 47. Bei Ablaufblock 540 übergibt die Konfigurationsmanagerschnittstelle 47 die Aktionen und Parameter an den Konfigurationsmanager 70 als Antwort auf vom Konfigurationsmanager erstellte periodische SAVE-Anfragen über die gemeinsame Nachrichtenschnittstelle 100, d. h. in Form von Nachrichten mit einem Nachrichten-TAG "SAVE_REQUEST", und gesendet über Kommunikationskanal 71. Die Antworten, die übergeben werden, nehmen die Gestalt von Nachrichten mit einem Nachrichten-TAG "SAVE_CONTENT" an, um anzuzeigen, dass der Nachrichteninhalt 136 der Nachricht gemäß der gemeinsamen Nachrichtenschnittstelle 110 aus den von der Anwendung 42 und der universalen Managementobjektschicht 44 erzeugten Aktionen und Parameter besteht. Nach der Verarbeitung durch den Konfigurationsmanager 600, wie in 9 beschrieben ist, fährt die Verarbeitung bei Ablaufblock 560 fort, wo die Anwendung 42 die Nachrichtenschnittstellenheader entfernt, so dass sie gegebenenfalls auf die in dem Nachrichteninhalt 136 enthaltene Antwort zugreifen kann. Wenn die Antwort für den Nutzer bestimmt ist, ruft die Anwendung die UMOL 44 zum Formatieren der ausgepackten Antwort auf, und ruft den Subagent 42 zum Übergeben der formatieren Antwort zurück an den Masteragent mittels der gemeinsamen Nachrichtenschnittstelle 110 und Kommunikationskanal 25 auf (z. B. durch Anhängen von Nachrichten-Tag, Nachrichtenlänge, etc.).
9 ist ein Flussdiagramm, das den Konfigurationsmanagerbetrieb 600 darstellt. Da sich die Kenntnis der detaillierten Befehlssyntax, Befehlsausführung, Validation und andere Kenntnisse, welche für die Verarbeitung der von dem Masteragent/Subagent-Modell empfangenen Befehls- und Konfigurationsdaten wichtig sind, in der Anwendungsschicht 40/50/60 befinden, können die tatsächlichen, aus diesen Kenntnissen resultierenden Aktualisierungen der Konfiguration auf einen begrenzte Gruppe von Aktionen und Parametern reduziert werden, welche vom Konfigurationsmanager 70 über die Konfigurationsmanagerschnittstelle 47/57/67 angewendet werden. Demnach arbeitet der Konfigurationsmanager 70 als eine "dumme" Schicht zwischen den Anwendungen 45/55/65 und der tatsächlichen Routerkonfiguration.
In einer Ausführungsform, bei Ablaufblock 610, ermittelt der Konfigurationsmanager 70, ob es irgendwelche registrierten Anwendungen 45/55/65 gibt, die Konfigurationsdaten haben könnten, welche gespeichert werden müssen. Erinnert sei, dass sich jede Anwendung bei dem Konfigurationsmanager 70 über die gemeinsame Nachrichtenschnittstelle 110 zur Startzeit registriert. Wenn es keine aktiven registrierten Anwendungen gibt, wird der Konfigurationsmanagerbetrieb bei 650 beendet. Wenn es registrierte Anwendungen gibt, erzeugt der Konfigurationsmanager 70 bei Ablaufblock 620 eine SAVE_REQUEST-Nachricht für die nächste registrierte Anwendung. Die nächste registrierte Anwendung wird auf der Grundlage der Sequenznummer einer Anwendung im Vergleich mit den Sequenznummern anderer registrierter Anwendungen ermittelt. Erinnert sei, dass die Anwendungssequenznummern zur Zeit der Registrierung erzeugt wurden. Die Anwendungssequenznummern ermöglichen dem Konfigurationsmanager, die notwendige Konfigurationsaktualisierungspriorität zu erhalten. Die Konfigurationsaktualisierungspriorität hängt von dem Typ der Anwendung ab, der unterstützt wird.
In einer Ausführungsform ist die SAVE_REQUEST-Nachricht gemäß der gemeinsamen Nachrichtenstelle mit geeignetem Nachrichten-TAG 132 und Werten der Nachrichtenlänge 134 formatiert und wird über den Kommunikationskanal 71 zwischen dem Konfigurationsmanager 70 und der Konfigurationsmanagerschnittstelle 47 gesendet. Bei Ablaufblock 630 erzeugt die nächste registrierte Anwendung einen SAVE_CONTENT gemäß der gemeinsamen Nachrichtenschnittstelle 110. Der SAVE_CONTENT-Nachrichteninhalt 136 enthält den Inhalt, der für das Aktualisieren der letzten gesicherten Konfiguration des Routers benötigt wird. In einer Ausführungsform wird der Inhalt in Form von Aktionen und Parametern gemäß der UMOL 44 der Anwendung erzeugt. Der Inhalt ist in der gleichen Form, d. h. die Aktionen und Parameter ungeachtet der Managementschnittstelle, CLI, SNMP oder XML, von welcher der Inhalt stammte, ob es eine SNMP MIB-Tabellen-OID, XML-Elemente oder CLI-Befehle war.
Bei Ablaufblock 640 entfernt der Konfigurationsmanager 70 die Nachrichtenheader von der SAVE-CONTENT-Nachricht – den Nachrichten-TAG 132 und Nachrichtenlänge 134 – und aktualisiert die letzten gesicherten Konfigurationsdaten gemäß des Nachrichteninhalts 136. Der Konfigurationsmanagerbetrieb 600 wird fortgeführt bei Ablaufblock 610, bis es keine aktiven registrierten Anwendungen mehr gibt, von denen Konfigurationsaktualisierungen empfangen werden.
Dementsprechend ist ein neues Verfahren und eine neue Vorrichtung beschrieben, in welchen ein Konfigurationsmanagementsystem 100 das dynamische Management einer Konfiguration auf einem Netzwerkgerät ermöglicht. Von der vorangegangen Beschreibung werden die Fachleute erkennen, dass viele andere Variationen der vorliegenden Erfindung möglich sind. Insbesondere, obwohl die vorliegende Erfindung als in einem Netzwerk, umfassend einen Masteragent, Subagent, Anwendung, Konfigurationsmanager und verbundene Komponenten, implementiert beschrieben wurde, sollte angemerkt werden, dass einige der hier beschriebenen Logiken auf andere Komponenten eines Netzwerks verteilt werden können, ohne den Bereich der vorliegenden Erfindung zu verlassen.
Zum Beispiel können Ausführungsformen der Erfindung als ein auf einem maschinenzugreifbaren Medium (auch bezeichnet als ein computerlesbares Medium oder ein prozessorlesbares Medium) gespeichertes Softwareprodukt verkörpert sein. Das maschinenzugreifbare Medium kann jede Art eines magnetischen, optischen oder elektrischen Speichermediums inklusive einer Diskette, CD-ROM, Speichergerät (flüchtig oder nichtflüchtig) oder ähnliche Speichermechanismen sein. Das maschinenzugreifbare Medium kann verschiedene Befehlssätze, Codesequenzen, Konfigurationsinformationen oder andere Daten enthalten. Als ein Beispiel können die hier beschriebenen Prozeduren für die gemeinsame Nachrichtenschnittstelle 110, die Masteragenten 10/20/30, die Subagenten 42/52/62, die Anwendungen 44/54/64, den Konfigurationsmanager 70 und verbundene Komponenten auf dem maschinenzugreifbaren Medium gespeichert werden. Zudem können die Registrierdaten, die die Anwendungen zum Registrieren beim Masteragent beziehungsweise Konfigurationsmanager verwenden, oder die Konfigurationsbefehle, Anfragen, Aktionen und Parameter und zugehörige andere Daten in einem internen Speicherbereich oder einem externen Speichermedium, welche maschinenzugreifbar sind, gespeichert werden. Die Fachleute werden verstehen, dass andere Anweisungen oder Operationen, die zum Implementieren der beschriebenen Erfindung notwendig sind, ebenfalls auf einem maschinenzugreifbaren Medium gespeichert werden können.

Claims

Ein Verfahren zum Management der Konfiguration eines Netzwerkgeräts, dadurch gekennzeichnet, dass es die folgenden Schritte umfasst: Registrieren einer Anwendung, die eine Priorität hat, bei einem Masteragenten (10, 20, 30) und einem Konfigurationsmanager (70); Validieren von empfangenen Daten bei dem Masteragenten; Weiterleiten der validierten empfangenen Daten an die Anwendung, wobei die Anwendung die validierten empfangenen Daten in eine interne Datenstruktur einer universalen Managementobjektschicht (44; 54, 64) umwandelt; und periodisches Auffordern, dass ein Inhalt der internen Datenstruktur der universalen Managementobjektschicht an den Konfigurationsmanager (70) weitergeleitet wird, wobei die Konfiguration gemäß der Priorität der Anwendung aktualisiert wird, und dadurch, dass die genannte Anwendung, der genannte Masteragent und der genannte Konfigurationsmanager (70) unabhängig voneinander arbeiten.
Das Verfahren gemäß Anspruch 1, wobei der Masteragent eine SNMP-Managementschnittstelle darstellt und Registrieren die Aufnahme eines neuen Blattes in einen SNMP-MIB-Baum bedeutet.
Das Verfahren gemäß Anspruch 1, wobei der Masteragent eine CLI-Managementschnittstelle darstellt und Registrieren die Aufnahme eines neuen Blattes in einen CLI-Befehlsbaum bedeutet.
Das Verfahren gemäß Anspruch 1, wobei der Masteragent eine XML-Managementschnittstelle darstellt und Registrieren die Aufnahme eines neuen Tags in eine XML-Datei bedeutet.
Das Verfahren gemäß Anspruch 1, wobei Validieren einen Vergleich der Eingangsdaten mit den Registrierinformationen des Masteragenten umfasst.
Das Verfahren gemäß Anspruch 1, wobei das Umwandeln in eine interne Datenstruktur (74) einer universalen Managementobjektschicht (44; 54, 64) ein Formatieren der validierten Daten in eine Aktion und/oder einen Parameter beinhaltet.
Das Verfahren gemäß Anspruch 6, wobei das Formatieren von einer universalen Managementobjektschicht, die einer Anwendung zugeordnet ist, durchgeführt wird.
Das Verfahren gemäß Anspruch 6, wobei die Aktion und der Parameter ungeachtet der Herkunft der Eingangsdaten einem gebräuchlichen Format entsprechen.
Das Verfahren gemäß Anspruch 8, wobei die Herkunft der Eingangsdaten ein CLI-Befehl ist.
Das Verfahren gemäß Anspruch 8, wobei die Herkunft der Eingangsdaten eine SNMP-Anfrage ist.
Das Verfahren gemäß Anspruch 8, wobei die Herkunft der Eingangsdaten eine XML-Anfrage ist.
Ein Konfigurationsmanagementsystem (100) für ein Netzwerkgerät, umfassend: eine Konfigurationseinheit zur Implementierung einer Konfiguration des Netzwerkgeräts; einen Empfänger zum Empfangen und Validieren von Konfigurationsdaten; eine Anwendungseinheit, um den Einsatz einer Anwendung, die eine Priorität hat, zu ermöglichen, wobei die Anwendung die validierten Daten in ein Format umwandelt, dadurch gekennzeichnet, dass es auch umfasst: einen Prozessor für periodisches Anwenden der umgewandelten Daten auf die Konfiguration gemäß der Priorität der Anwendung, einen Masteragenten und einen Konfigurationsmanager, und Mittel, die so eingerichtet sind, dass die Anwendung bei dem Masteragent (10, 20, 30) und dem Konfigurationsmanager (70) registriert wird, wobei die Anwendung, der Masteragent und der Konfigurationsmanager unabhängig voneinander arbeiten.
Das Konfigurationsmanagementsystem gemäß Anspruch 12, wobei der Empfänger eine Managementschnittstelle zur Anwendung ist.
Das Konfigurationsmanagementsystem gemäß Anspruch 13, wobei die Managementschnittstelle zur Nutzung von SNMP und Validierung der Eingangsdaten gemäß eines Blattes in einem SNMP-MIB-Baum eingerichtet ist.
Das Konfigurationsmanagementsystem gemäß Anspruch 13, wobei die Managementschnittstelle zur Nutzung von CLI und Validierung der Eingangsdaten gemäß eines Blattes in einem CLI-Befehlsbaum eingerichtet ist.
Das Konfigurationsmanagementsystem gemäß Anspruch 13, wobei die Managementschnittstelle zur Nutzung von XML und Validierung der Eingangsdaten gemäß eines Tags in einer XML-Datei eingerichtet ist.
Das Konfigurationsmanagementsystem gemäß Anspruch 12, wobei das Format eine Aktion und/oder einen Parameter umfasst, und der Prozessor zum Anwenden der Aktion und des Parameters auf die Konfiguration gemäß der Priorität der Anwendung eingerichtet ist.
Das Konfigurationsmanagementsystem gemäß Anspruch 17, weiterhin umfassend eine universale Managementobjektschicht, UMOL, die mit der Anwendung in Zusammenhang steht, wobei die UMOL zur Erzeugung einer Aktion und/oder Parameters in einem gebräuchlichen Format ungeachtet der Herkunft der Eingangsdaten eingerichtet ist.
Das Konfigurationsmanagementsystem gemäß Anspruch 18, wobei die Herkunft der Eingangsdaten ein CLI-Befehl ist.
Das Konfigurationsmanagementsystem gemäß Anspruch 18, wobei die Herkunft der Eingangsdaten eine SNMP-Anfrage ist.
Das Konfigurationsmanagementsystem gemäß Anspruch 18, wobei die Herkunft der Eingangsdaten eine XML-Anfrage ist.
Ein Netzwerkgerät, umfassend: einen Eingangsempfänger zum Empfangen einer Eingabe für eine Konfiguration des Netzwerkgeräts; eine Anwendungseinheit, um die Nutzung einer Anwendung, die eine Priorität hat, zu ermöglichen, wobei die Anwendung mit dem Eingangsempfänger verbunden ist, um die empfangene Eingabe auf die Konfiguration anzuwenden, dadurch gekennzeichnet, dass es auch umfasst: einen Controller in Kommunikation mit der Anwendung, um die Anwendung der empfangenen Eingabe auf die Konfiguration gemäß der Priorität der Anwendung zu steuern, einen Masteragenten und einen Konfigurationsmanager, und Mittel, die so eingerichtet sind, dass die Anwendung bei einem Masteragent (10, 20, 30) und einem Konfigurationsmanager (70) registriert wird, wobei die Anwendung, der Masteragent und der Konfigurationsmanager unabhängig voneinander arbeiten; und der Controller dazu eingerichtet ist, ohne Abschalten des Netzwerkgeräts zu arbeiten.
Das Netzwerkgerät gemäß Anspruch 22, wobei der Eingangsempfänger umfasst: einen ersten Agenten zum Empfangen der Eingabe von einer externen Quelle, und einen zweiten Agenten in Kommunikation mit dem ersten Agenten, wobei der zweite Agent die empfangene Eingabe validiert, bevor die Anwendung die empfangene Eingabe auf die Konfiguration anwendet.
Das Netzwerkgerät gemäß Anspruch 23, wobei der erste und zweite Agent eine Managementschnittstelle zur Anwendung umfassen.
Das Netzwerkgerät gemäß Anspruch 24, wobei die Managementschnittstelle zur Nutzung von SNMP und Validierung der Eingangsdaten gemäß eines Blattes in einem SNMP-MIB-Baum eingerichtet ist.
Das Netzwerkgerät gemäß Anspruch 24, wobei die Managementschnittstelle zur Nutzung von CLI und Validierung der Eingangsdaten gemäß eines Blattes in einem CLI-Befehlsbaum eingerichtet ist.
Das Netzwerkgerät gemäß Anspruch 24, wobei die Managementschnittstelle zur Nutzung von XML und Validierung der Eingangsdaten gemäß eines Tags in einer XML-Datei eingerichtet ist.
Das Netzwerkgerät gemäß Anspruch 24, wobei die Anwendung eine universale Managementobjektschicht zum Umwandeln der Eingabe in ein gebräuchliches Format umfasst, das eine Aktion und/oder einen Parameter umfasst, und wobei der Controller zum periodischen Anwenden der Aktion und des Parameters auf die Konfiguration gemäß der Priorität der Anwendung eingerichtet ist.
Das Netzwerkgerät gemäß Anspruch 23, wobei die Eingabe ein CLI-Befehl ist.
Das Netzwerkgerät gemäß Anspruch 23, wobei die Eingabe eine SNMP-Anfrage ist.
Das Netzwerkgerät gemäß Anspruch 23, wobei die Quelle der Eingabe eine XML-Anfrage ist.