Verwenden des juniper.device.config Ansible-Moduls zum Abrufen oder Vergleichen von Junos OS-Konfigurationen

Wenn Sie das juniper.device.config Modul zum Abrufen der Konfiguration verwenden, müssen Sie den retrieve Parameter in die Argumentliste des Moduls aufnehmen. Der retrieve Parameter gibt die Konfigurationsdatenbank an, aus der die Daten abgerufen werden sollen. Sie können die folgenden Werte festlegen retrieve , um Konfigurationsdaten aus der jeweiligen Datenbank zurückzugeben:

• candidate– Daten aus der Kandidatenkonfiguration abrufen.

• committed– Ruft Daten aus der festgeschriebenen Konfiguration ab.

Committete Konfigurationsdatenbank

Im folgenden Playbook wird die vollständige Konfiguration im Textformat für jedes Gerät in der Bestandsgruppe abgerufen:

Datenbank für die Konfiguration von Kandidaten

Im folgenden Playbook wird die vollständige Kandidatenkonfiguration im Textformat für jedes Gerät in der Bestandsgruppe abgerufen. Das Modul gibt einen Fehler zurück, wenn die Datenbank gesperrt oder geändert ist.

Zusätzlich zum Abrufen der vollständigen Junos OS-Konfiguration können Sie mithilfe des filter Parameters bestimmte Teile der Konfiguration abrufen. Der filter Wert des Parameters ist eine Zeichenfolge, die den Teilstrukturfilter enthält, der die zurückzugebenden Konfigurationsanweisungen auswählt. Der Teilstrukturfilter gibt die Konfigurationsdaten zurück, die den Auswahlkriterien entsprechen. Wenn Sie mehrere Hierarchien anfordern, muss der Wert von filter alle Ebenen der Konfigurationshierarchie darstellen, beginnend mit der Wurzel (dargestellt durch das <configuration> Element) bis hin zu jedem anzuzeigenden Element.

Im folgenden Playbook werden die Konfiguration auf [edit interfaces] [edit protocols] und die Hierarchieebene in der festgeschriebenen Konfigurationsdatenbank für jedes Gerät abgerufen und gedruckt:

Im folgenden Playbook wird die Konfiguration für die ge-1/0/1-Schnittstelle abgerufen und ausgedruckt:

Im folgenden Playbook wird die auf Hierarchieebene [edit system services] festgeschriebene Konfiguration abgerufen und ausgedruckt:

Wenn Sie das juniper.device.config Modul zum Abrufen der Konfiguration verwenden, ruft das Modul die Junos XML-Protokolloperation <get-configuration> auf, die Konfigurationsdaten in verschiedenen Formaten zurückgeben kann. Standardmäßig gibt das Modul Konfigurationsdaten als formatierten Text zurück. Das Textformat verwendet Zeilenumbrüche, Tabulatoren und andere Leerzeichen, geschweifte Klammern und eckige Klammern, um die hierarchischen Beziehungen zwischen den Anweisungen anzugeben.

Um das Format anzugeben, in dem die Konfigurationsdaten zurückgegeben werden sollen, setzen Sie den format Parameter des Moduls auf das erforderliche Format. Zu den zulässigen Werten gehören:

• json– JavaScript Object Notation (JSON)

• set– Junos OS-Befehle set

• text– Formatierter Text (Standard)

• xml– Junos XML-Elemente

In der Playbook-Ausgabe enthalten die config Schlüssel und config_lines die Konfiguration im angeforderten Format. Wenn Sie das Junos-XML- oder JSON-Format anfordern, enthält der config_parsed Schlüssel die entsprechende Konfiguration im JSON-Format.

Mit dem folgenden Playbook wird die vollständige Konfiguration für jedes Gerät in der Bestandslistengruppe im XML-Format abgerufen:

Junos-Geräte geben RPC-Antworten im XML-Format zurück. Selbst wenn Sie Daten im JSON-, Set- oder Textformat anfordern, umschließt die Antwort des NETCONF-Servers die Daten in XML-Tags. Daher müssen die Ansible-Module einen XML-Parser verwenden, um die RPC-Antwort zu verarbeiten. XML-Parser legen häufig Sicherheitsgrenzen für die Dokumenttiefe und die Größe einzelner Textknoten fest. Diese Grenzwerte sind eine integrierte Sicherheitsmaßnahme, um böswillige Angriffe, Speicherauslastung und allgemeine Leistungsprobleme zu verhindern.

Netzwerkgeräte können große, komplexe Konfigurationen und umfangreiche Befehls- und RPC-Ausgaben haben. Standardmäßig erzwingt der XML-Parser eine Größenbeschränkung für Textknoten, die in der Regel bei etwa 10 MB liegt. Wenn ein einzelner Textknoten die Größenbeschränkung überschreitet, generiert der Parser einen Fehler. Zum Beispiel:

Wenn Sie Konfigurations-, Befehls- oder RPC-Daten im XML-Format anfordern, enthält das Dokument im Allgemeinen viele kleine XML-Knoten, und der Parser stößt nur in seltenen Fällen auf dieses Limit. Wenn Sie jedoch dieselben Daten im JSON-, Set- oder Textformat anfordern, gibt das Gerät die Daten in einem oder mehreren XML-Tags zurück. Beispielsweise umschließt das Gerät zusätzlich zum <rpc-reply> Tag Set- und Textkonfigurationsdaten in einem <configuration-set> Tag oder einem <configuration-text> Tag. Auf ähnliche Weise schließt das Gerät die Befehlsausgabe im Textformat in ein <output> Element ein. Bei umfangreichen Daten kann die Antwort zu einem einzelnen XML-Textknoten führen, der die Standardgrenzwerte des Parsers überschreitet.

Wenn Sie große Konfigurationen oder umfangreiche Befehls- oder RPC-Ausgaben in einem beliebigen Format anfordern, verarbeitet der XML-Parser die RPC-Antwort. Daher kann der Fehler "Knotengrößenbegrenzung" für alle Formate auftreten, obwohl er bei XML-Daten seltener ist. In diesen Fällen wird empfohlen, die Antwort als XML zurückzugeben.

Wenn Sie eines der anderen Formate benötigen, können Sie die Parser-Grenzwerte überschreiben, indem Sie das huge_tree: true Argument Modul einfügen. Wenn Sie huge_tree: trueverwenden, wird die XML_PARSE_HUGE Option aktiviert, die Grenzwerte für die maximale Textknotengröße, die maximale Attributgröße und die maximale Tiefe ignoriert. Daher kann der Parser große XML-Dokumente, tiefe XML-Strukturen und große Textknoten verarbeiten.

Im folgenden Playbook wird die festgeschriebene Konfiguration im set Format für die Geräte in der Bestandsgruppe abgerufen. Zu den juniper.device.config Argumenten des Moduls gehören huge_tree: true. Mit dieser Option ist die Aufgabe auch dann erfolgreich, wenn eine bestimmte Antwort die standardmäßige Knotengrößenbeschränkung des Parsers überschreitet.

Sie können standardisierte oder benutzerdefinierte YANG-Module auf Junos-Geräte laden, um Datenmodelle hinzuzufügen, die von Junos OS nicht nativ unterstützt, aber durch Übersetzung unterstützt werden können. Sie konfigurieren nicht native Datenmodelle in der Kandidatenkonfiguration mit der für diese Modelle definierten Syntax. Wenn Sie die Konfiguration bestätigen, übersetzen die Übersetzungsskripte des Datenmodells diese Daten und übernehmen die entsprechende Junos OS-Konfiguration als vorübergehende Änderung in der Checkout-Konfiguration.

Die Kandidaten- und aktiven Konfigurationen enthalten die Konfigurationsdaten für nicht native YANG-Datenmodelle in der von diesen Modellen definierten Syntax. Sie können das juniper.device.config Modul verwenden, um Konfigurationsdaten für Standard- (IETF, OpenConfig) und benutzerdefinierte YANG-Datenmodelle abzurufen und die native Junos OS-Konfiguration abzurufen. Standardmäßig enthält die Antwort des Moduls keine Konfigurationsdaten für YANG-Datenmodelle von Drittanbietern.

Um Konfigurationsdaten abzurufen, die durch ein nicht natives YANG-Datenmodell definiert sind, führen Sie zusätzlich zum Abrufen der Junos OS-Konfiguration das Modul mit dem model Parameter aus und schließen Sie den namespace Parameter bei Bedarf ein. Das model Argument nimmt einen der folgenden Werte an:

• custom– Ruft Konfigurationsdaten ab, die durch benutzerdefinierte YANG-Datenmodelle definiert sind. Sie müssen das namespace Argument beim Abrufen von Daten für benutzerdefinierte YANG-Datenmodelle einbeziehen.

• ietf– Rufen Sie Konfigurationsdaten ab, die durch IETF-YANG-Datenmodelle definiert sind.

• openconfig– Rufen Sie Konfigurationsdaten ab, die durch OpenConfig YANG-Datenmodelle definiert sind.

• True– Rufen Sie alle Konfigurationsdaten ab, einschließlich der vollständigen Junos OS-Konfiguration und Daten aus beliebigen YANG-Datenmodellen.

Wenn das model Argument oder angibt ietf openconfig, verwendet das Modul automatisch den entsprechenden Namespace. Wenn Sie model: custom angeben, Daten für ein benutzerdefiniertes YANG-Datenmodell abzurufen, müssen Sie das namespace Argument auch mit dem entsprechenden Namespace einschließen.

Wenn Sie das model Argument mit dem Wert custom, ietfoder und openconfig auch das filter Argument einschließen, um eine bestimmte XML-Unterstruktur zurückzugeben, gibt Junos OS nur die übereinstimmende Hierarchie aus dem nicht nativen Datenmodell zurück. Enthält die Junos OS-Konfiguration eine gleichnamige Hierarchie, zum Beispiel "Schnittstellen", wird diese nicht in die Antwort einbezogen. Die filter Option wird bei Verwendung von model: Truenicht unterstützt.

Wenn Sie das juniper.device.config Modul zum Abrufen nicht nativer Konfigurationsdaten verwenden, können Sie das Format der zurückgegebenen Daten nur angeben, wenn Sie auch den filter Parameter angeben. Wenn Sie den filter Parameter weglassen, müssen format: xmlSie angeben.

Im folgenden Playbook wird die OpenConfig-Konfigurationshierarchie interfaces aus der festgeschriebenen Konfiguration abgerufen. Wenn Sie das filter Argument weglassen, gibt der RPC die vollständigen Junos OS- und OpenConfig-Konfigurationen zurück.

Die folgende Aufgabe ruft die l2vpn Konfigurationshierarchie aus der festgeschriebenen Konfiguration für ein benutzerdefiniertes YANG-Datenmodell mit dem angegebenen Namespace ab:

Mit der folgenden Aufgabe werden die vollständige Junos OS-Konfiguration sowie die Konfigurationsdaten für andere YANG-Datenmodelle abgerufen, die dem Gerät hinzugefügt wurden:

Wenn Sie das juniper.device.config Modul zum Abrufen der Konfiguration verwenden, ruft das Modul den Junos XML-Protokollvorgang <get-configuration> auf. Das Modul unterstützt explizite Argumente für viele der <get-configuration> Attribute, z. B. das format Attribut. Das Modul unterstützt auch das options Argument, wodurch Sie alle zusätzlichen <get-configuration> Attribute einschließen können, für die kein äquivalentes Modulargument vorhanden ist. Das options Argument verwendet ein Wörterbuch von Schlüssel/Wert-Paaren aller Attribute, die von der <get-configuration> Operation unterstützt werden.

Eine vollständige Liste der Attribute, die von der Junos XML-Protokolloperation <get-configuration> unterstützt werden, finden Sie unter <get-configuration>.

Beispielsweise ruft das juniper.device.config Modul Daten aus der Konfiguration vor der Vererbung ab, in der die <groups>Tags , <apply-groups>, <apply-groups-except>und <interface-range> separate Elemente in der Konfigurationsausgabe sind. Um Daten aus der Konfiguration nach der Vererbung abzurufen, können Sie das options Argument mit inherit: inheriteinschließen. Die Konfiguration nach der Vererbung zeigt Anweisungen an, die von benutzerdefinierten Gruppen und Bereichen als untergeordnete Elemente der vererbenden Anweisungen geerbt wurden.

Im folgenden Playbook werden die Konfigurationsdaten auf Hierarchieebene [edit system services] aus der Konfiguration nach der Vererbung abgerufen. In der Konfiguration nach der Vererbung werden Anweisungen, die unter Gruppenhierarchieebenen [edit groups global system services] wie konfiguriert sind, unter [edit system services] den abgerufenen Konfigurationsdaten geerbt und zurückgegeben.

Wenn Sie das juniper.device.config Modul zum Abrufen der Konfiguration verwenden, können Sie die zurückgegebenen Konfigurationsdaten in einer Datei auf dem lokalen Ansible-Steuerungsknoten speichern. Um die Daten in einer Datei zu speichern, fügen Sie die Parameter oder Parameter des dest_dir Moduls ein dest . Die dest_dir Option gibt einen Verzeichnispfad an. Die dest Option kann sowohl einen Pfad als auch einen Dateinamen angeben. Wenn bereits eine Ausgabedatei mit dem Zielnamen vorhanden ist, überschreibt das Modul die Datei.

Um das Verzeichnis anzugeben, in dem die abgerufenen Konfigurationen gespeichert werden sollen, setzen Sie das dest_dir Argument auf den Pfad des Zielverzeichnisses. Die Konfiguration für jedes Gerät wird in einer separaten Datei mit dem Namen hostname.config gespeichert.

Im folgenden Playbook wird die festgeschriebene Konfiguration von allen Geräten in der Bestandsgruppe abgerufen. Das Playbook speichert jede Gerätekonfiguration in einer separaten Datei im Verzeichnis configs unter dem Verzeichnis playbook auf dem Ansible-Steuerungsknoten.

Um den Pfad und den Dateinamen für die Ausgabedateien anzugeben, setzen Sie das dest Argument auf den absoluten oder relativen Pfad der Datei. Wenn Sie das dest Argument angeben, aber das Verzeichnis weglassen, werden die Dateien im Playbook-Verzeichnis gespeichert. Wenn Sie die Konfiguration für mehrere Geräte abrufen, muss das dest Argument eine Variable enthalten, z. B {{ inventory_hostname }} . um den Dateinamen für jedes Gerät zu unterscheiden. Wenn Sie die Dateinamen nicht unterscheiden, überschreibt die Konfigurationsdatei für jedes Gerät die Konfigurationsdatei der anderen Geräte.

Im folgenden Playbook wird die [edit system services] Hierarchie aus der Datenbank für die festgeschriebene Konfiguration auf allen Geräten in der Bestandsgruppe abgerufen. Das Playbook speichert jede Gerätekonfiguration in einer separaten Datei im Playbook-Verzeichnis auf dem Ansible-Steuerungsknoten. Jede Datei wird durch ihren Hostnamen eindeutig identifiziert.

Wenn Sie die Konfigurationsdaten in Dateien speichern und die Konfigurationsdaten in der Antwort des Moduls nicht duplizieren möchten, können Sie sie optional in die Argumentliste des Moduls aufnehmen return_output: false . Die Einstellung return_output auf false bewirkt, dass das Modul die configTasten , config_linesund config_parsed in seiner Antwort weglässt. Dies kann erforderlich sein, wenn das Gerät eine erhebliche Menge an Konfigurationsdaten zurückgibt.

Das juniper.device.config Modul ermöglicht es Ihnen, die aktive Konfiguration mit einer zuvor festgeschriebenen Konfiguration oder Rollback-Konfiguration zu vergleichen. Um die aktive Konfiguration mit einer vorherigen Konfiguration zu vergleichen, geben Sie die folgenden Modulargumente an:

Wenn Sie das rollback: id Argument angeben, setzt das Modul standardmäßig die Konfiguration zurück, führt eine Commit-Prüfung durch und führt die Änderungen aus. Sie müssen das commit: false Argument angeben, um nur die Konfigurationen zu vergleichen und zu verhindern, dass das Modul die Rollback-Konfiguration lädt und festschreibt. Das Einfügen des check: false Arguments verhindert die unnötige Commit-Überprüfung.

Das Modul gibt die Schlüssel und diff_lines zurückdiff. Die Schlüssel enthalten die Konfigurationsunterschiede zwischen der aktiven und der vorherigen Konfiguration im Diff- oder Patch-Format.

• diff– Wörterbuch, das einen einzelnen Schlüssel mit dem Namen prepared und seinem Wert enthält, d. h. eine einzelne mehrzeilige Zeichenfolge, die die Unterschiede enthält.

• diff_lines– Liste der einzeiligen Zeichenfolgen, die die Unterschiede enthalten.

Um die Unterschiede in einer Datei auf dem lokalen Ansible-Steuerknoten zu speichern, schließen Sie das diffs_file Argument ein und definieren Sie den absoluten oder relativen Pfad der Ausgabedatei. Wenn Sie das diffs_file Argument angeben, aber das Verzeichnis weglassen, werden die Dateien im Playbook-Verzeichnis gespeichert. Wenn Sie die Konfigurationen auf mehreren Geräten vergleichen, muss das diffs_file Argument eine Variable enthalten, z. B {{ inventory_hostname }} . um den Dateinamen für jedes Gerät zu unterscheiden. Wenn Sie die Dateinamen nicht unterscheiden, überschreibt die Ausgabedatei für jedes Gerät die Ausgabedatei der anderen Geräte.

Im folgenden Playbook werden Sie aufgefordert, die Rollback-ID einer zuvor festgeschriebenen Konfiguration einzugeben. Das Playbook vergleicht dann die zugesicherte Konfiguration mit der angegebenen Rollback-Konfiguration, speichert den Vergleich in einer eindeutig benannten Datei und gibt die Antwort als Standardausgabe aus.